8 ms·

Humor: Interview with an Ex-Microsoftie Who Used to Name OS Folders

183 points by taude 13y ago

niuzeta 13y ago
Is this a joke, or a real deal? It seems too true to not to be a genuine joke.
- deleted 13y ago
  [deleted]
talles 13y ago
Haha, amazing. I literally laughed out loud at: Why is there a 'WOW' in the middle of the name? —I was typing System64 and half way through I just thought: "WOW, nature is beautiful!"
bhauer 13y ago
Amusing, but the standard Unix file system is nothing to be too proud of. I'd very much like to see a file system layout re-imagined for the 2010s.
- voidiac 13y ago
  At least there are no spaces in the directory names.
  - harrytuttle 13y ago
    Yes and UNIX is really better! $ mkdir ".. " $ ls -a . .. .. Fun eh?
    - Xylakant 13y ago
      Now go and fire of "rm -rf ..". Now we're talking fun.
      - harrytuttle 13y ago
        Exactly my point!
    - pavanky 13y ago
      You can't plan for user stupidity. The system paths do not have spaces in them.
      - harrytuttle 13y ago
        No but allowing leading and trailing spaces is not user stupidity. That is design stupidity. You know like recording numbers as string in the format: "0000000000000000000000000123.23210000000000000"
        icebraining 13y ago
        The shell by default ignores spaces, you have to specifically force it to acknowledge them by enclosing the name in quotation marks or escaping with a backslash. In that situation, a command line tool should do what it's told, not disobey a direct command. Leave the rubber padded tools for the GUI land.
        harrytuttle 13y ago
        Rubber padded I do not expect. Retarded I also do not expect. Explain the validity of: mkdir " " mkdir " " mkdir " " ? It at least violates the principle of least surprise
        icebraining 13y ago
        Validity? It's a string like any other. It's not mkdir's job to second-guess what I tell it to do. And I don't see how it violated such principle. You tell it to create a file with spaces - you even emphasized them with quotes -, and you're surprise it did so?
        harrytuttle 13y ago
        It is merely an illustration. The reality is stuff like that occasionally does happen when you use variables and parse results from other commands.
    - tjdetwiler 13y ago
      I once accidentally did: $ touch ./~ # Much later I noticed the "~" file in the directory # so I mindlessly decided to cleanup: $ rm -rf ~ Luckily $HOME was on a _really_ slow NFS mount so I didn't manage to remove anything too important before I killed it.
      - harrytuttle 13y ago
        Ha that's a classic. A friend of mine did a "rm -rf ~ /tmp" rather than "rm -rf ~/tmp" on a fast SCSI local disk on his Sun workstation. His backup strategy of tarring up everything into ~/backup went with that one too. I lectured his ass on that one. However... The same guy, no less than 8 years later carried around a DVD-RAM with his single copy of his life's work on it (I assume this was only 8 years of his life) and jammed it in one of those dodgy Pioneer slot loader drives and proceeded to mount it. bzzzt ... wheee ... clunk ... BANG! DVD span to full speed and promptly shattered taking the drive fascia off and spraying everyone with bits of "I told you so". He now puts up scaffolding which worries me even more...
        tjdetwiler 13y ago
        Luckily I was on an IT maintained machine that takes nightly snapshots of home partitions so I was safe in the worst case. Had I done that on one of my personal machines I wouldn't have been so lucky.
- taude 13y ago
  I found not just the naming aspect funny, but the whole munging of 32/64 bit files good, too. That's beyond naming atrocities.
  - bhauer 13y ago
    Agreed. To me, it's even more funny when you realize "WOW" actually means "Windows on Windows." Say what??
    - harrytuttle 13y ago
      Makes sense to me, then again I know NT inside out... It's NT's syscall translation layer, CPU mode switching backend and entry point front end. It was originally used to run 16-bit apps on 32-bit platforms but is now WOW64 so is to run 32-bit apps on 64-bit machines. Basically it's a very light weight virtualisation layer. And it works well. My circa 1996 RPN calculator I wrote in VC++ works perfectly on 2013 x64 machine.
      - bhauer 13y ago
        Don't get me wrong. I know it makes sense once you know what it is. And the result in terms of compatibility and stability is impressive. Still, when I first heard the phrase "Windows on Windows" I had a chuckle. It reminds me that I enjoyed the way x86 apps ran on my old Alpha NT machine. If I recall correctly, the process list included "fx32" beside each.
        quarterto 13y ago
        WOW doesn't stand for Windows On Windows. WOW64 stands for Windows On Windows 64 [bit].
        bhauer 13y ago
        Oh, that I didn't fully appreciate. That actually makes it more reasonable. (Not being sarcastic!) What are you trying to do? Make me feel bad for having a good laugh at the name when I first looked it up? :)
