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

21 of 628 comments (clear)

  1. Legacy by HermesHuang · · Score: 2, Interesting

    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.

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

    1. Re:Cool by bninja_penguin · · Score: 2, Interesting

      My XP - a gaming rig, at that - (sic)botts in about 30 seconds.

      That is the thing right there. Your system is a "gaming" rig, and that's probably all you do with it, so you've got it all tweaked and rarely change anything with it. Nothing wrong with that, but, on a "general purpose" machine, or the average XP users machine, I guarantee it slows down to an aching crawl for boot after a few weeks/months of use. This is caused by everything from Quick Books "TSR" bot to default settings in IE that allow every damned search bar/spyware piece of junk to automatically install in the background.

      I work on Windows boxes all day long, and I know this happens. Machines I've built for customers, with nothing but XP loaded will boot in under 20 seconds. Two months later, when they've just purchased a new scanner or what have you, and want me to install it, the boot time of the exact same machine is now over 2 1/2 minutes. They had installed Anti-Virus software, Office XP, a few games, Quick Books, etc., nothing exotic. I checked for viruses, there were none. I ran Spy Bot, and there was 350 (non-cookie) issues found. Even after cleaning, clearing temp files, and defragging, the boot time was still just under two minutes. My Mandrake machines' boot times haven't changed by even 2 seconds in three years. My Mandrake boots from power button on to fully loaded KDE desktop in 40 seconds, and I've only got 256MB RAM in it. The XP box I've been talking about has 1GB.

      No matter what people say, nor what the benchmarks show, Windows XP appears slow, and feels sluggish. Go to the Add/Remove Programs in the control panel. Even with a 2.6Ghz processor with 1GB of RAM, you have to "Please wait while list is being populated." Sure, you can "prove" with benchmarking that XP is faster than 98SE, but my K6-III Win98 machine feels one Hell of alot faster than any XP machine I've worked with.

      So, I guess my point would be, yeah, you are probably right, there's something broken with the parent poster's XP box, but it's probably broken in every other XP box on the planet as well (except for yours.)
      :)

      --
      For those who describe their systems as 'boxen', do you order multiple 'boxen' of corn flakes also?
    2. Re:Cool by zdzichu · · Score: 2, Interesting

      Find following line in your /etc/inittab :

      # Script to run when going multi user.
      rc:2345:wait:/etc/rc.d/rc.M

      and change it into

      # Script to run when going multi user.
      rc:2345:once:/etc/rc.d/rc.M

      Much faster, isn't it?

      --
      :wq
  3. 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!

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

  5. Re:Keep this away from my server! by sweetooth · · Score: 2, Interesting

    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.

  6. Re:Why ? by crotherm · · Score: 2, Interesting

    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
  7. Re:Why ? by the_2nd_coming · · Score: 2, Interesting

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

  9. ya, and... where is it? by dermusikman · · Score: 2, Interesting

    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?

    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 /. right away!!

    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?!

  10. 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.
  11. Init written in Python? Don't think so. by jjackson · · Score: 2, Interesting

    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.

  12. Using Make sounds better than python. by aliensexfiend · · Score: 2, Interesting

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

  13. Re:DBus project page compromised by BobaFett · · Score: 2, Interesting

    They must be checking the Referer because the same link works fine when you come there through the main site.

  14. Re:D-BUS, and NIH by jmac880n · · Score: 2, Interesting

    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.

  15. "Boot Linux faster" at IBMs developerworks by Anonymous Coward · · Score: 1, Interesting
  16. Re:Why change what isn't broken by Fat+Cow · · Score: 2, Interesting

    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
  17. Re:Transparency should be goal #1 by moncyb · · Score: 2, Interesting

    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.

    Not only are people recreating the look-and-feel of Windows but the very things that made us dispise Microsoft and Windows in the first place!

    That's why you have to take an active stance in avoiding script kiddie projects like GNOME or KDE. Just say no to crap!

  18. Re:making or faking? by Tom · · Score: 2, Interesting

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