14 ms·

I get that not everybody likes systemd, but a lot of the criticisms seem misguided and looking at sysvinit with role-colored glasses. For example, people are c

I get that not everybody likes systemd, but a lot of the criticisms seem misguided and looking at sysvinit with role-colored glasses. For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. Yes, there's parts to systemd that not everyone will use, like container support, but in that case you can pretty safely ignore that use case. For me, systemd has provided a much more consistent way of managing services. There's a tightly defined service definition format that allows one to comfortably modify any 3rd party service as well, (unlike random, variable-quality shell scripts), relatively small amount of commands to learn that work consistently across services, mounts, timers etc. There's also much better handling of modern hardware, hotplugging & the like. I can't say I miss sysvinit. Also, stuff like [1] from the anti-systemd camp doesn't inspire confidence. 1 - https://lwn.net/Articles/786593 https://lwn.net/Articles/786593

mruts 7y ago
I don’t think anyone thinks that sysvinit is better than systemd, but RC definitely is.
- PlutoIsAPlanet 7y ago
  You would be surprised.
- krzyk 7y ago
  Actually I do. systemd is too complicated for my needs, maybe it is usefull in some complicated system setups but for me (and probably others) it is too big, too complex and completely unneeded. What was the problem with sysvinit that they tried to fix? I don't see any.
  - JdeBP 7y ago
    systemd was aimed at the problems with Upstart rather than the problems with van Smoorenburg rc. van Smooreburg rc had already been superseded for its creators. Fedora was using Upstart. The problems with van Smoorenburg rc are widely acknowledged, however, and motivated the creation of Upstart, finit, init-ng, and many other softwares; indeed, the problems of System 3/5 init/rc, which van Smoorenburg rc began as a clone of, similarly motivated the creation of the SAF in AT&T Unix System 5 release 4, the Solaris SMF, and the AIX SRC. There is a history of superseding them that goes back for decades. It is clearly wrong to claim that they are without problem. They've been recognized as problematic and people have been replacing them since before Linux was invented. * http://jdebp.uk./FGA/system-5-rc-problems.html http://jdebp.uk./FGA/system-5-rc-problems.html * http://jdebp.uk./FGA/unix-service-access-facility.html http://jdebp.uk./FGA/unix-service-access-facility.html * https://blog.darknedgy.net/technology/2015/09/05/0/ https://blog.darknedgy.net/technology/2015/09/05/0/
Mediterraneo10 7y ago
> I can't say I miss sysvinit. Distros that choose not to employ systemd do not necessarily retain sysvinit.
- masklinn 7y ago
  They probably do though, openrc defaults to sysvinit as its PID1. I guess it's part of the confusion too, most of the systemd work was replacing the "rc bits" (process startup and management) not replacing PID1 itself.
  - jchw 7y ago
    I mean, before systemd there existed other initds. Upstart was Ubuntu’s for a time.
    - jasondclinton 7y ago
      The creator of Upstart, Scott, explicitly said that he thought that systemd was better and that Debian and Ubuntu adopting it was the right decision: https://www.reddit.com/r/LinuxActionShow/comments/1xzfv0/upstart_creator_on_ubuntus_systemd_switch/cffz9vh/ https://www.reddit.com/r/LinuxActionShow/comments/1xzfv0/ups...
      - jchw 7y ago
        I don’t really have a strong opinion anymore. Scott makes the right move here for professionalism and modesty, and Linux is more united on this than it isn’t. Still, the spats with the Linux kernel team and the rest of the community has earned systemd a reputation I can only say it deserves, even if the initial ire drawn towards it was over the top. Systemd is not a project I have strong confidence in to act in the user’s best interest, based on what I’ve seen with handling security issues.
    - throw7 7y ago
      It was redhat's also, albeit, for a very short time.
