i was fine with systemd for a few years, even truly enjoying getting rid of hacky docker workflows in place of machined.
then i start to find out it is full of rando backdoors intended for VMs, which will run just the same on your bare metal. For example, just to list the very last one, you can inject smbios data that will be parsed to create files in your system. very convenient to drop passwords and keyfiles around a vm... unless it is the firmware on your actual bios doing the same. And we know how common persistence via bios is. sigh.
but as you mention correctly, it have crushed and dominated linux. so i guess i just waste a week or some working around those things later, as usual.
The unit and service file formats are honestly fine, it should be possible to have a second implementation. We have several varieties of SysV init already.
The unit file format is what I don't like about it. A giant spaghetti code mess where dependencies can be literally anywhere and the final imperative result is completely opaque. An init system, ultimately, does a bunch of one time actions to bring the system up; it really does just work better as an imperative script.
An init system is for all practical purposes a build system - a very complex problem where literally every sane solution is declarative. Especially when you take into account error handling (that HDD is not yet available, will you imperatively wait for it to come up and pause everything else? Do parallel work in the meantime in fking bash? Or what exactly?)
Startup is ultimately a complex problem. There is no magic, just race conditions which maybe became more apparent. LVM may or may not be used, and takes time to start up. Do you wait for it? Ditto wireless networks. And how do you handle devices being hotplugged? Setups vary widely, and can be dynamic.
How are Systemd's unit files any worse than unconstrained init scripts written in a Turing complete language with even basic stuff - like PID files - managed manually?
Because they are opaquely translated into an imperative sequence but you never get to see it.
Also who are these people who have complicated sysv scripts? I've heard this for years and never really understood it. One script per service with a stop and start command (and maybe a status if you want to get fancy) and runlevel definitions that start and stop them. It's not rocket surgery, and it's a hell or a lot easier to debug than a declarative system definition.
The reality is that it wasn't corporate scripts hidden away from the public eye. There were some nightmare van Smoorenberg rc scripts in the likes of Debian.
FreeBSD has Mewburn rc not van Smoorenberg rc and was thus inherently better in this regard until the middle of 2014 (https://unix.stackexchange.com/a/480897/5132). But even FreeBSD has some large rc scripts, particularly in the networking and the HID parts such as Bluetooth and configuring all attached keyboards; albeit that the FreeBSD style guidelines mean that they are more legible than the nightmare Debian (et al.) ones.
It may shift to a different community balance seeing how RedHat employs a lot of the main contributors to systemd and more recently are showing signs of acting in a more closed manner.
Oh I didn't realize that. Maybe similar teeth, different dragon. I'm cautious about Microsoft, but recently I'd have to say they've been a reasonable Linux community member - though if there are fewer larger balancing orgs - who knows.
> about Microsoft, but recently I'd have to say they've been a reasonable Linux community member
All it takes is to look around at what Microsoft is doing to gestures vaguely to see the writing on the wall for how Microsoft sees Linux.
Advertisements on the home screen? Advertisements on the every screen? Login darkpatterns? Configuration resets on updates? Forceful browser choices? Forced updates? UEFI shenanigans? Boot manager shenanigans?
Yup, the windows OS (as opposed to Linux) is where they have no counterbalancing reason to not pursue darker patterns. So it's a window into unchecked tendencies.
Or you know, Microsoft is a giga-company with no singular goal (besides increasing revenue). Improving and “destroying” linux may be simultaneously goals to separate areas of the same company, and due to bureaucracy I really can’t take this conteos seriously.
>but recently I'd have to say they've been a reasonable Linux community member
LOL
Its amazing how easy it is. I guess if you spend your entire history being a shitty company and then spend a couple of years pretending to be marginally less shitty then you can dupe a bunch of people.
then i start to find out it is full of rando backdoors intended for VMs, which will run just the same on your bare metal. For example, just to list the very last one, you can inject smbios data that will be parsed to create files in your system. very convenient to drop passwords and keyfiles around a vm... unless it is the firmware on your actual bios doing the same. And we know how common persistence via bios is. sigh.
but as you mention correctly, it have crushed and dominated linux. so i guess i just waste a week or some working around those things later, as usual.