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'm one of the crowd who will probably stick with init. It took me many many tries to tune my scripts the way I like it (and since I'll be reinstalling at some point, I'll have to spend some more time tuning) and I'm just too lazy to learn a new way. This is of course why old stuff is still all over the place, but hey, if it isn't broken, I'm not in a big hurry to replace it.
The current init system is actually fine in my opinion, but if someone comes up with better system that can boot my Linux system as fast as my XP system boots, I'm game.
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.
You missed the part where he said
and checks to see if it should be doing a graphical bootup.
So, this shows that he doesn't think the only reason to run Linux is to support an X environment. He continues to talk about what would happen IF starting up in a GUI mode were the current choice. He doesn't however ever state that would be the only choice.
Moderators, mod up this parent!
I 100% agree that linux can use a parallel service loader, but not with the bloat Seth envisions. All systems come with bash. Why not use it? Python is not needed for this.
Personnaly I LIKE my init.d scripts.
"Those who make peaceful revolution impossible, make violent revolution inevitable" - JFK
becasue BASH does not scale well and is dificult to use when needing to expose APIs to an upper layer.
I am the Alpha and the Omega-3
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 first read this article last night on Newsforge and did some cursory searches for the project. i couldn't find anything. has anyone else had any luck?
/. right away!!
the only things i've yet found are blog entries. he seems to be a reliable hacker but of what news is this until there's downloadable source-code? i'm planning on working on a new MUD; i'll be sure to submit that to
so if you have a link for us, please pass this along. also, like so many others have asked, how closely will this be tied to GNOME? even my desktop system uses WindowMaker ; why should a foundational mother-program rope me into a DE i don't like? or be reliant on the GUI in the first place?!
Oh, you mean until you find another OS that can "fake" boot as fast as XP...
XP has some serious issues in some cases with the way it "optimizes" the boot order. It appears quick, but in a corporate environment that can lead to weird timing problems. That's probably why MS left/added a feature to disallow logins until XP was really booted.
.sigs are for post^Hers.
I would agree that the init system in general could use an overhaul, however, the idea of writing a replacement init for "*Linux*" in Python is not going to fly. Maybe a replacement init for Red Hat, Suse, Mandrake, or other large distro.
Neither of my distros will benefit in the slightest from this sort of system. Coyote Linux and the Wolverine Firewall and VPN Server use a busybox init application. Coyote fits on a 1.44Mb floppy and Wolverine installs in 7.5Mb. This would not be possible if either system's init relied on Python.
The embedded Linux market will have no use for something that requires a Python interpreter. Not to mention, Bash shell scripting and Python source code are very different animals. Having to learn the basics of shell scripting to reconfigure the way your system boots is a far cry less complex than having to learn Python.
As an embedded Linux developer, this project gets an emphatic thumbs down (as do most interpreted programming languages, though). They have their place in larger systems, but "Linux" is no such system, it is just a kernel. If he wants to write an init replacement, he should target a given set of distros, not the kernel itself.
"There was an interesting idea posted on slashdotregarding using make to handle the boot process (Parallelize, and dependency handling) The original slashdot post is here."
They must be checking the Referer because the same link works fine when you come there through the main site.
I cannot leave this alone without citing a significant counter-example where a simplification of a complicated system was a tremendous success.
Unix as a less complex replacement for Multics.
Also worth a look:
r y/l-boot.html
http://www-106.ibm.com/developerworks/linux/libra
unnecessarily slow bootup caused by lack of parallelism.
i'm making a tivo box and i know that the startup times will be appalling compared to windows.
stay frosty and alert
Your complaints seem to be about GNU projects. They do some strange things. Not all of it is incompetence either. Some of it is politics.
That's why you have to take an active stance in avoiding script kiddie projects like GNOME or KDE. Just say no to crap!
Tested that just now.
Boot time before change: 41 seconds (*)
after Change: 31 seconds
That was a change that took about 15 seconds.
(*) not 30 as I remembered. Well, I've changed some stuff after I last checked.
Assorted stuff I do sometimes: Lemuria.org
Actually, there's been a huge thread on an OpenBSD mailing list with DJB telling people to "do what he says" and the /package, /doc and /service is better, breaking their filesystem hier(7)archy. The result is that the OpenBSD port maintainers have removed all DJB software from the ports tree, and now DJB is now switching to FreeBSD.
I'm a happy djbdns user but I find it to be less scalable (backup name servers for a domain) without some amounts of work to write rsync scripts, etc.
PS: I love UNIX fs hierarchy and do not intend to change it whatever DJB says.