From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1091 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Vision for new platform Date: Tue, 12 Jun 2012 10:30:56 -0400 Message-ID: <20120612143056.GX163@brightrain.aerifal.cx> References: <20120610235125.31f38cd7@sibserver.ru> <20120610163359.GJ163@brightrain.aerifal.cx> <20120611015349.701fa061@sibserver.ru> <20120611022606.303f6d07@sibserver.ru> <20120610193348.GK163@brightrain.aerifal.cx> <20120611175922.34fea59b@newbook> <20120612014840.GT163@brightrain.aerifal.cx> <3044.132.241.65.136.1339479458.squirrel@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1339511730 21329 80.91.229.3 (12 Jun 2012 14:35:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 12 Jun 2012 14:35:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1092-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 12 16:35:27 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SeSBp-00049D-7O for gllmg-musl@plane.gmane.org; Tue, 12 Jun 2012 16:35:25 +0200 Original-Received: (qmail 13657 invoked by uid 550); 12 Jun 2012 14:35:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13649 invoked from network); 12 Jun 2012 14:35:24 -0000 Content-Disposition: inline In-Reply-To: <3044.132.241.65.136.1339479458.squirrel@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1091 Archived-At: 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