Comment by egorfine
3 months ago
> it gets the job done
Except exactly the opposite is true: it is sysvinit (and derivatives) who had the job done. In a very basic way, slow and perhaps not even compatible with modern requirements and expectations, but the job was done.
Systemd on the other hand does the job it thinks should be done, not you. Your opinion does not matter.
You can spend however much time you want editing /etc/ssh/sshd_config and then restarting sshd and then pulling your hair out on why tf sshd ignores certain options while still definitely parsing sshd_config. Only to later find out that systemd/ubuntu crowd decided to listen on port 22 via systemd, sort of like inetd did back in the days. It's like sshd directly listening on port was not good enough for the last 30 years, definitely had to be changed. Oh yeah, and to make your life miserable, they mask the name of the listening process with "sshd" in it, so you get confused even more.
And people can come up with countless of similar examples.
Incredible attitude and arrogance is what makes people hate systemd.
I'm sure you have other examples (and I'm not really asking for them) but your sshd example would make me dislike the choices Ubuntu made, not systemd. Like I don't blame systemd for snaps being so awful.
You are technically right.
My view is that there is an attitude/approach spillover from systemd crowd into other teams. Switching port 22 from sshd to systemd was not something that any sane person could come up with. It's a stream of incredibly hostile decisions from systemd upstream that allowed that kind of thinking.
Or maybe the people who think it's a good idea have a different perspective and value system to you?
Labelling a technical decision that was made about a system design (that a lot of people agree with) as "not sane" makes you look like a fundamentalist.
2 replies →
Sysvinit left everyone to their own ends to write their own bespoke special ways of configuring & running services. With no security options and no consistency.
Personally I found that to be offering nothing at all & having every maintainer and sysadmin diy their services to be incredibly inefficient & waste a ton of time because every service you looked at was potentially built from a different init skeleton & modified in bespoke unique ways.
Sysvinit offers way way way too little.
Let me reiterate: sysvinit had the job done in an extremely inefficient way that it's not really feasible for long ago. Upstart tried to remedy that but failed.
sysvinit was bad, no arguing about that, but it was controllable, predictable and comprehensible. While I believe that there was a time when systemd-as-PID1 looked like an excellent solution, I am confident that systemd has none of those qualities.
This is an thesis without argumentation. You've made no assertions and no statements that can be validated or refuted. You've said nothing. Few systemd haters do, in my view.
There's a lot of reasons to be pro systemd, because it does so much cohesively & well.
But if we just look at the task of running jobs, if we ignore all the other excellent management & other things in the systemd monorepo: when it comes to running programs, systemd is millions of miles head and shoulders above everything else. Like, everyone else was throwing shit up in the air, and systemd was launching fucking rockets. Nothing else has had even the faintest dose of taking itself seriously or trying to get good: it's all been sad recreations of 1970/1980's with no acceptance that the scope needed to be bigger, that we should have better more secure ways of running services.
Upstart may have been a semi ok way of wiring some kind of graph of services together, in an event based way. But honestly I prefer systemd's level-based way, rather than evented, because events don't reconcile in stable ways and level-based relationships do, are understandable not just sequences of actions but as relations of systems.
Its daunting as fuck, and I think this is why most haters hate systemd: because they don't want to get better. But a third of what's available in systemd.exec and systemd.service is absolutely crucial brilliant bundled-in ways to make your service more secure, to make it less of a risk. It exposes incredible awesome things the OS could do that most people simply never got good at doing, that the anti-pattern of sysv never could encompass. SysV said it was up to every service to define their own init scripts, and most of these were very very very dumb init scripts, bespoke and unique and brutally dumb mostly, grafting some random shitty bad shell scripting to running something in the background. Systemd exposes a cornocopia of offerings that Linux has to do this, but securely, safely, with isolation, in a standard, clear/concise (not having to delve into bespoke shell scripts) cross-cutting/repeatable way. Whats on tap here is amazing. None of the haters seem to have the faintest most remote appreciation or interest in getting good, in making any of this incredibly good potentiating shit available or on tap, much less in any repeatable consistent clear fashion. I think the haters are playing at such deeply sad forsaken stupid levels, actively fighting the ability to appreciate even remotely the awesome forces they - if they had any idea what was good for them - would be moving towards, be it via systemd or other.
Yes, 1/3rd of this is incredibly niche. 1/3rd is common/good/necessary and somewhat buried amid the rest. 1/3rd of it is just fantastically good security/safety practice that no one did, that no one knew about, that's just on tap, and easy to bring in, that's so accessible, that was so hard & weird & difficult to do before, that's such a colossal improvement in posture:
https://www.freedesktop.org/software/systemd/man/latest/syst... https://www.freedesktop.org/software/systemd/man/latest/syst...
1 reply →