3 ms·

I see that systemd is still doing this thing where they are trying to strong-arm all Linux distros into arbitrary stuff that someone decided is the only right w

I see that systemd is still doing this thing where they are trying to strong-arm all Linux distros into arbitrary stuff that someone decided is the only right way to do something: > 5.2.2. systemd message: System is tainted: unmerged-bin systemd upstream, since version 256, considers systems having separate /usr/bin and /usr/sbin directories noteworthy. At startup systemd emits a message to record this fact: System is tainted: unmerged-bin. It is recommended to ignore this message. Merging these directories manually is unsupported and will break future upgrades. Further details can be found in bug #1085370. No option to disable this either, per discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370

jcgl 1y ago
You may not like it, but “arbitrary” isn’t a fair description; there’s reasoning behind it that is over 10 years old: http://0pointer.net/blog/projects/stateless.html http://0pointer.net/blog/projects/stateless.html https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... That said, my knee-jerk is also that this is about strong-arming distros. Which leaves a bad taste in my mouth. I’d be interested to hear other viewpoints though.
- int_19h 1y ago
  Note that this is about a different thing - Debian has also merged its /bin into /usr/bin, but now systemd also wants /usr/bin and /usr/sbin to be merged.
  - jcgl 1y ago
    Oh thanks, I totally missed that distinctions. You’re right. My first thought is to wonder: why would systemd care about this then? Any idea? My second thought is: with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin? My understanding is that sbin has historically been useful to have statically linked binaries that can be made available early during boot without needing various lib dirs mounted. But that need seems obviated by a unified /usr…
    - NekkoDroid 1y ago
      > with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin? There really isn't any, the sysmlink being for compat. Early boot is nowadays taken over by an initrd/initramfs. Some say what you say sbin was for were actually the root /bin (early boot) and /usr/bin (elsewhere) but it was all just so arbitrary and no-one could actually agree on what is for what actually. Some say sbin is for static binaries, others for superuser binaries and either destinction really doesn't make sense nowadays as earlyboot is initrd and a lot of "superuser binaries" actually also are fine to use unprivlidged in certain scenarios (e.g. `mkfs.*` for making disk images) so having them in a separate dir is just arbitrary (e.g. `cat` can also fail if I cat the shadow file).
    - 1718627440 1y ago
      sbin is for binaries intended for the superuser, so it is only in the PATH for root, but not for anyone else. This is useful as it doesn't bloat the completions with stuff I never care to run anyways.
