The functionality is key for socket-activated daemons which is a Big Idea behind systemd: it can launch daemons on-demand instead of at boot, allowing for faster boot times
True! But the launchd style of socket activation integrating into the dependency graph of service startup is what's novel and alleviates some significant challenges to concurrent starting of interdependent services...
The person who raised it just said socket-activated daemon is "a Big Idea" behind systemd. They didn't say or imply that systemd invented it, just that systemd is based on that pattern.
Yes. But the Iron Law of systemd is that you should never mention it unless you’re prepared for a tangential argument about systemd and other init systems.
I don't understand why faster boot times was ever a priority in the first place. I know it's a metric that linux ricers sometimes like to compete on, but normal users just suspend their computers when not in use 99 times in 100.
Linux use in computers that can suspend is negligible compared to the number of instances of Linux in random gadgets that you expect to work as soon as you turn them on.
More than once I've known I have an early meeting and got to my desk just before the clocked turned - but by the time I got into the meeting several minutes had past. I work with people around the world, sometimes you need someone in Germany, India, Australia, and Basil to all meet at the same time - there is no way to pick a good time for everyone, and the closer you get for one person the worse things get for someone else so you end up with barely acceptable times for everyone as the best compromise.
Its not faster boot that matters but that the system can have many more services configured and pending activation. It makes a much more dynamic OS possible, which matters in a world of mobile computers that dock and connect to new hardware and networks all the time.
