The Case for the /usr Merge

[menotu]

http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

https://fedoraproject.org/wiki/Features/UsrMove

==============

Edit - added following:

By Brian Proffitt - January 27, 2012  (itworld)

The Grand /usr-fication of Linux

Fedora developers defend the proposed merger of /usr directories

The Fedora Project is currently mounting a concerted effort to merge Linux filesystem directories into a more organized structure, an effort known as /usr merge.

This is not really new news: I covered this back in November. But a new posting on FreeDesktop.org from systemd developer Lennart Poettering is seeking to dispel many of the arguments against such a merge, while touting the merger's advantages.

Poettering is not the initial proposer of /usr merge--that designation goes to fellow Red Hat developers Harald Hoyer and Kay Sievers, as an effort to clean up the mess that was made when the /sbin and /bin directories were first split off from each other. The Grand /usr-fication Theory will, when implemented, essentially pull in every component of the operating system to a single mounted volume.


Full article

[menotu]

posted by Thom Holwerda on Mon 30th Jan 2012 (osnews)

Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

Finally something really interesting to talk about. If you've used UNIX or any of its derivatives, you've probably wondered why there's /bin, /sbin, /usr/bin, /usr/sbin in the file system. You may even have a rationalisation for the existence of each and every one of these directories. The thing is, though - all these rationalisations were thought up after these directories were created. As it turns out, the real reasoning is pretty damn straightforward.

..............

Late last week, I came across a link at HackerNews giving some intriguing insight into how /bin, /sbin, /usr/bin, and /usr/sbin came to be. Many of you will be surprised to learn that no, there is no divine plan behind all this separation.

