4 ms·

Can someone explain to me what systemd detractors are actually worried about? In practical, not purely philosophical terms?

toast0 11y ago
I haven't yet used systemd, so maybe it works great, but here are the warning flags: 0) pulseaudio 1) there used to be many choices for startup that were relatively easy yo switch between. Systemd seems to be hard to switch to and back. 2) systemd seems to keep reimplimenting old things in its suite, without any regard for the previous experience. Fundamentally, I worry that one day when in update my debian box, things are going to be super broken as a result of systemd subsuming many pieces of the system with new buggy versions that are not easy to stop using. This is in contrast to openbsd: Their developers also have a poor attitude, and reimplement old ideas, but they develop in a modular fashion, and are conscious of past experience. By modular, I mean I can take their ntp server if i like it, without switching everything. And it's relative easy to switch between their https and others, etc.
- beatpanda 11y ago
  So, a lot of that sounds like philosophical disagreement. The one practical concern in there is "I worry that one day when I update my debian box, things are going to be super broken", and it appears that by "broken" you mean "requiring systemd". I still don't understand what the problem is.
  - digi_owl 11y ago
    How is this for practical: Update box, get systemd, fail to boot because of a fstab entry you barely remember was there that was acceptable to mount for years, but systemd stops the boot dead on. Or stall on reboot/shutdown because they still can't get straight that NFS is a mount over the network, and so needs to be unmounted before taking the network down. their DNS client that quietly grew a cache was found to be susceptible to cache poisoning. A issue that has been known about and protected against for a decade by more mature DNS implementations. And i think their dhcp client (yep, it has that to) ignores a bunch of best practices/security in the name of speed. The whole edifice is a NIH of cards. This even though the project leadership is supposedly very keen on security...
    - the_why_of_y 11y ago
      Systemd correctly implements the "noauto" and "nofail" keywords in fstab(5) in the way they have always been documented: if neither of these is specified for a filesystem, then that file system will be mounted at boot time and a failed attempt to mount that filesystem implies a boot failure. The fact that previous init scripts gladly ignored these failures does not reflect negatively on systemd but on those init scripts. By the way, FreeBSD has the same options, except that "nofail" is called "failok".
      - digi_owl 11y ago
        Odd, i find nothing in the fstab man file about nofail. And all that the mount man file says on it is that it suppresses error messages. Neither dictates any specific behavior when said errors show up.
        the_why_of_y 11y ago
        Ok, it is younger than I thought, it was added in 2008 so more conservative veteran UNIX admins might not have heard of it: Util-linux-ng 2.14 Release Notes (09-Jun-2008) ============================================== Release highlights ------------------ mount(8) supports new "nofail" mount option. Then it wasn't documented for 2 years, the commit that adds it to the fstab.5 man page is from 2010: https://github.com/karelzak/util-linux/commit/abe3d704b6aeb6b82ff32e8599edb56525cdfd72 https://github.com/karelzak/util-linux/commit/abe3d704b6aeb6... Interestingly, it pre-dates the similar FreeBSD parameter by 3 years: https://svnweb.freebsd.org/base?view=revision&revision=222832 https://svnweb.freebsd.org/base?view=revision&revision=22283... Add a special mount option "failok" to indicate that the administrator wants the system to proceed to boot without bailing out into single user mode, even when the file system can not be successfully mounted. Oh and people are of course invited to down-vote me again, I've got karma to burn, and the evidence that systemd is doing things in exactly the same way as FreeBSD clearly needs to be suppressed if we want to maintain our regular rituals of pointless outrage on this site.
        11y ago
  - toast0 11y ago
    I'm not necessarily worried about 'requiring systemd', I'm more worried about requiring systemd-component X where component X replaces an existing service I had installed, and is a broken reimplementation, leading to system doesn't boot, doesn't bring up network, doesn't respect my previous settings, shares my data with the world, is susceptible to security bugs that were fixed in mainstream implementations many years ago, etc.

