5 ms·

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 re

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). I long for a day where PATH=/bin is all we need.

_wldu 5y ago
$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.
- CameronNemo 5y ago
  I use ~/.local/bin, but yeah using your homedir for as much as possible makes system administration easier for everyone.
hashhar 5y ago
Not everything is a binary. 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.
- zozbot234 5y ago
  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.
  - pabs3 5y ago
    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.
    - zozbot234 5y ago
      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.
  - masklinn 5y ago
    > 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?
  - marcosdumay 5y ago
    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.
pabs3 5y ago
There is a comment on the LWN article about that: https://lwn.net/Articles/890306/ 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.
- ssl232 5y ago
  The A/B system upgrade idea is intriguing. And kinda painfully obvious, in hindsight. Why don't the distros that have merged /usr do that already?
  - pabs3 5y ago
    I think they do, Fedora's workstation product is meant as an appliance and I think it uses ostree to do something like the A/B upgrade thing. 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.
    - johnny22 5y ago
      it's not Workstation, it's Silverblue. Workstation is just like every other distro.
  - deleted 5y ago
    [deleted]
  - JoshTriplett 5y ago
    The latest version of systemd has a tool for doing exactly that.
masklinn 5y ago
> 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.
erik_seaberg 5y ago
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.
mekster 5y ago
Why not read the reasoning once? https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
- cerved 5y ago
  > There is no valid reason anymore to have the operating system spread over multiple hierarchies, it lost its purpose. I always thought the reason was to categorize binaries which seemed like a valid reason
- erik_seaberg 5y ago
  > 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.
- enriquto 5y ago
  - mekster 5y ago
    What offensive word in the URL?
    - 0des 5y ago
topspin 5y ago
That is surprising. Just /bin with a /usr/bin->/bin symlink is common in embedded systems. I doubt the symlink is even necessary in most of those.

_wldu 5y ago

$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.

CameronNemo 5y ago
I use ~/.local/bin, but yeah using your homedir for as much as possible makes system administration easier for everyone.

hashhar 5y ago

Not everything is a binary. 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.

zozbot234 5y ago
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.
- pabs3 5y ago
  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.
  - zozbot234 5y ago
    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.
- masklinn 5y ago
  > 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?
- marcosdumay 5y ago
  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.

pabs3 5y ago

There is a comment on the LWN article about that: https://lwn.net/Articles/890306/ 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.

ssl232 5y ago
The A/B system upgrade idea is intriguing. And kinda painfully obvious, in hindsight. Why don't the distros that have merged /usr do that already?
- pabs3 5y ago
  I think they do, Fedora's workstation product is meant as an appliance and I think it uses ostree to do something like the A/B upgrade thing. 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.
  - johnny22 5y ago
    it's not Workstation, it's Silverblue. Workstation is just like every other distro.
- deleted 5y ago
  [deleted]
- JoshTriplett 5y ago
  The latest version of systemd has a tool for doing exactly that.

masklinn 5y ago

> 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.

erik_seaberg 5y ago

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.

mekster 5y ago

Why not read the reasoning once? https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...

cerved 5y ago
> There is no valid reason anymore to have the operating system spread over multiple hierarchies, it lost its purpose. I always thought the reason was to categorize binaries which seemed like a valid reason
erik_seaberg 5y ago
> 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.
enriquto 5y ago
- mekster 5y ago
  What offensive word in the URL?
  - 0des 5y ago

topspin 5y ago

That is surprising. Just /bin with a /usr/bin->/bin symlink is common in embedded systems. I doubt the symlink is even necessary in most of those.