deleted by creator
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.
For me, i don’t care what my system uses as long as it works & doesn’t cause any problems or headache.
Missing shepherd from Guix.
Jesus, this shit again?
