Comment by jauntywundrkind
2 days 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.
> 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.
IMHO, any competent sysadmin, when is installing the system, would edit all those templates into the exact shape the system and the user needs. Those file are just that - templates. The fact that overworked company sysadmins started using templates as final configuration and needed something automated instead, doesn't mean that this systemd that is fit for them is also fit for everybody else.
> IMHO, any competent sysadmin, when is installing the system, would edit all those templates into the exact shape the system and the user needs
That, IMHO, is the other 90% of the problem (to riff on the ninety-ninety rule).
Every competent sysadmin has their own particular style & preferences & opinions about what the exact shape should be. And will go rewrite the world, according to some particular set of tastes, that they usually won't write down or document or socialize.
So not only do you have to figure out all the special sauce in how the service you just walked in to is managed, you have to wade through a complete re-architecting that some sysop made on their own judgement 5 years ago that people have patched and hacked since.
You can keep adapting to these scenarios. But to me, the normativity, the incredibly great toolkit of options it comes with: yes it's sizable, but it's one thing that I have to learn, that is usually a direct representation of something the kernel gives me, that will then be familiar and portable and useful wherever I go. This feels so much more civilized than what came before.
I'm no sysadmin, except for my own systems, but I think that the vast majority of systems are fixed-config for their entire lifetime. Deployed once on VM and stays the same until it's no longer needed. So every sysadmin can just set them up in whatever way he wants with no obligation to make it understandable to the next guy. The VM will be deleted anyway when no longer serves it's purpose.
That being said, I do understand the need for some standardization. But you missed this part:
> doesn't mean that this systemd that is fit for them is also fit for everybody else.
They practically forced everybody to use it, and not just the service manager, everything else too: init, logger, network, login, dbus, etc.
1 reply →
Days since my last exposure to “I'm sorry, you're absolutely right, that's wrong”: 1
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
the systemd init system is complicated but fine. the problem with systemd is how much it wants your computer to itself. e.g. it can only run as PID 1, you aren't allowed to use control groups if you use systemd, it overwrites resolv.conf with its own address, it renames all your network adapters to lennart's preference (he calls them stable names but anyone who actually uses a computer will tell you they change more often now), and it binds itself to syslog
The problem with systemd is not the init system. Most people who do not like systemd are happy with the init system, but do not want the rest of it.