3 ms·

Might be worth pondering what Poettering and Red Hat did that make people hate their work so much, and to make Poettering uniquely infamous in the open source w

Might be worth pondering what Poettering and Red Hat did that make people hate their work so much, and to make Poettering uniquely infamous in the open source world. No-one's upset with the creators of dozens of other init systems and audio daemons, including ones that are pretty bad, and even ones that were promoted by major distro vendors.

sophacles 4y ago
From my point of view as an old guy who remembers the hell of init scripts, what they did was make an alternative to remembering arcane details of how each os and distro chose to set up their scripts. This: * made debugging a random system a lot more straight forward * made putting up software for packaging a lot easier * made customizing the start-up of a daemon a lot easier (this ties in with the first point) * made it so I didn't have to go to the guru who's only job seemed to be managing our obtuse set of init scripts that were extra baroque because order of startup really mattered. That guy I had to go to - he was an asshole an lorded his knowledge of arcana over anyone who brought him a question. I'm 90% sure he made it intentionally complex since he didn't have much skill beyond memorizing those silly facts (this is the same guy who got an entire project reassigned to me because he couldn't understand the concept of functions when I removed some extreme repetition from a python script he wrote). Most of the systemd haters remind me of this guy. I guess what you're implying is that he helped automate away dead weight and that made the leeches mad?
- zozbot234 4y ago
  These "simple" use cases break when you need to do anything even slightly more complex than whatever the systemD designers envisioned for the user. And if you try to submit an issue upstream, the typical response is "you're holding it wrong" or equivalent. This lack of a consistent design might be excusable when first trying to support a bunch of entirely novel use cases, but let's not pretend that it doesn't come with serious drawbacks.
  - sophacles 4y ago
    I have yet to encounter something that systemd doesn't do OK or well. What is your example of something that systemd can't handle that was better handled by init scripts?
  - ElectricalUnion 4y ago
    These "simple" use cases break when you need to do anything even slightly more complex than whatever the sysvinit scripts you copied envisioned. FTFY systemd might be sad but makes the simple case simple. sysvinit makes everything complex and error prone.
    - sam_lowry_ 4y ago
      sysvinit could be debugged, at least. I tried to debug a couple of systemd edge cases with Pottering, communicating over Github Issues, but he lost interest very quickly. To his, credit he is reactive until he decides the issue is not worth his time. To his discredit, he made himself into a giant bottleneck. Random systemd users can not easily understand it.
  - kaba0 4y ago
    I’m sure then you can list a use-case which doesn’t work under systemd. Please do so, otherwise you are not contributing much.
- the_biot 4y ago
  This, and it seems like it needs repeating every time somebody brings up systemd. The SysV init scripts weren't good, they were crufty and slow, and messy when you wanted to customize something, and -- this doesn't get said enough -- used no Linux-specific features at all. Systemd was an upgrade that was sorely needed, and brought features to the init system that just didn't exist before.
- shrubble 4y ago
  How many different servers of non-systemd and systemd types, have you set up and managed? Where you had ultimate responsibility for the correct operation of the box and any VMs or services that it ran? The reason I ask, is that despite running many more non-systemd than systemd boxes over the past 22 years, I have had far more time taken up by systemd issues than issues with other init script systems. And that includes Solaris both sysV and SMF based.
eternityforest 4y ago
I don't see any real evidence people hate their work. Some people do, but it's not like, an overflowing toilet or wet socks that almost everyone hates. I personally wouldn't touch a non-systemd system if I didn't have to. The thing they did to piss people off was breaking with UNIX tradition and not prioritizing simplicity. This makes them hated by enthusiasts, tinkerers, people who don't trust tech, etc, and loved or just passively ignored by corporate sysadmins, non-hobbyist everyday desktop users, general devs just trying to make modern software, etc. It's kind of an unsolvable conflict. People who want simplicity are looking for something very different from people who want everything to just work and never require looking under the hood.
- corrral 4y ago
  I'm actually strongly in favor of someone coming in and replacing a bunch of the bike-shedding horseshit in Linux with some "no, it's this way, period, live with it" if only to make distributing software for Linux less crazy-making. I just think Poettering's (and, more generally, Red Hat's) taste is really bad, so I wish it weren't him(/them). Possibly when they finally achieve Systemd/Linux and the entire stack atop the kernel is stuff Red Hat likes & directs it'll all be worth it, I dunno. FWIW I also haven't much cared for a lot of Ubuntu's attempts to steer the direction of Linux—they've just lost so badly at every attempt, that it hardly matters.
  - eternityforest 4y ago
    Ubuntu is wonderful as long as they don't do a anything new, and you're using a derivative not raw Ubuntu. I'm actually not even fully sure on the details what they even do that isn't in Debian aside from maybe some driver stuff and assorted annoyances like Snaps. I just know to stick with Ubuntu derivatives because almost all large popular apps seem to be well tested and designed to work on it, until the community gets tired of it and probably Fedora or something takes over. It's the perfect example of "I'd rather have a mediocre standard than something excellent but obscure". I'm not a fan of Pulse, because of its lack of low latency, although It still offers a lot over raw ALSA, and PipeWire solves basically all of it's issues. But systemd is a lot more comprehensive, it doesn't seem to leave any use cases out, aside from ultralight embedded and old school "Control everything yourself with imperative scripting" style setups.

sophacles 4y ago

From my point of view as an old guy who remembers the hell of init scripts, what they did was make an alternative to remembering arcane details of how each os and distro chose to set up their scripts. This: * made debugging a random system a lot more straight forward * made putting up software for packaging a lot easier * made customizing the start-up of a daemon a lot easier (this ties in with the first point) * made it so I didn't have to go to the guru who's only job seemed to be managing our obtuse set of init scripts that were extra baroque because order of startup really mattered. That guy I had to go to - he was an asshole an lorded his knowledge of arcana over anyone who brought him a question. I'm 90% sure he made it intentionally complex since he didn't have much skill beyond memorizing those silly facts (this is the same guy who got an entire project reassigned to me because he couldn't understand the concept of functions when I removed some extreme repetition from a python script he wrote). Most of the systemd haters remind me of this guy. I guess what you're implying is that he helped automate away dead weight and that made the leeches mad?

zozbot234 4y ago
These "simple" use cases break when you need to do anything even slightly more complex than whatever the systemD designers envisioned for the user. And if you try to submit an issue upstream, the typical response is "you're holding it wrong" or equivalent. This lack of a consistent design might be excusable when first trying to support a bunch of entirely novel use cases, but let's not pretend that it doesn't come with serious drawbacks.
- sophacles 4y ago
  I have yet to encounter something that systemd doesn't do OK or well. What is your example of something that systemd can't handle that was better handled by init scripts?
- ElectricalUnion 4y ago
  These "simple" use cases break when you need to do anything even slightly more complex than whatever the sysvinit scripts you copied envisioned. FTFY systemd might be sad but makes the simple case simple. sysvinit makes everything complex and error prone.
  - sam_lowry_ 4y ago
    sysvinit could be debugged, at least. I tried to debug a couple of systemd edge cases with Pottering, communicating over Github Issues, but he lost interest very quickly. To his, credit he is reactive until he decides the issue is not worth his time. To his discredit, he made himself into a giant bottleneck. Random systemd users can not easily understand it.
- kaba0 4y ago
  I’m sure then you can list a use-case which doesn’t work under systemd. Please do so, otherwise you are not contributing much.
the_biot 4y ago
This, and it seems like it needs repeating every time somebody brings up systemd. The SysV init scripts weren't good, they were crufty and slow, and messy when you wanted to customize something, and -- this doesn't get said enough -- used no Linux-specific features at all. Systemd was an upgrade that was sorely needed, and brought features to the init system that just didn't exist before.
shrubble 4y ago
How many different servers of non-systemd and systemd types, have you set up and managed? Where you had ultimate responsibility for the correct operation of the box and any VMs or services that it ran? The reason I ask, is that despite running many more non-systemd than systemd boxes over the past 22 years, I have had far more time taken up by systemd issues than issues with other init script systems. And that includes Solaris both sysV and SMF based.

eternityforest 4y ago

I don't see any real evidence people hate their work. Some people do, but it's not like, an overflowing toilet or wet socks that almost everyone hates. I personally wouldn't touch a non-systemd system if I didn't have to. The thing they did to piss people off was breaking with UNIX tradition and not prioritizing simplicity. This makes them hated by enthusiasts, tinkerers, people who don't trust tech, etc, and loved or just passively ignored by corporate sysadmins, non-hobbyist everyday desktop users, general devs just trying to make modern software, etc. It's kind of an unsolvable conflict. People who want simplicity are looking for something very different from people who want everything to just work and never require looking under the hood.

corrral 4y ago
I'm actually strongly in favor of someone coming in and replacing a bunch of the bike-shedding horseshit in Linux with some "no, it's this way, period, live with it" if only to make distributing software for Linux less crazy-making. I just think Poettering's (and, more generally, Red Hat's) taste is really bad, so I wish it weren't him(/them). Possibly when they finally achieve Systemd/Linux and the entire stack atop the kernel is stuff Red Hat likes & directs it'll all be worth it, I dunno. FWIW I also haven't much cared for a lot of Ubuntu's attempts to steer the direction of Linux—they've just lost so badly at every attempt, that it hardly matters.
- eternityforest 4y ago
  Ubuntu is wonderful as long as they don't do a anything new, and you're using a derivative not raw Ubuntu. I'm actually not even fully sure on the details what they even do that isn't in Debian aside from maybe some driver stuff and assorted annoyances like Snaps. I just know to stick with Ubuntu derivatives because almost all large popular apps seem to be well tested and designed to work on it, until the community gets tired of it and probably Fedora or something takes over. It's the perfect example of "I'd rather have a mediocre standard than something excellent but obscure". I'm not a fan of Pulse, because of its lack of low latency, although It still offers a lot over raw ALSA, and PipeWire solves basically all of it's issues. But systemd is a lot more comprehensive, it doesn't seem to leave any use cases out, aside from ultralight embedded and old school "Control everything yourself with imperative scripting" style setups.