- pmelendez 13y ago
  I am agreed. Although the last time I heard about a major attempt for a modern file system was in Longhorn and all we know how that ended. I guess there are still some fears to try it again, considering that current file systems in mainstream OS' are "good enough".
  - harrytuttle 13y ago
    Indeed. I think people worked out that metadata indexing over the top is probably better.
- fiatpandas 13y ago
  Check out GoboLinux's file system structure: http://www.gobolinux.org/index.php?page=at_a_glance http://www.gobolinux.org/index.php?page=at_a_glance
  - bhauer 13y ago
    I like it! I suppose I am a tad disappointed that it's a distribution in its own right. But they deserve credit for taking a decent first step.
  - Pxtl 13y ago
    Ick, capitalization in a case-sensititive file-system? Of course, as far as I'm concerned case-sensitivity is generally a misfeature in anything user-facing.
    - fiatpandas 13y ago
      If I remember correctly, their scripts automatically convert lower case letters to uppercase when you are trying to autocomplete typing with TAB. It only does it for the gobolinux-specific uppercase directories
    - bhauer 13y ago
      Agreed! I feel retaining case-sensitivity in file systems in 2013 is basically trolling users. I can think of no practical upside; only the opportunity for annoying jokes and tricks.
      - tekacs 13y ago
        But what of users (as they often do) descriptively naming files? I've seen plenty of "Accounts for Proctors' Attention.xlsx" style files. Case insensitivity would lose the case there. :/
        mistercow 13y ago
        There's a difference between case sensitivity and case preservation. FAT32 and HFS+ are examples of case-insensitive, case-preserving file systems.
- mintplant 13y ago
  Binaries? Libraries? Let's stick 'em in `/usr`! Oh, but where do user files go? I know, `/home`! What about all this other stuff? Eh, `/etc` will do. Unless it won't, in which case `/var` is the obvious solution. Or maybe even `/opt`, if we're feeling especially hip today.
  - Bjoern 13y ago
    Historical heritage unfortuantely. /sbin and /usr/sbin are other examples... http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074... https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=3519952
  - antocv 13y ago
    usr doesnt mean user, it meant Unix System Resources, and a user of the system usually puts his stuff at home, what would you like it to be otherwise /users ? That would be describing the users of the system and not where their stuff is, and users are described in /etc/passwd together with their passwords, sort of. /etc isnt called /conf or configuration because it contains examples, scripts and other small stuff as well, which is etcetera. /var is for variable data like logs and pid files, not meant to be changed by the user directly /opt sucks and is for losers who dont know about /usr/local or how to install stuff in ~ The Linux way makes much more sense than Windows or MacOSX way. binaries are in bin libraries are in lib, whats not to like?
    - BHSPitMonkey 13y ago
      > /var is for variable data like logs and pid files, not meant to be changed by the user directly One would certainly never dream of keeping entire web sites in there!
      - antocv 13y ago
        Well thats just wrong, thats what /srv/http is for, to serve http, but historically websites were served from your home, as then they where known as home (personal) sites, and they're still known as "home sites" in many non-english languages. Now when you have web applications they can be in /srv as well and the database is usually wrongly put in /var (looking at you mysql) but what you gonna do when you need a system user, just like a users stuff is supposed to be in home so put your database there /home/postgresql/its_datas here, as anyway you need to run the db as its own user. Makes sense no?
- amenod 13y ago
  Actually it stood the test of time quite well. System directory names are lowercase, short and mostly-standard. Granted, there is the /bin/, /sbin/, /usr/bin/, /usr/local/bin/... stuff, but at least /home/ directory is standard and applications really use it since forever, as opposed to Windows (apps saving user settings to registry, IE6 saving bookmarks to its "Program Files" dir - not sure how it is done now). One could argue that someone who knew Unix 30 years ago could still use command line in today's Linux without much problems.
jvehent 13y ago
- Where do I put my binaries ? in /usr/bin of course - But it's kinda personal stuff... so put it in /usr/local/bin - Oh right, but now I have more stuff that's not really important but still useful that's what we have /opt for - but... what if it's optional and only on my machine oh hell, just create /opt/local/bin and be done with it already!
- jjindev 13y ago
  wasn't /usr the original /home? as I understand it, it grew and became a system directory. with /bin as the original bin.
  - yebyen 13y ago
    On FreeBSD, /home is actually a symlink to /usr/home
