3 ms·

I thought all the distros already did this with the /bin and /usr/bin merge; it's like that on at least Void and Arch Linux anyway. The whole reinterpreting of

by arp242 3y ago

I thought all the distros already did this with the /bin and /usr/bin merge; it's like that on at least Void and Arch Linux anyway. The whole reinterpreting of "static bin" to "system bin" never made sense to me.

mrweasel 3y ago
Debian is merging /bin and /usr/bin as well. The "static bin" makes sense, if you follow it very strictly, in that case it ensures that regardless of how much you damage libraries, everything in /bin (and /sbin) will still work. If you merge /bin and /usr/bin it becomes unclear which binaries you can rely on in an emergency. There's simply no easy way to tell at a glance. Merging bin and sbin makes a little more sense to me. It avoids the very common scenarios where you type "sudo mount" or "sudo ip addr", something like that, and our shell just return "command not found", simply because it's not in the users $PATH. It's a minor convenience factor, but I can't see it making anything worse.
- spookie 3y ago
  Completely agree.
- andrewshadura 3y ago
  In the event of an emergency, you rely on initramfs.
jodrellblank 3y ago
What about the reinterpreting of "usr" from "user" to "unix system resources" after Unix overflowed the original 1.5 MB OS drive on Thompson and Richie's PDP-7? > "The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented" - http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...
- blueflow 3y ago
  The term "UNIX System Resources" for /usr is documented no earlier than 2003. This is about 30 years after the events you refer to.
- PlutoIsAPlanet 3y ago
  In the state of immutable distros that use a modern image format (so not Android), /usr is read only and managed by the system only anyway. imho we should go the entire way and move /home to /var/home, so anything other than /etc and /var can be read-only, I already place /var on a separate partition with /var/home on RHEL installs.
  - NekkoDroid 3y ago
    fun fact: you can already have almost everything except /var/ and /home/ read-only (there are still some legacy problems in /etc/, namely passwd, shadow, group... that I think userdbd can handle, but are there because of backwards compat). You can add to /etc/ by using systemd-confexts and overlaying files onto there (and systemd-sysext for /usr/). ~~Tho you have to choose the software you run somewhat carefully~~ Lets rather say, the infrastructure is already mostly there for this to be possible. I'd love to have a way to have root really only be a read-only tmpfs that is only used for mount points (specifically /usr/, /var/ and /home/) and symlinks (for example /var/home/ to /home/ if no separate partition is wanted).
    - nurple 3y ago
      Impermanence is an interesting take on this using NixOS https://github.com/nix-community/impermanence https://github.com/nix-community/impermanence

by arp242 3y ago

mrweasel 3y ago

Debian is merging /bin and /usr/bin as well. The "static bin" makes sense, if you follow it very strictly, in that case it ensures that regardless of how much you damage libraries, everything in /bin (and /sbin) will still work. If you merge /bin and /usr/bin it becomes unclear which binaries you can rely on in an emergency. There's simply no easy way to tell at a glance. Merging bin and sbin makes a little more sense to me. It avoids the very common scenarios where you type "sudo mount" or "sudo ip addr", something like that, and our shell just return "command not found", simply because it's not in the users $PATH. It's a minor convenience factor, but I can't see it making anything worse.

spookie 3y ago
Completely agree.
andrewshadura 3y ago
In the event of an emergency, you rely on initramfs.

jodrellblank 3y ago

What about the reinterpreting of "usr" from "user" to "unix system resources" after Unix overflowed the original 1.5 MB OS drive on Thompson and Richie's PDP-7? > "The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented" - http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...

blueflow 3y ago
The term "UNIX System Resources" for /usr is documented no earlier than 2003. This is about 30 years after the events you refer to.
PlutoIsAPlanet 3y ago
In the state of immutable distros that use a modern image format (so not Android), /usr is read only and managed by the system only anyway. imho we should go the entire way and move /home to /var/home, so anything other than /etc and /var can be read-only, I already place /var on a separate partition with /var/home on RHEL installs.
- NekkoDroid 3y ago
  fun fact: you can already have almost everything except /var/ and /home/ read-only (there are still some legacy problems in /etc/, namely passwd, shadow, group... that I think userdbd can handle, but are there because of backwards compat). You can add to /etc/ by using systemd-confexts and overlaying files onto there (and systemd-sysext for /usr/). ~~Tho you have to choose the software you run somewhat carefully~~ Lets rather say, the infrastructure is already mostly there for this to be possible. I'd love to have a way to have root really only be a read-only tmpfs that is only used for mount points (specifically /usr/, /var/ and /home/) and symlinks (for example /var/home/ to /home/ if no separate partition is wanted).
  - nurple 3y ago
    Impermanence is an interesting take on this using NixOS https://github.com/nix-community/impermanence https://github.com/nix-community/impermanence