Mark: you were right. I did it bit by bit and it turned out one of my NICs was totally fried and caused the system to not start at all. I had unplugged everything else, but never bothered with PCI cards. Computer now chugging away happily :-)

Listening to 80s music today. Started with a sugar-coated dose of A-Ha (accidentally left "Take on me" on repeat for 30 minutes, it will be stuck in my head for millenia to come). Moved right along to an hour of the incredible Ultravox. I want to be a machine. Then somehow my player landed on Queen's 1980 album "The Game". I finally figured out that it was going to be an 80s day and acquiesed. So now I have a playlist for the rest of the day including some old U2, 80s David Bowie, etc. I will end with a stunning indictment of the period: I have noticed that most of the best albums that are strictly speaking "from the 80s" were released either at very the end or in 1980/81.

In other news, reshaped SystemServices around the futile, idealistic goal of having daemons contribute the services instead of silly little shell script wrappers in the future. Ever poked through RH's /etc/init.d/ scripts? Its absurd... they do so much stuff in there that should be included in the bloomin' C code. If you need a check for something, just have the program itself do it.... But of course, these programs were designed to be run with lots of magic brittle flags rather than running and situating themselves intelligently.

So the thing I'm playing with now is.... System services are just plain ol' services which run on the system dbus and provide a standard org.whatever.Services interface (in addition to any extra interfaces they want to provide). So I've got all these great ideas for SystemServices, but the first goal is to make sure we cover init/initscripts role well.

Starting a service: ServiceManager, when you tell it "start org.designfu.SomeService" does a check on SomeService's dependencies, loads those first if necessary, and then activates org.designfu.SomeService using normal dbus activation. Ideally this would mean activating the daemon itself which would use DBus, but it could also mean activating a "python wrapper". ServiceManager sends out a signal over DBus announcing a new system service (and providing its name). At this point org.designfu.SomeService is responsible for keeping people notified as to its state.

The boot process: So first the kernel loads itself, and calls ServiceManager (instead of "init"). The ServiceManager starts the DBus service manually, and checks to see if it should be doing a graphical bootup. If it should be, it starts the GraphicalLogin service (which of course may have dependencies to start first). Once this is done, it loads the list of services to be started, and goes through them in order starting each one (with dependency checking of course) from a thread-pool. In the long run, we could measure critical path from the last boot and run through in that order.

Graphical boot progress: As soon as X is runnable we start GDM (gdm has to manage X, so we have to start GDM). But we modify gdm to have a "--no-login" argument that hides the login window... until we write to the GDM socket a "show login window" message. OK, so now we have X running. We startup a boot progress monitor which listens to ServiceManager. When it hears about a new service, it registers to listen to that service. When we hear a service is starting, we show a "starting" icon for it (services can specify icons), then when we hear its running we display that. Once the last dependency needed for safe login is loaded, we call GDM and tell it to show the login window. Hopefully, this will be about 15 seconds from the kernel starting to load. When you log in, a boot progress window moves to the side of the screen, so you can still get feedback on system services starting. The window disappears when the system is fully started.

Using init scripts: We have an init scripts proxy that tells the ServiceManager about all the available "runlevels" (which just depend on a bunch of other services) and existing init scripts. These all just become services. So we can load init scripts at this level normally. They won't provide an icon or a nice human-readable name, and won't provide most of the services features once things are running, but they'll start ok.

...more on non-initscipts-like features later...