6 ms·

A article about programming to systemd and how it helped the various distributions turned into HN emotional responses to bash systemd. I like systemd and it ha

by baldfat 10y ago

A article about programming to systemd and how it helped the various distributions turned into HN emotional responses to bash systemd. I like systemd and it has helped Linux advance. init was a mess and no one still has come with a golden response that shows the world how anything would be better then systemd. systemd answered a difficult question and hopefully we willsee more similar advancements shortly for Linux.

mixedCase 10y ago
>I like systemd and it has helped Linux advance. init was a mess and no one still has come with a golden response that shows the world how anything would be better then systemd. Just boot the system and hand it off to a service manager that handles unit files. That was a nice idea. Everything else that came after with tight coupling to systemd was not.
mikekchar 10y ago
Personally, I would have been ecstatic to see systemd if it hadn't have been tied directly to GNOME and thereby installed by every distribution that wanted to include GNOME. My main gripe with systemd is that every other system the main author of systemd has written has made my computer inoperable time and time again. I would have liked to have a choice of using systemd or waiting until I saw it become mature enough that I trusted it. I just didn't want to be forced to use it in case history repeated itself. Opting out of systemd is ridiculously difficult due to that GNOME tie-in. It's one of the most important parts of my system. I still would prefer not to have systemd, but I will admit that it works reasonably well for my purposes. I'm pretty upset about how it all went down, but that's life in the fast lane I guess. Where are the days when everybody ignored Linux? I should move to BSD ;-)
- vetinari 10y ago
  The Gnome developers were asking for years for someone to step in and maintain ConsoleKit. Nobody did and there wasn't any hope somebody would. So they took plan B and used logind, which is part of systemd. People are still free to develop shims that would work with other init systems - but so far nobody is willing to do that.
  - thejosh 10y ago
    It's sometimes easier to complain loudly on message boards.
  - wott 10y ago
    And the one supposed to maintain ConsoleKit, who abandoned it, was... a certain Lennart Poettering.
    - belovedeagle 10y ago
      How... convenient.
    - jsight 10y ago
      How terrible is it that he maintained a replacement for it instead?
    - Xylakant 10y ago
      please elaborate, why exactly was he supposed to maintain it? Did we as a community pay him for that? Did anybody else pay him for that?
    - mattnewton 10y ago
      Yes, it was all part of his evil plan to.. write what he thought a better overall system would be, and give it to the community for free?
    - mikekchar 10y ago
      As annoyed as I am with the situation, I actually have a hard time blaming this entirely on Lennart Poettering. Red Hat pays for this development (as they do with quite a lot of GNOME). How many project managers are going to go and say, "No. You must spend more time to decouple system X from system Y even though it provides us absolutely no value as an organisation." He's doing his job and he's nowhere near the worst lead developer I've ever seen ;-) The main problem is that, as the responder to my comment said, there are not enough outside developers getting in there and fixing the problem. I am included in the list of people who could fix it, but won't because I have other things to do. It doesn't stop me complaining about it, though. I don't think the complaints are counter productive either, if they are aimed in the right place: Red Hat. Blaming Lennart is useless, whether or not it is fair. It's Red Hat's behaviour that needs to change, because if they replaced Lennart tomorrow the new person would have a mandate to do exactly the same thing.
- microcolonel 10y ago
  To me, one of the greatest weaknesses of OpenBSD (and I say this as an avid OpenBSD user) is not having a system manager like solaris smf or systemd. Launchd is a pain to configure, so I don't really consider it a solution. Opting out of systemd is hard because systemd is the only package which actually solves these problems reliably, and is enthusiastically maintained. Logind is the only maintained implementation of ConsoleKit. xinetd works fine, but it operates outside the loop of the system manager, which makes socket activated services harder to monitor and configure and prevents them from being started before xinetd itself. Say what you will, but systemd is relied upon because if they didn't rely on it, the functionality they need would not be found elsewhere. I think these are all growing pains. As the system gets more complex, we are starting to realize that we can't afford to maintain two or three wrappers and sets of configs for the device manager process; we can't afford to maintain a handful of different metadata-enhanced logging systems in each daemon; we can't afford to maintain adapters and configs for a bunch of login managers. This is exactly the same kind of pain which made portable UNIX an overnight commercial success. People yearned not to have to maintain a port for every computer they run on. Today they yearn not to have to have to ask five daemons different questions for the same answer.
  - JdeBP 10y ago
    It can have a service manager. I have an OpenBSD machine where it has. A system manager is a little more difficult. The problems range from outright missing stuff to hurdles that could be overcome given a large amount of work. * https://www.mail-archive.com/supervision@list.skarnet.org/msg01308.html https://www.mail-archive.com/supervision@list.skarnet.org/ms... * http://jdebp.eu./Softwares/nosh/openbsd-binary-packages.html#Limitations http://jdebp.eu./Softwares/nosh/openbsd-binary-packages.html...
  - makomk 10y ago
    Take a look at the function signatures of the dbus API that logind exposes, and it should rapidly become obvious why they are no other implementations.
