[quietbritishjim]

Raymond Chen clears things up again:

> Some people suggest that one thing Microsoft Research could do with that time machine they’re working on is to go back in time and change the name of the Program Files directory to simply Programs. No, it really should be Program Files. Program Files are not the same as Programs. Programs are things like Calc, Notepad, Excel, Photoshop. They are things you run. Program Files are things like ACRORD32.DLL and TWCUTCHR.DLL. They are files that make programs run. If the directory were named Programs, then people who wanted to run a program would start digging into that directory and seeing a page full of weird DLL names and wonder “What the heck kind of programs are these?” And eventually they might figure out that if they want to run PowerPoint, they need to double-click on the icon named POWERPNT. “Computers are so hard to use.” WLCM2DOS

> If you want to find your programs, go to the Start menu. The Program Files directory is like the pantry of a restaurant. You aren’t expected to go in there and nibble on things that look interesting. You’re expected to order things from the menu.

https://devblogs.microsoft.com/oldnewthing/20131119-00/?p=26...

See also:

https://learn.microsoft.com/en-us/previous-versions/technet-...

[vlovich123]

I'd buy this except we have existence proof of how Apple solved this by instead making .app folders act special in the UI and having an /Applications folder you drag applications into.

A much more elegant solution and I think the criticism stands correct; Microsoft Research just didn't realize how to solve the problem and everything else is justification after-the-fact.

[Ntrails]

I'm not a mac guy - but I was playing some sts and for some reason my _data_ was embedded inside an Application which is kind of a package of files and I have to "unzip it" from a context menu to see the save games (but everything still functions the same).

That is, imo, awful. I'm not sold they've got everything right

[vlovich123]

That is very weird and suggests the App developer made a weird choice and ignore the HIG. Not a problem with the approach IMHO.

[mixmastamyk]

I remember when you’d look in that folder in old versions of Windows, explorer would actually tell you, “Hey, don’t look in here!”

This was because they hadn’t yet implemented security. (Was probably Win98 or so.)

[xeyownt]

Except that "Program Files" contains also folders, so it should be "Program Files And Folders", with all the nasty caps and spaces. What's the point of pushing the details to such level if you destroy usability?

In the meantime unix and alike use /bin, /lib, ... and everybody is happy.

[Etherlord87]

But Unix isn't a good system for a person that isn't a computer geek

[giobox]

Macs seem to sell just fine to people that aren't "computer geeks".

> https://www.opengroup.org/openbrand/certificates/1223p.pdf

[JTbane]

this makes Unix-style directories seem downright logical:

- programs go in /bin

- configurations go in /etc

- libraries go in /lib

- your personal user files go in /home/username

[GuB-42]

And then, there is /usr

It was supposed to be the user directory, but because someone didn't have enough space on /, it was somehow decided to put some stuff in there, so you have /usr/bin, /usr/lib, etc... But the user directories moved to /home, making /usr hold everything but user directories. Decades later, we still don't know what goes in /usr and what goes in /. In theory, what you need to boot the system should go to /, the rest goes to /usr, but in practice, there is no real rule, just don't break the scripts. Nowadays, distros tend to link one to the other in hope of making some sense without breaking too much stuff.

All that because someone was lacking disk space at some point in history.

[raffraffraff]

But do you put extra programs in /usr/bin, /usr/local/bin, /opt/, ~/bin. ~/.local/bin or somewhere else entirely. Or if you're using homebrew, who the hell even knows how to make those the first choice in your PATH.

[woleium]

i thought /usr was a mounted shared volume for files that were static for everyone in the lab/office and the local machine machines files went in /

[opem]

It should have been /shr for shared resources rather than unix shared resources (usr) to prevent people from confusing it with something related to user

[dns_snek]

god I wish it was that simple. Anything using the native package manager mostly follows this convention (with a variants like /usr/bin, /usr/local/bin, /opt). As soon as you need to install something that's not available from the system package manager all bets are off and you need to get ready for your home directory to never look the same again.

[watwut]

So, each thing is split through five completely different categories. And my /home/username still have to contain tons of configuration files.

[mock-possum]

These labels are unintuitive.

‘Bin’ is a generic empty container, and specific slang for a trash can. It might stand for ‘binary’ but what’s the difference between ‘binary’ 1s and 0s and ‘binaries’ aka compiled executables?

‘Etc’ is a dismissive way to refer to there being more things, too numerous to list: X, Y, Z, etc. in no way does it relate to configuration or options or settings or preferences.

‘Lib’ is fine I guess, but also what are libraries. If I ask my mom “what libraries do you have on your computer?” She’s going to be 1) confused and 2) assume I mean ebooks. I’m a programmer so I have a concept of what a library is - but how does that relate to my OS? Is it packages? Is it utilities? Is it frameworks?

accessible, intuitive, usable UX is a Very Hard Problem, there’s a reason it isn’t trivially solved with directory names like ‘bin,’ rather with elements of layout, colour, iconography, typography, you know, a GUI.

Users don’t want to solve a logic puzzle in order to interact with their computer.

[resize2996]

except...

[dingaling]

The types of people digging in PROGRA~1 were pretty likely to understand the difference between executables and DLLs.