4 ms·

The problem with systemd is not that it is "bad". There's a lot worse software out there. Systemd is relatively competently programmed. And it's even useful! T

The problem with systemd is not that it is "bad". There's a lot worse software out there. Systemd is relatively competently programmed. And it's even useful! The problem with systemd has always been that it forces you to do everything the systemd way, and usually to use its tools. It goes against everything that has helped GNU/Linux become a great system: that it wasn't really one system. It was bits and pieces, and you could add them together however you wanted to get something you liked. Systemd is the opposite. It is inflexible and clunky, monolithic and proprietary, binary and difficult. Everything has to be made to work with it, not vice versa. It doesn't follow any of the old conventions that made it simple to combine one tool with another. I can compare it to Windows, but I feel like that would be an insult to Windows' usability. If this one single fact was different, everyone would love systemd, because it has plenty of useful features. But because it is designed specifically to please a single quirky user, people hate it.

jcrites 10y ago
> It is inflexible and clunky, monolithic and proprietary, binary and difficult. Everything has to be made to work with it, not vice versa. It doesn't follow any of the old conventions that made it simple to combine one tool with another. Could you share a few specific examples? That hasn't been the case at all for me. I have worked with systemd and have had the opposite experience. I simply write textual config files describing how to launch the service, which can be done in a variety of ways. Could you share more about how you tried to use systemd? I'd encourage you to read Russ Allbery's analysis of systemd [2], which includes a description of his experience converting one of his packages to use systemd. He remarks on the well-done integration and its compatibility: * Integrated daemon status. This one caught me by surprise, since the systemd journal was functionality that I expected to dislike. But I was surprised at how well-implemented it is, and systemctl status blew me away. I think any systems administrator who has tried to debug a running service will be immediately struck by the differences between upstart: lbcd start/running, process 32294 and systemd: lbcd.service - responder for load balancing Loaded: loaded (/lib/systemd/system/lbcd.service; enabled) Active: active (running) since Sun 2013-12-29 13:01:24 PST; 1h 11min ago Docs: man:lbcd(8) http://www.eyrie.org/~eagle/software/lbcd/ Main PID: 25290 (lbcd) CGroup: name=systemd:/system/lbcd.service └─25290 /usr/sbin/lbcd -f -l Dec 29 13:01:24 wanderer systemd[1]: Starting responder for load balancing... Dec 29 13:01:24 wanderer systemd[1]: Started responder for load balancing. Dec 29 13:01:24 wanderer lbcd[25290]: ready to accept requests Dec 29 13:01:43 wanderer lbcd[25290]: request from ::1 (version 3) Both are clearly superior to sysvinit, which bails on the problem entirely and forces reimplementation in every init script, but the systemd approach takes this to another level. And this is not an easy change for upstart. While some more data could be added, like the command line taken from ps, the most useful addition in systemd is the log summary. And that relies on the journal, which is a fundamental design decision of systemd. And yes, all of those log messages are also in the syslog files where one would expect to find them. And systemd can also capture standard output and standard error from daemons and drop that in the journal and from there into syslog, which makes it much easier to uncover daemon startup problems that resulted in complaints to standard error instead of syslog. This cannot even be easily replaced with something that might parse the syslog files, even given output forwarding to syslog (something upstart currently doesn't have), since the journal will continue to work properly even if all syslog messages are forwarded off the host, stored in some other format, or stored in some other file. systemd is agnostic to the underlying syslog implementation. I think Russ's passage exhibits the opposite sentiment from the one you wrote. Russ says you can get the benefits of systemctl and journalctl if you want, but you can also use syslog in the old-fashioned way if you want. This has been my experience with systemd as well. I still have a habit of writing "service postfix restart", which still works but is not the systemd-idiomatic way. I don't even have the "correct" way memorized because the old way that I'm used to using works. So what I'm asking is, have you tried to achieve something with systemd and found that you were forced to do it differently? I'd be curious to learn more about what those cases were. I'm not affiliated with systemd project, but I have a general interest in wanting to see it improve. (Please note that, barring conventions of some kind that span multiple tools, every tool naturally requires you to do things that tool's own way. If you are holding systemd to the standard that its job should be able to be performed by two different tools, each with the same interface, while supporting advanced features, then you should have other examples of this as well.) [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... [2] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html
reflexive 10y ago
> Systemd is the opposite. It is inflexible and clunky, monolithic and proprietary The other points can be debated, but please don't call it proprietary. It is free software as in "freedom" (LGPL).
- peterwwillis 10y ago
  It is indeed proprietary because it does indeed have an owner. But I use the word in the context of its design and implementation, which is basically that of the not so benevolent dictator, or the possessive or territorial.
  - reflexive 10y ago
    > It is indeed proprietary because it does indeed have an owner. You are using the term proprietary incorrectly, probably out of simple ignorance. The software does not have an "owner" who has power of the users; the LGPL means all users have complete control over the software. Please read this carefully before spreading more misinformation: https://www.gnu.org/proprietary/proprietary.en.html https://www.gnu.org/proprietary/proprietary.en.html
    - peterwwillis 10y ago
      I'm aware of the definition of proprietary software. I'm not using that form of the word.

