From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1081 Path: news.gmane.org!not-for-mail From: idunham@lavabit.com Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Vision for new platform Date: Mon, 11 Jun 2012 22:37:38 -0700 (PDT) Message-ID: <3044.132.241.65.136.1339479458.squirrel@lavabit.com> References: <20120610225226.137363d0@sibserver.ru> <20120610151311.GH163@brightrain.aerifal.cx> <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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1339479480 30851 80.91.229.3 (12 Jun 2012 05:38:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 12 Jun 2012 05:38:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1082-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 12 07:37:59 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 1SeJnb-0001yY-JZ for gllmg-musl@plane.gmane.org; Tue, 12 Jun 2012 07:37:51 +0200 Original-Received: (qmail 13679 invoked by uid 550); 12 Jun 2012 05:37:51 -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 13671 invoked from network); 12 Jun 2012 05:37:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=qGTJPAOGQEWi6K7WcxCvdAlESdgb2u1eQ9SNK67Ok4JBdcknYmOK1kDSVz6lc8OfIEuqY1PP7Z+clkKxjLFoMWdt5Zxihf94l2ZLcNatbWWKNTc3piJOjbjigHSerFyRFO98DgEwYJC1DmR51lX+yuxELVWBzWTVMmwJ0UXIo+0=; h=Message-ID:In-Reply-To:References:Date:Subject:From:To:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; In-Reply-To: <20120612014840.GT163@brightrain.aerifal.cx> User-Agent: SquirrelMail/1.4.13 Xref: news.gmane.org gmane.linux.lib.musl.general:1081 Archived-At: > On Mon, Jun 11, 2012 at 05:59:22PM -0700, Isaac Dunham wrote: >> runlevels come in handy, if you know how to use them. >> Debian mutilates them, though, so they seem less handy on >> Debian/Ubuntu systems. >> Here's what I'd do: >> 1. I just want to get into recovery (single-user) mode in a hurry; the >> system is hosed as it stands. > > If you're just talking about booting, adding "init=/bin/sh" to the > kernel boot line is the way to do this.. > If you're talking about taking down a running system "into single-user > mode", that's a hard problem to do correctly and it depends on all the > daemon stop/start stuff. Both. init=/bin/sh is usually good; however, I have seen at least two systems where it wouldn't boot (one Arch Linux and one Scientific Linux) Also, I'd rather use the same command both times... >> 2. I want a shell, quick (maybe because there's one file I need to copy >> over to a flash drive) >> 3. Networking would be nice, but I don't want X just yet. >> 4. X is handy, but maybe not networking or printing... >> 5. Start the whole enchilada. >> >> And yes, I do see a need for all 5 of those, including a way to start >> the system in any of them (which runlevels allow, via kernel >> parameters). >> Sometimes, starting networking or not makes a minute or more of >> difference (yes, I've timed it: 34 seconds vs 100+). On one of my > > 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. 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. > As such, I don't think "we need to be able to boot into profile X or > profile Y because profile Y might sometimes be too slow" is a good > argument for multiple boot profiles. Nonetheless, I think they could > be done as long as the kernel boot passes some environment to init > which can in turn be passed to the script init runs that starts the > daemons or daemon supervisor. parsing /proc/cmdline is the standard approach. >> computers, if I let the networking daemon run in the wrong area, it >> reliably panics the kernel (madwifi 0.10.5.6 is the most functional >> driver, except it panics if dhclient gets run too soon). So "turn off >> networking via boot parameter" is mandatory for me. > > This is extremely broken and needs fixing. I know, but it's beyond my knowledge, the madwifi developers have abandoned this branch, and both ath5k and madwifi 0.9.4 (the official version) drop connections multiple times per hour--and that's been a "known issue" since 2008, IIRC (still not fixed in kernel 3.4). ndiswrapper may not work these days (I've heard of connection drops that way, too), it's a pain, and I'm not touching it. In other words, it's not getting fixed, and it's still better than the alternatives. And you can bet that there will be more drivers that don't work right.