Date: Tue, 12 Jun 2012 10:30:56 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Re: Vision for new platform On Mon, Jun 11, 2012 at 10:37:38PM -0700, idunham@...abit.com wrote: > > Our aim should be <5 seconds (preferably <1 sec) from power on to full > > UI. The reason I bring this up is that A LOT of the motivations for a > > lot of the bad designs in legacy boot/init/etc. systems, including > > systemd, is due to tolerating ultra-slow crap and then trying to make > > it less hideous by doing it in the background, etc. > Tell me how you plan to handle wireless+DHCP. It can take 5+ seconds to > associate, and 20+ to get a lease. That's not negotiable, it's the facts > of life. dhclient defaults to 60 seconds timeout, IIRC. > There are other devices that will not initialize without a 3-5 second pause. Maybe I'm missing a usage case here. My view of wireless has generally been that it's a transient connection you can't always rely on to be up, and that it should always be handled in the background. Are there some users who use wifi like a fixed ethernet line and expect it to be configured and working before anything else gets started? If the issue is just wanting applications not to fail with "no route to host" type errors, I think this is something I want to solve even for transient wifi. I'd like to end up with a connection manager that (at least optionally) provides a fake route to a virtual device with 100% packet loss while the wifi is down or in the process of associating/dhcp, so that connection attempts don't immediately fail but keep trying until the timeout is reached when the wifi is not yet up. There are some issues with ip address changing, but I believe the kernel has a feature to deal with this; I used to have something like it setup with dialup pppd and dial-on-demand where connection attempts that started the demand-dial initially did not have the public local ip, but got it assigned once the connection was made. > Anyhow, I still insist on a choice at boot time of X or text. I could > list numerous reasons other than speed, but would rather not. Fair enough. > parsing /proc/cmdline is the standard approach. Got it. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.