jcrites 10y ago

> It is inflexible and clunky, monolithic and proprietary, binary and difficult. Everything has to be made to work with it, not vice versa. It doesn't follow any of the old conventions that made it simple to combine one tool with another. Could you share a few specific examples? That hasn't been the case at all for me. I have worked with systemd and have had the opposite experience. I simply write textual config files describing how to launch the service, which can be done in a variety of ways. Could you share more about how you tried to use systemd? I'd encourage you to read Russ Allbery's analysis of systemd [2], which includes a description of his experience converting one of his packages to use systemd. He remarks on the well-done integration and its compatibility: * Integrated daemon status. This one caught me by surprise, since the systemd journal was functionality that I expected to dislike. But I was surprised at how well-implemented it is, and systemctl status blew me away. I think any systems administrator who has tried to debug a running service will be immediately struck by the differences between upstart: lbcd start/running, process 32294 and systemd: lbcd.service - responder for load balancing Loaded: loaded (/lib/systemd/system/lbcd.service; enabled) Active: active (running) since Sun 2013-12-29 13:01:24 PST; 1h 11min ago Docs: man:lbcd(8) http://www.eyrie.org/~eagle/software/lbcd/ Main PID: 25290 (lbcd) CGroup: name=systemd:/system/lbcd.service └─25290 /usr/sbin/lbcd -f -l Dec 29 13:01:24 wanderer systemd[1]: Starting responder for load balancing... Dec 29 13:01:24 wanderer systemd[1]: Started responder for load balancing. Dec 29 13:01:24 wanderer lbcd[25290]: ready to accept requests Dec 29 13:01:43 wanderer lbcd[25290]: request from ::1 (version 3) Both are clearly superior to sysvinit, which bails on the problem entirely and forces reimplementation in every init script, but the systemd approach takes this to another level. And this is not an easy change for upstart. While some more data could be added, like the command line taken from ps, the most useful addition in systemd is the log summary. And that relies on the journal, which is a fundamental design decision of systemd. And yes, all of those log messages are also in the syslog files where one would expect to find them. And systemd can also capture standard output and standard error from daemons and drop that in the journal and from there into syslog, which makes it much easier to uncover daemon startup problems that resulted in complaints to standard error instead of syslog. This cannot even be easily replaced with something that might parse the syslog files, even given output forwarding to syslog (something upstart currently doesn't have), since the journal will continue to work properly even if all syslog messages are forwarded off the host, stored in some other format, or stored in some other file. systemd is agnostic to the underlying syslog implementation. I think Russ's passage exhibits the opposite sentiment from the one you wrote. Russ says you can get the benefits of systemctl and journalctl if you want, but you can also use syslog in the old-fashioned way if you want. This has been my experience with systemd as well. I still have a habit of writing "service postfix restart", which still works but is not the systemd-idiomatic way. I don't even have the "correct" way memorized because the old way that I'm used to using works. So what I'm asking is, have you tried to achieve something with systemd and found that you were forced to do it differently? I'd be curious to learn more about what those cases were. I'm not affiliated with systemd project, but I have a general interest in wanting to see it improve. (Please note that, barring conventions of some kind that span multiple tools, every tool naturally requires you to do things that tool's own way. If you are holding systemd to the standard that its job should be able to be performed by two different tools, each with the same interface, while supporting advanced features, then you should have other examples of this as well.) [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... [2] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html

reflexive 10y ago

> Systemd is the opposite. It is inflexible and clunky, monolithic and proprietary The other points can be debated, but please don't call it proprietary. It is free software as in "freedom" (LGPL).

peterwwillis 10y ago
It is indeed proprietary because it does indeed have an owner. But I use the word in the context of its design and implementation, which is basically that of the not so benevolent dictator, or the possessive or territorial.
- reflexive 10y ago
  > It is indeed proprietary because it does indeed have an owner. You are using the term proprietary incorrectly, probably out of simple ignorance. The software does not have an "owner" who has power of the users; the LGPL means all users have complete control over the software. Please read this carefully before spreading more misinformation: https://www.gnu.org/proprietary/proprietary.en.html https://www.gnu.org/proprietary/proprietary.en.html
  - peterwwillis 10y ago
    I'm aware of the definition of proprietary software. I'm not using that form of the word.