Reordering the boot for fun and profit

Yep. Rewriting this seems like a lot of work. And based on my experience, Ubuntu Hardy hasn't
yet done all of it. Some parts such as getty definitely has been upstart-ified, though.

But there is a thorny problem in the method of launch everything asynchronously from events, I
think.

As an example, I have an USB-attached disk that I want to mount on every bootup. Currently
something tries to do fsck on everything a bit too early. The USB disk is not ready, yet the
dumb fsck tries to access it, barfs on missing device file, tells me to log in as root to
correct it.

This is a bit ridiculous. It's supposed to be a removable device. Conceiveably I could plug it
in any time. And I do want it mounted automatically, too. And I know exactly where I want it
mounted. And most of the time, the device is connected and power is on.

Clearly, the only way to do mounts like this is to have udev detect a new device, then figure
out that it's a disk, and check fstab and find that user wants it mounted. So *udev* has to
launch fsck and do that mount, if fsck says it's safe to mount. And that sucks because from
asynchronous daemon you have hard time communicating to user that something is wrong with the
connected device, and he needs to take action.

Assume for instance that there is a disk error during boot time. There's no X yet, no notify
area in console, the system is only half ready. What on Earth can you do? Skipping the drive
might be good idea, but what if /usr is on it? It's conceiveably quite easy to handle failures
of non-critical disk mounts from, say, GNOME (just pop up a messagebox in notify area about
error), but at boot time you are SOL.

So what are the solutions? Start X before starting anything else, maybe? Implement a notify
area for Linux console? Accept that stuff mounted during bootup from fstab is fundamentally
different from anything done later on, and thus fragment the user experience? All these
solutions that come to mind seem to suck for one reason or other. Of all of them, I'd prefer
to drop the stupid splash screen and launch X, actually. Imagine that.

Since I have to have some text here, else LWN comment editor complains....

This has the structural tone of a classic.  We need a place to store it, but not just a place
to enshrine its wisdom and wit.  It must be open to allow a branch where it can be embellished
and polished to the finest finish possible, albeit, still allowable by the Lords of the Wiki.
While the original should be venerated as the Core.  The Branch should be known by a related
but better naming, I modestly suggest it become the Kernel-Humorous.

Just think to the delicious mayhem when the Gentoo-DOM add their non-taxable, non-profit two
cents.  And think of the better Debian embodied in the Free Solaris skewing free of reason.
Of course, it would not be done until the better Unix build as exhibited by the
Windows-Whatever were allowed to make their mark.  Only then would it be done with their six
point "x".  Ah the horror ...

I think this is the funniest comment I've ever seen on LWN...

> Indeed.  Debian could call them "halt", "reboot", and "singleuser"
> Ubuntu would call them "Stop", "Restart" and "Just Me".

Let's rename /etc as well, shall we?

Gentoo would trigger a dip in the world petroleum supply with a flamewar on a dev list,
leaving no survivors with the will to effect any changes, and just keep the old stuff due to
inertia.

Level 4 was originally graphical without networking. However, that's pretty useless anyway,
and involved turning the networking from level 3 off, so nobody ever used it.

This is the only thing that I just can't understand why debian has to screw it up, and use
level 2 for everything, graphical or no.

As for the sequencing, it's not really rocket science - it's alphabetical! Originally the
numbering was such that the Kill script + Startup script = 100 ( or 1000 if you used HP-UX ).
That way, the services were stopped in the reverse order of startup, so there's no problem.

eg S80apache and K20apache, S81tomcat and K19tomcat