I long for a day where PATH=/bin is all we need.
https://lwn.net/Articles/890306/
> First, technical challenges: HURD tried to move from /usr to / and had quite a bit more trouble with it, and that trouble warned against trying it on a larger scale. It's much easier to move from / to /usr than from /usr to / ; fewer things break.
> Second, consolidation: moving into /usr gives us a single directory containing all files managed by the distro / package manager. This has quite a few advantages. It makes sharing /usr among several chroots or containers feasible (one /usr, different /etc and /var). It makes versioning and A/B upgrades (upgrade to new image, fall back to old image if new image doesn't boot) simpler and easier. It makes it easy to lock down /usr with something like fs-verity.
Some folks also do something similar using LVM, BTRFS or ZFS snapshots on various distros.
Many users prefer the flexibility of package managers to appliance installs though, so having both types of installs is still a good idea.
That is explained in the “Case for the usr merge” essay: having all the readonly system stuff under a single root directory makes the system much easier to manage, and simplifies useful scenarios like having the system on a network share, or sharing the host’s read-only across guests: with a merged usr, you just have to manage a single mount point or directory rather than half a dozen which must be kept in sync.
Also /usr is not just /usr/bin. Sbin, and lib (and lib64, and lib32) are also part of the usr merge.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
> On Fedora the root directory contains ~450MB already. This hasn't been minimal since a long time[…]
> There is no way to reliably bring up a modern system with an empty /usr.
These seem like workarounds for self-inflicted Fedora problems. Having a known-good /bin from boot time seems strictly better than an extra copy of some of /bin in a ramdisk that almost nobody works with because it’s quickly thrown away.
I always thought the reason was to categorize binaries which seemed like a valid reason
There will always be sets of tools managed by the distro or my org or my team or me, and it’s pretty important to segregate them to avoid and resolve conflicts, so I expect at least four entries in $PATH for the foreseeable future. Plus whatever messes vendors care to dump somewhere in /opt.
Also having everything system specific live under a single path means easy backups, easy immutable trees that can be A/B swapped for seamless and online updates with easy rollbacks.
No more wondering where the various tools live since everything lives in /usr/bin and more.
The original point of a non-merged /bin was that /usr/bin was a spillover from when they ran out of space on the primary drive back in the 70s, so there was a slapdash split where the stuff necessary for bringup was kept in /bin and the rest would be kicked down to /usr/bin, in a very inconsistent manner depending on the system’s evolution.
In fact that’s also why users were moved from /usr (the original location, hence the name) to /home: /usr ran out of space, so they added a third disk and moved the user directories over there.
> Keep in mind that the approach of booting from initrd is quite non-idiomatic
How can you claim that it’s non-idiomatic when it’s the standard approach?