cm3 10y ago
> no one still has come with a golden response SMF or Nosh
cm3 10y ago
> systemd answered a difficult question and hopefully we willsee more similar advancements shortly for Linux. Agreed, but I hope that systemd starts focusing on stability and fixing the regressions they've introduced compared to sysvinit. systemd machines are the only instances of Linux since 1995 where I've had intermittent random hangups during startup and sometimes shutdown. I never thought about startup and shutdown before systemd. It just worked, and if there was a problem, it was reproduceable and a real error (usually configuration), not systemd random fault. I don't use CentOS, maybe their systemd integration is actually reliable.
- op00to 10y ago
  Did you capture memory core dumps from those random freezes to reliably pinpoint systemd as the source of the issue, and not the more likely culprit of hardware?
  - cm3 10y ago
    It's not that kind of hang.
raverbashing 10y ago
> and it has helped Linux advance Statement without substance that sounds more like a "feel good" phrase > that shows the world how anything would be better then systemd. Not breaking and being very unstable is a start > systemd answered a difficult question No, it caused more problems than solved > more similar advancements It's not an advancement except in the mind of some I'm not against an init tool like Systemd. I'm against 2 things: LP and his contributors don't seem to know what stable software means or even care (I went through something like 4 distro versions before Pulseaudio was minimally stable) and the scope creep of systemd
- op00to 10y ago
  > Statement without substance that sounds more like a "feel good" phrase So you're saying Linux didn't advance in the last few years? > Not breaking and being very unstable is a start Statement without substance that sounds more like a "feel bad" phrase > No, it caused more problems than solved Statement without substance that sounds more like a "feel bad" phrase More seriously, show us data that refutes OP's statement instead of simply claiming that it's without value. You do the same thing in your assertions, and it really doesn't drive the discourse forward. I worked with a number of large enterprise customers running Linux at scale, and when the architects opened up to the value of systemd, they universally sang its praises. Out of all these large customers, I've never run into an issue where systemd was the culprit of a significant, P1 style issue. There's a large, silent majority of systemd users who run into no issues at all.
  - falcolas 10y ago
    > So you're saying Linux didn't advance in the last few years? Linux advanced significantly more under sysvinit than systemd, so does this mean sysvinit is superior to systemd? > Not breaking and being very unstable is a start When it works, it works fine. When it breaks, it's very hard to debug. There's plenty of articles out there about this. Even the original article which spawns this talks about the same types of problems - "we have to mask it, not disable it, because <xyz>", or "end users will have to be responsible for masking this service", or "when it was just bash scripts, we didn't have to worry about order". > There's a large, silent majority of systemd users who run into no issues at all. Can be equally said about sysvinit and upstart. Does that mean they are just as good as systemd? My two cents: Developers love systemd; its one more thing they can abstract away and mostly not deal with. People who have to troubleshoot problems with systemd don't feel nearly as charitable towards it.
irishcoffee 10y ago
"Systemd is far more than an init system: it is becoming a secondary operating system kernel, providing a log server, a device manager, a container manager, a login manager, a DHCP client, a DNS resolver, and an NTP client. These services are largely interdependent and provide non-standard interfaces for other applications to use. This makes any one component of systemd hard to replace, which will prevent more secure alternatives from gaining adoption in the future." [1] "There will be better alternatives in the future that are more secure than what we have now. But adopting them will only be possible if systemd has not destroyed the modularity and standards-compliance that make innovation possible" [1] [1] https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_...
- mgbmtl 10y ago
  In other words, it's a service management layer for Linux. Before it, init scripts were mostly a bunch of duct tape (start a daemon and hope it doesn't crash). Some could argue it was more flexible, some could argue that it was a mess. In any case, this is off-topic. The article was an interesting example of how upstreaming unit file for systemd means more collaboration between distributions, less wasted work.
  - emeraldd 10y ago
    What the parent quoted does not describe "a service management layer for Linux", it describes something that is trying to become all things to all people. Which is exactly what irks a large portion of the linux/unix community (myself included). What does DNS or DHCP have to do with managing "services"?
    - lobster_johnson 10y ago
      Surely those are services in a very classical sense: Processes that provide a service that other apps need, and which need to go up, down or be reconfigured dynamically as a response to other changes in the system (such as networking). So far the way to do that has been pretty ad-hoc, with no formal definition of who has the responsibility for controlling the lifecycle of each component. What systemd brings to the table is a way to formalize those relationships and centralize a lot of common logic related to dependency handling and process control.
