5 ms·

I don't get why people are so against systemd. I'm very happy using since it became available on debian. It's simply a clone of Apple's launchd. If it's about

I don't get why people are so against systemd. I'm very happy using since it became available on debian. It's simply a clone of Apple's launchd. If it's about 'choice', go swap out your kernel for hurd or sth.

ldng 7y ago
It is not simply a clone of Apple's launchd. It's a lot more. Too much at that. It's about it getting in the way.
- jbverschoor 7y ago
  Afaik they both do: - init - dependency management - inetd-type spawning - timed / cron launching - managing processes depending on network state or filesystem mounting
  - chongli 7y ago
    You’re missing some: - logging (replacing syslog) - login (replacing login managers such as ConsoleKit) - network configuration - tmpfiles - timedated (replacing ntpd) - udev (userspace /dev manager) - boot (replacing boot managers like grub) As you can see, systemd has taken over a great many things that are totally unrelated to its core mission of replacing sysvinit. The fact that it continues to grow and take over all these other facilities and the fact that the systemd team actively fights people trying to develop alternatives is why people hate the project so much.
    - throw0101a 7y ago
      Per JWZ's Law, I am waiting for it to read mail: * https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles
    - fulafel 7y ago
      - systemd-nspawn (replacing Docker) - systemd-resolved (DNS resolver) - systemd-cryptsetup etc etc
    - thenewnewguy 7y ago
      I see we've reached the point in any systemd-related debate where someone tries to claim systemd is bloated by listing off projects that are not part of the systemd init system and just happen to share a common name and dev team.
      - chongli 7y ago
        The problem isn't the common name, it's the tight coupling between components. This is antithetical to the Linux philosophy, which emphasizes modularity, interchangeability, and configurability.
        cycloptic 7y ago
        That is not the Linux philosophy. According to a usenet post made by Linus Torvalds in 1996 [0], the Linux philosophy is "Do it yourself." [0] https://groups.google.com/groups?&selm=Pine.LNX.3.91.961016155929.27735D-100000%40linux.cs.Helsinki.FI https://groups.google.com/groups?&selm=Pine.LNX.3.91.9610161...
        zzo38computer 7y ago
        When you wish to cite Usenet articles, please cite the message ID. (I also think that those who use mailing lists should just use NNTP instead, possibly having NNTP as an alternative interface to the same data.)
        teddyh 7y ago
        In this case, the Message-ID seems to be <Pine.LNX.3.91.961016155929.27735D-100000@linux.cs.Helsinki.FI>.
        thenewnewguy 7y ago
        I assume you mean the UNIX philosophy? Regardless, almost all of said components are optional, systemd doesn't in any way force you to use them. As a matter of fact many of the components you listed have alternatives that are more popular than the systemd tool (NetworkManager over systemd-networkd, GRUB2 over systemd-boot, etc).
    - throw0101a 7y ago
      > As you can see, systemd has taken over a great many things that are totally unrelated to its core mission of replacing sysvinit. This is my pet peeve: systemd-as-init is / may be fine. systemd-as-NTPd or systemd-with-udevd seems like overly tight coupling.
