3 ms·
> Basically, it started out as an init system... But systemd started to expand into its "middleware" position, absorbing vital system functions like udev. Not
by mapgrep 6y ago
> Basically, it started out as an init system... But systemd started to expand into its "middleware" position, absorbing vital system functions like udev.
Not true. From the start it was positioned as much more than an init system. This is clear just skimming the blog post announcing systemd http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html
Among other things, it talks about:
-deferring launch of some services until they are needed, to speed up boot
-launching additional services and shutting down others in response to hardware changes (e.g. adding a usb device).
-taking some or all socket management away from daemons so that sockets can be ready before daemons are live or daemons can be shut down when there is no activity
-“babysitting” services including through cgroup based process management
-managing (some of the) access to /home and other directories
It’s quite a broad scoped announcement. Toward the end there is a “short list of other features”, numbered, ending at 20. Under “Where is this going?” he writes, “ The feature set described above is certainly already comprehensive. However, we have a few more things on our plate.”
systemd clearly started out as a broad based solution, and reading through that post, looking at the problems it addresses, and considering that launchd and upstart tackled similarly many issues, it’s clear why it is so broad - the world has changed. In the 70s on a pdp 11 it was sufficient to launch some daemons at boot, keep an eye on getty, and call it a day. Maybe ~50 years later a new, more comprehensive system makes sense? When Linux runs laptops and phones that are endlessly reconfiguring themselves in response to network, Bluetooth, usb, when systems are sleeping and waking routinely, when vastly more services run on a single machine, when conserving battery is important, when boot time can be reduced to seconds if things are better orchestrated? “standard ways of doing things” have changed in every other sector of society, basically, why wouldn’t they finally change in OS service management?
- jsmith45 6y agoSure, but most of that introductory post was about service management, and mount management, which are two areas the init system was traditionally heavily involved in. Sure, the init system might not technically have concerned itself with either, but a lot of the ordering considerations were very heavily concerned with both of those. Now, no one will argue that systemd's service management capabilities far exceed what most historical init systems did. Heck, the traditional init system had interior service management to window's Service Control Manager implementation, since the classic init could not for example give a list of running services. And systemd is far more flexible and feature rich than Window's options now. systemd-boot and timedated on the other hand are pretty darn disconnected from anything a classic init system was concerned with. It does feel like a lot of the non service/mount management parts of systemd are basically a grab bag of random stuff.