4 ms·

In my experience, systemd is much better documented, way more consistent, and way more reliable than what came before.

lucideer 3mo ago
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?
        3mo ago
- 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
po1nt 3mo ago
Maybe, but the scale of systemd features is humongous. It better be well documented. You don't need a user manual for hammer, you do need one for hydraulic press.
- nubinetwork 3mo ago
  > hydraulic press What is there to know? It goes up and down, and don't stick your arm inside...
  - po1nt 3mo ago
    Until it breaks, reports error, leaks, makes weird sound, needs a maintenance or even if you want to move it. You need to know how heavy it is, where are mounting points, where is the center of gravity, what needs to be affixed etc. What is the power it draws for the pump, what is the peak power and how long is the peak, what is the power factor? Does it have a safety certification, what kind of training operator needs, are safety elements up to date to modern standard? What kind of fire extinguisher do you need? What is the toxicity of all the materials under normal and extreme conditions? What kind of peak force is applied to floor and how is it distributed?
  - M95D 3mo ago
    You'd be surprised to know. https://www.manualslib.com/manual/3389176/Cincinnati-90-Form-Master-Ii.html?page=32#manual https://www.manualslib.com/manual/3389176/Cincinnati-90-Form...
- 7bit 3mo ago
  The scale is humongous? Syszemd is not one big thing. It's a collection of small things, each meticoulsouy documented and you can pick and choose. If you still think there is only one Systemd, maybe learn about the tool instead of just talking others after their mouth.
  - iririririr 3mo ago
    that's wrong in the sense it won't be useful for anything unless you have a dozen of those small things setup in the very specific way the author envisioned you set them up. you seem to be repeating all the marketing, while mentioning in other comments you never understood any init system. i don't think you're the authority to be adding so many comments here.
shevy-java 3mo ago
So, I disagree about your statement here, but let's for a moment assume it were correct - so let's not evaluate THAT particular statement, thus. You most likely refer to sysinit or something like that, right? Because to what else do you compare it to? Shell scripts? Shell scripts in general are crap. I don't understand why linux systems use them. When I transitioned to linux a long time ago, I wrote - and still write - pretty much all logic in ruby and .yml files. Literally my whole system is described via .yml files, ruby then just auto-expands all of this into what is meaningful. I also compile from source and manage the system via ruby as-is, so I don't even need systemd, nor shell scripts. But this is just one comment here and if you refer to shell scripts then I agree with you - shell scripts have always been horrible. I fail to see why we should like systemd merely because shell scripts are so awful. That makes no sense. I neither use systemd nor shell scripts (ok ok I bail ... I am currently using manjaro which uses systemd; I disabled most of the services, but the primary reason I was assimilated into systemd is mostly because the non-systemd linux distributions, kind of gave up for the most part or come with their own set of problems - slackware, void and so forth. And yeah, I was using and testing them for ages too, slackware I used for many, many years. It is still a great distribution but it is not really active anymore. No new .iso releases in years, sorry, that is dead. Even if Patrick still updates packages.) The other part is ... IF you referred to an alternative init system, then THAT comparison is flawed too, because sysvinit is mostly just an init system. Systemd is some giant thing that does 100000 things. So the comparison is, and ALWAYS has been, unfair. Not the same things are compared here.
- eptcyka 3mo ago
  Systemd is not 1 giant thing that does 100000 things - it is a collection or 10000 services doing 10000 things, integrating amongst themselves where practical. You need not use networkd, logind, resolved or any other one piece of the system you dislike.
  - yjftsjthsd-h 3mo ago
    My least favorite part is journald. When you find a way to rip that out, let me know. Also logind is so hard to avoid that even other systems have ported it: https://wiki.alpinelinux.org/wiki/Elogind https://wiki.alpinelinux.org/wiki/Elogind
dosisking 3mo ago
Well, in my experience, systemd has much worse documentation, is very inconsistent (or you could say it is constistantly brain-dead), and extremely unreliable and unpredictable, since it often hangs when shutting down and rebooting.
- bombcar 3mo ago
  systemd is like the registry. If you drink the koolaid and fully admit and adopt the decisions made, you’ll do ok, perhaps even good. If you have 20+ years of experience, you’ll will NEVER get it to work the way you expect, might as well install Gentoo.
- preg_match 3mo ago
  In my experience hangs usually happen from no time limits on units or excessively long time limits. I fried a NIC a while back and network-manager-wait-online has no time limit. Usually this isn't a problem, but the NIC was fried in a very unique way where it would continuously try to connect and then downgrade connections. The bright side is this is all logged, trivially grep-able, and easy to fix.
M95D 3mo ago
I'm still using sysvinit without anything on top (the default would have been sysvinit + openrc, but I dropped openrc, too complicated for my needs). I find it a lot easier than learning systemd, or learning anything else. To find out what's going on, I just need to open one file: /etc/inittab, and it's all in there. Nothing hidden somewhere else. Nothing undocumented. Simple commands, one after another. There are no dependencies, no conditions, not unless I put them there myself.
egorfine 3mo ago
This has never been my experience for the whole duration of the systemd existence.

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?
        3mo ago
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

