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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