- claudius 13y ago
  But even /opt/local/bin (a construct I’ve never seen…) is just one letter longer than ‘Program Files’ – so at least they got the "not too long" bit right.
  - mintplant 13y ago
    `Program Files` would actually be `C:\Program Files` (or the equivalent) if you're going for an absolute path. So `/opt/local/bin` comes out to two letters shorter.
    - claudius 13y ago
      Hence ‘even’, saying that even the full path is only one letter longer than the single directory name. :) Though, really, I have never seen /opt/local/bin – /usr/bin for package-manager owned stuff, /usr/local/bin for stuff not owned by the package manager and /opt/<Vendor> for weird things…
    - gnaritas 13y ago
maga 13y ago
I was buying it up until "WOW, nature is beautiful".
felixr 13y ago
I wonder why the interviewee is an Ex-Microsoftie. Did Microsoft realize that they had to replace him, or did he retire? Probably the latter...
- shaaaaawn 13y ago
  This ex-Microsoftie sounds a lot like Clippy..
magic_haze 13y ago
Amusing, but after looking up on the actual reasons why they came up with this scheme, I'm very impressed by the amount of work that goes into backwards compatibility: > Batch files ran programs from C:\Windows\System32 with the expectation that the resulting program would match the native OS. These expectations were not explicit, but they were implied by the nature of the activity. If the System32 directory were filled with 32-bit programs, then a batch file that ran the C:\Windows\System32\REG.EXE program to upset a system registry setting would be running the 32-bit version of REG.EXE, which means that it would be updating the 32-bit simulated version of the registry instead of the real 64-bit version. Other types of scripting files (such as REG files) have the same problem. http://technet.microsoft.com/en-us/magazine/ff955767.aspx http://technet.microsoft.com/en-us/magazine/ff955767.aspx How did Linux handle this problem?
- byroot 13y ago
  AFAIK it just don't have the problem. 32bits binaries executed on a 64bits system are not isolated in any way.
- _ZeD_ 13y ago
  the problem is not in the 32/64 reg.exe executable. It's that "32-bit simulated version of the registry". Why do I need something like that? (I expect some binary compatibility, but we're just opening a can of worms...) By comparison, most of the configuration files / registry equivalent info in linux are saved in plain text, and AFAIK all of them did not care about the 32/64 bit version of the executables.
- workbench 13y ago
  > 32-bit simulated version of the registry > How did Linux handle this problem? Not having something as terrible as the registry in the first place.
magic_haze 13y ago
Amusing, but after looking up on the actual reasons why they came up with this scheme, I'm very impressed by the amount of work that goes into backwards compatibility: > Batch files ran programs from C:\Windows\System32 with the expectation that the resulting program would match the native OS. These expectations were not explicit, but they were implied by the nature of the activity. If the System32 directory were filled with 32-bit programs, then a batch file that ran the C:\Windows\System32\REG.EXE program to upset a system registry setting would be running the 32-bit version of REG.EXE, which means that it would be updating the 32-bit simulated version of the registry instead of the real 64-bit version. Other types of scripting files (such as REG files) have the same problem. http://technet.microsoft.com/en-us/magazine/ff955767.aspx http://technet.microsoft.com/en-us/magazine/ff955767.aspx How did Linux handle this problem?
plorkyeran 13y ago
All of the names it makes fun of have perfectly sensible explanations. "Program Files" and "Documents and Settings" have spaces to force software to support spaces in paths. system32 for the Win32 version of system makes perfect sense. 64-bit Windows continues to use the Win32 API, and renaming system32 would have broken compatibility with dumb programs that hardcoded the name. SysWOW64 is the system32 directory for Windows 32-bit on Windows 64-bit. WOW64 is perhaps an overly cutesy name, but it's actually fairly descriptive.
- amenod 13y ago
  > All of the names it makes fun of have perfectly sensible explanations. Yes - OP just posted them. :) (for the record: your explanations, while they may be true, are not much better than the OP's)
- ciniglio 13y ago
  WoW isn't meant to be cutesy (which I think you hinted at, but to be explicit for others), it stands for Windows on Windows, which is the compatibility layer between different architectures (first 16 on 32, and now 32 on 64). http://en.wikipedia.org/wiki/Windows_on_Windows http://en.wikipedia.org/wiki/Windows_on_Windows
  - echohack 13y ago
    Ah acryonyms, the death of us all.
  - deleted 13y ago
    [deleted]
  - codeflo 13y ago
    The problem with WoW isn't the name, it's the concept itself. Some folders are shared between the two subsystems, some folders aren't. Some registry keys are shared, some aren't. If you thought the COM registration hell was fun, wait till you have a component that's misregistered twice, subtly different in each subsystem.
- gosub 13y ago
aegiso 13y ago
What you see here is the result of Microsoft's ridiculous infighting and internal politics, constructed by the stack-ranking culture of doom. You basically get ranked on how visible your stuff is to management, so you: 1) name your project as patriotically as possible. It's gotta include one of "Windows", "Microsoft", "XML", "COM", ".NET", "Modern" -- preferably all of them multiple times, especially if it has nothing to do with any of them. 2) make sure to stick the name in as many places as possible. A great place is the default filesystem structure, where everyone is bound to come across it. 3) earn bonus points if you can massage it into a de-facto standard (hello, XHR) With any luck, Microsoft Modern framework for Windows Azure .NET connectivity with Windows Azure 8.1 will show up on your reviewer's radar and you can enjoy your juicy bonus until the same time next year. Source: used to work there P.S. I'm not a Microsoft cynic -- just having a bit of fun :).
- theg2 13y ago
  Stack ranking wasn't around when any of this was done. This is early 90's stuff when stack ranking didn't even start until the late 90's.
  - icebraining 13y ago
    SysWOW64 is from the 90s?
    - workbench 13y ago
      64bit system files were pretty progressive back then, "WOW! 64bit system files we used to say"
    - plorkyeran 13y ago
      The Windows on Windows name was also used for the 16-bit compatibility layer, so the WOW part is from the early 90s.