po1nt 3mo ago

Maybe, but the scale of systemd features is humongous. It better be well documented. You don't need a user manual for hammer, you do need one for hydraulic press.

nubinetwork 3mo ago
> hydraulic press What is there to know? It goes up and down, and don't stick your arm inside...
- po1nt 3mo ago
  Until it breaks, reports error, leaks, makes weird sound, needs a maintenance or even if you want to move it. You need to know how heavy it is, where are mounting points, where is the center of gravity, what needs to be affixed etc. What is the power it draws for the pump, what is the peak power and how long is the peak, what is the power factor? Does it have a safety certification, what kind of training operator needs, are safety elements up to date to modern standard? What kind of fire extinguisher do you need? What is the toxicity of all the materials under normal and extreme conditions? What kind of peak force is applied to floor and how is it distributed?
- M95D 3mo ago
  You'd be surprised to know. https://www.manualslib.com/manual/3389176/Cincinnati-90-Form-Master-Ii.html?page=32#manual https://www.manualslib.com/manual/3389176/Cincinnati-90-Form...
7bit 3mo ago
The scale is humongous? Syszemd is not one big thing. It's a collection of small things, each meticoulsouy documented and you can pick and choose. If you still think there is only one Systemd, maybe learn about the tool instead of just talking others after their mouth.
- iririririr 3mo ago
  that's wrong in the sense it won't be useful for anything unless you have a dozen of those small things setup in the very specific way the author envisioned you set them up. you seem to be repeating all the marketing, while mentioning in other comments you never understood any init system. i don't think you're the authority to be adding so many comments here.

shevy-java 3mo ago

So, I disagree about your statement here, but let's for a moment assume it were correct - so let's not evaluate THAT particular statement, thus. You most likely refer to sysinit or something like that, right? Because to what else do you compare it to? Shell scripts? Shell scripts in general are crap. I don't understand why linux systems use them. When I transitioned to linux a long time ago, I wrote - and still write - pretty much all logic in ruby and .yml files. Literally my whole system is described via .yml files, ruby then just auto-expands all of this into what is meaningful. I also compile from source and manage the system via ruby as-is, so I don't even need systemd, nor shell scripts. But this is just one comment here and if you refer to shell scripts then I agree with you - shell scripts have always been horrible. I fail to see why we should like systemd merely because shell scripts are so awful. That makes no sense. I neither use systemd nor shell scripts (ok ok I bail ... I am currently using manjaro which uses systemd; I disabled most of the services, but the primary reason I was assimilated into systemd is mostly because the non-systemd linux distributions, kind of gave up for the most part or come with their own set of problems - slackware, void and so forth. And yeah, I was using and testing them for ages too, slackware I used for many, many years. It is still a great distribution but it is not really active anymore. No new .iso releases in years, sorry, that is dead. Even if Patrick still updates packages.) The other part is ... IF you referred to an alternative init system, then THAT comparison is flawed too, because sysvinit is mostly just an init system. Systemd is some giant thing that does 100000 things. So the comparison is, and ALWAYS has been, unfair. Not the same things are compared here.

eptcyka 3mo ago
Systemd is not 1 giant thing that does 100000 things - it is a collection or 10000 services doing 10000 things, integrating amongst themselves where practical. You need not use networkd, logind, resolved or any other one piece of the system you dislike.
- yjftsjthsd-h 3mo ago
  My least favorite part is journald. When you find a way to rip that out, let me know. Also logind is so hard to avoid that even other systems have ported it: https://wiki.alpinelinux.org/wiki/Elogind https://wiki.alpinelinux.org/wiki/Elogind

dosisking 3mo ago

Well, in my experience, systemd has much worse documentation, is very inconsistent (or you could say it is constistantly brain-dead), and extremely unreliable and unpredictable, since it often hangs when shutting down and rebooting.

bombcar 3mo ago
systemd is like the registry. If you drink the koolaid and fully admit and adopt the decisions made, you’ll do ok, perhaps even good. If you have 20+ years of experience, you’ll will NEVER get it to work the way you expect, might as well install Gentoo.
preg_match 3mo ago
In my experience hangs usually happen from no time limits on units or excessively long time limits. I fried a NIC a while back and network-manager-wait-online has no time limit. Usually this isn't a problem, but the NIC was fried in a very unique way where it would continuously try to connect and then downgrade connections. The bright side is this is all logged, trivially grep-able, and easy to fix.

M95D 3mo ago

I'm still using sysvinit without anything on top (the default would have been sysvinit + openrc, but I dropped openrc, too complicated for my needs). I find it a lot easier than learning systemd, or learning anything else. To find out what's going on, I just need to open one file: /etc/inittab, and it's all in there. Nothing hidden somewhere else. Nothing undocumented. Simple commands, one after another. There are no dependencies, no conditions, not unless I put them there myself.

egorfine 3mo ago

This has never been my experience for the whole duration of the systemd existence.