Linked by Thom Holwerda on Wed 2nd Nov 2011 23:17 UTC
Fedora Core 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.
Thread beginning with comment 495536
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Why not go all the way?
by sorpigal on Thu 3rd Nov 2011 12:08 UTC in reply to "Why not go all the way?"
sorpigal
Member since:
2005-11-02

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

Reply Parent Score: 2

RE[2]: Why not go all the way?
by Icaria on Thu 3rd Nov 2011 13:06 in reply to "RE: Why not go all the way?"
Icaria Member since:
2010-06-19

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).

Reply Parent Score: 2

sorpigal Member since:
2005-11-02

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.

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.

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.

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?

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.

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.

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).

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.

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).

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.

Reply Parent Score: 2