Replacing init with Upstart (Linux.com) [LWN.net]

Replacing init with Upstart (Linux.com)

Posted Oct 4, 2006 20:06 UTC (Wed) by bronson (subscriber, #4806) [Link]

Sort of like how standardized horse-drawn carts outweigh the intrinsic usefulness of the automobile? :) Besides, upstart appears to be backward-compatible with SysV init scripts. It's not an either/or choice.

Replacing init with Upstart (Linux.com)

Posted Oct 4, 2006 20:15 UTC (Wed) by pphaneuf (subscriber, #23480) [Link]

And for similar reason, I'm a bit worried about not using Apple's launchd, which isn't half-bad itself, and fracturing the issue even more than needed.

Replacing init with Upstart (Linux.com)

Posted Oct 4, 2006 20:40 UTC (Wed) by ajross (subscriber, #4563) [Link]

For what it's worth, I've read through the docs on both, and am completely sold on upstart. Launchd has a nice feature set (it does timer/cron facilities, which upstart plans to include, and inetd stuff, which it apparently does not). But the configuration complexity is kind of a mess. Take a look at Apple's page "Getting Started" page:

http://developer.apple.com/macosx/launchd.html

Especially, scroll down to the part where they show you the equivalent XML (!) for a simple xinetd entry. This is technological progress? Even the XML usage itself is dumb. Where upstart's configuration syntax would write:

  exec /usr/libexec/rshd

The equivalent launchd syntax is (I'm not making this up):

  <key>ProgramArguments</key>
  <array>
   <string>/usr/libexec/rshd</string>
  </array>

I'm not normally a zealot about things like this. But then, I'm not normally as impressed by the sheer sanity of design as I am with upstart either. As I wrote earlier, Bravo! Here's hoping that the other big distros move to it as soon as possible.

Replacing init with Upstart (Linux.com)

Posted Oct 4, 2006 21:00 UTC (Wed) by pphaneuf (subscriber, #23480) [Link]

From the page you linked to, there was an example of an xinetd entry:

service shell
{
    disable         = yes
    socket_type     = stream
    wait            = no
    user            = root
    server          = /usr/libexec/rshd
    groups          = yes
    flags           = REUSE
}

Then they give an appalling chunk of XML, that is apparently equivalent. I don't know why Apple sticks to that awful, awful XML syntax for property lists, but there's also the classic syntax, which was (is still?) used in GNOME and is available as a simple and easy to use library. The syntax is non-awful enough:

{
    Disabled = 1; 
    InitGroups = 1; 
    Label = "com.apple.rshd"; 
    ProgramArguments = ("/usr/libexec/rshd"); 
    Sockets = {Listeners = {SockServiceName = shell; }; }; 
    inetdCompatibility = {Wait = 0; }; 
}

Note that some of thse are compatibility, I'm just lifting their example right off (I piped it through their very own "pl" utility, actually).

Now, I could bear to use that...

Replacing init with Upstart (Linux.com)

Posted Oct 4, 2006 21:50 UTC (Wed) by ajross (subscriber, #4563) [Link]

Heh, you learn something new every day: http://en.wikipedia.org/wiki/Plist tells me that this is actually a standard metadata format. Which excuses (somewhat) a lot of the usability brain damage, although even with the deprecated non-XML syntax, the editability is still not what you would see from a custom designed format.

But it also points out the mildly uncomfortable problem that pid number 1 on a Mac is apparently linking against parsers for not one but two moderately elaborate metadata formats, plus all the framework code that they require. My sense of design aesthetics still hands this round to upstart, sorry.

Replacing init with Upstart (Linux.com)

Posted Oct 5, 2006 4:22 UTC (Thu) by drag (subscriber, #31333) [Link]

Bah. Screw Launchd and Apple. ;-)

Linux devs already have something better going on with Upstart.

Same thing happenned with Redevous/Bonjuer VS Avahi. Avahi is more capable by a long shot. http://avahi.org/

Now the problem happens with integrating other services and such into Avahi. This is another example of the benifits of Apple having tight control over their environment. If they want everything to work with zeroconfig stuff, they just tell the developers to make it happen. With Linux everything is consenses. Much slower, but often has superior results.

Replacing init with Upstart (Linux.com)

Posted Oct 5, 2006 8:34 UTC (Thu) by pphaneuf (subscriber, #23480) [Link]

Editability of the classic property list format isn't bad at all (it reminds me of Perl, while that might be a downside for many, I like the familiarity), actually, having done it a large number of times (Window Maker uses it). On my Linux system, I have /usr/lib/libPropList.so.0.2.2, 46K in size and depending only on libc.

On a technical level, I like Upstart, myself, but I like an earlier commented posted, I worry about fracturing things, but still, recognizing that there is progress to be made, and seeing that the highest volume Unix vendor in the world has made the step ahead with something at least half-way decent, with a reasonable enough license (the Apache 2.0 license, if I'm not mistaken, compare with xinetd's, Vixie cron's, or, well, Apache's license, those packages being well-accepted by the community).

Just saying that it might be a reasonable compromise between innovation and not breaking away too much...

Replacing init with Upstart (Linux.com)

Posted Oct 5, 2006 13:03 UTC (Thu) by madscientist (subscriber, #16861) [Link]

I really can't understand what benefit we gain by adopting launchd. What packages out there for Linux use launchd syntax or require launchd? None, as far as I'm aware. So, what exactly are we "breaking away" _from_? Not much, as far as I can tell. What "fracturing" are we referring to?

Obviously, launchd already exists to some extent (but presumably some work still needs to be done to get it running well on Linux) and it does have a development team (and money) behind it. On the other hand, Apple has had a spotty relationship with F/OSS in the past.

But on the gripping hand, if launchd doesn't do everything we want (doesn't handle pluggable devices as well) I fail to see any advantage in adopting it: that would involve making massive changes to the system init process to get to a partial solution. If you're going to make those kinds of massive changes you might as well change to something that solves the WHOLE problem (or at least has the ability to do so).

And, while we might be concerned about "NIH" propagation, the fact is that Upstart is already done and available and will ship in a major distribution by the end of October... so I really can't see _any_ upside in going back to choose launchd over Upstart.

Replacing init with Upstart (Linux.com)

Posted Oct 5, 2006 15:27 UTC (Thu) by pphaneuf (subscriber, #23480) [Link]

We'll be breaking away from classic "init". Apple already did, a rather gutsy move, but I guess they can manage to pull these kinds of things off. But you can't pull them off too often, otherwise you end up with Unix in the 80's and 90's, things all over the place. Linux brought back things together, I'm not too keen on going back to the way things were...

launchd not only exists, but has been actually deployed for about a year and a half. When the commit to Upstart was done, it had been in use on hundreds of thousands, if not millions, of machines for about a year. And it has a non-crazy license, which seems to be more and more common with Apple (thankfully!). When it comes to pluggable devices, I'd say that if we supported pluggable devices as well as Mac OS X, we'd probably would be doing okay. It's already almost done now, and I've mentioned these things a few months ago, when it was barely started. I worried back then, and I still do now.

Replacing init with Upstart (Linux.com)

Posted Oct 6, 2006 18:31 UTC (Fri) by dododge (subscriber, #2870) [Link]

Editability of the classic property list format isn't bad at all

Well it is and it isn't. An issue with Apple's plist XML is that it's actually poorly designed for being XML. It throws all of the keys and values together in a big pile and relies on the order of the elements to associate them with each other:

  <dict>
    <key>key1</key>
    ...value1...
    <key>key2</key>
    ...value2...
  </dict>

You can edit this by hand easily enough, and of course use programs and libraries that are specifically designed around the plist format. But it's very difficult to process and transform the data meaningfully with generic XML tools such as xslt because there's no real XML-level binding between the keys and values. Any number of slight changes to the format would solve this, for example:

  <dict>
    <item key="key1">...value1...</item>
    <item key="key2">...value2...</item>
  </dict>

At this point the "bad" plist design is probably way too ingrained to fix it. What you end up with is a format that has all of the bad properties of XML but not so many of the good ones.

Replacing init with Upstart (Linux.com)

Posted Oct 6, 2006 19:13 UTC (Fri) by pphaneuf (subscriber, #23480) [Link]

I was referring to the "classic" property list format, not the new XML one. I don't care for the XML one at all, since I'm not too fond of XML in general, and as you pointed out, they didn't do the best job ever of coming up with a decent DTD.

Replacing init with Upstart (Linux.com)

Posted Oct 4, 2006 22:58 UTC (Wed) by rvfh (subscriber, #31018) [Link]

You mean launchd does not replace inetd I presume, because upstart does plan to replace *inetd.

Replacing init with Upstart (Linux.com)

Posted Oct 5, 2006 8:37 UTC (Thu) by pphaneuf (subscriber, #23480) [Link]

launchd does cover inetd (Mac OS X was using xinetd, they are incrementally moving over to launchd).

I don't know what he was referring to.

Replacing init with Upstart (Linux.com)

Posted Oct 4, 2006 20:39 UTC (Wed) by AJWM (subscriber, #15888) [Link]

> having a standard like init across Unix most variants outweighs the intrinsic usefulness of this tool

I think you may be overstating how "standard" it is. There are plenty of differences in init between Unix variants, and I'm not just talking about between the BSD flavors vs Sys V flavors.