Linux
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
They made an init system called systemd, and it worked way better than anything prior.
Then they realised that to have a functional and maintainable system, you need a bunch of other system level tooling to be in and around about the same layer as the unit system (time sync, base network, disk mounting, etc.). All of these other things got spun off as daemon projects, for example "systemd-timesyncd". And all got good and consistent command line tooling that made things relatively convenient.
The downside is now power-users saw systems taking over their computer and "violating the Unix philosophy". I would argue that at some level, it doesn't. They've made a suite of relatively independent tools all part of the same group with the purpose of managing the system. It gets things running, it gets users logged in and out, it tells you what when wrong, and it will restart things if it can. System management, do one thing and do it well.
I think the fact is that managing a modern system in a way that "just works" is complicated challenge. Many people either haven't run Ubuntu 9, and done a software update, or have repressed a lot of those memories.
Is it perfect: no. Is it the best model we have so far: I would say so.
systemd used to be just an init system.
It'd actually be pretty good, if it stuck to just being an init system!
But noooo. Now it does DNS resolution. Network management. NTP time sync. They basically bought out udev and folded it into systemd, somehow. Login session management. A fucking BOOTLOADER.
It's too much power to give to one project.
You uninstall systemd, half your system breaks and you suddenly have to relearn a bunch of crap all at once if you were using the systemd things for them before.
Oh, and did I mention that anyone using or talking about non-systemd methods of doing things tends to get painted as "oh that's OLD and OUTDATED and OBSOLETE, just use the systemd way it's Modern™ and good"? That's a thing too. See: cron and systemd timers (oh yeah, they have a cron replacement now too for some reason).
-- Frost
Systemd said on its first website that its a system management daemon. That is where the name came from. It was never supposed to be just an init system.
No need to buy out udevd, considering the guy doing that was on board with systemd from the start and made sure that systemd-init can make maximum use of udev and the other way around... you typically do want to start stuff in response to hardware appearing and disappearing. Now they can do that safely by just asking systemd-init to manage the services. They needed to run stuff thenselves before, which pretty often ended up blocking the udev daemon from recognizing new events... a quality of live improvement for everybody involved:-)
The rest has similar stories (only run network services when the network is up, start services only after the system clock has a sane value over starting the service and then adjusting the time at some later point (which some services handle really poorly), ... . There are some damn good reasons for the stuff systemd does. That bootloader is a pretty central piece in the image by the way.
Oh, and did I mention that anyone using or talking about non-systemd methods of doing things tends to get painted as "oh that's OLD and OUTDATED and OBSOLETE, just use the systemd way it's Modern™ and good"?
That is pretty much the only thing I can agree with:-) And that is because the systemd ways are ofentimes way more robust and able to deal with corner cases way better.
As I understand, one point is that systemd contradicts with its completeness the Unix philosophy of KISS, small tools that serve only one specific task.
The other point is that the main developer, Lennart Poettering, is employed by "big tech", now Microsoft (before: Red Hat) and thus has switched to the "evil site".
systemd is a monolith in practice, despite what its advocates like to claim. You can't run just a part of it under another init without doing extra patch-up work (see elogind). Whereas you can run just one GNU utility on top of, or even alongside, someone else's implementation of that or other utilities (for instance, in parallel with a rust implementation that isn't quite ready for the big time yet).
systemd also won't work on anything except Linux. Older solutions also worked on BSD. That matters to some people.
And the issue was never just Poettering's employers. He had a bad reputation in parts of the Linux community long before systemd—he was also the main force behind pulseaudio, which was shipped long before it was ready for actual use in the real world and remained in a semi-broken state for quite a long time afterwards. And he often comes across as personally obnoxious. Nothing like telling someone "I'm not interested in fixing your issues with my project" (except less politely) to get them to adopt your code.
Either you build a tool that works well with one OS or you build one that works poorly with several.
And it is not as if those other OSes are waiting for new cross-OS init tools: They either seem to be happy with what they got or want something tailored to their own features.
Considering how widely Lennarts code got adopted: You must be missing something.
Seriously? You're invoking argumentum ad popularum (which is a logical fallacy to begin with) in a discussion of linux technical details? That's so illogical I can't even.
You said Lennart is obnoxious and there is nothing like a big "that is not my problem" to not get your project adopted.
IMHO he does manage to get his projects widely adopted. His personality does not seem to have the effect you claim it has.
SystemD started as a pure init system then added a lot of features over time.
Which is either good, if you actually just want something that works, or very bad because you are violating the purity of the Unix way.
Oh, and the best part, a lot of those people loudly against SystemD then praise what Apple did and the whole discussion quickly devolves into an insane "do this! no not like that! because rEaSoNs!!" shitshow.
For me, i don't care what my system uses as long as it works & doesn't cause any problems or headache.