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."
He plans on implementing one of the key things which will makes systems bring up the user interface faster: launch only those services required by the system to boot, then launch the desktop (if applicable), then continue loading any "secondary" services. For example, the log rotation script found on some distros doesn't need to run before the interface is launched. I think this has been needed for a long time on the Linux desktop. It's worked that way on Windows for a long time.
Developers: We can use your help.
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, I'd hesitate to call it easy to use. The standard C++ language bindings in particular are astonishingly bad:
The situation is reported to look better from other languages, and I can personally confirm that the Java bindings are a delight to work with by comparison (of course in Java it's even easier to just use RMI).
As for the wire-level protocol, I have no complaints about IIOP now that it has readable corbaloc: URLs (the CDR marshalling details are still messy but unless you are writing your own ORB they are taken care of for you). I'm actually a bit surprised that IIOP isn't more widely used on the Internet and in the open source world (outside of GNOME of course) -- it's the distributed computing open standard, it interoperates across languages and OSes, it has numerous open-source implementations, and It Just Works(tm).
Instead we are getting stuff like web services and SOAP, whose wire format is just as incomprehensible to humans (don't kid yourself that XML is easy to read -- have a look at a fully-decked-out SOAP message some day) while using many times as much bandwidth and memory and taking at least ten times as long to parse. (And I say this even though I currently write SOAP gateways for a living.)
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.
I don't think Seth's reasoning _ever_ got on this.
The boot process on Linux is slow. It's one of the few things that seems to be the same about every distribution. Compare boot time on a WinXP box with non-essential services turned off to boot time on a Linux box with non-essential services turned off. WinXP boots a lot faster, at least in my experience. Can the current system be improved enough to compete? At least one person is saying no.
Seth is proposing a new system that would be faster and have daemons "take care of themselves" without the need for tons of complicated scripts. These are valid and appropriate goals. It's not pushing some sort of desktop agenda (the "GNOME is taking over!" conspiracists amuse me, I must say), or forcing you to run X.
This doesn't "address the server-side", or so some people claim, but I've seen no reason that you couldn't easily direct text output to console exactly like the current init does. Of course he's addressing the X desktop - because that's the far more complicated problem.
-Erwos
Plausible conjecture should not be misrepresented as proof positive.
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.