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.
Permalink for comment 495576
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?"
Member since:

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.

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

......volume01/ (first hdd, first partition, OS location, first non-virtual part of filesystem tree)
........user/ (optionally symlinked to /devices/drive02/volume01/)
........optional_files/ (optionally symlinked to eg. /network/compname/storage/volume01)
........temp/ (temp files and logs)



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