throw2016 10y ago
I am curious, can there be any criticism of systemd? Since everything is dismissed as an emotional response or haters or greybeards. This kind of defensive response seeks to shift everything from the technical to the political and leaves no room for genuine criticism, improvement and diversity. Linux was a success way before systemd, you just can't disrespect all the talented people who have got Linux where it as greybeards or motivated. You say systemd has advanced Linux but don't say how, you say init scripts were a mess but so are systemd symlinks littered all over the place. This is not reasonable.
- teddyh 10y ago
  The people wanting to criticize systemd are in the same problematic situation as people wanting to criticize feminists. Any single point or argument may be technically correct, but nobody will listen to them unless they are presented extremly carefully.
falcolas 10y ago
Actually, the article is about working around problems encountered integrating nfs with systemd. They were charitable enough to not use that kind of phrasing, but everything they talked about had to do with fixing new problems brought forth by using systemd at the upstream layer, so those downstream don't have to worry about it (but admitting that there are still some steps which have to be undertaken by the end user to avoid unnecessarily starting the rpcbind service). They could have easily written this same article when nfs first came out and they were working through their default sysvinit scripts.
- kbenson 10y ago
  I'm pretty sure they were being charitable because that's a somewhat biased interpretation of what was being discussed. It would be trivial to make NFS start exactly as it did prior to systemd. I would characterize this as fixing the problems brought forth by trying to use NFS with the new capabilities systemd offers, and the unforseen consequences of doing so without knowing/considering how everything interconnects with it.
- lobster_johnson 10y ago
  NFS is an old (some would say legacy), idiosynchratic piece of software with multiple revisions that affect how you run it, depending on what kind of backwards compatibility you want. As the article points out, some of the problems could be eliminated by only enabling NFSv4 support, for example. If anything, the article is a good example of adapting new tech to work around the many odd behaviours of old tech.
aidenn0 10y ago
One of my highest voted comments on HN was a fairly inane complaint about systemd; it's very hated on HN.

by baldfat 10y ago

mixedCase 10y ago

>I like systemd and it has helped Linux advance. init was a mess and no one still has come with a golden response that shows the world how anything would be better then systemd. Just boot the system and hand it off to a service manager that handles unit files. That was a nice idea. Everything else that came after with tight coupling to systemd was not.

mikekchar 10y ago

Personally, I would have been ecstatic to see systemd if it hadn't have been tied directly to GNOME and thereby installed by every distribution that wanted to include GNOME. My main gripe with systemd is that every other system the main author of systemd has written has made my computer inoperable time and time again. I would have liked to have a choice of using systemd or waiting until I saw it become mature enough that I trusted it. I just didn't want to be forced to use it in case history repeated itself. Opting out of systemd is ridiculously difficult due to that GNOME tie-in. It's one of the most important parts of my system. I still would prefer not to have systemd, but I will admit that it works reasonably well for my purposes. I'm pretty upset about how it all went down, but that's life in the fast lane I guess. Where are the days when everybody ignored Linux? I should move to BSD ;-)

vetinari 10y ago
The Gnome developers were asking for years for someone to step in and maintain ConsoleKit. Nobody did and there wasn't any hope somebody would. So they took plan B and used logind, which is part of systemd. People are still free to develop shims that would work with other init systems - but so far nobody is willing to do that.
- thejosh 10y ago
  It's sometimes easier to complain loudly on message boards.
