Fedora To Simplify Filesystem Hierarchy, Move Everything to /usr
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.
E-mail Print r 4   · Read More · 145 Comment(s) http://osne.ws/jih
Thread beginning with comment 495576
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Why not go all the way?
by Icaria on Thu 3rd Nov 2011 15:07 UTC in reply to "RE[3]: Why not go all the way?"
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

sorpigal Member since:
2005-11-02

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.

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.

"In the first place, even if you did it that would be b:/

Well no, it wouldn't be but I digress. "
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.

Well for starters, you'd have a static directory sitting on a HDD partition, somewhere.

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.

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

Except, for the purposes of spitballing, I'm really not concerned with backwards compatibility.

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.

Reply Parent Score: 2

sorpigal Member since:
2005-11-02

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.

Reply Parent Score: 2