[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Jun 2012 21:48:40 -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 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.
> 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.
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.
Speaking of which, if we end up writing a new program for that, how's
"daemon-visor" for a name? I can think of some nice logos for it.. :-)
> 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...
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.