- shrikant 13y ago
  Maybe we should formulate a Microsoft equivalent of Godwin's Law: "As an online discussion about Microsoft grows longer, the probability of an ex-Microsoftie bringing up stack ranking approaches 1." ("Ballmer's Law" has a nice ring to it..)
terrymah 13y ago
FWIW, "WOW" stands for "Windows on Windows"
- _ZeD_ 13y ago
  FWIW... it's "WOW64" (windows on windows 64)
agumonkey 13y ago
Note that it works hand in hand with `Excel can't save to paths over 218 characters (microsoft.com)` (https://news.ycombinator.com/item?id=6281462 https://news.ycombinator.com/item?id=6281462) bad name => earlier limit reach </synergy>
revelation 13y ago
That's not the best part yet. Remember links? Apparently they survived the big Longhorn and made their way into Vista! They really only exist as the "mklink" command line tool, support for creating them is nonexistent in Explorer, and iirc they have some other underlying architectural failures that makes them generally unpleasant to use on Windows. But hey, they exist, so someone had the glorious idea to translate these already terrible names into whatever is appropiate for your localized Windows, and create links for stuff like Documents and Settings. Confusion complete.
- dchest 13y ago
  Of course we remember! Here's how it happened: https://gist.github.com/dchest/800407/raw/48fd662716b7d446e76418d8b0d7cf47d96f8efc/gistfile1.txt https://gist.github.com/dchest/800407/raw/48fd662716b7d446e7...
- disposablename 13y ago
  http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext...
th0ma5 13y ago
I always thought it was funny that the hosts file is still in etc/ but under the windows system folder!
malkia 13y ago
My recent favorite is WinSxS - it's the folder that makes total sense on WinRT/Pro devices... not! Okay, it's sounds like a fine idea - having multiple DLL versions, allowing applications to link to them. But look, the idea of DLL was to save memory, where two or more applications accessing them would reuse the same hw memory (if they are not relocated). Now maybe on modern PC's that doesn't matter much (although it's still problematic if two MSVCRT libs are used from two different DLLs). Anyway, but on mobile devices - memory and storage space are important - so make sure all your apps use the same DLL, so you don't lose to storage space, and it's loaded only once (virtually for every process, but due to COW only once in memory). Have fun, go to Best Buy/Costco/anywhere where they sell the Windows RT/Pro tablets. Go to the command prompt (cmd.exe), c:\windows\winsxs, and type "dir /s" - you can see how much space is wasted there. And this would get even more and more with more updates coming.
- codeflo 13y ago
  To be fair, dir /s vastly overerstimates the storage use of WinSxS. That directory contains multiple hardlinks to every physical file, and dir /s doesn't handle those properly.
- disposablename 13y ago
  http://blogs.technet.com/b/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspx http://blogs.technet.com/b/askcore/archive/2008/09/17/what-i...
jloughry 13y ago
The way Microsoft Windows parses "Program Files" in the path seems incredible at first: https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464 https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vuln... http://xato.net/hardening/the-programexe-problem/ http://xato.net/hardening/the-programexe-problem/ "The problem is that it doesn't know. It just starts at the beginning and tries finding an executable until it finds a match. So in this case, it will try these files every time you run the command: C:\Program.exe C:\Program Files\Internet.exe C:\Program Files\Internet Explorer\iexplore.exe "You might see where I'm going with this: if you place an executable named program.exe in the root directory, it will probably end up running quite a bit. In fact, it will run anytime Windows launches a Program Files executable that does not have quotes around the path." [1] [1] http://www.securityfocus.com/columnists/301 http://www.securityfocus.com/columnists/301

183 points by taude 13y ago

niuzeta 13y ago

Is this a joke, or a real deal? It seems too true to not to be a genuine joke.

deleted 13y ago
[deleted]

talles 13y ago

Haha, amazing. I literally laughed out loud at: Why is there a 'WOW' in the middle of the name? —I was typing System64 and half way through I just thought: "WOW, nature is beautiful!"

bhauer 13y ago

Amusing, but the standard Unix file system is nothing to be too proud of. I'd very much like to see a file system layout re-imagined for the 2010s.

voidiac 13y ago
At least there are no spaces in the directory names.
- harrytuttle 13y ago
  Yes and UNIX is really better! $ mkdir ".. " $ ls -a . .. .. Fun eh?
  - Xylakant 13y ago
    Now go and fire of "rm -rf ..". Now we're talking fun.
    - harrytuttle 13y ago
      Exactly my point!
  - pavanky 13y ago
    You can't plan for user stupidity. The system paths do not have spaces in them.
    - harrytuttle 13y ago
      No but allowing leading and trailing spaces is not user stupidity. That is design stupidity. You know like recording numbers as string in the format: "0000000000000000000000000123.23210000000000000"
      - icebraining 13y ago
        The shell by default ignores spaces, you have to specifically force it to acknowledge them by enclosing the name in quotation marks or escaping with a backslash. In that situation, a command line tool should do what it's told, not disobey a direct command. Leave the rubber padded tools for the GUI land.
        harrytuttle 13y ago
        Rubber padded I do not expect. Retarded I also do not expect. Explain the validity of: mkdir " " mkdir " " mkdir " " ? It at least violates the principle of least surprise
        icebraining 13y ago
        Validity? It's a string like any other. It's not mkdir's job to second-guess what I tell it to do. And I don't see how it violated such principle. You tell it to create a file with spaces - you even emphasized them with quotes -, and you're surprise it did so?
        harrytuttle 13y ago
        It is merely an illustration. The reality is stuff like that occasionally does happen when you use variables and parse results from other commands.
  - tjdetwiler 13y ago
    I once accidentally did: $ touch ./~ # Much later I noticed the "~" file in the directory # so I mindlessly decided to cleanup: $ rm -rf ~ Luckily $HOME was on a _really_ slow NFS mount so I didn't manage to remove anything too important before I killed it.
    - harrytuttle 13y ago
      Ha that's a classic. A friend of mine did a "rm -rf ~ /tmp" rather than "rm -rf ~/tmp" on a fast SCSI local disk on his Sun workstation. His backup strategy of tarring up everything into ~/backup went with that one too. I lectured his ass on that one. However... The same guy, no less than 8 years later carried around a DVD-RAM with his single copy of his life's work on it (I assume this was only 8 years of his life) and jammed it in one of those dodgy Pioneer slot loader drives and proceeded to mount it. bzzzt ... wheee ... clunk ... BANG! DVD span to full speed and promptly shattered taking the drive fascia off and spraying everyone with bits of "I told you so". He now puts up scaffolding which worries me even more...
      - tjdetwiler 13y ago
        Luckily I was on an IT maintained machine that takes nightly snapshots of home partitions so I was safe in the worst case. Had I done that on one of my personal machines I wouldn't have been so lucky.
taude 13y ago
I found not just the naming aspect funny, but the whole munging of 32/64 bit files good, too. That's beyond naming atrocities.
- bhauer 13y ago
  Agreed. To me, it's even more funny when you realize "WOW" actually means "Windows on Windows." Say what??
  - harrytuttle 13y ago
    Makes sense to me, then again I know NT inside out... It's NT's syscall translation layer, CPU mode switching backend and entry point front end. It was originally used to run 16-bit apps on 32-bit platforms but is now WOW64 so is to run 32-bit apps on 64-bit machines. Basically it's a very light weight virtualisation layer. And it works well. My circa 1996 RPN calculator I wrote in VC++ works perfectly on 2013 x64 machine.
    - bhauer 13y ago
      Don't get me wrong. I know it makes sense once you know what it is. And the result in terms of compatibility and stability is impressive. Still, when I first heard the phrase "Windows on Windows" I had a chuckle. It reminds me that I enjoyed the way x86 apps ran on my old Alpha NT machine. If I recall correctly, the process list included "fx32" beside each.
      - quarterto 13y ago
        WOW doesn't stand for Windows On Windows. WOW64 stands for Windows On Windows 64 [bit].
        bhauer 13y ago
        Oh, that I didn't fully appreciate. That actually makes it more reasonable. (Not being sarcastic!) What are you trying to do? Make me feel bad for having a good laugh at the name when I first looked it up? :)
pmelendez 13y ago
I am agreed. Although the last time I heard about a major attempt for a modern file system was in Longhorn and all we know how that ended. I guess there are still some fears to try it again, considering that current file systems in mainstream OS' are "good enough".
- harrytuttle 13y ago
  Indeed. I think people worked out that metadata indexing over the top is probably better.
fiatpandas 13y ago
Check out GoboLinux's file system structure: http://www.gobolinux.org/index.php?page=at_a_glance http://www.gobolinux.org/index.php?page=at_a_glance
- bhauer 13y ago
  I like it! I suppose I am a tad disappointed that it's a distribution in its own right. But they deserve credit for taking a decent first step.
- Pxtl 13y ago
  Ick, capitalization in a case-sensititive file-system? Of course, as far as I'm concerned case-sensitivity is generally a misfeature in anything user-facing.
  - fiatpandas 13y ago
    If I remember correctly, their scripts automatically convert lower case letters to uppercase when you are trying to autocomplete typing with TAB. It only does it for the gobolinux-specific uppercase directories
  - bhauer 13y ago
    Agreed! I feel retaining case-sensitivity in file systems in 2013 is basically trolling users. I can think of no practical upside; only the opportunity for annoying jokes and tricks.
    - tekacs 13y ago
      But what of users (as they often do) descriptively naming files? I've seen plenty of "Accounts for Proctors' Attention.xlsx" style files. Case insensitivity would lose the case there. :/
      - mistercow 13y ago
        There's a difference between case sensitivity and case preservation. FAT32 and HFS+ are examples of case-insensitive, case-preserving file systems.
mintplant 13y ago
Binaries? Libraries? Let's stick 'em in `/usr`! Oh, but where do user files go? I know, `/home`! What about all this other stuff? Eh, `/etc` will do. Unless it won't, in which case `/var` is the obvious solution. Or maybe even `/opt`, if we're feeling especially hip today.
- Bjoern 13y ago
  Historical heritage unfortuantely. /sbin and /usr/sbin are other examples... http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074... https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=3519952
- antocv 13y ago
  usr doesnt mean user, it meant Unix System Resources, and a user of the system usually puts his stuff at home, what would you like it to be otherwise /users ? That would be describing the users of the system and not where their stuff is, and users are described in /etc/passwd together with their passwords, sort of. /etc isnt called /conf or configuration because it contains examples, scripts and other small stuff as well, which is etcetera. /var is for variable data like logs and pid files, not meant to be changed by the user directly /opt sucks and is for losers who dont know about /usr/local or how to install stuff in ~ The Linux way makes much more sense than Windows or MacOSX way. binaries are in bin libraries are in lib, whats not to like?
  - BHSPitMonkey 13y ago
    > /var is for variable data like logs and pid files, not meant to be changed by the user directly One would certainly never dream of keeping entire web sites in there!
    - antocv 13y ago
      Well thats just wrong, thats what /srv/http is for, to serve http, but historically websites were served from your home, as then they where known as home (personal) sites, and they're still known as "home sites" in many non-english languages. Now when you have web applications they can be in /srv as well and the database is usually wrongly put in /var (looking at you mysql) but what you gonna do when you need a system user, just like a users stuff is supposed to be in home so put your database there /home/postgresql/its_datas here, as anyway you need to run the db as its own user. Makes sense no?
amenod 13y ago
Actually it stood the test of time quite well. System directory names are lowercase, short and mostly-standard. Granted, there is the /bin/, /sbin/, /usr/bin/, /usr/local/bin/... stuff, but at least /home/ directory is standard and applications really use it since forever, as opposed to Windows (apps saving user settings to registry, IE6 saving bookmarks to its "Program Files" dir - not sure how it is done now). One could argue that someone who knew Unix 30 years ago could still use command line in today's Linux without much problems.

jvehent 13y ago

- Where do I put my binaries ? in /usr/bin of course - But it's kinda personal stuff... so put it in /usr/local/bin - Oh right, but now I have more stuff that's not really important but still useful that's what we have /opt for - but... what if it's optional and only on my machine oh hell, just create /opt/local/bin and be done with it already!

jjindev 13y ago
wasn't /usr the original /home? as I understand it, it grew and became a system directory. with /bin as the original bin.
- yebyen 13y ago
  On FreeBSD, /home is actually a symlink to /usr/home
claudius 13y ago
But even /opt/local/bin (a construct I’ve never seen…) is just one letter longer than ‘Program Files’ – so at least they got the "not too long" bit right.
- mintplant 13y ago
  `Program Files` would actually be `C:\Program Files` (or the equivalent) if you're going for an absolute path. So `/opt/local/bin` comes out to two letters shorter.
  - claudius 13y ago
    Hence ‘even’, saying that even the full path is only one letter longer than the single directory name. :) Though, really, I have never seen /opt/local/bin – /usr/bin for package-manager owned stuff, /usr/local/bin for stuff not owned by the package manager and /opt/<Vendor> for weird things…
  - gnaritas 13y ago

maga 13y ago

I was buying it up until "WOW, nature is beautiful".

felixr 13y ago

I wonder why the interviewee is an Ex-Microsoftie. Did Microsoft realize that they had to replace him, or did he retire? Probably the latter...

shaaaaawn 13y ago
This ex-Microsoftie sounds a lot like Clippy..

magic_haze 13y ago

Amusing, but after looking up on the actual reasons why they came up with this scheme, I'm very impressed by the amount of work that goes into backwards compatibility: > Batch files ran programs from C:\Windows\System32 with the expectation that the resulting program would match the native OS. These expectations were not explicit, but they were implied by the nature of the activity. If the System32 directory were filled with 32-bit programs, then a batch file that ran the C:\Windows\System32\REG.EXE program to upset a system registry setting would be running the 32-bit version of REG.EXE, which means that it would be updating the 32-bit simulated version of the registry instead of the real 64-bit version. Other types of scripting files (such as REG files) have the same problem. http://technet.microsoft.com/en-us/magazine/ff955767.aspx http://technet.microsoft.com/en-us/magazine/ff955767.aspx How did Linux handle this problem?

byroot 13y ago
AFAIK it just don't have the problem. 32bits binaries executed on a 64bits system are not isolated in any way.
_ZeD_ 13y ago
the problem is not in the 32/64 reg.exe executable. It's that "32-bit simulated version of the registry". Why do I need something like that? (I expect some binary compatibility, but we're just opening a can of worms...) By comparison, most of the configuration files / registry equivalent info in linux are saved in plain text, and AFAIK all of them did not care about the 32/64 bit version of the executables.
workbench 13y ago
> 32-bit simulated version of the registry > How did Linux handle this problem? Not having something as terrible as the registry in the first place.

