3 ms·

This is a loaded way to frame the question, some of us were just fine being "stuck" with SysVinit. I try not to get dragged into systemd flamewars because life

by simias 6y ago

This is a loaded way to frame the question, some of us were just fine being "stuck" with SysVinit. I try not to get dragged into systemd flamewars because life is too short but it's disingenuous to claim that before systemd init systems were some kind of inescapable hellscape. I administrate multiple systemd-based linux distros, FreeBSD servers and buildroot-based embedded systems and I can tell you that systemd still gets in my way regularly while the sh-based init systems tend to Just Work and are very simple to understand and maintain. Of course I know that a big reason is that I'm very familiar with un*x system administration and the gotchas of shell scripting while systemd is probably more approachable for somebody who doesn't want to learn arcane knowledge about chmod and file locking and setuid and symbolic links but I think that explains why there's still so much pushback against systemd all these years later: people who care about init systems know enough about them that systemd feels over-engineered and unnecessarily complex while not bringing a lot to the table. Never once in the past years of running systemd have I thought "oh man, I sure am glad I'm using systemd and not an old SysV/BSD init system!". Not a single time. I did have multiple occurrences of systemd breaking stuff after an update though.

AsyncAwait 6y ago
> systemd still gets in my way regularly while the sh-based init systems tend to Just Work For me systemd based systems allow me to have declarative, portable unit files where init scripts don't. They allow me to reliably monitor and restart services, they shut things down properly instead of just force killing as many init scripts end up doing. I instantly know how to manage most major distros now that systemd's common among all of them, have no hesitation of writing a proper service file even for minor tasks and I get a ton of functionality 'for free' too. Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic. If your experience differs there's still plenty of non-systemd choices out there. They're not as prevalent as systemd ones, but that's because the people who sit down and actually write the code we all use find the services systemd provides valuable.
- simias 6y ago
  Arguing that the advantage of systemd is portability is rather bold! And even if portability was the point I'm not sure I see the big deal. Writing an RC script from scratch if the software you use doesn't provide it is generally trivial. The vast majority of the time you wouldn't have to do that anyway as it ships with your OS's packages anyway. Sure, systemd might be "tidier" with its standard APIs and whatnot but it's also a lot more complicated and opaque than a bunch of shell scripts running one after an other. And if you're serious about sysadmin you'll have to learn shell scripting one day or the other anyway. >Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic. They're non-portable, that much is true but so is systemd, that's a weak argument. If everybody had adopted FreeBSD-style init it would be equally as portable, it's a self-fulfilling prophecy. With that logic we should just all ditch un*x and start running Windows since most people already use that anyway. The rest is nonsense. It's poor quality, non-consistent and non-deterministic if you write them that way. Sure, shell scripts being turing-complete opens the door to a lot of nonsense if people go wild and gives more latitude for very sloppy code but it doesn't have to be that way. >the people who sit down and actually write the code we all use find the services systemd provides valuable Systemd has been pushed down everybody's throat for a while now, saying retroactively that people use it because they find it valuable is a bit of a stretch. I'm sure many of them use it because that's what's available. I wrote a bunch of systemd unit files myself, I assure you that it wasn't meant as an endorsement. Besides it's only one side of the equation. Maybe it's nicer for the people writing the unit files, doesn't mean that it's a good thing for people actually having to use them. I'm sure many software maintainers would prefer if everybody ran the same OS on the same hardware with the same use cases but that's not how the real world works.
  - AsyncAwait 6y ago
    > Arguing that the advantage of systemd is portability is rather bold! It's merely a statement of fact, systemd services accept the same set of commands across distros, which is rather unlike SysV. > It's poor quality, non-consistent and non-deterministic if you write them that way. That's a bullshit statement, because everything fits it. Of course everything is great if you make it great. And? The point is that systemd's declarative nature makes it hard to screw up services and even badly written ones will get enough common functionality for free that they'd be usable. > Systemd has been pushed down everybody's throat for a while now, saying retroactively that people use it because they find it valuable is a bit of a stretch. Systemd got adopted because people generally found it valuable enough to adopt over what they had before. > Maybe it's nicer for the people writing the unit files, doesn't mean that it's a good thing for people actually having to use them Matter of opinion, but I happen to think that having a uniform set of commands working at work and at home is nicer for users too, over the patchwork of scripts that SysV was across the various distros.

by simias 6y ago

AsyncAwait 6y ago

> systemd still gets in my way regularly while the sh-based init systems tend to Just Work For me systemd based systems allow me to have declarative, portable unit files where init scripts don't. They allow me to reliably monitor and restart services, they shut things down properly instead of just force killing as many init scripts end up doing. I instantly know how to manage most major distros now that systemd's common among all of them, have no hesitation of writing a proper service file even for minor tasks and I get a ton of functionality 'for free' too. Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic. If your experience differs there's still plenty of non-systemd choices out there. They're not as prevalent as systemd ones, but that's because the people who sit down and actually write the code we all use find the services systemd provides valuable.

simias 6y ago
Arguing that the advantage of systemd is portability is rather bold! And even if portability was the point I'm not sure I see the big deal. Writing an RC script from scratch if the software you use doesn't provide it is generally trivial. The vast majority of the time you wouldn't have to do that anyway as it ships with your OS's packages anyway. Sure, systemd might be "tidier" with its standard APIs and whatnot but it's also a lot more complicated and opaque than a bunch of shell scripts running one after an other. And if you're serious about sysadmin you'll have to learn shell scripting one day or the other anyway. >Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic. They're non-portable, that much is true but so is systemd, that's a weak argument. If everybody had adopted FreeBSD-style init it would be equally as portable, it's a self-fulfilling prophecy. With that logic we should just all ditch un*x and start running Windows since most people already use that anyway. The rest is nonsense. It's poor quality, non-consistent and non-deterministic if you write them that way. Sure, shell scripts being turing-complete opens the door to a lot of nonsense if people go wild and gives more latitude for very sloppy code but it doesn't have to be that way. >the people who sit down and actually write the code we all use find the services systemd provides valuable Systemd has been pushed down everybody's throat for a while now, saying retroactively that people use it because they find it valuable is a bit of a stretch. I'm sure many of them use it because that's what's available. I wrote a bunch of systemd unit files myself, I assure you that it wasn't meant as an endorsement. Besides it's only one side of the equation. Maybe it's nicer for the people writing the unit files, doesn't mean that it's a good thing for people actually having to use them. I'm sure many software maintainers would prefer if everybody ran the same OS on the same hardware with the same use cases but that's not how the real world works.
- AsyncAwait 6y ago
  > Arguing that the advantage of systemd is portability is rather bold! It's merely a statement of fact, systemd services accept the same set of commands across distros, which is rather unlike SysV. > It's poor quality, non-consistent and non-deterministic if you write them that way. That's a bullshit statement, because everything fits it. Of course everything is great if you make it great. And? The point is that systemd's declarative nature makes it hard to screw up services and even badly written ones will get enough common functionality for free that they'd be usable. > Systemd has been pushed down everybody's throat for a while now, saying retroactively that people use it because they find it valuable is a bit of a stretch. Systemd got adopted because people generally found it valuable enough to adopt over what they had before. > Maybe it's nicer for the people writing the unit files, doesn't mean that it's a good thing for people actually having to use them Matter of opinion, but I happen to think that having a uniform set of commands working at work and at home is nicer for users too, over the patchwork of scripts that SysV was across the various distros.