Upstart Now Available In Debian Unstable

[AdamW]

I think you are forgetting about OpenRC, which many distributions use. OpenRC is designed to run on top of any init system to provide proper dependency management and other things, such as cgroups (Linux-only). As a consequence, the use of sysvinit does not imply that you are using sysvinit scripts.

I honestly don't see how this paragraph has anything at all to do with the paragraph you quoted, which was about socket activation.

Google Chrome OS, RHEL6, and Ubuntu and their derivatives use Upstart. RedHat used Upstart in Fedora until they decided to start from scratch instead of trying to work with Canonical on improvements.

What prevented Redhat from implementing this in Upstart?

To simplify massively, the systemd and upstart developers could not agree on a design, and so could not work on the same project. This is touched upon in http://0pointer.de/blog/projects/systemd.html "On Upstart". It's probably also significant that RH staff are in general not allowed by corporate policy to sign the Ubuntu CLA as our legal department is not happy with it.

[ryao]

I honestly don't see how this paragraph has anything at all to do with the paragraph you quoted, which was about socket activation.

OpenRC was designed to plug into an existing init system. When it does this, that init system will handle basic things like starting OpenRC and setting up terminals. Any init system will suffice and sysvinit is perfect for this on Linux because it provides the basics that OpenRC expects and nothing more. OpenRC provides the rest. You cited upstart and systemd as having new capabilities that systems using sysvinit lack, but OpenRC is special in that it can provide many of those capabilities to systems using sysvinit.

There is a nice feature comparison between OpenRC, Upstart, Systemd and sysvinit in the OpenRC Wikipedia article:

http://en.wikipedia.org/wiki/OpenRC

Your question suggests that you have never examined OpenRC. I highly recommend taking a look at it.

To simplify massively, the systemd and upstart developers could not agree on a design, and so could not work on the same project. This is touched upon in http://0pointer.de/blog/projects/systemd.html "On Upstart". It's probably also significant that RH staff are in general not allowed by corporate policy to sign the Ubuntu CLA as our legal department is not happy with it.

How does the Ubuntu CLA differ from copyright assignment to the FSF?

[AdamW]

OpenRC was designed to plug into an existing init system. When it does this, that init system will handle basic things like starting OpenRC and setting up terminals. Any init system will suffice and sysvinit is perfect for this on Linux because it provides the basics that OpenRC expects and nothing more. OpenRC provides the rest. You cited upstart and systemd as having new capabilities that systems using sysvinit lack, but OpenRC is special in that it can provide many of those capabilities to systems using sysvinit.

Okay. Fine. I still don't see how that fits in context.

It's an interesting design, sure. I'm not sure what it wins you in practice, though, because apps can and often do ship both sysv and systemd-native/upstart-native init scripts. What's the practical difference between shipping an internally-complete sysv script along with an internally-complete upstart/systemd-native script, and shipping an internally-complete sysv script along with a not-internally-complete OpenRC script that builds on the sysv script?

Remember in context we were talking about socket activation, so far as I can tell, OpenRC has no capabilities for socket activation anyway.

There is a nice feature comparison between OpenRC, Upstart, Systemd and sysvinit in the OpenRC Wikipedia article:

http://en.wikipedia.org/wiki/OpenRC

...which, according to the talk page, appears to have been primarily written by someone with an agenda to promote OpenRC. I give all such stuff - including Lennart's similar table for the purpose of pimping systemd at http://0pointer.de/blog/projects/why.html - approximately the same weight, i.e., very little. But at least Lennart put his table on his blog and acknowledged that he was likely to be biased, while in this case the table was published on what is supposed to be a neutral site with no acknowledgement of the author's bias.

Your question suggests that you have never examined OpenRC. I highly recommend taking a look at it.

I haven't looked at it in any detail, no, because it just doesn't seem significant enough. My evaluation of the meta-discussion on init daemons is that OpenRC has no chance of adoption outside its current niche, so I haven't bothered using any of my finite time to look into it much.

How does the Ubuntu CLA differ from copyright assignment to the FSF?

I am not a lawyer and not interested in going into any detail on that whole thicket. There are plenty of posts around the blogosphere if you want to get into it. I just noted it as a fact of life: my personal opinion or yours is irrelevant to the fact that RH devs in general can't contribute to projects that require signing of the Ubuntu CLA. Note that systemd does not require any kind of copyright assignment or agreement for contribution, so far as I know.

[ryao]

...which, according to the talk page, appears to have been primarily written by someone with an agenda to promote OpenRC. I give all such stuff - including Lennart's similar table for the purpose of pimping systemd at http://0pointer.de/blog/projects/why.html - approximately the same weight, i.e., very little. But at least Lennart put his table on his blog and acknowledged that he was likely to be biased, while in this case the table was published on what is supposed to be a neutral site with no acknowledgement of the author's bias.

The comparison could use more information, but I would not consider it to be written in favor of OpenRC. It shows outstanding issues that need to be resolved. On the other hand, Lennart's comparison makes no mention of such things, takes credit for things in udev, such as "Automount handling" and ignores things that are handled on systems using alternative systems , such as "Swap handling". There are also some fairly vague bullet points like "XDG_RUNTIME_DIR Support" and "Built-in kexec support". I have no idea what "XDG_RUNTIME_DIR Support" means and kexec is a tool that needs no scripts. I often run it by hand when testing kernel modifications.

I haven't looked at it in any detail, no, because it just doesn't seem significant enough. My evaluation of the meta-discussion on init daemons is that OpenRC has no chance of adoption outside its current niche, so I haven't bothered using any of my finite time to look into it much.

