6 ms·

The reason for having a separate /usr has long slid into obsolescence. Our storage is no longer constrained to require us to mount a remote partition which hold

The reason for having a separate /usr has long slid into obsolescence. Our storage is no longer constrained to require us to mount a remote partition which holds most of the binaries and other sundry required to boot a distribution.

tremon 1y ago
In other words, the strongest argument for usrmerge is that there is no compelling argument against it?
- mariusor 1y ago
  I think the current strongest argument against it is that systemd complains when /usr is on a separate partition[1], and what its devs have weighed in on the matter[2]. [1] https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ https://freedesktop.org/wiki/Software/systemd/separate-usr-i... [2] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
  - amiga386 1y ago
    sysvinit had no problem being told to mount /usr as soon as network was available, and if you set up an init script to run before /usr was available, but the script needed /usr, that was your own fault. systemd relies on things in /usr being available, including to decide which scripts to run, and mounting /usr would be one of those scripts, so it has a chicken-and-egg problem. But ah, it doesn't! Instead the world needs to make sure /usr is mounted before systemd even gets started, so systemd doesn't have to fix its bug. Personally, I don't mind /usr/bin merging with /bin, the benefit I can see is no more squabbling over whether something should be in /bin or not (i.e. is this tool needed to boot the system, or not?)
    - mariusor 1y ago
      > sysvinit had no problem being told to mount /usr [..] if you set up an init script to run before /usr was available, > the world needs to make sure /usr is mounted before systemd even gets started, so systemd doesn't have to fix its bug. Unironically in the same post despite being, to my untrained eye, the same thing.
      - amiga386 1y ago
        The difference being that the authors of sysvinit didn't advertise obnoxious messages at boot time (https://systemd.io/SEPARATE_USR_IS_BROKEN/ https://systemd.io/SEPARATE_USR_IS_BROKEN/) and try to get the filesystem standards changed. One is like "I'll run some scripts in order, everything else is on you", the other is like "I'll take care of everything, I'll do that, WHAT YOU DIDN'T MOUNT /USR ? SHAME ON YOU I DON'T WANT TO DEAL WITH THAT CORNER-CASE"
        immibis 1y ago
        In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc). From the creators of systemd we also have GNOME, PulseAudio, and Wayland. They have some design philosophy in common. BTW most sysvinit distros barely even use sysvinit. sysvinit is a service monitor, similar to systemd but more primitive, but typically most of what it's configured to do is to launch some shell scripts on startup. We really have "systemd distros" and "ad-hoc script distros", not sysvinit distros ("ad-hoc" is not a pejorative). I don't know why they don't make init a shell script directly - you can do that, and it's typically done that way in initramfs.
        jcgl 1y ago
        > In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc). Name one thing you can do in sysvinit (or "ad-hoc script"-init) that you cannot do in systemd. With systemd, you're still entirely free to write your own artisinal shell spaghetti and jam it in alongside the otherwise clean unit structure.
- dathinab 1y ago
  no, it is that it adds complexity which is no longer needed especially for image based stuff it's a pain which includes OCI images for things like docker but also image based distros like e.g. ostree (as used through rpm-ostree by Atomic Fedora desktops like Fedora Silverblue, but also in similar but different forms something Ubuntu has been experimenting with)
  - 1oooqooq 1y ago
    if you're building containers with full systemd instead of the pid0 shim you're doing systemd wrong
    - deleted 1y ago
      [deleted]
    - dathinab 1y ago
      did you accidentally post on the wrong comment? Your comment seems fully unrelated to my point that overlaying images is much more a pain if the things you might want to shadow and/or extend are distributed or even duplicated across many different places when they could be just be in one place.
syncsynchalt 1y ago
I'm assuming you're referring to partitioning of boot-critical binaries into `/bin`, but "the reason for having a separate /usr" is even older and worse than that. In original Unix `/usr` was for home dirs[1], and was colonized by the operating system in 1971 when it no longer fit on a single 1.5MB RK05 disk. Nobody ever untangled that change and we've been living with the hack ever since. [1] https://lists.busybox.net/pipermail/busybox/2010-December/074114.html https://lists.busybox.net/pipermail/busybox/2010-December/07...
1718627440 1y ago
On the contrary. While the issue is not space, and hasn't been for a long time, a lot of devices are "network/cloud-first" and it is modern to load programs over the internet. It seams all the more useful, to have the distinction between core binaries, that are needed to boot, connect to the network and should be there in case the network setup became toast for debugging, and programs that can be loaded from the network on demand.

