5 ms·

> 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

> 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.
ori_b 6y ago
> For me systemd based systems allow me to have declarative, portable unit files where init scripts don't. Portable to what?
- Valmar 6y ago
  Portable to other systemd-using Linux distros. sysv init scripts simply weren't portable between distros, leading to tons of non-standard, incompatible fragmentation. Users simply couldn't simply take their own scripts over to another distro and expect them to just work, given said differences. With systemd, unit files will simply just work between all systemd distros, given the standardized format.
  - ori_b 6y ago
    Oh. That hasn't been my experience. Where did they standardize the names and set of the services you can depend on?
    - AsyncAwait 6y ago
      > Where did they standardize the names and set of the services you can depend on? You're ignoring what the parent said and talking past. It's not the 'sets' that are standardized, it's the set of commands that are applicable to a systemd service and to any systemd Linux distro that is.
    - majewsky 6y ago
      If the names of dependencies are the only unportable thing, we have indeed come a long way.

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.

ori_b 6y ago

> For me systemd based systems allow me to have declarative, portable unit files where init scripts don't. Portable to what?

Valmar 6y ago
Portable to other systemd-using Linux distros. sysv init scripts simply weren't portable between distros, leading to tons of non-standard, incompatible fragmentation. Users simply couldn't simply take their own scripts over to another distro and expect them to just work, given said differences. With systemd, unit files will simply just work between all systemd distros, given the standardized format.
- ori_b 6y ago
  Oh. That hasn't been my experience. Where did they standardize the names and set of the services you can depend on?
  - AsyncAwait 6y ago
    > Where did they standardize the names and set of the services you can depend on? You're ignoring what the parent said and talking past. It's not the 'sets' that are standardized, it's the set of commands that are applicable to a systemd service and to any systemd Linux distro that is.
  - majewsky 6y ago
    If the names of dependencies are the only unportable thing, we have indeed come a long way.