outadoc 7y ago
+1. I don't know about the big picture, but as a user, systemd is just damn convenient. I don't want to have to code every single little daemon I need in shell scripts. systemd handles most of that so neatly.
simion314 7y ago
The issue I noticed are - systemd supporters are mainly desktop users, so their opinions are irrelevant because as a desktop user the only thing you might do is restart a service, is important to listen to server admins that know what they are talking about - GNOME (other Red Hat tech) depends on a systemd component and refuses patches to make it independent, so basically GNOME is forcing systemd adoption and is trying to block alternatives by refusing patches - systemd projects and fans will ask you to create a better alternative to systemd if you don't like it, but if you try to promote an alternative they will try to block the alternatives by refusing to accept patches to keep projects systemd independent. Monoclultures are bad, when systemd will o longer be popular and we want to implement a better succesor we will discover that many things are hard coded to depend on some it's many components. About what is the best init system, I don't know , I am desktop user, and as I said all desktop users opinions are probably "it works for me so you are wrong"
- doublerabbit 7y ago
  I dislike it for the fact if a process hangs or if your network isn’t ready you get “Starting process - 2/5minutes” If your trying to hastely safe shutdown “Waiting for process to stop - 3/8minutes” Sure, you can alter the timer but that’s then just another task I shouldn’t need to do. Dependencies within unit files It’s own log formatting in a binary format It’s icky, it feels clunky and while it works it doesn’t feel smooth.
  - PlutoIsAPlanet 7y ago
    This isn't actually an issue with systemd, it's just how the distro has configured it. systemd is really good at doing what it's told, if it's told something bad it will do something bad.
- ninkendo 7y ago
  > systemd supporters are mainly desktop users > is important to listen to server admins that know what they are talking about Huh? I got on the systemd train when race conditions with pidfiles caused essential services not to restart correctly for the umpteenth time on a small subset of the thousands of bare metal servers I managed. Not a single sysadmin I worked with liked anything about sysvinit. Nearly every distro-provided init script for the services we cared about had some sort of subtle bug which we had to manually fix with our configuration management. Or maybe somebody had been diagnosing an issue and manually run “sudo /etc/init.d/someservice start” and now congratulations, the service inherited the cwd of the person who ran the init script. Or you have to deal with inconsistent log rotation behavior, or the service coming up before the network was ready on boot (better rename the symlink to 99_myservice!) I don’t know where people get the idea that sysadmins prefer sysvinit. Maybe ones that only run one or two servers? After having managed tens of thousands of them across many datacenters, systemd is a clear and obvious win.
harryruhr 7y ago
1. the infamous "a start/stop job is running" message. 2. Some services just won't start at boot. E.g. reproducible ntpd on CentOS 7 3. Sometimes my notebook, running Debian with systemd, won't shut down an I had to shut it down hard by ling pressing the power button. Never had this kinds of problems with any other init systems.

ldng 7y ago

It is not simply a clone of Apple's launchd. It's a lot more. Too much at that. It's about it getting in the way.

jbverschoor 7y ago
Afaik they both do: - init - dependency management - inetd-type spawning - timed / cron launching - managing processes depending on network state or filesystem mounting
- chongli 7y ago
  You’re missing some: - logging (replacing syslog) - login (replacing login managers such as ConsoleKit) - network configuration - tmpfiles - timedated (replacing ntpd) - udev (userspace /dev manager) - boot (replacing boot managers like grub) As you can see, systemd has taken over a great many things that are totally unrelated to its core mission of replacing sysvinit. The fact that it continues to grow and take over all these other facilities and the fact that the systemd team actively fights people trying to develop alternatives is why people hate the project so much.
  - throw0101a 7y ago
    Per JWZ's Law, I am waiting for it to read mail: * https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles
  - fulafel 7y ago
    - systemd-nspawn (replacing Docker) - systemd-resolved (DNS resolver) - systemd-cryptsetup etc etc
  - thenewnewguy 7y ago
    I see we've reached the point in any systemd-related debate where someone tries to claim systemd is bloated by listing off projects that are not part of the systemd init system and just happen to share a common name and dev team.
    - chongli 7y ago
      The problem isn't the common name, it's the tight coupling between components. This is antithetical to the Linux philosophy, which emphasizes modularity, interchangeability, and configurability.
      - cycloptic 7y ago
        That is not the Linux philosophy. According to a usenet post made by Linus Torvalds in 1996 [0], the Linux philosophy is "Do it yourself." [0] https://groups.google.com/groups?&selm=Pine.LNX.3.91.961016155929.27735D-100000%40linux.cs.Helsinki.FI https://groups.google.com/groups?&selm=Pine.LNX.3.91.9610161...
        zzo38computer 7y ago
        When you wish to cite Usenet articles, please cite the message ID. (I also think that those who use mailing lists should just use NNTP instead, possibly having NNTP as an alternative interface to the same data.)
        teddyh 7y ago
        In this case, the Message-ID seems to be <Pine.LNX.3.91.961016155929.27735D-100000@linux.cs.Helsinki.FI>.
      - thenewnewguy 7y ago
        I assume you mean the UNIX philosophy? Regardless, almost all of said components are optional, systemd doesn't in any way force you to use them. As a matter of fact many of the components you listed have alternatives that are more popular than the systemd tool (NetworkManager over systemd-networkd, GRUB2 over systemd-boot, etc).
  - throw0101a 7y ago
    > As you can see, systemd has taken over a great many things that are totally unrelated to its core mission of replacing sysvinit. This is my pet peeve: systemd-as-init is / may be fine. systemd-as-NTPd or systemd-with-udevd seems like overly tight coupling.