OpenRC is not an init daemon. It is an RC system that relies on an external init daemon. In theory, it can run on top of systemd.

With that said, systemd is probably the worst choice possible for an OpenRC init daemon on Linux. systemd has the largest quantity of code that would be useless for anything other than introducing bugs and regressions. sysvinit is the best in this regard while upstart is somewhere in-between the two.

[kigurai]

With that said, systemd is probably the worst choice possible for an OpenRC init daemon on Linux. systemd has the largest quantity of code that would be useless for anything other than introducing bugs and regressions. sysvinit is the best in this regard while upstart is somewhere in-between the two.

If sysvinit is the only really good choice to couple with OpenRC, why would I want that instead of just running sysvinit directly? Genuine question, because I haven't used gentoo in a long time, and never heard of OpenRC. But to me, it sounds a bit hypocritical to bash systemd for "unused code" while championing an init system that sits on top of another init system...
Also, the "more code = more bugs" is a rule of thumb, not some kind of law. As you are probably aware there are some really stable pieces of hardware with milions of lines of code (Linux kernel, to take one relevant example), and lots of very small applications that are riddled with bugs.
If systemd crashed substantially more than sysvinit I suppose you could have a point. I have not seen anything that hints about that.

[j-kidd]

If sysvinit is the only really good choice to couple with OpenRC, why would I want that instead of just running sysvinit directly? Genuine question, because I haven't used gentoo in a long time, and never heard of OpenRC.

Just a Gentoo user here. With OpenRC, first and foremost, I am free from the horror of the 0 1 2 3 4 5 6 runlevels. Also, I found the syntax provided by OpenRC (need, use, provide, before, after) to be very nice.

Let's use a software xxx that can use different database backends as an example. On Gentoo, I can just put

use mysql postgresql

in the /etc/init.d/xxx script, and then never have to bother whether the deployed instance uses MySQL or PostgreSQL. Let's say my deployed instance uses PostgreSQL, while I also have MySQL installed on the same machine for testing only and thus doesn't want it to autostart, then I can just run:

rc-update add postgresql-9.2 default
rc-update add xxx default

and it will just work. As I mostly just use Gentoo, I am not sure how to do the same with sysvinit, upstart, or systemd.

[funkSTAR]

How does the Ubuntu CLA differ from copyright assignment to the FSF?

FSF is a non-commercial org caring deeply about software freedom.They want CA to maximize legal protection for the licensed code. Canonical is just a RH competitor seeking an advantage. They dont want CA to keep the code open and protect it. Canonical want the copyrigtht so they can do whatever skunkwork they need. This includes distrobuting closed source editions. And yes Canonical KNOWS the CAing will keep RH out of the loop. They are causing fragmentation without any regrets.

Upstart: CA, low canonical investment, no community.
Systemd: no CA, high RH investment, much larger community.

Systemd is already way ahead based on technical merits. Based on metrics like keeping the source code on free license and building communities systemd is your pick.

So in order to follow your PurgePoettering agenda you have to accept less features, less freedom and less community. Only a suffering hater can do something this stupid. I hope you will get well by time. God bless you.

[Bernard Swiss]

The interesting bit about Upstart is that Canonical seems to be sticking to it and also -according to LP G+- they want to use it in the user session.

I thought the interesting thing about Upstart was that it was something Ubuntu got right.

- - - -
I'm probably speaking beyond my competence, here, but here goes:

Upstart is arguably an improvement on SysV init; it's simple, straight-forward, and human-readable/comprehensible, like Unix-y software should be whenever possible.

Upstart isn't much more complicated than SysV init, and offers some clear benefits. It's right dead-centre in line with the "Unix philosophy" of software and operating system design.

On the other hand: Systemd may be all kinds of "cool"; but its arguably an inherently and needlessly obfuscating, complicating approach -- that imposes the same drawbacks on all too many other tasks, bits of software and other files that it touches, and even requires new tools to deal with the problems it creates. It's a very "MS Windows" way of doing things, and its not clear that the benefits actually outweigh the drawbacks. Some would even describe it as a solution looking for a problem.

[Akka]

The interesting bit about Upstart is that Canonical seems to be sticking to it and also -according to LP G+- they want to use it in the user session.

How do this differ from systemd --user? I use that to control my user daemons.

[funkSTAR]

Systemd may be all kinds of "cool"; but its arguably an inherently and needlessly obfuscating, complicating approach -- that imposes the same drawbacks on all too many other tasks, bits of software and other files that it touches, and even requires new tools to deal with the problems it creates. It's a very "MS Windows" way of doing things, and its not clear that the benefits actually outweigh the drawbacks. Some would even describe it as a solution looking for a problem.

You really should go read what the systemd commumity is doing. They are making boot so much simpler and tje truth is they are inspired by other unixy "friends" from Apple, not MS. The basic idea is spawnig as few processes as possible and do socket activation. Is is simple and clean, and as a side effect; damn fast! Thats for init.

The rest is about features which will keep linux(thus its sponsors) relevant tomorrow. Linux NEEDS flawless session management, ressource control better than nice-levels, a metadata based logging which cant be tampered by intruders and so on.

This what systemd is about. Clean boot, and a bootload of future features. Shopping init and session systems is a different thing to teenagers shopping shoes. You cant just follow your feelings. You need to do whatd right. Systemd doesnt exclude others by CA, it has a growing community and is getting adopted in fast pace. Upstart is just a skunkwork.