• w7ngman (unregistered)

    "He hadn't put it into source control yet because it wasn't quite ready"

    It should have at least been in a branch somewhere

  • Andrew (unregistered) in reply to dpm
    dpm:
    KattMan:
    Code in source control should compile, it does not need to be bug free or ready for testing. If that was the case then you would have absolutely no back of any work in progress.

    Getting things to compile is easy, have a call to a function that doesn't exist yet, create a stub. Have a pointer error, comment it out for now. Just make sure it can build.

    Better yet, it doesn't need to compile at all and you don't need to comment out bugs "just for now" (translation: will never get fixed) because you check it in and DON'T ADD IT TO THE MAKEFILE.

    Seriously, why would a build attempt to compile a file just because it was added to source code control? Does someone actually have a wildcard somewhere, saying "cc *.c" ?

    Yes we actually do have a wildcard somewhere, saying "cc *.c"? Gnu MAKE has "suffix rules" that compile all *.c using GCC, all *.cpp as GCC C++ mode, etc. See the ".SUFFIX" Gnu MAKE directive.

    Large projects are very hard to manage without suffix rules. It's unreasonable to add exact filenames for every C, C++, or Fortran source file to the makefile. Even medium projects have 20 or more source files.

    Computer Science departments really need to add a a course on builds & source control!

  • (cs) in reply to Dean Menezes
    Dean Menezes:
    dphunct:
    bdew:
    Anon:
    This story was horrible and stupid.

    This comment is horrible and stupid.

    This thread is horrible and stupid.

    The Internet is horrible and stupid.

    Anyone who uses the phrase "horrible and stupid" is...

  • accident (unregistered)

    Um, you guys are all wrong, in the last paragraph of the article this one links to it says

    They also stripped Jared of his ability to work on any of the sites by revoking access to the servers, disabling all of the nightly batch jobs that he'd created, and deleting his user account from the production site. He wasn't even given read-only access to the code. And that's how Jared could no longer do his job.

    So it isn't a wtf that he didn't check it in, or create backups, he didn't have permission.

  • Nether (unregistered) in reply to dpm
    dpm:
    KattMan:
    Code in source control should compile, it does not need to be bug free or ready for testing. If that was the case then you would have absolutely no back of any work in progress.

    Getting things to compile is easy, have a call to a function that doesn't exist yet, create a stub. Have a pointer error, comment it out for now. Just make sure it can build.

    Better yet, it doesn't need to compile at all and you don't need to comment out bugs "just for now" (translation: will never get fixed) because you check it in and DON'T ADD IT TO THE MAKEFILE.

    Seriously, why would a build attempt to compile a file just because it was added to source code control? Does someone actually have a wildcard somewhere, saying "cc *.c" ?

    Actually, we have projects just like this. A number of directories are compiled with wildcards. We just put files that aren't ready for compilation into different directories. It's easier than maintaining a list of literally thousands of files in a makefile, it's easy to understand, and it works just fine.

  • Anonymous (unregistered)

    Microsoft is surely horrible, but certainly not stupid.

  • (cs)

    Now, see, I don't understand that attitude. "Hey, let's replace this massive, complex system which everyone is afraid to alter because it might break with a new system running on my favorite operating system." Yeah, because nobody is going to blame the inevitable failures of the replacement system on the OS, thus tainting that OS forever in the minds of more or less the entire company. That never happens.

  • Secret Santa (unregistered) in reply to dphunct

    C-C-C-C-COMBO BREAKER!

  • (cs) in reply to Dean Menezes
    Dean Menezes:
    dphunct:
    bdew:
    Anon:
    This story was horrible and stupid.

    This comment is horrible and stupid.

    This thread is horrible and stupid.

    The Internet is horrible and stupid.

    The gloriousness of the Cascades are horrible and stupid!!!!1!!!

  • (cs) in reply to Nick
    Nick:
    Jared and Stephen meet for lunch to talk about code. Meanwhile, Chris and Eva are travailing on a train east bound from Odenville. At what time will Stephen’s code arrive at Ken’s train station in North Havenbrook?

    The answer depends on whether there's a solar eclipse and how many opossums are on board.

  • (cs) in reply to Andrew
    Andrew:
    dpm:
    KattMan:
    Code in source control should compile, it does not need to be bug free or ready for testing. If that was the case then you would have absolutely no back of any work in progress.

    Getting things to compile is easy, have a call to a function that doesn't exist yet, create a stub. Have a pointer error, comment it out for now. Just make sure it can build.

    Better yet, it doesn't need to compile at all and you don't need to comment out bugs "just for now" (translation: will never get fixed) because you check it in and DON'T ADD IT TO THE MAKEFILE.

    Seriously, why would a build attempt to compile a file just because it was added to source code control? Does someone actually have a wildcard somewhere, saying "cc *.c" ?

    Yes we actually do have a wildcard somewhere, saying "cc *.c"? Gnu MAKE has "suffix rules" that compile all *.c using GCC, all *.cpp as GCC C++ mode, etc. See the ".SUFFIX" Gnu MAKE directive.

    Large projects are very hard to manage without suffix rules. It's unreasonable to add exact filenames for every C, C++, or Fortran source file to the makefile. Even medium projects have 20 or more source files.

    Computer Science departments really need to add a a course on builds & source control!

    Please just calm down.

  • Bailey (unregistered)

    The real WTF is the idiot not putting the code into source control after working on it for a month.

  • Jeff (unregistered)

    Well, Ken should be fired, and Jared needs to get the folks at CollaboSmart to use Accurev. If Jared had used Accurev while at Initrode, he could have just 'kept' the file in his private workspace. The file would be safely tucked away in Accurev, even though it was not ready to be shared. Only when Jared or the bone-headed Ken got the script working properly would he then 'promote' the file and make it available to others. Fear of unstable code is virtually eliminated in Accurev because of private developer workspaces and the Keep command.

  • Harrow (unregistered) in reply to dpm
    dpm:
    ...Does someone actually have a wildcard somewhere, saying "cc *.c" ?
    /me quickly edits makefile

    uh... no

    -Harrow.

  • Shill (unregistered) in reply to Dean Menezes
    Dean Menezes:
    dphunct:
    bdew:
    Anon:
    This story was horrible and stupid.

    This comment is horrible and stupid.

    This thread is horrible and stupid.

    The Internet is horrible and stupid.

    Your mom is... actually quite nice and intelligent. I enjoyed the time I spent banging her last night immensely. Say "Hi" for me next time you see her.

  • (cs) in reply to Andrew
    Andrew:

    Yes we actually do have a wildcard somewhere, saying "cc *.c"? Gnu MAKE has "suffix rules" that compile all *.c using GCC, all *.cpp as GCC C++ mode, etc. See the ".SUFFIX" Gnu MAKE directive.

    Large projects are very hard to manage without suffix rules. It's unreasonable to add exact filenames for every C, C++, or Fortran source file to the makefile. Even medium projects have 20 or more source files.

    Computer Science departments really need to add a a course on builds & source control!

    Fine. If you can't use imake, and you just have to use wildcards instead of real dependencies, then you must use branches or some equivalent in your source code control system, to prevent every file, no matter where, from being part of the build, right?

    Nether:
    We just put files that aren't ready for compilation into different directories.

    Well, that's one way.

  • ben (unregistered)

    All the people involved in this story are horrible and stupid. Anyone who runs a company or a system or their life like this is doing it wrong.

  • Obi Wan (unregistered) in reply to TCS
    TCS:
    Ok nice story. But,,,,, How many programmer only have one copy of a peice of code they have worked on for a month.....?

    Uh,,,,,, None.

    So sorry but I'm calling pooo on this whole story.

    No, what you're done is identify the Real WTF(TM). :P

    Sorry, couldn't resist!

  • Some Relationship Expert (unregistered) in reply to Schnapple
    Schnapple:
    suzilou:
    A similar technique, when having a disagreement with someone, is to be the first to say "just calm down". At that point you win.
    Do not try this technique with your spouse, especially your wife. It just pisses them off more. And you will definitely NOT win.

    A woman always has the last word. Anything a man says after that is the beginning of a new fight.

  • (cs) in reply to Outlaw Programmer
    Outlaw Programmer:
    Yeah, I think this is one of those things that will vary by language. With Java, most IDEs will automatically detect and add any new files to the build path. You can manually exclude files but it's difficult to push the list of excluded files to other developers.
    That has nothing to do with the language and everything with the IDE. The most popular Java IDe is eclipse, and it certainly does not have this problem if you structure your project sensibly. On creating a project, eclipse will have you designate one or more "source folders". Only source files inside those folders are considered part of the IDE-internal build. Source folders can be added and removed, and this configuration is saved in a .classpath file in the project's root directory and can be shared with other developers via source control. Works like a charm.
  • (cs) in reply to FredSaw
    FredSaw:
    dpm:
    Seriously, why would a build attempt to compile a file just because it was added to source code control?
    Because your team is using Cruise Control.
    Cruise Controls does NOT require each and every file to be part of the build; I don't even think it defaults to that. I only tinker with our Cruise Control configuration occasionally, but it explicitly lists the directories which are to be compiled for the build; anything outside them is not.
  • Obi Wan (unregistered) in reply to Lysis
    Lysis:
    Dean Menezes:
    dphunct:
    bdew:
    Anon:
    This story was horrible and stupid.

    This comment is horrible and stupid.

    This thread is horrible and stupid.

    The Internet is horrible and stupid.

    The gloriousness of the Cascades are horrible and stupid!!!!1!!!

    And this, my friends, is how everyone contributed to the Universe so it is the way it is today...which, of course, is why it is HORRIBLE AND STUPID!! (Calming down, calming down...)

  • morry (unregistered)

    I had a friend who stayed behind, just like Stephen, but he felt it was my duty to consult - as he was in charge of the application after I left. For about 2 months, I fielded 3 calls from my friend for assistance. Eventually (I felt he'd used up all his friend points), I suggested to him that maybe the company needed to hire me as a temporary consultant in order for me to fix these problems. He got the point.

    and now I've forgotten why I wanted to add this story. Someone find a point in here somewhere.

  • MS (unregistered) in reply to MK

    Production branch? What's a branch?

  • (cs)

    The true WTF is that nobody yet has commented that Java is horrible and stupid, and so is anyone who uses (let alone loves) it.

    Are all Java haters on an outdoor trip away from civilization?

  • Ken B (unregistered) in reply to Schnapple
    Schnapple:
    suzilou:
    A similar technique, when having a disagreement with someone, is to be the first to say "just calm down". At that point you win.
    Do not try this technique with your spouse, especially your wife. It just pisses them off more. And you will definitely NOT win.
    A better technique with the wife is "geez, is it that time of the month again?"
  • (cs) in reply to Jeff
    Jeff:
    Well, Ken should be fired, and Jared needs to get the folks at CollaboSmart to use Accurev. If Jared had used Accurev while at Initrode, he could have just 'kept' the file in his private workspace. The file would be safely tucked away in Accurev, even though it was not ready to be shared. Only when Jared or the bone-headed Ken got the script working properly would he then 'promote' the file and make it available to others. Fear of unstable code is virtually eliminated in Accurev because of private developer workspaces and the Keep command.
    Why is Everybody so clueless on the importance of Accurev...
  • September ain't over yet (unregistered) in reply to Zylon
    Zylon:
    dphunct:
    bdew:
    Anon:
    This story was horrible and stupid.
    This comment is horrible and stupid.
    This thread is horrible and stupid.
    This forum is horrible and stupid.
    Me too!
  • Teh Optermizar (unregistered) in reply to morry
    morry:
    I had a friend who stayed behind, just like Stephen, but he felt it was my duty to consult - as he was in charge of the application after I left. For about 2 months, I fielded 3 calls from my friend for assistance. Eventually (I felt he'd used up all his friend points), I suggested to him that maybe the company needed to hire me as a temporary consultant in order for me to fix these problems. He got the point.

    and now I've forgotten why I wanted to add this story. Someone find a point in here somewhere.

    Happy to oblige :)

    The point: Friends don't drag friends back into shitty jobs that they have elected to leave.

    As an amusing semi-related anecdote of my own, I once worked at a place where people were being let go due to cash-flow problems (and the execs tried to martyr themselves by claiming they were shielding the rest of us and taking a pay cut), the inevitable exodus began. I got wind of the company's dire situation regarding a massive outstanding tax debt and the fact that they had not paid into any employees' pensions for the previous 12+ months (required by law in that country), and that was it... I had a brief discussion with a few of my colleagues and packed it on the spot.

    As I was one of the last senior developers left, the execs made a desperate bid to keep me around by dangling a very large lump-sum carrot and offering to pay me as a consultant for further work (neither of which they could actually afford to do)... I was so torn between just laughing myself into a coma at the absurdity of their obvious bluffing and launching into a fiery tirade telling just how I felt about being lied to that I just coldly refused, and asked them never to contact me again.

    Of course, they did contact me again not 2 weeks later to see if I had changed my mind and ask me for help on a problem they were having... funnily enough, I didn't feel like helping them.

  • (cs) in reply to brazzy
    brazzy:
    FredSaw:
    dpm:
    Seriously, why would a build attempt to compile a file just because it was added to source code control?
    Because your team is using Cruise Control.
    Cruise Controls does NOT require each and every file to be part of the build; I don't even think it defaults to that. I only tinker with our Cruise Control configuration occasionally, but it explicitly lists the directories which are to be compiled for the build; anything outside them is not.
    I'm not sure whether you're expanding on the topic, or you think you're refuting something I said. I only said that Cruise Control initiates a build when a file is checked in to source control. Get specific about folders and such, if that pleases you; it doesn't alter my point.
  • (cs) in reply to MK
    MK:
    There's got to be a bit of a question over why it wasn't in source control, I mean ready or not the latest version should have been there so it gets the same protection as the rest of the source code. It doesn't need to be in the production branch.

    Am I the only person in the world who insists on working in his own branch?

  • (cs) in reply to Nick
    Nick:
    This article reads like a bad S.A.T problem. Jared and Stephen meet for lunch to talk about code. Meanwhile, Chris and Eva are travailing on a train east bound from Odenville. At what time will Stephen’s code arrive at Ken’s train station in North Havenbrook? I’m so sick of names!!!
    Wonder what they were working so painfully hard on, on that train.
  • MikeCD (unregistered) in reply to Andrew

    At least Jared had the decency to be embarrassed about not putting the script into source control.

    Andrew:
    Yes we actually do have a wildcard somewhere, saying "cc *.c"? Gnu MAKE has "suffix rules" that compile all *.c using GCC, all *.cpp as GCC C++ mode, etc. See the ".SUFFIX" Gnu MAKE directive.

    Large projects are very hard to manage without suffix rules. It's unreasonable to add exact filenames for every C, C++, or Fortran source file to the makefile. Even medium projects have 20 or more source files.

    Computer Science departments really need to add a a course on builds & source control!

    Suffix rules are not build wildcards. The corresponding .o still has to be depended upon by one or more targets for a suffix rule to trigger (I'm speaking of a typical C or C++ project).

    Just putting a "foo.c" in a source directory will not cause it to compile into "foo.o" unless something else depends on foo.o or unless it's explicitly built with something like "make foo.o".

    Of course this is all an unrelated tangent since the story is talking about a script, which most likely wasn't built at all.

  • (cs) in reply to FredSaw
    FredSaw:
    Nick:
    This article reads like a bad S.A.T problem. Jared and Stephen meet for lunch to talk about code. Meanwhile, Chris and Eva are travailing on a train east bound from Odenville. At what time will Stephen’s code arrive at Ken’s train station in North Havenbrook? I’m so sick of names!!!
    Wonder what they were working so painfully hard on, on that train.

    Eva was implementing Chris' interface to inherit portions of Chris' code so that child process can use polymorphism to look like both of them.

    How's that for being an uber geek.

  • AuMatar (unregistered) in reply to Andrew
    Andrew:
    dpm:
    KattMan:
    Code in source control should compile, it does not need to be bug free or ready for testing. If that was the case then you would have absolutely no back of any work in progress.

    Getting things to compile is easy, have a call to a function that doesn't exist yet, create a stub. Have a pointer error, comment it out for now. Just make sure it can build.

    Better yet, it doesn't need to compile at all and you don't need to comment out bugs "just for now" (translation: will never get fixed) because you check it in and DON'T ADD IT TO THE MAKEFILE.

    Seriously, why would a build attempt to compile a file just because it was added to source code control? Does someone actually have a wildcard somewhere, saying "cc *.c" ?

    Yes we actually do have a wildcard somewhere, saying "cc *.c"? Gnu MAKE has "suffix rules" that compile all *.c using GCC, all *.cpp as GCC C++ mode, etc. See the ".SUFFIX" Gnu MAKE directive.

    Large projects are very hard to manage without suffix rules. It's unreasonable to add exact filenames for every C, C++, or Fortran source file to the makefile. Even medium projects have 20 or more source files.

    Computer Science departments really need to add a a course on builds & source control!

    20 files? I've dealt with programs with 100s of files, and we added each one. The trick is you break your code up into directories, and each directory has its own makefile. Then the directories only need to be added to the global makefile. The idea of compiling everything of a given type is absolutely asinine. A piece of code should only be compiled when its ready to be part of the project- when a human adds it to the makefile. Anyone who thinks compiling *.cpp is a good idea should never be allowed to touch a build system again.

  • (cs) in reply to Some Relationship Expert
    Some Relationship Expert:
    Schnapple:
    suzilou:
    A similar technique, when having a disagreement with someone, is to be the first to say "just calm down". At that point you win.
    Do not try this technique with your spouse, especially your wife. It just pisses them off more. And you will definitely NOT win.

    A woman always has the last word. Anything a man says after that is the beginning of a new fight.

    "If a man speaks; and there is no woman to hear - is he still wrong?"
  • (cs) in reply to FredSaw
    FredSaw:
    brazzy:
    FredSaw:
    dpm:
    Seriously, why would a build attempt to compile a file just because it was added to source code control?
    Because your team is using Cruise Control.
    Cruise Controls does NOT require each and every file to be part of the build; I don't even think it defaults to that. I only tinker with our Cruise Control configuration occasionally, but it explicitly lists the directories which are to be compiled for the build; anything outside them is not.
    I'm not sure whether you're expanding on the topic, or you think you're refuting something I said. I only said that Cruise Control initiates a build when a file is checked in to source control. Get specific about folders and such, if that pleases you; it doesn't alter my point.
    It does alter your point because Cruise Control will NOT initiate a build for just any file, but only for those it is configured to consider part of the build. Thus, there is no reason to keep experimental code out of source control, whether there is a Cruise Control build or not.
  • (cs) in reply to brazzy
    brazzy:
    FredSaw:
    brazzy:
    FredSaw:
    dpm:
    Seriously, why would a build attempt to compile a file just because it was added to source code control?
    Because your team is using Cruise Control.
    Cruise Controls does NOT require each and every file to be part of the build; I don't even think it defaults to that. I only tinker with our Cruise Control configuration occasionally, but it explicitly lists the directories which are to be compiled for the build; anything outside them is not.
    I'm not sure whether you're expanding on the topic, or you think you're refuting something I said. I only said that Cruise Control initiates a build when a file is checked in to source control. Get specific about folders and such, if that pleases you; it doesn't alter my point.
    It does alter your point because Cruise Control will NOT initiate a build for just any file, but only for those it is configured to consider part of the build. Thus, there is no reason to keep experimental code out of source control, whether there is a Cruise Control build or not.
    No, it doesn't alter my point. You are misquoting me. I didn't say "any file". He asked why checking a file into source control would fire a build. I answered that it would happen if your team is using Cruise Control. And so it will, under the constraints of whatever configuration has been specified.

    Most folks don't always find it necessary to give all the details, history, context and modifying factors with every statement they make. That kind of stuff is generally implicit in the statement and understood by the listener/reader. Otherwise, every sentence would become a book.

  • Andy (unregistered) in reply to Andrew

    [quote user="Andrew]Computer Science departments really need to add a a course on builds & source control![/quote]

    I'm not going to disagree that source control is important, but it hardly falls under "Computer Science". A CS degree doesn't (and shouldn't) mean someone knows how to program - aren't there technical schools for that?

    Where I'm from, CS == theory.

  • Stiggy (unregistered) in reply to Obi Wan

    Every single Universe in the Multiverse is horrible and stupid, except one.

    But this isn't it.

  • Stiggy (unregistered)

    Clicking Reply when you meant to click Quote is horrible and stupid.

  • (cs) in reply to Andy
    Andy:
    A CS degree doesn't (and shouldn't) mean someone knows how to program - aren't there technical schools for that?

    Where I'm from, CS == theory.

    So, what... you make conversation about CS theory with the customer while you're sacking up the big mac and fries she ordered?

  • (cs)

    There's no "right" or "wrong" way of doing this...

    Source control is one of the many tools you use, and you use it in such a way that fits your development strategy.

    If you're on the kind of team/project that doesn't try to integrate everything until it's all "ready" to go, then not adding things to the build but shoving it in source control anyway is fine.

    If you take the approach of developing in parallel with your teammates or in parallel with other teams, you can get shit done a whole lot faster if you write skeleton code, put some preprocessor warning directives in, and THEN check in, as it will compile and exposes interfaces for the other developers/teams to use, so that integration isn't its own step in the process.

    I may absolutely hate that first philosophy, but that doesn't make it "wrong."

  • dkf (unregistered) in reply to FredSaw
    FredSaw:
    Andy:
    A CS degree doesn't (and shouldn't) mean someone knows how to program - aren't there technical schools for that?

    Where I'm from, CS == theory.

    So, what... you make conversation about CS theory with the customer while you're sacking up the big mac and fries she ordered?
    Any CS graduate worth the salt on that big mac and fries should be able to figure out make without specific tutoring on the topic. They've had an advanced education; they're supposed to know how to learn without spoon-feeding.

  • dkf (unregistered) in reply to FredSaw
    FredSaw:
    Most folks don't always find it necessary to give all the details, history, context and modifying factors with every statement they make. That kind of stuff is generally implicit in the statement and understood by the listener/reader. Otherwise, every sentence would become a book.
    What sort of book? Who by? Would it have pictures in it? Would the binding on the book be leather, and if so would it be ethically sourced? If every sentence is going to be a book, it's vitally important that we don't cause unnecessary suffering to animals in the process. And pictures are good anyway; they could even be of the ethically-correct process used to produce the binding! Kill two birds with one stone (metaphorically though, and with absolutely no actual harm caused to any extant avians).
  • dkf (unregistered) in reply to A Nonny Mouse
    A Nonny Mouse:
    those that are saying he should have checked his script in: no i disagree. if something is not ready then it shouldn't go into source control. my basic assumption is that if something is in then as far as the developer is concerned, it works.
    It's better to have different branches, with some that are sandboxes (I'd name those with "sandbox" in there just so that anyone ignoring it is an obviously stupid jerk; YMMV) and others that hold code that is fit to be used by people not working on the specific feature. Like that, it's much easier to collaborate on a sandbox (sometimes needed) and you centralize the backup of the code. This applies doubly if you're working in a distributed team. Autobuilding the mainline/release/maintenance branches is fine, but doing so to peoples' sandboxes is just a way to make noise and stops people from getting their code safe. (Hence the article!)
    A Nonny Mouse:
    i learned this the hard way - someone checked something in, someone else cavalierly released it to UAT, and i was the fire fighter lumped with the messy rollback
    Couldn't you just roll back (or rather reverse-patch) to a particular time/date? That's a pretty trivial operation with at least some version control systems...
  • Vlad (unregistered) in reply to MK

    Right; I too find the practice of keeping a code for a month without submitting and/or backing it up extremely horrible and stupid. By the way, the guy could have lost it without the help of others, just as a result of disk crash.

  • (cs) in reply to Obi Wan
    Obi Wan:
    Lysis:
    Dean Menezes:
    dphunct:
    bdew:
    Anon:
    This story was horrible and stupid.

    This comment is horrible and stupid.

    This thread is horrible and stupid.

    The Internet is horrible and stupid.

    The gloriousness of the Cascades are horrible and stupid!!!!1!!!

    And this, my friends, is how everyone contributed to the Universe so it is the way it is today...which, of course, is why it is HORRIBLE AND STUPID!! (Calming down, calming down...)

    The previous and rather short-lived name of this site was h... oh never mind.

  • David Schwartz (unregistered)

    I constantly have to fight with developers about putting unfinished work into a source control system. It's needed for at least the following reasons:

    1. Development history is lost. The reason for changes is never recorded. Code you decided you no longer needed is permanently lost.

    2. It is impossible for managers to keep track of what you are doing. If the developing code isn't what they wanted, they won't be able to tell you until you've wasted days.

    3. If you die or your hard drive crashes, your work may never be found.

    4. Commit notices keep people informed of what you're doing and what issues you are running into. No commit notices makes it impossible to know how you're spending your time.

    The arguments presented against doing so are bogus. You can create a branch or a private development repository. You can add special code to keep the program from running unless it's on your machine, or whatever is needed.

  • El_oscuro (unregistered)

    How can anyone say Windows is "A Horrible and Stupid System"? I mean, everyone knows Windows is the best system ever writte

    *** STOP: 0x00000050 (0x37DFEF3D, 0x00000001, 0x42FE1256, 0x00000000)

    *** SPCDMCON.SYS (Address FB3DE7E5 base at FBFE5000 Datestamp 3dd37cd3

    • no carrier *

Leave a comment on “The Horrible and Stupid System”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article