I think what he's running into is "the unix philosophy".
It is basically about small tools, limited in scope, that solve a problem surgically and comprehensively. They work together by mixing and matching to solve the problem.
systemd is sort of like if microsoft word took on system init. In the beginning it was small, but now it is web based and does videoconferencing.
I don't know, it is sort of like busybox, replacing other system components in a limited Minimum Viable Product way, but more like limited function, not limited resources.
I think the problem is that small tools are missing that "comprehensively" part.. trying something as simple as getting full system startup log (something very useful on headless system!) - it was basically impossible until systemd came. Only gentoo tried to do this for a few years, but then that functionality broke.
Same goes for service startup - why does start-stop-daemon discards stdout/stderr instead of logging it? This would be trivial to fix, but somehow this was not available until upstart (and then systemd) did it.
Some of the oldest init systems made decisions that were sensible at the time but not so much now, e.g. when storage is hundreds of thousands of dollars per GB you don't want to log everything, when it's tens of cents per GB you do. But you can obviously make a non-monolithic init system that causes output to be stored to a log instead of being discarded.
So then systemd comes in, solves some of the old problems and independently, unnecessarily introduces new ones by being a huge monorepo that lacks clean and stable interfaces between its own components, inhibiting anyone else from providing a viable competing implementation of an individual component.
Then people complain about the latter and the defense that comes back is of the former. But that's no defense -- we could instead be making the good change and not the bad change.
> systemd is sort of like if microsoft word took on system init. In the beginning it was small, but now it is web based and does videoconferencing.
It's actually a suite of tools that do solve individual problems comprehensively. Not as small as the programs in coreutils, but still not a huge monolith.
It's a suite of tools created with hate to the unix philosophy. That's something that all of them have in common. There was no reason to create systemd timers as cron worked just fine for decades.
It's a suit of a tools each doing one thing and communicating together via a message bus. How exactly is that hating the "unix philosophy" whatever that means? From where I stand, it's extremely close to the way Unix has ever done things. The design is even directly lifted from the boot system of a certified Unix.
Okay. How? They're all individual binaries that just happen to use the systemd name. You realize systemd isn't just one big program, right? It's like 30 programs, all independent of each other, with integrations to other programs.
This is purely speculative. From my talks with sys admins, all the ones I've met greatly appreciate systemd. Also timers and cron have different requirements, notably timers can do much more. Also timers is purely optional and most distros DO use cron.
There's a major disconnect, I've seen, from what systemd haters proclaim and what is reality. Nobody is forcing anything, you don't have to use 99% of systemd, it's not a monolith, and many people do want the features. To be clear, this isn't my opinion - this is the truth. You can find all this out by perusing the repos and mailing list.
Really? I have yet to see one. Kids, maybe. Experiences sysadmins may appreciate systemd as PID1, but almost everything else is pure cancer.
> There's a major disconnect, I've seen, from what systemd haters proclaim and what is reality.
I can certainly agree with that.
> Nobody is forcing anything
... until distro maintainers decide to move crucial tasks to systemd-timers from cron, change resolved to systemd-resolved, switch from ntpd to whatever its called, remove sudo in favor of another systemd thing, etc. But sure, you are free to not use any. Except the only *nix thing left is the Linux kernel. Soon to be systemd-kernel.
I've been building and automating data centers for years now. Systems has greatly simplified my life. I use all of the systems tooling; timesyncd, networkd (which is actually does _more_ unlike what is stated above, go read the man page), timers (better than cron, again go read the man page) resolved.
Not only does it solve a lot of problems, the configuration file format consistent across the tools, and the configuration is consistent _across distros_. I can write large swaths of automation that just works on most modern Linux distros.
Anyway, I'm not one to argue on the Internet. But I'm absolutely tired of hearing that's it's a dumpster fire. Sure, there are legitimate complaints and use cases where it might not be a good fit, but that holds true for all software. But, there is a reason so many distros switched to it. It's objectively better than the way things were. Those of us that deal with this stuff day in and day out are not going back to the way it was.
Cron is probably the worst example you could have chosen. For my uses cases that, you know, involve manually running jobs to see if they actually work, cron has been broken for decades and is still to this day basically unusable. Systemd timers work far better than cron.
It's due to systemd in that systemd makes it too fiddly to figure out or change which services are enabled on boot. (I used to know a way to disable certain services on boot under systemd, but it doesn't work any more, and I've reached a state of learned helplessness at this point)
My system boots systemd in 2 seconds from the firmware handover to my code fully running. And this includes device initialization and a DHCP lease renewal.
On VMs you can get to within 200ms for a full system.
You can use `systemd-analyze critical-chain` to visualize the boot process. The slowdown is likely caused by something unexpected.
Try measuring a reboot instead. On modern Windows versions with “fast startup” enabled, the “Shutdown” button is a lie: it logs you out and hibernates the system instead of actually shutting it down. (This is important if you dual boot, because it means you can’t safely access the Windows partition in the interim.)
Are you seriously complaining right now that systemd doesn't have a specific feature no other init for linux has either, while at the same time complaining it is too complicated and does too much stuff?
It is basically about small tools, limited in scope, that solve a problem surgically and comprehensively. They work together by mixing and matching to solve the problem.
systemd is sort of like if microsoft word took on system init. In the beginning it was small, but now it is web based and does videoconferencing.
I don't know, it is sort of like busybox, replacing other system components in a limited Minimum Viable Product way, but more like limited function, not limited resources.