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...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.
> But systemd makes it easy and universal.
Easy? yes. Universal? No. https://xkcd.com/927/ ;)
EDIT: wording
[1] https://web.archive.org/web/20090505144440/http://www.pardus...