magic_haze 13y ago

plorkyeran 13y ago

All of the names it makes fun of have perfectly sensible explanations. "Program Files" and "Documents and Settings" have spaces to force software to support spaces in paths. system32 for the Win32 version of system makes perfect sense. 64-bit Windows continues to use the Win32 API, and renaming system32 would have broken compatibility with dumb programs that hardcoded the name. SysWOW64 is the system32 directory for Windows 32-bit on Windows 64-bit. WOW64 is perhaps an overly cutesy name, but it's actually fairly descriptive.

amenod 13y ago
> All of the names it makes fun of have perfectly sensible explanations. Yes - OP just posted them. :) (for the record: your explanations, while they may be true, are not much better than the OP's)
ciniglio 13y ago
WoW isn't meant to be cutesy (which I think you hinted at, but to be explicit for others), it stands for Windows on Windows, which is the compatibility layer between different architectures (first 16 on 32, and now 32 on 64). http://en.wikipedia.org/wiki/Windows_on_Windows http://en.wikipedia.org/wiki/Windows_on_Windows
- echohack 13y ago
  Ah acryonyms, the death of us all.
- deleted 13y ago
  [deleted]
- codeflo 13y ago
  The problem with WoW isn't the name, it's the concept itself. Some folders are shared between the two subsystems, some folders aren't. Some registry keys are shared, some aren't. If you thought the COM registration hell was fun, wait till you have a component that's misregistered twice, subtly different in each subsystem.
gosub 13y ago

aegiso 13y ago

What you see here is the result of Microsoft's ridiculous infighting and internal politics, constructed by the stack-ranking culture of doom. You basically get ranked on how visible your stuff is to management, so you: 1) name your project as patriotically as possible. It's gotta include one of "Windows", "Microsoft", "XML", "COM", ".NET", "Modern" -- preferably all of them multiple times, especially if it has nothing to do with any of them. 2) make sure to stick the name in as many places as possible. A great place is the default filesystem structure, where everyone is bound to come across it. 3) earn bonus points if you can massage it into a de-facto standard (hello, XHR) With any luck, Microsoft Modern framework for Windows Azure .NET connectivity with Windows Azure 8.1 will show up on your reviewer's radar and you can enjoy your juicy bonus until the same time next year. Source: used to work there P.S. I'm not a Microsoft cynic -- just having a bit of fun :).