outadoc 7y ago

+1. I don't know about the big picture, but as a user, systemd is just damn convenient. I don't want to have to code every single little daemon I need in shell scripts. systemd handles most of that so neatly.

simion314 7y ago

The issue I noticed are - systemd supporters are mainly desktop users, so their opinions are irrelevant because as a desktop user the only thing you might do is restart a service, is important to listen to server admins that know what they are talking about - GNOME (other Red Hat tech) depends on a systemd component and refuses patches to make it independent, so basically GNOME is forcing systemd adoption and is trying to block alternatives by refusing patches - systemd projects and fans will ask you to create a better alternative to systemd if you don't like it, but if you try to promote an alternative they will try to block the alternatives by refusing to accept patches to keep projects systemd independent. Monoclultures are bad, when systemd will o longer be popular and we want to implement a better succesor we will discover that many things are hard coded to depend on some it's many components. About what is the best init system, I don't know , I am desktop user, and as I said all desktop users opinions are probably "it works for me so you are wrong"

doublerabbit 7y ago
I dislike it for the fact if a process hangs or if your network isn’t ready you get “Starting process - 2/5minutes” If your trying to hastely safe shutdown “Waiting for process to stop - 3/8minutes” Sure, you can alter the timer but that’s then just another task I shouldn’t need to do. Dependencies within unit files It’s own log formatting in a binary format It’s icky, it feels clunky and while it works it doesn’t feel smooth.
- PlutoIsAPlanet 7y ago
  This isn't actually an issue with systemd, it's just how the distro has configured it. systemd is really good at doing what it's told, if it's told something bad it will do something bad.
ninkendo 7y ago
> systemd supporters are mainly desktop users > is important to listen to server admins that know what they are talking about Huh? I got on the systemd train when race conditions with pidfiles caused essential services not to restart correctly for the umpteenth time on a small subset of the thousands of bare metal servers I managed. Not a single sysadmin I worked with liked anything about sysvinit. Nearly every distro-provided init script for the services we cared about had some sort of subtle bug which we had to manually fix with our configuration management. Or maybe somebody had been diagnosing an issue and manually run “sudo /etc/init.d/someservice start” and now congratulations, the service inherited the cwd of the person who ran the init script. Or you have to deal with inconsistent log rotation behavior, or the service coming up before the network was ready on boot (better rename the symlink to 99_myservice!) I don’t know where people get the idea that sysadmins prefer sysvinit. Maybe ones that only run one or two servers? After having managed tens of thousands of them across many datacenters, systemd is a clear and obvious win.

harryruhr 7y ago

1. the infamous "a start/stop job is running" message. 2. Some services just won't start at boot. E.g. reproducible ntpd on CentOS 7 3. Sometimes my notebook, running Debian with systemd, won't shut down an I had to shut it down hard by ling pressing the power button. Never had this kinds of problems with any other init systems.