Merging into /usr
 

Any though about this post?

From what I read on this page there are some benefits into the merging the binaries into /usr.

Here are a few of my thoughts, though you might not find them very nice...

It looks like this has something to do with systemd. I therefore cringe. It seems 2011 was the year of "not good enough" in Linux Land. X11 sucks, here's Wayland. GNOME2 sucks here's GNOME shell. sysV is "old" here's systemd. "init"? you must be joking. Who is this freedesktop.org people anyway? They remind me of GNOME developers. Self-appointed rulers of "The Way Things Aught To Be".

Yes, I fear the new crop of Not Invented Here developers are....here. The Old UNIX way is....old.

Sure, I understand. GNU is Not Unix after all. But let's hope our new "One Daemon To Rule Them All" overlords don't forget what happens to people who don't understand UNIX.
They are doomed to re-invent it...poorly!

I am just looking for thoughts, I do not understand enough of systemd so I am see what other people know :)

Though some of the 'advantages' they claim for it are a bit suspect, I'm in favour of this one. The /usr/bin, /bin split really doesn't make much sense these days At one point they were also talking of getting rid of both /sbin and /usr/sbin and shoving everything in /usr/bin. I don't agree with that however, as there are very good reasons not to do that - which they've now realised.


P.S. I'm also in favour of bringing back the BSD style /usr/libexec which got deprecated a few years back, but always seemed to make a lot of sense to me.

The systemd issue is slightly different. systemd needs /usr to be part of the rootfs as it needs some of the stuff in /usr/lib/udev and suchlike during early boot before it mounts /usr. Whether /usr/bin and /bin are separate directories has no bearing on this so long as /usr isn't a separate filesystem.

Bad idea to make systemd depend on having /usr present. If it needs something from /usr/lib/udev or other places under /usr, then thse things should be moved to /lib -most of udev is under /lib anyway.
I also like the old-style /usr/libexec, but only for it's real purpose of housing architecture-independent stuff (scripts) which get's violated a lot.

The thing that annoys me is that all those Red Hat "innovators" now have a lot of power, especially after Suse dropped a lot of projects.
If a dev wants to play with the file hierarchy, invent new deamons to his heart content and break compatibility and force everyone to relearn how to use a computer and how the system is organized, that's fine. There's a distro, whose name I forget, that hides /usr, /bin, etc. in favor of a directory per software.
Now, when said devs are the maintainer of half the userland, things get scary, especially when they show no signs of ever wanting to stop constantly reinventing the wheel. I mean, they're already at udisks2 for heaven's sake. In 6 or 7 months, they'll be releasing the beta of systemd 3.5 and suggesting to do away with directories entirely. Let's move all to the root. It's more organic and less confusing. Let's just keep the /run directory.

I like Slackware and OpenBSD. They make sense.

For me, i still prefer the current situation
If it ain't broken, why change it?
It would only cause a mess for people and to the maintainer to move all files to the new place and i guess it would break a lot of applications

Mac OSX ?

Mac OSX is indeed different, but no. I was talking about GoboLinux - found it.

Edit: added a screenshot of its hierarchy taken from Wikipedia.

I am very much opposed to conflating the /usr subdirectories with their top-level counterparts. On about half the installations I do, my /usr is a separate mount point because of the advantages doing so offers.

/usr typically comprises the bulk of a typical installation and the criteria for its operation differs significantly than that for the core system, configuration, and users' data.

Depending upon the situation, it might be desirable to have /usr be either the most reliable partition, or the least. On my personal workstations, a failure of /usr doesn't cost me much since it can be re-constituted quite readily and at no cost (my data is what's important). On a server where maintaining uptime is critical, keeping /usr on a reliable medium can sometimes be more important than protecting users' data (there may not even be any).

/usr is accessed more often than most other paths -- nearly all of your applications, libraries, and system resources get loaded from /usr -- making read speed a significant criteria in the media.

/usr is to a large degree read-only (or at least write-rarely, read-often) which makes keeping it on a flash device a viable option (or in extreme cases, ROM). Alternatively, one could place it on a RAID 1 device gaining a near doubling in read times and greater reliability (no need to worry about write times). Also, journaling on such a rarely written filesystem would seem unnecessary and a slight speed benefit might be had by using Ext2 (though for consistency's sake, I typically use Ext4).

In some circumstances, it may be desirable to have /usr mounted on a common NFS share. This is useful for thin clients or to ease maintenance of multiple similar workstations on networks.

In order to administrate a system that takes advantage of any of the above opportunities, it is necessary to have a functional system available without /usr being mounted. The utilities available in /bin, /sbin, and /lib provide such a minimal administrative system. (When I upgrade to a new version of Slackware, I install to a single partition and after a few weeks when I have things sussed, will remove the old /usr and move the new /usr to freed partition.)

I do not want to rely upon elaborate approaches like LVM or BTRFS for my core system -- especially when the tools are not available to recover from problems that arise on such systems (last time I checked, sysrescueCD did not support LVM, and BTRFS is still in beta). Being able to switch to a reliable runlevel which does not depend upon /usr, yet offers the administrative tools necessary, is very important to me.

I happen to be one of the "red hat's" BUT the move by fedora 17 to do that ?? iffy
fedora is NOT a good server distro so they could get away with it.
now if RHEL 7 or 8 were to do that -- NOT GOOD


on a HOME SINGLE TOWER set up merging it would be fine, as it is having a /usr/local on that is also useless.

now on a networked office or home setup merging is NOT a good idea

saulgoode : all very good points

on a very simple set up one could BUT on a complex set up -- no way .

My preference these days is for a partition layout such as:
/
/var
/home
/tmp
/localdata

... and IMO this is equally viable for server, workstation or desktop use (though on a server you might want a couple of extra subdivisions of /var). Merging /bin, /lib and /sbin into their /usr counterparts makes good sense when you use this sort of layout.


But then, I'm one of those weird people who actually likes putting application resources under /opt/$program-name.

:)

I don't agree with the proposed merge. The only stated reason for it is: compatibility. There's only problem with this argument ... it's them who are not compatible with us, not the other way around. They are incompatible, and they want us to be incompatible too. They say this will make us all compatible.

saulgoode, the whole point is that your initrd will take the place of mandatory non-usr /bin etc. In a pinch, you can boot to /bin/sh using the initrd, which allows you to run busybox utilities (which should suffice for most pre-system maintenance tasks) and mount /usr if you need more. I actually don't have a problem with the merge in theory and can see the potential benefits. However, it's a lot of work, and I don't agree with their exaggerated arguments about how difficult the separated state is to maintain software -- as they say themselves, most software is built using autotools, which allows standard arguments to specify system directories. As seen in Slackware's SlackBuilds, packaging standard software is not made more difficult at all by the separation of /bin and /usr. I also don't agree with their statements regarding the feasibility of booting without an initrd -- although this may be impossible in other distros, it most certainly works fine in Slackware with the appropriate kernel (FYI I use LUKS encryption so I require an initrd anyway, but without that one isn't necessary).

If the end state could be reached, I wouldn't have a problem with the unified /usr. Getting to that state, however, may be more trouble than it's worth.