7 ms·

The tragedy of systemd is that it's the wrong solution to a real problem. Because most people against systemd will keep saying that the old init system was ok,

The tragedy of systemd is that it's the wrong solution to a real problem. Because most people against systemd will keep saying that the old init system was ok, they don't move forward trying to provide a true alternative. So systemd became a standard despite the issues, because it solves certain real problems that people have, even if not great.

kfwhp 8y ago
systemd became a standard because the guy works at Red Hat so he can make GNOME require it (there is no way to use GNOME without systemd; distros that allow that such as Gentoo do so by patching GNOME, which is costly.) I agree that a more modern init system is necessary, but the idea of systemd is meh and the implementation is subpar.
- tapoxi 8y ago
  systemd became a standard because Debian adopted it after a lengthy discussion, partially because big Debian users like Spotify expressed an interest in systemd. https://lists.debian.org/debian-ctte/2014/01/msg00287.html https://lists.debian.org/debian-ctte/2014/01/msg00287.html
- nickik 8y ago
  Conspiracy nonsense. It became standard because the existing solutions were crappy and nobody else bothered to do anything about it.
  - kfwhp 8y ago
    I don't believe this to be a "conspiracy". It's nothing shadowy, really. What they did is completely natural. That doesn't mean I support the idea though.
- kevin_b_er 8y ago
  The intentional and willful breaking of screen and tmux was to fix a GNOME bug of GNOME not closing up as it should when the user logs out, so systemd was changed to mass kill processes. The interplay between GNOME and systemd in backroom dealings is a major pain point.
  - kbenson 8y ago
    I think that's an oversimplification. There are definitely cases where some thing started as a daemon under a user session, graphical or not, should be killed to be safe. For example, ssh-agent. There are other things that are meant to be left around, as that's their purpose, such as screen and tmux. I would say the safe solution would be to kill everything in the user session at multiple levels (GNOME, and user session management demon like logind, etc), and to provide a defined safe way for the very few programs that want to stick around to do so. That seems like what systemd came up with as well.
- taffer 8y ago
  You make it sound like the systemd author was something the CEO of all Linux Distros. The maintainers of Arch Linux have given an explicit list[1] of the reasons why they decided to introduce systemd: 0) it is hotplug capable 1) we can know the state of the system 2) it is modular 3) it allows dbus/udev to go back to doing the task they are meant to do 4) we can reduce the number of explicit ordering dependencies between daemons 5) we get a lot of security/sandboxing features for free 6) systemd service files can be written and distributed upstream 7) systemd is a cross-distro project 8) logind will finally deliver on what consolekit was supposed to do 9) systemd is fast [1]: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
sametmax 8y ago
I concur. Before systemd, I used supervisor because I wanted to avoid using any init system like hell. Since systemd, I just do a service file. So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need. I'm sure all the power user complaints about systemd are legitimate, but I really don't care about those. I just want an easy way to setup custom deamon on ubuntu and centos. Provide a better system, that solve those problems, and I'll use it. I really don't care as long as my problem is solved.
- onli 8y ago
  > So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need. Same couldn't be said about supervisor, the solution you already had running (well, maybe strike init)?
  - sametmax 8y ago
    It's not installed by default on any distro. I don't want to install something as basic as an init system. And it's not installed by default because it doesn't solve the problem of a service dependancy graph.
    - onli 8y ago
      Sorry, but that first argument seems a bit random to me. Couldn't even use a proper editor like nano with that argumentation, having a usable editor available is after all also pretty basic. I doubt that supervisor is not installed because of not solving something it evidently does not want to solve, but that argument at least looks valid to me. Just in case you are not aware, https://github.com/Supervisor/supervisor/issues/122 https://github.com/Supervisor/supervisor/issues/122 lists two solutions (wait_for_it.sh and a supervisor plugin that adds dependency resolution).
      - kbenson 8y ago
upofadown 8y ago
>Because most people against systemd will keep saying that the old init system was ok, ... There isn't and wasn't hardly anyone saying that. It is and was well known that there were better things out there than the hacked up sysV style init systems produced by the various Linux distributions. This is a common strawman that seems to get rolled out any time any discussion involves systemd.
- antirez 8y ago
  A few of the authors of one of the Debian based distributions dropping systemd are friends of mine and all of them see things in that way, that the good old init is fine and there is no need to replace it. In the Facebook group where they use to stay the others I don't know first-hand seem to share this POV.
- nickik 8y ago
  And yet basically no alternative to systemd was produced by any of those people.
  - bluejekyll 8y ago
    Does upstart not count as an alternative?
    - loeg 8y ago
      Is upstart better in any way?
      - sliken 8y ago
        Upstart doesn't include implementations on NTP, DNS, DHCP, or anything that opens a network port. It does however allow parallel boots with dependency analysis for quick boots. Systemd on the other hand seems to be trying to take over syslog, ntpd, dhcpd, named, and related with generally poorer implementations. Feature creep seems constant with systemd, for no particularly good reason.
    - 8y ago
