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