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."
I like python a lot, but why make it a requirement for init ? Just means more stuff has to be installed fort he default system to work. I prefer to sue the base shell.
SystemServices is not at all tied to Gnome. It will probably not require much more than the kernel and Python. His goal is partly to make a nice set of APIs callable from a desktop like Gnome to ease with management and error reporting. This project is not tightly integrated with Gnome just because someone from Gnome has started it.
Developers: We can use your help.
Back in my day, young whippersnappers didn't show disrespect to their
elders by talking about replacing them with fancy-pants code. We were
shell scripts and we liked it.
Not Bash scripts either, real life ksh scripts. You hippies and your
bash shell.. why I outta.. ouch, hurt my arm waving it so.
Anywho.. back in the day when we were happy little startup systems
we didn't have to worry about snakes. Python? Who ever heard of that
back then? We has ksh and csh and WE LIKED IT.
Damn granola-crunching kids and their need to improve what don't need
improving.. Stay in school, don't become pot-junkies and enjoy the
blessed rc that nature intended.
It started with all this Rock and/or Roll that you ingrates listen to.
Back in the 70's we rc scripts were appreciated. Then along comes this
electric gee-tar thing getting so popular and that did it.
Dag nabbit... where's my crontab..
where was I? Oh yeah..
Back in my day, young whippersnappers didn't show disrespect to their
elders by talking about replacing them with fancy-pants code. We were
shell scripts and we liked it.
.
.
.
It's "faster", because it's "python based"?!
The standard Linux init system is based on sysvinit and is slow precisely _because_ it is interpreted (it's basically a ton of shell scripts). The other reason why it's so slow is because glibc is slow and the init system starts several hundred processes during the init process. Just log in on a freshly restarted Linux system and type "echo $$" in a shell prompt to see how many programs were run before you logged in. On my minit based notebook, the number is below 20. On my minit based server, it's still below 30.
minit takes less than one second to initialize the whole server system, on an aging 466 MHz Celeron box, right from the point where the kernel starts init up to the login prompt. And the server does file sharing, cvs serving, rsync serving, runs a mail server and sshd.
In fact, because minit does not even depend on glibc, minit can probably initialize a small system in less time than it takes to even load python and glibc on this init system.
Fast and python based, give me a break. And the freedesktop people should keep their bloat to themselves, if you ask me. With the notable exception of KDE, all the gui systems on Linux have gotten progressively slower and more bloated over the years. KDE has also become slower, but less drastically, so it can be excused IMHO. But Gtk? Give me a break! Even starting the gnome theme engine takes 5 seconds on my 2 GHz Athlon XP!
A replacement for the current init system, while necessary, should have fewer, if possible, dependencies than the current init, not more. Unices are being deployed across more and more diverse kinds of systems, and dependencies on python and d-bus, both of which projects I support in themselves, are not going to be welcome in the init of the majority of unix systems today, especially in servers or embedded systems.
As far as "most" sysadmins not understanding run levels, he's out of his mind. Maybe he doesn't get it, but it's a long standing thing that works well. In fact, it works SO well, that Linux adopted it from System V after using the older monolithic rc scripts for a long while.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
So I skimmed through the D-BUS spec and, as I expected, they are simply reinventing CORBA.
When will Open Source developers figure out that just because the OS community didn't come up with a technology, doesn't mean it has to be re-written with fewer features?
I gaurantee that whatever aspects of CORBA the D-BUS developers found unnacceptable - complexity, overhead - will be reintroduced into D-BUS by the time it reaches maturity. That's just how these things go - someone decides that Standard X is "cool, but too complicated", and then five years later they realize that their solution has become just as complicated as Standard X because, lo and behold, all that complexity was there for a reason. Real-world solutions never stay simple, because real-world problems aren't simple.
--
CPAN rules. - Guido van Rossum
If someone comes up with a whizbang new boot system. great. Just make sure that if something goes wrong, or something needs to be changed, it's:
I don't want some horrific equivalent of the Windows Registry lurking in the background. There should be no mysteries about what gets started and when. I'm not a Windows guru, so maybe this stuff is easy to determine in XP or Server 2003, but I've always found plain ol' text files to be much easier to deal with than fancy-dancy databases. Or at least compile the databases from plain ol' text files.
The only init replacement i've seen that seem to have some sense is: http://www.atnf.csiro.au/people/rgooch/linux/boot- scripts/index.html
elFarto
I think Seth's idea is a good one. Of course, there are some things to refine: the dependency shouldn't be external (e.g. SystemService knowing the dependancy tree) but dynamic (e.g. GDM sees that its config requires network login, so it asks SystemService to start network), etc.
But overall rethinking the init is a good thing. Even just opening the debate is a very good thing. The mess of shell scripts is more a giant hack than a well-thought bootstrap system.
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.
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