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 495539
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Why not go all the way?
by Icaria on Thu 3rd Nov 2011 13:06 UTC 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

Icaria Member since:
2010-06-19

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.


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.

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?
Again, you're way off base. This wasn't what I was suggesting at all.

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

In the first place, even if you did it that would be b:/
Well no, it wouldn't be but I digress.

in the second place how is this different from mkdir /b:/ ?
Well for starters, you'd have a static directory sitting on a HDD partition, somewhere.

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).
Except it's all virtual; Windows doesn't throw it's it's VFS and the OS partition in a blender.

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

Reply Parent Score: 2