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. Enjoy it. It's a latent possibility, it's 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.

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.

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.

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.

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.

> hydraulic press

What is there to know? It goes up and down, and don't stick your arm inside...

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.

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.

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.

> You most likely refer to sysinit or something like that, right? Because to what else do you compare it to? Shell scripts?

dinit is a good service manager that doesn't feel obligated to reinvent the kitchen sink

No, it is part of the "I just want stuff to work" strategy

That's pretty much all software.

Think about user services in a multi-user setup

Do you want user-level services, or a multi-tenant system-level service? - Who can tweak the service configuration? - How do you ensure there's no data leaks between users? - What about misbehaviour? Quotas, crashes

I think lingering is great here