Arnavion 1y ago
>No option to disable this either, per discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370 The discussion in that bug is that the Debian maintainer (and upstream dev) is open to an upstream patch to add such an option.
- kasabali 1y ago
  > Debian maintainer (and upstream dev) is open to an upstream patch to add such an option Wild interpretation right here. There are only 2 realistic choices: Leave it as is or patch out the warning message in the Debian package Debian maintainer is clearly deflecting the responsibility here because everyone knows very well that upstream wouldn't accept such a patch. As it's already explained in the bug report, since Debian has no plan to do that migration in the near future, aforementioned warning isn't only useless and annoying, it's also potentially harmful, thus the correct action would be to remove it downstream like they did it in xscreensaver (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#84 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#84) But then they'd face the wrath of Lennart, so the only choice left is ignoring the report.
  - account42 1y ago
    Perhaps we need to have a concept of separation of upstream and distros.
spookie 1y ago
Lovely.
TacticalCoder 1y ago
Debian choosing systemd (not that it's a new decision) is the reason I'll be switching my Proxmox to FreeBSD/bhyve (FreeBSD has great ZFS support btw). Once I get the hypervisor systemd-free (no systemd on FreeBSD), I can then install a minimal distro in a VM mean to do containerization (like, say, the Talos Linux distro for K8s, that only has a few executables and they're all immutable) and then I can run containers that, by design, have something that is precisely not systemd as PID1. So life is good: there's a systemd-free world at the end of the tunnel.
- zahlman 1y ago
  > Debian choosing systemd (not that it's a new decision) is the reason I'll be switching my Proxmox to FreeBSD/bhyve Did you consider Devuan? Or is this just taking one annoyance as motivation to fix others at the same time?
creatonez 1y ago
Why do you think this is an attempt at a persuasion tactic? Taint flags in this context just means something that might be relevant to debugging. Which this condition might be, if people in the future are unfamiliar with a potentially anachronistic split between /usr/bin and /usr/sbin. The debug message isn't there to judge the morality of your configuration. It's actively improving your ability to continue to support both ways, by properly indicating what style of system it is for troubleshooting purposes.
- kasabali 1y ago
  > Why do you think this is an attempt at a persuasion tactic Because they said so: > As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration [1] 1. https://0pointer.de/blog/projects/the-biggest-myths.html https://0pointer.de/blog/projects/the-biggest-myths.html
  - creatonez 1y ago
    This was written 11 years before that debug log was added. Extremely loose connection. Things do actually change over the course of 11 years, believe it or not.
    - kasabali 1y ago
      It's their modus operandi and it haven't changed, believe or not. > it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so. [1] > Distros may deviate from this by patching this downstream, but by shipping this as secure default I do hope to gently push everybody in the same direction. > start pushing people gently to define GPT partition type UUIDs for missing archs > Let's generate a single gcc `#warning` message asking people to define partition type UUIDs for their architectures if they are missing. [3] [1] https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se... [2] https://lists.freedesktop.org/archives/systemd-devel/2011-March/001823.html https://lists.freedesktop.org/archives/systemd-devel/2011-Ma... [3] https://github.com/systemd/systemd/commit/d42e4fa258701ff5e094a39149f6cef327adcf52 https://github.com/systemd/systemd/commit/d42e4fa258701ff5e0...

jcgl 1y ago

You may not like it, but “arbitrary” isn’t a fair description; there’s reasoning behind it that is over 10 years old: http://0pointer.net/blog/projects/stateless.html http://0pointer.net/blog/projects/stateless.html https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... That said, my knee-jerk is also that this is about strong-arming distros. Which leaves a bad taste in my mouth. I’d be interested to hear other viewpoints though.

int_19h 1y ago
Note that this is about a different thing - Debian has also merged its /bin into /usr/bin, but now systemd also wants /usr/bin and /usr/sbin to be merged.
- jcgl 1y ago
  Oh thanks, I totally missed that distinctions. You’re right. My first thought is to wonder: why would systemd care about this then? Any idea? My second thought is: with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin? My understanding is that sbin has historically been useful to have statically linked binaries that can be made available early during boot without needing various lib dirs mounted. But that need seems obviated by a unified /usr…
  - NekkoDroid 1y ago
    > with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin? There really isn't any, the sysmlink being for compat. Early boot is nowadays taken over by an initrd/initramfs. Some say what you say sbin was for were actually the root /bin (early boot) and /usr/bin (elsewhere) but it was all just so arbitrary and no-one could actually agree on what is for what actually. Some say sbin is for static binaries, others for superuser binaries and either destinction really doesn't make sense nowadays as earlyboot is initrd and a lot of "superuser binaries" actually also are fine to use unprivlidged in certain scenarios (e.g. `mkfs.*` for making disk images) so having them in a separate dir is just arbitrary (e.g. `cat` can also fail if I cat the shadow file).
  - 1718627440 1y ago
    sbin is for binaries intended for the superuser, so it is only in the PATH for root, but not for anyone else. This is useful as it doesn't bloat the completions with stuff I never care to run anyways.

Arnavion 1y ago

>No option to disable this either, per discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370 The discussion in that bug is that the Debian maintainer (and upstream dev) is open to an upstream patch to add such an option.

kasabali 1y ago
> Debian maintainer (and upstream dev) is open to an upstream patch to add such an option Wild interpretation right here. There are only 2 realistic choices: Leave it as is or patch out the warning message in the Debian package Debian maintainer is clearly deflecting the responsibility here because everyone knows very well that upstream wouldn't accept such a patch. As it's already explained in the bug report, since Debian has no plan to do that migration in the near future, aforementioned warning isn't only useless and annoying, it's also potentially harmful, thus the correct action would be to remove it downstream like they did it in xscreensaver (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#84 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#84) But then they'd face the wrath of Lennart, so the only choice left is ignoring the report.
- account42 1y ago
  Perhaps we need to have a concept of separation of upstream and distros.

spookie 1y ago

Lovely.

TacticalCoder 1y ago

Debian choosing systemd (not that it's a new decision) is the reason I'll be switching my Proxmox to FreeBSD/bhyve (FreeBSD has great ZFS support btw). Once I get the hypervisor systemd-free (no systemd on FreeBSD), I can then install a minimal distro in a VM mean to do containerization (like, say, the Talos Linux distro for K8s, that only has a few executables and they're all immutable) and then I can run containers that, by design, have something that is precisely not systemd as PID1. So life is good: there's a systemd-free world at the end of the tunnel.

zahlman 1y ago
> Debian choosing systemd (not that it's a new decision) is the reason I'll be switching my Proxmox to FreeBSD/bhyve Did you consider Devuan? Or is this just taking one annoyance as motivation to fix others at the same time?

creatonez 1y ago

Why do you think this is an attempt at a persuasion tactic? Taint flags in this context just means something that might be relevant to debugging. Which this condition might be, if people in the future are unfamiliar with a potentially anachronistic split between /usr/bin and /usr/sbin. The debug message isn't there to judge the morality of your configuration. It's actively improving your ability to continue to support both ways, by properly indicating what style of system it is for troubleshooting purposes.

kasabali 1y ago
> Why do you think this is an attempt at a persuasion tactic Because they said so: > As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration [1] 1. https://0pointer.de/blog/projects/the-biggest-myths.html https://0pointer.de/blog/projects/the-biggest-myths.html
- creatonez 1y ago
  This was written 11 years before that debug log was added. Extremely loose connection. Things do actually change over the course of 11 years, believe it or not.
  - kasabali 1y ago
    It's their modus operandi and it haven't changed, believe or not. > it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so. [1] > Distros may deviate from this by patching this downstream, but by shipping this as secure default I do hope to gently push everybody in the same direction. > start pushing people gently to define GPT partition type UUIDs for missing archs > Let's generate a single gcc `#warning` message asking people to define partition type UUIDs for their architectures if they are missing. [3] [1] https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se... [2] https://lists.freedesktop.org/archives/systemd-devel/2011-March/001823.html https://lists.freedesktop.org/archives/systemd-devel/2011-Ma... [3] https://github.com/systemd/systemd/commit/d42e4fa258701ff5e094a39149f6cef327adcf52 https://github.com/systemd/systemd/commit/d42e4fa258701ff5e0...