Slashdot Mirror
Replacing the Aging Init Procedure on Linux
SmellsLikeTeenGarlic writes "Seth Nickell (of Storage and Gnome HIG fame) has started a new project which aims to replace the aging Init system on Linux. OSNews has more details on the project, directly from Seth. The new Python-based approach will make booting faster and it will talk to the D-BUS daemon, freedesktop.org's leading project. And speaking of freedesktop.org, it is important to mention the release of HAL 0.1, an implementation of a hardware abstraction layer for KDE, XFce and Gnome, based on a proposal by freedesktop.org's founder Havoc Pennington and being implemented by David Zeuthen. It is innovative projects like Storage, SystemServices and HAL that can bring the kind of integration to the underlying system that current X11 desktop environments lack."
The relevant one here is the management of services -- far easier than anything similar I've ever dealt with in the Unix world. I realize that 1) this proposed replacement goes beyond what the Gentoo system manages and 2) real sysadmins running real servers aren't going to leave the existing system any time soon, but for desktop users today, it's a great advance that doesn't get the credit it deserves.
What I'm listening to now on Pandora...
What kind of coke are you on?
1) Shell-scripting being interpreted is not the bottleneck. The bottleneck is all the processes that most init-scripts start at bootup, as well as stuff like hardware detection, waiting for DHCP leases, etc. Besides, Python isn't interpreted like shell-scripts, it runs on a bytecode-VM. And Python is fast enough that RedHat uses it for its GUI tools, and most people can't tell the difference.
2)KDE has gotten *faster* since 2.0.x. 3.2 is the fastest release since the 1.x series. In the 2.x transition, GNOME got a lot faster, but people didn't notice it as much because GTK 2.x was so much slower.
A deep unwavering belief is a sure sign you're missing something...
"His approach isn't very *nix-ish, it is very Windows-ish. It assumes you have a GUI."
Please read the article again, especially the part where Seth Nickell wrote "I *will* provide a way to boot into a "stripped down console mode" aka "single" for system recovery and backup, and a regular non-graphical boot for servers."
From what I can tell, SystemServices in and of itself only depends on D-BUS and libc. There are Python bindings for D-BUS, so that may make it easy to write a script for SystemServices using Python, but that's the extent of Python's relationship to SystemServices.
Hmmm... Windows XP gives me a desktop (somewhat) more quickly than Gentoo does, but I have to wait for about 90 seconds to actually do anything or run a program.
It's a tortoise-and-hare thing; Windows (and lately Gnome) give you eyecandy early on at the cost of having to wait with what looks like a perfectly functional desktop while the rest of your base loads. That's why I use Windowmaker. Once I get to GDM it's rare that it takes more than 5 seconds to have a desktop with nothing stalling on me. YMMV, and this is fairly OT anyways since once I'm at GDM, init's not automatically loading stuff anymore.
All's true that is mistrusted
There already is a better init system: simpleinit. I've worked with it on embedded systems, and it rocks.
It's dependency-based, so you only start up the services you need. Read all about it.
Dependancies are a big improvement over runlevels, although you could implement runlevels on top of it.
ETLinux replaced init several years ago with an entirely scripted version. Different scripting engine (Tcl instead of Python) and for different reasons (keeping an embedded Linux kernel tiny.)
... added Tcl equivalents for some common syscalls and services: sys_dup, sys_exec, sys_fork, sys_kill, sys_nice, sys_pipe, sys_reboot, sys_sync, sys_wait, sys_chmod, sys_umask, sys_mknod, inp, inw, outp, outw, setleds, mount, umount, uudecode, uuencode, time, ifconfig, route, udp. The introduction of these commands allowed the rewrite of the initialization scripts in pure Tcl, avoiding the inclusion of large binary programs.
Making this happen was that the ETLinux folks
More on ETLinux architecture here.
Oww, gawd!
Not Emacs, vi!
If you RTFA, you'll see this is aimed at desktops with a GUI, which is somewhere that startup time is very important.
To quote the article:
"SystemServices has four major goals:
1) Provide a full services framework (including handling "boot up")
2) Integrate well with a desktop interface
3) Start X, and then allow login ASAP
4) Allow daemon binaries to directly contribute services rather than requiring each distro/vendor to write shell script wrappers"
Yes, this is very Windows like, but just because it's Windows like does NOT imply it's a bad thing!
FreeBSD, for example, has relied on Perl being available in the past. Gentoo relies on Python. Relying on a scripting language to provide extensibility is not a bad thing.
I'll agree that init works well for servers. I love how DB2 installs itself in the inittab, so init makes sure it's always running. This is a good thing.
Init does not work as well for desktops. My laptop takes incredibly longer to boot Linux than Windows XP. My iPAQ takes a long time to boot Linux, compared to the startup of WinCE. (Yes, I realize that you don't have to restart Linux very often on the iPAQ, but that's not the point)
Some of you may not have written your own dists, so here is a breif overview of why this is the stupidest thing I have heard in a very long time.
1) Bootloader straps a kernel
2) Kernel mounts a filesystem ro, and loads init from it
3) init forks a single shell
4) that shell launches everything found in the inittab
5) that shell then procedes to run your init scripts
From that shell what you do is up to you.
In single user {runlevel S/s} you stop at #4, and start from that shell.
Any other runlevel will be started from that shell. It doesn't matter if your scripts are written in perl, csh, sh, php, tcl or python.
It doesn't even matter if you write them in a language that you can compile for extra speed.
99% of your time is in loading the interpreter, and waiting on the daemons themselves.
sendmail is extremely slow on loadup, so are other apps. Try setting dhcp, and having it time out.
or RedHat's retarded Kudzu tool.
Calling those from a faster interpreter, doesn't make them load or run any faster. It never will.
If you think runlevels aren't important... Try patching a running system sometime.
-- Sir Ace
But that doesn't answer the original question -- what exactly is wrong with the current init process that requires a replacement?
Say you are on an enterprise that uses a DHCP server for the network. Say the DHCP server is down, but people still can boot their desktops and do work with no network connection, so productivity doesn't go to hell while they don't get an IP.
Now if you're using dhcp clients on your computer, unplug the network wire. Reboot. See it try for minutes to get a dhcp lease before it continues boot. Now think of services that could trigger the same wait.
Current init: good for servers, not so for desktops.
As someone else noted (in an article with a link done as text, not as an , and with an extra blank in it), Mac OS X has a possibly-interesting scheme for starting and stopping system services. Here's the section on System Initialization in the Mac OS X online documentation; in particular, look at the Startup Items stuff.
It's a dependency-based scheme, like at least some of the other proposed system services mechanisms; see the section on adding your own startup items.
Note also that Boring Old Init isn't itself changed; /etc/rc runs SystemStarter as its last act, and that starts up the system services. SystemStarter can also be used as a command to start, stop, or restart services, so this isn't just a system startup mechanism.
NetBSD 1.5 and later have a new rc-based system for controlling services; it's also dependency-based. FreeBSD 5.x has rcNG, which is derived from the NetBSD scheme.
(Note that all of those systems have a BSD-style init, and thus don't have run levels.)
Those schemes don't address one of Seth's complaints, however - according to his description in his blog, he doesn't like having shell script wrappers doing the configuration, he wants it done in the service's process itself:
(I express no opinion on this one way or the other; if you like or don't like the idea, send bouquets or brickbats to him, not me.)
Note also that it appears that he is not designing something just for desktops - in particular, he says:
Now, whether the kernel should start ServiceManager directly, or whether it should continue to run init and have ServiceManager started from an rc file, is another issue; I'm not sure that there's a compelling argument to eliminate init other than to discourage people from continuing to use the current rc script scheme (which might be Seth's motivation for running ServiceManager as process 1 - he might want to discourage rc script tweaking).
Perhaps one of the reasons why people thought of ServiceManager as being purely for desktop systems is that they thought that, as D-BUS is somewhat associated with freedesktop.