5 ms·

I guess it depends on your source of info but I've found what came before was pretty comprehensively & accessibly documented, at least as well as systemd, which

I guess it depends on your source of info but I've found what came before was pretty comprehensively & accessibly documented, at least as well as systemd, which - while well documented - suffers from sprawl & overwhelm of the docs. There's just SO MUCH to grok in comparison.

m0llusk 3mo ago
Absolutely not the case. Even relatively simple real world uses involved collections of shell scripts to carefully mount or initialize services in just the right order and would often fail with weird and infrequent timing glitches. With systemd that all becomes explicit, so of course it is awkwardly verbose. That is the whole point and a huge upgrade.
- shevy-java 3mo ago
  I never used shell scripts for that. Ruby worked much better and easier. No glitches either. I also fail to see how verbosity is a "huge upgrade".
  - jamespo 3mo ago
    So your systems have a dependency on ruby to startup and anyone who maintains it has to know ruby?
  - preg_match 3mo ago
    The problem is Ruby is not de-facto installed on most distros. Shell is the "universal" thing, but shell is actually not portable, even across distros. Perl is the only thing I'd qualify as both "sufficiently portal" and "universal". But then you have to write Perl, which nobody wants to do seemingly.
BirAdam 3mo ago
I never found systemd difficult, but I do find prior solutions to be simpler. An init script is easy, and the order is also easy. If people are accustomed to UNIX systems, the sysvinit is better. For people who never experienced those systems, systemd is their friend. No need to use UNIX tools when Systemd ships with batteries included.
- dietr1ch 3mo ago
  Yeah, init scripts are simple, but things get tricky outside of the happy path. Think of service upgrades/restarts. Once you care about dependencies, then you are back to a graph like systemd's.
  - iririririr 3mo ago
    talking "outside happy path" in defense of systemd is wild. because that's it's Achilles heel. systemd is awfully documented (volume is not quality), things are still changing and haven't even caught up in functionality with any init hack. the only saving grace of systemd is that it almost makes it easier to use namespace and other sandbox (but only because those are newer and init systems also didn't have their solutions up yet) systemd only purpose is to mimic windows administration in linux. sorry of anyone who fails to see this
    - jamespo 3mo ago
      How are hacky init scripts written in shellscript well documented? Can you point me to this documentation? When are the init systems going to implement the basic security measures systemd has?
      - graemep 3mo ago
        Which security measures are init systems missing? Are you saying all other init systems are badly documented?
        jamespo 3mo ago
        take your pick: https://github.com/alegrey91/systemd-service-hardening https://github.com/alegrey91/systemd-service-hardening - and this was 6 years ago and barely scratches the surface
  - BirAdam 3mo ago
    If ever handled thousands of servers running Linux with sysvinit, you get quite accustomed to it… and the tricky bits aren’t that tricky.
7bit 3mo ago
No way. I was easily able to create Systemd units from 0-knowledge, where the init system remains a big black box riddled with question marks for a very long time. Very little was documented.
jauntywundrkind 3mo ago
We can argue about which has better docs, but, to me, systems offers a uniformity of practices and a consistency of service offerings that was never the case before. Ever company used to have to make its own decisions about what logging solution to use. Each one had its own configuration paradigms! Every single daemon had some kind of bespoke /etc/init.d/ script that had its own rules and practices, having either forked off some other skeleton or having been made on it's own at some point. And then companies wanted to do the right thing and apply some capabilities restrictions to processes. They wanted a little more than out of box security. That results in every company forming and modifying init scripts, changing the configuration paradigms, encoding config directly in or inventing their own new parameterization. The fact is I don't have to look at docs any more, because everything has a (pleasant) uniformity. The fact is we are worlds better at securing and locking down our processes, because systemd has incredible built in options for capability, sandboxing, and other fantastic security processes. > There's just SO MUCH to grok in comparison. There always was before too. Most people skated along the surface, but when some daemon tried to actually have better practices, do some security tightening, operators were in for that exciting rabbit hole of trying to catch up and learn. Or just hand wave it away. I think this statement really iconifies the systemd resistance really. Yes there is so much (imo: enjoy it, isn't that so great?) It's many many many latent possibilities (for you to over time learn): it's so often what the kernel is offering you, it's well exposed, and you have a pleasant uniform system for harnessing that, that you only have to learn once and which can pay dividends again and again and again once you learn it. Learn once, use many. Or just ask your LLM. It knows. It will just tell you. It won't have to read docs or source. It knows systemd very well. Because it is something shared, something known. Imo it ought be something treasured. I'm fine if some day we get rid of systemd. Nothing sacred here. But to attack it, it must be attacked from above. It must be replaced by something with more principled and more capabilities. Same as Kube. Neither is going away, neither will ever be displaced by smaller offerings. The only way out is through, the only way out is up. Godspeed, good luck, have fun.
- vrighter 3mo ago
  the oss community has a phobia of having anything in common against all its reimplementations of the same thing. So systemd offers some consistency between distros: bad. X11 was pretty much standardized, that won't do.... let's invent wayland but make sure that there are multiple incompatible implementations of it! and so on. I love linux, but this sort of mentality is ridiculous