theg2 13y ago
Stack ranking wasn't around when any of this was done. This is early 90's stuff when stack ranking didn't even start until the late 90's.
- icebraining 13y ago
  SysWOW64 is from the 90s?
  - workbench 13y ago
    64bit system files were pretty progressive back then, "WOW! 64bit system files we used to say"
  - plorkyeran 13y ago
    The Windows on Windows name was also used for the 16-bit compatibility layer, so the WOW part is from the early 90s.
shrikant 13y ago
Maybe we should formulate a Microsoft equivalent of Godwin's Law: "As an online discussion about Microsoft grows longer, the probability of an ex-Microsoftie bringing up stack ranking approaches 1." ("Ballmer's Law" has a nice ring to it..)

terrymah 13y ago

FWIW, "WOW" stands for "Windows on Windows"

_ZeD_ 13y ago
FWIW... it's "WOW64" (windows on windows 64)

agumonkey 13y ago

Note that it works hand in hand with `Excel can't save to paths over 218 characters (microsoft.com)` (https://news.ycombinator.com/item?id=6281462 https://news.ycombinator.com/item?id=6281462) bad name => earlier limit reach </synergy>

revelation 13y ago

That's not the best part yet. Remember links? Apparently they survived the big Longhorn and made their way into Vista! They really only exist as the "mklink" command line tool, support for creating them is nonexistent in Explorer, and iirc they have some other underlying architectural failures that makes them generally unpleasant to use on Windows. But hey, they exist, so someone had the glorious idea to translate these already terrible names into whatever is appropiate for your localized Windows, and create links for stuff like Documents and Settings. Confusion complete.

dchest 13y ago
Of course we remember! Here's how it happened: https://gist.github.com/dchest/800407/raw/48fd662716b7d446e76418d8b0d7cf47d96f8efc/gistfile1.txt https://gist.github.com/dchest/800407/raw/48fd662716b7d446e7...
disposablename 13y ago
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext...

th0ma5 13y ago

I always thought it was funny that the hosts file is still in etc/ but under the windows system folder!

malkia 13y ago

My recent favorite is WinSxS - it's the folder that makes total sense on WinRT/Pro devices... not! Okay, it's sounds like a fine idea - having multiple DLL versions, allowing applications to link to them. But look, the idea of DLL was to save memory, where two or more applications accessing them would reuse the same hw memory (if they are not relocated). Now maybe on modern PC's that doesn't matter much (although it's still problematic if two MSVCRT libs are used from two different DLLs). Anyway, but on mobile devices - memory and storage space are important - so make sure all your apps use the same DLL, so you don't lose to storage space, and it's loaded only once (virtually for every process, but due to COW only once in memory). Have fun, go to Best Buy/Costco/anywhere where they sell the Windows RT/Pro tablets. Go to the command prompt (cmd.exe), c:\windows\winsxs, and type "dir /s" - you can see how much space is wasted there. And this would get even more and more with more updates coming.

codeflo 13y ago
To be fair, dir /s vastly overerstimates the storage use of WinSxS. That directory contains multiple hardlinks to every physical file, and dir /s doesn't handle those properly.
disposablename 13y ago
http://blogs.technet.com/b/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspx http://blogs.technet.com/b/askcore/archive/2008/09/17/what-i...

jloughry 13y ago

The way Microsoft Windows parses "Program Files" in the path seems incredible at first: https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464 https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vuln... http://xato.net/hardening/the-programexe-problem/ http://xato.net/hardening/the-programexe-problem/ "The problem is that it doesn't know. It just starts at the beginning and tries finding an executable until it finds a match. So in this case, it will try these files every time you run the command: C:\Program.exe C:\Program Files\Internet.exe C:\Program Files\Internet Explorer\iexplore.exe "You might see where I'm going with this: if you place an executable named program.exe in the root directory, it will probably end up running quite a bit. In fact, it will run anytime Windows launches a Program Files executable that does not have quotes around the path." [1] [1] http://www.securityfocus.com/columnists/301 http://www.securityfocus.com/columnists/301