6 ms·

systemd is by far the best linux init system. The options are sysvinit, OpenRC, Upstart, and systemd. Of those, the only reasonable choice is systemd. Upstart

by georgyo 10y ago

systemd is by far the best linux init system. The options are sysvinit, OpenRC, Upstart, and systemd. Of those, the only reasonable choice is systemd. Upstart was almost good, but its really frustrating to use. OpenRC is decent, but confusing. systemd solved problems, not only that it solved them well. The scope creep of systemd is something that is a bit alarming, however even with the creep it's doing a good job. The tools that it is building work fairly well, and its a relatively new project.

fapjacks 10y ago
The one thing that is painfully obvious about the situation with init systems is that people have strong opinions about their preferences. And that makes the systemd situation even more terrible, since it's a choice unwillingly foisted upon a huge number of people. This situation really deserves some choices. For me, that is the number one reason I do not like systemd, even if it's solved some problems.
- georgyo 10y ago
  I agree with your reason, however for me they get outweighed by other factors. If I am a maintainer of a popular distribution, I want my distro to have the best init system, and I want that init system to have the largest user base. EL6 and its derivatives was upstart, debian and its derivatives was upstart. The vast majority of linux systems were upstart for a long period of time. Other systems did not switch to upstart, because it introduced headache. Switching init systems requires quite a bit of work. The fact that they all switched to systemd shows that beyond political pressure, they needed a better system.
  - fapjacks 10y ago
    The choice that was put before the Debian TC was literally "Should we use systemd instead of sysvinit" and did not consider any of the many other init systems. In fact, a motion was put forward to the Debian TC to consider other init systems, and guess what? Pro-systemd TC members pointed to the original motion ("Should we use systemd instead of sysvinit") as the reason not to consider other init systems. That is pretty much as political as it gets.
    - Aeolos 10y ago
      For the record, this post is completely false, as even a cursory glance at the relevant Debian bug report will prove: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#672... We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be D systemd U upstart O openrc V sysvinit (no change) F requires further discussion [...] Therefore, the resolution reads: We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be systemd.
  - jude- 10y ago
    I don't think the distro maintainers had that much say, since the most popular Linux desktop software began to depend on it. It started with GNOME, and now KDE is on its way. This basically forces their hand--if they want to provide a good out-of-the-box experience, they either have to switch to systemd, or continuously fight upstream's patches.
  - regularfry 10y ago
    That's not my recollection. Upstart was an Ubuntu project, Debian never adopted it. Red Hat picked up upstart, then Poettering managed to convince them that they'd be better off with one they controlled. Somehow that filtered back through to Debian, and they jumped straight to systemd from sysvinit. At no point was it necessary for systemd to actually be better than upstart at being an init system. It just had to be bigger by the time it got to Debian.
- mjevans 10y ago
  There are exactly two compelling (for me) arguments against systemd, and one that seems to result from it's current focus: * Binary log files (WHYYYYY; OTOH you could argue that the only proper place to do logging is to a remote database.) * Monolithic nature - everything gets shoved in to the daemon, making it harder and more unusual to do things without it. * Servers - systemd seems to be focused on a desktop lifecycle, where users interactively log in, have settings and log out. It is less clear how secure or well this inter-operates with services running as 'users' for privilege separation. I think this may have recently gotten better.
  - georgyo 10y ago
    All of these are false. It stores everything in binary logs, however your old system didn't store it at all. You had a daemon (syslog, rsyslog, etc) that wrote them as plain text. If you start those daemons, you at exactly the same spot as before. Just with an additional copy in a binary log. Which btw, journalctl can do some magical things, and you should take some time to play with it. systemd is not monolithic, or at the very least its a distributed monolith. The vast majority of services happen in their own userspace process. Systemd excels with servers, since it standardizes how their execution gets defined. It takes only an added line to spawn them in their own namespaces, set cgroup restrictions, prevent network access, etc. Before hand, doing these things was very hard, so no one did them.
    - Sanddancer 10y ago
      If you had a basic syslog setup, it stored as text files. However, a more interesting syslog setup would take those entries and send them to a remote database, filter them to match certain contents, run scripts based on those matches, etc. Systemd only seems magical because most distros don't use even a sliver of the abilities that modern syslogs provide. Systemd is a Jenga tower. Yes, there are lots of little pieces, and yes, removing a few won't hurt anything, but it's still fragile, and rather inconsistent. "Parts" like the journal, are a separate executable, but are not managed like other services. It uses a poorly documented ipc interface to talk to the various parts, and the configuration files are a nasty tangle of symlinks and control files stretching across the filesystem. It's just not a very well engineered piece of software.
