OTOH, people are probably already somewhat used to this. If I go to http://slashdot.org/CoMMenTs.pL [slashdot.org], I get a 404.
yes, but not if I go to http://sLaShDoT.OrG. And really, how often do "people" (as in average users) type in something more complicated than www.cnn.com?
My point was that there's actually a reason for passwords being a point of difficulty, while there's no reason whatsoever for keeping the filesystem difficult. In fact, there's no reason to think that a user would connect passwords to files - an average user would almost never type the name of an existing file - only new files.
Correct me if I'm wrong here, but that would mean that passwords should be case-insensitive, too.
So every piece of the system is supposed to equal password-level? Okay, so every filename must also be at least 8 characters long, have caps, non-caps, digits and some other characters in it.
[user@host]$ ls
ReaD-Me67
coNF%#iGu26re
MaKe+558FiLE ...
And while we're at it, let's make sure that applies to all the menu items in MozIL%&$A347 and Gn_:66oMe#@*.
I don't store my passwords as filenames (that'd kinda defeat the purpouse of it, wouldnt it?), so there's no reason that passwords need to be case insensitive just because files do - in fact, passwords should be hard to guess; filenames should be easy to guess. Notice any difference?
I'm sure removing case sensitivty in this late hour would be a pain
Really? Can you honestly say you know of something that depends on the fact that there can be files somestuff, SomeStuff and SOMESTUFF in the same directory or on the same path?
In general, people know that if I make a README, a ReadMe and a readme file, not even the most techie person is going to remember witch one contains what, so you don't do it.
I consider this worth doing - in fact, I consider even deeper changes to the way *nix handles it's files (see my journal on that) worth doing.
The actual problem is not that it would be hard, but that all the idiot l33ts would flame a full volcano about it "ruining linux". And then there are always the people who think that it should be done in the UI instead of in the system itself - which of course never worked and never will work (especially not in the OSS world) because alot of programmers say "screw you" to the guides and "my way of doing it is much better".
The biggest difference would probably be that you'd get one less error once in a while from doing the wrong capsation (is that a word?) of a filename.
That can be dificult for a user who doesn't know what they are doing, and it violates the principal that C:\Windows\ is a system folder that you should never have to look at. So would you rather type/home/username/ (or just ~ for that matter) or C:\Windows\Profiles\UserName\My Documents\? The Linux method is both shorter and more logical.
Yes, but this is a location issue and a naming issue. It's bad, for sure, but doing it better doesn't present much of a challenge.
No, you only get a link in the start menu if you use an install program.
Point 1: Have you ever seen a windows program without an install prog? No, they all have one, and they all do roughly the same things and look roughtly the same, putting stuff in roughly the same places. Point 2: Trying to force all package distributors to make an installer (and make that an installer that doesnt confuse people), that installs into standard locations is just not going to work. There's more thoughts of this in my journal for those who are interested.
A user who can understand that C:\Windows\, C:\Program Files\ and many of the files in C:\ (which they probably have to go through to get to My Documents) are system, "advanced", stuff, should be able to understand that files beginning with . are settings files which they probably should not mess with. In any case, they probable can't see these files anyway.
Well, I'd say like this: The user understands that: everything is bad except the home directory. docs go in ~/documents/, pics in ~/pictures/, etc. He puts some other stuff in his home directory (kinda normal thing to do). Now all of a sudden he finds a bunch of weird stuff in his homedir after switching on "show hidden files". Going "hey, it's my home directory", he promptly removes all of them. (you wouldn't beleive what newbie cleverheads do to their computers in form of "cleaning up" and stuff...) I would much rather see if he could learn that configuration files go into ~/config or/config/myname, which would be nice and consistant with the rest of the directory layout.
So basically, Linux does't handle it correctly, but neither does windows.
... which is no reason not to try and improve Linux.
It's quite possible that neither Linux (because it's based on UNIX, which is not designed as a desktop), or Windows (because it based on DOS, which is just a extremely simplified, badly implemented, version of UNIX), can ever be a really great desktop.
The DOS heritage of windows shows up more or less only in it's directory structure nowadays - and MS is talking about tossing it around and putting the entire fs in a database anyway. I do not think that being a great desktop has so much to do with filesystem layout - but if we're talking a truly easy system that is good for slowly learning more about the system, then windows wins in this case. A user can start learning by clicking the "show files" to show his files in C:\Program Files\, even though there's a note you shouldn't mess around there. Another funny thing is that MacOS X is actually "based" around UNIX as well... and I see alot of people here claiming its superiority.
and a large part of the problem may be with users unused to the idea of having separate (for user accounts) root access.
People get used to security stuff - most people werent used to typing a password once, and now they can run Win2k boxes just fine logging in on startup. The key is just telling them not that it's a "root account" but that it's a password needed to install software and configure some things. When needed, they should be automaticly asked to provide the password.
Basically the App Directories are self-contained applications, with the executables, help, etc. all in one package
Thanks for the link - that's an idea I like and think could be useful.
The point is that we're talking desktops here... I made clear from the very beginning that there needs to be a separation to where the current FHS should be in effect, which is basicly systems that are administered by somebody who wouldn't run away screaming at the mention of "heavily automounted home directories";). And then again, having configs in/config/user/namehere and mounting that along with the home dir shouldn't be a terrible problem... and if it is, just set $CONFIG to $HOME/config and that's fine. Anyway it's rather a non-issue.
admittedly/etc is a bit strange, but bin for binary(executable) lib for libraries sbin for system binaries boot for boot up files makes a lot of sense
... and usr for "more stuff", right?;) And that "binaries" are not binaries but executables. And that shared isn't shared, usually, but lib is shared... and local is just as local as everything else in most distros, and/usr/stuff is just as optional as/opt. The system has it's points - but they are mainly for server usage when alot of stuff is on different partitions. Have you read the FHS? Could you tell me the difference between/bin,/usr/bin and/usr/local/bin? Most people couldn't, and don't care.
Let me clarify things a bit - I do not mind so much the name of etc, even though i find it stupid. What i mind is the structure of stupid names that is/opt,/usr,/usr/share,/usr/local, and all the differnt stuff that goes in an arbitrary place within it. And if we're going to change that, why not give names that actually mean something reflecting their contents in a readable way while we're at it...
I was under the impression that symlinks do not work if you chroot. That'd kinda break the chroot wouldnt it? You'd have to hard-link everything, which is only possible putting user_root on the same partition as all the other dirs. Unless I'm wrong and symlinks work through chroots.
Well, that was an answer to this question: I can make the model just fine, but then what would I do with it?
Of course a good deal of work would go into getting a design that was actually better and not realize halfway through that "oops, this wasn't so good".
I later figured out that any program that puts config files as $HOME/.something needs to be patched to use something like $USERCONF instead as well.
Personnaly I'm switching to gentoo, it seems to have a much better package manager.
Congratualtions. I switched more or less on a whim a few months back - now all my linux boxes run gentoo. The portage system is simply a godsend when it comes to simplicity and is just generally better than anything else I've seen.
Note that I don't think it's good enough for "home" (read "newbie") users though.
The problem of course, is that it'd never work. Let's try it:
Listen up everybody, from now on, EVERYBODY's working on KDE.
Think it'll work? I don't... there's the obvious flaw that people work on what they want to work on, since they're not hired by somebody who can tell them work work on project xyz. Thus, people would quarrel over which project to all work on, and never get there...
The only conclusion is that open source needs to work anyway (and I think it will), by finding some other way of coping with this. In my opinion, this way is standards and interoperability between projects.
Ah... my other gripe with it. Install all of KDE and look at the program menu. *Almost* everything is named KWhatever... which entirely breaks the sorting of things.
That's a big exagguration. Config files are placed in/etc or your home directory
Ideally yes. But i wasn't joking - i've seden those things. Most stuff goes into/etc or ~/.whatever. Postgresql or mysql (can't seem to remember which now) installed its config into/usr/share/*sql/etc|config|something on some old install i did. I currently have KDE configs in/usr/kde/3/etc (one file) and/usr/kde/3/share/config (the rest) on gentoo, which could also be/usr/local/kde/share/config on some distros,/usr/share/kde/config on some and/opt/kde/share/config on others... and there you have all that I listed. I wasn't making it up you know - I was talking out of experience because I'm godawfully tired of fucking around trying to figure out where the hell my latest distro pick to install something. Oh, and I currently have QMail configs in/var/qmail/rc and/var/qmail/control... *sigh*
Mentioning that was not so much a saying that windows is better but that linux is just as bad in the general case - which the parent post to my answer complained about; multiple partitions etc.
No no no no NO! First off, Windows is not more organised than Linux. Far from it. Apps frequently install themselves god knows where, usually in Program Files, but sometimes also in directories off the root, sometimes people install apps into "My Documents" (I have seen this!) often if you have multiple partitions there is more than one Program Files folder etc. It's a mess.
This is aproximately what I expected (and have seen before). I never said Windows was more organised - I said it hides the complex parts better and more obviously to the user - while not taking away direct access to the filesystem. I know people install on the desktop - but hey did I say windows was perfect or was it just your l33t ego I hit or something? I said windows has a better idea at the thing than FHS. Now what happens in linux if you buy a new harddrive? It magicly melts into/usr without the need of another partition? It doesn't on my system...
And what's this about apps being spread out everywhere?
The fact that apps spread on windows doesnt make them spread less on *nix.
Windows apps usually install stuff into their directory,
of course.
the windows or windows/system directories,
It was ages since I've seen anything installed into the windows dir. The system stuff goes into the system dir - that's all. I.e. call it "shared" instead of maybe/usr/lib/something/usr/shared/something or why not/var/something/something or/usr/local/something/shared,/opt/whatnot/shared... (i've seen all of these in action)
sometimes they add stuff to your Profile and they add shortcuts.
... which is gruesomely missed in linux. I would give so much for that little convenience of having a menu item in my KDE menu automaticly when I install some program.
I don't hear anybody complaining about that.
I hear people complaining about it quite often - how badly structured it is compared to *nix, for instance. The point is that while you can guess the 4 or often less places a windows install puts stuff, it's hardly ever possible to guess all of the places unix installs go - that without even providing that service of adding things to your menus.
the registry is never accessed by users, and ditto for the Linux file system.
To me it seems like a horrible mistake to classify users into "stupid" (i.e. running the StupidSimpleLinux distro like Joe User), and l33t superwizgeeks like you running whatever other distro - I don't think you've brought linux to them then, just as you arent a "linux user" just because the ATM you just got money from was running a linux-based system. Like said in other posts - the "friendlyness" and "easyness" should scale up to the advanced level - where everything is open. Claiming that spewing config files all over my home dir would be better than putting them in e.g. ~/config just because you can hide it is silly.
I can't think of any compelling reason to do this at all, considering that these are paths normally only used by software.
Now that's a gem. You never use the filesystem layout on your systems? Would YOU want to use the system never seeing the filesystem? Or is this exlusively for the stupid newbies? Come on... in your vision of a newbie system the paperclips aren't that far off - and just admit that you would never run such a system without an "advanced" switch that let you disable all your nice UI gadgets.
compile a system from scratch using compile switches to fix directory layouts.
fix a few makefiles of the more stupid programs (mainly broken configures or apps not using autoconf)
recode/bugfix any program that hardcodes a path
After that there'd probably be a period of just trying everything out and seeing what isn't working. This most likely would be things that you missed in step 4 above. I might take an old P133 i have just to try this concept out...
Hide the flaws instead of fixing them, that is? How about if every programmer figured out that, say, ~/config was a good place to put configs? That'd eliminate the issue instantly. ~/config would become one of these "difficult places" with no need to look in them. Even better, there could be a "config dir" for each user, $CONFIG, in/etc/joeuser, or why not/config/joeuser.
Now about the/usr/bin etc issue, what happens when Joe starts learning about the computer. He wants to know more, and switched the "advancedness" lever one flip upwards. Suddenly it exposes a system that is none at all like what he currently knows. I would like a newbie-friendly system that "scales" its friendlyness all the way up to the advanced mode.
Now here's the second problem with the FHS; where a program ends up depends on who installs it and when - if I install it it probably goes in/usr/local/bin or/usr/local/whatnot/bin, but if installed by the distribution it could go in any of/bin/usr/bin/opt/whatever/bin or/usr/something/bin.
The solution to all of this is in my opinion to 1. Create an alternative FHS for desktops only and make install programs compatable with this layout or 2. hide everything and have a wizard/popup box for every little feature a-la the Microsoftish way. I don't really like that second answer, and the first one is hard on a linux-lover to even consider. But hard things must sometimes be done, if you want that "easy" system - not just an "easy" startup page that proves to be bogus once you reach level 2 in linux the platform game [tm].
To cut it short -- one could make Linux (*BSD) look completely innocent. It would only take lots of time and quite a bit of creativity.
Of course it would be possible to do - but it would be just that: "a look". Like a mask to cover the true nature of the beast, instead of a true change in the system. It's really just a push in where the user experience turns bad and where the learning curve derivate goes sky-high.
Sorry for the depressive info, but if you wanna make anything even remotely "friendly" or "easy" to Joe User using linux, you need to make major changes to the filesystem layout.
Having C:\Windows and C:\Program Files is okay on a windows box; they're just points of no-entry, aka advanced stuff you never need to look at. Instead you have "My Documents" to put documents into, and "My Pictures" for pictures. As you get more advanced you could even install a new program. It goes, logically into Program Files, and you get a link automaticly in the start menu.
Now lets look at the linux version. There's/home/joeuser, which has nothing. You could add, say, documents, pictures to it. So now we have those two nice folders. Now Joe is feeling brave and starts learning about his computer. He finds in his home dir:.bash_history,.kde3,.mcop,.mozilla,.qt,.bashrc,.DCOPserver_localname_localname_0,.ICEauthority,.kderc,.mcoprc and.xftcache.
Okay, well, so be it - just ignore all of that. Now Joe wants to install NewCoolApp. He starts the installer that was written up for TechnophobeLinux, which kindly asks him to provide the administrator password for the installation. Said and done, and the installer spews files all over his disk. They go into/bin,/usr/bin,/usr/local/whatever,/usr/share/whatever, a bunch of man directories, some in/etc, and maybe some in/opt/whatever as well.
Honestly, how many people here have actually read the guidelines for filesystem layout? I know which stuff goes in/bin as opposed to/usr/bin (which is also mostly different on different distributions btw...), but Mr. User is most likely to have one partition for everything on his simple desktop system, and none of it matters. Say what you want about the stupidity of putting apps in C:\Program Files\Vendor\ProgramName but at least it's fairly obvious that the "program files" end up under "Program Files" (duh) and possibly C:\Win(NT|dows)\System, which kinda makes sense since they're system files.
Joe is going to have a lot of questions rather quickly. For instance, why isn't there user stuff in/usr? Who is/usr/share shared with? What's optional with/opt and why isn't the rest optional? And why is my home directory full of config files if config files go into/etc? And why are there at least two */bin dirs (containing not only binaries but other runnable files btw)?
Say what you want about the Windows registry, but at least it's not laying around in plain view in Joe's home directory. And separating/bin and/usr/bin makes perfect sense on a server handled by a skilled person who could actually do something if/usr would be unavailable anyway - Joe certainly wouldn't be able to poke around the system using/bin and/sbin tools to set things right.
If you're truly going for an easy-to-use idiot-friendly linux, you're going to have to take some tough decitions. Toss the old layout out the window, pick something like/apps,/config,/system,/documentation, or whatever - and spend a long time compiling stuff from scratch to make it work. I once had plans to do this but never reached anything usable (see LFS for a good beginning). You will probably be flamed until you glow red from people saying you're fragmenting the standard and what-not, but sorry guys, the current layout is for server-techs, not for Joe.
(Sorry about the rant)
If you feel like actually doing something like that, feel free to contact me.
I almost reached for a flounder to smack you with while yelling "Read the post before you reply!" but chose not to.
Quote from that post: "Is there anywhere that summarizes the various changes to perl since version 5? there are the perldoc perldelta documents (here is the perldelta document for 5.8.0 [perl.org]). However, these are complete, technical changelogs, and cover everything from language changes to small inconsistency smoothings to changes to obscure library functions to bugfixes in internal perl functions." (emphasis added)
To which your incredibly clever answer was to look up perldelta, even explaining how to do it with perldoc (in a rather clumsy way; perldoc perldelta will do fine). Now: Since you seem to be such an amazingly clever person, could you actually come with some information that could actually help? Thanks.
Slashdot Mirror
Uhm. There's one link in the entire story. That one might just be it...
yes, but not if I go to http://sLaShDoT.OrG. And really, how often do "people" (as in average users) type in something more complicated than www.cnn.com?
My point was that there's actually a reason for passwords being a point of difficulty, while there's no reason whatsoever for keeping the filesystem difficult. In fact, there's no reason to think that a user would connect passwords to files - an average user would almost never type the name of an existing file - only new files.
Not if something is done to the system to let XFree open the file with the name XF86Config...
So every piece of the system is supposed to equal password-level? Okay, so every filename must also be at least 8 characters long, have caps, non-caps, digits and some other characters in it.
[user@host]$ ls
...
ReaD-Me67
coNF%#iGu26re
MaKe+558FiLE
And while we're at it, let's make sure that applies to all the menu items in MozIL%&$A347 and Gn_:66oMe#@*.
I don't store my passwords as filenames (that'd kinda defeat the purpouse of it, wouldnt it?), so there's no reason that passwords need to be case insensitive just because files do - in fact, passwords should be hard to guess; filenames should be easy to guess. Notice any difference?
Really? Can you honestly say you know of something that depends on the fact that there can be files somestuff, SomeStuff and SOMESTUFF in the same directory or on the same path?
In general, people know that if I make a README, a ReadMe and a readme file, not even the most techie person is going to remember witch one contains what, so you don't do it.
I consider this worth doing - in fact, I consider even deeper changes to the way *nix handles it's files (see my journal on that) worth doing.
The actual problem is not that it would be hard, but that all the idiot l33ts would flame a full volcano about it "ruining linux". And then there are always the people who think that it should be done in the UI instead of in the system itself - which of course never worked and never will work (especially not in the OSS world) because alot of programmers say "screw you" to the guides and "my way of doing it is much better".
The biggest difference would probably be that you'd get one less error once in a while from doing the wrong capsation (is that a word?) of a filename.
... just like americans use .com instead of .us? okay. And did you have a point to go with that?
Great page. Not only is it horribly ugly, it's also entirely functionally broken. This, for instance, is a nice html file, no?
Yes, but this is a location issue and a naming issue. It's bad, for sure, but doing it better doesn't present much of a challenge.
No, you only get a link in the start menu if you use an install program.
Point 1: Have you ever seen a windows program without an install prog? No, they all have one, and they all do roughly the same things and look roughtly the same, putting stuff in roughly the same places.
Point 2: Trying to force all package distributors to make an installer (and make that an installer that doesnt confuse people), that installs into standard locations is just not going to work. There's more thoughts of this in my journal for those who are interested.
A user who can understand that C:\Windows\, C:\Program Files\ and many of the files in C:\ (which they probably have to go through to get to My Documents) are system, "advanced", stuff, should be able to understand that files beginning with . are settings files which they probably should not mess with. In any case, they probable can't see these files anyway.
Well, I'd say like this: The user understands that: everything is bad except the home directory. docs go in ~/documents/, pics in ~/pictures/, etc. He puts some other stuff in his home directory (kinda normal thing to do). Now all of a sudden he finds a bunch of weird stuff in his homedir after switching on "show hidden files". Going "hey, it's my home directory", he promptly removes all of them. (you wouldn't beleive what newbie cleverheads do to their computers in form of "cleaning up" and stuff...) I would much rather see if he could learn that configuration files go into ~/config or /config/myname, which would be nice and consistant with the rest of the directory layout.
So basically, Linux does't handle it correctly, but neither does windows.
It's quite possible that neither Linux (because it's based on UNIX, which is not designed as a desktop), or Windows (because it based on DOS, which is just a extremely simplified, badly implemented, version of UNIX), can ever be a really great desktop.
The DOS heritage of windows shows up more or less only in it's directory structure nowadays - and MS is talking about tossing it around and putting the entire fs in a database anyway. I do not think that being a great desktop has so much to do with filesystem layout - but if we're talking a truly easy system that is good for slowly learning more about the system, then windows wins in this case. A user can start learning by clicking the "show files" to show his files in C:\Program Files\, even though there's a note you shouldn't mess around there. Another funny thing is that MacOS X is actually "based" around UNIX as well... and I see alot of people here claiming its superiority.
and a large part of the problem may be with users unused to the idea of having separate (for user accounts) root access.
People get used to security stuff - most people werent used to typing a password once, and now they can run Win2k boxes just fine logging in on startup. The key is just telling them not that it's a "root account" but that it's a password needed to install software and configure some things. When needed, they should be automaticly asked to provide the password.
Basically the App Directories are self-contained applications, with the executables, help, etc. all in one package
Thanks for the link - that's an idea I like and think could be useful.
The point is that we're talking desktops here... I made clear from the very beginning that there needs to be a separation to where the current FHS should be in effect, which is basicly systems that are administered by somebody who wouldn't run away screaming at the mention of "heavily automounted home directories" ;). And then again, having configs in /config/user/namehere and mounting that along with the home dir shouldn't be a terrible problem... and if it is, just set $CONFIG to $HOME/config and that's fine. Anyway it's rather a non-issue.
Let me clarify things a bit - I do not mind so much the name of etc, even though i find it stupid. What i mind is the structure of stupid names that is /opt, /usr, /usr/share, /usr/local, and all the differnt stuff that goes in an arbitrary place within it. And if we're going to change that, why not give names that actually mean something reflecting their contents in a readable way while we're at it...
Good point. I still would like to have them in ~/config/ instead of ~/ though. The effect would be the same.
I was under the impression that symlinks do not work if you chroot. That'd kinda break the chroot wouldnt it? You'd have to hard-link everything, which is only possible putting user_root on the same partition as all the other dirs. Unless I'm wrong and symlinks work through chroots.
I can make the model just fine, but then what would I do with it?
Of course a good deal of work would go into getting a design that was actually better and not realize halfway through that "oops, this wasn't so good".
I later figured out that any program that puts config files as $HOME/.something needs to be patched to use something like $USERCONF instead as well.
Congratualtions. I switched more or less on a whim a few months back - now all my linux boxes run gentoo. The portage system is simply a godsend when it comes to simplicity and is just generally better than anything else I've seen.
Note that I don't think it's good enough for "home" (read "newbie") users though.
Listen up everybody, from now on, EVERYBODY's working on KDE.
Think it'll work? I don't... there's the obvious flaw that people work on what they want to work on, since they're not hired by somebody who can tell them work work on project xyz. Thus, people would quarrel over which project to all work on, and never get there...
The only conclusion is that open source needs to work anyway (and I think it will), by finding some other way of coping with this. In my opinion, this way is standards and interoperability between projects.
Ah... my other gripe with it. Install all of KDE and look at the program menu. *Almost* everything is named KWhatever... which entirely breaks the sorting of things.
Ideally yes. But i wasn't joking - i've seden those things. Most stuff goes into /etc or ~/.whatever. Postgresql or mysql (can't seem to remember which now) installed its config into /usr/share/*sql/etc|config|something on some old install i did. I currently have KDE configs in /usr/kde/3/etc (one file) and /usr/kde/3/share/config (the rest) on gentoo, which could also be /usr/local/kde/share/config on some distros, /usr/share/kde/config on some and /opt/kde/share/config on others... and there you have all that I listed. I wasn't making it up you know - I was talking out of experience because I'm godawfully tired of fucking around trying to figure out where the hell my latest distro pick to install something. Oh, and I currently have QMail configs in /var/qmail/rc and /var/qmail/control... *sigh*
Mentioning that was not so much a saying that windows is better but that linux is just as bad in the general case - which the parent post to my answer complained about; multiple partitions etc.
This is aproximately what I expected (and have seen before). I never said Windows was more organised - I said it hides the complex parts better and more obviously to the user - while not taking away direct access to the filesystem. I know people install on the desktop - but hey did I say windows was perfect or was it just your l33t ego I hit or something? I said windows has a better idea at the thing than FHS. Now what happens in linux if you buy a new harddrive? It magicly melts into /usr without the need of another partition? It doesn't on my system...
And what's this about apps being spread out everywhere?
The fact that apps spread on windows doesnt make them spread less on *nix.
Windows apps usually install stuff into their directory,
of course.
the windows or windows/system directories,
It was ages since I've seen anything installed into the windows dir. The system stuff goes into the system dir - that's all. I.e. call it "shared" instead of maybe /usr/lib/something /usr/shared/something or why not /var/something/something or /usr/local/something/shared, /opt/whatnot/shared... (i've seen all of these in action)
the registry,
instead of /etc, /usr/shared/something/etc|config|picksomething, /usr/local/something, /opt/*/config|etc, ~/.mycrypticnamerc
sometimes they add stuff to your Profile and they add shortcuts.
I don't hear anybody complaining about that.
I hear people complaining about it quite often - how badly structured it is compared to *nix, for instance. The point is that while you can guess the 4 or often less places a windows install puts stuff, it's hardly ever possible to guess all of the places unix installs go - that without even providing that service of adding things to your menus.
the registry is never accessed by users, and ditto for the Linux file system.
To me it seems like a horrible mistake to classify users into "stupid" (i.e. running the StupidSimpleLinux distro like Joe User), and l33t superwizgeeks like you running whatever other distro - I don't think you've brought linux to them then, just as you arent a "linux user" just because the ATM you just got money from was running a linux-based system. Like said in other posts - the "friendlyness" and "easyness" should scale up to the advanced level - where everything is open. Claiming that spewing config files all over my home dir would be better than putting them in e.g. ~/config just because you can hide it is silly.
I can't think of any compelling reason to do this at all, considering that these are paths normally only used by software.
Now that's a gem. You never use the filesystem layout on your systems? Would YOU want to use the system never seeing the filesystem? Or is this exlusively for the stupid newbies? Come on... in your vision of a newbie system the paperclips aren't that far off - and just admit that you would never run such a system without an "advanced" switch that let you disable all your nice UI gadgets.
After that there'd probably be a period of just trying everything out and seeing what isn't working. This most likely would be things that you missed in step 4 above. I might take an old P133 i have just to try this concept out...
Now about the /usr/bin etc issue, what happens when Joe starts learning about the computer. He wants to know more, and switched the "advancedness" lever one flip upwards. Suddenly it exposes a system that is none at all like what he currently knows. I would like a newbie-friendly system that "scales" its friendlyness all the way up to the advanced mode.
Now here's the second problem with the FHS; where a program ends up depends on who installs it and when - if I install it it probably goes in /usr/local/bin or /usr/local/whatnot/bin, but if installed by the distribution it could go in any of /bin /usr/bin /opt/whatever/bin or /usr/something/bin.
The solution to all of this is in my opinion to 1. Create an alternative FHS for desktops only and make install programs compatable with this layout or 2. hide everything and have a wizard/popup box for every little feature a-la the Microsoftish way. I don't really like that second answer, and the first one is hard on a linux-lover to even consider. But hard things must sometimes be done, if you want that "easy" system - not just an "easy" startup page that proves to be bogus once you reach level 2 in linux the platform game [tm].
To cut it short -- one could make Linux (*BSD) look completely innocent. It would only take lots of time and quite a bit of creativity.
Of course it would be possible to do - but it would be just that: "a look". Like a mask to cover the true nature of the beast, instead of a true change in the system. It's really just a push in where the user experience turns bad and where the learning curve derivate goes sky-high.
Having C:\Windows and C:\Program Files is okay on a windows box; they're just points of no-entry, aka advanced stuff you never need to look at. Instead you have "My Documents" to put documents into, and "My Pictures" for pictures. As you get more advanced you could even install a new program. It goes, logically into Program Files, and you get a link automaticly in the start menu.
Now lets look at the linux version. There's /home/joeuser, which has nothing. You could add, say, documents, pictures to it. So now we have those two nice folders. Now Joe is feeling brave and starts learning about his computer. He finds in his home dir: .bash_history, .kde3, .mcop, .mozilla, .qt, .bashrc, .DCOPserver_localname_localname_0, .ICEauthority, .kderc, .mcoprc and .xftcache.
Okay, well, so be it - just ignore all of that. Now Joe wants to install NewCoolApp. He starts the installer that was written up for TechnophobeLinux, which kindly asks him to provide the administrator password for the installation. Said and done, and the installer spews files all over his disk. They go into /bin, /usr/bin, /usr/local/whatever, /usr/share/whatever, a bunch of man directories, some in /etc, and maybe some in /opt/whatever as well.
Honestly, how many people here have actually read the guidelines for filesystem layout? I know which stuff goes in /bin as opposed to /usr/bin (which is also mostly different on different distributions btw...), but Mr. User is most likely to have one partition for everything on his simple desktop system, and none of it matters. Say what you want about the stupidity of putting apps in C:\Program Files\Vendor\ProgramName but at least it's fairly obvious that the "program files" end up under "Program Files" (duh) and possibly C:\Win(NT|dows)\System, which kinda makes sense since they're system files.
Joe is going to have a lot of questions rather quickly. For instance, why isn't there user stuff in /usr? Who is /usr/share shared with? What's optional with /opt and why isn't the rest optional? And why is my home directory full of config files if config files go into /etc? And why are there at least two */bin dirs (containing not only binaries but other runnable files btw)?
Say what you want about the Windows registry, but at least it's not laying around in plain view in Joe's home directory. And separating /bin and /usr/bin makes perfect sense on a server handled by a skilled person who could actually do something if /usr would be unavailable anyway - Joe certainly wouldn't be able to poke around the system using /bin and /sbin tools to set things right.
If you're truly going for an easy-to-use idiot-friendly linux, you're going to have to take some tough decitions. Toss the old layout out the window, pick something like /apps, /config, /system, /documentation, or whatever - and spend a long time compiling stuff from scratch to make it work. I once had plans to do this but never reached anything usable (see LFS for a good beginning). You will probably be flamed until you glow red from people saying you're fragmenting the standard and what-not, but sorry guys, the current layout is for server-techs, not for Joe.
(Sorry about the rant)
If you feel like actually doing something like that, feel free to contact me.
Quote from that post: "Is there anywhere that summarizes the various changes to perl since version 5? there are the perldoc perldelta documents (here is the perldelta document for 5.8.0 [perl.org]). However, these are complete, technical changelogs, and cover everything from language changes to small inconsistency smoothings to changes to obscure library functions to bugfixes in internal perl functions." (emphasis added)
To which your incredibly clever answer was to look up perldelta, even explaining how to do it with perldoc (in a rather clumsy way; perldoc perldelta will do fine). Now: Since you seem to be such an amazingly clever person, could you actually come with some information that could actually help? Thanks.
According to Wired news, A 100-million-year-old skull of one of the weirdest creature has been discovered in Brazil.
Now, according to the article:
The 100-million-year-old skull was discovered in 1983 in Brazil
I mean, ok, slashdot is usually a bit behind but this reaches new heights... You're 19 years late guys! :)