isostatic 8y ago
But it's not just replacing init - it's replacing a dozen other services including things like ntp or dns, and often it's replacing them with inferior solutions.
- antirez 8y ago
  Yes, that's a design problem due to what the systemd main author believes to be a good thing.
- nickik 8y ago
  systemd can be used without most of these things. systemd as a project has other services in but those you can use or not use. And the claim that they are 'inferior solutions' is just absolutely false in most cases. It often replaced horrible old tools that haven't been updated in 30 years. It often provides far better interfaces and tooling then the existing solutions.
  - isostatic 8y ago
    The DNS resolver seems to break DNS, the time system no longer acts as a server This isn't necessarily a problem with the systemd project, it's more on the distros that bundle these service, but when you have the same branding across multiple systems, you have to take the bad with the good. Had they called it "multidnsd" or "ntpclientd" then people wouldn't think "systemd sucks because when MyDistro 9 came along", they've blame multidnsd and let the systemd init system stand on it's own.
    - zaarn 8y ago
      I don't recall the DNS resolver actually breaking DNS without it being fixed. And I'm not sure why most systems need NTP to run as a server. You can always disable them at runtime or during compile and use your own though.
  - deleted 8y ago
    [deleted]
- 8y ago
altmind 8y ago
>Because most people against systemd will keep saying that the old init system was ok, they don't move forward trying to provide a true alternative. The problem with systemd it is not just an init system. Its network-state-aware, device-state-aware container launcher(nspawn), cron, logind and syslog implementation. The scope creep of systemd is enormous, nobody asked for that when they wanted reliable daemons.
- w323898 8y ago
  More or less this. Gummiboot is nearly pointless, and ntpd and resolved have both caused problems for me. As an init system, systemd is fine, but shipping these bad components while giving them the systemd "seal of approval" is dumb. On the other hand, I've had no issues with logind and gdm. I've been interested in trying S6 but given it's quite easy to substitute out the bad parts of systemd, so I just haven't bothered. Probably the biggest problem with systemd is that it's hurting BSD. Then again, gnome devs are having enough trouble getting things working on Linux... also binary format journals are so dumb. How have they not changed that?
dvfjsdhgfv 8y ago
The tragedy of systemd is tight coupling. What makes Linux great is that I used to always have a choice - regarding what kernel I use, what editor, what shell, even what Init I use... Systemd changed all that. Distro makers gave up supporting alternatives because it would mean too much work. (I almost flipped out when I read somewhere they had to do it because of some Gnome-related component... I mean I don't care about Gnome, I don't even use X, but I have hundreds of servers to manage - now let's change everything because one guy said it's the only way...) Nobody would make what Lennart did if we had a choice. Those who liked Systemd would use it, and the rest would use the init of their choice. As simple as that.

kfwhp 8y ago

systemd became a standard because the guy works at Red Hat so he can make GNOME require it (there is no way to use GNOME without systemd; distros that allow that such as Gentoo do so by patching GNOME, which is costly.) I agree that a more modern init system is necessary, but the idea of systemd is meh and the implementation is subpar.

tapoxi 8y ago
systemd became a standard because Debian adopted it after a lengthy discussion, partially because big Debian users like Spotify expressed an interest in systemd. https://lists.debian.org/debian-ctte/2014/01/msg00287.html https://lists.debian.org/debian-ctte/2014/01/msg00287.html
nickik 8y ago
Conspiracy nonsense. It became standard because the existing solutions were crappy and nobody else bothered to do anything about it.
- kfwhp 8y ago
  I don't believe this to be a "conspiracy". It's nothing shadowy, really. What they did is completely natural. That doesn't mean I support the idea though.
kevin_b_er 8y ago
The intentional and willful breaking of screen and tmux was to fix a GNOME bug of GNOME not closing up as it should when the user logs out, so systemd was changed to mass kill processes. The interplay between GNOME and systemd in backroom dealings is a major pain point.
- kbenson 8y ago
  I think that's an oversimplification. There are definitely cases where some thing started as a daemon under a user session, graphical or not, should be killed to be safe. For example, ssh-agent. There are other things that are meant to be left around, as that's their purpose, such as screen and tmux. I would say the safe solution would be to kill everything in the user session at multiple levels (GNOME, and user session management demon like logind, etc), and to provide a defined safe way for the very few programs that want to stick around to do so. That seems like what systemd came up with as well.
taffer 8y ago
You make it sound like the systemd author was something the CEO of all Linux Distros. The maintainers of Arch Linux have given an explicit list[1] of the reasons why they decided to introduce systemd: 0) it is hotplug capable 1) we can know the state of the system 2) it is modular 3) it allows dbus/udev to go back to doing the task they are meant to do 4) we can reduce the number of explicit ordering dependencies between daemons 5) we get a lot of security/sandboxing features for free 6) systemd service files can be written and distributed upstream 7) systemd is a cross-distro project 8) logind will finally deliver on what consolekit was supposed to do 9) systemd is fast [1]: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

sametmax 8y ago