djsumdog 10y ago
The only thing systemd solves, and I will say this is a big problem, is full process management. It also unifies startup scripts which does make it easier to support multiple distributions with a simpler packaging process. I'll give you that too. The scope creep is really bad. It's not just bad, it's terrible. I don't want a program that's an init, and replaces xinitd and replaces my logging system and replaces cron. That's all totally beyond unnecessary. Even with full process management, I'd hardly say it is the best. I have had cases where I stopped a service on a systemd box and it did leave child processes running. It's command line tools are terrible. In fact it's this creep that keeps people from even being able to make drop in replacements. uselessd was a fork that kept up for a bit, but lost maintainership. With systemd being RedHat funded for full time development, it's very difficult for independent programmers to put in the time to make anything that can get adopted in the way it is.
captainmuon 10y ago
I know not everybody has the same needs, but at least for me, systemd did not solve any problem I had. In fact, I found that it's main selling point, "better" service management, got much worse. Before, I could simply do "sudo service xxx start". Now, with systemctl, everything is much more cumbersome. Just run "systemctl list-units". Ho boy, you get a huge list of... things. Not just what used to be called services or daemons, but units belonging to mount points, /dev entries, and who knows what. Granted, it is probably easier to create service scripts for developers than with init.rc or upstart (although I never had a problem the few times I had to muck with them). But as a simple consumer, I do not feel systemd solves any problem I had. It just made things some things that worked fine before slightly more confusing, and there are some regressions every now and then while other programs are getting ported to systemd.
fridsun 10y ago
Clearly you have missed this article: http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/

by georgyo 10y ago

fapjacks 10y ago

The one thing that is painfully obvious about the situation with init systems is that people have strong opinions about their preferences. And that makes the systemd situation even more terrible, since it's a choice unwillingly foisted upon a huge number of people. This situation really deserves some choices. For me, that is the number one reason I do not like systemd, even if it's solved some problems.

georgyo 10y ago
I agree with your reason, however for me they get outweighed by other factors. If I am a maintainer of a popular distribution, I want my distro to have the best init system, and I want that init system to have the largest user base. EL6 and its derivatives was upstart, debian and its derivatives was upstart. The vast majority of linux systems were upstart for a long period of time. Other systems did not switch to upstart, because it introduced headache. Switching init systems requires quite a bit of work. The fact that they all switched to systemd shows that beyond political pressure, they needed a better system.
- fapjacks 10y ago
  The choice that was put before the Debian TC was literally "Should we use systemd instead of sysvinit" and did not consider any of the many other init systems. In fact, a motion was put forward to the Debian TC to consider other init systems, and guess what? Pro-systemd TC members pointed to the original motion ("Should we use systemd instead of sysvinit") as the reason not to consider other init systems. That is pretty much as political as it gets.
  - Aeolos 10y ago
    For the record, this post is completely false, as even a cursory glance at the relevant Debian bug report will prove: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#672... We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be D systemd U upstart O openrc V sysvinit (no change) F requires further discussion [...] Therefore, the resolution reads: We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be systemd.
- jude- 10y ago
  I don't think the distro maintainers had that much say, since the most popular Linux desktop software began to depend on it. It started with GNOME, and now KDE is on its way. This basically forces their hand--if they want to provide a good out-of-the-box experience, they either have to switch to systemd, or continuously fight upstream's patches.
