On Wed, Jul 21, 2010 at 10:28:32PM -0400, Colin Walters wrote: > Well Lennart's post basically boils down to: > * Boot faster I don't need my systems to boot any faster. Or rather, I would like them to, but the majority of the time is spent in the bios boot sequence already as disks come online and so forth, so improvements here are moot. My laptop already boots fast enough already, although I guess if it can be improved even further with minimal disruption, why not. I don't see it as worth a lot of pain, though -- not because I don't use my laptop a lot, but because suspend/resume makes boot time irrelevant in the general case. > * Have the init system be more flexible and powerful So, for me, this is the key benefit. It'd be nice to have the service that starts services be able to keep track of them better. It might be nice to have a smarter interface to cron (and something like incrond?). However, in the overall scheme of things, I don't know any sysadmin who really spends much time _worrying_ about this stuff. For the most part, it works _very well_. It's annoying if some little program doesn't already have a nice init script written, but eh, no big deal. When something goes wrong, it doesn't take long to figure out what (even if the root cause is a mystery -- "autofs died. hmm. wonder why") and correct it. Changing the init system to something complicated runs the risk of making an easy problem into a hard problem -- this is the concern raised a while ago about shell scripts vs. a config file interpretted by binary code. I won't speak for anyone else, but to me this is why "wait, what problem are we trying to solve?" resonates with me. I *do* like the prospect of easy management of resources (CPU policy, OOM, io class) for services. The templating mechanism might be useful here. And I'm hoping that maybe, finally, dependencies in init will mean that NFS mounts in fstab don't utterly fail when NetworkManager (another source of sysadmin displeasure, but let's not go there now) is used. And I should add that I appreciate that the proposed config file format is key=value rather than some XML monstrosity. -- Matthew Miller <mattdm@xxxxxxxxxx> Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