marcosdumay 7y ago
When there was a problem with a sysvinit procedure, one could simply fix it. As a result, mostly nobody ever had a problem with it. When there is a bug with systemd, you have to fix systemd. And your version of systemd is completely different from the head, because head was rewritten last month (in a process that persists bugs) and yours is a year old. You can't just use head either, because every low level system on your computer is tied to systemd, and they work differently on head. You won't fork it either, because it's so large that a single person can't keep up. Without a doubt, a declarative init is much better than an imperative one. But that relatively small number of commands is no gain if each command is more complex than the entire set it is replacing, and I'll completely disagree on the handling of modern hardware, hotplugging and the like. Besides, there is the entire logging saga against systemd.
- dmitryminkovsky 7y ago
  > As a result, mostly nobody ever had a problem with it. The number of broken init scripts I have encountered throughout the years, that went unfixed for months if not years, stand in stark contrast to this statement. And I’m talking packages like uWSGI on Ubuntu 14.04! This is exactly why I gravitated immediately to systemd. The idea that init scripts actually worked and when they didn’t were easily fixable is not true. Yeah you can fix a broken script locally, but this doesn’t fly at scale n > 1. Submitting patches to distros is not a simple process, and not one that makes sense in this context either. Declarative beats imperative 9/10 times, and systemd is one of those 9.
  - JohnFen 7y ago
    > The people who prefer initv are the people who enjoy digging in other people’s (untestable) Bash scripts This is demonstrably untrue. I strongly prefer SysV (which is not to say I think SysV is wonderful or anything) over systemD for a number of architectural and functional reasons. But I do not enjoy digging into other people's init scripts. Fortunately, I rarely have to do that. I think the last time I had a problem with someone's init script was over 7 years ago.
    - 7y ago
brobdingnagians 7y ago
Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. I don't think the code is high-quality, but even more than that I have a problem with the people being controlling, dismissive, and deceptive.
- boxfire 7y ago
  If systemd were a gstreamer plugin it would be in gstreamer-plugins-bad
- Piezoid 7y ago
  > They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. We should standardize on the interfaces, avoiding hard dependencies. There is dbus for that.
  - Crinus 7y ago
    dbus is also a dependency though. If you are on the bus (heh) that says systemd is a hard dependency that should be avoided then dbus is also the same thing.
    - eropple 7y ago
      I agree with your logical consistency, but I'm curious: is D-Bus sufficiently specified that one could write an alternative to it? That is, is it a hard dependency or is it itself an interface? I'm not nearly sufficiently experienced with desktop Linux application development to know. ;)
      - 7y ago
tyingq 7y ago
It's not the init replacement part that bugs me. It's the expansion into audio, kernel logging, resolvers, containers, and so forth that is the issue. It's a monolith of sorts that breaks the loosely coupled toolbox concept of Unix.
- eropple 7y ago
  Systemd is a bunch of loosely coupled tools, though; it's not a monolith at all. PulseAudio was written by Lennart but isn't part of systemd. You don't have to use systemd's resolver. systemd-nspawn is a completely separate process and isn't required for systemd as a whole. It's worth watching Benno Rice (a BSD developer, actually) discuss systemd and some of the misconceptions, some of which you're expressing, therein: https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo
  - yarrel 7y ago
    It's good that systemd apologists have moved on from arguing that it isn't a single binary. But it is not a bunch of loosely coupled tools any more than it is "just" an init replacement.
    - eropple 7y ago
      Hmm. "Apologists." Couldn't be that it's been a lot better for me where I regularly interact with it and has been no worse where I don't. It's gotta be apologism. We have to be out to getcha. I think you owe me an apology for that one, dude. More productively: what parts of systemd's ecosystem--aside, apparently, from journald, but the above no-harm-no-foul reply to the sibling still applies as far as I'm concerned--have you had trouble pulling out when you wanted to, out of curiosity?
      - ben509 7y ago
        > It's gotta be apologism. Apologists are engaging in apologia, which means a defense of one's ideas. It's not suggesting a hidden agenda, to the contrary, it suggests the agenda is fully on display since it's plain what is being defended.