- regularfry 10y ago
  That's not my recollection. Upstart was an Ubuntu project, Debian never adopted it. Red Hat picked up upstart, then Poettering managed to convince them that they'd be better off with one they controlled. Somehow that filtered back through to Debian, and they jumped straight to systemd from sysvinit. At no point was it necessary for systemd to actually be better than upstart at being an init system. It just had to be bigger by the time it got to Debian.
mjevans 10y ago
There are exactly two compelling (for me) arguments against systemd, and one that seems to result from it's current focus: * Binary log files (WHYYYYY; OTOH you could argue that the only proper place to do logging is to a remote database.) * Monolithic nature - everything gets shoved in to the daemon, making it harder and more unusual to do things without it. * Servers - systemd seems to be focused on a desktop lifecycle, where users interactively log in, have settings and log out. It is less clear how secure or well this inter-operates with services running as 'users' for privilege separation. I think this may have recently gotten better.
- georgyo 10y ago
  All of these are false. It stores everything in binary logs, however your old system didn't store it at all. You had a daemon (syslog, rsyslog, etc) that wrote them as plain text. If you start those daemons, you at exactly the same spot as before. Just with an additional copy in a binary log. Which btw, journalctl can do some magical things, and you should take some time to play with it. systemd is not monolithic, or at the very least its a distributed monolith. The vast majority of services happen in their own userspace process. Systemd excels with servers, since it standardizes how their execution gets defined. It takes only an added line to spawn them in their own namespaces, set cgroup restrictions, prevent network access, etc. Before hand, doing these things was very hard, so no one did them.
  - Sanddancer 10y ago
    If you had a basic syslog setup, it stored as text files. However, a more interesting syslog setup would take those entries and send them to a remote database, filter them to match certain contents, run scripts based on those matches, etc. Systemd only seems magical because most distros don't use even a sliver of the abilities that modern syslogs provide. Systemd is a Jenga tower. Yes, there are lots of little pieces, and yes, removing a few won't hurt anything, but it's still fragile, and rather inconsistent. "Parts" like the journal, are a separate executable, but are not managed like other services. It uses a poorly documented ipc interface to talk to the various parts, and the configuration files are a nasty tangle of symlinks and control files stretching across the filesystem. It's just not a very well engineered piece of software.

djsumdog 10y ago

The only thing systemd solves, and I will say this is a big problem, is full process management. It also unifies startup scripts which does make it easier to support multiple distributions with a simpler packaging process. I'll give you that too. The scope creep is really bad. It's not just bad, it's terrible. I don't want a program that's an init, and replaces xinitd and replaces my logging system and replaces cron. That's all totally beyond unnecessary. Even with full process management, I'd hardly say it is the best. I have had cases where I stopped a service on a systemd box and it did leave child processes running. It's command line tools are terrible. In fact it's this creep that keeps people from even being able to make drop in replacements. uselessd was a fork that kept up for a bit, but lost maintainership. With systemd being RedHat funded for full time development, it's very difficult for independent programmers to put in the time to make anything that can get adopted in the way it is.

captainmuon 10y ago

I know not everybody has the same needs, but at least for me, systemd did not solve any problem I had. In fact, I found that it's main selling point, "better" service management, got much worse. Before, I could simply do "sudo service xxx start". Now, with systemctl, everything is much more cumbersome. Just run "systemctl list-units". Ho boy, you get a huge list of... things. Not just what used to be called services or daemons, but units belonging to mount points, /dev entries, and who knows what. Granted, it is probably easier to create service scripts for developers than with init.rc or upstart (although I never had a problem the few times I had to muck with them). But as a simple consumer, I do not feel systemd solves any problem I had. It just made things some things that worked fine before slightly more confusing, and there are some regressions every now and then while other programs are getting ported to systemd.

fridsun 10y ago

Clearly you have missed this article: http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/