tremon 1y ago

In other words, the strongest argument for usrmerge is that there is no compelling argument against it?

mariusor 1y ago
I think the current strongest argument against it is that systemd complains when /usr is on a separate partition[1], and what its devs have weighed in on the matter[2]. [1] https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ https://freedesktop.org/wiki/Software/systemd/separate-usr-i... [2] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
- amiga386 1y ago
  sysvinit had no problem being told to mount /usr as soon as network was available, and if you set up an init script to run before /usr was available, but the script needed /usr, that was your own fault. systemd relies on things in /usr being available, including to decide which scripts to run, and mounting /usr would be one of those scripts, so it has a chicken-and-egg problem. But ah, it doesn't! Instead the world needs to make sure /usr is mounted before systemd even gets started, so systemd doesn't have to fix its bug. Personally, I don't mind /usr/bin merging with /bin, the benefit I can see is no more squabbling over whether something should be in /bin or not (i.e. is this tool needed to boot the system, or not?)
  - mariusor 1y ago
    > sysvinit had no problem being told to mount /usr [..] if you set up an init script to run before /usr was available, > the world needs to make sure /usr is mounted before systemd even gets started, so systemd doesn't have to fix its bug. Unironically in the same post despite being, to my untrained eye, the same thing.
    - amiga386 1y ago
      The difference being that the authors of sysvinit didn't advertise obnoxious messages at boot time (https://systemd.io/SEPARATE_USR_IS_BROKEN/ https://systemd.io/SEPARATE_USR_IS_BROKEN/) and try to get the filesystem standards changed. One is like "I'll run some scripts in order, everything else is on you", the other is like "I'll take care of everything, I'll do that, WHAT YOU DIDN'T MOUNT /USR ? SHAME ON YOU I DON'T WANT TO DEAL WITH THAT CORNER-CASE"
      - immibis 1y ago
        In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc). From the creators of systemd we also have GNOME, PulseAudio, and Wayland. They have some design philosophy in common. BTW most sysvinit distros barely even use sysvinit. sysvinit is a service monitor, similar to systemd but more primitive, but typically most of what it's configured to do is to launch some shell scripts on startup. We really have "systemd distros" and "ad-hoc script distros", not sysvinit distros ("ad-hoc" is not a pejorative). I don't know why they don't make init a shell script directly - you can do that, and it's typically done that way in initramfs.
        jcgl 1y ago
        > In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc). Name one thing you can do in sysvinit (or "ad-hoc script"-init) that you cannot do in systemd. With systemd, you're still entirely free to write your own artisinal shell spaghetti and jam it in alongside the otherwise clean unit structure.
dathinab 1y ago
no, it is that it adds complexity which is no longer needed especially for image based stuff it's a pain which includes OCI images for things like docker but also image based distros like e.g. ostree (as used through rpm-ostree by Atomic Fedora desktops like Fedora Silverblue, but also in similar but different forms something Ubuntu has been experimenting with)
- 1oooqooq 1y ago
  if you're building containers with full systemd instead of the pid0 shim you're doing systemd wrong
  - deleted 1y ago
    [deleted]
  - dathinab 1y ago
    did you accidentally post on the wrong comment? Your comment seems fully unrelated to my point that overlaying images is much more a pain if the things you might want to shadow and/or extend are distributed or even duplicated across many different places when they could be just be in one place.

syncsynchalt 1y ago

I'm assuming you're referring to partitioning of boot-critical binaries into `/bin`, but "the reason for having a separate /usr" is even older and worse than that. In original Unix `/usr` was for home dirs[1], and was colonized by the operating system in 1971 when it no longer fit on a single 1.5MB RK05 disk. Nobody ever untangled that change and we've been living with the hack ever since. [1] https://lists.busybox.net/pipermail/busybox/2010-December/074114.html https://lists.busybox.net/pipermail/busybox/2010-December/07...

1718627440 1y ago

On the contrary. While the issue is not space, and hasn't been for a long time, a lot of devices are "network/cloud-first" and it is modern to load programs over the internet. It seams all the more useful, to have the distinction between core binaries, that are needed to boot, connect to the network and should be there in case the network setup became toast for debugging, and programs that can be loaded from the network on demand.