api 7y ago
My gripe is bad UX. The whole system is needlessly obtuse and esoteric. Git is another popular thing with this problem, but in the case of git it provides so much value it's enough to get me to overcome its obtuseness. For systemd it's not "enough better" to get me to forgive it for being designed with no thought whatsoever to simplicity or ease of use. Another thing that makes me forgive git more is that its underlying design is rather novel and powerful. There is something to "get" in git (hah!) that justifies the cognitive investment. In the case of systemd the problem of managing services and their dependencies is not novel or really all that interesting. The complexity of the systemd UX is significantly greater than the novelty or sophistication of what it's doing. It's a piece of software built to complexify the simple.
- dual_basis 7y ago
  I strongly agree that git has a UX issue, and the widespread adoption of it over mercurial is a perfect example of inertia leading us to get stuck in a local minima.
  - api 7y ago
    I haven't tried hg but from what I've seen one major advantage of git that gets under-acknowledged is its speed. Git is fast and fast really does matter for a version control system you use constantly. Is hg as fast as git?
    - AndrewUnmuted 7y ago
      Personally, I like pushing with hg, but I prefer pulling with git. An HgHub service at the scale of GitHub would probably result in massive end-user UX issues but maybe happier developers and repo administrators.
      - e12e 7y ago
        This reminds how pleasant it was to use hg as a git front-end (via an extention[0]) - compared to using the git cli. I think I'll have to revisit and see if that's still the case, and if I can make it work with feature branches etc. Also looks like there's finally python3 support in the recent mercurial 5.0 release. [0] https://hg-git.github.io/ https://hg-git.github.io/
iamvik 7y ago
It's a stupid position to take - watch luke smith's video on it for a neutral point of view. https://www.youtube.com/watch?v=_ljfOCiP0XM https://www.youtube.com/watch?v=_ljfOCiP0XM
vbezhenar 7y ago
sysvinit is easier to understand for me. It's just a bunch of shell scripts after all. So from the point of simplicity sysvinit wins for me and I never had much problems with it (while I had some problems with systemd). On the other hand, I recently had to write unit file for tomcat and it was extremely easy, systemd had all necessary options. Writing shell script was not that hard, of course, but it was some work.
- sprash 7y ago
  One reason even big ol sysvinit is superior to systemd is that shell scripts are transitive knowledge. You can do almost everything with shell scripts. Learning some obscure (albeit very simple) systemd unit file format won't help you anywhere else besides systemd.
  - AsyncAwait 7y ago
    > One reason even big ol sysvinit is superior to systemd is that shell scripts are transitive knowledge. In theory. In practice systemd's actually much more transitive since many distros have adopted it and systemd services tend to work cross-distro, so once you learn systemd you can somewhat confidently manage Fedora, RHEL, Ubuntu, Arch, SuSE, Nix etc. sysvinit shell scripts often differed in subtle ways between distros and the particular distro implementation was rarely transportable without quite a bit of work. > You can do almost everything with shell scripts. This cuts both ways. I'd argue the problem with sysvinit was precisely the fact that you can do almost everything with shell scripts, since now you're executing a script as root that can do almost anything, depends heavily on the bash abilities of the author to not introduce subtle bugs, or break easily, (which varied heavily from script to script and distro to distro), and to not be a security nightmare.