The issue was that when Ken Thompson and Dennis Ritchie upgraded from a PDP-7 (on which they created UNIX in 1969) to a PDP-11 in 1971, they were confronted with not one 1.5MB hard drive, but two. Amazingly, they now had an insane amount of megabytes (3 of 'm). The first disk contained the operating system, while the second one contained all the user stuff. This second disk, with all the user stuff, was mounted at /usr (/home was invented later).

At some point, the operating system grew too big for the first disk, and had to spill over to the second disk. As a result, Thompson and Ritchie replicated the system directory structure (/bin, /sbin, /lib, /tmp, and so on) on this second disk under /usr. When they got a third disk, they moved all the user stuff from /usr to the third disk, mounted under /home.

This forced them to come up with a number of rules, such as that a command like mount couldn't be installed in /usr/bin, since mount was needed to mount the second disk (/usr) in the first place.

"The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things," Landley explains, "It stopped making any sense before Linux was ever invented, for multiple reasons."

Full article/links

[Bald Brick]

As I've written before the arguments in favour of The Merge are quite compelling.

There's one drawback though. I know quite a lot about the Linux filesystem hierarchy. And now The Merge threatens to make a third of what I know obsolete...!

[menotu]

As I've written before the arguments in favour of The Merge are quite compelling.

There's one drawback though. I know quite a lot about the Linux filesystem hierarchy. And now The Merge threatens to make a third of what I know obsolete...!

Yup!  And all the tutorials/how-to's and myriad number of other things it would affect.

[The Chief]

But. at some point you just have to bite the bullet and have a do over to keep moving forward.  KDE 3.x to 4.x?   Gnome 2.x to 3.x?  The merge certainly seems to simplify things, and should get back to having the entire operating system on a separate drive (like a small SSD?).

Even before that - Windows on top of DOS, to Windows without DOS?  Wait - maybe that's not going forward...   

[sling-shot]

I do not see anyone complain about dumbing down things here or anywhere on the web on this particular issue

[horusfalcon]

Okay... this looks like it will simplify certain things:

/bin moves to /usr/bin?
/lib moves to /usr/lib?
/sbin moves to /usr/sbin?

with /bin, /lib, and /sbin becoming symbolic links to their new actual locations?

At first I didn't get the reasoning for moving everything to /usr and then it hit me:  keep the root clean and simple, and make one mount point under root for everything OS-related. Seems like a good move to me.

No pain, no gain.  At least with this approach, the pain will be minimal and the gain will be worth every bit of it and then some.  Yeah, let's do this.

[EDIT]  One question, though:  would /opt then need to move to /usr/opt to make this a really complete unification?  Seems like it might.  Then the resulting "base" partition scheme would look like this:

• / (root) - a small partition now, containing only essential boot, configuration, logging, and kernel-related stuff?
• /usr - all other OS-related stuff, applications, and all the stuff in /usr/opt
• /home - home folders for all users.
• (swap) - the Linux swap partition(s)

- I would tend to create swap toward the outer edge of a disk's platters or on a small, separate SSD, but that's just me...
[/list]

(I realize that infinitely many partitioning schema are out there, but this would be a reasonable default.  Looks pretty good from here.)

Later On,
D

[Bald Brick]

I do not see anyone complain about dumbing down things here or anywhere on the web on this particular issue

The merge would simplify things without dumbing down anything. And we wouldn't have to learn anything new. We'd just have to forget parts of what we know today.... (And that is irritating, of course....  )

[Crow]

Hu? 

"I don't see any of those things in /home/crow, what are you talking about?"
                                                                    Signed: The User   

Seriously, all those things sounds like my wife telling me: "clean your desk" or worst: "you two (my son and me) clean that room (computers room)". We go outside, do other (useful) things and basically avoid the task but sooner or later the desk/room is still there and we have to clean or else (else means: she or the maid cleans but they can't be held responsible for lost or broken things).

I guess cleaning time reached developers and better get involved or someone else will do it, if something gets broken or lost... bad luck...

[AS]

I've never made a secret of the fact that I absolutely detest the UNIX directory structure. The names are non-descriptive and often entirely arbitrary, they require a book to properly understand, and everyone seems to have their own ideas about what goes where

The above recap the whole article, written from someone who admittedly don't understand the structure.

To say that we could get rid of the separation 30 years ago, is a complete non sense, thinking only at the filesystem performance of 15 years ago, you couldn't not have such large directories, an ls command took ages when running on dir containing thousand of files, so was each "open" system call on such large dirs, the overall impact on performance was very high, this improved only starting from ext3 and other filesystems implementing some sort of directories optimization.

AS

[Bald Brick]

I've never made a secret of the fact that I absolutely detest the UNIX directory structure. The names are non-descriptive and often entirely arbitrary, they require a book to properly understand, and everyone seems to have their own ideas about what goes where

The above recap the whole article, written from someone who admittedly don't understand the structure.

To say that we could get rid of the separation 30 years ago, is a complete non sense, thinking only at the filesystem performance of 15 years ago, you couldn't not have such large directories, an ls command took ages when running on dir containing thousand of files, so was each "open" system call on such large dirs, the overall impact on performance was very high, this improved only starting from ext3 and other filesystems implementing some sort of directories optimization.

AS

+1

On the other hand that's not a valid argument against the merge: I absolutely love the UNIX directory structure, but that doesn't mean that it could never be improved. It just means that you shouldn't change it on the spur of the moment.

[horusfalcon]

+1

On the other hand that's not a valid argument against the merge: I absolutely love the UNIX directory structure, but that doesn't mean that it could never be improved. It just means that you shouldn't change it on the spur of the moment.

I gotta agree with you on that one.  I think that's why the proposed merge includes symlinks so moving all that stuff to /usr doesn't break any legacy stuff that uses the old hierarchy.  (But you probably already knew that, huh?)

I still wonder whether moving /opt under /usr would also make sense, though...  Like I said earlier, it seems like it would.

Later On,
D

[djohnston]

As I've written before the arguments in favour of The Merge are quite compelling.

There's one drawback though. I know quite a lot about the Linux filesystem hierarchy. And now The Merge threatens to make a third of what I know obsolete...!

Not true. Someone has to know where all the symlinks should be. 

[pags]

Wasn't there an older thread about this same thing?

I remember a bit about booting into maintenance mode, and needing some binaries...if /usr is mounted separately and not available, wouldn't preclude access to the tools to fix from (barring, of course, fixing from LiveCD, etc).  The symlinks would become invalid until the /usr partition could be mounted...if it needed to be fsck'd first, you'd be...well, fsck'd.

[AS]

Wasn't there an older thread about this same thing?

I remember a bit about booting into maintenance mode, and needing some binaries...if /usr is mounted separately and not available, wouldn't preclude access to the tools to fix from (barring, of course, fixing from LiveCD, etc).  The symlinks would become invalid until the /usr partition could be mounted...if it needed to be fsck'd first, you'd be...well, fsck'd.

Yes!   

http://www.pclinuxos.com/forum/index.php/topic,98942.0.html