Good news from the Linux world. Fedora has announced its intention to drastically alter the file system layout of its Linux distribution. The plan‘s been out for a while, but was brought to my attention by Brian Proffitt (still the best name ever) over at ITWorld. The gist is to move all binaries to /usr/bin, and all libraries to /usr/lib and /user/lib64.
If you want an even more succinct summary of the plan, it’s ‘move all to /usr‘. Or, more specifically, “instead of spreading RPM package content all over the place in the filesystem, and artificially separate /bin from /usr/bin and /lib from /usr/lib, move all content to /usr and provide only symlinks in the root filesystem.”
“For historic reasons, we split-off more and more tools from /usr and put them in /. But, advanced features in today’s systems can not really bootup with an empty /usr anymore. More and more fails in subtle ways in such setups,” the proposal reads, “Instead of moving more tools to /, we today already require /usr to be mounted from inside the initramfs, to be available before the real ‘init’ starts. The split of the root filesystem an /usr serves no purpose in Linux anymore and only complicates or prevents simple and more flexible setups.”
All this is done in an effort to reduce complexity in an installed Linux system.
“Splitting things up complicates stuff. If you want to keep things separate you really need a good reason for that. We should always focus on simplifying things,” Red Hat’s Lennart Poettering wrote, “And merging things into /usr does just that: it drastically simplifies the complexities we have collected over 30+ years of Unix heritage.”
Sooner rather than later, please. While this might go against the LSB and FHS, it sometimes takes a defiant nature to get things moving again. A simpler and cleaner file system structure can only be seen as a good thing.
Thank you, this is something really needed, I hope the other distros follow this move.
Except, why should my OS applications (like ifconfig) be in the same programs directory as my installed applications (like httpd)?
Considering how poorly most filesystems work when you have thousands of files in a single directory, why dump everything into one directory?
While the Linux filesystem hierarchy “standard” isn’t that great, dumbing it down further isn’t going to help. Especially once you add in all the aggravation of having symlinks everywhere to make it look like the “old” way.
Edited 2011-11-02 23:34 UTC
There’s always the difference between ./bin and ./sbin. Both in / and /usr/. Merged or not.
Except they plan to merge them two together too.
On my machine, ifconfig is an “installed application”. I use Arch, which uses iproute2 by default, so net-tools (which contains ifconfig) is entirely optional. The point – your distinction is pretty much completely arbitrary.
Read their rationale for doing this: https://lists.fedoraproject.org/pipermail/devel/2011-October/158845….
I’m sure there’ll be huge uproar from some people, but the rationale does make sense. No matter how you slice it, the distinction between these dirs is already arbitrary. And the “minimal boot system” is nowadays in an initramfs.
The distinction is variable, not arbitrary. It’s different between arch and fedora, but it’s pretty clear on one or the other. Some programs are supplied by default and are always required, some are supplied optionally by the distribution but required under certain configurations, some are supplied optionally by the distribution and are not required to boot, some are installed by the sysadmin from distro-compatible packages and some are installed by the sysadmin from generic packages not necessarily made for the distribution or from source. Each class of binary needs a place to go and ought to be listed separately.
Each distribution can do it differently and that’s okay, as long as internally it’s pretty consistent.
I’ve read the rationale, I’ve read the mailing list thread, I’ve read Lennart’s summary. It still doesn’t make sense, and unnecessarily complicates things with symlinks and over-simplifies things to the point of complexity.
But, maybe I’ve been spoiled by FreeBSD where there’s a real, working, followed filesystem hierarchy (aka hier(7)). And a clear, logical separation between “what’s needed to boot”, “what’s needed to run”, and “third-party apps”.
“what’s needed to boot” is /, /lib, /bin, /sbin, /etc; the kernel, init system, and binaries needed to login and mount stuff.
“what’s needed to run” is the rest of the OS itself, all under /usr
And “third-party apps” are kept under /usr/local.
Nice, neat, logical, and very, very, very useful. It’s too bad most Linux systems don’t work in a similar fashion, and that Fedora wants to takes things to the grand ol’ days of DOS where everything is dumped into one directory.
Ah, Poettering. That explains *everything*.
Yes, I too like the clear BSD hier.
This also makes the FreeBSD jail system quite powerful. All jails share the kernel, and if you want, you can have them share the OS-level binaries too, mounting the same /usr for all jails. This leaves you free to change /usr/local aplications to your hearts’ content in each jail, while still depending on the core OS to remain solid.
In fact, you can even decide to share a specific /usr/local among various jails, so that they can share a common application space. Keep boot, userland, and applications orthogonal to each other!
Symlinks will add a complexity when browsing directories, otherwise no.
If I remember correctly most Linux distributions have that directory structure. The guy that suggested the filesystem change in Fedora is suggesting it since these days Fedora use an initramfs that has all the necesary kernel drivers and stuff to boot the system. While there are still some needed stuff in /bin like the bash, most stuff is in the initram itself. Thus making the old 30+ years definition of /sbin and /bin not that valid in terms of stuff needed to boot the system anymore.
Also people should considered while Fedora is a multipurpose distribution, is desktop oriented. And that FS change IMHO is more towards desktop. Many people should remember the flame when Fedora decided to move X to init1. And is working very good so far.
But I accept, the proposal needs more in-deep analysis, both as desktop and server targets.
My only concern is that with every change (GPL3, init changes, X driver removal, filesystem) Linux is separating itself from other UNIX like systems. Since UNIX derivative market is small compare to others, I prefer if they find a way to work out most of that differences and provide an unified layer where developers will be able to work once, deploy anywhere.
Edited 2011-11-03 17:32 UTC
What could be worse than this mess?
http://imagebin.org/182175
And why would you care if ifconfig is mixed with other files?
They already are, for the most part in pretty much every Linux distro.
This isn’t even a problem with ext2fs on modern system unless you reach tens of thousands of files. Much less for more modern filesystems. Non-issue unless you’re planning on running ext2 on a 486 and dumb a massive amount of extra files in there.
Why is this an aggravation? It’s not like you need to maintain them manually.
Why?
The nice thing about Linux/UNIX is it doesn’t matter were apps are installed, unlike Windows.
But if you really need to dig out the executable, then just which it: http://unixhelp.ed.ac.uk/CGI/man-cgi?which
People make such a big deal about the directory hierarchy in Linux, but I don’t think it really makes a huge amount of difference unless you’re a systems administrator – and in those cases you’d be using tools like the above anyway.
what are you talking about? you can install programs wherever you want on windows
It would be nice if people actually thought a little about the post they reply to rather than just reacting to it
At no point did I say you couldn’t install apps where-ever you wanted in Windows. I just said it matters. In Windows there is no global directory for 3rd party application like there is in Linux. This means everything has to be called for with absolute paths when writing scripts.
Granted you could easily configure Windows to behave a little more like Linux in that regard, but I’m talking about default behavior.
I know none of this is an issue for regular users who just key off installed shortcuts or even on Win7 where you can type the name of the application into the start menu. But equally the different directory structures in Linux is a non-issue to those same kind of users. However to people who do write batch/shell scripts that run utilities not located in (%windows|%system%) nor have their install locations added to %PATH% (which, again, is not the default action for most installers), then it very much matters where programs install to.
Plus Windows Add/Remove programs isn’t perfect, so many power-users are left tidying up directory structures. This, again, is a non-issue with Linux package managers.
So my point wasn’t a criticism of Windows (and thus no need for yourself to get riled up). I was just making a generalisation; comparing Windows administration to Linux administration.
One word: %PROGRAMFILES%
One link: http://technet.microsoft.com/en-us/library/cc749104(WS.10).aspx
One request: Please don’t troll!
%PROGRAMFILES% does not solve that problem. I still can’t just type “firefox” in a cmd window and have firefox launched. I’d have to know what directory firefox is in, even if it’s only relative to %PROGRAMFILES%.
Unless of course I add every programs folder into %PATH% but that’s a bit awkward.
No, but you can type in “start firefox”.
Applications on Windows can register themselves in the “known applications” list, and can then be launched from anywhere with the “start” command (or Start -> Run, or in code using ShellExecute and ShellExecuteEx).
Edited 2011-11-04 05:53 UTC
%PROGRAMFILES% is only a variable name for an absolute path to a top level install directory. Nothing more.
It wont include the full install paths to any application installs (as they will be sub-directories) and it wont work for any applications that install out of that specific top level folder (which may not be the norm, but it does occasionally happen).
What I’m talking about is %PATH%, which holds multiple directories and anything within those directories runs without an absolute path. You could add every single directory for every single application install into %PATH%, but that would be time consuming and could likely screw up other things due to:
1/ length of the environmental variable
2/ access times where the HDD is forced to seek dozens of different directories.
So perhaps you’d want to research a little into your own suggestions before being condensing to others
Is it even possible to have a discussion on here without someone accusing someone else of “trolling” or being a “fanboy”?
*bangs head on desk until it goes numb*
Edited 2011-11-03 15:03 UTC
This is indeed great and long past due.
Still, cue on breakage and hordes complaining about fixing things that aren’t broken…
I don’t have an issue of moving all binaries and libraries under /usr somewhere, but won’t it actually lead to more complexity in the short term? This is because soft-links will have to be left behind in their original places for a while (2-3 years at least?).
Also, here’s some stuff that might be affected by this:
X.org driver libraries (currently scattered around /usr/lib/xorg/modules/* – expected to go in /usr/lib or /usr/lib64 now?)
Third party packages that install their binaries and libraries into /opt/<package> (e.g. Adobe, Google, LibreOffice and Oracle products) – I can’t see them changing their install locations since they’re cross-distro.
Kernel (/lib/modules/*) and pam (/lib/security) modules
A laudable idea in theory, but in practice, it’ll be many years before this could potentially (look at LSB – many distros have either ignored it or not installed it via default after how many years?).
Third party packages installing into /opt are not affected by the proposal. They’re talking about merging /bin and /lib into /usr, not merging *everything* into /usr…
Woot! Woot! Triple woot! It’s about time!
Now, RedHat, go the last yard and adopt the GoboLinux file hierarchy (http://gobolinux.org/?page=at_a_glance). Then the Linux file hierarchy will finally be out the dark ages altogether.
Please, please, please. You can do it!
I can’t agree with you more! I have read quite a bit about GoboLinux – many years back. The file-system hierarchy seemed a lot more “sane” than what we have now.
How can we notify the Red Hat guys about GoboLinux? They could take a look at an actual working Linux distro which uses an alternative file hierachy. Maybe there is something (which I am sure there is) they can learn and take from GoboLinux.
For those that don’t know, here are some more link to what GoboLinux did, and why they did it.
http://www.gobolinux.org/?page=k5
http://en.wikipedia.org/wiki/GoboLinux
Edited 2011-11-03 07:03 UTC
You think they don’t know of GoboLinux? I would be gob-smacked if they didn’t. They have chosen not to do like Gobo. Why? Well it will probably be the old problem when revolution needs legacy compatibility. They you end up having made the problem worse because you still have the old system, but you have a new one too. Gobo still has the “legacy tree” but it hides it with the “GoboHide” hack.
http://wiki.gobolinux.org/index.php?title=The_GoboLinux_Way#The_.22…
There is a reason the Gobo way didn’t catch on. The “legacy tree” is a Unix standard and will be with us a long time yet. Considering it’s age and how it evolved, I think it’s actually quite clean, once you read how it works.
I would be surprised if they did. NIH adversity runs deep in the Fedora project.
I’m sure they do. The Linux community is still relatively small (and was smaller still when Gobo made its big splash). More likely they don’t like the workarounds gobo used to make things still function (and I’m not talking about backwards compatibility).
Why is a certified Unix – Mac OSX – have a different structure and still is a Unix?
OS X still has /bin and /sbin and /usr and so on, they’re just hidden from Finder.
Because POSIX is not about your File System Hierarchy … it is more about system utilities and so forth.
http://en.wikipedia.org/wiki/Single_UNIX_Specification#Specificatio…
Edited 2011-11-03 15:44 UTC
Sure. Or you could just stick with Windows.
This change has nothing to with making things easier for the user though and will not result in anything like the
gobolinux stuff.
I don’t quite understand this obsession with making the the file system hierarchy “simpler”. As a user I rarely ever look at files outside the home directory and when I do it’s almost always on a removable device.
As a developer you need to know a bit more about the hierarchy but the gobolinux changes does not really make a big difference here.
If I was a new admin I might find these alternative hierarchies easier to use but it’s questionable.
Why not focus on making better applications and a better user experience rather than obsessing over something that doesn’t matter much in the grand scheme of things?
It makes sense in the context that Fedora requires /usr to be populated in order to boot today, but the whole point of a separate /usr is to enable the system to boot and be repaired without depending on all of the “applications” to be available.
Root could be small, readonly, and always there as a failsafe. Becoming more monolithic really makes it harder to recover when things go wrong – if your openoffice install corrupts some part of the filesystem tree, you’ll need more dramatic recovery options (eg. boot from CD/DVD.)
These days, we call that “initramfs”. Because if you already have a small readonly version of the system that’s sophisticated enough to mount root from a network filesystem or an encrypted device, there’s not much value in the separate root device at all…
Is initramfs required to boot? Last I knew, it wasn’t.
It is for Fedora.
Strictly speaking, no, but almost all distros default to using them, and you’ll need a fair bit of work to configure the system not to need or use one.
My feelings exactly. The result of moving /bin and /sbin to /usr will be a major clusterfuck. The OS graveyard is full of Unices which did that. Think HP-UX. Oh, and it will make mounting /usr from NFS even more nightmarish than it is now. So I say first implement union directories a la Plan 9 (aufs is fine but doesn’t come anywhere close to that) and improve u9fs, and then screw with the filesystem layout as much as you wish.
Next step would be to have merging directory under /, including $HOME, /opt, etc. (Isn’t what Hurd is supposed to do ?) That would be very nice.
HURD was basicly linking /usr to /.
The whole idea of moving everything to / is incompartible with Red Hat’s effort to share the application and data folder between users – / contains much more.
“Brian Proffitt” is not the best name ever.
“M3 Sweatt” is: http://blogs.msdn.com/b/mthree/about.aspx
“M3 Sweatt” is not the best name ever.
“Max Power” is : http://en.wikipedia.org/wiki/Max_Power
I find the whole thing kind of silly, but if you’re going to do this, why not make it as simple as possible.
/System
/Library
/Programs
/Users
Because that’s too long and complicated to type.
Moving everything to /usr is a nice idea. I just wonder how long before those symlinks in / will no longer be needed. Until then it won’t feel like a real move.
That makes no sense, following your logic to its ultimate consequences, everything should be in /
lowercase, please. shift keys are expensive.
Exactly!
This and many more concerns are answered very well by the GoboLinux creator:
http://gobolinux.org/?page=doc/articles/clueless
When does a user ever type this?
They just select it in a list in the GUI. And the current ridiculous naming scheme is inpenetrable to them. And ugly.
Computers should be made for users and not developers.
CLI users are users too.
Uhmm… all the time.
There exist users other then “users”.
Since it doesn’t matter to dumb “desktop users” who don’t understand anything and just click anyway and it DOES matter to those of us who use the command line, why not satisfy everybody instead of just the philistines?
Obviously because you use a command line and have memorized obscure commands makes you a better human being …
Anyway most shells have tab completion. Even cmd.exe (which is well known for being a bit rubbish) has it (since Win XP). The length of the word is pretty much irrelevant.
The word “System” is pretty clear what it is …
Edited 2011-11-03 13:42 UTC
Again I ask: Since you admit and accept that one class of users doesn’t care and it doesn’t matter to them, and you admit that it does matter to another class of users, what then is the harm to making BOTH sets of users happy?
Tab completion is rather irrelevant to the issue. With or without it I am not touching my shift key. Gobo’s approach of case-insensitive tab completion is just obscene (not to mention dangerous).
What I am saying is that you are making a big deal over nothing …
Also some will be confused if “clicking through” the same folders … so tbh the same criticism is valid both when using a CLI and a GUI.
“What is the /usr thing?” … seriously everytime I see /usr I think U.S.S.R. When I see /etc I think “.etc” not “editable text configuration”.
Overly Terse naming schemes are a constant frustration in my job already thankyou.
LOLWOT … Pressing a Shift key isn’t a big deal, there is even two of them on a keyboard.
Edited 2011-11-03 14:49 UTC
No. I’m making a big deal over something that’s nothing to you. It really matters.
Off topic! We were discussing why the proposed new names should be all lower-case, were we not? Nobody is disputing that the existing names are confusing.
Let me say it again for you very slowly because you and I seem to be having a communication problem: This. Really. Matters. I care. Lots of people care. Pressing a shift key is a big deal. You may not think so, that was pretty clear from the start, but this entire conversation has been about disabusing of the notion that your evaluation is correct. Advocating “/Users” instead of “/users” helps no one and harms some of us. You may not think it’s much harm, but since you are not one of the people it harms you are in no position to judge that. I am one of those people. I am telling you “This is harmful.” You can ignore people like me only if you don’t care to actually get what you want.
Look get some decent tab completion … like in cmd.exe in Windows and it won’t matter either way.
Agree, but it’s trivial to adapt to.
~/.inputrc
set completion-ignore-case On
~/.zshrc
zstyle ‘:completion:*’ matcher-list ” ‘m:{a-zA-Z}={A-Za-z}’
What is simple here? The end user shouldn’t browse / until he knows how that works. and when he learns the principals, the naming simplicity turns out to be the typing simplicity, so /s, /l, /p and /u (respectively) will make more sense. And You forgot /m (local media) and (possibly) /n (network resources).
lolwot!
I give all my variable names in programming proper variables name so when another developer comes along and read my code they might know what the hell was going through my head at the time.
Stupid one letter names would be confusing.
Most shells have tab completion so the length of the actual word is largely irrelevant .. If you have problems typing “System” quickly … I suggest you should invest in a better keyboard.
I actually agree with this hierarchy (available in Mac OS X, PC-BSD and in some extent, in Windows).
Edited 2011-11-03 02:23 UTC
1. “<Shift>First char</Shift>remnant chars” (after all: we’re talking Unix with case sensitive FSs, and not Windows or AmigaOS where that luxury (pain) is absent) isn’t exactly as simple as possible: one of the the few stupid ideas in GoboLinux.
2. You have “library” (singular/collective), and then “programs” and “users” (plural). Non-uniformity is not as simple as possible.
My few rotten cents…
No.
Gobolinux by default uses a version of zsh which is configured to auto-complete regardless of case.
So, the procedure to type “/System” in the shell is simply “/”, “s” and “<tab>”.
On top of that, the captialized names prevent name clashes with standard directories. When GoboLinux was introduced, /sys did not yet exist. People used to complain that Gobo should use /sys rather than /System, but that would have created problems later.
Ok, that might be the case now. But surely the sensible thing is to just lower-case the thing so one doesn’t have to use modification of filesystem x ?
Yes. Such is the case, if “now” means “from 2002 to the present.”
Not sure what is meant by “so one doesn’t have to use modification of filesystem x.” The file system is not being modified.
Using lower-case is sensible in this situation for a few reasons. Bogomipz has hinted above at one advantage of using capitalized system directories, and bogomipz has also linked in another post above to the explanation of the way things are done in Gobolinux by Hisham Muhammad (Gobolinux’s creator). Here is the link again: http://gobolinux.org/index.php?page=doc/articles/clueless
I’m not sure, last time I tried it (4 years ago ?) I don’t remember it auto-capitalize. But then, my memory == RAM…sometimes
Filesystem as in “filesystem driver“. Pardon me and my RAM, or “webcam”, since I have forgotten a thing or two *nix related (z-shell included), I somehow thought “zsh” was a filesystem, even though that sounded really weird that autocompletion would be implemented on filsystem driver level (I deserve rotten tomatos for breakfast).
I have read it in the past.
But regardless, an OS that has /sys and /System “directories” is where Alice belongs. Reminds me of AmigaOS which has SYS:, the system partition, and SYS:System, containing a few percent of core system files (the rest are simply in SYS: >_>). AROS, which I played with a few years ago, now (at least back then) mostly holds GUI related files in SYS:System !
Should the same name be used for sibling “directories” that hold different content ? does that make any sense ? regardless how you “decorate” the names ? /sys and /System, /sys and /system, /_sys(tem) and /sys(tem), /sys(tem) and /Sys(tem)…. WTH ?!
Except that you would not have
/System
/Library
etc.
on AmigaOS. You would use device names to point to relevant directories, eg:
SYS:
Libs:
Devs:
Fonts:
C: (for commands)
etc.
Then it does not matter where you put those directories and you could re-point any of those device names at will.
Took a little while to get used to when if you were a DOS or UNIX head back in the day, but it was a far neater system IMHO. Maybe Linux should use that instead
I know that. I was referring to case sensitivity of *nix filesystems.
Yep.
Because you have to support the Unix standard hierarchy. If you reinvent the hierarchy, you end up having the new one, and the old one. Like GoboLinux. Sure you can hide the old one, like GoboLinux, but that just pretending it’s simpler when actually it’s now more complicated. Windows NT kind of does this and it makes things much more complicated. What I love about Unix is it is simple. Everything is a file and those files are plain to see. It’s all out in the open. The standard hierarchy really isn’t that bad, especially considering it’s age and how it’s evolved, once you read how it works. So tweak it by all means, but don’t try and throw it away, because unless you want to limit what can be run, you will end up with it anyway. As always, evolution not revolution.
Okay big shot, reality check time.
Do you put libraries required by the system under /library or /system?
Where do you put databases?
Where do you put log files?
Do you split up logs for system and non-system components? How?
Where do you put temp files? Is that a /system sort of thing or a /users sort of thing? What if it’s a temp file written by something from /programs – should we write into /system? If they write into /users, which home directory should be used when it’s a daemon doing the writing?
Where does configuration go? If it’s in /system, what about configuration for things that sit in /programs? Do you distinguish them? How?
If I put Firefox in /programs do I put its libraries in /library or under its directory in /programs? What counts as a library? Is it only ELF .so files or can I include e.g. Perl modules and “libraries” of shell code? What do you do about 32/64 bit programs and libs on the same system? Wht about libraries that aren’t meant to be shared?
I could go on. Your idea of utopia is sweet but in the real world would be so much uglier than it appears in your head.
Edited 2011-11-03 12:10 UTC
Have you actually used OSX? The root file system looks neat enough but start making you way down the filesystem tree and you’ll get as lost and as quickly as you would browsing the FHS.
In short: ‘yo dawg, I herd u liek filesystem layouts so we put file system layouts inside your filesystem layouts so u can file while u file’.
Funnily enough, OSX still makes a distinction between core OS resources/programmes and optional ones, with it’s /Library and /System/Library directories (not to forget /Users/*/Library), which is exactly what Red Hat are trying to eradicate.
Anyway, I’m going to voice an unpopular opinion, here and state that I think the DOS style of filesystem layout is a lot better than anything the Unices have offered. The fundamental hierarchy is superior, as it doesn’t lead to weird situations where users have to get their heads around mounting media inside another HDD’s tree (WinNT can do this also but it’s not often used), or dealing with virtual abstractions created by the kernel (eg. linux’s /proc and *nix’s /dev) inside your HDD’s tree.
The obvious advantage of this goofy system is being able to do things like share /usr between multiple workstations over the network but a more ideal solution would still be to symlink /usr (or it’s equivalent) to b:\ (or it’s equivalent).
Eg. the first harddrive should appear as something like:
/devices/drive_a/
While the root filesystem remains simply as an abstraction for stuff like /proc and /dev[ices] (and perhaps a virtual /bin dir that populates with all items from all system paths).
If you’re advocating a user-level UI decision about which things to hide and show then you are off topic, since the article was talking about physical layout. If you honestly think that the OS X approach of just hiding some of the complicated things is the right answer to technical challenges then I welcome you to make the case to the makers of user level software that their UIs should do this.
OS X can do this by (a) using app bundles and (b) meaning something a little different when they say “Library”. If you want to discuss the pros (and holy crap the cons!) of app bundles, you’re welcome to, but again that is off topic. No fix up of the FHS which depends on doing app bundles first is likely to be accepted any time soon by any mainstream distribution. Do you have an incremental proposal to get us there?
You’re right, and I think you’re crazy if you think that the awful CP/M workspace hack is better than the VFS approach. Drive letters actually make no sense whatsoever.
In the first place, even if you did it that would be b:/, in the second place how is this different from mkdir /b:/ ? The answer is that on the Windows side you *STILL* have a root above the drive letters, it just doesn’t seem that way (most of the time). When your system is a special case of my system, my system is better.
It’s entirely possible to revise the FHS to be like this (and I recommend you try it!) I am all for it provided you don’t break anything useful in the process. The problem is that there are broadly two camps: Those who don’t understand the FHS and want to do things like you propose and those who like it and don’t want to change it. A third camp involving people who like it AND want to change it would be useful.
I have to ask: what point do you think I was trying to make? You seem to have phenomenally misconstrued my intent.
The post to which you were replying was suggesting that the OSX layout was the way to go. You quite rightly tore that to shreds but it appears that you didn’t realise where that poster got their layout from. I was agreeing with you, while providing some additional context.
Again, you’re way off base. This wasn’t what I was suggesting at all.
Agreed.
Well no, it wouldn’t be but I digress.
Well for starters, you’d have a static directory sitting on a HDD partition, somewhere.
Except it’s all virtual; Windows doesn’t throw it’s it’s VFS and the OS partition in a blender.
Except, for the purposes of spitballing, I’m really not concerned with backwards compatibility. As for use cases supported, for something like the following, can you see any specific limitations?
______________________
/bin (symlink/merge of all bin/ directories on OS volume)
/boot (symlink to OS volume: /devices/storage/drive01/volume01/)
/devices/
..storage/
….drive01/
……volume01/ (first hdd, first partition, OS location, first non-virtual part of filesystem tree)
……..user/ (optionally symlinked to /devices/drive02/volume01/)
……….username/
…………bin/
…………libraries/
…………config/
……..system_files/
……….bin/
……….libraries/
……..optional_files/ (optionally symlinked to eg. /network/compname/storage/volume01)
……….bin/
……….libraries/
……..temp/ (temp files and logs)
……volume02/
….drive02/
……volume01/
/network/
..compname/
….storage/
……volume01/
……volume02/
/proc
______________________________
Just a half-arsed effort on my part. Obviously would put more than 5 minutes thought in to it, were I about to go and write my own OS.
The OP was suggesting that we simplify even further than the article describes and proposed a scheme that closely resembles OS X. However, while it’s easy to say “Just make it simple” it’s hard to do. I was attempting to explain why the real world isn’t simple (and how OS X gets away with sometimes pretending it is). You came in talking about what the user sees, but that’s not the topic of the article that started all of this and thus not what we were discussing. The article is talking about physical layout, so AFAIK the OP was talking about physical layout, so I am objecting to an oversimplification of physical layout and you are saying “But physical layout doesn’t matter, only what the user sees matters”– but the topic is changes to phsysical layout! Now *I’m* confused. What the user sees is another topic, how it actually works is what I care about (and what we are, AFAIK, discussing).
Whether OS X is what the OP modeled his naive suggestion on, or not, is not important to me since it ignorantly omits the hidden directories. If the OP would care to chime in and clarify whether he was intending for those hidden directories to exist, that would be helpful.
The entire world uses forward slashes to delimit directories at this point in history, except for systems which spiritually inherit from DOS, which had already used forward slash for its switch character. To continue using backslash is just silly. The use of backslash on Windows is itself essentially unnecessary and is only kept around (AFAICT) “Just in case” something is installed which might break it. Windows has supported forward slash for directories for a long time. Proposing the (re)introduction of backslash in a non-legacy context is crazy, so it would be b:/
Side note: If you were really going to do this you should use drive labels and not arbitrary drive letters. Like “system:/” and “my thumb drive:/” – makes more sense these days.
Then make the “static” directory be managed by udev or something like it and appear and disappear as needed. Automounters are perfectly capable of doing this today.
I’m really confused by this. You advocate simply hiding the real VFS root from the user? I don’t see how this helps; your original complaint was about how confusing it was, but you can make it less confusing with simple UI gimmicks and a sprinkling of policy without requiring any fundamental change to Unix. Why throw out the VFS when it can be used to implement exactly what you want without nearly as much effort as starting again?
I’m sorry, I thought we were discussing actual, practical real-world things that Fedora might actually be able to do within the next 2-3 release cycles to actually improve real FHS issues on a real mainstream distribution, both as they relate to packagers and sysadmins. I wasn’t aware that you were off on some tangent about what might be a nice design in theory for a new system someone could build.
A second reply for the other topic in your post – your new FHS.
I’d say that I generally like it, modulo (as you point out) the fact that it’s a five minute kind of job.
I like having a network root in the VFS; this is definitely where Unix faceplants pretty hard and Windows (and Domain OS) do well.
I’d certainly want to discuss the virtue of your /bin idea; I’ve tried to do that before but I don’t know how to make it work.
I certainly don’t like the FS roots to be inside the device tree; that makes some things simpler to understand at the cost of making everything harder to manage. The VFS is really good for seamless hardware migrations, which you throw out for no good reason. It would be okay if you could map physical hardware into logical components that don’t change and then base your heirarchy on top of that, thus.
/devices/
..storage/
….disk01
and then logically map disk01 as being part of MyAwesomeVolume
/system/
..MyAwesomeVolume/
….home/
and so on. That would be only a little more complex and a lot less breaky when the 2T disk01’s data is migrated to the 20T disk02 at some point in the future (and then disk01 is used to serve some other part of the fs).
Whatever usability you gain it’s important not to lose this kind of flexibility.
I agree. It time to move the file/directory system out of the last century.
You should have it as /Applications and /Programs since it would help guarantee that the programs show up first if sorting alphabetically. Also you would always have symlinks to the traditional file system that you can use.
Just remember include files, logs, temporary files, configuration files (both systemwide and per user), cache files, the possibility to mount some directories on a speedier drive etc etc
… and save the effort.
While I have nothing against simplicity or change, I am not sure I like this. These folders were separated out for reasons. While I guess it makes no difference if you combine /bin and /sbin these days, why put everything under /usr? That doesn’t change anything. You are just adding one more layer into the path of any file while breaking pretty much everything in the process. Is there really a difference between /lib and /usr/lib? Seems like a lot of work for minimal gain.
i typically have /bin, /lib, boot and /etc on one partition. I keep /usr on another (on lvm). It allows me to have a minimal bootable system for recovery.
Yes, they were, and the Fedora page addresses that. They were separated out to be able to boot before /usr is available. That can be easily taken care of by initramfs today, so there’s no justification for keeping lots of stuff in /bin, /sbin etc. these days.
/usr has a long tradition of being for stuff that should be possible to mount read-only from a directory shared amongst multiple servers, so it makes sense to try to keep as much as possible of the system there.
As long as I can easily see the filesystem, organise it however you want. Like multiarch there are some valid reasons for doing thise.
/run caused enough controversy so why not just update everything?
Luckily /run was an easy change. Imagine trying to change everything? You would never be able to and run everything, so you end up with the old system hidden away in the background. Is that simpler? I don’t think so. You going to get everyone to agree to the new hierarchy so you can phrase out the old system? I don’t think so, so you will be stuck with both systems forever. To be clean, you either do revolution and straight up front say you won’t support old apps, or you do evolution and do incremental improvements.
Indeed. And there’s a lot of evolution to be had. I’d start by nixing sbin and games.
mv /usr/games/* /usr/bin/
mv /usr/sbin/* /usr/bin/
mv /sbin/* /bin/
And see how that strikes people. At this point in history these things make no more sense than /usr/X11/ did.
This is just a proposal, not a final decision, fortunately. A user doesn’t have to know where the binaries are installed, everything he needs to execute in on his $PATH. On the other hand, the people that need to know the difference are called System Administrators and they know why the current separation exists. There are very good reasons for it.
Yes, and the OSAlert doesn’t make that clear at all. There’s currently nothing more than a discussion of what would be involved and whether it would be a good idea – not a decision to go ahead and do it.
There’s also separate two issues involved. One is the merging of bin and sbin directories, which is relatively uncontroversial. The second is removing all applications and libraries from / to /usr, and that’s the subject of most of the argument.
Yes, this is exactly correct. This is only a feature proposal. Anyone with a Fedora account can make a feature proposal; all the existence of a feature proposal proves is that one person with a Fedora account thinks something would be a neat idea.
It’s not a Fedora feature unless it’s accepted by FESCo after their review process.
God, I hope this is in fact the case. Fedora *DOES NOT* need a repeat of the Gnome 3 Disaster.
I applaud this and hope it is the first step towards a simpler, more organized, and modern operating system.
Anyone against this decision is no friend of Linux and should be “mv’d” to “/dev/null”.
why not
/sys
/lib
/app
/user
better for typing !!
Yeah, since the file-system is case-sensitive definitely go the path of least resistance and make the standard all lowercase.
I’d choose /programs and /users (plural) instead of /app and /user, respectively.
/sys already exists and is mounted as sysfs, so I’d choose /system as the actual os dir in order to not clash with the existing /sys. I’m guessing /selinux, /boot, /dev, /proc, and possibly even /tmp could then get moved under /os. You could also even move /sys (sysfs mount) under /os. All of these changes would, of course, initially provide appropriate symlinks for backwards compatibility.
/lib is an interesting folder since both /programs and /system would probably use components from it, and I don’t see an easy way (nor a distinct need) to separate out system from program libraries, so I’d just move /lib and /lib64 into /system also.
I like the GoboLinux structure of retaining side-by-side versions for /programs and /system/lib, so I’d definitely keep that.
The layout would then be
/programs
/users
/system
You could also possibly have a folder like /media with /music, /videos, /tv, /books, /whatever-other-stuff in it, but you’d have to make it very clear to the user that this folder is shared by everyone on the machine (and/or optionally across a network, hopefully choosable at os installation).
A discussion on building a better FHS would be valuable, if that’s what you want to talk aout. That’s pretty off topic, of course.
Any imagined new FHS would have to account for both “desktop” and “server” use. If you’re moving things around you might as well stick /sys under your /system or /os directories; then there’s no reason you can’t say /sys for your new /system.
You have to look at how things go together. You want the same FHS to apply during initramfs as the final system (that’s just easier) and you want booting to work when some parts of the filesystem are stored on NFS or otherwise available late. You need to have a plan for what the system looks like from single user mode and how recovery is performed. One nice thing about a read only / of a minimal size is that you can be pretty sure it’s never going to be corrupt, even if your fancy btrfs /var or /home is. What are the recommended partitioning schemes in your Better FHS design?
Where does /home/ go? Where do packages which install to one big directory go if there’s no /opt/? How do you distinguish between base-system components, optional components provided by the distribution, and locally-installed components provided by the sysadmin? What about programs installed by regular users? What are your replacements for /usr/share, /usr/include, /usr/share/doc, /var/cache/, /var/lib/ and /etc/init.d/? What do you do with /mnt and /media? What do you do with /lib/firmware/ and /lib/modules/? Remember that these things probably shouldn’t be mounted from NFS.
If you’re improving things, what about defining more structure for /var and /tmp? In fact, take a look at http://www.osnews.com/thread?327769 where I asked some questions like these before.
Here’s a thought experiment I did a few years ago:
/ – contains:
/local/
/system/
/mount/
/cfg/
/home/
/tmp/
/system/ – contains
— /boot/ – files required to boot the system
— /exe/ – copies of the programs executed during boot (statically linked?) so that /system/exe/ can be absent
— /exe/ – symlinks to (or otherwise a collection of) all executables that a user or another process might be expected to run (non-internal, think public methods)
— /lib/
— one directory per package
—- any non-portable (arch-specific) files not needing to be writable at runtime. These may be .so or may be executables, or anything. Think private methods.
— /all/ – symlinks to (or otherwise a collection of) all system libraries. LD_LIBRARY_PATH points here.
— /system/ – ld-linux.so, libc, etc. Libraries not provided by packages.
— /share/
— one directory per package
—- any portable (not arch specific) files not needing to be writable at runtime
— /data/
— one directory per package
—- any non-temp files that will need to be written to during a program’s run time
— /<package>/run/ – lock files and named pipes
— /<package>/lib/ – ?
— /<package>/spool/ – write queues
— /log/ – log files
—- /user/<username>/ – user’s log files? Perhaps symlink back to ~/.sys/log/?
—- /<package>/
—- /system/ – log files for things that are basic and not part of another package. Kernel and what else?
—- NO log files in /log/ itself.
— /kernel/ – kernel virtual fs mounts
— /sys/
— /proc/
— /dev/ – device files
/local/ – contains
— /lib/
— one directory per package
— /all/ – symlinks to (or otherwise a collection of) all locally installed non-system libraries. LD_LIBRARY_PATH points here.
— as with /system/lib/, so here.
— /share/
— one directory per package
— as with /system/share/, so here.
— does NOT contain /data/. Runtime data is runtime data, regardless.
/cfg/ – contains
— /<package>/ – one directory per package
— /system/ – configuration files for things that are basic and not part of another package
—- /paths/ – directory containing files describing paths by name. This will make sense.
—– home – contains the string “/home/” by default. This is used when computing a user’s home directory.
—– mount – contains the string “/mount/” by default
—– dev – contains the string “/kernel/dev/” by default
—– basically, the local admin can change the base name of system directories by altering these files. Woe betide you if you make a typo.
/home/ – contains
— one directory per user
— /<user>/
— /.sys/ – hidden directory containing all files and the only files in the users home directory which the user does not create himself
—- /cfg/ – all userland app config files go under here, dotfile or no, subdir or no
—– /<package>/ – programs SHOULD store their config data in a subdir named after themselves, even if it’s only one file
—– investigate fd.o ~/.local/ and see if it’s worth duplicating
—- /mount/ – user mounted filesystems (remote or local). Perhaps system policy can lock users out of mount privileges unless it is under this directory.
—– /net/ – mirrors /mount/net/ in structure. User-mounted network locations.
—– /disk/ – non-network mounts
—– instead of /local/ the user’s naming policy is to have symlinks called whatever the user likes pointing back to net or disk directly. I think this is OK.
—- /exe/ – user’s executables. This directory is in the front of the user’s PATH
—- /log/ – log files for user’s processes
—– /<app>/ – one directory per application, internal structure is up to the app
/mount/ – contains
— Perhaps by policy nothing will be mounted outside of /mount/ and /home/$user/.sys/mount/. I think using symlinks is sufficient to make this OK.
— /net/ – network hosts sorted by host name
— /<hostname>/
—- /<some_export_name>/
— /local/ – directories for mounts named however the local sysadmin likes. In reality anything can be mounted anywhere as needed, but this is the correct location for transiant mounts. might be symlinks to ../disk/*/*. NOTE: not just local devices! Local naming policy. Policy may be *described* in /cfg/system/ somewhere, but here is where those named links are created in fact.
— /disk/ – local disks sorted by disk name (as found in /dev/). If something is mounted anywhere it is ALSO mounted here
— /cdrom0/ – for example, the first cdrom device (device file: /system/kernel/dev/cdrom0)
— /floppy/ – for example, the first floppy (device file: /system/kernel/dev/floppy)
I eventually gave up on this approach. Remember, please, that it’s all about what problems you’re trying to solve (and that with the FHS you have to solve ALL PROBLEMS).
I’d also add that all non-system software should be split off, so that it does not “pollute” the system directories.
I know that the best software package management tools have been created to deal with the mess, but they should be able to add a good option of cleaning up the scattered data that software packages tend to leave behind.
Well,
I would choose /app and /user because it’s definitely better for typing; it’s a real pain when you have to browse manually file systems directories.
actually
/adm
/app
/lib
/med
/sys
/user
/var
Would do better, the new /adm to replace /root and /med in place of /media. we could keep /var and let /tmp inside it.
Anyways, any simplification of this current mess would be nice to have.
Why this fetish for /user instead of /home?
Try this experiment: Find some non-technical users and ask them: “If you’re looking for your files are you more likely to click on a folder called Home or a folder called Users?” My experiments over the years have been about 70% in favor of “Home,” pretty consistently too.
“Users” may be a technically correct classification of the directory, but users don’t think of themselves as users.
Why not abandon directories entirely? Just shove everything into one big, disorganized, incomprehensible mess. Who cares if it confuses the heck out of users? It makes snapshotting easier.
Wasn’t that the point of WinFS?
i’d prefer seeing some things installed as packages but then someone has to decide what gets installed into the system and what gets installed as a bundle.
I just know that arch throws everything in /usr/bin and i frankly have a difficult time using a file browser to navigate into /usr/bin due to the long delay required to populate the browser.
Why does it need to go to /usr?
In the custom distribution I run on my servers I pul all packages in /pkg as in ….
/pkg/org.vendor/product/1.2.3
… I then symlink specific files into /bin and /lib.
(It’s based off of Slackware so there is no dependency managed. Although there is a package remove mechanism I can usually just rm a pkg.)
]{
Did you get rid of /usr entirely, like in http://sta.li/ or is it still there for /usr/include and /usr/share?
Because directories are also containers and it’s easier to mount /usr ro than /bin and /lib and /share, etc. It also makes selinux and apparmor policies easier. There are a lot of reasons worth considering.
A turd is still a turd, even after you’ve polished it a little. One of the biggest problems with Linux is the layering of bandaid after bandaid instead of just addressing the root cause of the problems.. You may experience some growing pains but in the long run it’s a better solution.
Exactly! That’s why OSX and Windows are such pieces of crap.
Yeah, lamely hiding the underlying directory hierarchy and using a registry instead of addressing the root problem… oh, wait… that’s what OSX and Windows do!
Yes, OSX should’ve just started with a completely new directory hierarchy, instead of using the established Unix hierarchy and hiding it beneath their lame hierarchy — would’ve been some growing pains, but it would have been a better long-term solution.
/sarcasm
…
…
…
Why are you whining about Windows and OSX in a thread about a change in Fedora Linux? Regardless of what’s done in Windows and OSX, the topic is Linux and what should be done there. If you want to soil about Windows and OSX, start a new thread.
No whining — just stating facts.
You made a vague, unsupported whine that Linux has “layered” fixes. My question would be: “Compared to what?” Which OS is did you have in mind that is different, and exactly why is it different.
My friend, “Welcome to the Internet!”
Forum threads often grow and develop in unpredictable and interesting ways, and trolls do not determine the rules of what what is accepted as on-topic or off-topic.
In truth I made an accurate statement that is common knowledge and a view shared among many linux developers/contributors. Join the linux kernel mailing list and see for yourself. It’s not as if I’ve just revealed how the Egyptians built the pyramids.
And, “compared to what?”.. Compared to nothing, we’re not talking about OS comparisons here. Start a new thread if you want to talk about that.
Edited 2011-11-04 16:16 UTC
Soo…instead of putting more tools in / they move everything from / to /usr and put symlinks in /. Say what? Wtf? Might as well put everything in /bin and /lib then since it’s pretty much what they’re doing anyway.
What confusion? Normal users don’t care and those who do should know better than to be confused.
Really? The belong under the cryptic path “/usr” rather than the straihtforward, and shorter, /?
Sure, you could say that but it’s a moot point since you’ll require /usr anyway . Come on, if you want to actually simplify this just move everything from /usr to /, since that’s what they’re effectively doing anyway, and just keep /usr/local.
Or if you moved everything to / you could just mount /bin and /lib read-only. Not really a big difference in practice.
Yeah, because moving them down one level makes a giant difference.
I dunno, it’ s not like it matters a whole lot if it’s /bin or /usr/bin but this change feels rather pointless and the arguments aren’t that great.
Edited 2011-11-03 08:02 UTC
I like how he says this even though it would actually be smaller by only 3 directories. You’d still have /boot, /root, /etc, /var, /usr, /sys, /proc, /tmp, /media, /mnt, /opt, /home, /dev. Did I forget any?
A proposal to do that was brought up and shot down earlier this year.
Edited 2011-11-03 11:53 UTC
I think he meant small in the sense of filesystem size, not number of directories under /. And in a typical setup, half of the directories you list are empty, used only as mountpoints for other filesystems.
After Fedora, everyone else will follow…just watch! I truly support this move.
While this might go against the LSB and FHS…
Do we really care? The LSB and FHS are a mess when it comes to this so who cares? Do we really want to keep living in the past – 30+ years old rules?? The people in charge of LSB and FHS will have to think twice when everyone follows Fedora or we will just create LSB++ and FHS++ respectively
Edited 2011-11-03 10:15 UTC
First you’d have to wait for Fedora to actually approve that change.
Well I hope they do
I think this is an important point that you and other supporters of this idea (and others like it) need to understand. I care.
Lots of people care. Just because you don’t like, don’t understand or don’t want to deal with the FHS doesn’t mean it isn’t logical and valuable. It certainly isn’t perfect, and many aspects of it could be improved, but you can’t just throw it out. You must understand it and love it before you can hope to improve upon it.
You complain about being bound by 30-year-old rules, but in fact that’s not necessary. The FHS hasn’t been updated lately but it could be. If you actually have a way to improve it and you can get some consensus you can get it changed. I believe there are people looking at an update now if for no other reason than to add the much-needed /run directory. If you think other changes are valuable go forth and conquor!
Let’s see…
no plan for /boot
no mention of /usr/sbin
apparent ignorance of the usefulness of the root usr split
So let’s review. Someone who doesn’t know the FHS, much less understand the FHS, thinks the FHS was created purely to be sadistic and decides he wants to just slap things together because “It will be simpler.” No rational justification given as to what the benefit is. Attempted justifications don’t hold water: Read only /usr? Already supported. Simpler to package because we don’t need to split things up? A tiny cognitive gain which doesn’t hold up against the loss. I hope the Fedora project rejects the proposal as it stands.
Don’t get me wrong, the FHS seriously needs updating and a lot of improvements could be made… but this proposal is a half-baked joke.
I think he wants to move sbin to bin. Why? dunno.
Yeah, that was kinda funny. Does he really think that we can’t mount /usr read-only today and that it can’t be shared over NFS already? Seriously? Been living under a rock long?
Actually sbin -> bin makes sense. There’s really a very limited usefulness to that distinction at this point in history.
Perhaps but I like that daemons goes into sbin because, really, how often do you need to run a daemon from the command line? They’ll just be needlessly cluttering bin, which is already badly cluttered after you install a DE.
Maybe Linux (and more software) should adopt libexec for binaries that are almost never used by users directly.
If you read Lennart’s postings on fdo, he advocates against /usr being a separate filesystem, and he actively breaks it in systemd (you can’t use systemd if /usr is a separate fs). The justification? Some packages are broken and install files into both / and /usr, therefore /usr needs to be part of / in order for boot to work. Uh, what? Instead of fixing the 2 or 3 broken packages, you want to break the entire boot process that’s worked for 30-odd years?
Perhaps it’s time for Fedora to drop “Linux” from it’s name, and to stop pretending to be a Linux distro, and just go off and do it’s own incompatible things, and leave the rest of the Linux/Unix world alone. Between PusleAudio, SystemD, breaking /usr a separate fs, and now this proposal, they basically already have.
Completely false – systemd has no problem with having /usr on a separate FS, and never has. Other parts of the boot may stop working (which is why systemd prints out a warning message), but systemd itself will work fine.
Another odd argument: it makes snapshot’ing /usr easier.
Why do you need to snapshot /usr? It contains no variable data and it almost never changes.
First, I never said in my previous post user. I said admins and programmers. For the normal Joe, it will be transparent. If you use synaptics, yum, pacman, Ubuntu One, it doesn’t matter. Users don’t deal with complexities, users don’t think in other than browsing, chatting, making docs.
Backing up an /usr folder with everything is far faster, and reliable than other methods like anaconda kickstart. Kickstart take a list of packages installed on your system, and while it works, what happens if the day you need to restore your system, you also have a ISP problem which will prevent you from downloading the packages. Also, does that app works with manually installed sources or packages? Does every distro has a kickstart like feature???
Backing up your system locally is the safest, fastest way to go. Those suggestions where made primary thinking on that purpose.
Never changes – except when you install patches. Taking snapshots of /usr before installing system updates gives you a rollback option in the event of something going wrong…
Does anyone know, is there any effort to have software installed similarly like ROM image?
– Software package defines what it provides and what it needs
– Software package is stored as a self contained single file containing all components (a loopback mounted ISO is you will)
– The configuration is stored in user’s home or /etc for system
I like how Android apps work in that regard. They fulfil a lot of these requirements.
Yes, this has existed for years on Linux and is called Klik. See http://en.wikipedia.org/wiki/Klik_%28packaging_method%29
Is it similar to Mac DMG? Or does Mac OS actually unpack something out of DMG?
Mac OS unpacks somethnig out of the .dmg file. For Mac OS each application is a directory named Whatever.app and finder hides the extension then treats it differently. Something like that is also possible under Linux, if you want to do that take a look at the Rox desktop.
Why is this good news? More mess? The “end-user” shouldn’t even care where his binaries are. The one who uses a console instead, will appreciate the distinction between bin and sbin, between system stuff and user stuff.
Somebody called Linux a watered down version of Unix. He was an optimist.
The easiest thing to do is:
#umount /dev/sd0 && mkntfs /dev/sd0 && shutdown -r now
Don’t be vulgar.
Also, even as root your umount command will fail.
Forgot
#mkdir -p /mnt/ram && mount -t ramfs -o size=2048m ramfs /mnt/ram && cp -r / /mnt/ram && chroot /mnt/ram
Probably you want pivot_root, actually.
Both this approach and the Gobo Linux approach have some disadvantages attached. Why not do it the right way? Like Hannah Montana Linux distribution does it?
For more info of the file system hierarchy see: http://hannahmontana.sourceforge.net/Site/Home.html
And it must be abolished.
Each application must reside solely in its own folder.
Shared libraries must be merged and reference-counted by the filesystem. For example, if the library ‘foo_1_0.so’ is in directories ‘bar1’ and ‘bar2’, the filesystem should keep only one copy of the library and link it to both directories, with a reference count = 2.
Sounds similar to how PBIs work in PC-BSD 9.x.
What about scripts? Quite a few of my scripts I give the full path, and at times relative paths to certain programs/files/etc.
Heck, even the interpreter itself, /bin/sh following the shebang symbol. Wouldn’t that screw things up? Are they intending to keep the legacy system in place by using symlinks so nothing screws up along the way?
I am all for change, when change is necessary, but honestly, I am so used to /sbin/ifconfig and the current location of things, I rather not relearn. At least I am more of a Debian user, so I hope they don’t change. Though a lot of my endusers seem to like Fedora, and I get people liking Ubuntu for some reason, but at least it is a Debian flavour.
In the sugested Plan, they suggested making symlinks that will keep compatibility.
/
|– etc
|– usr
| |– bin
| |– lib
| `– lib64
|– run
|– var
|– bin -> usr/bin
|– sbin -> usr/bin
|– lib -> usr/lib
`– lib64 -> usr/lib64
Changing the hierarchy of the system can be a good thing for admins and programmers. Anyone that has worked either in packaging, fixing packages, programming in Linux knows that the current hierarchy just sucks. Many programs when directed to install in /usr directory, actually store its configuration in /usr/etc instead of /etc. Take a deep look in Arch or Gentoo how many packages they have to sed fix for that.
I suggest a little more drastic change and also storing the /etc directory in /usr. That way, if an admin backup /usr, everything will be backup at one: system programs, configuration, locally installed programs, everything.
In terms of security, a revision of user/group access policies must be made in the whole tree to make sure no compromises are made. But a note: most security breaches are made by lazy admins that give way too much access (root access, shell access), instead of security within files or directories.
Also about dir names, if the whole system is placed under /usr, it will make that name kind of void. A new name like /system, or /os should be used instead, with sysmlinks for compatibility.
But I think that /bin and /sbin can be merged. Because:
1. Both are need for the basic system to start.
2. While /sbin are supposed to be root only tools, it’s path is included in every normal user in most if not all linux distros.
3. Any /sbin app that require root these days has the requirement implied in the binary itself (attributes, selinux/apparmor rules)
4. Some /bin programs sometimes require /sbin progs for certain operations.
That will help with a lot of scripts since some distros have some progs in /sbin while others have it in /bin.
Edited 2011-11-03 19:01 UTC
I don’t know exactly what the problem is with these two systems, but I find them very easy to use, very logical and much more functional.
Just keep the symlinks there -and hidden- for a transition period (two to four years, I dunno). Then remove them.
Wouldn’t it be simpler to get rid of /usr?
How about:
/bin: All programs
/lib: All libraries
/etc: All configuration files
/home: All home directories
/var: All log files
/stand: Stand alone programs (kernel, diags, etc)
If you insist on a directory for 3rd party apps
/opt: with bin, lib, and etc below
Edited 2011-11-04 21:31 UTC
You make the same point I tried to make to Lennart. The idea of a useless indirection (usr) seems silly. The problem isn’t /bin, /lib, etc… arguably, the problem is /usr. However, changing that WOULD have greater impact. I look at what Red Hat is proposing (yes. Red Hat) as being a quick and dirty way to get around problems inherent with restructuring init in their way (systemd). Sure… it make life easier for them… but perhaps it’s not really making things “better”.
So… not arguing against “better”.. just saying this really isn’t about “better”.. it’s about “easier”. For now anyhow…
systemd… it keeps growing and growing and growing…
I found an in-deep explanation of why they are looking to change the filesystem layout.
More info about it here <a href=”http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-br…
Edited 2011-11-07 15:10 UTC
Whoa, quite a nerd rage above ;p …and, ultimately, this probably doesn’t matter that much. OS uptake hardly seems dependant on their fs hierarchy; the widespread ones appear fairly “good enough” for those who need to really work with them – and too complex (NVM “uninteresting”) for too many average users, either way.
Edited 2011-11-09 23:09 UTC