Ask OSNews is apparently quite popular among you guys; the questions just keep on coming in. Since David took on the first two, we decided to let me handle this one – it’s an area I’ve personally covered before on OSNews: file system layouts. One of our readers, a Linux veteran, studied the GoboLinux effort to introduce a new filesystem layout, and wondered: “Why not adopt the more sensible file system from GoboLinux as the new LSB standard?”
Basically, there are two reasons why we’re still stuck with the Filesystem Hierarchy Standard (FHS). The first is a perceived benefit, the other is the real reason.
The perceived benefit is that the FHS should provide a standardised file system layout across various UNIX-like operating system. This would mean that users and developers alike know exactly where to find which files. Sounds like a good idea, right?
It actually is a good idea. It’s just too bad that no one actually cares about the FHS, and places their files wherever they want. Not only do different operating systems use different implementations of the FHS, but even different Linux distributions use different implementations. On top of that, the standard itself isn’t strict, and allows for exceptions to its own rules (X11R6 being placed in /usr, anyone?). What good is a standard nobody adheres to?
Exactly, no good at all. So, this is a perceived reason why everybody still clings to the FHS. What is the real reason?
The real reason we’re not moving ahead to greener pastures in file system layout land is because of inertia. The FHS is so entrenched in the UNIX/Linux world, that it’s going to be very hard to move away from it. Not only would it be virtually impossible to get all the noses to point in the same direction (we can’t even agree on the implementation details of the FHS!), there would be a massive uprising among people who still believe the FHS is serving its intended purpose just fine (even though it doesn’t).
In the GoboLinux article on OSNews I summarised the FHS situation as follows:
Us Linux, BSD, and (yes) Mac OS X users are still stuck with a system that predates the coming of Christ, and the only reason we still have it is because people are too afraid to make the big step and come up with something that is – in every possible way – better than the FHS, but still compatible. In a very brave and commendable effort, GoboLinux has done just that, but instead of being praised for bringing the filesystem structure of Linux systems to an acceptable, modern level, they get ridiculed and frowned upon as if they are some sort of heretics. To me, it is absolutely mind-boggling that distributions like openSUSE, Fedora, and Ubuntu call themselves “user-friendly” while still maintaining a directory structure that requires a degree in computer history to even remotely understand – including all its exceptions and quirks.
To answer your question succinctly: developers are not replacing the FHS with something that actually works because they still believe in the ideals of the FHS. In addition, it would be very hard to get everyone to agree on the FHS’ replacement.
With “something that actually works” I mean a file system layout that is:
- Human-readable
- Logical
- Strict (does not allow for differing interpretations)
- Translatable into other languages
- Not legacy encumbered
- Not hidden by abstraction layers
Rests me to say that the UNIX/Linux world isn’t the only one suffering from messy and incomprehensible file system layouts – Windows suffers from it just as much.
Do you have a burning question for OSNews on any topic ranging from OSes and computing to science and geek culture? Our team of self-proclaimed experts will answer your question, and if it falls outside of our domain expertise, we’ll try to track down a real expert to help out. And of course, our responses will always be supplemented by further advice from OSNews readers in the comments. Contact us now! (Please include “Ask OSNews” in the subject)
…why bother changing it? The fact is most users never leave their “home” directory, and if they are so bold to do so, to manipulate their system outside of that operating system’s standard method of application installation and updating, then they will take the time to learn and try and understand the file system layout.
Mac OS X users are perfectly happy seeing “Applications”, “Home” and little else. It’s the hacks like myself who love digging down into the underlying guts and mucking around down there, replacing finder, moving my home directory to another disk, etc.
Most people understand this:
Home
My Documents
My Music
My Video
My Pictures
And that is about all they care about… that and email and web browsing.
—
Edit: Don’t get me wrong, I understand the benefits of a truly standardized file system layout, but I don’t see any real pressure to treat this as tho’ it were extremely important.
Edited 2009-05-28 19:39 UTC
Yes, and why do you think that is so?
Are you going to try and tell me that is because of the file system?
Is the layout of a file system so inspiring to people, to creativity, to life on a computer?
I am a software engineer, and even to me file system layout is not really a subject that causes me to wax on about standards and the pain and suffering caused by a lack thereof.
I’m just trying to explain that many people are put off diving further into the intricacies of the computer simply because of how daunting everything is. By making a system easy to use and understand not only at the very highest level (the UI) but also all the levels below that, we might enable more people to actually *understand* their computers better, which would be beneficial to *all* of us.
I am of the strong belief that there is no sane reason WHATSOEVER why we couldn’t make computers easier to use and understand on ALL levels, and not just at the top – other than geek job security.
Transparency, clarity, and simplicity across the board are beneficial to the computer industry. The file system is part of that.
Well I can’t argue with that.
Maybe I am too entrenched in the operating system and programming worlds to really see the forest for the trees, or the other way around maybe.
I guess I’ve just worked on so many different Operating Systems with a variety of file systems that I am just able to figure it all out fairly quickly.
Simplicity is always better.
I’ve only been a programmer for ~6 months: what I am about to say may be idiotic. But:
It is exactly as a programmer that the FHS annoys me. When I do the “configure, make, make install” (dance to install a dependancy, say), I have no idea where on my system the libraries I’m building are going to end up (yes, I know that I can usually specify that with configure, but, sometimes some things expect those libraries to be in their default locations: if I change that with configure, I may break some other library that has the library I’m building as a dependancy). When I’m writing a make file, it can be really, really annoying to figure out what my library include paths should be. If it was clearly specified and consistently enforced where libraries should go and where headers should go, my life would be a lot easier.
“I’ve only been a programmer for ~6 months: what I am about to say may be idiotic. But: ”
Good thing you put in that disclaimer. Er, I’m sorry, but it *is* a bit idiotic.
“When I do the “configure, make, make install” (dance to install a dependancy, say), I have no idea where on my system the libraries I’m building are going to end up”
Almost always, if you don’t specify a prefix, everything will be installed within /usr/local. If not, the author either has an extremely good reason, or is just flat out wrong. All typical buildsystems should be written to install within /usr/local by default.
The reason for this is simple: as long as everything adheres to the convention, you have a clear and easy separation between code installed from source (which will all be within /usr/local) and code from distribution packages (which will all be up in /usr). It’s always easy to know where something comes from, and in the worst case, you can always delete (or just move) /usr/local to get back to your ‘base’, distribution-packaged system state.
BTW, why are you building the libraries you want to build against from scratch? Why not just install your distribution’s packages for them? This would usually be the sensible way to do it.
“When I’m writing a make file, it can be really, really annoying to figure out what my library include paths should be.”
In most cases, you should be using pkg-config for this purpose (if you don’t know about that, yet, look it up).
All well and fine, Adam, but every Linux distributions basically disregards the FHS anyway, and places files wherever the hell they please. It gets even more retarded the moment you go cross-platform into the world of BSDs, and don’t get me started on the layer-upon layer mess that Mac OS X has created, which is basically a full-blown admission that yes, the FHS is MAJOR SUCKAGE. However, instead of Apple fixing it, they gave in as well and now we have this hybrid monstrosity.
“All well and fine, Adam, but every Linux distributions basically disregards the FHS anyway, and places files wherever the hell they please.”
I really don’t agree with this at all. What distribution doesn’t place binaries in /usr/bin , static data in /usr/share , libs in /usr/lib (or /usr/lib64, which is a de facto extension by now, for widely-recognized and valid reasons), dynamic data in /var , configuration in /etc…? Distributions use different layouts for things that aren’t specified by the FHS – like the differences in, oh, network configuration between Red Hat and Debian, for instance – but that hardly invalidates the FHS. I haven’t seen you provide any kind of substantiation for the claim that distros just put stuff wherever they like.
And why can’t they agree on a single path and use that? Something like /System/Configuration/Network would be even better. The user should always know where to find the files.
Edited 2009-05-29 10:59 UTC
One more time: there is already such a single path. What was again the reason to have
/System/Configuration/Network
instead of
/etc
?
No, there actually is not.
There can be new directories within /etc, and files inside that, or even more directories.
Perhaps you should try different distributions and look what differences they use.
The FHS is a silly standard.
a) It does not enforce itself much, not even as LSB standard (LSB only extends FHS, but does not govern the layout of configuration files in /etc, other than that they say you should place all config files in /etc but dont tell which config files *should* be used to HELP end users)
b) It removes flexibility for no other solutions. No Appdirs, no registry, no other solution may be applied. Now you monkeys can say that registry is always bad, that appdirs are always bad, but this is not the point. The point is that the FHS already restricts yourself. If you can not accept that the FHS restricts you, then go play on the meadow.
“And why can’t they agree on a single path and use that? Something like /System/Configuration/Network would be even better. The user should always know where to find the files.”
Because significant distros have been using different layouts for a long time now and it is not easily possible to get them all to agree to switch to a new standard. Debian has a certain style of laying out network configuration files, Red Hat another; Debian and Red Hat admins are very used to the respective styles and would be extremely pissed off if they were to change.
This isn’t really an “FHS is great” or “FHS sucks” issue, though. The FHS has never been intended to be so incredibly detailed it can tell you *exactly* where *every* file should go. It would be extremely difficult to attempt such a thing (remember, when FHS was written, much of the infrastructure in current Linux distros didn’t even exist). All standards have to achieve a trade-off between comprehensive coverage and flexibility.
Except for the Billions of folks who don’t speak English.
If you must set out to find them, then
by definition you don’t know where they are.
“Except for the Billions of folks who don’t speak English.”
Oh, there’s an easy solution to that – we could just have a framework for internationalizing those directories, like we do for the content directories standardized by fd.o within user home directories…
…excuse me, I have to go and vomit.
Nobody knows where the system files are when they first start using an OS. But having a logical and human-readable (that is, not geek-readable) file structure helps a lot in finding them.
“However, instead of Apple fixing it, they gave in as well…”
If they want to have their OS certified as Unix, they have to do it that way.
Welcome to the Macho club. This club exists at all levels – file systems, programming languages, application development, etc, etc. I describe it as the “I made it up the hill, now it’s your turn” syndrome. This syndrome also applies to math – “How symbolic can we make, they’ll never figure out our shorthand”. Even in religion it is done. I get physically nauseous when I hear some Christians banter around theological terms designed to keep out the uninitiated. I call PHOOEY on all of it.
[deep breath]
I feel better now. I hope you `cat my_comment | grep useful` , Okay?
This is so sadly true, and also apparent quite often here at this site even. I would go further to suggest that many geeks and techies just lack the comprehension that other users simply view computing differently. Let’s face it, there is a lot of unwarranted arrogance by people who simply look down at non-techies as either lazy, ignorant, or stupid.
Users could care less, or give a damn, about the logic or reasons behind etc, var, usr, opt, etc..On the other hand;
Programs
Users
System
Files
Mount
Depot
This is what a system should look like for end-users, or better put “the public”. I think we can all agree that POSIX FHS was NOT designed for end users in mind. Windows got it right with putting the OS in “Windows”, programs in “Programs Files”, and profiles in “Documents and Settings”. For any user, this is not just logical but easily understandable.
Go find 100 random people on the street, show them two pieces of paper with the directory listing. Should we be surprised that 99% would pick GoboLinux’s over any other?
For geeks, computing is a hobby and toy, but for non geeks it is a tool meant for easing certain tasks. When you complicate the task at hand, you defeat the whole purpose of having a computer. Maybe in 2009 some can figure out that a FHS designed decades ago for non public use should be evolved some. Otherwise, with such mentality, expectations should be lowered to realistic levels about adoption.
To begin with, non-geeks categorically won’t be poking around the filesystem, on Windows, Linux, or (insert OS here), simply because there is NOTHING productive to be gained from it – all they care about is their Desktop, their home directory, and their installed programs. The parent post mentions Windows, which is an excellent example of end user-apathy: despite the ‘simplified’ root filesystem, none of the non-geeks that I can know can navigate it any better than they could the traditional *nix filesystem, nor should they need to.
The Windows model also provides a glimmer of the hurdles provided by ‘simplified’ interfaces: every library or binary which is installed system-wide is placed in X:\Windows\System32, which results in an even more bloated primary resource directory than on *NIX. This monolithic layout also prevents the traditional *NIX concept of mounting additional remote resources to a standardized location (/usr) atop a the bare minimum required for local maintenance (/). Whether or not this model is valid any longer is up for debate, but the fact of the matter is that the FHS was not designed in order to create a ‘macho club’ as you are inclined to suggest.
All in all, while filesystem revisions sound like a good idea to the unresearched geeks suggesting the alterations, the end users could care less, and those ‘initiated’ geeks understand the historical and practical considerations of how such layouts came to be. Even GoboLinux maintains a traditional FHS shim under the trappings of a new root filesystem.
Edited 2009-05-28 21:12 UTC
To begin with, non-geeks categorically won’t be poking around the filesystem, on Windows, Linux, or (insert OS here), simply because there is NOTHING productive to be gained from it – all they care about is their Desktop, their home directory, and their installed programs.
Non-geeks shouldn’t care about it, no, and most often they don’t.. but is that a good reason for not creating a better standard? IMHO there is ALWAYS room for improvement, even if it helps only a select bunch of people. And in this case it’d help developers, sysadmins and most likely packagers too!
I f.ex. am annoyed by the fact that there’s atleast three different “bin” locations: /bin, /usr/bin and /usr/local/bin. Why not just make two locations instead: /Executable/CLI and /Executable/GUI? The same for libraries: /Shared/Libraries/32bit and /Shared/Libraries/64bit..
Why do most people proposing alternatives to the FHS insist in introducing capital letters?
Do they add any advantage worth the extra keypresses?
Why do most people proposing alternatives to the FHS insist in introducing capital letters?
Do they add any advantage worth the extra keypresses?
It’s a matter of taste. Why do so many people insist on them being lower-case? Is it too hard to press shift while typing a letter?
Yes.
When typing a single letter: no.
Doing it over and over when working on the console: yes, it’s utterly annoying.
I can’t speak for the others, but in the case of Gobo, long names with capital letters were chosen to avoid conflicts with the FHS which still lives underneath Gobo’s hierarchy.
From teh GoboLinux page:
Because they look nice.
The file system would be better off case insensitive.
That way the directories could be capitalised and you can just refer to them in lower case in the shell and all the sane people are happy.
(What I am saying i that I see no good reason for case sensitivity in the file system, and in fact many reasons for case insensitivity)
WOW. Just Wow.
So you would be perfectly happy if every file switched
to ALL CAPS every time your rebooted your computer?
So you would prefer that developers waste time working on
the best possible way to fake it?
Even though we already have it now for real??
Nobody is saying it _shouldn’t_ be improved, but that 1) it shouldn’t be completely overhauled for the end user as GoboLinux does (forcing the user to use the FS instead of appropriate tools for package management),
2) practical considerations trump aesthetic qualities, and
3) sufficient circumspection is required before proposing a new system, instead of simply slapping down the solution that solves _your_ problem.
Given your example, the third point raises the following questions:
Why is the proposed system superior to an incremental improvement to the FHS?
What is the significance of rendering the directory names with a leading uppercase character?
Why are executables not ‘Shared/’?
What happens when an executable presents either interface depending on the arguments and/or context?
Do we impose the 32/64-bit differentiation as part of the standard, or just apply in the differentiation to systems atop architectures on which it is a concern?
By all means, feel free to improve on the FHS – but be aware that there is far more to be considered than “macho clubs”, end-user readability, and what “works for you”. Standards are hardly the ideal place for a “YMMV” disclaimer.
Given your example, the third point raises the following questions:
Why is the proposed system superior to an incremental improvement to the FHS?
I never claimed such, but well, the point was rather that that there’d be a single directory under which all executables are organized, preferably with CLI and GUI executables separately.
What is the significance of rendering the directory names with a leading uppercase character?
No significance. But what significance is there for rendering that same letter lowercase either? I just am used to writing the first letter of the first word in a sentence with uppercase.
Why are executables not ‘Shared/’?
Could very well be.
What happens when an executable presents either interface depending on the arguments and/or context?
Do we impose the 32/64-bit differentiation as part of the standard, or just apply in the differentiation to systems atop architectures on which it is a concern?
It’d be best if there was no special cases. Handle the executables the same on all and every supported architechture, ie. if your system supports only 32bit executables then still put then in the 32bit folder. But that too was just a simple example, I was just trying to make the point that it should be made more logical. You’re reading way too much into my post. Heck, since no end-user probably visits those locations anyway you could just make it /Shared/Executables/PowerPC/64bit or /Shared/Libraries/x86/32bit and similar. It’d be neatly organised and easy to navigate for the sysadmins.
“I f.ex. am annoyed by the fact that there’s atleast three different “bin” locations: /bin, /usr/bin and /usr/local/bin. Why not just make two locations instead: /Executable/CLI and /Executable/GUI? The same for libraries: /Shared/Libraries/32bit and /Shared/Libraries/64bit..”
There’s a good reason for the separation between / and /usr: network clients. A client running Linux does need a few things to be present locally; these should go outside of usr (so binaries in /bin and libraries in /lib). Anything else – anything that can safely be located on the server – goes in /usr, and /usr is remote mounted.
See? There’s a reason. Just because it seems odd on a typical desktop where you’re *not* remote mounting /usr doesn’t make it wrong.
“Why not just make two locations instead: /Executable/CLI and /Executable/GUI?”
Mandriva’s configuration tools run as GUI apps if you run them from within X, and CLI apps if you run them from outside of X. Which directory should they go in? Why do you want to draw this distinction anyway? It doesn’t serve much purpose. It’s more or less the old /usr/X11R6, which we *finally* got rid of from most distributions a few years back, much to everyone’s relief.
Edited 2009-05-28 21:54 UTC
Agreed. Although, accomplishing the same thing with a UnionFS setup instead of using multiple mount points would be a more modern way to do this. There’s a slim chance it might even turn out more user friendly.
Oh for the love of… not this again.
/bin is the bare minimum required to pull the system up. It’s incredibly helpful to have this as a separate directory in any case where the main file system isn’t available at boot time…
Which happens every time you boot, when the initrd.img is decompressed into ram.
/usr/local/bin is used for binaries that were compiled on the system, and are not part of the package management (if it even exists) system. Need a specific version of java? It goes there. Have a couple of perl scripts customized to the system? That’s where it belongs. How about if you install a system package that has the same file name as an existing custom program? If you have everything in the same place, you’re going to have issues.
If the standards are followed, the admin knows to completely ignore everything in /usr except /usr/local when it comes to doing backups – which is you know, useful.
Just because you don’t understand the need for something, doesn’t mean it’s pointless.
Whilst I think /Executable/CLI and /Executable/GUI would be a nice separation, I also like /bin /usr/bin and /usr/local/bin … why?
/bin has essential low-level system tools, /usr/bin has optional applications, /usr/local/bin is where stuff I compiled generally puts itself so that it’s out of the way of the official distro-packaged binaries in /usr/bin, thus reducing the risk of breaking my package manager.
It’d kinda be nice to have the option of both views, perhaps with /Executable being a psuedo filesystem on top of the Unixy filesystems (or perhaps the other way round, except that that might possibly break some usecases).
I’ll also note that with /sbin and /usr/sbin and (probably?) /usr/local/sbin we actually have even more locations for binaries than you pointed out. Not that that makes it any less confusing 😉
All in all, while filesystem revisions sound like a good idea to the unresearched geeks suggesting the alterations, the end users could care less, and those ‘initiated’ geeks understand the historical and practical considerations of how such layouts came to be.
Exactly!
“On the other hand;
Programs
Users
System
Files
Mount
Depot
This is what a system should look like for end-users, or better put “the public”.”
Er, why?
I have no idea what the hell that layout means. What goes where? What’s the difference between “Files” and “Depot”? What actually goes in “Files”? How do you distinguish between “Programs” and “System”, exactly?
Generally, can people who’ve never done any serious work on an operating system *please* quit proposing filesystem layouts as if it were something any idiot could jot on a bar mat after a couple of pints? It just isn’t.
Did you have any idea what ‘/etc’ was for the very first time you laid eyes upon it? Probably not. No file system hierarchy is completely understandable just by the names, but the GoboLinux documentation explains what each is for very well.
There IS a method to their madness.
But the person proposing it claimed that it was a much better system for end users. Exact quote:
“This is what a system should look like for end-users, or better put “the public”. I think we can all agree that POSIX FHS was NOT designed for end users in mind.”
If it’s just as hard to understand as FHS, why is it any better for end users? Where’s the win?
Because the end user can easily figure out and find what they need to do in one, whereas the other can cause ulcers.
WTF, I can not even begin to count how many times I have to open up the Software Management in Yast to see where the f**k some god damn program installed files. Then I get the joy of having to go through numerous directories to get a job done that would be much simplified if it was installed in “Programs”.
On Windows, if I install just about anything, I know to go to Program Files if I need to look at a readme, make changes, etc.. THAT is intuitive thinking. Again, pretty damn easy to figure out “Programs” are located in “Program Files”.
Again, can some just get it through their thick geek skulls that this POSIX was NEVER designed for public use? Linux, BSD, etc.. are all, excuse me for saying, clones in this regard. Let’s not forget Solaris, and please do look at Solaris’s history and WHY it was developed, and WHAT it was used for. For that matter, look at just about ANY POSIX system, and look at it’s roots. These were NEVER developed for end users in the first place.
Want BSD, Linux, Solaris just for appliances and servers, then fine. Want that “Year of the *nix desktop”, then lose the tech mentality and start thinking for the end users! It’s just not the subjact at hand that drives me mad, but the entire mentality of geeks to blind.
Only so called “power” end users who *think* they know more than they actually do will refuse to use the nice and easy package management software. Isn’t “Add/Remove Software …” an intuitive enough name?
Assuming a Gnome based Linux distro and Firefox is installed on both machines:
On a Linux machine, open “Run” (Alt+F2), type
“firefox” and hit Enter, What happens?
On a Windows machine, open “Run” (Windows+R), type
“firefox” and hit Enter, What happens?
On the Linux machine, open a terminal, type
“firefox” and hit Enter, What happens?
On the Windows machine, open the command prompt, type
“firefox” and hit Enter, What happens?
WHY?
Your logic is quite flawed.
By that logic, Windows could never have built their hideous monopoly
until *after* they cleaned up the insane mess that is system32
and completely eliminated the registry. Did they?
By that logic, Mac OS X must not be too popular among
Apple’s customers. Also, the iPhone seems to have sold
fairly well – even to non Mac owners – how much would
*you* want to bet that there is no semblance of FHS
or no /usr/bin under there?
Your logic is quite flawed – what a frail attempt at misdirection –
bringing up the old “Year of the Linux Desktop” argument again!
and having the gall to misdirect further and say “*nix” desktop!
Linux, not “*nix,” but *_LINUX_* continues a steady rise
in desktop marketshare year after year.
I don’t see anything changing that trend anytime soon.
And if I may misdirect the misdirection,
What about “The Year of the Windows 7 Desktop?”
All of those budget conscious IT Managers whose operations
are all on WinXP right now had nothing to gain from Vista
except a much higher pricetag and endless retraining of staff.
Isn’t Windows 7 the same proposition all over again?
When it comes right down to the checkbook, Business IT
*still* has no real incentive to leave WinXP.
Go ahead and hit me with your arguments as to why
“The Year of the Windows 7 Desktop” is inevitable:
1. The final coup de grâce for WinXP support.
2. Windows 7 will be pre-installed by all OEM’s.
3. Windows 7 will run cool new games.
Congratulations, your arguments are correct sir!
But now realize that the same arguments would work for any OS.
If you really want the help us realize the
“Year of the Linux Desktop,” simply help make those
arguments true for Linux as well – and #1 is a given.
The underlying filesystem layout has precisely
SQUAT to do with market dominance.
It’s not “just as hard”, it IS easier to understand, but it still requires a modicum of effort. You will never be able to eliminate all requirements of user effort, but you can at least minimize them.
OS X:
User preferences go into /Users/<username>/Library/Preferences
Linux:
While user preferences go into ~/, they’re most of the time hidden and users don’t know they are there.
So tell me which one is easier to figure out.
Yes, “Library” is a perfectly understandable part of the path for a user. Why aren’t “Preferences” under the users dir directly? Putting Library in there sure doesn’t make things easier.
“Library” is there to avoid filling up the root and home directory with an insane amount of subdirectories. If you look inside it, you’ll see one or two dozen subdirectories. In / and /User/<username>, you have “Applications”, which you want easy access to, and “Library” containing everything you don’t fiddle with on a daily basis.
That I can agree with. (As long as you take the capital letters away.)
Unfortunately it is impossible to reverse the behavior of all open source applications, given that these files are created by applications, not distributions.
But what I fail to understand are those great benefits from having, say, /System/Libraries instead of /usr/lib because, well, there is no other difference except new names with capital letters.
usr/lib makes no sense.
system/libraries is instantly recognizable.
Means absolutely nothing to somebody who has no idea what libraries are. I can assure you that my mother would be equally bewildered by either naming scheme. Someone who knows something about operating systems would have no trouble with either. Nothing gained, nothing lost. Why not just leave it the same?
Exactly! And I wonder how many of the people who say “change the FHS” have actually installed and use GoboLinux for its wonderful new approach?? Let’s see a show of hands…
Did you have to look up “usr/lib” just now or did you just know it?
Nice way to invalidate your own argument there.
I guess not having “system/libraries” is what is really holding WinXP back.
SSH for Mac still stores in “~/.ssh/”
Firefox for Mac stores data in “~/Library/Application Support/”
Safari stores bookmarks in “~/Library/Safari/”
Apple broke with Unix tradition and gained absolutely
nothing – now their users are dumbed down AND there are
at least 3 different places to look for user preferences!!!
Advantage: Linux!
Don’t fall into the trap of thinking you represent “most users” and what you’re arguing for would make it easier for all. Maybe if you show 100 PC _users_ the Microsoft layout vs. FHS you would get agreement that the MS way was easier. Then go talk to a different audience – how easy is it to use a networked FS to share common parts of the systems for thin-client applications? Different answer.
I know its an obtuse point – my point, though, is that the FHS has been designed to suit more use-cases than just desktop users, and there are reasons why many things are done the way they are. No, it’s not necessarily easy to understand for an end-user, but then that is not the bee-all and end-all of metrics to measure the success (or otherwise) of a file-system layout.
egads – claiming that it’s “the macho club” in incredibly macho. and also ignorant, or at least disrespectful of the non-idiots who brought us to this point. sure, whether it’s /usr or /User is a bit silly, not unlike creat()/create(), but who really cares? the idea (of segregating kinds of files) is worth preserving, even if a casual user is puzzled.
I’m guessing gobo is just based on ignorance of history, perhaps wilful. also, if they were serious, they’d include something like environment modules, rather than the fairly awful Current pointer.
Mathematicians don’t make things symbolic to confuse anyone (they wouldn’t be very good mathematicians if they did!). It’s not a symptom of making other people pay their dues. The fact of the matter is that it makes communicating mathematics simple for deep concepts; no one is deliberately trying to obfuscate anything or “keep out the uninitiated”.
I’d argue that most every subject has its own jargon so that everyone can stay on the same page without having to work from first principles every time they wish to start a dialog.
But they don’t care to understand… so many people don’t understand the difference between the OS, the word proccesor, the browser and the search engine, and when you explain it to them, you can see that empty look when they try to _pretend_ that they are trying to _understand_.
But as long as the… er… ‘stuff’ does it’s… er… ‘thingie’ or whatever, they’re ‘okay’…
Why do you think users intersted in learning more are not able to comprehend the FHS? Compared to other things in the computer field it’s straight forward and actually documented.
I don’t think we need to treat users as total idiots who are incapable of comprehending something like the FHS.
The FHS is clearly documented and it is the way it is for good reasons.
The problem with your theory is human stupidity. If you make the filesystem more “friendly looking” then a larger number of people are going to be more likely to start poking around in places they shouldn’t and hose their system.
“I accidentally..the whole drive” isn’t exactly covered under the manufacturer’s warranty, either.
For the average user, “My Documents” or “/home”is a fine place to stay. Leave the inner workings to people that understand it.
Don’t confuse stupidity with a lack of knowledge. Sooner or later, we all “poke around” places we shouldn’t and screw things up. If that sort of behavior makes someone stupid, then we’re all taking the short bus from now on.
Also, you’re arguing here in favor of the principle known as “security through obscurity.” Sometimes it actually works — but I wouldn’t count on it.
Because that’s where the things that interest them are?
Look at it like you look at cars: sure you can open the hood and poke around if you like, and it’d be easier if everything were laid out for simplicity, but in the end only a small subset of people want to. Most are content to drive from place to place without ever worrying about anything more serious than putting gas in and checking their oil.
What’s interesting is that Mac OS X is a hybrid of the two.
For your users that would never hit the command line you have:
System
Library
Applications
Users
Volumes
in GoboLinux you have:
Programs
Users
System
Files
Mount
Depot
These more or less match up and it’s only when you dip into the command line in MOSX that you really have to bother with *nix directory structure.
I tend to agree with, Thom and don’t see any real inertia to make things better. Ultimately, I think it would take a new OS project to start there and hope for it to catch fire and gain market share.
I’m the one who said there is no reason to make things better.
Mac OS X gets it’s Filesystem layout from NeXTSTEP. GoboLinux is a copy of it.
Apple has the best way to do it on “Unix”!
Have a virtual file system (Like they used to have in Gnome) and then if you want to go to the command line and muck around you can.
Normal day to day users don’t want to open the hard drive and freak out or get confused. People just want to see the basics.
Yet still on the Mac I can turn on the root account and see everything I need to see. Most of the time even as an advanced user I don’t need to see all the folders in the Linux file system!
Or NeXT before them.
http://books.google.com/books?id=dCczblScSoYC&pg=PA31&lpg=PA31&dq=f…
Yeah your right about that but same Steve Jobs though.
Remember Mac OS came from Nextstep / Openstep after Jobs came back and sold NeXT to Apple.
The ‘My’ in ‘My this’, ‘My that’ is superfluous. I am glad recent Linux distributions (e.g. Ubuntu Jaunty, Mandriva Spring 2009.1) did the sensible thing and by default put folders like ‘Documents’, ‘Videos’, ‘Pictures’ in the /home/user/ directory.
What remains is to pick those as default locations for document saving in certain applications, e.g. OpenOffice Write saves in ‘Documents’, Digikam saves in ‘Pictures’ etc. could be some distributions already do that though?
Personally I am very glad with the attention that is being given by the Linux community to big usability issues as well as smaller details like these.
Also, there is nothing really wrong with the layout of everything outside of /home/.
And if distributions follow the LSB, then it will be much easier to obtain Linux skills with distribution X and equally apply them in Linux distribution Y. I suppose directory names could still be made more human-readable, but I guess the idea in the olden days was that they should be short, e.g. ‘srv’ and not ‘myspankingbrandnewserverdirectory’.
As for /home/ , if it’s easy enough for end-users, admins should be able to figure it out as well…
Oh, they care about %homedir%\local settings\esoteric\esoteric\Outlook\*.pst when Auto Archive eats there mail or Outlook has issues.
Skype being allowed to install under a subdirectory of %homedir% is pretty suspect also.
debian has always been my favorite distro. and, its strengths are heavily acknowledged by the fact that so many other distros are based off of it.
i would be interested in seeing what could be accomplished if GoBoLinux were used as a sort of ‘starting point’ distribution, as well.
could be fun.
edit: fixed typo
Edited 2009-05-28 19:45 UTC
Go for it!
It seems to me that most users really do not need access to the internals of the OS, or anything outside of their home directory. OS X does include the FHS, but its hidden from users unless they go looking for it.
This is for good reason too, a user who doesn’t know any better could inadvertantly delete, move, rename, or alter a file that the OS needs to operate correctly.
It is all well and good to say that computers should be simple enough for everyone to understand, but the reality of the matter is that computers and operating systems are complicated, and it takes a lot of special training to understand what is going on and why. I really don’t think that’s “macho”, its just reality. Can the FHS be improved? Sure, but do 100 random people off of the street really need to be mucking about with system files? Probably not.
So, the real question is not “What should the file system look like?”, it’s “What should the file system look like to the user?”
I think that’s an interesting question, but ultimately why should there be a disparity between the two?
For the most part on Mac OS X, all applications written for Aqua stay within the boundaries of the visible directories and as an administrator you could still do great damage going into /System/Library and deleting some small part…
Heck, how many users know the difference between /System/Library/, /Library/ and ~/Library/?
/System/Library – everything the system needs
/Library – everything the system needs but it’s not critical
~/Library – everything your user account needs
Even if it’s not apparent at first, the users won’t freak out when they see /System/Library. But if they see /etc they do freak out.
If I am a non-technical user, upon seeing “Library” I’d think “I don’t need to read books on this computer, I just want to surf the Internet” and press the Delete button.
Naming system directories like this is nice but I don’t think it helps as much as people here claim it does.
Edited 2009-05-29 11:46 UTC
That has to be the most retarded thing I’ve EVER heard. Millions of non-experienced users use the Mac, which has numerous Library directories. How many of them have deleted it because they thought it had to do with books?
Jesus dude, get out more
.
Edited 2009-05-29 11:52 UTC
Retarded huh? I’ve heard of at least several people who delete everything on their system that they didn’t create themselves and isn’t called “Drivers”. A friend of mine hides his work in a directory called “Windows System Drivers” because otherwise his dad will delete the stuff without looking.
Maybe in the Dos days but if you mean users recently who deleted all but there self created files; why where they able to do so? Doesn’t that indicate deeper problems with the OS design than directory and file names chosen?
Yes it was recently: 3 years ago. The OS in question was Windows XP.
The FHS is forcing us into “spray-on usability” where a simple-looking GUI obscures complex internals when we should probably be working on real usability: making the system internally simple and understandable.
People have opposed every cross-cutting usability improvement (udev, HAL, D-Bus, NetworkManager, PulseAudio, X on tty1 (!), compositing, kernel modesetting, etc.) yet they were eventually made, so there is some hope of fixing FHS. I suspect it would take a strong leader to push it through.
Perhaps if they were real usability enhancements, then people wouldn’t complain.
udev, hal, and d-bus all use weird, esoteric, bizarre config file formats that no sane person can understand. XML for a human-editable config file? Seriously?
networkmanager keeps a completely separate configuration database from the OS config files, leading to two separate (more in the case of wireless) places to configure things. Perhaps on RedHat systems, where /etc/sysconfig/ is a horrible mess, this is an improvement, but on Debian system with /etc/network/interfaces, it’s not. Then you add in all the different GUIs for it, and it’s most certainly not a usability enhancement.
pulseaudio is yet another layer on top of a broken audio foundation. Adding layers does not make things better, it just hides it a little longer.
Having X on tty1 is not hard. Just edit /etc/ttys to disable all the virtual consoles except 1. Done. I do this all the time, to only have 4 virtual consoles, and X on tty4 (ALT+F5).
Compositing has some uses, and can be helpful for accessibility, but not sure how that can be a usability enhancement.
kernel modesetting may be a good thing, so long as the X side of it is done in a portable way (ie don’t make the modesetting/using API Linux-specific, there’s more to the free Unix-alike world than just Linux), and Xorg doesn’t become locked into only working on Linux. If that happens, I’d call it anything but a useability enhancement.
Why do you care? Do you need to edit the config files? For me udev, HAL and D-Bus just work, as they should.
Next up: “Computers are weird, esoteric and bizarre. They operate in base 2 instead of base 10? Seriously?”
Why should I care? I click on the NetworkManager icon, select a wireless network… and it works! I right click on it, select “Settings”, and I’m able to configure my network manually using a nice GUI. Why should I care about your purist view of configuration files?
As soon as you mention “/etc” you’ve already failed. I don’t want to edit config files to configure my network. I want my system to autodetect the settings for me and I don’t care how it stores the settings. The only way I want to configure it is through a GUI.
All this complaining about HAL, udev and D-Bus are only from people who for some reason think that poking in /etc is cool.
Yes, actually I do need to edit the config files, especially for HAL and udev. udev has a horrible habit of locking in interface names to MAC addresses, and depending on the kernel version will re-order the interfaces at boot. Very annoying on our servers with a 10/100 and 2 10/100/1000 NICs … udev keeps flipping which one is eth0. It’s really annoying when you have to replace NICs in systems as well. When there’s only 1 NIC in the system, it should always be eth0, not eth0 one boot, eth1 the next, and so on. If you’re going to use generic interface names like ethX, then don’t rename things behind my back.
What do you do when it breaks? What do you do when you can’t get into the GUI and need network access? What do you do when you have to boot to single-user/safe mode and need network access?
There’s nothing wrong with having a GUI to configure/manage the network setup … so long as it doesn’t break the non-GUI tools that do the same.
Look at apt-get, aptitude, synaptic, adept, and PackageKit for how this can be done right. NetworkManager is just plain wrong.
Which is fine … but don’t break the non-GUI tools in the process. Why is it so hard to grasp that?
Would it really have been so hard to have the GUI write out the config to the normal text files?
People like you are part of the problem. Your answer to a broken system is to say “Paper over it with a simple GUI!” Simple GUIs are great, but a simple system is essential.
What if something breaks and the GUI no longer works? If the underlying system is hard to understand, the barrier to fixing is high. “So what! Normal users call tech support!” I hear this all the time. Where does the mythical tech support guy learn how to fix it? Shouldn’t we make his life easier, too?
Using a simple GUI that papers over complexity is fine for an end user… but what about a third party developer? Making the underlying system complex maks writing software for it complex and bug-prone. The ‘simple’ GUI is not simple to write or maintain if it has to work to overcome the complexity of the system. Sure it *can*, but if the system can be improved it would make maintaining the simple GUI easier, freeing developers to write other useful things, reducing bugs that users encounter while using the simple GUI, improving life on earth.
A better question for you and people of your ilk is “If the user doesn’t need to see it or understand it, why can’t we change it”? You say that it’s fine because the simple GUI works. OK! We’ll leave the simple GUI in place. Now that the children and end users have left the conversation satisfied, can the adults talk? How do we make the system better for the people who have to deal with it.
A benefit to a system that is simple to understand is that more people will learn it and come to understand how the things they use work. Education of this nature is never a bad thing. Keeping things that could be simple complicated creates a priesthood of the enlightened. It’s far better to make enlightenment so easy that anyone can attain it, freeing the masses from a potential oppressive authority.
One of the big problems with Windows is that some parts of it cannot be understood by average geeks, much less by average users. It remains a mystery. This gives people the false impression that they’re stupid, that computers are magic, that some things cannot be known. None of this is good! Yes we could operate Linux this way, but why would we want to?
EDIT: s/ave/have/
Edited 2009-05-31 13:18 UTC
I think you all need to take a step back and get a grip on reality. Its not macho manhood that leads me to believe that most people shouldnt be mucking around in their filesystem. Its based on pure experience. Hell, look at dos. That was about as simple as you could get. And people still screwed it up. You seem to forget that under Windows there is a whole slew of crap that doesn’t make any sense to the common user either. Its not meant for them. Just like anything outside /home is not meant for the user.
Also, do you really think that if GoboLinux became a mainstream linux that people wouldn’t start putting things in different places? The only way to enforce a standard is take away the freedom to change it. That kind of goes against the whole idea of free software. As it is, a standard is just a suggestion. And most creators chose not to stick strictly with FHS. Why would they stick to Gobo?
From
http://www.gobolinux.org/index.php?page=doc/articles/clueless
Well, you could say that the W3C recommendations are just suggestions, but you won’t make many friends among web developers. Wouldn’t it be nice if there was no standard data format? Then again, perhaps you really like the thought of being locked to a single program/vendor.
I could go on, but I’m pretty sure you got the point. Hey, even standards like the FHS might seem futile, but it got a goal : increase productivity and interoperability. If developers were respecting it (and the standard itself was more up-to-date), you wouldn’t have to waste your time finding paths in different Unix-based/Unix-like systems. While learning to do the same thing in many ways develop your learning skills, your capacity to adapt to different situations and even your intelligence, there are times when it’s just stupid.
Again, just think about it. Imagine having to use 4 or 5 different browsers, just because there was no HTML standard… Perhaps that isn’t what you meant to say; that’s why you have to be careful when stating such bold claims.
Edited 2009-05-28 23:20 UTC
I was not implying that having a standard is a bad thing. There are many places where it is beneficial and makes things work. With the FHS, its a standard that is loosely followed by almost every distro. I don’t think it would work being strict as Thom advocates. As for the end user, I think they are the last reason to make changes as the average user should not be mucking around.
I understand where Thom is going with the idea though. And that goal is more user friendly computing. Well, that will happen when the computer becomes an appliance. Like a Tivo. A Tivo runs linux yet it doesn’t expose it to the end user. Now the good thing about that is ease of use. The down side is that it only does what it was designed to do from the beginning. People right now are used to being able to download what ever crap they want off the internet and expect their PC’s to run it. They will not want to give up that power even though it causes them problems every single time. But eventually most people will end up using a thin client like device that just does the basics and is free from malware and viruses. Except for us geeks, we will always have the high end workstations sitting under the desks.
Your argument is stupid:
“That kind of goes against the whole idea of free software”
The FHS is a standard.
Your reasoning would apply to it as well.
The FHS does not allow one to use other locations.
So what is your point please?
If FHS is bad, then GoboLinux’s proposal is TWICE as bad. There are at least some historical reasons behind the madness of FHS… there is NO good reason (NONE) for GoboLinux’s “vision”, except pure ignorance.
Sigh… whatever… plonk this one folks IMHO.
That’s a rather bold statement. Care to back it up?
Yes, there is. However instead of spending 5 minutes reading the GoboLinux author’s rationale you dismiss it without understanding it. Which makes YOU the ignorant one.
I agree with the article. And I think GoboLinux is one of the best under-rated distros out there.
However there is one issue I have with the directory layout — Capitalization. Personally, I prefer all lowercase. I don’t mind capitalization as a visual style, but I don’t want to have to bother distinguishing between the two for the computer’s sake. Here again I think there is a divide between computer geeks and regular people. If you’re Grandmother sees a folder called “mom’s stuff” and later sees one called “Mom’s Stuff”, she isn’t going to be thinking like a UNIX guru that they are different. She’s going to naturally think they are the same.
The only way a new and improved FHS will come about is if Ubuntu, Debian and perhaps a few other big players get together to make it happen. That would be great, but I’m not holding my breath. More likely a new operating system will come along to supplant Linux altogether that will have a better structure from the get go. (AROS?)
Debian wont do it. They are far too stodgy (and that’s a good thing!). Ubuntu might, in the name of friendlinss, but they might not in the name of compatibility.
A new distro could do it. The best bet would be a company like Red Hat creating a secondary distribution just to experiment with the idea; sort of like a research paper done as an OS release. RH has the pedigree to get some notice and attention, the resources to make it happen, the experience to not make so many of Gobo’s mistakes.
It would take years and would never fully replace the traditional FH, no matter what the improvement. Eventually through the grand tradition of ‘if it works better it wins’ the sheer usefulness of an improved FH would gain it devotees, mindshare and eventually dominance–at least among workstation and desktop users.
“A new distro could do it. The best bet would be a company like Red Hat creating a secondary distribution just to experiment with the idea; sort of like a research paper done as an OS release.”
AFAIK no-one at Red Hat has the slightest interest in this. Someone posted a similar Grand Proposal to fedora-devel lately to little enthusiasm. RH developers interested in improving Linux as a desktop operating system (and we have a lot) are generally more interested in doing things that are really useful in obvious and concrete ways than re-organizing the entire filesystem because someone thinks it’d be more ‘elegant’.
Yes, this is largely why Debian wont do it either. But, Red Hat is a company. They could get a bee in their bonnet at a high level and mandate such a change, whereas the DDs would never vote for it.
So, strike the big two.
FHS is messed up because people had different opinions about where things should go. Changing to another system will result int he same arguments that led to the inconsistencies that are in FHS implementations.
But maybe more users would understand the arguments better?
From a previous article I wrote:
—
All three major operating systems today are designed for developers, by developers, and it shows in almost every aspect of computing except the very surface. Developers have stacked layer upon layer upon layer just to make it possible for ordinary people to use these complex beasts we call operating systems. Funnily enough, by providing all these layers, developers actually flat-out admit operating systems are anything but designed for users. If they were actually designed for users from the ground up, they wouldn’t need all those layers. Those layers are the developers saying: “look, we know we have an incomprehensible messy system that even we ourselves barely understand, but instead of actually fixing the problems and making our operating systems better, we’ll just staple another layer on top to hide the ugliness.”
The holy grail of the coming ten years of the operating system world is to make them not only pretty on the surface, but also pretty underneath – logical, structured, human-readable. This is exactly what I’ve been trying to do with my theoretical program management system [1], which I designed from the ground up to be easily usable by all those hypothetical grandmothers, while still offering advanced functionality that no other operating system offers. I strongly believe that this is the next big challenge for developers on all sides – Windows, Mac OS X, or Linux.
We got computers to work. We got them in every home. We got them to be usable. The next big step is to make them manageable.
[1] http://www.osnews.com/story/19711/The_Utopia_of_Program_Management
I’ll try to be diplomatic in my response to this, because I actually agree with you on the fundamentals (i.e. FS layout can be improved) – but what you say here literally makes the hair on the back of my neck stand up…
I’m a developer – I don’t do OS work, but I know enough to appreciate the issues involved. Developers do NOT build layers to hide ugliness – they build layers to allow for change. Its called abstraction, and it is a GOOD thing. You layer abstraction upon abstraction so that, hopefully, if you did things just right and foresaw all the corner cases and your fingers were crossed just so, then you can change/improve one of those layers without bringing the whole thing down on your head.
Developers don’t set out to build unwieldy monsters, but they almost inevitably do. Any non-trivial piece of software that is designed to satisfy an active user base will eventually become a monster – that isn’t opinion, its fact. As a developer, learning to accept that is wisdom. Sometimes its admittedly poor design choices, but most of the time it is simply the act of extending something in ways you did not intend to. Developers can not see the future, although people expect them to be able to.
The point is the only way to construct a file system that is both simple to end users AND logical and functional for a developer AND can withstand changes over time is to build an abstraction, either for the end user or for the developer, preferably both OSX tries to do this admirably I might add – and you dismiss it as a mess.
Trying to “hardwire” a simple design that will serve both audiences and that will stand the test of time is an exercise in futility. Read that again and remember it in 10 years when you nod your head and agree with me.
As the previous poster stated, software developers don’t make layered code just for the hell of it. What happened to hardwired computers? The were replaced by programmable ones because it wasn’t practical to rebuild the entire thing just to change the algorithm it performed. Layered code isn’t always about hiding the uglyness: Jokes aside, it’s a feature, not a bug.
And you can spend as much time as you want designing the perfect system, making sure it’s as simple as possible, but when you finally give the design documents to a software developer, he will most likely implement it with several layers of abstraction. That way, when you find a mess up in your design, there’s a chance of fixing it without breaking stuff on userland. That’s the big difference between design and implementation.
Regarding FSH, yes, it could be improved quite a bit. But is it really worth the massive effort for something the user shouldn’t be messing with in the first place? The fact that sometimes he/she has to do it is a different matter: Blame the userland tool in any case. The fact that network-manager will revert some of my settings (made through the gui) after some time is ridiculous, yes, but it’s network-manager’s fault, not FSH’s. The tool isn’t performing the task it’s supposed to perform.
But yes, we agree, there are quite a few cases when extra layers of cruft are added just to hide the uglyness of the lower layers. PulseAudio being a prime example.
On the other hand, oversimplifying things can lead to painful situations in the future.
Edit: I forgot. Sometimes, developers are accused of reinventing the wheel because, at some point of the development, they decide to rewrite the codebase. And that’s unfair: Most of the times, that’s done just to adapt the code to the new requirements, because the users are always demanding new features / tweaks which the original codebase wasn’t designed to support. And that’s fine, software needs are always changing, but it’s just impossible to come up with the perfect design, specially when the requirements change once the design got implemented.
Edited 2009-05-29 04:30 UTC
BTW, from reading the Gobo author’s stuff, he’s clearly thought carefully about the issues, understands most of them, and knows what he’s doing. Which is fine. One of the benefits of Linux is flexibility, after all. Personally I think the Gobo system requires rather a lot of effort for not much (if any) gain, and I’d rather spend that effort improving other things, but hey – maybe we’ll all agree with them in the end.
What I get tired of is people who jump in without knowing what the hell they’re talking about. Like the type the Gobo author specifically identifies himself:
“Many, many people, when they stumble upon GoboLinux, look at the long, descriptive directory names and say “Look! They changed the Linux directory names by making them longer and descriptive to make the system friendly!”. There is some people who say this as if this were a good thing, and some people who say this as if this were a bad thing. Both are wrong.”
I do believe Mac OS 9 and earlier (the classic Mac OS) got the filesystem structure aspect mostly right.
There was an Applications folder and a System folder in the root level of the HD. To install kernel extensions all you needed to do was drag said extension into the Extensions folder in System (or merely the System folder, and it actually moved it into the right subfolder on your behalf and informed you what was going on). Same for fonts, etc.
It was a very simple system that was self-explanatory, and even the most novice users could actually do these things (install a font or extension). There were no fancy installers needed (although eventually developers did so), and you didn’t have to worry about where to find things as it was clearly labelled (with different icons for each of the important System subfolders).
I’d love for some of that simplicity to return
ROFLMAO
2 words: RESOURCE FORK
“WTF, I can not even begin to count how many times I have to open up the Software Management in Yast to see where the f**k some god damn program installed files. Then I get the joy of having to go through numerous directories to get a job done that would be much simplified if it was installed in “Programs”.”
What job? What exactly is it you want to do? I can’t really think of many cases where our typical under-informed end user would care where a program’s files went, or would have anything in particular he needed to do to them. What’s your use case?
“On Windows, if I install just about anything, I know to go to Program Files if I need to look at a readme, make changes, etc.. THAT is intuitive thinking. Again, pretty damn easy to figure out “Programs” are located in “Program Files”.”
…except for the bits they have to install to \Windows\System32, which as someone else already noted, is a godawful mess. Or the configuration data that gets installed within your personal profile directory (Users and Settings or some such, they keep moving it around), or possibly to the registry.
Hey, starting to sound a bit like that *other* filesystem layout now, isn’t it?
In every major distro, documentation files that are meant to be accessed outside of the app itself get installed to /usr/share/doc . That’s a perfectly sane system.
Actually, it’s a directory called Application Data, stored in Documents And Settings. The funny thing about apps loading and saving stuff to Program Files is that, begining with Vista, changes to that directory requires elevation and, while it makes sense, it produces quite a few headaches and unnecessarily forces users to run the app as administrator.
Oh, I’d forgotten about that one. Actually, we’re both right: that’s yet *another* place where some Windows programs install bits, and some do still install bits into your own personal profile directory. Very badly behaved ones, admittedly. They shouldn’t.
Don’t forget Local Settings\ also in the user’s directory. One of the two (App Data/Local Settings) is a hidden directory as well.
Ultimately, these issues will never be resolved as long as file systems are organized in a hierarchy. The primary disadvantage of hierarchies is that they are only capable of sorting data based on a single factor.
People that prefer the typical UNIX layout like their files sorted by type while those that prefer the Windows/OSX layout want their files sorted into logical groups based on the owning application/library.
Both are valuable views on our file systems, yet we are forced to choose one.
If file systems were to use some sort of relational database instead, we could easily ask for specific views; for example, a list of all the files used by the application “Firefox” or a list of all local configuration files.
We wouldn’t even have to abandon the FHS, because we could provide “smart folders” based on queries into the database. So /usr/local/etc would simply refer to the list of all local configuration files referenced above. Similarly, something like /apps/firefox could refer to all files used by Firefox.
I realize something like this is unlikely to happen, but if it did, it would be a killer feature for me, and would make it really difficult to resist switching to Linux full time on my desktop.
I agree that smart folders would be a better way to organize a file system, but what you described seems to be more or less handled by GoboLinux via symlinks.
The GoboLinux approach is somewhat clever, but “more or less handled” by a ton of fragile symlinks is not really interesting to me.
Plus, it only addresses the two specific scenarios I mentioned, and completely disregards the possibility of custom queries on the file system.
You should probably check out the excellent metadata capabilities of the BeFS. In history, and in the sucessor platforms, mind … *sniff*
Oh for the days when my music library was just a folder in Tracker and not some massive fragile thing iTunes tries to keep in memory …
Sorry, where was I? Oh right, posix extended attributes might help you get most of the way there, too, if anyone started using them for anything much.
The file system style and/or locations of files doesn’t seem that important. The thing that always is a struggle for me is “How am I going to configure this application?” When I used MS Dos and Win 3.1, I had to page through the .ini files. In Win 95 and up, it was the registry and system32 directories. In Linux it’s the /etc directory… As a full time Linux person, I have adapted to /etc for configuration of programs… But it’s very unfriendly… many config files are not human readable and have little to no easy documentation. In comes xml… just one more step, use the web browser for easy to configure applications. Use Nautilus… Add another frame or something that shows an application’s configuration options… MUCH more useful then changing the file system style or locations or names of directories… AND MUCH less confusing for developers.
Linux user since redhat4 here. I understand the history of the FHS, and why each folder exists. I understand there are benefits. I also think it’s an obfuscated, outdated load of crap and there’s no reason why we can’t figure a new structure that has the benefits of the old system, but is innately more comprehensible.
Why bin? Because that’s where your ‘binaries’ are, right? oh, except there are programs now that are text files run through an interpreter, so that doesn’t really apply. A user’s files aren’t under /usr, my webserver by default isn’t under /svr, it’s under /var/www. /etc? Yeah, something about etcetera really says ‘config files’. Seriously, who thought /etc was a good name?
Names have one purpose: to DESCRIBE an object. That’s what the FHS pretty much universally fails to do these days, is accurately describe things in modern, understandable terms. How can anyone argue against making folder names more accurate to what they contain? How is making things LESS comprehensible, better?
I tried Gobo a few years ago and found that a lot of the programs weren’t very stable. Maybe they’ve corrected that, I don’t know, haven’t had a chance to go back to it and play around. I definitely am rooting for *anyone* going back and rethinking some of the ancient eccentricities in the *nix world that should’ve been left back in the 70s.
It’s not worth quibbling over such a distinction. No matter what name you choose, there will be exceptions unless you just want to call it ‘stuff’. ‘bin’ is short, concise and easy to type.
The choice of usr as a name was questionable, but I’m not really sure what else you’d call it frankly. One reason for its existence is that it should be sharable over NFS amongst multiple boxes.
/svr is suppose to be for read-only files. /var is for read-write. That said, almost no packagers actually follow the spec here. Again, /svr is supposed to be sharable via NFS.
The stuff under /etc aren’t necessarily config files. The init system lives in there for one. Yes, while it is used for configuration, the init script are not themselves configuration files. It also often gets used as a dumping ground for ad hoc scripts written by systems admins for backups, reports, ETC (emphasis intended).
I don’t think spelling everything out, capitalization and using naive categorization schemes really adds anything useful. There are 30 years of accumulated wisdom in the current layout. Wanting to throw it all away reminds of me fresh out school CS graduates that always want to throw the existing code base away and start over because everyone before them were obviously idiots.
The problem is that it’s not really 30 years of accumulated wisdom. It’s simply wisdom from 30 years ago. And it provides solutions to problems that aren’t applicable to a modern desktop.
This type of thinking is endemic to Linux development. That’s why every Linux desktop still runs a graphics stack that favors network transparency over hardware acceleration.
But if something has existed in computing for thirty years, it certainly is an asset, not an obstacle.
And Linux is derived from UNIX, the ideal type of a system that has proven itself for decades. Nothing else in the realm of operating systems has had such a profound effect on design and implementation of operating systems.
And here are people like you demanding to destroy tradition in the name of perceived progress, always bringing the mythical Desktop and usability to the table.
Changing a file system hierarchy is not an innovation, and a file system hierarchy should have absolutely nothing to do with a so-called Desktop.
Edited 2009-05-29 06:10 UTC
If you are willing to disregard the significance of the “mythical desktop” and the trouble that UNIX has experienced gaining traction in that space, then there really isn’t much to discuss.
Ironically, the underlying message in my post was that UNIX reactionaries such as yourself are inadvertently sabotaging the chances of Linux on the desktop by resisting any change that may “destroy tradition.”
Though responses like yours give me the feeling that, for some at least, it may not be inadvertent at all.
Please.
Do you honestly believe that file system hierarchies are such an obstacle for the Linux desktop adoption?
In my opinion it is ridiculous to believe that there would be such a silver bullet to any problem that deals with operating systems.
I welcome progress, but not progress because of progress. There is enough skepticism in this thread already and you find plenty more whenever this issue is brought to the mailing lists.
In any case, I value your opinion but refuse to believe that I and others who value the tradition are such an obstacle for desktop systems — actually I think those systems are doing well already. Besides, given that most developers are against this kind of change, you have to purge a whole lot of people that are assumed to be hindrances.
Edited 2009-05-29 10:13 UTC
There is this tiny company called Microsoft – you obviously
need to read up on them and their business practices.
http://en.wikipedia.org/wiki/Halloween_Documents
http://antitrust.slated.org/
http://boycottnovell.com/
… just to get you started
Sir, logic please!!
WinXP is the dominant desktop system.
It still has %systemroot%\system32, regedit.exe
and CP/M Drive Letters.
If our arguments do not require logic, let me
just say “purple monkey dishwasher” and declare myself the winner!
It’s actually 40 YEARS OF ACCUMULATED WISDOM.
I can purge my system of locally compiled software by
simply deleting /usr/local whilst simultaneously causing
no damage whatsoever to the packaged software.
Your statement is pure, concentrated ignorance.
On Windows, if you think for one second that you can rid
yourself of all traces of software by using “Add/Remove”
AND/OR deleting its folder in “Program Files,”
that is just more fantastic ignorance.
You may be right – it’s those darn developers –
they should immediately start thinking like
lawyers, prostitutes and/or carpenters!
On second thought, wouldn’t computing be better off if
we just eliminated those pesky developers altogether?
All of my Linux systems have both.
And I actually use both on a daily basis.
I have and enjoy the best of both worlds, so what’s the big problem?
Please, what is so broken that needs fixing?
I’m going to go ahead and assume that ACCUMULATED WISDOM is not the same thing as accumulated wisdom, since you put in the effort to mash the shift key long enough to differentiate them.
Yes! Everyone I know has just been dying to locally compile a huge collection of software and then purge it all in one fell swoop. Thanks.
I heard that the expulsion of “pure, concentrated ignorance” is a symptom of swine flu.
I searched and searched, but for the life of me, I cannot figure out what you are referring to in my post. I’m fairly certain I didn’t mention Windows at all. Perhaps, through the miracle of the internet, you have contracted my swine flu and are expelling some pure, concentrated stuff of your own.
Prostitutes? What?
This is an example of the problem: http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/
It is absolute madness and is the direct result of trying to shoehorn a modern graphics system into an architecture that was in no way designed to support it.
According to some fraction of the 1% of desktop Linux users, everything is hunky dory. With numbers like that, it must be perfect.
“This is an example of the problem: http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/
It is absolute madness and is the direct result of trying to shoehorn a modern graphics system into an architecture that was in no way designed to support it.”
It’s not that at all. You’re just…entirely wrong. The whole point of the process at the moment is that various frameworks within X.org are being updated and improved – all within the same system that’s worked well for a couple of decades. I’d say that’s pretty good engineering.
Adam, I’d say it’s a pretty remarkable feat of engineering, and I did not, in any way, intend to denigrate the work that these developers are doing. My point is that they shouldn’t have to jump through these hoops and my contention is that they are forced to do so because there are people who are unwilling to admit even the possibility that some bits of UNIX may be in need of modification or retirement, at least in the context of a modern desktop.
The X developers are smart guys and they aren’t ideologically wedded to the X framework. Hell, they already broke from XFree86. If they really felt it was necessary to break things more radically, that would’ve been the perfect place to do it. They didn’t. That should tell you something.
(apologies for any typos, I’m a lil drunk.)
Market Share Trolling – That’s Nice!!
Ahh, statistics pulled right out of the arse –
always the last refuge of logical fallacy.
http://digg.com/linux_unix/GNU_Linux_Desktop_Market_Share_is_4_Gart…
http://news.zdnet.com/2100-3513_22-140314.html
http://www.w3schools.com/browsers/browsers_os.asp
Anyway, back to the grown-up discussion:
I fully enjoy the use of hardware accelerated graphics
AND network transparency every, single day –
all on a filesystem that is *gasp* FHS-based.
What is broken here that needs fixing?
UNIX 101
/etc = eDITABLE tEXT cONFIGURATION
“N_E_X_T_?”
Ever heard of a backronym? This is one.
I seriously think that the traditional unix file system for desktop computer operating systems needs some serious rethinking.
Take a look at the bigger picture.
What does the FHS file system revolve around? Programers. Only software programers. Matter of fact, every stitch of logic in an FHS file system comes from coder / programmer centric thinking.
A better generalized name for this type of file system is a “programer’s tree”.
I think so far what I have written is pretty impartial.
IMHO, a “programer’s tree” is a useless layout except to those who code. It is a coder’s file system meant for coding purposes. Desktop orientated computer users have little to nothing to gain from it. A “programer’s tree” doesn’t concern them, because it wasn’t made for them, and that’s a real problem in a desktop oriented system.
It’s a case of mismatched identity, the system trying to pretend on the surface it’s one thing (a user centric desktop system) when in reality it’s simply a coders workstation, hacked, and wearing a desktop coat.
The underlying issue is… why should a desktop oriented computer have a “programer’s tree” in the first place? Why didn’t more people ask this question from the get go when GNU/linux went to the desktop? Probably because the majority of them were coders, and (like most humans) don’t shift their perspective right way when the situation calls for a new one.
A user centric desktop file system should be built around and logically extend at least partially from a user-centric point of view. IMHO, this means, among other things, that as a whole it should represent the organization of data on physical devices first and foremost.
IE make the top level directories the physical devices. Windows already does this (albeit in an archaik fassion with letters A: and C:), and MAC OS X does it almost perfectly; ie everything starts with Hard Drive, CD-ROM, Flash Drive, etc. Non-coders (ie most users) can grasp their hard drive far more intuitively since folder names are not heaps of abbreviated coder terms, but a smaller set of simplistic, well-organized folder names which anyone can appreciate… Applications, Libraries, Users, System etc…
Making the top level directory / in a desktop computer is completely non-applicable logic. While useful in non-desktop oriented workstations and servers, orienting programer centric folders with a top level / in a desktop oriented computer computer is a unintuitive misfit of an implementation, taken from an entirely different scenario of usefulness and placed in an environment where it just doesn’t belong in the first place.
Edited 2009-05-29 00:53 UTC
I am not really sure what you are getting at. The user’s files are not the topic of this discussion; the system and program files are.
Every modern desktop environment (Windows, OS X, Gnome, KDE, XFCE) shows the home folder (well, My Documents in Windows, but, close enough), a list of devices (with the minor difference that they have drive letters in parens like “(F:)” after them in Windows), and the contents of the user’s desktop as the most directly accessible files/folders. That sounds like what you are asking for — and it is already there.
… and geeks still talk about directory names.
Something must have gone terribly wrong at some point.
I actually wonder whether there is a real need for a hierarchy of “files” at all (not to talk about “programs” with their stupid names and brands, “windows”, “mouse pointers” and all the unbelievably unnatural and, after all, inconsistent metaphors to “talk to” a computer).
I don’t want to troll and I don’t have solutions, I’m just asking myself why on Earth I’m after those ridiculously retro devices everybody owns these days.
I do recognize the hard work and brillant ideas people have had, but I really can’t stand the smell of idiosyncrasies and rhetoric arguments, which in many cases are only useful to make the whole thing even more confusing, as an advantage to “specialized” workers/companies.
Some people do earn from other people’s ignorance, open source or not, you better keep it in your mind!
Just see how the work and ideas of many people these days gets constantly and arbitrarily ridiculed on so many levels: from Gobolinux to Syllable and Plan 9 just to talk about OSes, or the Archy ZUI, Netsukuku or database-like “file systems”… stuff that could really put an end to parts of this whole huge mess IMO.
What we have is really the best we can do? I highly doubt it.
Maybe we need something like an Hippocratic Oath for the IT industry, and/or an artistic/handicraft approach to technology development, rather than new flashy standards talking about the same old crap each and every time.
As a side note, to be less OT, I do prefer the Gobolinux approach, or even better, a sensible default and the opportunity for the user to change the file system structure as he/she likes most without breaking software.
Computers still only understand binary bits… EVERYTHING an OS actually does is extremely difficult for any human to follow… So what does it matter whether the root folder/directory/location is called / or “beginning of file system”… What is important is that the file system and/or OS become easier for the average end user to install and configure programs. Changing the names of every important location involved in a Linux based OS will break many programs and take years of code revisions. It’s really not worth it… As pointed out MacOSX does a really decent job of obscuring the “actual” underling filesystem from the average user. An average user could install a similarly obscured Linux distro… no real need to change what’s not really broken so that it is really broken… and… without a meaningful programmer centric file system Linux would suck to develop apps for… and.. programmers make the modern age possible…
I’m mostly with cb_osn, prime107, and even – oddly – daste, who’ve all nailed it (although in daste’s case he doesn’t quite realize it).
For a lot of people, it seems like they’re attacking the filesystem to solve a problem, except adjusting the filesystem layout isn’t really the way to solve it. If you found your cellphone hard to use for some reason, would you bash the directory layout? Probably not – even though it probably *has* one, at some level, and it’s likely a mess. Why? You don’t really interact with it.
Ultimately, everyone designing operating systems today is trying to avoid typical use cases having to interact with the filesystem directly. It’s not necessary, and if we can really properly achieve it, *that* will be a significant benefit to usability. Trying to rearrange a static filesystem into some kind of perfection that works for everyone is, as cb_osn pointed out, essentially a futile effort. It makes sense to say that what we have now works well enough and serves its purposes well enough that time spent trying to refine it without redefining it is mostly wasted. Work on far more radical changes, which daste mentions in part, is actually more useful. And daste, you’re wrong to suggest that people ridicule things like Plan9 – most developers understand that it’s good to have people who spend time thinking, on a not-currently-practical level, about how we could make fundamental changes to how we design software, to eventually produce big improvements. I suspect that the future of desktop operating systems (as long as they continue to have a future…) will be that the layer you interact with for most purposes really doesn’t come into much contact with the underlying filesystem, just like it doesn’t on your cellphone. And then it won’t matter much how the filesystem’s laid out.
would you listen to yourself? rearranging the file system is futile? we’re in a GOBO LINUX THREAD. GOBO LINUX. the distro that reorganized the file system successfully. hello???
you guys are saying that FHS is complicated, therefore it is hard for normal people to use, therefore fixing FHS is not worth fixing because file systems are hard to use. holy crap. talk about the the cart in front of the horse.
IT IS POSSIBLE FOR THE FILE SYSTEM TO BE EASY TO USE. THAT TRAIT IS VALUABLE TO USERS.
Have you ever changed the engine in your car? Have your ever changed the oil in your car? The tires? Filled up the brake fluid? Filled up the engine oil? The gas tank?
Some of those are easy enough for normal people to do. Some of them are easy enough for nerds to do. The more easy they become, the more value more people get from the product in question.
Have you ever fixed a vacuum cleaner hose with duct tape? Have you ever glued a broken toy back together? Taken apart a pair of headphones to fix them? Tried to take apart a complicated pair of headphones and been UNABLE to fix them?
There is no reason why products should be complicated when they can be fixed to be NOT complicated. Understand yet? Do I need to explain more for you?
It reorganized the filesystem. Fine. What did it achieve? What do Gobolinux users achieve that users of other distros can’t?
Generally when distros do something really useful…they become very popular and you hear a lot about them. Gobo hasn’t. All I ever hear about it is that it reorganized the filesystem. Well, er, good. I don’t hear much about how, in concrete terms, that’s helped people do things better.
The achieve a HUGE improvement in one part of the overall UNIX design.
Really? This is how you think it works? Then Windows must do something really useful…
If it’s not apparent to you, go read their documents.
They demonstrate how things get done better with the reorganization.
But even a simple 1% simplification, generalization and elegantization of the overall design is worth it…
And please ratchet down the rhetoric and the overbearing tone, it’s not doing your argument any good.
I have yet to find ANY non developer type person who has complained about the file system needing to be more transparent to them. From Microsoft users to “new” Linux users (like your 152 year old grandmother), there are very few complaints like… I need a more transparent file system… it’s more like this… I click here and I see a picture from my camera… or… I click here and I can “get to” the internet (whatever that means, I never touch the stuff myself)… The fact is Nautilus or whatever is installed in X Windows hides most of this stuff already… and look at the Debian installation guide under partitioning (almost entirely the home directory)… Seriously, anyone who “needs” more transparency in the file system is computer savvy enough NOT to “need” more transparency… It’s interesting to note in the comparison of OS and cars that as a car gets “easier” to use it gets more complicated “under the hood”… Ever try to diagnose an emissions problem on a 2008 model car with only a wrench… good luck! A carburetor is a rather simple device that works well and is fixable with basic knowledge… a fuel injection system is rather complex incorporating thermodynamic calculations with intake airflow and temperature and engine speed and many other factors being performed instantly and continuously… Complex systems under the hood hidden by a “layer” or “layers” of abstraction is the standard solution to the creation of extremely useful systems…
Then you do not know enough people. Get out of your server room more.
Heck, even do a simple google search for complaints of CASUAL users of trying to install or uninstall or edit this or that thing and needing access to some files in the filesystem, but being unable to find them.
Like, “where’s this foo.ini file the documentation talks about” etc.
Being able to make something more coherent and re-design an 30 year old legacy design to be simpler and more efficient and remove legacy accumulated craft and not doing it IS A CRIME AGAINST COMPUTING.
Mostly due to conditioning and the Stockholm Syndrome.
Just because you “understand” the historical factors inherent in the design of the FHS does not mean that they are justified. It only means that they were compromised people once had to make, and that we now follow due to sheepishness, inertia, and fear of breaking backwards compatibility.
Sheepish adherence to backwards compatibility (and historical craft) is what made Windows an ad-hoc mess, and what keeps UNUX/Linux an adhoc mess.
It can’t possibly be because people need to use those features that have been built in and refined over the years, can it? Of course not, there is absolutely nothing that computers have been used for over the last 40 years that they are still used for today. No, in the world of “tomorrow, Today” they only need to look pretty and check facebook, right?
To Hell with those 1000’s of deployments out there with /usr, /etc, and /home seamlessly mounted over the network!!
To Hell with those 100’s of commercial vendors, 1000’s of System Administrators, 10000’s of certified professionals, 100000’s of package maintainers, and 1000000’s of developers!!
You know better than all of them, right?
Who cares if it screws up compatibility for embedded hospital equipment, assembly line machinery, and the power grid??
Damnit! We must make it easier for
Grandma to grep the filesystem, right?
The FHS is the only filesystem layout design which is sane for now. The main problem about it is the bad developper practice.
The idea of FHS was to have layout where the command ´rm -r $PREFIX/bin/$i $PREFIX/lib/*$i* $PREFIX/usr/*/$i´ will help You getting rid of the software package You don need, and adding ´$PREFIX/etc/$irc /home/*/.$irc´ will purge the package entirely. Everything got worse when four things arrived:
1. the ´/opt´ directory, which is the internal inconsistancy of FHS;
2. the advanced GUIs, where all the GUI software respects its own rules (~/.gconf/*);
3. the nobrainer configuration files layouts (~/.config/*);
4. conflicting convensions (eg. /etc/foobarrc, /etc/foobar.conf and /etc/foobar.d/*).
All these problems have there solutions:
1. get rid of ‘/opt’;
2. add special exception for GUI (like the KDE´s ‘/usr/kde’);
3. get rid of nobrainers;
4. deal the one convension (eg. /etc/foobarrc || /etc/foobarrc/* + /home/.foobarrc || /home/.foobarrc/*).
P.S.: It isn’t reasonable at all to have a human-readable filesystem layout, because the main (and in many cases the only) reader for this layout is computer. The user reads his home directory.
You have your head on straight.
I would quibble about your “nobrainer” bit.
I would support a ~/.config/ as the root for all other config in the user’s home directory, especially if it were named ~/.etc/ or whatever the global configuration root is named. This to me makes sense, if for no other reason then I get tired of having to use find(1) to cp all of my config data recursively. cp -a -R ~/.* oops…
Also, while standardizing on .conf or a -rc suffix would be great, you cannot throw out .d directories. They serve a different purpose, you see, and replacing one with the other would be losing functionality. the conf.d/ style of directory is one of the few real, useful innovations to have emerged recently.
I would also say that the GUIs don’t really need their own directory structure rules, as you allow. This, to me, is a cop-out of the sort that brought us /usr/X11/, which is at long last finally dead. Better to say that if the GUIs want something that cannot be provided consistently with the existing system, let’s amend the system as slightly as possible to add it (without arbitrary exceptions! They have a way of becoming the norm). I suspect few GUIs actually *need* their special structures.
As to your postscript: It *is* reasonable to have a human readable filesystem layout to a certain extent, because the computer after all does not actually care what something is called. Thus, /cfg/ is no diffferent from /etc/ except that it is more human readable. FSH revisions which make things less computer readable are questionable, but ones which improve human interaction and do not interfere with the computer’s ability to use them are fine by me.
1. Running “ls -d /etc/*.d” on my Ubuntu installation shows, that no special idea is included here. And I don have any “conf.d” as I had in Gentoo (I was always amused to see there some loosy configuration files that almost instantly either reffered to oother config (as /etc/conf.d/sshd) or simply replaced some foorc’s. So what is the sacred sense of these foo.d’s?
2. the ~/.config/ directory could happen to have sence if three factors happened to be in place:
* ~/.config/ was a convension – this is not happening;
* the configuration files really needed to be persistant – effectively about half of the setups are irrelevant when switching from one environement to another;
* the configuration files of different versions of software were compartible – not the case.
As a matter of case, You need only some of these, when You migrate, and You really need to get rid of most of them if You want to avoid the bloat.
3. Changing the human-unreadable “/etc” to human-readable “/cfg” (as in every other case with FHS) is completely useless – the user, that know nothing about the content of these direcories shouldn´t be even entering them. Furthermore, it is even handy to have cryptic directory structure to make the human reader aware of the fact that he should get some info before he does anything with his system. Renaming the problem doesn´t solve it.
4. The last thing: I really doubt, that a user can´t understand FHS with its ridiculous mnemonic load, if he understands how to get to the file browser. And even if I´m wrong, I believe nowdays at least half of linux users don´t really know, that thay even have the “/etc”, “/bin”, and atc. directories in there system.
May I presume you are familiar with Apache2? At least as it is configured under Debian. The idea of conf.d directories (and here I use conf as a variable) is that when there may be multiple configuration files or scripts to process that might be added and removed independently of any central authority. Another Debian example would be under /etc/network/if-up.d/, scripts run when an interface comes up. I expect most distributions should have a pam.d, and of course nearly everyone has an init.d or rc.d. The nomenclature is a bit obscure and rather misleading, but it is distinctive.
With regards to ~/.config/, I don’t propose it for any of the reasons you imply. Preserving config data between environments is not very useful and is doable now (see dual booters who mount the same home partition as an example). I’m not sure why configuration for different versions makes a difference here. Does ~/.config/.emacsrc imply a cross version compatibility that ~/.emacsrc does not?
What I want primarily is the non-practical benefit of orderliness. I hate having a zillion directories and files in ~/ that I do not maintain manually. Yes, most of them are ‘hidden’, but they’re there. And I’ve noticed a disturbing tendency for some programs, notably *step related ones, to litter non-hidden directories all over my $HOME.
My other desire is for backup purposes, which I mentioned before.
I can propose scenarios in which you tell a user “Just don’t mess with ~/.config/”, which is easier than saying “Don’t mess with dotfiles. You know, files starting with a dot?” or, on a support forum, “mv ~/.config /tmp/config.backup” as a way of testing whether something is a configuration error.
We disagree here. You say the ignorant should not proceede, I say the ignorant should learn. You say the name is irrelevant, so keeping /etc is fine. I say the name is irrelevant, so changing to /cfg is fine. There may be no practical benefit, but I believe in the existence of some fringe benefits.
No more do Windows users know they have a \windows\ or a \system volume information\. I don’t care about those people and I am not interested in helping them. The fewer people are aware of the underlying structure the easier it is to improve, with fewer negatives, and the more reason there is to do it.
If you can’t see a use to renaming e.g. /etc, then can you cite a down side? Obviously familiarity will be lost, but that is not much. Standards compliance goes out the window, but that was always a given. Most programs don’t hard code /etc/ path references, AFAIK, most users (as you say) don’t even know /etc/ exists now. What is *worse* for those who know and use /etc/ right now to having a new name? If it is not much worse for them then all I have to do is show that it is much better for *someone*, *anyone* and the change is justified.
I do see NO reason to have foo.d/* instead of foorc/*. Anyway, inside are all the configuration files, and distingushing independant configuration files (like in init.d) from splitted configuration files (like in ssh) doesn´t make any sense since to configure either ssh or init script the user must know how to do it.
This was all about the backup facilities of “~/.config”. Moving files around doesn´t imply any compartibility.
What is the difference between having the same zillion directories under ~/ and under an extra ~/.config? Just one unneeded directory more.
That was answered before. I found having separate ~/.config directory only making my backups and transissions harder.
OK, may be we could have a choice here?
Yes, You´ll type a couple of symbols less. Do You really care that? Doubt it.
Every change should worth happening. This one doesn´t.
I have read the above posts and gone to the GoboLinux site to read a bit more there. As I understand it, (and I’m an intermediate-level user not a developer or expert) is that a massive change is being proposed to “fix” the Linux file system. Perhaps my understanding is deficient, but what I have not seen is a demonstration that the file system is broken. Why fix something that is not broken? The Gobo developer’s remarks (which someone linked above) did not seem to be a call to for a file system revolution, either. Those with the need to muck around in /etc, /usr/local /boot or whatever should take the trouble to learn what is where, and why. If not… well, c’est la vie.
Someone who is really interested will take the time and make the effort to learn. I knew 0.000 about Linux, BSD or any other any ‘nix till I was 52 (7 yrs back), but learned enough to function comfortably in Linux and semi-comfortably in FreeBSD -once I made the effort.
The idea that ordinary users would learn more about their “confusers” if only the O/S file system layouts were revolutionized seems implausible. As others have pointed out above, most folks just want the damn box to function predictably-just like their toasters, and have no more interest in O/S internals than toaster internals. I have a friend who is a reasonably proficient Windows user, who has reformatted a hard drive and reinstalled Windows + drivers more or less from scratch (have even 1 in 100 Windows users done this?), but did not know how to delete a file without it going to the Recycle Bin first. That is an above average user.
Interesting idea, but the point really escapes me. Putting xorg.conf .xinitrc or menu.lst in a directory with a different, longer name just makes for a lot more typing if I’m at a command prompt.
Fails for me. YMMV.
People do not respect the history of UNIX anymore?
More than anything else, this proposition would be a change because of change. Sadly, the new mantra of usability is used to promote even this nonsense.
Let’s replace “cp” with “copy” and “ls” with “list” while at it.
You know what, these commands wouldn’t make users so afraid of the command line. I used AROS and had to change the stack size. Guess what? The command was ‘stack’ and not ‘stk’.
People do not respect the history of computers anymore?
More than anything else, this proposition would be a change because of change. Sadly, the new mantra of usability is used to promote even this nonsense.
Let’s replace punching assembly code in cards with abstract languages and keyboards while at it.
(What do you gain by respecting the history of UNIX? [other than making old people feel secure.])
At least you won’t get another Windows!
Please do some reading before responding.
Joel: Why are the Microsoft Office file formats so complicated?
http://www.joelonsoftware.com/items/2008/02/19.html
Joel: Things you should never do part 1: start over:
http://www.joelonsoftware.com/articles/fog0000000069.html
Both carefully explain the value inherent in old, complicated, successful software.
+1 !!!!!
“Those who don’t understand UNIX are condemned to reinvent it,
poorly.” ~ Henry Spencer
OSX uses FHS, but from my understanding, applications are usually installed in a specific application folder rather than having individual parts of it moved to the FHS directory of choice.
I don’t see any reason why we can’t just append the FHS to include an applications folder (/apps) than is for things like GUI applications like /apps/firefox/ and let things like CLI binaries remain in the current FHS location.
I hate trying to track down bits and pieces of an installed application especially when I stray from using the standard package manager to install said applicatiuon and I am not able to check the package manager database for it. This would help solve that.
For the people that are saying people “don’t need to know” where anything outside of /home is, please consider that most people fall somewhere in the middle of the spectrum, not at the ends.
I have yet to meet a single Linux user that never tried to dig deeper than files in /home, so for the sake of sanity could we please stop generalizing the mythical “user” in this way?
There is this perception that the mythical home user needs to know absolutely nothing because they all have a mythical “admin” totally at their disposal with an answer for everything. This could not be farther from the truth.
This complete misunderstanding of who the end user is makes meeting end user needs pretty difficult.
Agreed on Linux users and the general wealth of computer savvy people who brave the Linux world… However, let’s get to the generic computer user… Most of the installed base of the world’s desktop computer users are Microsoft Windows users. During the DOS days Microsoft users were savvy computer people. Now Microsoft users generally know nothing about computers. I have many friends who use computers to play Freecell, write documents, view pictures and videos, and use the internet. They don’t care about ANYTHING else. They think I’m a computer GOD because I can install a new application on a Windows computer. They would NEVER EVER attempt such a tremendously complicated task… I really am not joking. And so, if GNU/Linux really wants to break out of the developer world, application developers need to realize that the APPLICATION needs to present the user with a friendly “intuitive” interface and lead that user “by the hand” to where the user accessible data is stored… The FS need not be changed, nor muddled with at all… IF the FS was broken, then invest portions of the limited programmer resources to fix it…
Example… A few months ago someone at work sent around an email to everyone indicating that if you go into the preferences in Internet Explorer you can actually delete the temporary files that have gobbled up all your hard drive space… Is this problem an FS problem with Windows, a user problem, or an application problem? It’s an APPLICATION problem… the application developer did not inform the user of where the data was and how the stored data could affect system operation…. The example also shows the technical level of the average installed base of computer users.
Edited 2009-05-29 05:42 UTC
Your comment only further reinforces my point. You state that the windows users you know are idiots that never do anything outside of basic tasks. What you overlooked was the fact that they are not Linux users, you are.
Most the people who install and evaluate Linux but decide to keep booting Windows are far more like you and me then the people that view us as guru’s.
I think there is a large number of hobbyists out there who more accurately fit the profile of a potential Linux user than the windows users you described.
I have met /thousands/ of semi technical users IRL who are not just clueless morons who have installed/used/evaluated Linux at some point but decided to keep booting windows for varying reasons.
Maybe your experiences are different, but the majority of the people I know who regularly use a computer are also able to point and click through a windows software install.
If you are designing a Linux distro with idiots in mind that cant click next > next > finish in a windows software install and ignoring hobbyists you are doing it wrong. It is that simple. For the love of god, can we drop the idea that Linux users don’t need to explore outside of /home?
For home computing, user = administrator. Your “admin” installs applications on your home desktop for you like your dentist brushes your teeth for you every morning.
Agreed.
To put it more bluntly: the constant aim to lure these imagined idiot users will lead to idiotic decisions, which will eventually lead to idiot system that can no longer be used for tasks it used to do well.
That is essentially my (admittedly overblown) fear about these crazy ideas that are thrown because of the perceived problems with usability. Changing the FHS is a prime example of this.
Does anyone remember the car designed by Homer Simpson?
There is a clear rational behind Gobo’s reorganization of the file system. Could it be done better? Probably, open to discussion.
“Idiotic decision” is not an engineering term, however, and you do not provide any technical arguments.
What is a fact, and not open to discussion, though is that the UNIX FS organization is a legacy, 40 year old system, and that it was designed with constraints and concerns in mind that do not exist today and/or are not suitable for a desktop system. From shortening the names of folders, to mixing programs in the same directory (/usr/bin) with no concern for namespace separation.
Even the creators of the original UNIX did one better with Plan 9 and fs namespaces. And there are 40 years of FS and usability academic advancements and practical implementations that HAVE NOT BEEN introduced to the legacy unix fs standard.
And again you provide no argument (technical argument) why it is “a prime example”.
HUGE FAIL.
The FHS is not the only example of Linux becoming an idiot box. Nor can windows be used as that. Windows has so many problems. But Linux has as well.
The idiox box is actually superimposed by decision makers, like those that do create Udev/Hal/Policykit crap.
I wouldn’t complain IF their solutions would be dead solid and helpful for the user.
But they f–k him up, and ignore complaints. They are like a global Ulrich Drepper movement against users. And let’s not forget that distributions first try to fix problems for themselves. Many dont even report upstream at all. Now what actually is the real idiot box here? The end user, or distributions who are selfish?
I will gauge what both distributions AND developers do, and comment on it. You have to appreciate good work certainly. But why should you not bitch at bad work or silly standards? Why is it that people are not that happy at glibc for example and that the company that puts most effort into glibc obviously doesn’t care about complaints?
Linux has become an idiot box – it caters to newcomers, it gives them ready-made solutions, it is steered by COMPANIES – or in certain situations by some developers – but if you as end user try to deviate from the official path, you are not only on your own, people will try to convince you that your path is bad and thus wrong. Projects like LFS are a lot more important. But LFS does not go far enough.
Too many advanced Linux users are fanatical people who try to make everyone follow their way. And if you point out that their way has problems, most of them get mad.
Although we may disagree with the issue at hand, I couldn’t have said it better myself. Thumbs up.
I never stated that Windows users are idiots… It’s you that have given those people who find computers in general confusing the title… I know PhDs who are afraid of “breaking” a computer and thus will not install an application or update a computer (click on the gold thing in the task bar) without massive amounts of assistance… These users are not idiots. They simply don’t understand, don’t want to understand, and are generally afraid of the risks of performing tasks on a computer. My position is is the following:
1. The GNU/Linux file system works very well, especially when APPLICATION developers follow the rules for file placement.
2. Anyone who is a Linux hobbyist or Linux developer does not “need” greater transparency in the FS than is already present since the technical knowledge needed to locate “hard to find” files is already well developed.
3. Wasting valuable limited resources tackling a perceived problem versus a real problem is harmful to the overall achievement of real world progress and adoption of GNU/Linux as a general computer user Desktop Platform.
4. The point of changing the FS is muted because there is no way to enforce general adoption of the current rules within the current FS let alone a new FS with “simpler” nomenclature.
5. Stick with the current FS, and develop apps like mad so that GNU/Linux will continue to be better and badder with each release of each distro.
“1. The GNU/Linux file system works very well, especially when APPLICATION developers follow the rules for file placement.”
OK, I GUI ham radio app. where does FHS say I put it?
For a locally installed application, compiled from source: /usr/local/bin, libraries in /usr/local/lib, data files in /usr/share/appname/; for a distribution package /usr/ and ditto. It’s simple enough for any developer to understand, and the user doesn’t need to know.
Hi,
If you have to install things outside your package manager (and please do try to avoid doing that
there are packages to help you do that sanely. One I happen to recall the name of is GNU stow, which will create a folder in /usr/local/stow for each application that you use it to install with all of that application’s files.
This is just a mechanism for using the –prefix option of various tools. The bsd ports systems do this as well, which is why apache is in /usr/local/apache on eg FreeBSD (or was last I looked
hth,
adric
If we’re going to go down this path we might as well go the whole hog and have app bundles and fat binaries like Mac OS X. I know I’ll be shouted down, moderated down and have lies spread about app bundles – people claiming that it ‘duplicates’ libraries when it does no such thing, or uses static linking when it does no such thing.
The problem with programmers is they took Linux and shoe horned it into a UNIX way of doing thing; I’ve never heard Linus ever say, “take my kernel and implement it in a UNIX way of doing things”. It is the surrounding projects who have made this grasp that UNIX is the ultimate and perfect way instead of standing back and saying, “hey, there are some limitations of UNIX, lets be pragmatic”.
Sure, keep the low level directory structure like how Mac OS X has done with the UNIX side of it, but use something better for the user visible portion; user installed applications going in the Applications directory for starters. I’m not surprised if in 10 years time we’re still having the same debate because of intertia and programmers who seem to have the brain of 50 year olds with, “back in the good old days we had UNIX, we don’t need any of this new fandangled ideas”.
new things get into Linux all the time. heck, half the people complain about how stuff is ‘always getting rewritten’ – PulseAudio, DeviceKit, whatever. doesn’t anyone notice the two complaints are completely contradictory? obviously there’s an appetite among developers for shiny new stuff – yet only one minority distribution decided to redesign the entire filesystem. Why? because most developers just don’t see the win. What do you actually get from re-designing things so that all – or, maybe, most, no-one’s ever quite clear on this point – of a program’s files go in one directory? how does it help, exactly? what does it improve?
I don’t know a single person here who has complained about DeviceKit once they realised how much of a clusterf*ck HAL is when compared to how DeviceKit is going to be designed. PulseAudio simply left a bad taste in peoples mouths because it was rammed into distributions riddled from top to bottom with bugs with little being asked as to the merit of it when compared to possible alternatives.
The file structure of Linux goes to the very heart as to the direction of Linux; is it an attempt to be yet another “me too” UNIX clone or is it actually going to stand on its own two feet, throw off the shackles of the past and embrace some new ideas?
shackles? more of this language of constraint…
Where is the limitation? What is it that Unix systems can’t do
because of FHS? – that would be a “shackle”
Are you living under a rock?
Linux is not a “me too” Unix clone –
Linux is THE UNIX CLONE!!
Server dominance plus constantly gaining ground on the Deskop –
The French National Police and the Governments of Cuba,
Brazil, Russia, China, Vietnam and Korea are not just
“sticking with Windows” on the desktop and are not
switching to Mac. Duh – they’re switching to GNU/Linux!
CP/M style Drive Letters are almost as old as Unix.
“Will Windows 7 finally throw off the shackles of the Drive Letters?”
ROFLMAO – Give Me a Break.
AdamW, this is what a decent, self-contained application management system with a decent filesystem layout would look like:
http://www.osnews.com/story/19711/The_Utopia_of_Program_Management
There is no system currently available that allows for such simplicity and power at the same time.
The Linux kernel, eh?
So it implements UNIX signals.
So it defaults to a UNIX compliant filesystem.
So it uses UNIX file permissions.
So it launches /sbin/init as Process #1.
“If it walks like a Duck …”
What are these “limitations of UNIX,” seriously??
You need to prove that there is something Unix can’t do
because of FHS – that would be a “limitation.”
Mac OS X is a broken ENVIRONMENT, period.
I’ll take my Apps in a nice friendly menu, thank you very much.
Why should I have to go poking around in the FILESYSTEM
to launch an App that I only need once in a while??
Why must it try to deceive me so? Those are Folders and I know it!!
Try launching the Firefox Profile Manager on OS X.
All it takes is a simple `firefox -P` on non-broken systems.
The point of view expressed above is so strikingly opposite mine that frankly, just trying to understand the value system behind it comes close to putting me on the verge of seizures. I don’t even kind of relate to whatever leads him to such an utterly alien opinion. Please don’t take any offense; it’s just like stumbling across some guy bitching about physical relations with women because he prefers cats. I mean, what the hell do you even tell the guy?
Personally, I’ve liked the apple applications folder for some time. It’s not what I grew up using; I mostly used windows until I eventually started using GNU/linux in my early twenties, several years before I ever tried OS X. So at least I can safely say I have no “initial bias”.
On a desktop, why deal with directories and nested executables, when your applications themselves can be self-contained packages which serve as folders, executables, and icon-launchers simultaneously. It removes so many needless abstractions. Installation and uninstallation is a simple matter of dragging them to and from your hard drive; it works the same way you deal with mp3s or jpgs. That’s exactly what I want with a desktop computer.
That being the case, what on earth am I supposed to say to an individual who comes along and complains that the applications are not further sub-divided into individual executables, menu launchers, and generic folders and then scattered across the entire file system? That approach involves too many abstractive layers and offers nothing much in return that’s of any value to a simple desktop operating system.
Sure, it really does make sense in certain operating environments where coders desire coder-centric means of organizing every bit and byte according to file type, exclusive of any other ideal. But what, really, is FHS doing in a desktop environment, where its key strengths are not even needed, and where it sacrifices the kind of desktop orientation it ought to be focused on having from the moment of it’s inception?
I think there is a very real need for traditional *nix, which is based upon otherwise solid concepts (such as FHS) that originated entirely in non-GUI desktop territory, to part ways in a graceful manner with desktop oriented computing entirely. I don’t think that the overarching strengths of these two philosophies overlap well with each other. This, I believe, is where the intense double-sided frustration comes from, when software finds that it simply cannot successfully subscribe to both schools of thought at the same time.
To use a simple analogy, treat traditional *nix like an orange. There’s nothing wrong with oranges, they are tasteful and worthwhile for what they are. However, if you find yourself surrounded by orange trees, and discover that what you really have a craving for is apples, then what exactly is the best choice? Attempt to genetically modify oranges into apples? Or consider planting an apple tree? Does an immense history or knowledge of orange tree cultivation play a role in this decision?
Food for thought…
“Food for thought…”
No, it isn’t. The same points have already been made and responded to in this thread. You’re bringing nothing new.
You live in a utopia where apps are (and should be) entirely non-interdependent little bundles. They aren’t, and should not be.
Quick little anecdote on this topic – yesterday I downloaded Handbrake for Fedora. I noticed the download page had only source or Ubuntu packages, and it wasn’t packaged in the Fedora repos already. I also noticed the Ubuntu binary packages were much, much larger than the source – that’s odd, I thought.
So I downloaded the source, read the docs, started it building and watched in fascinated horror as it downloaded and built its own private copies of ffmpeg (which isn’t _so_ unusual, as they’re crappy about doing stable releases, and snapshots are frequently not compatible with each other), a52dec, faac, faad, lame, libdca, libdvdread, libmkv, libmp4v2, libogg, libsamplerate, libtheora, libvorbis, mpeg2dec, x264 and xvidcore.
I did _not_ think to myself “wow, how convenient! Now this app is a neat little independent ball I can stick wherever I like!”
I thought…well, firstly I thought “sheesh, I’m lucky I live in Canada or this thing would’ve just caused me unwittingly to infringe on several dozen patents with no warning whatsoever”. _Then_ I thought “good God, what a hideous ball of…hideousness.” Then I thought “I feel sorry for the sucker who has to manage that build script and pile of patches. No wonder there hasn’t been a release for months and they haven’t built packages for Ubuntu 9.04 yet.” Then I thought “What a horrible mess my system would be if every app that dealt with multimedia built its own copies of all those libraries instead of just using the system ones.” Then I gave the whole thing up for a bad job, didn’t install it, and left it alone.
Jeez.
Yep. Had the same experience. Handbrake is sort of a like a mini Gentoo.
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-Marc…
Perhaps you should look for one damn thing in your 4 paragraph rant that is of concern to –anyone– but coders obsessed with avoiding code duplication. Any one thing whatsoever. It would certainly help all those uninitiated types who download handbrake know what a big mistake they’re making.
The –only– ideal you seem to adhere to is avoiding code duplication across the board. Which is why you ended up with an awful 4-paragraph experience. This in turn doesn’t benefit most people in any real way. You could instead simply drag handbrake to your applications folder, and be done with it.
Give me a 5mb hard drive and I’ll stick with your route. Avoiding code duplication at the cost of everything else might make sense in that sort of situation.
Now consider this. My applications folder contains 55 items. It takes up ~0.01532615 of my total hard drive space (even taking into account the actual binary disc space and not advertised disc space). Roughly one and a half percent of the total. When actual software doesn’t even make a substantial impact on your hard drive in the first place, what does it even matter? Next time I install an app, I’m not going to lose any sleep over what code may have been duplicated.
Edited 2009-06-01 00:03 UTC
The point of avoiding duplication has nothing to do with hard disk space. There are two major reasons:
1) So that, when you fix a bug in some code, it’s fixed for _every app that uses that code_. This is even more important when the bug is in fact in a security issue. If every damn app on your system had a private copy of libpng, every single one would have to be patched when a vulnerability was discovered in libpng. How does that make any sense?
2) Saves on _memory_. Not hard disk space. Memory. Far more important. If every app has its own private libraries, then even if all ten apps you’re running use the same, say, ten libraries, you’ll get ten copies of each library loaded into memory. Owch. If they all use the system copies, you’ll have only _one_ copy of each library loaded into memory.
This is why shared resources are important. And that’s why you can’t just forget about them and make every application its own little bundle.
Complexity is a perceived notion… A problem is always hard until you know the solution… and my favorite… Things are usually where you find them (including files)…….. Oh, and I’m tall for height.
Edited 2009-05-29 06:15 UTC
Why don’t we adapt a “more sensible file system” ? Because it’s not a sensible new filesystem, it’s a hack. That’s why.
Unix distributions have package managers. They are a fairly effective way to hide the complexity of the directory structure. If the package manager does a pretty good job of maintaining the files for you, what’s the point in trying to make it simpler? Don’t fix it if it ain’t broke.
The genius of GoboLinux is to make the file system itself a package manager. This significantly reduces the complexity of the entire system. You don’t need cache files and several layers of programs to manage the files in the file system. When using such a tightly controlled file system, the user feels a solid control over all the pieces of software on his or her computer. (Indeed, there are other approaches to GoboLinux’s use of symbolic links, like using a UnionFS-based package manager, which I have written about here: http://www.linuxfromscratch.org/hints/downloads/files/pkg_unionfs.t…)
So I ask a simple question:
“Why? because most developers just don’t see the win. What do you actually get from re-designing things so that all – or, maybe, most, no-one’s ever quite clear on this point – of a program’s files go in one directory? how does it help, exactly? what does it improve?”
and again I get handwaving.
kaiwai: “The file structure of Linux goes to the very heart as to the direction of Linux; is it an attempt to be yet another “me too” UNIX clone or is it actually going to stand on its own two feet, throw off the shackles of the past and embrace some new ideas?”
Stirring rhetoric – no analysis. There’s no point embracing new ideas just because they happen to be new. What advantage do they bring us?
Thom points me back to http://www.osnews.com/story/19711/The_Utopia_of_Program_Management , which he knows I read and commented on before. It didn’t convince me then and it doesn’t convince me know. For a start, it has a gaping hole: he doesn’t explain how you separate “System” from “Programs”. Aside from this, the benefits he claims are nothing that you can’t do perfectly well within the FHS. There’s no reason you can’t install multiple versions of applications within the FHS; indeed, distributions have packaged multiple versions of the same app in the past, do so at present, and will do so in future. The reason this isn’t *usually* done is not because there’s something about the FHS that makes it impossible or difficult, but simply that it’s sub-optimal practice in creating a distribution, and can have all sorts of ramifications that are best avoided if possible. So it’s only done when there’s a really good and unavoidable reason to do it. Making it ‘easier’ (which it isn’t, really) by mandating that all ‘Programs’ (but not all ‘System’ components, it seems…) be installed as self-contained bundles wouldn’t change that.
foljs: “Heck, even do a simple google search for complaints of CASUAL users of trying to install or uninstall or edit this or that thing and needing access to some files in the filesystem, but being unable to find them.”
this is useless fluff.
“Like, “where’s this foo.ini file the documentation talks about” etc.”
It’s in /etc , or possibly /etc/foo. There. That was ten seconds of education that no-one ever needs twice. Is that *really* worth the gigantic amount of effort that would be required to convert every major distribution to some completely new filesystem? Do any of the proposals even make it more likely that this user would magically be able to find foo.ini without assistance? I doubt it. How many OS X users go looking for foo.ini files? They like OS X because, generally speaking, they don’t HAVE to.
foljs again: “The achieve a HUGE improvement in one part of the overall UNIX design.”
You’re thinking in circles. I’m asking what exactly *makes* it such an improvement. What exactly about it is, practically speaking, better?
“Really? This is how you think it works? Then Windows must do something really useful… ”
When it became successful – around 3.0 – yes, it did. It was a rather better graphical user interface than any other available on PC hardware at the time.
“But even a simple 1% simplification, generalization and elegantization of the overall design is worth it… ”
No, it really, really isn’t. Making things more elegant is always a win *as long as* it doesn’t disturb anyone else. I’ll happily rework my spec files for elegance and efficiency all day, as long as what they generate behaves the same as it did before. But if I could make my spec files 20% more elegant at the cost of the app working differently for the user, I wouldn’t do it, because then I’m inconveniencing them for my convenience. Wasn’t this supposed to be all about the users? You can’t eat (or, more to the point, use) elegance. (Never mind that I don’t see exactly what it is about the Windows filesystem, the OS X filesystem, the Gobo filesystem, or any filesystem proposed in this thread that’s any more ‘elegant’ than FHS).
There’s no hole. My plan is a template. Mac OS X has a separation between system and programs. Windows has it. It isn’t that hard. Every operating system would decide for itself what goes where. In the case of Linux, the LSB could implement it.
My plan allows for flexibility and transparency, and the freedom of users to manage their software in a way THEY want – not some method mandated by the operating system. It also reduces complexity by a large degree, because you don’t need fallible dependency tools, and you don’t require access to repositories – which may not always be readily available, especially in places without internet (and carrying around a disc with outdated repository files is ludicrous).
And I always thought that the UNIX/Linux world was about keeping things simple. Well, I obviously disregarded that thought eons ago, and you just seem to further cement my belief that the Linux world is just as afraid of moving on and true innovation as Microsoft.
Edited 2009-05-29 09:21 UTC
“There’s no hole. My plan is a template. Mac OS X has a separation between system and programs. Windows has it. It isn’t that hard.”
Apparently it’s hard enough that no-one’s yet done it ‘correctly’, because both on Windows and OS X, plenty of ‘programs’ install stuff to both locations. And when they do that, where’s the benefit over FHS?
“My plan allows for flexibility and transparency, and the freedom of users to manage their software in a way THEY want – not some method mandated by the operating system.”
‘Flexibility and transparency’ – of what exactly? We’re into angels dancing on a pin territory here. How exactly is a system based on the filesystem layout significantly better than a system where the location of files associated with a given program is tracked in a database with a perfectly standard and well-known format (i.e. package management systems)? Especially when it’s almost inevitable that the filesystem-based method will be fundamentally broken, because all sorts of programs can *not*, practically speaking, restrict all their files to a single directory, so something else will have to track them anyway?
“It also reduces complexity by a large degree, because you don’t need fallible dependency tools, and you don’t require access to repositories – which may not always be readily available, especially in places without internet (and carrying around a disc with outdated repository files is ludicrous).”
You’re baiting and switching here. You’re talking about applications in self-contained, statically-linked bundles, which really has nothing much to do with the filesystem layout. You can perfectly feasibly do this within the FHS. Hell, you can do it within package management tools – you could build, oh, Firefox into a completely statically-linked, self-contained package which didn’t depend on anything else, then you could perfectly easily give someone that package and they could install it with “rpm -Uvh firefox.rpm”. No dependencies would have to be satisfied, no repository metadata required, no internet connection needed. There would be no need to change the FHS, even if we were all to take hallucinogens and decide that was a really great way to distribute all our software.
“And I always thought that the UNIX/Linux world was about keeping things simple.”
This has nothing to do with simplicity. The proposals just look simple because you don’t fill in any of the lower levels of the tree, and you leave out bits like /sys and /proc (which would have to exist in some form, even if you rename them just for kicks), and no-one’s thought about the difficult cases (Python? Ruby? Tcl?)
Riiight, because no Software Installer in Windows
ever puts files in “C:\WINDOWS” – oh wait, they do!!
Because the backend of ClamXav for Mac OS X doesn’t
go in /usr/local – oh wait, it does!!
FHS, by far, comes the closest to actually having its standards
followed – Mac and Windows are just Wishing in the Wind.
If you can’t live with the built in package manger, maybe,
just maybe, you’ve chosen the wrong distro to begin with.
Because centralized packaged software deployment isn’t
the next logical evolutionary step – oh wait, it is!
Because other companies aren’t all scrambling to repeat the
success of the iPhone App Store – oh wait, they are!!
“Unix is simple. It just takes a genius to understand its simplicity.”
~Dennis Ritchie
“innovation” is a meaningless buzzword –
you seem to have it confused with “progress”
That’s a big giant gaping hole in Linux, not in Thom’s proposed filesystem layout. There’s no such distrinction in a Linux distro, as there’s no such thing as “the OS” vs “the user apps”. Once someone gets the balls to stand up and say “this is the OS” and package it separately from “the user apps”, the FHS will never change.
“That’s a big giant gaping hole in Linux, not in Thom’s proposed filesystem layout. There’s no such distrinction in a Linux distro, as there’s no such thing as “the OS” vs “the user apps”. Once someone gets the balls to stand up and say “this is the OS” and package it separately from “the user apps”, the FHS will never change.”
Oh, please, please, try and do that. I could do with a laugh.
Here’s the first question – is Firefox a user app or part of the OS?
(hint: it’s not as easy as you think.)
It’s been done, by pretty much every OS out there except the Linux distros.
That one’s so easy as to not even be worth mentioning. Obviously, Firefox is a user app, only relevant to GUI installs, and not needed by the OS itself for anything. At least pretend to be trying.
Could an HTML rendering engine be considered part of an OS? Possibly. Could a full-fledge web browser? Definitely not.
Edited 2009-05-29 19:17 UTC
Ah, congratulations, you fell slap bang into my bear trap.
But, to rewind:
“It’s been done, by pretty much every OS out there except the Linux distros.”
someone already tried that. It won’t wash. Other OSes have tried, but they all failed. All sorts of applications on Windows and OS X wind up installing stuff outside of the ‘Programs’ folder, and often in the ‘System’ space. We discussed this further up the thread.
“That one’s so easy as to not even be worth mentioning. Obviously, Firefox is a user app, only relevant to GUI installs, and not needed by the OS itself for anything. At least pretend to be trying.
Could an HTML rendering engine be considered part of an OS? Possibly. Could a full-fledge web browser? Definitely not.”
Aaaaaand therein lies the bear trap.
Firefox is heavily tied to the Gecko rendering engine it contains, and dozens of other apps (on any distro) depend on Firefox being present in order to use Gecko.
Mozilla have been promising to split Gecko out properly for, ooh, years and years now. They still haven’t quite managed it. It’s now more or less split out as ‘XULRunner’ – some distros already have separate Firefox and XULRunner packages, like Mandriva – but in practice, XULRunner still includes all sorts of icky bits that really should be just part of individual web browser applications, not the rendering engine.
And that’s just the _easy_ example – you can argue against that one by saying, well, it’s Mozilla’s damn fault for tying their web browser into the rendering engine and not properly splitting it up. And you’d be right. Still, it leaves you with a big practical problem for your nice neat ‘elegant’ system right there in the single most popular open source application…
Let’s get on to some of the hard examples. What do you when an app provides a library that, say, two or three other apps use?
Well, you can call its library a ‘system component’ and split it out into a separate ‘package’ (or whatever your system is) that gets installed in /System, with just the binary and graphics and whatever going in /Program. And…that’s just like distributions already do with /usr/bin and /usr/lib . What have you won again?
Or you can compile all three apps that use the library statically and keep everything in the /Program folder for each one…but then you lose all the benefits of shared resources. If there’s a security problem in the library, you have to rebuild all three apps (in fact, you have to _know_ that all three apps use that library, and that you have to patch and rebuild them). And if you run two of them at once, both will load their own copy of the library, wasting a bunch of memory.
So…where’s the win again?
And I haven’t even gotten on to the really tricky bits, like…where do your system mail spools go? Where do your logs go? Where does the data you want to serve out via your web server go? (No, it can’t just go in the web server’s Program directory, or in any particular user’s own Settings or Data directories. None of those options makes any sense.)
And…have you looked at how Python, Ruby or Tcl apps and plugins are implemented yet? What do you propose to do about them in this lovely elegant system?
If you want a quick summary of my post: the two ultimate problems with the “let’s have a /System and a /Programs directory!” proposal are:
1) It’s predicated on the idea that it’s simple to split the stuff typically present on a system into ‘user applications’ and ‘bits of the system’. It isn’t.
2) It’s also predicated on the idea that all applications are simple little independent bundles – an executable and maybe some static data used by the executable. They aren’t.
All I have to say, to this big, long-winded, winding, no-point-made post is: look at the BSDs, they’ve solved this quite nicely.
…said like that’s some sort of an achievement. “pretty much every OS out there” is distributed by a vendor, in whose interest it is to define what constitutes the OS. In the case of the Linux ecosystem, what’s part of the OS in one distro is not (and is therefore an application) in another. Out of 25,000 packages, most would need to have dual personalities, installed in a system location for some of the time, and in an application location the rest of the time.
GNU/Linux _is_ different, because it is an ecosystem not an OS.
You don’t want software designed by mere users.
Stop right there. There’s the problem. That whole perspective is the issue several of us have a problem with.
Someone else already summed up the issue quite nicely:
Very well said. Applies to my last 5 years of using *nix systems really well, because I’ve found you almost inevitably have to utilize the file system at some point (and quite often several) whether someone else thinks you ought to or not. Mouse back/forward buttons, getting your graphics to work, hell, even getting videos to play all require a leap into FHS.
Well… geez… I hadn’t thought of that… How do you even kind of counter such a statement? It not only smacks of ignorance, it’s hilariously cocky. You must be absolutely in the dark about why anyone like myself wants to see the FHS replaced with something else in desktop oriented systems. You must really and honestly have no idea whatsoever. Heck, I honestly can not even fathom what you must do with your computer on a day to day basis that warrants such a statement. Such ignorance of any perspective other then your own. Is it that hard to at least toy with someone else’s idea?
Geez. Is this a religion now? I grasp other people’s concepts pretty well, but that statement is just full of wtf… full of axiomic, non-thinking loyalty to tradition that I just don’t agree with one iota.
40 years? I care not. Who the #$%& cares about tradition. Base arguments off of merit alone. Consider just how long some of the crazy religious beliefs you likely disagree with have been around. Consider how the US uses gallons, feet, and miles rather then the metric system. Consider how embarrassing we are going into the 21st century when the norm is propulsion via limited supplies of dinosaur flesh being burned in motors powering convoluted transmissions systems with arrays of gears, necessitating cooling systems and alternators and oil pumps and countless other moving parts which break down and require virtually never-ending maintenance throughout the life of the vehicle. Conservative types (speaking relatively, not politically) can bark all they want about “years of experience”, when all along they could have been developing electric powered vehicles since the day Tesla developed the first AC motor over 100 years ago. It’s well known that they can be vastly more efficient, cost a whole lot less to drive, can easily exceed standard horsepower and torque, have almost no moving parts (other then givens like axels and the AC motor), virtually eliminate smog when used en mass, and can be powered by virtually any source of energy which can be converted into electricity… not just sludge pulled out of holes in the ground. And people are just now starting to warm up to the idea. You get the idea.
In summation, I couldn’t care less about the whole “tradition plays an important role in whether or not something is worthwhile” line of thought.
Edited 2009-05-29 11:11 UTC
Geez.
You are probably the kind of guy who is willing to throw out, say, POSIX and TCP/IP and C99 and whatnot because, well, geez, standards sux.
While your stupidity amazes me, your ability to withstand thinking about my main points for 2 seconds actually makes my nose bleed.
Edited 2009-05-29 17:37 UTC
Electric cars suck! Internal combustion engines rule! Give me a big block Chevy muscle car and cheap American made gasoline and a 1/4 mile! Cars should sound as dangerous as they are as well! Down with the metro-centric ideas of smaller, quieter, more efficient!
prime107: while we’re doing car analogies – this proposal is like saying “jeez, the current layout of car controls sucks. We should turn all the pedals and levers into simple buttons that surround the driver on all sides. What? People have already learned how to drive their cars and are quite used to it? Well that’s just TOO BAD, the new system will be way more elegant!”
“prime107: while we’re doing car analogies – this proposal is like saying “jeez, the current layout of car controls sucks. We should turn all the pedals and levers into simple buttons that surround the driver on all sides. What? People have already learned how to drive their cars and are quite used to it? Well that’s just TOO BAD, the new system will be way more elegant!””
Oh, and while we’re at it – why the hell is the engine under the hood? That doesn’t seem very logical. It should be behind a transparent panel in the driver’s seat so newbies will know how to get at it. What’s that you say? If I’m going to learn enough to tinker with the engine I should be capable of learning that I have to pop the hood to get at it? Tosh! Any idiot can figure out how to fix an engine once they can SEE it, but discovering that you have to pop the hood to find it is just really hard!
the reason why no one uses it is because no one understands it. Users find it hard. i used linux for 2 years. and i still don’t know what all those weird directories are for. and apparently alot of developers have a problem with it.
seriously. they need to get rid of it. they used those short names so that a long time ago people could use a keyboard to easily navigate around. now even if you need to use a keyboard theres tab completion. and most people use a gui. so what they need to do is make a directory called programs. a directory called system. one called users. and be done with it.
So let me get this straight: you are also promoting abandonment of command line interface with this move?
Merry time selling this. Remember to add that no-CLI part to every advertisement.
nope, read it again
The FHS is a joke.
Sabayon has had /usr/kde4 and /usr/kde3 as part of “transitioning” to KDE 4.
This was a clear violation of the FHS, and if Sabayon can use versioned directories already then I wonder why Gobo can not developed the concept further.
However, the FHS is like the holy grail. No distribution really *wants* to change from it, they aren’t even truly compatible to it (see Sabayon), plus the FHS changes over time as well (in the past we had /usr/X11R6 as an exemption from their stupid rules, but this was now changed).
Still, someone explain to me why the Sabayon way is fine, but the Gobolinux way was bad bad bad.
PS: And on Gobolinux “cd /usr” just works exactly like on any other distribution. So what is the point?
Er. You seem to be under the impression that there’s some kind of FHS Police going around enforcing the rules haphazardly.
There isn’t.
Yes, Sabayon broke the FHS. So anyone who relies on it probably wouldn’t choose Sabayon as their distro. I’d consider that a bug, and if I were a Sabayon user or developer I’d have complained about it. But I’m not.
There’s no ‘enforcement mechanism’ for the FHS, distros just stick to it in general because they know it has a significant overall benefit (so people know where the hell to find stuff). There’s no FHS Police.
And, wow, a standard that changes over time? It must be no good! Everyone revert to HTML 1.0 immediately!
I don’t remember anyone above saying GoboLinux (or its filesystem) is bad, much less “bad, bad, bad.” One doubts that many people care.
More problematic is that while there were 5 Gobo releases between late 2002 and 2004, there have been only 3 since, the latest being on 3 March 2009. At the moment, it has the dubious distinction of having older packages (e.g. Firefox, OpenOffice) than Debian Lenny (what I am using to post) or Slackware! 😉 You seem to be a Gobo supporter, what’s the deal?
More to the point, if “new and improved” filesystems like that of GoboLinux or Thom’s proposal are so superior as to be compelling, why has there been no flood of imitators or joiners? People will adopt something with a demonstrable benefit, or simply a perceived benefit–whether it is real or not. It is not like Linux developers and users are reactionary conservatives.
Perhaps the Gobo or a similar system is a genius-level advance that should be adopted by everyone. However, it is not the responsibility of ordinary folks like myself to be geniuses, it is the responsibility of genius to explain and demonstrate its inventions in a way that make the tangible benefits clear to the rest of us.
Rolling release distros tend to have fewer releases.
And while their binary package collection is lagging behind, the primary update method is source based. They have compilation scripts for firefox 3.0.10 and OO.org 3.0.1 in the Recipe database.
Rolling release. Makes a big difference; thanks for the info.
How close to Red Hat (Mandriva specifically) and Debian come to latest FHS standards? I’m finding some differences between the two with Debian closer to rational file and directory use.
/etc/aliases seems a little odd with the rest of the mail related config in /etc/postfix (or applicable mail transport). Beyond that, I haven’t found enything else completely irrational with Deb.
“How close to Red Hat (Mandriva specifically) and Debian come to latest FHS standards? I’m finding some differences between the two with Debian closer to rational file and directory use.
/etc/aliases seems a little odd with the rest of the mail related config in /etc/postfix (or applicable mail transport). Beyond that, I haven’t found enything else completely irrational with Deb.”
I’m a bit confused when you say “Red Hat (Mandriva specifically)”. These are two different distros.
RHEL and Mandriva are both LSB-compliant, which implies FHS compliance (Mandriva has a special lsb package, which ensures LSB compliance if you have it installed). I believe Debian is fully FHS-compliant too. You seem to be labouring under the mistaken impression that FHS canonically defines where every single file on the system must go. Of course it doesn’t, how could it account for systems that weren’t designed years ago when it was written? HTML doesn’t define everything down to the last digit either. No standard does. Standards provide a broad framework for consistency. The FHS doesn’t define exactly how a distribution should lay out its system-wide network configuration files, for instance, it just says they should be in /etc somewhere.
I specified Red Hat and Mandriva as a subordinate due to Debian being a source equal to Red Hat where Mandriva is a second level fork. I haven’t touched Red Hat in years but still recognize the lineage.
The reason for /etc/aliases being different is that under Debian postfix is only one choice of MTA. By default exim4 is used, and you can also install coriour and several others. They may all use /etc/aliases, or not.
Debian has the distinction of having perhaps the most consistent filesystem hierarchy of any Linux distribution. They have a policy, a superset of the FHS, and it is largely enforced. It always bothers me, when I am obliged to use Red Hat or (horror!) SuSE, to see the haphazard and random way in which things are placed. Consistency matters; in Debian it is a bug if a executable is installed in a bin dir and it has no corresponding man page, yet I see this situation constantly with other distributions.
How does that have anything to do with the filesystem layout? It’s just a question of whether you consider it necessary for every executable to have a man page. Which Debian does. It’s a nice feature, but it’s not as if the other distros are doing anything ‘wrong’. Just means Debian’s maintainers get to spend a long time writing man pages for things which don’t have them…
RHEL and Fedora both have a solid filesystem layout policy which is followed. If you find packages in RHEL or Fedora where files are not in the right cases according to the policies, by all means file bugs.
man pages have nothing to do with FS layout and I did not say they did. I said they are an example of consistency, which is something Debian does well.
Consistency is more important than logic when it comes to filesystem layout (in my opinion), so I am implying by this unrelated example of consistency that Debian does/will have good filesystem layout.
Perhaps the FSH on RH/Fedora is not so bad as I imagine, but I have seen over the years a number of strangely placed files on non-Debian distributions. I will say that SuSE is by far a worse offender than RH/Fedora.
All software available via official repositories in Fedora/ RHEL follows the FHS
https://fedoraproject.org/wiki/Packaging/Guidelines#Filesystem_Layou…
If anything that does not, it is merely a bug. No different from what you are talking about.
That was my guess but I wasn’t sure that aliases was used across MTA where virtual and similar config files are specific to postfix.
(Now if I could get rsyslogd to stop shutting down overnight. Somehow I seem to have syslogd and rsyslogd installed thanks to a dist-upgrade from Etch to Lenny)
What is simple anyway?
I find that typing /usr/ takes much less time than typing “C:\Program Files\Ubisoft\Crytek\FarCry\” what do you think? If you really want to ln -s everything into wonderful fairyland newness so be it… but a belief that it makes life simple is simply a belief…
I think FHS is actually pretty well designed for a general machine. There is no reason why _user_ should be able to get to the root of hierarchy in Linux, especially since there is a mount and symbolic links (of which SUBST and ASSIGN are stupid counterparts).
But I have two personal issues with FHS:
1. Configuration files (.*) in home directory; I would prefer something like ~/etc or even ~/.etc for this; but many applications rely on this.
2. Some third-party applications may have problems, if they don’t use package manager. But this isn’t really an FSB problem, as there should be standard API to all package managers which 3rd party apps could use (like InstallShield in Windows).
Not FHS, but there exists the XDG Base Directory Specification, which addresses your point 1:
User-specific configuration files go in $XDG_CONFIG_HOME = ~/.config/ instead of cluttering ~/.?*.
It also specifies $XDG_DATA_HOME = ~/.local/share/, for data resources like user-specific menu entries, and $XDG_DATA_HOME = ~/.cache/.
As far as I’ve seen, the newer programs and toolkits using these XDG directories do a good job of keeping their stuff organized. For example, you can “rm -rf ~/.config/vlc ~/.local/share/vlc ~/.cache/vlc” with confidence that VLC doesn’t have any junk lying elsewhere, and that you’re not affecting any other programs.
I’m a user and I want to use the file system. That is reason enough.
I also want to know how my tools are organized in my tool boxes. Got a problem with that too?
This is much ado about nothing really. Do you really want user poking around in system files.
The minutes users need to understand what is in the directories /usr, /var, /bin, /etc, etc, then the developers have already failed, whether the names change or not.
If the faux complexity keeps the users out of those directories, then that is actually be a good thing, because those people who need to know what’s in there will figure it out, and those can’t figure it out should probably keep out.
Seriously, and operating system is at least as complex as a car, if not more, and no one suggests that car manufacturers start putting more ‘user friendly’ descriptions on the internals, and make it easier for users to poke around. Users should generally only be interested in their home directory, their other storage (usb drives, external drives), emails etc.
Edited 2009-05-29 17:42 UTC
We are not discussing what end users do and do not want. We are discussing what the layout of the filesystem should be. Will you admit that some people have to deal with it? Those people are users, too, and the discussion is about them. Software developers are users and the discussion is also about them. Don’t try and confuse the issue by bringing up clueless grandma-users. They are, after all, a minority on Linux. And, as you point out, what they think doesn’t matter.
The entertaining thing is that most people commenting and implying knowledge of the fhs don’t appear to have read it in any detail as:
/etc is exactly that = ecetera
there was no specific appliaction configuration directory.
The fhs could be vastly improved by simply providing a guideline to move actual system configuration files to a /cfg (or config to give abbreviations a break) and leave the rest of the mess in /etc.
/usr means UnixSystemResources – there is blatantly nothing in there that the ‘User’ needs to handle directly.
I think earlier comments along the lines of programs should be adapatable and be able to find libraries as opposed to standardised locations are notable due to slightly useful mis-feature of confusing the hapless script-kiddie with a few rootkits since they can’t find important files to your system.
Also interestingly the comments regarding ‘Library’ on MOSX also bear relevance to GNUStep too – it too has a whole FHS of its own but thats another story..
Just my 1(0)p
Actually…. the name Unix System Resources didn’t come up until long after the /usr directory. It’s a “backronym”, it was retrofitted. /usr does in fact mean user, because when it was designed, it held user files. But it has since been redefined, and “unix system resources” was some cutesy attempt to redefine it post-facto.
http://en.citizendium.org/wiki/Unix_directory_structure
http://gobolinux.org/?page=doc/articles/clueless
I’ll just say that AmigaOS had the best damn file system hierarchy, and the designers understood that it eliminated the need for a lot of maintenance tools that other OS’es needed, thus making everything even simpler.
This is something the unices have not quite understood and that Microsoft obviously twisted into something they could make money on.
If AmigaOS breaks for some reason, you can fix it yourself by hand, simply due to the design of the file system hierarchy. It takes only a few days to get to the deep end, and know everything and there’s no need to read long HOWTOs, to become a “specialist” in it.
Find me another OS where you would dare to dive into the file system to move around libraries yourself.
It’s a damn shame that every OS designer out there is ignoring this amazing advantage of AmigaOS.
Haiku. It has a very nice, logical directory structure.
>
>
What a load of BS. The Amiga FS was just as fragile as any other OS FS,actually it was even more so because of the cluess cowboys like yourself who ran around screwing up their and other people’s drives, and leaving people like me to clean up the messes they had made because they couldn’t undo what they had done.
Nope, sorry. It’s not true. You could always repair a screwed up AmigaOS installation, except for corrupted disks. Also if you had SnoopDOS, you pretty much always knew what was wrong, if a program wouldn’t start.
A midlevel Amiga user, who has studied the file system can actually build his own working AmigaOS disk completely from scratch, build his own startup sequence and customized set of libraries necessary for just the programs you need.
By hand.
I did that many, many times to squeeze more space onto 880 KB disks, before I got a harddrive. I’m sure many other Amigans have done the same to make custom Workbench disks for very specific purposes. I also did it alot when playing around with WinUAE for a time.
Try that same process with Linux. Build an installation from scratch and see if you have a working computer tomorrow.
One example of eliminating unnecessary complexity through design, is how many operating systems want you to use a special program to determine which programs you want to start on boot. AmigaOS just reads the WBStartup directory. I don’t remember using any package managers either. The GUI based installer was a 50 kb program with a simple scripting language.
Like I said, it’s quite amazing that others are ignoring what AmigaOS could do in this regard, simply thanks to its extremely simple design.
Funny, that’s exactly how sysvinit works. The only difference is multiple runlevels, but those are not strictly necessary. init just goes to /etc/rc?.d/ and executes everything that’s executable in lexical order. Simple.
I’m sure Amiga had many nice things, but this was your only concrete example and it’s not a very strong one.
The deal is that this is not going to change. That doesn’t seem to stop people from posting ~ 200 posts to this thread. True bikeshedding in effect.
What we *really* need is
– More capitalizion
– More extensive use of whitespace like tabs.
E.g. Documents\tand\Settings
This makes the file listing “line up” much better on terminal window.
Hidden files would be preceded by ., AND followed by invisible character (remember ALT+255?)
I’m sorry, I thought this was a discussion of the FHS and how to improve it. I see a lot of people talking about user friendliness and desktop oriented distributions. Why? Solve one problem at a time, please!
If you want a filesystem layout best suited to average desktop users then you want on in which anything ca be given any name and located in any place at the user’s discretion. Mac OS 9 managed a system that worked in practice a lot like this. If that’s what you want, then do it! It’s largely a solved problem.
If you want a filesystem that’s more like a database, where you ask for what you want and don’t worry about how it’s stored, so users can create custom ‘views’ of data any which-way they want… then you want what MS promised but never delivered for Vista nee Longhorn. You can start with BeFS, which does most of this already. It’s, again, mostly a solved problem.
Building a complete OS up around an innovative filesystem is a great idea. Go do it! But, it has nothing to do with a discussion of a revision to the FHS. If you want to solve some other people’s computing problems with a new filesystem or a new system of organization, then solve their problems and leave Unix alone!
If what you want to do is what I want to do, if what you want to do is revise the traditional Unix FHS in a largely additive way, and not throw away the baby with the bathwater, then you are welcome to this topic. We are discussing fixing the FHS, not creating a completely new OS around Utopian user friendly ideals!
I don’t want to hear certain comments; they are not germane. These comments include:
1) “The user should not be working outside of his own home directory. In his home directory the filesystem already has perfectly named directories for what every user needs: Documents, Pictures, etc.”
This line of reasoning is less than useless. We’re not talking about what the user ought or ought not know or do! We are talking about fixing what is, the FHS. In fact, the state of directories within a user’s home directory is a mess, but this is largely irrelevant. We are discussing the FHS, which says about home directories not much or less. Stay on topic.
2) “Users should be using a GUI to configure their systems, not editing config files! They have no reason to know how the system is actually put together.”
Again, a less than useless argument as it is off-topic! Someone needs to know how it works, someone needs to build and maintain it; whoever that person is deserves a system that is designed to work. That person cares about the FHS. Let all those who do not care remove themselves from the conversation, they are not in order.
3) “Other systems are just as horrible with respect to filesystem layout. Look at Windows! system, system32, wow64, etc.. Even Mac OS X just papers over the same problems.”
And just because no one has a good system we should not try to improve the one we build? To the back of the bus, sir, and shut up.
Let us try to be constructive here. Too many times I see discussions of the FHS devolve into useless bickering. The young and impetuous make rash comments, causing the experienced to shout them down. SOme people say throw it all out, it’s useless; they’re decried as ignorant. Others declare that they use it, so let’s keep it; they’re attacked as dinosaurs. It happens every time this comes up!
Can we take a few points as given and work from there?
1) The FHS is not the ideal.
I know a lot of people like it (me, for example) for a lot of reasons, and I know that it has served us for many years. It has undeniable strengths! But, I have not yet met a Unix guy who wont admit frustration with the FHS. Most Unix and Linux guys will regale you with irritations over the filesystem layout of some *nix or other, though usually not his preferred one. There is a problem to be fixed. Let’s start from there.
2) Hiding the problem doesn’t help.
Any answer that solely involves more layers is not an answer but a bandage. Your file manager may hide root by default, but that doesn’t mean it isn’t there.
3) The problem isn’t /etc
Or, rather, not just /etc. Let us not stray in to a discussion of config files, formats, XML and registries. That is a topic for another time. The FHS does not mandate the format of any file, nor should it. Solve one problem at a time or you never get anywhere.
I don’t have all the answers. I don’t have any answers. What I do have is some idea of how we can not get any answers, and that is by the kind of flammable debate I see on this topic. I have some kind of idea of what the form of a solution would look like, so let me outline it in general terms.
1) Throw nothing out.
There are reasons why some of the strange artifacts of the *nix filesystems are still in use. Any solution which fails to account for existing practices is as doomed as Gobolinux’s solution.
2) Friendly names are OK.
In the modern world we have inexpensive output, tab completion and high resolution. There is little necessity to keep our names short. There are vast gains reductions in learning curve to more understandable names.
3) Do nothing radical.
Case insensitivity is the prime example of a radical change that just wont ever fly, but there are others. You can probably make radical changes down the line,f if an initial reform is successful, but making radical and controversial changes at first blush is a sure way to see that nothing new is ever adopted.
I fail to see how ‘Distributions fail to adhere to the FHS consistently.’ and ‘Structures like /usr/bin, /etc, /opt, etc… are unintuitive.’ are arguments for ‘We need something completely different’.
At least in Debian, Ubuntu, and derivatives things seem to be pretty sane. And FHS is specified by the LSB, so theoretically any distribution that wants to be compliant with the LSB should by definition be compliant with the FHS.
If I want system wide config I go to /etc.
If I have to mess with anything in /sbin, /bin, or /lib, I’ve probably got bigger problems than filesystem organization, not unheard of, but not much of an argument for change, these should only be a small number of core things required for the basic operations of the system.
For other binaries and libraries unless an exception is made because upstream design is difficult to fit with FHS, binaries are in /usr/bin and libraries in /usr/lib, upstream design not fitting the FHS could also be considered reason by some distributions to put things in /opt.
Shared icons, wallpaper, system sounds, etc… I look for in /usr/share, program documentation (license, readme, etc..) in /usr/doc.
If I compile a program, I normally expect it to go in /usr/local, but usually I would also expect there to be some documentation indicating that, or failing that just end up with the compiled stuff that I move where I want it to go.
If I compile something and think it might clash with the rest of the system, I choose options to keep it more self contained and either have it go in my home directory or go in /opt, this is what /opt is geared for.
The argument for changing the names of some of these directories seems pretty clear. But the other changes seem like a pretty marginal benefit to the end user and a backward step for the sysadmins and distribution vendors.
Later, Seeker
Except that it should be /usr/share/doc, not /usr/doc
The problem with this conversation is that most participants talk past one another, having separate conversations about different things using a lot of the same words and getting mad when the other guys don’t make sense.
I dare say the fact that the volume of comments on this is exploding – with a lot of them beeing very lenghty ones – proves that this is a serious issue.
To me the mess around the directory structure is one of the main aspects where Unix sucks – big time.
It would be interesting to hear Linus’ take one it. Since a lot if directory names are hard coded into the kernel, there will be no clean solution on Linux unless the benevolent dictator decides to go for it.