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

6 of 628 comments (clear)

  1. Cool by mao+che+minh · · Score: 4, Interesting
    That's the strength of open source development: every little component has the potential of being made more efficient at any given time by any given party of developers.

    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.

  2. That's a joke, right? by Fefe · · Score: 5, Interesting

    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!

  3. Doh. by jensend · · Score: 5, Interesting

    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.

  4. Other init alternative by elFarto+the+2nd · · Score: 5, Interesting

    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

  5. XP by blunte · · Score: 4, Interesting

    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.
  6. Re:Keep this away from my server! by oohp · · Score: 3, Interesting

    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.