- wott 10y ago
  And the one supposed to maintain ConsoleKit, who abandoned it, was... a certain Lennart Poettering.
  - belovedeagle 10y ago
    How... convenient.
  - jsight 10y ago
    How terrible is it that he maintained a replacement for it instead?
  - Xylakant 10y ago
    please elaborate, why exactly was he supposed to maintain it? Did we as a community pay him for that? Did anybody else pay him for that?
  - mattnewton 10y ago
    Yes, it was all part of his evil plan to.. write what he thought a better overall system would be, and give it to the community for free?
  - mikekchar 10y ago
    As annoyed as I am with the situation, I actually have a hard time blaming this entirely on Lennart Poettering. Red Hat pays for this development (as they do with quite a lot of GNOME). How many project managers are going to go and say, "No. You must spend more time to decouple system X from system Y even though it provides us absolutely no value as an organisation." He's doing his job and he's nowhere near the worst lead developer I've ever seen ;-) The main problem is that, as the responder to my comment said, there are not enough outside developers getting in there and fixing the problem. I am included in the list of people who could fix it, but won't because I have other things to do. It doesn't stop me complaining about it, though. I don't think the complaints are counter productive either, if they are aimed in the right place: Red Hat. Blaming Lennart is useless, whether or not it is fair. It's Red Hat's behaviour that needs to change, because if they replaced Lennart tomorrow the new person would have a mandate to do exactly the same thing.
microcolonel 10y ago
To me, one of the greatest weaknesses of OpenBSD (and I say this as an avid OpenBSD user) is not having a system manager like solaris smf or systemd. Launchd is a pain to configure, so I don't really consider it a solution. Opting out of systemd is hard because systemd is the only package which actually solves these problems reliably, and is enthusiastically maintained. Logind is the only maintained implementation of ConsoleKit. xinetd works fine, but it operates outside the loop of the system manager, which makes socket activated services harder to monitor and configure and prevents them from being started before xinetd itself. Say what you will, but systemd is relied upon because if they didn't rely on it, the functionality they need would not be found elsewhere. I think these are all growing pains. As the system gets more complex, we are starting to realize that we can't afford to maintain two or three wrappers and sets of configs for the device manager process; we can't afford to maintain a handful of different metadata-enhanced logging systems in each daemon; we can't afford to maintain adapters and configs for a bunch of login managers. This is exactly the same kind of pain which made portable UNIX an overnight commercial success. People yearned not to have to maintain a port for every computer they run on. Today they yearn not to have to have to ask five daemons different questions for the same answer.
- JdeBP 10y ago
  It can have a service manager. I have an OpenBSD machine where it has. A system manager is a little more difficult. The problems range from outright missing stuff to hurdles that could be overcome given a large amount of work. * https://www.mail-archive.com/supervision@list.skarnet.org/msg01308.html https://www.mail-archive.com/supervision@list.skarnet.org/ms... * http://jdebp.eu./Softwares/nosh/openbsd-binary-packages.html#Limitations http://jdebp.eu./Softwares/nosh/openbsd-binary-packages.html...
- makomk 10y ago
  Take a look at the function signatures of the dbus API that logind exposes, and it should rapidly become obvious why they are no other implementations.

cm3 10y ago

> no one still has come with a golden response SMF or Nosh

cm3 10y ago

> systemd answered a difficult question and hopefully we willsee more similar advancements shortly for Linux. Agreed, but I hope that systemd starts focusing on stability and fixing the regressions they've introduced compared to sysvinit. systemd machines are the only instances of Linux since 1995 where I've had intermittent random hangups during startup and sometimes shutdown. I never thought about startup and shutdown before systemd. It just worked, and if there was a problem, it was reproduceable and a real error (usually configuration), not systemd random fault. I don't use CentOS, maybe their systemd integration is actually reliable.

op00to 10y ago
Did you capture memory core dumps from those random freezes to reliably pinpoint systemd as the source of the issue, and not the more likely culprit of hardware?
- cm3 10y ago
  It's not that kind of hang.

raverbashing 10y ago

> and it has helped Linux advance Statement without substance that sounds more like a "feel good" phrase > that shows the world how anything would be better then systemd. Not breaking and being very unstable is a start > systemd answered a difficult question No, it caused more problems than solved > more similar advancements It's not an advancement except in the mind of some I'm not against an init tool like Systemd. I'm against 2 things: LP and his contributors don't seem to know what stable software means or even care (I went through something like 4 distro versions before Pulseaudio was minimally stable) and the scope creep of systemd

