Coming from a Windows background, I can understand the initial learning curve in getting used to the Linux filesystem. I still don't quite grasp it all myself.
With that said, who the hell goes looking for stuff in C:\Program Files? The exe's live there, but most Windows programs create shortcuts on the Desktop/Start Menu, so you're rarely going to go into the program's directory itself unless you need to modify a .INI file.
I suspect that the question is just poorly worded - I think he meant to ask "why are programs in linux so hard to find" (if you look at his other questions they are not mega technical but they are also not questions that a novice would be posting)
I suspect this too. Still, who goes to Program Files to find programs in Windows? I've seldom seen this. Most Windows users I know start programs either from desktop shortcuts or from the start menu, and wouldn't know their way around Program Files (note: I'm talking about Windows XP, 7, etc. No idea how the newer Windowses work).
I don't think he is looking to execute the programs. He is looking to inspect the program files. This could be anything from looking for assets, to manually editing config files or adding a cracked DLL to make photoshop run.
When I was a teenager I would lurk around there a lot to "hack" stuff.
Indeed. Also, assuming you're installing programs to their default locations, Program Files used to be[0] the single location where you could get an accurate overview of installed applications. Both the Start Menu and Add/Remove Programs lists are way too cluttered by various Windows additions and/or third-party bullshit.
[0] - I don't know how's the situation with Windows 10, but on Windows 8 I've noticed some stuff tends to install to %APPDATA% instad.
A lot of programs didn't/don't put a shortcut to the uninstall utility in the start menu was usually my excuse that and installing various downloaded addons/level packs/extensions. Copying/modifying config or save files that the application decided to keep with itself instead of putting in a user specific location.
Part of the curse of backwards compatibility is that best practices have been invented and changed quite a bit over the last 20 years. I've been using linux full time for the last 3 years or so and before that it was old XP installs mostly but still I found myself in Program Files at least once a week?
Interesting. I think the posts contains a lot of useful information, however I believe this kind of response is detrimental toward user acquisition.
It's very much akin to the tech guy walking into a sale's person's office, to fix their immediate need. The tech guy is thinking all he has to do is teach the person to think for themselves, problem solved. All the sales guy is thinking is is "oh god, please don't teach me anything".
Personally I find locate and slocate very useful in linux to find the files I am after. Going over these might be more useful. That or whatever third party tools are available, with a UI and good UX, to achieve a similar goal.
The response is also abrasive bordering on condescending. The tone is very much along the lines of "what are you, stupid?" Even though they answer the question in quite some detail, that's really not the kind of thing that makes others be willing to open up about what they don't know and get better.
The Filesystem Hierarchy Standard is a very different approach to storing applications on the filesystem than to how MS-DOS/Windows does it. There's a learning curve for Windows users and they do get confused. They conceive of all files for an application residing in a single directory dedicated to that application, whereas the FHS thinks of distributing files for an application according to purpose.
I agree - I find locate to be very useful, and failing that grep/find.
A modest amount of time spent learning how to use the main features of find, with options like -o, prune, -exec, {}, along with xargs, grep, can repay itself many times over in a short period.
Of course, it presumes the user has the necessary technical bent.
Is just that you are not using your OS correctly. Learn a few commands of bash and you'll never look back.
... Or just create a link in your desktop pointing to the desired file or dir. Is ironic to say that files are hard to find in the first SO that allowed you to have as many soft and hard links to a file in your desktop as you want.
... Or browse the files in your file manager. In many cases you can even have thumbnails to help you finding the photos or videos that you want.
... Or just open firefox, write "file:///home/my-user-name" and browse your files. when "my-user-name" is the real name of your user
The only criticism I could have of Linux filesystems is that user mounted devices show up in /run?/media/<user>/<device> rather than ~/media/<device>. Otherwise everything a user does or makes is showing up under ~ somewhere, and the superuser's stuff resides in a mix of /etc, /root, and /usr.
Well, I'll take that back, the fact the config folder is hidden by default is also kind of sucky, and the habit of some software putting configuration data in ~/.local/share and some applications putting non-config data in ~/.config is extremely annoying but should be solved on a per-application basis.
Just a few offenders on my desktop in config:
* Chrome/ium stores extensions in .config rather than share. Those take up 600MB each in my config folder on my system.
* Qupzilla has a profile network cache of 32MB in config.
* Brackets has 14MB of cache data in config.
* Clementine puts its indexing databases in config.
* Spideroak puts everything in config - its index database and snapshots.
I'm not as familiar with offenders putting configurations into share, but I know at least KDE's kscreen puts monitor layouts in share/kscreen when they belong in config/kscreen.
I'd like to see Ubuntu, Arch, or Fedora (the big distros with the market share to push for best practices) enforce disk quotas on config directories - ie, a program cannot use more than 5MB of space there, akin to localstorage's limit and the intent to use it as a config store rather than persistent data store which is what indexdb / share are.
Also, .config should just be config. No dot. Users need to configure their stuff, they should be able to see it.
I have never had to edit anything in .config in decades of using Linux. Dotfiles are hidden for a reason, you shouldn't have to edit them by hand very often, and most heavy applications (e.g. Chrome) have their own configuration interface that will edit them for you. I think the . is a fine convention for easily separating configuration space from work/project data space.
That's not the reason why "dotfiles" are hidden, that's the reason that files whose names begin with dots are hidden. "Dotfile" refers specifically to user-local configuration files, which almost always have filenames that begin with a dot, or are located within a directory whose name begins with a dot.
Dotfiles are hidden because some people decided that configuration files ought to be hidden from the user during normal activities and so they took advantage of the originally-a-bug-feature of hidden files. This became the standard practice because at the time there was no agreed-upon location for user-local configuration (as existed for system-level config in the form of /etc), so the most logical thing to do was to just put config files inside $HOME. This clutters up the home directory, and so hiding these configuration files made sense.
Hidden from whom? Regular users? Very few regular people are using Linux or any variant of Unix other than OS X on a desktop. Those of us who install Linux are the kinds of people who are most likely to mess with deep system settings anyway.
Even my kids go into their .minecraft directory to install mods.
I dunno, I think it's hard to claim in full what types of people are using Unix/Linux since that's not exactly quantitative data. I mean, anecdotally, for every one person I know who does know their way around the various nix systems and understands enough to safely mess with the deep system settings, I know several folk who have a linux install because they do coding and someone told them that Linux is the best OS to code in, and it's almost always Ubuntu. (Not a knock against Ubuntu, but with the people I have in mind, Ubuntu is picked because of brand familiarity, not because of conscious choice).
Of course that's entirely anecdotal but the point is that there are a lot of reasons people are drawn to Linux, and it's not just because of the ability and knowledge to do more. I'm happy your kids are modding minecraft, just like I thought it was cool when my cousin did the same. But, in my cousin's case at least, it wasn't because he's the type to really mess with things, but because he wanted mods and was told how to do it. I still think it's good of him, but it doesn't really mean he has any more interest in really understanding computers than he did before the mods.
In defense of your kids, Minecraft hides the mod folder on every OS behind a hidden directory. Its actually easier to get to (albeit violating file system standards) to have it in ~/.minecraft vs on Windows you needing to figure out where your AppData folder even is (it varies on release) and then unhide it or browse directly to it.
Which is the point - you are now starting to try to make kids understand what symbolic links are or even how to input those in Windows Explorer. Just saying "open file manager, hit f8, go to .minecraft" is actually a usability improvement for kids.
Every minecraft guide explicitly says to open file manager and navigate to "%appdata%" often with pictures of where to even input "%appdata%".
I knew what symlinks were but never knew Windows had them. I only learned about %appdata% from a youtube video made by a 11-13 year old kid about how to install a mod for Minecraft. They don't need to know what a symlink is or where their .appdata folder is to know how to navigate to "%appdata%".
The young ones are a bit more tech savvy than adults are giving them credit for. Are they pandered a bit without having to know as much about the internals and how things work? Sure. But they're able to navigate and follow instructions because they've literally been doing it their entire lives.
Many laptops don't have a dedicated function row ("F\d" not FN) keys. So "F8" might serve to confuse some people who have had the privilege of only ever owning a laptop (I know a few of these teens myself!)
It's not just laptops. Many new keyboards ship with a laptop-like function-lock key that re-enables the functions you're actually seeking when you hit what you think are the Fn keys.
I am a full time Linux user for over ten years. I prefer it because I know where to look when things go wrong, but I am past the stage of too much tweaking. I can probably fix stuff if there is good reason to, but most of the time I can't be bothered these days. Quite happy with a system that works more or less out of the box (don't say that I should get a Mac or Windows as those have at least as many problems as Linux).
>I'd like to see Ubuntu, Arch, or Fedora (the big distros with the market share to push for best practices) enforce disk quotas on config directories - ie, a program cannot use more than 5MB of space there
Potentially useful idea, in general.
There used to be a quota feature on some Unix versions (SVR3 etc, IIRC), with commands to both set and get quotas, though I never really used it.
Update: Just googled for "Linux disk quota", and some links show that there seems to be some support. But it is per file system, not per directory. though per-user limits seem to be supported too.
But even if a per-directory limit could be enforced, how would you get around the fact that the program could create files in other dirs than the controlled ones, under your overall home dir (as long as they had write permission)? I supposed some kind of script-based monitoring could be improvised, but it might be a kludge ... and even if you could detect it in near real time, it wouldn't be a good idea to kill the process responsible.
Interested to know if there are any other methods or approaches.
Restricting write permissions could be the basis for one approach.
MAC addresses your later concerns. The fact Arch does not support MAC at all then becomes somewhat of a problem, but it is already a huge problem to begin with.
You can simply make SELinux / Apparmor profiles that default-restrict applications to ~/.config/<appname> and ~/.local/share/<appname> with quotas. Applications that need exceptions would be shipped with apparmor or selinux profile files to amend that.
Its also how you can make desktop Linux a lot more sophisticated in permissions management for applications. I know Apparmor at least supports the idea of network, peripheral, and display access in the same way it controls directory access. It would be a huge usability and security boon to the Linux desktop to have notifications of requests to access resources when an application does so - I think Android 6 is absolutely going in the right direction on application control, and adopting those ideas would be valuable.
What's MAC,, in the context I wrote about? Googled a bit, being a common acronym as well as abbreviation for Macintosh makes it difficult to find the right links.
The "problem" is much more prevalent than people think. Switchers come from Windows to Mac and expect it to function exactly like Windows. When it turns out Mac has its own ways of doing things, they're disappointed. It doesn't matter that quite often the "Mac" way of doing things is actually better or at least more consistent, they just expect it to be exactly like Windows. Well, guess what, folks, you can "drill with a saw and saw with a drill", but you shouldn't expect a good user experience unless you use the tools the way they are meant to be used.
Read the first chapter based on linux in 'Counter Hack reloaded' by Ed Skoudis. yes the book is focused on security however after reading it I found the file system in linux makes far more logical sense to me than windows.
I would pose a more general question, why is it so hard to find a file in Linux? Across all distributions I've found in difficult to predict where a particular binary or configuration file will be, and this is one of the reasons I prefer BSD (NetBSD in my case) -- the file system feels much more organized and the locations are predictable.
Dunno, I personally think Linux has a much more organized and common-sense file structure than Windows. The home folder keeps most user data in a nice, organized place, and generally programs installed from the repos are in a consistent place. Sometimes 'installers' put programs in strange places, but that's the price of freedom I guess...
That programs and libraries get installed in a consistent place is nice in some ways I guess, but for me it's always been terrible, since it's more often than not really hard to install multiple versions of the same program or library (and therefore two programs using different versions of the same library. The hairier programs can't even be built from sources on "the wrong OS version" by most mortals, not to mention installing binaries; try building KDevelop 3 on an OS where only KDevelop 4 is made available by default.)
Another maddening thing is how Linux distributions can't agree on where any bloody thing is - even env, which in large part serves a workaround for the inability to count on absolute paths, is at /usr/bin/env on some distros and /bin/env on other distros. So is something as basic as tcsh. How to write a portable tcsh script in these conditions I don't know. (And "you should use bash" misses the point, and also brings fond memories of #!/bin/sh script breakage when it turned out that sh is bash on some systems but dash on others.)
Bill Gates said in the 80s that there are many different Unixes and this will remain a problem for a long while. Damn, did that man make a good prediction! As to Linux - Richard Stallman said that it's a kernel, not an operating system. Damn, did the various distributions go out of their way to prove him right, creating many different, not Unixes, but Linuxes!
The major difference between Program Files and, say, /usr, is that the former is split up according to "which program it belongs to" and the latter according to "what kind of file it is". Each scheme has its merits, and both are quite fuzzy ("is this helper a part of my program, or standalone?" "should this asset go in 'share' or 'lib'?").
Interestingly, the /nix/store directory on NixOS is split according to package, so acts rather like Program Files. However, I try to keep my browsing of /nix/store to a minimum, since it currently contains ~25000 top-level directories. Search (eg. wildcard paths) is still necessary, even with this level of categorisation!
Ubuntu actually does make it hard to find files. Is it in /usr/bin? /usr/local/bin? /bin? /sbin? /etc/bin? /opt? /god-knows-what-directory?
Honestly, on linux, there should be /usr/local/bin, which is never touched by system management, for source installations, /sbin for emergency recovery tools, and /usr/bin for EVERYTHING ELSE. This is pretty much the only thing that fdo got right.
I recently started playing with lisp in ubuntu and decided to go with slime for it. So i installed slime through ubuntu software manager, couldn't find it, couldn't start it (i'm totally new to emacs and slime). After that I read some manuals, made changes to .emacs config and eventually installed slime using emacs and its package manager. Now i'm wondering if i have 2 versions of slime where are they located, which one is being actually used etc.
That's my point. On linux, there really is no distinction between /bin and /usr/bin. /usr/local/bin is different, as it's the designated location for stuff you install from source. /sbin is also different, because that's where you want your recovery tools. Although usually you'll boot into a livecd for recovery these days, so it's kind of moot.
Again, this about the only thing that systemd, fdo, etc. and I agree on.
I wish I'd seen something like this when I first started using ubuntu. As with most things linux, it's very sensible if you know what to look for (which is the hard part).
I think the underlying problem here is the expectation that you, the user, should be able to find stuff by looking "in" particular places. This is perfectly reasonable if you're dealing with a fairly limited set of files or executables, but that era has been slipping away for the last 5 years or more.
It is no surprise that the question comes from 2011. I believe that was near when Unity came out and Ubuntu did away with mouse menus to find "Programs" in favor of just searching for what you have. A lot of folks did not like it at first but I think its no longer an issue.
>A lot of folks did not like it at first but I think its no longer an issue.
The sudden popularity of Mint and ElementaryOS at the time of Unity tells me its still an issue. Those who care just left. Personally, I couldn't use Unity on a daily basis for this and other reasons.
OK, but even now Windows folks have largely given up on pressing <windows>/<All Programs> and looking for what they want.
There's simply too much stuff on a typical computer these days for a user to pick out what they want from a dropdown, yes, even if nested.
It is the same problem that Yahoo once had back in the day when it tried to "Categorize" the internet. At some point such attempts at categorization break down and you gotta look at more sophisticated strategies for search.
Well, I think this is sort of where Spotlight on OS X came from. Spotlight was pushed pretty hard when it came out as the new way to interact with your files, and for the most part it has lived up to its claims, allowing you to search concepts or text within a file and get nigh instant results, and it has only gotten better with SSDs now being default in so many Macs.
Of the users I've worked with over the last 10 years, many older users still hang on to rigid folder hierarchies, but I have noticed some users who are used to Spotlight and the faster Windows searches doing away with these strict hierarchies in favor of just a really well indexed search.
i think this is a really good post, though, b/c it demonstrates something that happens when we use engineered things on all levels: "different" is (perhaps falsely) equated with "difficult."
i suppose it would be possible to make a package that uses FUSE or something to provide a /prog_files with a similar directory structure to what a windows user would expect, but... nah : )
I don't agree that it is so much easier to find a file on Windows, but yeah searching for files on Linux could be a lot more user (or new user) friendly.
Usually I install packages wherever they go by default but if installing by hand I put it in the home folder and run it from there. Most programs are under /usr though, but it's true you never know.
I had to give up on Linux as a daily driver due to my fairly complex (multimouse, multimonitor) desktop setup. I suspect that some of the X11 code hasn't been touched in 20 years. This is why OSX and Windows make sense. For the user in the OP, the $100 or so dollars may be money well spent if that works for him. After much hacking I figured it's not equipped to handle my setup but I use it as my development platform and server both servers via SSH.
62 comments
[ 2.7 ms ] story [ 129 ms ] threadWith that said, who the hell goes looking for stuff in C:\Program Files? The exe's live there, but most Windows programs create shortcuts on the Desktop/Start Menu, so you're rarely going to go into the program's directory itself unless you need to modify a .INI file.
When I was a teenager I would lurk around there a lot to "hack" stuff.
[0] - I don't know how's the situation with Windows 10, but on Windows 8 I've noticed some stuff tends to install to %APPDATA% instad.
Part of the curse of backwards compatibility is that best practices have been invented and changed quite a bit over the last 20 years. I've been using linux full time for the last 3 years or so and before that it was old XP installs mostly but still I found myself in Program Files at least once a week?
It's very much akin to the tech guy walking into a sale's person's office, to fix their immediate need. The tech guy is thinking all he has to do is teach the person to think for themselves, problem solved. All the sales guy is thinking is is "oh god, please don't teach me anything".
Personally I find locate and slocate very useful in linux to find the files I am after. Going over these might be more useful. That or whatever third party tools are available, with a UI and good UX, to achieve a similar goal.
For less serious searches: du -a | grep -in filename # usually works
The Filesystem Hierarchy Standard is a very different approach to storing applications on the filesystem than to how MS-DOS/Windows does it. There's a learning curve for Windows users and they do get confused. They conceive of all files for an application residing in a single directory dedicated to that application, whereas the FHS thinks of distributing files for an application according to purpose.
I agree - I find locate to be very useful, and failing that grep/find.
Of course, it presumes the user has the necessary technical bent.
... Or just create a link in your desktop pointing to the desired file or dir. Is ironic to say that files are hard to find in the first SO that allowed you to have as many soft and hard links to a file in your desktop as you want.
... Or browse the files in your file manager. In many cases you can even have thumbnails to help you finding the photos or videos that you want.
... Or just open firefox, write "file:///home/my-user-name" and browse your files. when "my-user-name" is the real name of your user
... Or use the main menu in your desktop
... Or use emacs dired and tumme
Well, I'll take that back, the fact the config folder is hidden by default is also kind of sucky, and the habit of some software putting configuration data in ~/.local/share and some applications putting non-config data in ~/.config is extremely annoying but should be solved on a per-application basis.
Just a few offenders on my desktop in config:
* Chrome/ium stores extensions in .config rather than share. Those take up 600MB each in my config folder on my system.
* Qupzilla has a profile network cache of 32MB in config.
* Brackets has 14MB of cache data in config.
* Clementine puts its indexing databases in config.
* Spideroak puts everything in config - its index database and snapshots.
I'm not as familiar with offenders putting configurations into share, but I know at least KDE's kscreen puts monitor layouts in share/kscreen when they belong in config/kscreen.
I'd like to see Ubuntu, Arch, or Fedora (the big distros with the market share to push for best practices) enforce disk quotas on config directories - ie, a program cannot use more than 5MB of space there, akin to localstorage's limit and the intent to use it as a config store rather than persistent data store which is what indexdb / share are.
Also, .config should just be config. No dot. Users need to configure their stuff, they should be able to see it.
Dotfiles are hidden because some people decided that configuration files ought to be hidden from the user during normal activities and so they took advantage of the originally-a-bug-feature of hidden files. This became the standard practice because at the time there was no agreed-upon location for user-local configuration (as existed for system-level config in the form of /etc), so the most logical thing to do was to just put config files inside $HOME. This clutters up the home directory, and so hiding these configuration files made sense.
Even my kids go into their .minecraft directory to install mods.
Of course that's entirely anecdotal but the point is that there are a lot of reasons people are drawn to Linux, and it's not just because of the ability and knowledge to do more. I'm happy your kids are modding minecraft, just like I thought it was cool when my cousin did the same. But, in my cousin's case at least, it wasn't because he's the type to really mess with things, but because he wanted mods and was told how to do it. I still think it's good of him, but it doesn't really mean he has any more interest in really understanding computers than he did before the mods.
I believe "%appdata%" is symlinked to the AppData folder on every version of Windows Minecraft runs on.
I knew what symlinks were but never knew Windows had them. I only learned about %appdata% from a youtube video made by a 11-13 year old kid about how to install a mod for Minecraft. They don't need to know what a symlink is or where their .appdata folder is to know how to navigate to "%appdata%".
The young ones are a bit more tech savvy than adults are giving them credit for. Are they pandered a bit without having to know as much about the internals and how things work? Sure. But they're able to navigate and follow instructions because they've literally been doing it their entire lives.
Many laptops don't have a dedicated function row ("F\d" not FN) keys. So "F8" might serve to confuse some people who have had the privilege of only ever owning a laptop (I know a few of these teens myself!)
My point was more about not knowing what those are rather than the keyboards that lack them or have alternative inputs.
Potentially useful idea, in general.
There used to be a quota feature on some Unix versions (SVR3 etc, IIRC), with commands to both set and get quotas, though I never really used it.
Update: Just googled for "Linux disk quota", and some links show that there seems to be some support. But it is per file system, not per directory. though per-user limits seem to be supported too.
But even if a per-directory limit could be enforced, how would you get around the fact that the program could create files in other dirs than the controlled ones, under your overall home dir (as long as they had write permission)? I supposed some kind of script-based monitoring could be improvised, but it might be a kludge ... and even if you could detect it in near real time, it wouldn't be a good idea to kill the process responsible.
Interested to know if there are any other methods or approaches.
Restricting write permissions could be the basis for one approach.
You can simply make SELinux / Apparmor profiles that default-restrict applications to ~/.config/<appname> and ~/.local/share/<appname> with quotas. Applications that need exceptions would be shipped with apparmor or selinux profile files to amend that.
Its also how you can make desktop Linux a lot more sophisticated in permissions management for applications. I know Apparmor at least supports the idea of network, peripheral, and display access in the same way it controls directory access. It would be a huge usability and security boon to the Linux desktop to have notifications of requests to access resources when an application does so - I think Android 6 is absolutely going in the right direction on application control, and adopting those ideas would be valuable.
What's MAC,, in the context I wrote about? Googled a bit, being a common acronym as well as abbreviation for Macintosh makes it difficult to find the right links.
https://en.wikipedia.org/wiki/Mandatory_access_control
from a big picture perspective. http://www.ubuntugeek.com/linux-or-ubuntu-directory-structur... (taken from the article)
on a side note I added links from that page that are useful
my own .02 cents is: >updatedb
>locate xyz.xyz
Another maddening thing is how Linux distributions can't agree on where any bloody thing is - even env, which in large part serves a workaround for the inability to count on absolute paths, is at /usr/bin/env on some distros and /bin/env on other distros. So is something as basic as tcsh. How to write a portable tcsh script in these conditions I don't know. (And "you should use bash" misses the point, and also brings fond memories of #!/bin/sh script breakage when it turned out that sh is bash on some systems but dash on others.)
Bill Gates said in the 80s that there are many different Unixes and this will remain a problem for a long while. Damn, did that man make a good prediction! As to Linux - Richard Stallman said that it's a kernel, not an operating system. Damn, did the various distributions go out of their way to prove him right, creating many different, not Unixes, but Linuxes!
Interestingly, the /nix/store directory on NixOS is split according to package, so acts rather like Program Files. However, I try to keep my browsing of /nix/store to a minimum, since it currently contains ~25000 top-level directories. Search (eg. wildcard paths) is still necessary, even with this level of categorisation!
Honestly, on linux, there should be /usr/local/bin, which is never touched by system management, for source installations, /sbin for emergency recovery tools, and /usr/bin for EVERYTHING ELSE. This is pretty much the only thing that fdo got right.
for everything else, use mlocate
sudo updatedb
locate <name>
I don't see how that's hard at all.
or the even easier to remember 'whereis <name>'
updatedb is usually run daily by cron(8) to update the default database.
Also:
To create a private mlocate database as an user other than root, run
Note that all users that can read db_file can get the complete list of files in the subtree of source_directory.Again, this about the only thing that systemd, fdo, etc. and I agree on.
thats taking a very "desktop" view on things.
Many more systems run as headless installs in some rack somewhere.
It is no surprise that the question comes from 2011. I believe that was near when Unity came out and Ubuntu did away with mouse menus to find "Programs" in favor of just searching for what you have. A lot of folks did not like it at first but I think its no longer an issue.
The sudden popularity of Mint and ElementaryOS at the time of Unity tells me its still an issue. Those who care just left. Personally, I couldn't use Unity on a daily basis for this and other reasons.
There's simply too much stuff on a typical computer these days for a user to pick out what they want from a dropdown, yes, even if nested.
It is the same problem that Yahoo once had back in the day when it tried to "Categorize" the internet. At some point such attempts at categorization break down and you gotta look at more sophisticated strategies for search.
Of the users I've worked with over the last 10 years, many older users still hang on to rigid folder hierarchies, but I have noticed some users who are used to Spotlight and the faster Windows searches doing away with these strict hierarchies in favor of just a really well indexed search.
i think this is a really good post, though, b/c it demonstrates something that happens when we use engineered things on all levels: "different" is (perhaps falsely) equated with "difficult."
i suppose it would be possible to make a package that uses FUSE or something to provide a /prog_files with a similar directory structure to what a windows user would expect, but... nah : )
I had to give up on Linux as a daily driver due to my fairly complex (multimouse, multimonitor) desktop setup. I suspect that some of the X11 code hasn't been touched in 20 years. This is why OSX and Windows make sense. For the user in the OP, the $100 or so dollars may be money well spent if that works for him. After much hacking I figured it's not equipped to handle my setup but I use it as my development platform and server both servers via SSH.