m0llusk 3mo ago

Absolutely not the case. Even relatively simple real world uses involved collections of shell scripts to carefully mount or initialize services in just the right order and would often fail with weird and infrequent timing glitches. With systemd that all becomes explicit, so of course it is awkwardly verbose. That is the whole point and a huge upgrade.

shevy-java 3mo ago
I never used shell scripts for that. Ruby worked much better and easier. No glitches either. I also fail to see how verbosity is a "huge upgrade".
- jamespo 3mo ago
  So your systems have a dependency on ruby to startup and anyone who maintains it has to know ruby?
- preg_match 3mo ago
  The problem is Ruby is not de-facto installed on most distros. Shell is the "universal" thing, but shell is actually not portable, even across distros. Perl is the only thing I'd qualify as both "sufficiently portal" and "universal". But then you have to write Perl, which nobody wants to do seemingly.

BirAdam 3mo ago

I never found systemd difficult, but I do find prior solutions to be simpler. An init script is easy, and the order is also easy. If people are accustomed to UNIX systems, the sysvinit is better. For people who never experienced those systems, systemd is their friend. No need to use UNIX tools when Systemd ships with batteries included.

dietr1ch 3mo ago
Yeah, init scripts are simple, but things get tricky outside of the happy path. Think of service upgrades/restarts. Once you care about dependencies, then you are back to a graph like systemd's.
- iririririr 3mo ago
  talking "outside happy path" in defense of systemd is wild. because that's it's Achilles heel. systemd is awfully documented (volume is not quality), things are still changing and haven't even caught up in functionality with any init hack. the only saving grace of systemd is that it almost makes it easier to use namespace and other sandbox (but only because those are newer and init systems also didn't have their solutions up yet) systemd only purpose is to mimic windows administration in linux. sorry of anyone who fails to see this
  - jamespo 3mo ago
    How are hacky init scripts written in shellscript well documented? Can you point me to this documentation? When are the init systems going to implement the basic security measures systemd has?
    - graemep 3mo ago
      Which security measures are init systems missing? Are you saying all other init systems are badly documented?
      - jamespo 3mo ago
        take your pick: https://github.com/alegrey91/systemd-service-hardening https://github.com/alegrey91/systemd-service-hardening - and this was 6 years ago and barely scratches the surface
- BirAdam 3mo ago
  If ever handled thousands of servers running Linux with sysvinit, you get quite accustomed to it… and the tricky bits aren’t that tricky.

7bit 3mo ago

No way. I was easily able to create Systemd units from 0-knowledge, where the init system remains a big black box riddled with question marks for a very long time. Very little was documented.

jauntywundrkind 3mo ago

We can argue about which has better docs, but, to me, systems offers a uniformity of practices and a consistency of service offerings that was never the case before. Ever company used to have to make its own decisions about what logging solution to use. Each one had its own configuration paradigms! Every single daemon had some kind of bespoke /etc/init.d/ script that had its own rules and practices, having either forked off some other skeleton or having been made on it's own at some point. And then companies wanted to do the right thing and apply some capabilities restrictions to processes. They wanted a little more than out of box security. That results in every company forming and modifying init scripts, changing the configuration paradigms, encoding config directly in or inventing their own new parameterization. The fact is I don't have to look at docs any more, because everything has a (pleasant) uniformity. The fact is we are worlds better at securing and locking down our processes, because systemd has incredible built in options for capability, sandboxing, and other fantastic security processes. > There's just SO MUCH to grok in comparison. There always was before too. Most people skated along the surface, but when some daemon tried to actually have better practices, do some security tightening, operators were in for that exciting rabbit hole of trying to catch up and learn. Or just hand wave it away. I think this statement really iconifies the systemd resistance really. Yes there is so much (imo: enjoy it, isn't that so great?) It's many many many latent possibilities (for you to over time learn): it's so often what the kernel is offering you, it's well exposed, and you have a pleasant uniform system for harnessing that, that you only have to learn once and which can pay dividends again and again and again once you learn it. Learn once, use many. Or just ask your LLM. It knows. It will just tell you. It won't have to read docs or source. It knows systemd very well. Because it is something shared, something known. Imo it ought be something treasured. I'm fine if some day we get rid of systemd. Nothing sacred here. But to attack it, it must be attacked from above. It must be replaced by something with more principled and more capabilities. Same as Kube. Neither is going away, neither will ever be displaced by smaller offerings. The only way out is through, the only way out is up. Godspeed, good luck, have fun.

vrighter 3mo ago
the oss community has a phobia of having anything in common against all its reimplementations of the same thing. So systemd offers some consistency between distros: bad. X11 was pretty much standardized, that won't do.... let's invent wayland but make sure that there are multiple incompatible implementations of it! and so on. I love linux, but this sort of mentality is ridiculous