op00to 10y ago
> Statement without substance that sounds more like a "feel good" phrase So you're saying Linux didn't advance in the last few years? > Not breaking and being very unstable is a start Statement without substance that sounds more like a "feel bad" phrase > No, it caused more problems than solved Statement without substance that sounds more like a "feel bad" phrase More seriously, show us data that refutes OP's statement instead of simply claiming that it's without value. You do the same thing in your assertions, and it really doesn't drive the discourse forward. I worked with a number of large enterprise customers running Linux at scale, and when the architects opened up to the value of systemd, they universally sang its praises. Out of all these large customers, I've never run into an issue where systemd was the culprit of a significant, P1 style issue. There's a large, silent majority of systemd users who run into no issues at all.
- falcolas 10y ago
  > So you're saying Linux didn't advance in the last few years? Linux advanced significantly more under sysvinit than systemd, so does this mean sysvinit is superior to systemd? > Not breaking and being very unstable is a start When it works, it works fine. When it breaks, it's very hard to debug. There's plenty of articles out there about this. Even the original article which spawns this talks about the same types of problems - "we have to mask it, not disable it, because <xyz>", or "end users will have to be responsible for masking this service", or "when it was just bash scripts, we didn't have to worry about order". > There's a large, silent majority of systemd users who run into no issues at all. Can be equally said about sysvinit and upstart. Does that mean they are just as good as systemd? My two cents: Developers love systemd; its one more thing they can abstract away and mostly not deal with. People who have to troubleshoot problems with systemd don't feel nearly as charitable towards it.

irishcoffee 10y ago

"Systemd is far more than an init system: it is becoming a secondary operating system kernel, providing a log server, a device manager, a container manager, a login manager, a DHCP client, a DNS resolver, and an NTP client. These services are largely interdependent and provide non-standard interfaces for other applications to use. This makes any one component of systemd hard to replace, which will prevent more secure alternatives from gaining adoption in the future." [1] "There will be better alternatives in the future that are more secure than what we have now. But adopting them will only be possible if systemd has not destroyed the modularity and standards-compliance that make innovation possible" [1] [1] https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_...

mgbmtl 10y ago
In other words, it's a service management layer for Linux. Before it, init scripts were mostly a bunch of duct tape (start a daemon and hope it doesn't crash). Some could argue it was more flexible, some could argue that it was a mess. In any case, this is off-topic. The article was an interesting example of how upstreaming unit file for systemd means more collaboration between distributions, less wasted work.
- emeraldd 10y ago
  What the parent quoted does not describe "a service management layer for Linux", it describes something that is trying to become all things to all people. Which is exactly what irks a large portion of the linux/unix community (myself included). What does DNS or DHCP have to do with managing "services"?
  - lobster_johnson 10y ago
    Surely those are services in a very classical sense: Processes that provide a service that other apps need, and which need to go up, down or be reconfigured dynamically as a response to other changes in the system (such as networking). So far the way to do that has been pretty ad-hoc, with no formal definition of who has the responsibility for controlling the lifecycle of each component. What systemd brings to the table is a way to formalize those relationships and centralize a lot of common logic related to dependency handling and process control.

throw2016 10y ago

I am curious, can there be any criticism of systemd? Since everything is dismissed as an emotional response or haters or greybeards. This kind of defensive response seeks to shift everything from the technical to the political and leaves no room for genuine criticism, improvement and diversity. Linux was a success way before systemd, you just can't disrespect all the talented people who have got Linux where it as greybeards or motivated. You say systemd has advanced Linux but don't say how, you say init scripts were a mess but so are systemd symlinks littered all over the place. This is not reasonable.

teddyh 10y ago
The people wanting to criticize systemd are in the same problematic situation as people wanting to criticize feminists. Any single point or argument may be technically correct, but nobody will listen to them unless they are presented extremly carefully.

falcolas 10y ago

Actually, the article is about working around problems encountered integrating nfs with systemd. They were charitable enough to not use that kind of phrasing, but everything they talked about had to do with fixing new problems brought forth by using systemd at the upstream layer, so those downstream don't have to worry about it (but admitting that there are still some steps which have to be undertaken by the end user to avoid unnecessarily starting the rpcbind service). They could have easily written this same article when nfs first came out and they were working through their default sysvinit scripts.

kbenson 10y ago
I'm pretty sure they were being charitable because that's a somewhat biased interpretation of what was being discussed. It would be trivial to make NFS start exactly as it did prior to systemd. I would characterize this as fixing the problems brought forth by trying to use NFS with the new capabilities systemd offers, and the unforseen consequences of doing so without knowing/considering how everything interconnects with it.
lobster_johnson 10y ago
NFS is an old (some would say legacy), idiosynchratic piece of software with multiple revisions that affect how you run it, depending on what kind of backwards compatibility you want. As the article points out, some of the problems could be eliminated by only enabling NFSv4 support, for example. If anything, the article is a good example of adapting new tech to work around the many odd behaviours of old tech.

aidenn0 10y ago

One of my highest voted comments on HN was a fairly inane complaint about systemd; it's very hated on HN.