5 ms·

The /usr merge is an example of something that a modern FHS might reflect.

by rascul 1y ago

curt15 1y ago
OS X doesn't have a merged /usr. On my Mac I see /bin as a separate directory, not a symlink into `/usr`. Does Linux have a compelling reason that OS X lacks?
- mariusor 1y ago
  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.
- jcgl 1y ago
  Merged /usr is one (increasingly accepted?) means of implementing image-based distros. New OS version, new /usr parition.
- dathinab 1y ago
  it makes things more complicated without any benefits (at least not anymore) this doesn't matter for OS X which main changes mostly tend to be diverging away from it's roots into a fully proprietary direction but it does matter if you build image based Linux distros which might be the future of Linux
- comex 1y ago
  macOS didn't merge /usr, but it did do something sorta related. One of the purposes of usrmerge is to cleanly separate the read-only and read-write parts of the system. This helps with image-based distros, where /usr can be on its own read-only filesystem, and related use cases such as [1]. Usrmerge is not required for image-based distros to work [2], but it makes things cleaner. macOS, starting in 2019, is also an 'image-based distro', in that it has a read-only filesystem for system files and a separate read-write filesystem for user data. However, the read-only filesystem is mounted at / instead of /usr. Several different paths under the root need to be writable [3], which is implemented by having a single read-write filesystem (/System/Volumes/Data) plus a number of "firmlinks" from paths in the read-only filesystem to corresponding paths in the read-write filesystem. Firmlinks are a bespoke kernel feature invented for this purpose. Both approaches have their advantages and disadvantages. The macOS approach is nice in that the system filesystem contains _all_ read-only files/directories, whereas under "distro in /usr" scheme, you need a separate tmpfs at / to contain the mount points and the symlinks into /usr. But "distro in /usr" has the advantage of making the separation between read-only and read-write files simpler and more visible to the user. Relatedly, macOS's scheme has the disadvantage that every writable file has two separate paths, one with /System/Volumes/Data and one without. But "distro in /usr" has the opposite disadvantage, in that a lot of read-only files have two separate paths, one with /usr and one without. Finally, macOS's scheme has the disadvantage that it required inventing and using firmlinks. Linux can already achieve similar effects using bind mounts or overlayfs, but those have minor disadvantages (bind mounts are more annoying to set up and tear down; overlayfs has a bit of performance overhead). Actual firmlinks are not necessarily any better, though, since they don't have a clear story for being shared between containers (which macOS does not support). It is nice that "distro in /usr" doesn't require any such complexity. Ultimately, the constraints and motivations on both sides are quite different. macOS couldn't have gotten everything read-only under one directory as easily because it has /System in addition to /usr. macOS doesn't have containers. macOS doesn't have different distros with different filesystem layouts and deployment mechanisms. And philosophically, for all that people accuse systemd of departing from Unix design principles, systemd seems to see itself as evolving the Unix design, whereas macOS tends to treat Unix like some legacy thing. It's no surprise that systemd would try to improve on Unix with things like "/bin points to /usr/bin" while macOS would leave the Unix bits as-is. [1] https://lwn.net/Articles/890463/ https://lwn.net/Articles/890463/ [2] https://blog.verbum.org/2024/10/22/why-bootc-doesnt-require-usr-merge/ https://blog.verbum.org/2024/10/22/why-bootc-doesnt-require-... [3] https://eclecticlight.co/2023/07/22/how-macos-depends-on-firmlinks/ https://eclecticlight.co/2023/07/22/how-macos-depends-on-fir...

The /usr merge is an example of something that a modern FHS might reflect.

by rascul 1y ago

The /usr merge is an example of something that a modern FHS might reflect.

OS X doesn't have a merged /usr. On my Mac I see /bin as a separate directory, not a symlink into `/usr`. Does Linux have a compelling reason that OS X lacks?

mariusor 1y ago
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.
jcgl 1y ago
Merged /usr is one (increasingly accepted?) means of implementing image-based distros. New OS version, new /usr parition.
dathinab 1y ago
it makes things more complicated without any benefits (at least not anymore) this doesn't matter for OS X which main changes mostly tend to be diverging away from it's roots into a fully proprietary direction but it does matter if you build image based Linux distros which might be the future of Linux
comex 1y ago
macOS didn't merge /usr, but it did do something sorta related. One of the purposes of usrmerge is to cleanly separate the read-only and read-write parts of the system. This helps with image-based distros, where /usr can be on its own read-only filesystem, and related use cases such as [1]. Usrmerge is not required for image-based distros to work [2], but it makes things cleaner. macOS, starting in 2019, is also an 'image-based distro', in that it has a read-only filesystem for system files and a separate read-write filesystem for user data. However, the read-only filesystem is mounted at / instead of /usr. Several different paths under the root need to be writable [3], which is implemented by having a single read-write filesystem (/System/Volumes/Data) plus a number of "firmlinks" from paths in the read-only filesystem to corresponding paths in the read-write filesystem. Firmlinks are a bespoke kernel feature invented for this purpose. Both approaches have their advantages and disadvantages. The macOS approach is nice in that the system filesystem contains _all_ read-only files/directories, whereas under "distro in /usr" scheme, you need a separate tmpfs at / to contain the mount points and the symlinks into /usr. But "distro in /usr" has the advantage of making the separation between read-only and read-write files simpler and more visible to the user. Relatedly, macOS's scheme has the disadvantage that every writable file has two separate paths, one with /System/Volumes/Data and one without. But "distro in /usr" has the opposite disadvantage, in that a lot of read-only files have two separate paths, one with /usr and one without. Finally, macOS's scheme has the disadvantage that it required inventing and using firmlinks. Linux can already achieve similar effects using bind mounts or overlayfs, but those have minor disadvantages (bind mounts are more annoying to set up and tear down; overlayfs has a bit of performance overhead). Actual firmlinks are not necessarily any better, though, since they don't have a clear story for being shared between containers (which macOS does not support). It is nice that "distro in /usr" doesn't require any such complexity. Ultimately, the constraints and motivations on both sides are quite different. macOS couldn't have gotten everything read-only under one directory as easily because it has /System in addition to /usr. macOS doesn't have containers. macOS doesn't have different distros with different filesystem layouts and deployment mechanisms. And philosophically, for all that people accuse systemd of departing from Unix design principles, systemd seems to see itself as evolving the Unix design, whereas macOS tends to treat Unix like some legacy thing. It's no surprise that systemd would try to improve on Unix with things like "/bin points to /usr/bin" while macOS would leave the Unix bits as-is. [1] https://lwn.net/Articles/890463/ https://lwn.net/Articles/890463/ [2] https://blog.verbum.org/2024/10/22/why-bootc-doesnt-require-usr-merge/ https://blog.verbum.org/2024/10/22/why-bootc-doesnt-require-... [3] https://eclecticlight.co/2023/07/22/how-macos-depends-on-firmlinks/ https://eclecticlight.co/2023/07/22/how-macos-depends-on-fir...