On 13/06/2015 11:37, KatolaZ wrote:
> AFAIK all this fuss with
> "daemon-readiness" began with the first attempts to have parallel boot
> sequences, which is something that is still *useless* in 95% of the
> use cases: servers don't get restarted evey other minute and "normal"
> users who don't use suspend can wait 30 seconds to have their desktop
> ready, what else? Embedded systems? Well, they usually have just a few
> services running, if any....

30 seconds is a lot. What if you could get your desktop ready in
5 seconds or less ?
About embedded systems, things are changing quite fast. The amount of
services running on an Android phone, for instance, is mind-boggling,
and it can take several minutes to boot a phone. Most of this waiting
time is unnecessary.


> What are we really talking about? Isn't this just another
> feature-for-the-feature's-sake-thing? Why should I bother to allow
> cups signalling immediately that it is ready to put my printouts on a
> queue that will anyway need minutes to be processed?

A printing service may not be the best example, but when you're late
for a broadcast and turn your TV on, you don't want to wait any more
than is necessary to get image and sound. If your TV took extra seconds
to boot up, you'd curse at it.
(This has happened to me, I watch broadcast streams on my PC and have
wished for faster booting times on more than one occasion.)

More generally, the main reason why computing is so slow is that
everyone reasons the same way "why bother?" Somebody has to start,
and there's no better place than the low level.

If nothing else, there's the public relations argument. As long as
systemd is able to say "we do parallel service startup and boot your
machine in 5 seconds, nobody else does it", then systemd has a real,
valid, technical advantage over other systems, and it makes it harder
to advocate against it.

--
Laurent