Socket activation (and related features like bus activation) are one of systemd's key improvements to the boot process. Activation avoids the need for explicit dependencies, because you don't need to depend on avahi to start using the avahi socket. And because of that, systemd can launch avahi and services using avahi in parallel, by opening the socket for avahi, and letting other services write to that socket before avahi fully starts, only blocking when they go to read from it.
You could do that with inetd or similar, but inetd doesn't integrate with the init system, so an inetd service can't declare any dependencies on other services, and won't get tracked alongside other services (e.g. with systemctl status). So in practice, very few distributions actually launched services from inetd in practice (notable exception: CUPS), while many distributions use systemd's socket activation.
People care about booting quickly. While mechanisms like bootchart existed before systemd, you had to explicitly boot with them to collect results for analysis, and they'd slow down the boot process. With systemd, you can run "systemd-analyze blame" or "systemd-analyze critical-chain" on a production system and see exactly what you need to work on to make the system boot faster. (That was one of the widely lauded features of DTrace: you could safely use it to diagnose production systems.)
Then there's journald's original reason for existence: "how can we make 'systemctl status' show the last few lines of log output from a service?". How would you do that on an arbitrary system running an arbitrary syslog implementation? (For extra bonus difficulty, do so while attempting to track the syslog implementation as a service itself, and avoid deadlocks.) Sure, you could recreate that functionality on a particular system with a particular logging configuration, and there are dozens of systems doing so, not counting the myriad production systems deployed with bespoke solutions for log monitoring. (Even then, most of those systems don't correlate a service's log output with that service.) But systemd makes it easy and universal.
And that integration extends beyond systemd as well. For instance, if fixing a problem requires adding a new kernel interface, they'll submit a kernel patch, and then have systemd use that new kernel interface, rather than hacking around the problem in systemd and producing a suboptimal solution.
"booting faster" is a desktop concern from 1990. Are there really a bunch of linux users turning on and off their computers constantly and using linux on the desktop? Is this really an actual thing? Because I'd like to introduce these people to (a) real desktop environments maintained by smart people and (b) at the very least, suspend mode.
In practice, I see people boot Linux desktops under three conditions:
1. Once in a great long while, perhaps when there was a power outage or a critical system update.
2. Daily, for a few people who shut down their computers when they finish work for the day and boot them in the morning. (I never understood this.)
3. When something has gone quite badly wrong.
Outside of that, there are desktops which hibernate, laptops which hibernate, and phones which are running Firefox OS or Android and boot about once a week.
If you have a journaling filesystem and no weird hardware, desktop boot times are not a problem.
not a huge fan of systemd either, but I'm sure that if computers were able to boot in milliseconds then some of those practices would change.
Also, it's not only about desktop. Autoscaling of virtual on demand servers can greatly benefit of extremely short boot times. Surely you could use a simple and highly optimized boot system in such cases, but why not use the same if it works well.
It seems to me that it's more about systemd developers' attitude than with the actual goals. Perhaps the same goals could be achieved with a more modular approach.
The important thing is that distributions (or components that manage the deployment of services, e.g. package managers or custom service management solutions) need a simple yet powerful way to express their requirements. Not sure this requires this level of integration which appears more like a way to force people to use it (or simply because it's simpler to approach this problem by throwing away the complex legacy).
Given that Unix has been booting successfully, safely, and rapidly for several decades, I would venture to agree that 'the same goals could be achieved with a more modular approach.'
Which raises the question: why systemd? And the answer: desktop linux people, who are already mired in a world of overcomplicated and incomprehensible quarter-engineered freshman-level bullshit like gnome and dbus and pulseaudio and on and on, are sure that their problems are everyone's problems. In some cases it's because they don't know any better, I'm sure. But nevertheless, infecting the rest of Linux with the desktop philosophy is an extinction-class mistake.
None of the things you mentioned meet criterion (3) in my original question. Therefore, you have not convinced me that there is a need for systemd.
> Socket activation (and related features like bus activation) are one of systemd's key improvements to the boot process...etc...You could do that with inetd or similar, but inetd doesn't integrate with the init system, so an inetd service can't declare any dependencies on other services, and won't get tracked alongside other services (e.g. with systemctl status).
This problem can be avoided entirely if you start avahi early and immediately swap it to disk. Then, it's not taking up resources when it's doing nothing, and the OS swaps it back into RAM automatically when it gets a connection. No need for systemd, or inetd even.
The only thing inetd needs to function are (1) networking, and (2) locally-mounted disks (i.e. for reading its config and loading server binaries), so the solution is to start inetd once networking and disks are up (that applies to pretty much any non-trivial service, btw). You shouldn't have to tightly-couple inetd to the init system anyway--simply have the program inetd starts be a script that first checks with the init system (which may or may not be systemd) to see if the service can be started, and block (or time out) until the service is ready for inetd to hand off the connection. Again, no explicit need for systemd.
> People care about booting quickly.
Get an SSD :) ducks In all seriousness, this doesn't qualify as a show-stopping problem on the desktop, since you're not rebooting that often anyway (I regularly go ~3 months between reboots on my laptop). Moreover, you don't need systemd to get fast boot times--it's also possible to compile your boot process to minimize I/O (which is the limiting factor of boot speeds). It's not that far-fetched of an idea--Pardus Linux uses (byte-compiled) Python scripts to boot the system, for example, and it gets excellent speed-up [1] (in the benchmark: 15s to get to KDM login on a P4 with a 5400 RPM IDE disk).
I can see boot times being a problem in mobile space, but you don't need systemd to get fast boots either. Just load up the GUI and log-in prompt once the rootfs is mounted, and then asynchronously start up the rest of the phone's internal services once the user has logged in (i.e. and unlocked the SIM card). Chances are, the user is only concerned about boot-time when they're in a hurry, and I'm going to take an educated guess that the hurry is caused by the pressing need to dial a number, get/send a text, or load a map (probably in that order). So, asynchronously start the telephony stack, the SMS daemon, and the location service (in that order) once the user logs in.
The telephony stack takes a while to initialize anyway (i.e. to register with the service), so there's space to use that time for starting non-essential services asynchronously after log-in.
> Then there's journald's original reason for existence: "how can we make 'systemctl status' show the last few lines of log output from a service?"
See my earlier comment of why integration of orthogonal concerns belongs in a higher layer than systemd. I would (1) set up the daemon to log to its own well-known place, and (2) run "cat $LOG | tail". I could even store a repository of service configuration /etc/conf.d, where each service has its own file that describes a few common environment variables, like where it logs to. Again, no need for systemd.
Socket activation (and related features like bus activation) are one of systemd's key improvements to the boot process. Activation avoids the need for explicit dependencies, because you don't need to depend on avahi to start using the avahi socket. And because of that, systemd can launch avahi and services using avahi in parallel, by opening the socket for avahi, and letting other services write to that socket before avahi fully starts, only blocking when they go to read from it.
You could do that with inetd or similar, but inetd doesn't integrate with the init system, so an inetd service can't declare any dependencies on other services, and won't get tracked alongside other services (e.g. with systemctl status). So in practice, very few distributions actually launched services from inetd in practice (notable exception: CUPS), while many distributions use systemd's socket activation.
People care about booting quickly. While mechanisms like bootchart existed before systemd, you had to explicitly boot with them to collect results for analysis, and they'd slow down the boot process. With systemd, you can run "systemd-analyze blame" or "systemd-analyze critical-chain" on a production system and see exactly what you need to work on to make the system boot faster. (That was one of the widely lauded features of DTrace: you could safely use it to diagnose production systems.)
Then there's journald's original reason for existence: "how can we make 'systemctl status' show the last few lines of log output from a service?". How would you do that on an arbitrary system running an arbitrary syslog implementation? (For extra bonus difficulty, do so while attempting to track the syslog implementation as a service itself, and avoid deadlocks.) Sure, you could recreate that functionality on a particular system with a particular logging configuration, and there are dozens of systems doing so, not counting the myriad production systems deployed with bespoke solutions for log monitoring. (Even then, most of those systems don't correlate a service's log output with that service.) But systemd makes it easy and universal.
And that integration extends beyond systemd as well. For instance, if fixing a problem requires adding a new kernel interface, they'll submit a kernel patch, and then have systemd use that new kernel interface, rather than hacking around the problem in systemd and producing a suboptimal solution.