Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Bug Entertainment Games

Follow-up on EVE's Boot.ini Issue 169

Krinsath writes "CCP, publishers of Eve Online, have posted a Dev Blog detailing the circumstances leading up to the deletion of XP's boot.ini file, which was earlier discussed on Slashdot. The blog post has intimate details about how the mistake occurred (a new installer from their normal one), how they responded and what CCP has learned from it. While fairly dry, it is to the company's credit that they're being open about one of the more serious bugs to crop up in gaming's recent history."
This discussion has been archived. No new comments can be posted.

Follow-up on EVE's Boot.ini Issue

Comments Filter:
  • by Silverlancer ( 786390 ) on Saturday December 15, 2007 @02:23AM (#21706458)
    Now if only more businesses acted this way.
    • But they should delete greater percentages of XP...
    • by Animaether ( 411575 ) on Saturday December 15, 2007 @02:48AM (#21706528) Journal
      what of the users who did lose valuable computer time due to this problem? The proverbial kid handing in their homework (or dissertation paper or whatever), for example. Apologizing and willing to pay for a third party tech support service (e.g. Geek Squad) is nice and all, but does that cover damages incurred? doubtful. Perhaps that EULA will finally get a test.

      As for the bug itself... the installer code is NSIS script; quite powerful, but you do need to know what you're doing. Especially with a command such as "Delete", I can't help but wonder who failed to RTFM (TFM reads, as they point out, that "Delete" requires a full path to be safe or else it expects the path to be root) and instead made an -assumption- on how it would work.

      Now, to their defense, NSIS is also a little inconsistent (RMDir needs /r to be recursive, but DeleteRegKey needs /ifempty to NOT be recursive; whatthe.) and I've wiped my entire root myself while developing an installer with it, although via a more complex bug.. NSIS simply doesn't have any built-in "you dumbass"-protection like most commercial installers.

      Although I think it's nice of them to say that they're not blaming Windows for their own mistake, I do honestly think that Windows should protect such vital files at all cost - including against Administrator level process (e.g. a prompt "you dumbass - are you sure?" will do).
      • by TooMuchToDo ( 882796 ) on Saturday December 15, 2007 @02:51AM (#21706548)

        what of the users who did lose valuable computer time due to this problem? The proverbial kid handing in their homework (or dissertation paper or whatever), for example. Apologizing and willing to pay for a third party tech support service (e.g. Geek Squad) is nice and all, but does that cover damages incurred? doubtful. Perhaps that EULA will finally get a test.

        Almost never will damages be covered. Come to think of it, I think in this case I can say "Damages will never be covered." You have to show value and proof of destruction of that value. Your homework being destroyed? Your dissertation being destroyed? While it may have a large amount of value to you, monetarily it has very little value.

        • Re: (Score:2, Informative)

          Almost never will damages be covered. Come to think of it, I think in this case I can say "Damages will never be covered." You have to show value and proof of destruction of that value. Your homework being destroyed? Your dissertation being destroyed? While it may have a large amount of value to you, monetarily it has very little value.

          Lost homework is usually only about 1-3 weeks of lost work. Often less. Dissertations are a whole different beast.

          A lost dissertation has a lot more value than sentimental value. You've spent X years of your life working on it, with the clear expectation that you have a high probability of getting a PhD. Having a PhD means getting a job that pays better than the pay of a graduate student. If graduate student pay is $Y, and reasonable post-doctoral pay is $Z, and you lost X years of work due to the bug

          • Re: (Score:2, Insightful)

            by petermgreen ( 876956 )
            Data stored without backups is vulnerable to many things. Buggy software, viruses, hardware failure and so on. If you lose data as valuable as a phd thesis due to such a failure then IMO you who have been negligent.

            We don't expect hardware vendors to provide anything more than a replacement when thier products fail and I don't see why software should be any different.

          • by Runefox ( 905204 )
            Wha? You keep your dissertation in boot.ini? Clever.

            This deleted a single file, and even if it were to delete every file on your hard drive, you'd still have the option of recovery software. A delete without an overwrite is as simple as pie to recover, so if you've spent years on your dissertation, just spend the hour or so it'll take to get it back, if you haven't backed it up. Before you say it, yes, this is an installer, but if your installer flattened a hard drive before installing its software, you're
        • by Ost99 ( 101831 )
          Even though the bug deleted a file, it's not possible to lose data due to this bug.
          The only thing you stand to lose is a few minutes (or hours) of production time due to a non booting system.
        • Your dissertation being destroyed?
          If the crash of your computer means your "dissertation being destroyed", you may be too stupid for a PhD anyway. nothing.
        • by Belial6 ( 794905 )
          I don't know what they do now, but about 15 year ago I did development for a company call FSC. We wrote insurance rating software. You know those adds that advertise they compare rates between different companies? That's the kind of application we wrote. Amazingly enough, we actually guaranteed that our software would produce the correct data. If the real cost was different than what our software quoted (and the error was not due to bad data being input) FSC paid the difference. This did mean that we
      • by zippthorne ( 748122 ) on Saturday December 15, 2007 @02:57AM (#21706576) Journal

        what of the users who did lose valuable computer time due to this problem?


        That's a good point. And generates some good advice for future student/gamers: Do not install any new software of any kind a week or two before a paper is due*

        *at least, not without having some kind of back-up which can be read and worked on on another computer and which you regular test.

        TFM reads, as they point out, that "Delete" requires a full path to be safe or else it expects the path to be root


        That sounds like the the opposite of a good way for delete to fail.
        • That's a good point. And generates some good advice for future student/gamers: Do not install any new software of any kind a week or two before a paper is due*

          Well, over at my university we have deadlines every second week or so... that advice would pretty much require you to not keep your system up to date with patches. This would be why I backup my entire /home directory to an external drive that isn't connected when I'm not making the backups, and keep copies of important papers on a USB key I carry with

        • Re: (Score:3, Funny)

          by LarsG ( 31008 )
          Do not install any new software of any kind a week or two before a paper is due

          ITYM "Don't install an addictive game before a paper is due."

      • Although I think it's nice of them to say that they're not blaming Windows for their own mistake, I do honestly think that Windows should protect such vital files at all cost - including against Administrator level process (e.g. a prompt "you dumbass - are you sure?" will do).

        Isn't the first thing most people do on Vista is turn off the Administrator "Are you sure?" prompts?

        (I know that personally I do not- I don't get them more than a half-dozen times a day, if that, so it's really not that big a deal.)

      • If you really want that sort of behaviour, why haven't you switched to Vista? That sort of behaviour is a big part of why hardly anyone is?
        • I have Vista running on one of my machines, as I need to be able to test on it.

          And no, I'm not referring to Vista's behavior of demanding Admin rights for a ton of things.. though I don't have a direct problem with that.. if somebody does, have them run as administrator.
          I'm only referring to popping up a big fat warning when you are (or something else is) about to do something to a critical system file where the change could very well leave the machine unbootable without a boot or rescue disc. As long as t
      • Why weren't these people backing up their work (let alone definitely needing it when using an operating system well known for its bugs)?
      • Comment removed based on user account deletion
      • Its interesting to note that its impossible to do stuff like that accidentally under Linux. /boot/ is usually unmounted once its not needed and *nothing* should be touching anything in there anyway.

        Oh well. Thats what Windows users get for using a really bad file layout.
        • When cloning my linux from old hd to new hd, I accidentally forgot to change the label name back for the root= entry in grub. and couldnt boot unless I fixed it with the repair CD console login.

          Its as fragile as boot.ini, though I personally have a few copies of it and /boot.copy /local/boot.old

          What linux needs is like the old VMS days of auto versioning, grub.conf;1 etc...

          If its a system core component config, then its smart to do it for that, HD space is plenty for text files.
          • a) You were moving partitions around, not installing a game patch. :P
            b) Why didnt you simply press 'e' at the grub screen? You can edit how it boots from its self.
        • I don't think I've seen any Linux distribution where /boot is unmounted after boot, and most of the newer ones tend to default to a single-partition layout. A better example would be something like the FreeBSD boot loader, where the multiboot code lives in the boot sector (512 bytes of really neat assembly code) and presents a menu for selecting the partition or disk to boot from. Even if the entire FreeBSD partition is nuked you can still boot into any other operating systems you might have installed.
        • by mrbooze ( 49713 )
          Also presumably in linux you wouldn't be running the game client update process as a user who even *could* touch the system boot environment even if it wanted to.

      • You realise most people on Slashdot attack Vista for doing what you suggested.
      • There's a provision in the EULA that says basically that they aren't responsible for anything bad that happens to you as a result of using their software, and that it should not be used in any environment where a person's life or livelihood is at stake.

        In short, those people should have followed the EULA.
      • ...I do honestly think that Windows should protect such vital files at all cost - including against Administrator level process (e.g. a prompt "you dumbass - are you sure?" will do).
        You mean one of these [wikimedia.org]?
      • "Delete" requires a full path to be safe or else it expects the path to be root
        This seems like a bad design to me. Even aside from being inconsistent with the other file operations, which operate relative to a directory you set, if it requires a full path to be safe it should require a full path period. Assuming the root directory of a drive (which one? how does it decide?) is a bad decision for it to make.
      • Although I think it's nice of them to say that they're not blaming Windows for their own mistake, I do honestly think that Windows should protect such vital files at all cost - including against Administrator level process (e.g. a prompt "you dumbass - are you sure?" will do).

        I disagree on this one. If I want to mess with my boot.ini or similar files as administrator, the operating system should not get in my way.
        This is not limited to Windows by the way, the default settings of certain other systems are al

    • Re: (Score:3, Funny)

      by Ecuador ( 740021 )
      Yeah, if only more businesses did not test products enough before deployment, or read TFM when using delete commands...

      AND THEN they send GEEK SQUAD to "fix" your computer. Talk about adding insult to injury!
  • by AndrewBuck ( 1120597 ) on Saturday December 15, 2007 @02:42AM (#21706508)
    From the article...

    "Why doesn't Windows protect its system startup files? That's a good question, one that I have asked myself in these last few days and wish I knew the answer. But of course I'm not going to blame Microsoft for our mistake. Windows doesn't protect those files and therefore software developers must take care not to touch them. We should have been more careful."

    That is a good question. I am not an EVE player myself so I don't know if this update had to be run with admin privileges but it doesn't appear to be that way from the question and reply. If you are not running as admin then how is it even possible to remove a system file that is necessary to boot the system. Unlike the EVE representative making this statement I am going to blame Microsoft, it should not be the developers responsibility to make sure they don't break the OS, it is the OS developers responsibility to make sure that it cannot be broken without admin/system/root access.

    -Buck
    • by Osty ( 16825 ) on Saturday December 15, 2007 @02:59AM (#21706592)

      That is a good question. I am not an EVE player myself so I don't know if this update had to be run with admin privileges but it doesn't appear to be that way from the question and reply. If you are not running as admin then how is it even possible to remove a system file that is necessary to boot the system. Unlike the EVE representative making this statement I am going to blame Microsoft, it should not be the developers responsibility to make sure they don't break the OS, it is the OS developers responsibility to make sure that it cannot be broken without admin/system/root access.

      Two things to note:

      1. This was an XP problem. Technically it could've happened on Vista, but I haven't seen anything that said it did. As such, this falls into the same category of problems that Microsoft attempted to fix in Vista with UAC -- nearly everybody ran XP as admin, and many apps expected you to be running as admin.
      2. This was a problem with an installer/uninstaller. Since nearly everything on Windows installs into %programfiles% and that's a shared location, installers need admin access (installers that ask if you want to install for "Just this user" or "Everyone" are not going to install in %userprofile% if you choose "Just this user". They're just looking to see if the Start Menu shortcuts should go into "%appdata%\Microsoft\Windows\Start Menu" or "%allusersprofile%\Microsoft\Windows\Start Menu"). Vista will elevate your privleges when you try to run an installer (you'll get a UAC prompt), after which a misbehaving installer could screw up boot.ini. Regardless of operating systems, you almost always install applications as administrator. Yes, you can install apps in $HOME on *nix systems, but 9 times out of 10 you'll use sudo on the installer (sudo apt-get install foo). Therefore this is technically a bug that could happen on any OS. It's not difficult to imagine an application install that deletes your kernel image, for example.
      The real WTF here is that they have an important game file named "boot.ini". That's an exceedingly poor choice of filename. Think of it like having a game file called "autoexec.bat" or "vmlinuz" that actually has nothing to do with the DOS boot process or the Linux kernel. The only defense they give for that is "legacy".
      • This could indeed happen on any system. I saw a Perl script in Linux just today that said ${directory}/file. The directory variable was empty and it tried to write to /file. Fortunately, it didn't have permissions to do anything damaging. Hopefully it would have been better written if it did run with those permissions.

        Didn't Quake have an autoexec.bat file as a startup script?
        • by RulerOf ( 975607 ) on Saturday December 15, 2007 @04:58AM (#21706966)

          Didn't Quake have an autoexec.bat file as a startup script?
          Quake 3, and I assume for 2 and 1, contained a file called "autoexec.cfg." I always thought it was aptly named, being a DOS veteran myself, because it contains game configs like default keybindings (e.g. bind w +move) and such that actually allow you to control the game in the first place, and it's always called during game startup. Very similar in function to the file that it is named after.
          • by WWWWolf ( 2428 )

            Quake 3, and I assume for 2 and 1, contained a file called "autoexec.cfg."

            Yup, Quake 1 and 2 have that file too (though it doesn't seem to be always present, unless created by the user - at least for me, it seems that the only game where it gets automatically created if it doesn't exist is Quake 1). It also seems to appear in Doom 3 and Quake 4, and I assume every game other game based on id engines.

        • by Ilgaz ( 86384 ) *

          This could indeed happen on any system. I saw a Perl script in Linux just today that said ${directory}/file. The directory variable was empty and it tried to write to /file. Fortunately, it didn't have permissions to do anything damaging. Hopefully it would have been better written if it did run with those permissions.

          Didn't Quake have an autoexec.bat file as a startup script?

          It can't happen on some systems like OS X.

          There is no boot.ini -of course- but lets try deleting a system file necessary for booting

          Ilgaz:etc ilgaz$ rm rc.common
          override rw-r--r-- root/wheel for rc.common?

          That would happen.

          Applications doesn't even need to care what are in root or system init directories since they are in /Applications , actually they are Directories looking like Applications. They just care about their own .app directory in /Applications .

          Lets say they need to install/update a framework.

      • Re: (Score:3, Funny)

        by mav[LAG] ( 31387 )
        Technically it could've happened on Vista, but I haven't seen anything that said it did.

        Well, that would require a group of people who have Vista installed.
      • by m4g02 ( 541882 )
        Technically it could've happened on Vista

        Wrong, Vista no longer use a boot.ini file, changes to the boot process can only be made by running bootsect.exe in a CMD window.
      • by RonnyJ ( 651856 )
        The "legacy" defense they give is exceedingly weak, in fact non-existent.

        Windows 2000 was released in 1999, XP in 2001, both use boot.ini - yet they say they named it in 2001 but say the name is there because of "legacy"? This could have happened back in 2001, they couldn't have used the "legacy" excuse then. I'd sooner they said 'yeah, we gave a file a silly name, and didn't realise'.
      • by Andy Dodd ( 701 )
        Technically it couldn't have happened on Vista for other reasons - Vista does not use boot.ini at all to boot up apparently.
      • Technically it could've happened on Vista

        Actually, it couldn't. Vista neither uses nor even has a boot.ini file (it's not even there in some legacy form). Vista's bootloader is rather more complex than ntldr, mostly (AFAIK) because it needs to be for BitLocker (Vista's full-drive encryption tool, which requires a separate boot partition since the entire system volume gets encrypted). This new bootloader also uses a different configuration store, and boot.ini has been removed entirely.

    • Re: (Score:3, Interesting)

      I did patch EVE as a non-privileged user on my XP Pro system and the problem didn't happen to me. It does seem to be that since most people basically have to run as an administrative account to make XP "work", CCP was able to damage the OS as they did.

      This is a multi-part failure. One part Microsoft for making an OS that almost requires standard users to run a privileged account all the time to make basic applications work. One part CCP for developing software that damaged the underlying OS.

      My only hope i

    • Re: (Score:3, Interesting)

      by Deviate_X ( 578495 )

      "how is it even possible to remove a system file that is necessary to boot the system. Unlike the EVE representative making this statement I am going to blame Microsoft,"

      The boot.ini file is actually protected. It is specifically marked as a System File, Read-Only and Hidden. This means that to modify the file you need to remove these attributes in a specific order first before you can modify or delete it, even if you are logged in as Administrator.

      The only way to prevent software from doing bad things

      • This means that to modify the file you need to remove these attributes in a specific order first before you can modify or delete it,
        According to the windows API docs you only have to remove the "read only" attribute (which you end up with among other things for files copied direct from CD so it is not unreasonable for an install scripting tool to be pretty agressive about removing it) to use deletefile
  • by _Shad0w_ ( 127912 ) on Saturday December 15, 2007 @02:54AM (#21706562)

    If only more companies were so honest and straight forward when they cockup. It almost makes me feel like playing EVE again. CCP can consider themselves as being given a virtual karma bonus.

    Although I can't help but wonder if the "honesty is the best policy" choice was because of their handling of the last PR cockup.

    • They're trying to make up for lost karma in the seemingly unending employee-player scandals.
      I'd probably give it another go, it's not really that bad for an online spreadshzzzzZZZZZZ
      • I'd probably give it another go, it's not really that bad for an online spreadshzzzzZZZZZZ

        Pvp is pretty awesome in Eve, but there are a lot of parts in the game that could really use some improvmezzzZZZZzzzzzZZZ

  • Comment removed based on user account deletion
  • While it's nice to know the technical reasons for problem, it still does not answer why they failed to take note of this problem when it was originally reported and discussed on the beta server's message board two days before the expansion hit the live servers.

    It's in the eight post of this [eve-online.com] thread.
  • Alright! (Score:4, Funny)

    by Cheezymadman ( 1083175 ) on Saturday December 15, 2007 @04:21AM (#21706834)
    Finally, a benefit to Vista! Vista users like myself were 100% unaffected by this. It was awesome.
  • by Nezer ( 92629 ) on Saturday December 15, 2007 @04:41AM (#21706884) Homepage
    I have never been into MMOs. I just didn't get them. However, in the last week things have changed and it's due, in part, to this bug.

    You see, until this bug happened EVE was totally off my RADAR screen. When I read about the bug on /. last week I went to the companies website and found myself intrigued. Further discovery that they didn't charge $50 for the box on top of the monthly fee was also appealing. Further, I see client software for Macs and Linux. Intrigued I download the Mac client and create the trial account. Two days later I'm hooked and sending them my CC #.

    If it hadn't been for this bug, I probably would have never bought their product! They say that any publicity is good publicity and I think this is true. Sure the SNAFU was pretty bad yet the product was still compelling enough to buy it despite a pretty bad QA miss. This latest response from the company will only help further get their name out there and is truly an opportunity to make lemonade from lemons.
    • Hmmm... if money was an issue, you should take a look at Guild Wars: pay for the game, but there's no monthly fee.
  • Now if I could count how many hours of my life have I wasted because of disappeared boot.ini's, geez. Nice move, still.

  • by Antique Geekmeister ( 740220 ) on Saturday December 15, 2007 @06:46AM (#21707362)
    Having violated /. policies and actually Read The Fine Article, it was a good analysis. I wish more people would write their bug reports this well, and explain how they're going to address the problem.

    I also wonder if they wouldn't benefit from a nice virtual environment system to do QA testing of new releases with? Capturing the full graphical behavior of an OS is difficult in virtual systems, due to the overhead of the virtualization itself, but it might be a lot cheaper than keeping a dozen different hardware configurations around.
  • When is MS Windows going to get proper package management?
    These sort of problems are not something that should be occuring in a modern operating system.
    • It wouldn't have mattered. Unless your package manager runs as a special user who has carefully controlled privileges and you have some form of rôle-based access control this could still happen. A *NIX package can typically run pre- and post-install scripts (as root) and so it would be easy for the developer to accidentally do 'rm -rf boot' and have it delete the contents of the boot partition rather than the initialisation files for the package, since they forgot that the installer ran in the root d
      • by Jessta ( 666101 )
        I can't speak for other package managers but the gentoo package manager(emerge) runs the installer in a sandbox, it then copies the relevent files to the system while checking to see if they conflict with the files of any other package.
        An rm -rf in an install script will not do anything to the system.
        • How does this work with things like PostgreSQL, where the update procedure between major versions requires connecting to the live db, dumping the data and then restoring it, or for other packages where some configuration beyond simple modification of configuration files is required?
        • Comment removed based on user account deletion
        • I suspect you are misinterpreting what the original poster meant by install script.

          On debian the upstreams installation script/target is typically only used to copy the files to a staging area during package build (though if you are lazy and build packages as root it can still do damage if it is buggy). But there are scripts that are part of the package which are run when the package is installed or removed to allow the package to update configuration and so on. If those scripts are buggy then they can defi
  • by Anonymous Coward
    Read it as CCCP and not CCP and everything becomes a whole lot clearer
  • by Daimanta ( 1140543 ) on Saturday December 15, 2007 @09:35AM (#21708194) Journal
    Programming guy 1: So we're finally done with coding everything.
    Programming guy 2: Yeah finally.
    *Programming guy 2 tries to make a joke*
    Pr. guy 2: Hey pr. guy 1, look at this
    Pr. guy 1: lol, you appended a del boot.ini
    Pr. guy 2: Well, I'm going to take a coffee break
    Pr. guy 1: Yeah, me too
    Pr. guy 2: Wait, lets put a sticky-note on the board that we're done
    Pr. guy 1: Sure
    *Pr. guy 2 puts sticky on the notice board*
    *both walk off*
    *manager walks in*
    *manager looks at the board*
    Clueless manager 1: Nice, the work is finally done.
    Cl. manager 1: Ahhh, I'm on a tight schedule. Lets send this file to the head programmer so he can compile everything.
    *Tries to click close*
    Cl. manager 1: What, changes have been made? Whatever, save.
    Cl. manager 1: Ok, open outlook. Send. Done. Wow, I know this will be a spectacular release.
    *Cl. manager walks of*
  • by kabdib ( 81955 ) on Saturday December 15, 2007 @09:55AM (#21708328) Homepage
    I'm not aware of a single installer package on Windows that isn't a useless, complicated, badly-documented, bug-ridden piece of crap. The times when I've had to use (say) InstallShield, I've seriously thought about finding a new job. This stuff sucks *and* blows. (Don't get me started on USB support and BlueTooth. Oh my God. Don't even think about reading about that stuff: Once you crack open the docs and see the wavy tentacles, the squamous mouths, the eyes, the eyes, the eyes that . . . well, you'll never be quite the same again. T-tr-trust me on th-that).

    Remember the happy days of "just copy" installs, which worked great on MacOs in the 90s? Upgrade to a new system? Just copy your "apps" folder over.

    The question, "What kind of installer should our OS have?" is like asking, "Should we drink the red poison or the green one?" Just asking the question seals your doom.

    • The vast majority of applications can be installed by dragging them into the Applications folder. Or they can be run from an archive. The magic required to do this on the OS level is pretty minimal.
      • by kabdib ( 81955 )
        That's incredibly good to hear (I haven't touched a Mac since I left Apple in the mid 90s).

        The thing about an "installer" is that you're already in trouble. You have to learn another language (looking at the knowledge base for InstallShield was a real eye-opener, things like "no longer crash when a case-statement expression is not constant" in like version 5 of the product), with no debugger and essentially no specified semantics, with buggy, inconsistent runtime support routines (such as the 'delete' land
      • by grumbel ( 592662 )
        I would like to see some numbers on that. The majority of larger applications I know comes as Installer, Applications folder are mostly just for smaller stuff.
    • We use it at my place of work and I find it a lot easier to understand than InnoSetup. Plus it is free to download. One major limitation is that it does not support Windows Installer, instead you get a "classic" setup.exe.
      Link: http://www.jrsoftware.org/isinfo.php [jrsoftware.org]
  • Having mixed, inconsistent addressing modes is a major design screw-up. And having a default of the "delete" command to delete somewere else than is intuitive, is completely unacceptable and the people responsible for it should be fired and striped of their qualification. These people are not engineers, but incompetent hacks.

    The right way to do it is that you can have inconsitencies, if a) there is a very good reason for it (here, there was none) and b) you make sure people notice. This can be done by makin
  • The first part of the problem is the bloody registry, the second part of the problem is the moron who decided to mix critical system configuration information with user space information, the third part of the problem is the lack of a programming philosophy of keep your own shit in your own space.

    I think the following design principles would go a long way to solving this problem:

    • Complete and total segregation of the system configuration from user space, programs may have READ ONLY access.
    • creation of a s
    • I think this is a leftover from the days of Windows 3.x and 9x, which were NOT properly designed as professional, multitasking operating systems.

      Among other things, everybody was administrator. Which led to somewhat unhealthy design habits on the part of application developers, who often took the easy path of just dropping DLLs and such into the system directory. Including some of Microsoft's own developers, but I digress... ;-)

      Today, it seems that Microsoft has recognized the problem and tries to contain i
  • I was not affected by this issue, but I'm impressed by the explanation that really answered the question of "how the fuck could this happen" well..

    as a software developer, I can't say I wouldn't make the same mistake in the same circumstances..
  • The blog post has intimate details

    Intimate Details about Eve put Online. I can't wait!

The truth of a proposition has nothing to do with its credibility. And vice versa.

Working...