[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Jun 2012 22:37:38 -0700 (PDT)
From: idunham@...abit.com
To: musl@...ts.openwall.com
Subject: Re: Re: Vision for new platform
> 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.
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.