I concur. Before systemd, I used supervisor because I wanted to avoid using any init system like hell. Since systemd, I just do a service file. So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need. I'm sure all the power user complaints about systemd are legitimate, but I really don't care about those. I just want an easy way to setup custom deamon on ubuntu and centos. Provide a better system, that solve those problems, and I'll use it. I really don't care as long as my problem is solved.

onli 8y ago
> So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need. Same couldn't be said about supervisor, the solution you already had running (well, maybe strike init)?
- sametmax 8y ago
  It's not installed by default on any distro. I don't want to install something as basic as an init system. And it's not installed by default because it doesn't solve the problem of a service dependancy graph.
  - onli 8y ago
    Sorry, but that first argument seems a bit random to me. Couldn't even use a proper editor like nano with that argumentation, having a usable editor available is after all also pretty basic. I doubt that supervisor is not installed because of not solving something it evidently does not want to solve, but that argument at least looks valid to me. Just in case you are not aware, https://github.com/Supervisor/supervisor/issues/122 https://github.com/Supervisor/supervisor/issues/122 lists two solutions (wait_for_it.sh and a supervisor plugin that adds dependency resolution).
    - kbenson 8y ago

upofadown 8y ago

>Because most people against systemd will keep saying that the old init system was ok, ... There isn't and wasn't hardly anyone saying that. It is and was well known that there were better things out there than the hacked up sysV style init systems produced by the various Linux distributions. This is a common strawman that seems to get rolled out any time any discussion involves systemd.

antirez 8y ago
A few of the authors of one of the Debian based distributions dropping systemd are friends of mine and all of them see things in that way, that the good old init is fine and there is no need to replace it. In the Facebook group where they use to stay the others I don't know first-hand seem to share this POV.
nickik 8y ago
And yet basically no alternative to systemd was produced by any of those people.
- bluejekyll 8y ago
  Does upstart not count as an alternative?
  - loeg 8y ago
    Is upstart better in any way?
    - sliken 8y ago
      Upstart doesn't include implementations on NTP, DNS, DHCP, or anything that opens a network port. It does however allow parallel boots with dependency analysis for quick boots. Systemd on the other hand seems to be trying to take over syslog, ntpd, dhcpd, named, and related with generally poorer implementations. Feature creep seems constant with systemd, for no particularly good reason.
  - 8y ago

isostatic 8y ago

But it's not just replacing init - it's replacing a dozen other services including things like ntp or dns, and often it's replacing them with inferior solutions.

antirez 8y ago
Yes, that's a design problem due to what the systemd main author believes to be a good thing.
nickik 8y ago
systemd can be used without most of these things. systemd as a project has other services in but those you can use or not use. And the claim that they are 'inferior solutions' is just absolutely false in most cases. It often replaced horrible old tools that haven't been updated in 30 years. It often provides far better interfaces and tooling then the existing solutions.
- isostatic 8y ago
  The DNS resolver seems to break DNS, the time system no longer acts as a server This isn't necessarily a problem with the systemd project, it's more on the distros that bundle these service, but when you have the same branding across multiple systems, you have to take the bad with the good. Had they called it "multidnsd" or "ntpclientd" then people wouldn't think "systemd sucks because when MyDistro 9 came along", they've blame multidnsd and let the systemd init system stand on it's own.
  - zaarn 8y ago
    I don't recall the DNS resolver actually breaking DNS without it being fixed. And I'm not sure why most systems need NTP to run as a server. You can always disable them at runtime or during compile and use your own though.
- deleted 8y ago
  [deleted]
8y ago

altmind 8y ago

>Because most people against systemd will keep saying that the old init system was ok, they don't move forward trying to provide a true alternative. The problem with systemd it is not just an init system. Its network-state-aware, device-state-aware container launcher(nspawn), cron, logind and syslog implementation. The scope creep of systemd is enormous, nobody asked for that when they wanted reliable daemons.

w323898 8y ago
More or less this. Gummiboot is nearly pointless, and ntpd and resolved have both caused problems for me. As an init system, systemd is fine, but shipping these bad components while giving them the systemd "seal of approval" is dumb. On the other hand, I've had no issues with logind and gdm. I've been interested in trying S6 but given it's quite easy to substitute out the bad parts of systemd, so I just haven't bothered. Probably the biggest problem with systemd is that it's hurting BSD. Then again, gnome devs are having enough trouble getting things working on Linux... also binary format journals are so dumb. How have they not changed that?

dvfjsdhgfv 8y ago

The tragedy of systemd is tight coupling. What makes Linux great is that I used to always have a choice - regarding what kernel I use, what editor, what shell, even what Init I use... Systemd changed all that. Distro makers gave up supporting alternatives because it would mean too much work. (I almost flipped out when I read somewhere they had to do it because of some Gnome-related component... I mean I don't care about Gnome, I don't even use X, but I have hundreds of servers to manage - now let's change everything because one guy said it's the only way...) Nobody would make what Lennart did if we had a choice. Those who liked Systemd would use it, and the rest would use the init of their choice. As simple as that.