9 ms·

I'm also wondering this. I've seen plenty of hate for systemd, but I've never personally run into any issues with it.

Nursie 8y ago
The hate largely stems from the way it was rolled out - the linux community at large was left feeling like it had been told it would adopt this, and there was no choice, and that rubbed a lot of people up the wrong way. It's also not 'the unix way' to have tightly bound, large blobs, and the team behind it seemed to take pains to say that lots of other things would rely on it, like udev, so there really was no choice. So the hate comes from the idealogical side, largely. Personally, having worked with it, I've rather liked writing service files and timers to get stuff done, it's much quicker to get something up and running than the old system.
- dvfjsdhgfv 8y ago
  > The hate largely stems from the way it was rolled out - the linux community at large was left feeling like it had been told it wold adopt this, and there was no choice, and that rubbed a lot of people up the wrong way. It wasn't just a feeling, it really was just like that. Had the architecture of Systemd been different, it would have been possible to decouple it from other components and be able too choose an init system just like in the not so distant past. As it is now, practically speaking there is no choice.
  - bayindirh 8y ago
    Doesn't Debian support[0] init system switching? Just curious. [0]: https://wiki.debian.org/Init https://wiki.debian.org/Init
    - rosser 8y ago
      It does, but packages aren't obligated to provide sysvinit scripts for your non-systemd-using convenience. Over time, the number of packages that do will fall, because engineer convenience and cognitive bandwidth are incredibly high priorities; "that's the crusty old way while this is the new hotness"; and, "oh, but we need this one little thing systemd offers," &c. And before you know it, those of us on the ops side are stuck supporting something we loathe, and having to rewrite a bunch of scripting and tooling in response to discovering new and exciting ways the "new hotness" ends up breaking things that worked perfectly well until it came along. Literally, we're facing another iteration of that very cycle right now: our non-production environment refresh process suddenly fails to complete without being manually thumped at multiple points. Why? System fucking d. But no: "It works fine for us, so it can't be a problem for anyone else, right? Right?"
      - craigsmansion 8y ago
        Debian recently reached out to Devuan for sysvinit maintenance. Devuan has, in spite of a somewhat acrimonious start, delivered what they set out to do, a Debian without SystemD, so it might be worth consideration when dist-upgrading.
      - majewsky 8y ago
        > Over time, the number of packages that do will fall, because engineer convenience and cognitive bandwidth are incredibly high priorities; "that's the crusty old way while this is the new hotness"; and, "oh, but we need this one little thing systemd offers," &c. The thing that many people don't understand about systemd is that they don't have to sell to users or developers, they have to sell to (and design for) distributors. Lennart and Kay know that because they are both working for distributors (Redhat and Suse, respectively). To distributors, the promise of systemd is the promise of less integration work. It paves over a ton of useless idiosyncracies in distributions (e.g. compare systemd's /etc/os-release with the previous /etc/*-release files that you cannot even call by name because they were called something else on each distribution). Initscripts is the biggest bullet point in that list: Initscripts were always written by the distribution because each distribution had their own scripting layer on top of sysvinit to make it a bit nicer, and each of these was incompatible with those of other distributions. Systemd units, on the other hand, can be maintained by the application developers themselves, and several distros (e.g. the patch-hating Arch Linux) actively pushes systemd units upstream. When the application developer takes care and has only one target (the de-facto standards forced by systemd), life gets a whole lot easier for distributors. And that's why distributors choose systemd.
        dvfjsdhgfv 8y ago
        Well, it doesn't explain why Debian gave in. They're supposed to listen to the people, aren't they?
        bayindirh 8y ago
        They have listened to the people. Systemd has selected as a result of a poll [0]. [0] https://people.debian.org/~stapelberg/2013/05/27/systemd-survey-results.html https://people.debian.org/~stapelberg/2013/05/27/systemd-sur...
  - krylon 8y ago
    Fwiw, some distros have stuck with different init systems: Void uses runit, Devuan (Debian fork) uses sysvinit, Gentoo uses OpenRC[1]. There are probably more that I am not aware of. Systemd has not given me any trouble, yet, but I run Void in a VM, and it boots extremely fast. [1] I believe one can also use different init systems on Gentoo, after all it is Gentoo, but I have not touched it in years, so I do not know for sure.
bayindirh 8y ago
administration differences, not being designed according to UNIX principles and personal dislike towards developer(s) is coming to my mind. administration differences is the most direct effect of systemd, but after learning its various compatibility layers and watchdog functions, it can be tamed to a great helper. not being designed according to UNIX principles (composition of single-role small applications, which are doing their jobs very very well) is also bothering me, but we need to be pragmatic here. inter-process-communication cannot replace in-memory-communication in all cases it seems. The hate towards the developer(s) is stemming from his attitude, history (he's also developer of pulseaudio IIRC) and somewhat from his coding style. It seems like he's a kind of guy who can defend his work, do this in an unorthodox way, make it work and got it accepted. At the end of the day, the hate is a feeling and is personal. I think we need to be pragmatic here too. Not that better communication from both parties will benefit everyone and everything in the long run. At the end of the day, we are using systemd, and it's working. If we want a better system, we need to improve it. systemd is the state of the art right now, and we should either write something better or improve it if we have any beef with systemd itself. OTOH, Beef with developers is something that should stay out of software and community in general. My original comment was trying to explore whether there are more reasons to dislike it besides the original points that I stated above.
- edwr 8y ago
  "Those days are dead and gone and the eulogy was delivered by Perl." - Rob Pike on the UNIX principles
- lloeki 8y ago
  > administration differences is the most direct effect of systemd, but after learning its various compatibility layers and watchdog functions, it can be tamed to a great helper. It's both a negative and a positive. It's a change for sure but nowadays I can log into an ArchLinux, Fedora, Ubuntu, Debian,... machine and just leverage systemd instead of whatever local idiom (and its various assorted corner-cases) the distro decided to use. It's becoming the happy path of the XKCD comic about standards.
  - 8y ago
nottorp 8y ago
Well, yesterday I was messing with hostapd custom configurations, and starting/stopping it from systemd seems to give absolutely no feedback. It doesn't even tell me if it started or not. Very advanced and helpful, eh?
- bayindirh 8y ago
  As an (un)written rule, UNIX commands are mostly silent, and output something if something went wrong. This is one of the things that systemd got right I think. Yes, it feels awkward at first, but systemd's behavior is not wrong. edit: oh, downvoted, OK. This is actually an outcome of rule of silence, which is part of the UNIX philosophy [0]. [0]: https://en.wikipedia.org/wiki/Unix_philosophy#Rule_of_Silence https://en.wikipedia.org/wiki/Unix_philosophy#Rule_of_Silenc...
baq 8y ago
my ubuntu 16.04 LTS requires a 'service networking restart' after any update that touches systemd. having to log onto the vm console to do that kinda sucks. otherwise i don't care what's under the hood.

The hate largely stems from the way it was rolled out - the linux community at large was left feeling like it had been told it would adopt this, and there was no choice, and that rubbed a lot of people up the wrong way. It's also not 'the unix way' to have tightly bound, large blobs, and the team behind it seemed to take pains to say that lots of other things would rely on it, like udev, so there really was no choice. So the hate comes from the idealogical side, largely. Personally, having worked with it, I've rather liked writing service files and timers to get stuff done, it's much quicker to get something up and running than the old system.

dvfjsdhgfv 8y ago
> The hate largely stems from the way it was rolled out - the linux community at large was left feeling like it had been told it wold adopt this, and there was no choice, and that rubbed a lot of people up the wrong way. It wasn't just a feeling, it really was just like that. Had the architecture of Systemd been different, it would have been possible to decouple it from other components and be able too choose an init system just like in the not so distant past. As it is now, practically speaking there is no choice.
- bayindirh 8y ago
  Doesn't Debian support[0] init system switching? Just curious. [0]: https://wiki.debian.org/Init https://wiki.debian.org/Init
  - rosser 8y ago
    It does, but packages aren't obligated to provide sysvinit scripts for your non-systemd-using convenience. Over time, the number of packages that do will fall, because engineer convenience and cognitive bandwidth are incredibly high priorities; "that's the crusty old way while this is the new hotness"; and, "oh, but we need this one little thing systemd offers," &c. And before you know it, those of us on the ops side are stuck supporting something we loathe, and having to rewrite a bunch of scripting and tooling in response to discovering new and exciting ways the "new hotness" ends up breaking things that worked perfectly well until it came along. Literally, we're facing another iteration of that very cycle right now: our non-production environment refresh process suddenly fails to complete without being manually thumped at multiple points. Why? System fucking d. But no: "It works fine for us, so it can't be a problem for anyone else, right? Right?"
    - craigsmansion 8y ago
      Debian recently reached out to Devuan for sysvinit maintenance. Devuan has, in spite of a somewhat acrimonious start, delivered what they set out to do, a Debian without SystemD, so it might be worth consideration when dist-upgrading.
    - majewsky 8y ago
      > Over time, the number of packages that do will fall, because engineer convenience and cognitive bandwidth are incredibly high priorities; "that's the crusty old way while this is the new hotness"; and, "oh, but we need this one little thing systemd offers," &c. The thing that many people don't understand about systemd is that they don't have to sell to users or developers, they have to sell to (and design for) distributors. Lennart and Kay know that because they are both working for distributors (Redhat and Suse, respectively). To distributors, the promise of systemd is the promise of less integration work. It paves over a ton of useless idiosyncracies in distributions (e.g. compare systemd's /etc/os-release with the previous /etc/*-release files that you cannot even call by name because they were called something else on each distribution). Initscripts is the biggest bullet point in that list: Initscripts were always written by the distribution because each distribution had their own scripting layer on top of sysvinit to make it a bit nicer, and each of these was incompatible with those of other distributions. Systemd units, on the other hand, can be maintained by the application developers themselves, and several distros (e.g. the patch-hating Arch Linux) actively pushes systemd units upstream. When the application developer takes care and has only one target (the de-facto standards forced by systemd), life gets a whole lot easier for distributors. And that's why distributors choose systemd.
      - dvfjsdhgfv 8y ago
        Well, it doesn't explain why Debian gave in. They're supposed to listen to the people, aren't they?
        bayindirh 8y ago
        They have listened to the people. Systemd has selected as a result of a poll [0]. [0] https://people.debian.org/~stapelberg/2013/05/27/systemd-survey-results.html https://people.debian.org/~stapelberg/2013/05/27/systemd-sur...
- krylon 8y ago
  Fwiw, some distros have stuck with different init systems: Void uses runit, Devuan (Debian fork) uses sysvinit, Gentoo uses OpenRC[1]. There are probably more that I am not aware of. Systemd has not given me any trouble, yet, but I run Void in a VM, and it boots extremely fast. [1] I believe one can also use different init systems on Gentoo, after all it is Gentoo, but I have not touched it in years, so I do not know for sure.

bayindirh 8y ago

administration differences, not being designed according to UNIX principles and personal dislike towards developer(s) is coming to my mind. administration differences is the most direct effect of systemd, but after learning its various compatibility layers and watchdog functions, it can be tamed to a great helper. not being designed according to UNIX principles (composition of single-role small applications, which are doing their jobs very very well) is also bothering me, but we need to be pragmatic here. inter-process-communication cannot replace in-memory-communication in all cases it seems. The hate towards the developer(s) is stemming from his attitude, history (he's also developer of pulseaudio IIRC) and somewhat from his coding style. It seems like he's a kind of guy who can defend his work, do this in an unorthodox way, make it work and got it accepted. At the end of the day, the hate is a feeling and is personal. I think we need to be pragmatic here too. Not that better communication from both parties will benefit everyone and everything in the long run. At the end of the day, we are using systemd, and it's working. If we want a better system, we need to improve it. systemd is the state of the art right now, and we should either write something better or improve it if we have any beef with systemd itself. OTOH, Beef with developers is something that should stay out of software and community in general. My original comment was trying to explore whether there are more reasons to dislike it besides the original points that I stated above.

edwr 8y ago
"Those days are dead and gone and the eulogy was delivered by Perl." - Rob Pike on the UNIX principles
lloeki 8y ago
> administration differences is the most direct effect of systemd, but after learning its various compatibility layers and watchdog functions, it can be tamed to a great helper. It's both a negative and a positive. It's a change for sure but nowadays I can log into an ArchLinux, Fedora, Ubuntu, Debian,... machine and just leverage systemd instead of whatever local idiom (and its various assorted corner-cases) the distro decided to use. It's becoming the happy path of the XKCD comic about standards.
- 8y ago

nottorp 8y ago

Well, yesterday I was messing with hostapd custom configurations, and starting/stopping it from systemd seems to give absolutely no feedback. It doesn't even tell me if it started or not. Very advanced and helpful, eh?

bayindirh 8y ago
As an (un)written rule, UNIX commands are mostly silent, and output something if something went wrong. This is one of the things that systemd got right I think. Yes, it feels awkward at first, but systemd's behavior is not wrong. edit: oh, downvoted, OK. This is actually an outcome of rule of silence, which is part of the UNIX philosophy [0]. [0]: https://en.wikipedia.org/wiki/Unix_philosophy#Rule_of_Silence https://en.wikipedia.org/wiki/Unix_philosophy#Rule_of_Silenc...

baq 8y ago

my ubuntu 16.04 LTS requires a 'service networking restart' after any update that touches systemd. having to log onto the vm console to do that kinda sucks. otherwise i don't care what's under the hood.