Slashdot Mirror
Fedora Aims To Simplify Linux Filesystem
jfruhlinger writes "Even Linux's most passionate partisans will admit that its filesystem, which stashes vital files in a variety of arcane directories, can be baffling to users. The developers at the Fedora project want to cut the Gordian knot and consolidate all executables into /usr/bin and all libraries into /usr/lib or /usr/lib64. One downside: this system would conflict with the standards developed by the Linux Standard Base, or the (rarely used) Filesystem Hierarchy Standard."
The one thing that baffles my mind is that Linux filesystems still don't offer compression of specific folders or files. Seriously, Windows has had this for over a decade. There's a few experiemental filesystems that can compress the whole partition, but still not individual files. Why doesn't Linux have such a simple but important filesystem feature? And no, I don't want to make an archive file, because I want to access those files and folders while they are compressed.
Just store everything in /
What could be simpler?
The developers at Fedora can do whatever the heck they like. Pat knows what he's doing, and that's good enough for me.
Stick Men
/usr/local/bin is not supposed to contain any system executables, only locally installed ones. Fedora does not install anything there already. In any case, /usr/local/ seems to have been replaced by /opt/ in most UNIX installations today.
You can enable some hidden setting somewhere to show hidden files, but then it shows it shows EVERYTHING, including dot files. There's now way to get it to show /bin, etc but not .bashrc and stuff.
I think it's important to realize why the four directions /bin, /sbin, /usr/bin, /usr/sbin exist (and similarly why /lib is separate from /usr/lib).
The reason is that once upon a time discs were small, so that /usr would be mounted separately from the root partition. So /bin and /lib are small directories containing as much of the operating system as you need to get going before you mount /usr and get everything else. In particular, this means the utilities needed to mount those other filesystems and to fix errors in them (e.g. fsck).
The separation between /usr/bin and /usr/sbin means that ordinary users don't have system programs (those from /sbin) in their search path.
Today most installations have the whole system (/ and /usr) on the same partition and it seems that many users use a GUI rather than a terminal. This means that the separation is not needed.
Note that this change is not about multiple-architecture situations like /usr/lib and /usr/lib64. It's about the separation between /lib and /usr/lib (or /lib64 and /usr/lib64).
most passionate partisans will admit that its filesystem, which stashes vital files in a variety of arcane directories, can be baffling to users.
Isn't that [directories] what filesystems are to provide, so things can be well organized ?
Calling them, current UNIX/Linux filesystem hierarcy, "arcane", baffles me. Unless you're Poettering, of course. There is a good reason for things to be where they are, and, due to recent increase of embedded systems, a much more valid reason to split different levels of files across different filesystem hierarchies (read /bin vs. /usr/bin).
I can accept complains about "/opt" and "/usr/local" - they might not make much sense nowadays, but if you happen to need to bootstrap from a read-only 8Mb flash device, and need to have a somehow working system before you access some external data,
or
you have a huge shared filesystem where a few servers rely upon, and you don't want to replicate all system files,
then I see no reason at all to change this.
Actually, perhaps increasing the diversity of directories might come in handy (like in /usr/i686/lib + /usr/x86-64/lib + whatever you might need, and with eventual optimizations, and with eventual debug).
Or is this discussion only about directories which reside on the root of the filesystem ?
the file system hierarchy makes perfectly good sense -- the absolute basics are in /bin, distribution/system stuff is in /usr/bin and anything that an administrator installs for that particular box is in /usr/local/bin. Substitute sbin for sysadmin-y binaries. I guess maybe it doesn't matter as long as it doesn't take off, since I can just not use Fedora ever again, but frankly I like things just they way they are. The weird places that Ubuntu stashes things is already enough of a hassle when you have an extremely heterogeneous environment like I do at work.
Uhh, I want my stuff separate from system stuff. I want to be able to back-up my stuff without including standard stuff.
System essentials should be in /bin. Non-essentials in /usr/bin, and my stuff in /usr/local/bin.
Fedora has jumped the shark.
I agree. I suspect the libraries are the more 'needed' change, but your point is valid even there.
What I'd like to know is what's wrong with the FreeBSD file system, and why don't they just 'do that'? IIRC, everything non-standard is in /usr/local. Some configs are in /etc, but most (all?) non-base configs live in /usr/local/etc. If you blow your system away and have backups of /usr/local and /etc under FreeBSD then you can just reinstall the base system and be 'fine' (aside from the local user files, but that's an obvious restore/backup situation.)
This smells a lot like "we want to do things our own way" (tm). I suppose that's fine, but don't act like you're doing humanity a service by wiping your butt with a different hand ;)
PS: I don't reply to ACs.
As a kindly reader, I'd even put in a note for the editors whilst it was in the firehose queue that this should be "Knot". Not really a major typo and the editors can't be blamed for not reading all the comments, but it'd be good if more people DID pre-screen the submissions and enter USEFUL corrections so that the quality can be improved.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
forget /usr, just do /bin /dev /etc /home /lib /media /proc /root /sbin /sys /tmp /var
Politics is Treachery, Religion is Brainwashing
Although this proposal sounds reasonable at first, actually implementing it is troublesome. Linux systems have an expectation that the root directory / and the /usr directory may be on different filesystems; thus /bin is expected to come with / and be available at boot time, where /usr may not be. This means that making /bin -> /usr/bin via a softlink would break that.
Although the article summary claims that the Filesystem Hirearchy Standard (FHS) isn't used very often, some distributions such as Debian actually do try their best to follow it and even have it as one of the specs for how to build packages. Debian developers discussed the idea of trying to follow Fedora in this proposal, but it looks like it's too troublesome to be worth it. For one thing, all of the filesystem recovery tools or anything else that would be required in an emergency at the command line would need to be built into the kernel initrd images, which could be done but which doesn't seem terribly reasonable.
As such I think most Linux distributions are going to need to wait and see how well it works out for Fedora on this effort.
Why fix what is not broken?
Because sometimes when I install software on Ubuntu I can't find the magic file that makes it run.
I can choose the software I need, I can install it perfectly, and I know how to use it. I also know that some bin directory or other tends to house these things, but somehow that's not always enough - I can't trace the single action needed to make it run.
Call me dumb if you like. But seeing as how I've built my computer from components myself and installed the OS myself I have a feeling it's not solely my fault when I can't find an "executable" on my own computer. Hasn't happened on any other OS either...
(That said the part where they break standards is probably an actual problem with any reform.)
http://www.gobolinux.org/ Combines executables and necessary libraries each in their own directory under '/programs' Uses links to show files in traditional places.
What package manager GUIs are for. There's a lot going on in the filesystem that you'll probably never know or care about. Trying to simplify some at this level of the system for reasons of end-user convenience is just asking for trouble.
Someone had to do it.
This makes sense to me. All those extra directories had historical reasons but time marches on.
It is well-specified. There's a folder for executables, a folder for binaries, a folder for configuration data, a folder for temporary stuff. And its layout hasn't changed for 20 years.
Compare it to Windows, where the file system layout changes from one Windows version to the other, there are no documents specifying most of its organization, and it doesn't matter anyway, because since Windows NT the file system is meant to be only managed by automated installation tools, and even an expert user can not hope to fix it when things go wrong.
What's wrong with /bin and /lib ? They serve a specific purpose, and the files they contain shouldn't be directly handled by a user who gets confused because of the presence of more than a single directory in his $PATH, so who will gain from their "semplification"? Don't tell me the real reason is that Fedora's next-generation self-aware omniscient init system has grown so complex that they're no longer able to support a split /usr installation because of its dependency hell.
Please do not turn Linux into an unmanageable mess as the one Windows has become.
End of rant
> Trying to understand all those folders It hurts the widdle windows users' heads
> since they don't understand why they can't just keep throwing everything in C:\
(dryly) I see you've never visited \winnt\system, \winnt\system32, and the half-dozen or so directories with parenthesized "x86", "64", and/or "wow" that stupidly perverted the entire win64 file hierarchy. Sigh. We finally got symlinks & real directories for \users and \programs, then Microsoft realized its "error" and fucked them all up even worse than before. Sigh. :-(
That '->' in here? That means a symbolic link (ln -s) ...
I think this guy forgot to read his own diagram... if /bin is symlinked to /usr/bin, the scripts will work perfectly fine. This article is a little stupid, imho. In all fairness, the guy does realize that there are workarounds, but this paragraph and the one after talk about complete non-issues.
/usr, /tmp or where-ever to deal with code that hardlinks these locations (which, in most cases should never be required, because you should be accessing 'bin' directories via PATH, and 'lib' directories via LD_LIBRARY_PATH... and 'tmp' directories using the stdlib functions (or a language-specific wrapper).
/sbin has always been stupid so good riddance there. Separating super user executables from normal executables helps nothing in 99% of cases. What matters is the write and execute privileges on the actual executables, not the directory. I believe the argument is that if you want to have tiered write access amongst non-root administrator accounts, with administrators only able to write to /usr/bin but not /usr/sbin, you can do it with SLIGHTLY less work. But really- if everything is written PROPERLY, a simple change to the system's PATH variable, and some time moving the right executables into the more restricted directory will yield an identical result without the clutter by default, and the need for people to explain what sbin is to newbie users.
Many distributions have reworked the filesystem hugely, with some regulo symlinks on
Certainly '/etc' has no standardized variable or way of accessing it other than just hardcoding in '/etc', but this is why we have symlinks.
I agree with the other posts about keeping the boot volume separate from the non-essential OS code volume (/usr). It is there for a reason, not just compatibility. Also,
Also whoever had the bright idea to not have */sbin in the PATH was just retarded. I have no idea what their argument is on that.
When linux gets so simple my mom can sysadmin it with no worries, but I can't get anything done... wtf do I switch to? Corollary: why do we keep fixing things in linux kerneled operating systems that aren't even broken. Just leave the file system alone or you'll end up with Ext5: Unity Disaster.
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
Is it nonsense-week on /. or what?
"Even Linux's most passionate partisans will admit that its filesystem, which stashes vital files in a variety of arcane directories, can be baffling to users.
Errr... no?
First up, you rarely need to dig out those directories, especially not during daily use. A systems administrator may need to venture into /var/lib/whatever occasionally, but a user? Another non-problem created by people confusing their audiences. A system administrator, who needs to know these things, shouldn't be baffled by it, or whatever you're paying him, it's too much. A user, who would be baffled, shouldn't need to worry about it.
There's method to the madness - the mentioned filesystem standard, for example. If you don't grok the method, don't try to "simplify" it. Simplification only works, if you understand the thing you're simplifying really, really well. Otherwise, you're just throwing stuff out, and then say "oh, crap" when you realize much later that you shouldn't have.
Assorted stuff I do sometimes: Lemuria.org
In case you hadn't noticed, the organizational models for /usr/local and /opt are different in a manner similar to the difference between column-major and row-major arrays.
/usr/local/bin contains executables for all local applications. This is convenient in terms of configuring such things as PATH and LD_LIBRARY_PATH environment variables but can easily lead to application name and version collisions. The /opt convention is for each application to reside in its own subdirectory, meaning that multiple application versions can safely coexist, that /opt can refer to a nonlocal filesystem, and so on.
For example,
It's also possible, and very successful, to build hybrids of these two models, but unfortunately there is no convention for doing so. Instead we seem to have regressed to a point where package management supports local software installation only and will not meaningfully install on networked filesystems.
Parity: What to do when the weekend comes.
The thing is, a mac is fine if you're a power user. Unfortunately Gnome and KDE are trying to replicate bits of OS X without getting the foundations laid properly first to make such pieces actually work
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
From my cold, dead hands...
"Flyin' in just a sweet place,
Never been known to fail..."
They address that by saying "There is no way to reliably bring up a modern system with an empty /usr, there are two alternatives to fix it: copy /usr back to the rootfs or use an initramfs which can hide the split-off from the system."
Of course, they conveniently omit the third option: Fix their init system so it doesn't depend on half the software ever written just to bring up a basic system.
Unix wins because it follows KISS. Fedora (and others) have been moving away from that. It's not good.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
No, he is completely wrong about NTFS decompressing the files. It does not, like others have noted too.
As I read the comments for this topic, what stands out is that there are a bunch of arbitrary and conflicting interpretations of the "right" place to put things on a Unix/Linux system, each of which is justified by some sacred "historical reasoning" (even though no one can ever agree on said reasoning).
And that is the problem. Why should I have to know which arbitrary approach happened to be followed by a particular distro or installed package?
I don't have touchy geek pride or a need to whip out my big nerd phallus at parties--I just want the systems I manage or use to be reasonably robust and consistent. I don't care who wins--I just don't want all the variations.
A tablet without a fast wi-fi connection to a honking big server is a serving tray for the beer you're going to go get me.
Finder on Mac OSX hides all important standard Unix directories such as /etc and /usr, and /home is also empty; users are found in /Users.
This makes Finder pretty useless and stops any users learning about the true directory hierarchy. I can see the move to simplify the filesystem as great for newtime users, but it isn't actually that bad as it currently is with lib64 and lib and everything else. Why fix what is not broken?
The unix stuff is behind the scenes, there is no intention to make it necessary for a user to ever become aware of it. The unix stuff is really a secondary environment for those wanting to use traditional unix tools and apps. There was originally debate as to whether the console would even be installed by default, leaving it as an optional install for those who desired it.
if it ain't broke don't fix it! I see no BSOD's here I see no need to reboot everyday Everybody hates success........
I mount /boot, /bin, /sbin, /lib, and /lib64 read-only from a small SSD; I mount /usr on a large HDD. Maybe that's not a good argument, but it's yet another reason I'll probably never use Fedora.
Fedora's excuse for this is that their distro can't boot properly with /usr on a separate partition anyway, so rather than fix that bug so it at least boots far enough to mount that filesystem — like every other distro I've installed with that partition layout seems capable of doing — they're just saying "fuck the standards" and doing their own thing.
As in... nowadays, we don't store movies and music compressed??? What performance and characteristics do you imagine doing by re-compressing a file that already has lossful compression?
Sorry, the AC is completely wrong. That is not the way NTFS works at all, not even close.
what GNU/Linux fork isn't busy screwing with how things have been?
Debian.
Have you got your LWN subscription yet?