Merge /{s,}bin with /usr/{s,}bin

With the recent /lib -> usr/lib move, and things like systemD on the horizion, is it time to merge /bin and /sbin with /usr? There was some talk in "GNU/Linux Discussion" then Fedora started down this path. What do people think about this idea today (2012-08-30)? I personally like the idea of a read-only /usr partition mounted by initrd that I could share between VM's. I'd also like to encrypt the partition, share it via NFS, take snapshots, and a few other fun activies.

I could probably do this today if I mapped /bin to usr/bin.root to sidestep /bin/foobar -> /usr/bin/foobar symlink issues. I think the hardest part would be getting mkinitcpio's initrd to decrypt / and /usr, and then mount /usr. I think all the pieces are there in one form or another today, I'd just need to string them togeather properly. As for the distro as a whole, would /bin & /sbin be very different from the /lib move?

Re: Merge /{s,}bin with /usr/{s,}bin

* Having four different locations for binaries ({/usr,}/{s,}bin}) andtwo locations for libraries ({/usr,}/lib) is less KISS than having onelocation for binaries /usr/bin and one for libraries /usr/lib.

Re: Merge /{s,}bin with /usr/{s,}bin

* Having four different locations for binaries ({/usr,}/{s,}bin}) andtwo locations for libraries ({/usr,}/lib) is less KISS than having onelocation for binaries /usr/bin and one for libraries /usr/lib.

Re: Merge /{s,}bin with /usr/{s,}bin

thx fsckd

Allan wrote:

When I first looked at hurd and saw "usr -> .", I was immediatelyconvinced that this was a great idea. It is simplifying the filesystemlayout in terms of where of where to look to find specific files (e.g.is the library in /lib or /usr/lib) and makes packaging simpler (e.g. iflibfoo.so is in /lib and libfoo.a is in /usr/lib then you need symlinksto libfoo.so in /usr/lib too). It makes little difference from a usersperspective provided the symlink is present so the old directory layoutcan be used transparently.

What convinced me of putting all this in /usr rather than on / is that Ican have a separate /usr partition that is mounted read only (unless Iwant to do an update). If everything from /usr gets moved to the root(a.k.a hurd style) this would require many partitions.

Didnt know hurd was doing it, definitely like it better, as the read only partition is a very good point, but how many actually use it? < 5% I guess,besides someone could still do it as Allan said, he just needs like 3 partitions instead of 1.

Re: Merge /{s,}bin with /usr/{s,}bin

I fully support this move of putting all binaries on an equal footing. I don't know how many times I've rolled my eyes about how arbitrary it is now. Avahi thinks it's more critical than grep? Please.

I also think it's more pragmatic to keep /usr.1. This would create /share, /include and /src.2. Changing "--prefix=/usr" to "--prefix=/" in every program would be a huge undertaking.3. An impression I got in my early days with Arch was that a lot of people do have it on its own partition. And the one weakness of these plans to reorganize the filesystem is that you can't create cross-device symlinks. We wouldn't want to have to go with some kernel level hack like GoboLinux uses, would we?

Re: Merge /{s,}bin with /usr/{s,}bin

Re: Merge /{s,}bin with /usr/{s,}bin

Just my 2 cents but I always thought /usr was meant to contain userspace binaries while the stuff in /bin and /lib were all system specific (read as "Don't mess with this stuff or kiss your system goodbye") so that the usr directory could in theory be isolated from the system preventing rogue apps from going haywire on the system. And of course sbin was for superuser binaries (I think it still is). I don't think any of this matters anymore since permissions are pretty much the same now between the 2 locations and root owns everything for the most part except the home directory.

Re: Merge /{s,}bin with /usr/{s,}bin

techwiz wrote:

Just my 2 cents but I always thought /usr was meant to contain userspace binaries while the stuff in /bin and /lib were all system specific (read as "Don't mess with this stuff or kiss your system goodbye") so that the usr directory could in theory be isolated from the system preventing rogue apps from going haywire on the system. And of course sbin was for superuser binaries (I think it still is). I don't think any of this matters anymore since permissions are pretty much the same now between the 2 locations and root owns everything for the most part except the home directory.

The history of /usr is long and amusing (originally it was what /home is now, then hack layered upon hack and a chain of reinterpretations of /usr's purpose gave us what we have today).

Anyway, the description you give is roughly what we used to have before we started merging stuff back from / to /usr. There are several problems:

* it is not really clear what is the important stuff and what is the user-specific stuff as things change over time and between different users/use-cases * moving binaries from /usr/bin to /bin (or any other combination) without adding symlinks for compatibility is likely to cause problems as the path will be hardcoded in scripts++ * we end up with having stuff in /usr that should be in / and stuff in / that should be in /usr, either because we did not anticipate the change in usage and stuff is "stuck", or because we thought something might change in the future and took this into account, but it did not. * the problem is even more pronounced with /bin v. /sbin, as adding a feature that can be used by non-root users to a binary that used to be only for root means that it should move to /bin. However, we can't do that (because the path is hardcoded everywhere). The end result is that both /bin and /sbin is in the PATH of everyone (including non-root), and the distinction is meaningless. * if an app can change /usr then it can change /bin. There should never be a need for any app to have write-access to either.

In short: getting the distinction right is hard. Even if we could do it, it does not gain us anything.

Re: Merge /{s,}bin with /usr/{s,}bin

I'm sure you can hold him to that. Now it's a done deal: whenever the transition happens, pacman 4.1 will have been completed first. This is just as true if the /usr transition is done in 10 years as if it is done tomorrow.