Re: Re: Vision for new platform

[Rich Felker <dalias@aerifal.cx>]

On Mon, Jun 11, 2012 at 10:37:38PM -0700, idunham@lavabit.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