AtHeartEngineer 7y ago
Agreed, I very much like systemd. The documentation could be a bit better (though I haven't looked at it much in the last year), but overall it's a good improvement. I first started using systemd with Arch before it got pulled into Ubuntu. It definitely took a little bit to get used to, but once you understand how to write services instead of cron jobs, it's way more betterer.
chme 7y ago
I am not in any camp. I do think that systemd is very useful but have concerns that they simply don't have the man power to maintain that broad feature set and scope they have set themselves. What previously would be done in multiple different competing projects by different people with different ideas in different companies, is now done in a single code-base. I can imagine that innovation will be hindered that way, because systemd is not Linux. But maybe some day it will be, IDK. Currently it is just to big to scale that well to small systems though.
- AsyncAwait 7y ago
  That's a valid concern, but it's worth noting that not every component systemd replaced, (ie consolekit), was actually being maintained, so arguably we're in a better situation now from that standpoint.
  - m4rtink 7y ago
    Not to mention systemd being used in all current enterprise Linux distros with people being paid for maintaining it in missing critical usecases.
  - chme 7y ago
    Isn't it now much more difficult to figure out if certain components are or are not maintained? ConsoleKit was used in many commercial linux distributions and still wasn't maintained, now that its part of systemd and systemd is maintained, does that mean that every component of it is as well?
nwallin 7y ago
I get that systemd works for you, and I'm not telling you (or others) that you shouldn't use it. The problem is the systemd monoculture. Wayland, Gnome etc are non-starters because they have hard dependencies on systemd, which is ridiculous. > For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. I use neither logind nor consolekit. These are solutions for problems I don't have. Moreover, they often get in the way: when I ssh into my media PC, I don't want logind/consolekit to tell me I'm not allowed to access the sound or video cards. The only function that machine performs is to do the thing that logind/consolekit are designed to prevent. And it's a required component of systemd. I'm glad it's easier for you to manage services with systemd. But it's easier for me to manage services with OpenRC, and there's nothing wrong with that. As far as handling modern hardware- huh? I guess it's not clear to me what interactions an init manager is supposed to have with hardware. Which really speaks to my primary issue with systemd: it's a freaking monster. It does nine million things, but I only need it to do like three things: start services when I tell it to start services, stop them when I tell it to stop them, and restart them if they crash. (if it's configured to do so) That's it. Why do I need or want it to interact with my hardware? Why does it need an integrated web server in order to start apache? Why does it a logging daemon in order to start syslog-ng? Why do I have to use its built in log reader instead of tail, less, grep etc? Where is the boundary between systemd and the rest of my system?
- AsyncAwait 7y ago
  > The problem is the systemd monoculture. And sysvinit wasn't pretty much a monocultur?. I mean even OpenRC is basically sysvinit with a lipstick. > These are solutions for problems I don't have. Good for you. But event handling is something that many systems today do need and I think we should try to optimize for the common use case. As for you not needing logind/consolekit, sure, if security is not a concern on a system, they're not needed, but again, that's not true for most systems. GNOME etc. also don't really have a hard dependency on systemd, they depend on logind, which does not necessarily require systemd and indeed GNOME ships on Gentoo, Void etc. It's also not like the GNOME devs are stupid and got tricked into depending on logind or something. Mo, it solves real problems for them, so they depend on it. Why is this hard to grasp?
yellowapple 7y ago
> looking at sysvinit That's the thing: there are lots of alternatives besides sysvinit specifically (OpenRC, Upstart, BSD-style RC, launchd, SMF, runit, etc.) on varying scales from "simpler than even sysvinit" to "more feature-rich than systemd". And yet, the best the systemd advocates could ever muster up is/was criticizing specific flaws with just sysvinit. Of course sysvinit sucks, but you'll notice that (Devuan being the notable exception) most of the article's listed distros use something that's very much not sysvinit.
apexalpha 7y ago
RHEL has Systemd since 2014, Ubuntu and Debian as well. Even the purists at Arch have Systemd as default since 2012. Sure, it ain't perfect. But maybe if all the professional kernel developers and distro managers chose Systemd, and yet some angry people online keep basing their opinions on random amateur blogs catering to a certain narative, regardless of expert opinions, then maybe we can conclude that... ... anti-systemd people are the anti-vaxxers of the Linux world.

mruts 7y ago

I don’t think anyone thinks that sysvinit is better than systemd, but RC definitely is.

PlutoIsAPlanet 7y ago
You would be surprised.
krzyk 7y ago
Actually I do. systemd is too complicated for my needs, maybe it is usefull in some complicated system setups but for me (and probably others) it is too big, too complex and completely unneeded. What was the problem with sysvinit that they tried to fix? I don't see any.
- JdeBP 7y ago
  systemd was aimed at the problems with Upstart rather than the problems with van Smoorenburg rc. van Smooreburg rc had already been superseded for its creators. Fedora was using Upstart. The problems with van Smoorenburg rc are widely acknowledged, however, and motivated the creation of Upstart, finit, init-ng, and many other softwares; indeed, the problems of System 3/5 init/rc, which van Smoorenburg rc began as a clone of, similarly motivated the creation of the SAF in AT&T Unix System 5 release 4, the Solaris SMF, and the AIX SRC. There is a history of superseding them that goes back for decades. It is clearly wrong to claim that they are without problem. They've been recognized as problematic and people have been replacing them since before Linux was invented. * http://jdebp.uk./FGA/system-5-rc-problems.html http://jdebp.uk./FGA/system-5-rc-problems.html * http://jdebp.uk./FGA/unix-service-access-facility.html http://jdebp.uk./FGA/unix-service-access-facility.html * https://blog.darknedgy.net/technology/2015/09/05/0/ https://blog.darknedgy.net/technology/2015/09/05/0/

Mediterraneo10 7y ago

> I can't say I miss sysvinit. Distros that choose not to employ systemd do not necessarily retain sysvinit.

masklinn 7y ago
They probably do though, openrc defaults to sysvinit as its PID1. I guess it's part of the confusion too, most of the systemd work was replacing the "rc bits" (process startup and management) not replacing PID1 itself.
- jchw 7y ago
  I mean, before systemd there existed other initds. Upstart was Ubuntu’s for a time.
  - jasondclinton 7y ago
    The creator of Upstart, Scott, explicitly said that he thought that systemd was better and that Debian and Ubuntu adopting it was the right decision: https://www.reddit.com/r/LinuxActionShow/comments/1xzfv0/upstart_creator_on_ubuntus_systemd_switch/cffz9vh/ https://www.reddit.com/r/LinuxActionShow/comments/1xzfv0/ups...
    - jchw 7y ago
      I don’t really have a strong opinion anymore. Scott makes the right move here for professionalism and modesty, and Linux is more united on this than it isn’t. Still, the spats with the Linux kernel team and the rest of the community has earned systemd a reputation I can only say it deserves, even if the initial ire drawn towards it was over the top. Systemd is not a project I have strong confidence in to act in the user’s best interest, based on what I’ve seen with handling security issues.
  - throw7 7y ago
    It was redhat's also, albeit, for a very short time.

marcosdumay 7y ago

When there was a problem with a sysvinit procedure, one could simply fix it. As a result, mostly nobody ever had a problem with it. When there is a bug with systemd, you have to fix systemd. And your version of systemd is completely different from the head, because head was rewritten last month (in a process that persists bugs) and yours is a year old. You can't just use head either, because every low level system on your computer is tied to systemd, and they work differently on head. You won't fork it either, because it's so large that a single person can't keep up. Without a doubt, a declarative init is much better than an imperative one. But that relatively small number of commands is no gain if each command is more complex than the entire set it is replacing, and I'll completely disagree on the handling of modern hardware, hotplugging and the like. Besides, there is the entire logging saga against systemd.

dmitryminkovsky 7y ago
> As a result, mostly nobody ever had a problem with it. The number of broken init scripts I have encountered throughout the years, that went unfixed for months if not years, stand in stark contrast to this statement. And I’m talking packages like uWSGI on Ubuntu 14.04! This is exactly why I gravitated immediately to systemd. The idea that init scripts actually worked and when they didn’t were easily fixable is not true. Yeah you can fix a broken script locally, but this doesn’t fly at scale n > 1. Submitting patches to distros is not a simple process, and not one that makes sense in this context either. Declarative beats imperative 9/10 times, and systemd is one of those 9.
- JohnFen 7y ago
  > The people who prefer initv are the people who enjoy digging in other people’s (untestable) Bash scripts This is demonstrably untrue. I strongly prefer SysV (which is not to say I think SysV is wonderful or anything) over systemD for a number of architectural and functional reasons. But I do not enjoy digging into other people's init scripts. Fortunately, I rarely have to do that. I think the last time I had a problem with someone's init script was over 7 years ago.
  - 7y ago

brobdingnagians 7y ago

Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. I don't think the code is high-quality, but even more than that I have a problem with the people being controlling, dismissive, and deceptive.

boxfire 7y ago
If systemd were a gstreamer plugin it would be in gstreamer-plugins-bad
Piezoid 7y ago
> They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. We should standardize on the interfaces, avoiding hard dependencies. There is dbus for that.
- Crinus 7y ago
  dbus is also a dependency though. If you are on the bus (heh) that says systemd is a hard dependency that should be avoided then dbus is also the same thing.
  - eropple 7y ago
    I agree with your logical consistency, but I'm curious: is D-Bus sufficiently specified that one could write an alternative to it? That is, is it a hard dependency or is it itself an interface? I'm not nearly sufficiently experienced with desktop Linux application development to know. ;)
    - 7y ago

tyingq 7y ago

It's not the init replacement part that bugs me. It's the expansion into audio, kernel logging, resolvers, containers, and so forth that is the issue. It's a monolith of sorts that breaks the loosely coupled toolbox concept of Unix.

eropple 7y ago
Systemd is a bunch of loosely coupled tools, though; it's not a monolith at all. PulseAudio was written by Lennart but isn't part of systemd. You don't have to use systemd's resolver. systemd-nspawn is a completely separate process and isn't required for systemd as a whole. It's worth watching Benno Rice (a BSD developer, actually) discuss systemd and some of the misconceptions, some of which you're expressing, therein: https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo
- yarrel 7y ago
  It's good that systemd apologists have moved on from arguing that it isn't a single binary. But it is not a bunch of loosely coupled tools any more than it is "just" an init replacement.
  - eropple 7y ago
    Hmm. "Apologists." Couldn't be that it's been a lot better for me where I regularly interact with it and has been no worse where I don't. It's gotta be apologism. We have to be out to getcha. I think you owe me an apology for that one, dude. More productively: what parts of systemd's ecosystem--aside, apparently, from journald, but the above no-harm-no-foul reply to the sibling still applies as far as I'm concerned--have you had trouble pulling out when you wanted to, out of curiosity?
    - ben509 7y ago
      > It's gotta be apologism. Apologists are engaging in apologia, which means a defense of one's ideas. It's not suggesting a hidden agenda, to the contrary, it suggests the agenda is fully on display since it's plain what is being defended.

api 7y ago

My gripe is bad UX. The whole system is needlessly obtuse and esoteric. Git is another popular thing with this problem, but in the case of git it provides so much value it's enough to get me to overcome its obtuseness. For systemd it's not "enough better" to get me to forgive it for being designed with no thought whatsoever to simplicity or ease of use. Another thing that makes me forgive git more is that its underlying design is rather novel and powerful. There is something to "get" in git (hah!) that justifies the cognitive investment. In the case of systemd the problem of managing services and their dependencies is not novel or really all that interesting. The complexity of the systemd UX is significantly greater than the novelty or sophistication of what it's doing. It's a piece of software built to complexify the simple.

dual_basis 7y ago
I strongly agree that git has a UX issue, and the widespread adoption of it over mercurial is a perfect example of inertia leading us to get stuck in a local minima.
- api 7y ago
  I haven't tried hg but from what I've seen one major advantage of git that gets under-acknowledged is its speed. Git is fast and fast really does matter for a version control system you use constantly. Is hg as fast as git?
  - AndrewUnmuted 7y ago
    Personally, I like pushing with hg, but I prefer pulling with git. An HgHub service at the scale of GitHub would probably result in massive end-user UX issues but maybe happier developers and repo administrators.
    - e12e 7y ago
      This reminds how pleasant it was to use hg as a git front-end (via an extention[0]) - compared to using the git cli. I think I'll have to revisit and see if that's still the case, and if I can make it work with feature branches etc. Also looks like there's finally python3 support in the recent mercurial 5.0 release. [0] https://hg-git.github.io/ https://hg-git.github.io/

iamvik 7y ago

It's a stupid position to take - watch luke smith's video on it for a neutral point of view. https://www.youtube.com/watch?v=_ljfOCiP0XM https://www.youtube.com/watch?v=_ljfOCiP0XM

vbezhenar 7y ago

sysvinit is easier to understand for me. It's just a bunch of shell scripts after all. So from the point of simplicity sysvinit wins for me and I never had much problems with it (while I had some problems with systemd). On the other hand, I recently had to write unit file for tomcat and it was extremely easy, systemd had all necessary options. Writing shell script was not that hard, of course, but it was some work.

sprash 7y ago
One reason even big ol sysvinit is superior to systemd is that shell scripts are transitive knowledge. You can do almost everything with shell scripts. Learning some obscure (albeit very simple) systemd unit file format won't help you anywhere else besides systemd.
- AsyncAwait 7y ago
  > One reason even big ol sysvinit is superior to systemd is that shell scripts are transitive knowledge. In theory. In practice systemd's actually much more transitive since many distros have adopted it and systemd services tend to work cross-distro, so once you learn systemd you can somewhat confidently manage Fedora, RHEL, Ubuntu, Arch, SuSE, Nix etc. sysvinit shell scripts often differed in subtle ways between distros and the particular distro implementation was rarely transportable without quite a bit of work. > You can do almost everything with shell scripts. This cuts both ways. I'd argue the problem with sysvinit was precisely the fact that you can do almost everything with shell scripts, since now you're executing a script as root that can do almost anything, depends heavily on the bash abilities of the author to not introduce subtle bugs, or break easily, (which varied heavily from script to script and distro to distro), and to not be a security nightmare.

AtHeartEngineer 7y ago

Agreed, I very much like systemd. The documentation could be a bit better (though I haven't looked at it much in the last year), but overall it's a good improvement. I first started using systemd with Arch before it got pulled into Ubuntu. It definitely took a little bit to get used to, but once you understand how to write services instead of cron jobs, it's way more betterer.

chme 7y ago

I am not in any camp. I do think that systemd is very useful but have concerns that they simply don't have the man power to maintain that broad feature set and scope they have set themselves. What previously would be done in multiple different competing projects by different people with different ideas in different companies, is now done in a single code-base. I can imagine that innovation will be hindered that way, because systemd is not Linux. But maybe some day it will be, IDK. Currently it is just to big to scale that well to small systems though.

AsyncAwait 7y ago
That's a valid concern, but it's worth noting that not every component systemd replaced, (ie consolekit), was actually being maintained, so arguably we're in a better situation now from that standpoint.
- m4rtink 7y ago
  Not to mention systemd being used in all current enterprise Linux distros with people being paid for maintaining it in missing critical usecases.
- chme 7y ago
  Isn't it now much more difficult to figure out if certain components are or are not maintained? ConsoleKit was used in many commercial linux distributions and still wasn't maintained, now that its part of systemd and systemd is maintained, does that mean that every component of it is as well?

nwallin 7y ago

I get that systemd works for you, and I'm not telling you (or others) that you shouldn't use it. The problem is the systemd monoculture. Wayland, Gnome etc are non-starters because they have hard dependencies on systemd, which is ridiculous. > For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. I use neither logind nor consolekit. These are solutions for problems I don't have. Moreover, they often get in the way: when I ssh into my media PC, I don't want logind/consolekit to tell me I'm not allowed to access the sound or video cards. The only function that machine performs is to do the thing that logind/consolekit are designed to prevent. And it's a required component of systemd. I'm glad it's easier for you to manage services with systemd. But it's easier for me to manage services with OpenRC, and there's nothing wrong with that. As far as handling modern hardware- huh? I guess it's not clear to me what interactions an init manager is supposed to have with hardware. Which really speaks to my primary issue with systemd: it's a freaking monster. It does nine million things, but I only need it to do like three things: start services when I tell it to start services, stop them when I tell it to stop them, and restart them if they crash. (if it's configured to do so) That's it. Why do I need or want it to interact with my hardware? Why does it need an integrated web server in order to start apache? Why does it a logging daemon in order to start syslog-ng? Why do I have to use its built in log reader instead of tail, less, grep etc? Where is the boundary between systemd and the rest of my system?

AsyncAwait 7y ago
> The problem is the systemd monoculture. And sysvinit wasn't pretty much a monocultur?. I mean even OpenRC is basically sysvinit with a lipstick. > These are solutions for problems I don't have. Good for you. But event handling is something that many systems today do need and I think we should try to optimize for the common use case. As for you not needing logind/consolekit, sure, if security is not a concern on a system, they're not needed, but again, that's not true for most systems. GNOME etc. also don't really have a hard dependency on systemd, they depend on logind, which does not necessarily require systemd and indeed GNOME ships on Gentoo, Void etc. It's also not like the GNOME devs are stupid and got tricked into depending on logind or something. Mo, it solves real problems for them, so they depend on it. Why is this hard to grasp?

yellowapple 7y ago

> looking at sysvinit That's the thing: there are lots of alternatives besides sysvinit specifically (OpenRC, Upstart, BSD-style RC, launchd, SMF, runit, etc.) on varying scales from "simpler than even sysvinit" to "more feature-rich than systemd". And yet, the best the systemd advocates could ever muster up is/was criticizing specific flaws with just sysvinit. Of course sysvinit sucks, but you'll notice that (Devuan being the notable exception) most of the article's listed distros use something that's very much not sysvinit.

apexalpha 7y ago

RHEL has Systemd since 2014, Ubuntu and Debian as well. Even the purists at Arch have Systemd as default since 2012. Sure, it ain't perfect. But maybe if all the professional kernel developers and distro managers chose Systemd, and yet some angry people online keep basing their opinions on random amateur blogs catering to a certain narative, regardless of expert opinions, then maybe we can conclude that... ... anti-systemd people are the anti-vaxxers of the Linux world.