toast0 11y ago

I haven't yet used systemd, so maybe it works great, but here are the warning flags: 0) pulseaudio 1) there used to be many choices for startup that were relatively easy yo switch between. Systemd seems to be hard to switch to and back. 2) systemd seems to keep reimplimenting old things in its suite, without any regard for the previous experience. Fundamentally, I worry that one day when in update my debian box, things are going to be super broken as a result of systemd subsuming many pieces of the system with new buggy versions that are not easy to stop using. This is in contrast to openbsd: Their developers also have a poor attitude, and reimplement old ideas, but they develop in a modular fashion, and are conscious of past experience. By modular, I mean I can take their ntp server if i like it, without switching everything. And it's relative easy to switch between their https and others, etc.

beatpanda 11y ago
So, a lot of that sounds like philosophical disagreement. The one practical concern in there is "I worry that one day when I update my debian box, things are going to be super broken", and it appears that by "broken" you mean "requiring systemd". I still don't understand what the problem is.
- digi_owl 11y ago
  How is this for practical: Update box, get systemd, fail to boot because of a fstab entry you barely remember was there that was acceptable to mount for years, but systemd stops the boot dead on. Or stall on reboot/shutdown because they still can't get straight that NFS is a mount over the network, and so needs to be unmounted before taking the network down. their DNS client that quietly grew a cache was found to be susceptible to cache poisoning. A issue that has been known about and protected against for a decade by more mature DNS implementations. And i think their dhcp client (yep, it has that to) ignores a bunch of best practices/security in the name of speed. The whole edifice is a NIH of cards. This even though the project leadership is supposedly very keen on security...
  - the_why_of_y 11y ago
    Systemd correctly implements the "noauto" and "nofail" keywords in fstab(5) in the way they have always been documented: if neither of these is specified for a filesystem, then that file system will be mounted at boot time and a failed attempt to mount that filesystem implies a boot failure. The fact that previous init scripts gladly ignored these failures does not reflect negatively on systemd but on those init scripts. By the way, FreeBSD has the same options, except that "nofail" is called "failok".
    - digi_owl 11y ago
      Odd, i find nothing in the fstab man file about nofail. And all that the mount man file says on it is that it suppresses error messages. Neither dictates any specific behavior when said errors show up.
      - the_why_of_y 11y ago
        Ok, it is younger than I thought, it was added in 2008 so more conservative veteran UNIX admins might not have heard of it: Util-linux-ng 2.14 Release Notes (09-Jun-2008) ============================================== Release highlights ------------------ mount(8) supports new "nofail" mount option. Then it wasn't documented for 2 years, the commit that adds it to the fstab.5 man page is from 2010: https://github.com/karelzak/util-linux/commit/abe3d704b6aeb6b82ff32e8599edb56525cdfd72 https://github.com/karelzak/util-linux/commit/abe3d704b6aeb6... Interestingly, it pre-dates the similar FreeBSD parameter by 3 years: https://svnweb.freebsd.org/base?view=revision&revision=222832 https://svnweb.freebsd.org/base?view=revision&revision=22283... Add a special mount option "failok" to indicate that the administrator wants the system to proceed to boot without bailing out into single user mode, even when the file system can not be successfully mounted. Oh and people are of course invited to down-vote me again, I've got karma to burn, and the evidence that systemd is doing things in exactly the same way as FreeBSD clearly needs to be suppressed if we want to maintain our regular rituals of pointless outrage on this site.
        11y ago
- toast0 11y ago
  I'm not necessarily worried about 'requiring systemd', I'm more worried about requiring systemd-component X where component X replaces an existing service I had installed, and is a broken reimplementation, leading to system doesn't boot, doesn't bring up network, doesn't respect my previous settings, shares my data with the world, is susceptible to security bugs that were fixed in mainstream implementations many years ago, etc.