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 Linux startup process works. Is there any need to muck about with it? On Red Hat et al and Debian, there's the powerful but complicated init.d directory; while Slackware users have a less sophisticated system to contend with.
;-)
And hey, it's not like we have to boot all that often, is it
Je fume. Tu fumes. Nous fûmes!
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
Yes this is a horrible perversion and deviation of UNIX.
/etc/inittab to see what further program it should call. For each runlevel there is such a program.
/etc/rc2.d/S*). But all this is just "usual" and could be completely modified without throwing away the standard init system.
Also, the so called disadvantages of init are void. It looks like he does not understand what init is.
Init is very simple: the kernel calls a program called "init" as soon as the kernel-part of booting is ready.
The "normal" init (there is a SYSV and a BSD variant, the SYSV variant being somewhat more complex) only reads a config file
Usually these are the init.d/rc shell scripts that sequentially carry out a number of initializations. Often there is a kind of master script such as rc2 (for runlevel 2) that calls further scripts in some order (those are usually in
If you want, you can configure inittab to call some multithreaded language to carry out some initializations or start background daemons (yes, a UNIX "service" is a daemon, heretic!) in parallel, speeding up the init process.
You can also simply use shell scripts instead of threads, but use shell background jobs (&) to do some things in parallel and then wait for each of them afterwards (the shell wait command), so you don't even need some multithreading for speeding up your boot process (the difference between multiple processes versus threads in this context is measured in milliseconds, not really a worthwhile advantage when it comes to boot time).
In short: it is an insane and heretic idea, that can only be bred by evil plans or by ignorance.
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.
Python is not GPL
"Python is absolutely free, even for commercial use (including resale)"
http://www.python.org/doc/Copyright.html
A Usenet Troll Triumphs on Slashdot
Here's one from IBM: Parallelize Linux system services to improve boot speed. It's not so much as "replacement" as an "enhancement" to speed up the boot process. Interestingly, it uses make to manage service dependencies.
Oh yes it is. When I log in a user with bash as shell, you can _feel_ the delay while bash and the dynamic libraries of it are loaded. Yes, even on my Athlon XP. Why? Because my init system loads neither glibc nor bash.
KDE is only faster than 2.x if you disable all the new eye candy that is now available, like translucent menus and the flashy theme stuff. Yes, that's comparing apples and oranges, but it's also comparing the default desktops. Keramik is themed with large pixmaps, the kde 2.x default layout wasn't (or I'm on crack and didn't notice).
Welp, looks like the DBus project page has been compromised -- visiting it contains a link saying 'This file has moved here', the 'here' linking to goatse.cx. Anybody have a mirror of their site?
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
Reasons why CORBA sucks (mostly from the C++ mapping):
1) The whole distinction between servants, object references, etc, might be nice in whatever fantasy world the standards makers lived on, but its far too complex. A proper standard (POSIX is an excellent example) should scale. Simple things should be simple, and implementation complexity should scale linearly with problem complexity. Objects are a pretty simple idea. CORBA makes them anything but.
2) The C++ mapping is completely braindead. I'm someone who finds C++ itself to be rather simple and straightforward, and I still can't always get the parameter passing conventions correct. It also doesn't use the STL. Being released in 1994 is no excuse. We're thankfully leaving the stone-age of C++ behind us, and unless the CORBA C++ mapping is updated, it should be one of those relics we leave bhind.
3) The standard is full of "gee, wouldn't this be nice" features, while missing some very basic conveniences (offering string-representations of error messages in exceptions).
A deep unwavering belief is a sure sign you're missing something...
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.
The SystemStarter process that Mac OS X uses is based on the Next init/rc system which is similar in principle to how FreeBSD does it's init/rc system. Since it's part of Darwin it should be available under a BSD license. I'm sure it could be rewritten to use X rather than WindowServer for it's graphics.
I think that's a more worthwhile replacement for linux's init/rc system IMHO.
Link
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.
Caldera OpenLinux 2.2 -- see the review