Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Replacing the Aging Init Procedure on Linux 628

Posted by CmdrTaco from the whats-wrong-with-inittab dept.
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."
This discussion has been archived. No new comments can be posted.

Replacing the Aging Init Procedure on Linux More

Replacing the Aging Init Procedure on Linux

Comments Filter:

  • Keep this away from my server! (Score:3, Insightful)

    by Bryan Ischo ( 893 ) * on Thursday October 02, 2003 @01:35PM (#7115901) Homepage
    Reading this guy's thoughts on replacing init, makes it very clear that this is intended for very tight integration with the Gnome desktop system. It's not a general purpose mechanism built using the thinnest layer with the least dependencies possible (like init is). All you need to run init is a kernel, a filesystem, and for most init scripts, a shell program. This person's SystemServices concept is heavily tied into Gnome and would require a complete Gnome implementation to function properly. On the other hand, most init scripts do seem to be very specific in operation and make many assumptions about the tools available and the locations of files, making them tightly bound to the distribution they are running on as well. But at least init as a service starting program has minimal requirements, even if init script authors choose (typically because they have no other choice due to the lack of standardization of Linux systems) to make their scripts specific to the distribution.

    This makes it unsuitable for the purpose of starting up system services on a Linux system which does not include Gnome. I think that init was designed with very limited requirements and thus runs on every Linux system no matter how it has been customized.

    But that's typically the trade-off in software design: if your software can make more assumptions and be more specific in operation, then often it can be more powerful and integrate better with the specific system it is made to work on. Unfortunately, for something as general and low-level as the service running program, the SystemServices concept seems to specific to be useful for general use.

    Which is not to say that it's a useless project, just don't expect to see it replacing init any time soon.

    • RTFA (Score:5, Insightful)

      by truthsearch ( 249536 ) on Thursday October 02, 2003 @01:41PM (#7115978) Homepage Journal
      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.
      • OK, I apologize if I don't know enough about Python and Gnome to be able to tell what parts of Gnome and what parts of Python this person intends to use. I am not an expert in either Python or Gnome. The author of the article writes:

        Starting a service: ServiceManager, when you tell it "start org.designfu.SomeService" does a check on SomeService's dependencies, loads those first if necessary, and then activates org.designfu.SomeService using normal dbus activation. Ideally this would mean activating the d
        • DBus is something currently under development that is meant to serve as a fairly generic message passing system. There's a link in the Slashdot item.
          • My apologies again. My eyes glazed over a bit when I saw all of the links in the Slashdot article and I didn't follow them all. I read just enough to decide that this init replacement had some pretty serious dependencies on other software, and assumed it was mostly Gnome related. Mea Culpa.

            But certainly SystemServices does have many more dependencies than init, even if none of them are Gnome specific. Python, D-Bus, all of the naming systems and nomenclatures inherent in his description of how services
        • dbus is a freedesktop.org standard for inter-app communication. Its a dependency-free C library with bindings for Python and other languages.
    • Exactly. Here's some more of what he says:

      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

      Items 2 & 3 are the killer. This is clearly a guy who thinks that the only reason to run Linux is to support an X environment, which is absolutely wrong.

      • Re:Keep this away from my server! (Score:5, Insightful)

        by elmegil ( 12001 ) on Thursday October 02, 2003 @01:48PM (#7116068) Homepage Journal
        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.
        • 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.

          Sadly, I've met plenty of SysAdmins who didn't "get" SysV-style init scripts. Particularly the in-duh-vidual who thought that "S100weblogic" would start after "S99local". [sigh] Admittedly, I wouldn't let this person administer an

      • 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.
    • It's not a general purpose mechanism built using the thinnest layer with the least dependencies possible (like init is)
      I completely agree on the dependencies issue, but isn't calling the SysV init mess "thin" a little bit off? Honestly, how many runlevels exept "multi-user", "single-user" and "turned off" do you really need? Do you collect symlinks as a hobby?
  • Dare I ask? I mean, I've never had any problems with the init process on Linux, Solaris, or HP-UX... Was there some problem or inefficiency I didn't know about?

    • Re:Why change what isn't broken (Score:2, Insightful)

      by Anonymous Coward
      Because "old" code is automatically "bad" code, regardless of any other considerations. I know far too many programmers who think this way.

      • Re:Why change what isn't broken (Score:4, Informative)

        by Erwos ( 553607 ) on Thursday October 02, 2003 @05:16PM (#7118449)
        I don't think Seth's reasoning _ever_ got on this.

        The boot process on Linux is slow. It's one of the few things that seems to be the same about every distribution. Compare boot time on a WinXP box with non-essential services turned off to boot time on a Linux box with non-essential services turned off. WinXP boots a lot faster, at least in my experience. Can the current system be improved enough to compete? At least one person is saying no.

        Seth is proposing a new system that would be faster and have daemons "take care of themselves" without the need for tons of complicated scripts. These are valid and appropriate goals. It's not pushing some sort of desktop agenda (the "GNOME is taking over!" conspiracists amuse me, I must say), or forcing you to run X.

        This doesn't "address the server-side", or so some people claim, but I've seen no reason that you couldn't easily direct text output to console exactly like the current init does. Of course he's addressing the X desktop - because that's the far more complicated problem.

        -Erwos

    • Because it can be done (Score:5, Insightful)

      by ultrabot ( 200914 ) on Thursday October 02, 2003 @03:33PM (#7117337)
      This is what is great about Open Source - people can innovate, create new systems, and if they prove to be good, they can be widely deployed. That's how progress happens, and the heart of a developer rejoices on seeing things like this. In the end, superior technology will triumph, and seeing that he is using Python, he is already well on his way :-).

      And as for all of you sticking to the old stuff, because it's good enough: are you sure you are not just getting old? The time I start to whine about progress ("the old way was good enough") will be a sad day indeed. Or perhaps this is the difference between sysadmin-types and programmer-type: sysadmins like to stick to old shell script based system because it's uniquity, while developers see the opportunities of new technologies and have a certain inborn respect for technological superiority.

      Linux will evolve, live with it. If the old system is indeed better, it will be used indefinitely, but unless we try something different, we will never know. Having some distros doing the thing in an alternative way is a good way to hash this out.

      I for one welcome our new freedesktop.org overlords. I'm really liking the direction that Havoc Pennington and other Gnome-related people are taking as far as desktop things go. We need more dynamic & motivated people like them on powerful positions.
    • Why are we replacing all our punch card keypunch stations with these frickin' interactive terminals? The punch cards have always worked fine.

      Why are we replacing perfectly good command line interfaces with GUI's?

      Why are we trying to replace X with something modern?

      Why are most people dumping FVWM95 for KDE or GNOME?

      Why are our filesystems all getting features such as arbitrary metadata attachments on files, and ACL's? (Metadata in filesystems is a feature that could make desktop systems *way*

  • The new init procedure (Score:3, Funny)

    by Anonymous Coward on Thursday October 02, 2003 @01:37PM (#7115938)
    if $OS [] *linux* or $OS [] *nix* then
    repeat
    SCO.account = SCO.account + yourbankaccount
    until bankvault = empty
    end if

  • Legacy (Score:2, Interesting)

    by HermesHuang ( 606596 )
    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.

  • Cool (Score:5, Interesting)

    by mao che minh ( 611166 ) on Thursday October 02, 2003 @01:38PM (#7115942) Journal
    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.

    • Re:Cool (Score:4, Informative)

      by truthsearch ( 249536 ) on Thursday October 02, 2003 @01:45PM (#7116023) Homepage Journal
      He plans on implementing one of the key things which will makes systems bring up the user interface faster: launch only those services required by the system to boot, then launch the desktop (if applicable), then continue loading any "secondary" services. For example, the log rotation script found on some distros doesn't need to run before the interface is launched. I think this has been needed for a long time on the Linux desktop. It's worked that way on Windows for a long time.

    • Re:Cool (Score:3, Insightful)

      by bogie ( 31020 )
      "but if someone comes up with better system that can boot my Linux system as fast as my XP system boots, I'm game."

      I do find it interesting that anyone beside embedded developers care about Linux boot times. I guess dual-booters might need this, but then again booting and dealing with two different OS's on the same machine is always going to involve some headache.

      I mean really how often do you have to reboot your linux box? This isn't the days of Win95 where you had to reboot daily. The most your should e
      • Of course you are missing Option C on why I reboot systems too much (windows, Unix, Linux, whatever)

        When the damned kernel code I am currently working on panics and I have to debug it

        Of course this only applies to about .1% of people doing development - but I hate watching systems boot - it happens WAY too often for me

      • Re:Cool (Score:4, Insightful)

        by sweetooth ( 21075 ) on Thursday October 02, 2003 @01:58PM (#7116200) Homepage
        Some people don't leave their computers on 24/7. They turn them off when they leave the house etc. Hence they are booting their computers once a day probably.

        • Re:Cool (Score:4, Funny)

          by MsGeek ( 162936 ) on Thursday October 02, 2003 @03:03PM (#7116956) Homepage Journal
          People like me who live in earthquake-prone areas turn their computers off when not in use. Much safer for the hard drive.
      • If your actually having to reboot your linux box more than once a month your either playing with too many kernels or have a serious hardware problem.

        Or you're running linux on a laptop. I reboot my linux machine as often as 3 times a day, because that's how often I go from one place to another with my computer. Waiting 25 to 30 seconds for my desktop to come up each time I boot is annoying to say the least.
      • ...or you're using more than one OS on the same machine. I've routinely had as many as four different bootable partitions on my workstation, often running completely different operating systems (Linux, Net/OpenBSD, Win2k, BeOS R5).

        Is it strictly necessary? No. Is it a big part of how I've learned to code for and support all of those systems? Yes. Would I like to shave a minute or two off every Linux boot time? Definitely.

    • XP (Score:5, Interesting)

      by blunte ( 183182 ) on Thursday October 02, 2003 @02:26PM (#7116506)
      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.

    • Re:Cool (Score:3, Interesting)

      by zdzichu ( 100333 )
      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?

  • Why ? (Score:5, Insightful)

    by Anonymous Coward on Thursday October 02, 2003 @01:38PM (#7115949)
    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.

    • Re:Why ? (Score:5, Insightful)

      by Anonymous Coward on Thursday October 02, 2003 @01:41PM (#7115980)

      Remember when everything in /sbin was staticly linked, /bin -> /usr/bin and /usr was a separate filesystem?

      No more.

      The only thing we need still is parallel loading. Methinks a good RC system can do it.

      • Re:Why ? (Score:2, Interesting)

        by crotherm ( 160925 )
        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.

        • Re:Why ? (Score:2, Interesting)

          by the_2nd_coming ( 444906 )
          becasue BASH does not scale well and is dificult to use when needing to expose APIs to an upper layer.

        • Re:Why ? (Score:5, Insightful)

          by __past__ ( 542467 ) on Thursday October 02, 2003 @02:13PM (#7116362)
          All systems come with bash.
          <rant>
          How about "All POSIX-compatible systems come with a bourne-compatible shell"? I don't see any reason why a developer of an init system, which is so not tied to a specific kernel, should restrict himself to a non-standard embrace-and-extend version when he can also follow open standards, and create something more useful to more people instead.
          </rant>

        • it's 2003, not 1997 (Score:3, Insightful)

          by axxackall ( 579006 )
          All systems come with bash. Why not use it? Python is not needed for this.

          I still remember systems where bash scripts did not work as bash was broken or bash accidently was disabled for the user running the scripts. That time (3-5 years ago) there were many flamewars bash-vs-sh. What's happen? Bash is everywhere. Not precisely everywhere, but more systems have bash today.

          I think the evolution of unix-like operating systems (especially Linux ones) is moved far forward enough to begin flamewars python-vs-

    • Re:Why ? (Score:5, Funny)

      by dcgaber ( 473400 ) on Thursday October 02, 2003 @01:52PM (#7116119)
      Sue the base shell? Darl, stop posting as AC!

  • Interpreter FUD (Score:2, Troll)

    by Soong ( 7225 )
    Keep Python interpreters out of my system guts!

    System code should only be written in C!
    • fyi: init scripts are sh/bash (that's why they're called scripts.

      iirc, there was a kernel summit paper about a proper dependency system for init scripts.

  • Please don't replace me. (Score:5, Funny)

    by Anonymous Coward on Thursday October 02, 2003 @01:41PM (#7115979)

    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.
    .
    .
    .
  • The Linux startup process works. Is there any need to muck about with it? On Red Hat et al and Debian, there's the powerful but complicated init.d directory; while Slackware users have a less sophisticated system to contend with.

    And hey, it's not like we have to boot all that often, is it ;-)
    • Not so much broke as just less efficient than it could be. For some, rebooting is a rare occurance, and parallazing the boot process will do little. For developers, its a win-lose. If what you want to retest needs a reboot, then you'd love it. But the parallal execution can make debugging startup a pain.

      Who this really benefits are the people who don't leave their computer on every moment possible. The people who don't like the noise; the people who are concious about their Mean Time between failures; the

  • That's a joke, right? (Score:5, Interesting)

    by Fefe ( 6964 ) on Thursday October 02, 2003 @01:42PM (#7115996) Homepage
    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 [www.fefe.de] 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!

    • Re:That's a joke, right? (Score:5, Informative)

      by be-fan ( 61476 ) on Thursday October 02, 2003 @01:54PM (#7116139)
      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.

      • Re:That's a joke, right? (Score:3, Informative)

        by Fefe ( 6964 )
        Oh yes it is. When I log in a user with bash as shell, you can _feel_ the delay while bash and the dynamic libraries of it are loaded. Yes, even on my Athlon XP. Why? Because my init system loads neither glibc nor bash.

        KDE is only faster than 2.x if you disable all the new eye candy that is now available, like translucent menus and the flashy theme stuff. Yes, that's comparing apples and oranges, but it's also comparing the default desktops. Keramik is themed with large pixmaps, the kde 2.x default l

  • Doh. (Score:5, Interesting)

    by jensend ( 71114 ) on Thursday October 02, 2003 @01:43PM (#7116005)
    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.

    • Re:Doh. (Score:5, Insightful)

      by pmz ( 462998 ) on Thursday October 02, 2003 @02:21PM (#7116443) Homepage
      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.

      This still won't stop the GNU folks from fucking it up, though, because more dependencies ensure GPL-lock-in (you didn't think it could happen to us, too, did you?). This isn't a troll, but a very serious issue, where lots of software is becoming very GNU-specific rather than UNIX-specific (I hope everyone can see this distinction).

      • Re:Doh. (Score:3, Funny)

        by AME ( 49105 )
        GNU-specific rather than UNIX-specific (I hope everyone can see this distinction)

        Well, if GNU is not Unix, isn't the distinction explicit?

      • Re:Doh. (Score:4, Insightful)

        by groomed ( 202061 ) on Thursday October 02, 2003 @06:38PM (#7119262)
        GNU software is better, cheaper and freer than its UNIX counterparts. It's no wonder that GNU is finishing off the lame and deaf UNIX moloch. Besides, that has always been the project's goal. It's not like that's a secret or anything.

        As for "lock-in", well, if GNU's the prison, I don't mind being a criminal.

  • login (Score:2, Funny)

    by panxerox ( 575545 )
    for god's sake make it so we dont have to log in each time we turn it on.

    • Already done (Score:2, Offtopic)

      by Tony ( 765 )
      Uhm....

      This feature has been available for a long time. If you use gdm, run gdmconfig as root, and in the "general" tab, check the box labeled "Login a user automatically on first bootup", and select a username from the dropdown box.

      I'm sure kdm has similar features.
    • I don't know if you're a troll, just trying to be funny, or if you're serious, but there's nothing in linux forcing you to log in every time you boot beyond some simple configuration. It certainly isn't required by init.

  • HAL?? (Score:3, Insightful)

    by heh2k ( 84254 ) on Thursday October 02, 2003 @01:47PM (#7116054) Homepage
    why would you need it on nix*? devices are standardized. eg, except for a few ioctl quirks, ide and scsi devices are the same, from userspace. usb devices often look like serial char devs (pda cradles) or blk devs (cameras).

  • Another Gentoo feature (Score:5, Informative)

    by Otter ( 3800 ) on Thursday October 02, 2003 @01:49PM (#7116073) Journal
    Gentoo has a number of great modifications over traditional Linux distributions that don't get nearly as much hype as the nebulous performance increases from building everything from source.

    The relevant one here is the management of services -- far easier than anything similar I've ever dealt with in the Unix world. I realize that 1) this proposed replacement goes beyond what the Gentoo system manages and 2) real sysadmins running real servers aren't going to leave the existing system any time soon, but for desktop users today, it's a great advance that doesn't get the credit it deserves.

  • Not very *nix-ish (Score:4, Insightful)

    by MobyDisk ( 75490 ) on Thursday October 02, 2003 @01:50PM (#7116084) Homepage
    His approach isn't very *nix-ish, it is very Windows-ish. It assumes you have a GUI. It relies on a large complex framework of interfaces. It assumes you have Python scripting. This may work very well for many desktop distros, but it can't become some great unifying thing like he wants, since he chose dependencies that are not the least common denominator. I believe that his goals can all be achieved with minor changes to the existing init system, rather than a megalithic rewrite.

    This approach sounds like he is trying to push some specific technologies he is interested in, and so he decided a new init system that uses them would be a nice PR way to push them.

    • Re:Not very *nix-ish (Score:5, Informative)

      by J. J. Ramsey ( 658 ) on Thursday October 02, 2003 @02:08PM (#7116297) Homepage
      "His approach isn't very *nix-ish, it is very Windows-ish. It assumes you have a GUI."

      Please read the article again, especially the part where Seth Nickell wrote "I *will* provide a way to boot into a "stripped down console mode" aka "single" for system recovery and backup, and a regular non-graphical boot for servers."

      From what I can tell, SystemServices in and of itself only depends on D-BUS and libc. There are Python bindings for D-BUS, so that may make it easy to write a script for SystemServices using Python, but that's the extent of Python's relationship to SystemServices.

    • Re:Not very *nix-ish (Score:5, Informative)

      by nvrrobx ( 71970 ) on Thursday October 02, 2003 @03:10PM (#7117063) Homepage
      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)

  • Keep It Simple Stupid (Score:4, Insightful)

    by yancey ( 136972 ) on Thursday October 02, 2003 @01:53PM (#7116131)
    One of the great strengths of unix-like operating systems and the thing that makes them easy to port from one platform to another is that the core system components are very simple, not based on some relatively huge and complex thing like Python.

  • D-BUS, and NIH (Score:5, Insightful)

    by avdi ( 66548 ) on Thursday October 02, 2003 @01:54PM (#7116136) Homepage
    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.

    • Re:D-BUS, and NIH (Score:3, Insightful)

      by Vellmont ( 569020 )
      I agree with you, but I don't think complicated is a very descriptive word. Lots of things are complicated, but you don't always need to understand the complicated stuff to do most of what you have to do.

      Ideally a system should follow the 80/20 rule. That is you can do 80% of what most people want to do by only learning 20% of the system. SQL is a good example of this. You can learn only a little bit of SQL and immediatlely put it to use. SQL only gets complicated when you need to do that last 20%.

      In

  • Reinventing the wheel? That's the Linux way!! (Score:3, Insightful)

    by 44BSD ( 701309 ) on Thursday October 02, 2003 @01:54PM (#7116142)
    This is a dumb idea.

    It is antithetical to the UNIX design philosophy, and it betrays an ignorance of history.

    IBM tried to "improve" the init sequence in AIX, which was a godawful mess. The concept has not improved over time.

    • Yes this is a horrible perversion and deviation of UNIX.

      Also, the so called disadvantages of init are void. It looks like he does not understand what init is.

      Init is very simple: the kernel calls a program called "init" as soon as the kernel-part of booting is ready.

      The "normal" init (there is a SYSV and a BSD variant, the SYSV variant being somewhat more complex) only reads a config file /etc/inittab to see what further program it should call. For each runlevel there is such a program.

      Usually these are

  • Transparency should be goal #1 (Score:5, Insightful)

    by GeoGreg ( 631708 ) on Thursday October 02, 2003 @01:55PM (#7116147)

    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:

    1. Easy to determine where the problem is.
    2. Easy to fix using minimal tools available in single-user mode (i.e., vi).

    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.

  • Hmm (Score:2, Insightful)

    by stratjakt ( 596332 )
    I know it's people perogative to write whatever they feel like writing, but I cant help wishing that desktop linux had some sort of omnipotent boss who could order the dev community around, thusly: "Quit wasting your time on that until cut and paste works, and all the desktop apps look like something other than shit!"

    I mean, thats how OSX and Windows got where they are.

  • Other init alternative (Score:5, Interesting)

    by elFarto the 2nd ( 709099 ) on Thursday October 02, 2003 @02:03PM (#7116242)
    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

  • Wow .. did someone actually read the paper ? (Score:5, Insightful)

    by BESTouff ( 531293 ) on Thursday October 02, 2003 @02:14PM (#7116377)
    As always on /. there are loads of uninformed comments just based on the title :)

    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.

  • Replacing the Aging "Wheel" Device (Score:5, Insightful)

    by avdi ( 66548 ) on Thursday October 02, 2003 @02:21PM (#7116449) Homepage
    Apparently freedesktop.org has devolved from a desktop standards initiative to a home of pointless wheel-reinvention. Here's a list of the projects listed above, followed by their existing, more mature counterparts:

    Init Replacements: simpleinit [csiro.au], minit [www.fefe.de], jinit [fremlin.de], runit, daemontools [cr.yp.to], serel [fastboot.org]. Progeny [progeny.org] also has their own system based on Gooch's need/provide architecture.

    D-BUS: CORBA [corba.org]

    HAL: Discover [progeny.com]

    • Response from SystemServices author (Score:5, Insightful)

      by nullity ( 115966 ) on Thursday October 02, 2003 @03:23PM (#7117225) Homepage

      SystemServices: Hardly wheel re-invention. If you read the linked-to article [osnews.com] you'll find that none of the listed "init replacements" address any of my four major goals. They addressed their own goals, which are nice ones I'm sure, but not things that the desktop needs. In fact, the only thing they really add over init that's interesting to me is a dependency system + parallelization. And RH's internal work on init scripts has suggested this results in only small improvements (neighborhood of 30% I believe) in boot time... which is better but not dramatic. Dependency systems are pretty trivial to implement and a dime a dozen, in any case.

      DBus: yeah, its a lot like CORBA. Its even more like KDE's DCOP. In fact, its a lot like DCOP. You could even think of it as a major iteration of DCOP. So look, GNOME has been using CORBA for IPC for several years and its still something people avoid using whenever possible. KDE used CORBA for a while, and even with the comparatively nice CORBA/C++ bindings found KDE devs avoided it when possible. CORBA is a freaking PITA to use for lightweight desktop-style stuff. DCOP was the solution (its a good solution, GNOME should have done this ages ago): make it easy enough to use that developers will actually readily communicate over DCOP. Communication protocols have no inherent value on their own. They acquire value when there's things to talk to. Developers won't use the API unless its simple. You can write very simple comm layers for KDE and GNOME around DBUS. Even if we GNOME folk wanted to use CORBA (we don't), KDE wouldn't, and a requirement for DBus being truly useful is that KDE+GNOME have to be willing to use it. End of story.

      HAL: I'm not really familiar with discover, so I'm not going to shoot my mouth off (much *grin*). From ransacking the web page you linked to, it doesn't look like discover really supports the sort of "central daemon with notification signals" model that we need to provide good hardware support on the desktop side. Without that... its sort of useless to us. It looks a lot like Kudzu, which is a good thing (and trust me, Havoc who proposed HAL in the first place knows about Kudzu, and probably discover) but it simply isn't what those of us who are in the ditches writing this desktop code need.

      Moral of the story: a superficially similar "solution" does not necessarily address the issues that we as desktop developers face. We propose these things because we have concrete problems to solve. Sometimes the problems are not obvious until you try to do something and end up butting into them. We're lazy people, just like anyone, and we don't like :-)

      • Regarding D-BUS: I've seen nothing so far that explains why D-BUS couldn't have been implemented on top of CORBA. There's no reason for a lightweight desktop-integration bus to specify low-level crap like the protocol used, bit-ordering in packets, etc. There's no need for any coupling at all between passing messages between apps and how those messages are passed. Marshalling, dynamic service repositories, naming services, protocol abstraction, QoS issues - it's all been solved already. Why invent yet
        • I'm not as knowledgable in this area as the DBus developers, so I can't tell you all their reasons.

          So one thing is that CORBA tends to take a lot of memory, at least relative to DBus and DCOP. A lot of developers will not add a small feature (and lots of lost small features is a big loss) if it means linking with a big library.

          For this technical reason, and probably for other really good ones too, but also probably political/historical... I don't think a CORBA based solution would fly with KDE. A system D

  • simpleinit (Score:5, Informative)

    by Sharkeys-Day ( 25335 ) on Thursday October 02, 2003 @02:31PM (#7116556) Homepage
    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. [csiro.au]

    Dependancies are a big improvement over runlevels, although you could implement runlevels on top of it.

  • Been done before (Score:4, Informative)

    by ofgencow ( 51564 ) on Thursday October 02, 2003 @03:01PM (#7116925)
    ETLinux [etlinux.org] replaced init several years ago with an entirely scripted version. [etlinux.org] Different scripting engine (Tcl instead of Python) and for different reasons (keeping an embedded Linux kernel tiny.)

    Making this happen was that the ETLinux folks ... added Tcl equivalents for some common syscalls and services: sys_dup, sys_exec, sys_fork, sys_kill, sys_nice, sys_pipe, sys_reboot, sys_sync, sys_wait, sys_chmod, sys_umask, sys_mknod, inp, inw, outp, outw, setleds, mount, umount, uudecode, uuencode, time, ifconfig, route, udp. The introduction of these commands allowed the rewrite of the initialization scripts in pure Tcl, avoiding the inclusion of large binary programs.

    More on ETLinux architecture here. [etlinux.org]

  • This is really simple. (Score:5, Informative)

    by Anonymous Coward on Thursday October 02, 2003 @03:25PM (#7117245)
    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
    • And you're completely ignoring the BASIC FOUNDATION of why this is USEFUL: other SERVICES only have to WAIT on those they DEPEND on. Does loading X require a working DHCP lease? God, I hope not! So what happens is, that fundamental property of modern operating systems, "multitasking" switches between services starting in parallel.

      For the record, right now my init system waits for a dhcp lease before making progress. In essence, everything is started up as if it depends on everything before it. In reality,

  • Why this should not be python (Score:5, Insightful)

    by ajs ( 35943 ) <[ajs] [at] [ajs.com]> on Thursday October 02, 2003 @04:07PM (#7117731) Homepage Journal
    Ok, so I'm not the best person to say this because anyone who looks for my publishing credits will immediately realize that I'm a "Perl guy" and thus, I must hate Python (I'm not really a Perl guy, and I don't hate Python, but that's beside the point). I'll go on anyway because this is important, and folks who don't do sysadmin for a living may not have had to think about this.

    init itself is so lightweight and small that it rarely, if ever, fails. This is a good thing, since it's init's job to start a ton of very heavy-weight services.

    That said, I see the logic in bloating init with some of the features that are almost always implemented in a distribution built around it. For example, it would be nice to see init perform some service tracking such that it could be told directly to kill a service, and it could do so.

    Keep in mind that every time you increase the size of init, you remove a class of systems that can now no longer use it because of it's footprint. This matters a lot for some kinds of embeded systems that have just enough brains (that is, RAM and installed libraries/software) that it makes sense to have init today.

    You certainly could not achieve this minimal-growth by re-coding init in Python, Java, Perl, Lisp or any other high-level language. That's not a slam against high-level languages, it's a simple fact of life that their flexibility comes with costs.

    As for the shell-script init-scripts, I certainly feel that all of that should be moved out of init's domain. Each application should have a control program (like apachectl) which knows how to start it, stop it, get status, reload configs, etc. That program can be written in C for speed; a high-level, general purpose language for ease of maintenance; or even in shell. But, the point is that that should not be a constraint of init.

    init, might well provide a library and/or command-line tools to make writing those controlers easier and more modular, but I don't think there should be any REQUIREMENT that your program know anything more than the calling conventions of an "init controler". The more constraints you heap on, the less software is going to ship ready to integrate with your init system, and that way lies far too much integration work to create a workable OS (and thus MORE variants between distributions, not less).

    Once you've done all of that, THEN you can think about the high-level glue so that things like a desktop integrate better.

  • Mac OS X, NetBSD rc.d, rcNG, and so on (Score:5, Informative)

    by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Thursday October 02, 2003 @07:57PM (#7119854)

    As someone else noted (in an article with a link done as text, not as an , and with an extra blank in it), Mac OS X has a possibly-interesting scheme for starting and stopping system services. Here's the section on System Initialization [apple.com] in the Mac OS X online documentation; in particular, look at the Startup Items stuff [apple.com].

    It's a dependency-based scheme, like at least some of the other proposed system services mechanisms; see the section on adding your own startup items [apple.com].

    Note also that Boring Old Init [apple.com] isn't itself changed; /etc/rc runs SystemStarter [apple.com] as its last act, and that starts up the system services. SystemStarter can also be used as a command to start, stop, or restart services, so this isn't just a system startup mechanism.

    NetBSD 1.5 and later have a new rc-based system for controlling services [netbsd.org]; it's also dependency-based. FreeBSD 5.x has rcNG [freebsd.org], which is derived from the NetBSD scheme.

    (Note that all of those systems have a BSD-style init, and thus don't have run levels.)

    Those schemes don't address one of Seth's complaints, however - according to his description in his blog [gnome.org], he doesn't like having shell script wrappers doing the configuration, he wants it done in the service's process itself:

    In other news, reshaped SystemServices around the futile, idealistic goal of having daemons contribute the servicesinstead of silly little shell script wrappers in the future. Ever poked through RH's /etc/init.d/ scripts? Its absurd... they do so much stuff in there that should be included in the bloomin' C code. If you need a check for something, just have the program itself do it.... But of course, these programs were designed to be run with lots of magic brittle flags rather than running and situating themselves intelligently.

    (I express no opinion on this one way or the other; if you like or don't like the idea, send bouquets or brickbats to him, not me.)

    Note also that it appears that he is not designing something just for desktops - in particular, he says:

    The boot process: So first the kernel loads itself, and calls ServiceManager (instead of "init"). The ServiceManager starts the DBus service manually,

    and checks to see if it should be doing a graphical bootup. If it should be, it starts the GraphicalLogin service (which of course may have dependencies to start first).

    Now, whether the kernel should start ServiceManager directly, or whether it should continue to run init and have ServiceManager started from an rc file, is another issue; I'm not sure that there's a compelling argument to eliminate init other than to discourage people from continuing to use the current rc script scheme (which might be Seth's motivation for running ServiceManager as process 1 - he might want to discourage rc script tweaking).

    Perhaps one of the reasons why people thought of ServiceManager as being purely for desktop systems is that they thought that, as D-BUS is somewhat associated with freedesktop.

  • Please don't fuck up init! (Score:3, Insightful)

    by swordgeek ( 112599 ) on Thursday October 02, 2003 @10:25PM (#7120766) Journal
    inetd got buggered until it became xinetd. cron was forced to run side-by-side with the abortion known as anacron. In its defense, vim at least can be made to behave like vi, entirely UNLIKE bash, the sh-incompatabile sh replacement.

    To the Linux developers: QUIT BREAKING THINGS from a "unix-like" perspective. If Linux is going to be an entirely unrelated OS, then fine. If it's going to strive to behave similarly, then quit adding features that break expected behaviour, especially for the reason of being 'really cool.'

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close