I'm surprised that they are pushing to remove /bin and keep /usr/bin. Why not the other way round? Let's keep our binaries out of /usr! (as a first step to remove /usr altogether, since it has a confusing name).
> 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.
> I'm surprised that they are pushing to remove /bin and keep /usr/bin. Why not the other way round?
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.
$HOME/bin is useful as well. I like that I can have my own software (that I wrote and compiled) in my home folder and don't need to ask a sys admin to install it for me.
> What changes is simply that you need to boot with an initrd that mounts /usr before jumping into the root file system.
> 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.
Keeping /usr/bin is a smaller change, because that’s where most binaries were before the merge. Only a few essential repair tools traditionally lived in /bin because that made each host store its own copy (rather than maybe depend on NFS).
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 (and /sbin) was to contain essential binaries for system recovery and early boot, that should be available even when a separate /usr/ partition is not yet mounted. Keep in mind that the approach of booting from initrd is quite non-idiomatic and used only for convenience wrt. a generic distro install; you're generally meant to recompile your kernel so that it can mount / directly at boot and find everything it needs there, without requiring to mount either a ramdisk or a separate partition. This means that early-boot stuff must live there in order to get the benefits of separate partitions in the first place.
> The original point of a non-merged /bin (and /sbin) was to contain essential binaries for system recovery and early boot, that should be available even when a separate /usr/ partition is not yet mounted.
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?
You still need an initramfs in the case your bootloader/kernel doesn't support your filesystem; for eg GRUB didn't support LUKS2 and the Linux kernel can't boot LUKS directly without userspace tools to input the passphrase etc.
Your distribution needs an initramfs for that reason; you as a user can just recompile the kernel so that the modules it needs are built-in rather than needing to be loaded separately from a ram-disk. If you need an early-boot file system at all (as with an encrypted /), it can be provided in /boot/ and then "swap root" to / at boot like initrd does.
Nowadays a network files protocol fits inside the system initializing ROM, so all of those old issues are moot and we have completely different problems to optimize for.
I long for a day where PATH=/bin is all we need.