Kaz Kylheku \(gmake\) via Dng said on Sat, 08 Jan 2022 11:20:23 -0800 >On 2022-01-08 03:43, mirabilos wrote: >> Bah. How often do you boot a unix? > >Boot time optimization is very important in some embedded applications. > >A powered-up device is expected to come into service ASAP basically. > >Some devices are powered up every time whatever they are embedded into >is powered up, and have to provide some important function to that >host environment.
I said it before during this thread and I'll say it again: Serial boot is pretty quick unless a daemon is written inefficiently or it's misconfigured. And as far as devices being expected to boot a device, when's the last time in the past decade you've seen something come on in a second or less? My last two TV sets rivaled the old tube sets in time to show a channel. My car radio sometimes takes 30 seconds to play content. And as far as embedded applications, how many daemons will it have running? Probably few. Last but not least, if one thinks parallel instantiation is the hill to die on, runit and s6 already have it and do a great job without all the cruft inherited from sysvinit. I started using parallel instantiating Daemontools in the mid 00's, and it worked just fine. I've used runit for six years and love it, but parallel instantiation isn't why I love it. You know what I'd like to see for sequential instantiation? Use runit's runsv single process supervisor, and configure it with just a shellscript of runit commands, each of which has a timeout figure, and change something just a little bit so that if a daemon times out, it logs the timeout and then its runsv instance terminates. That feedback shows you where all your boot time is going. A lot of common sense and ease of debugging and DIY has been sacrificed on the alter of dancing to FreeDesktop/systemd's tune. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
