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."

4 of 628 comments (clear)

  1. Re:That's a joke, right? by be-fan · · Score: 5, Informative

    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...
  2. simpleinit by Sharkeys-Day · · Score: 5, Informative

    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.

  3. Re:Not very *nix-ish by nvrrobx · · Score: 5, Informative

    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)

  4. This is really simple. by Anonymous Coward · · Score: 5, Informative

    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