Upstart Now Available In Debian Unstable

[AdamW]

It's much simpler, and therefore maintainable

Hm.

, it's well documented

So is systemd.

http://www.freedesktop.org/wiki/Software/systemd

http://www.freedesktop.org/software/systemd/man/

http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks

http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions

http://freedesktop.org/wiki/Software/systemd/Debugging

http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

and the entire 'systemd for Administrators' and 'Documentation for Developers' sections at http://www.freedesktop.org/wiki/Software/systemd .

it does its job and only that

This is a very short-sighted perspective. It is unrealistic to assume the precise correct job descriptions for all components of a computer were perfected in the 1970s, and all it is now possible to improve is the precise implementations of each defined job. There is no stone tablet anywhere which says 'There Shalt Be An Init Daemon Which Handles Nothing But Process Creation'. It's just a design choice.

As gregkh perceptively pointed out in that whole eudev kerfuffle, when udev first showed up, there were plenty of people who accused it of being too complex and doing too much compared to devfs or static /dev trees (remember those?) Now udev is the paragon of virtue, I don't see too many people clamoring to be allowed to return to maintaining a static /dev tree any more.

it compiles

Er...seems to go out without saying, but so does systemd...

it doesn't require userland to be changed to conform to its model

Neither does systemd. Both upstart and systemd can function as transparent drop-in replacements for sysv if so desired. But if you want to use most of the extended features of *either*, you have to write native services - both upstart and systemd have their own native formats that are different from and incompatible with sysv.

[carrkevinu]

Canonical should really push for adoption of Upstart in order to get mindshare and make people change to it instead of that systemd.

[peppepz]

So is systemd.

The problem is that systemd's documentation is scattered all over many places, many of them informal or unofficial. Also, much of it is bitrotten as systemd changes the way it works quite often, pushing the burden of keeping up onto the users.

and the entire 'systemd for Administrators' and 'Documentation for Developers' sections at http://www.freedesktop.org/wiki/Software/systemd

I wouldn't call an init daemon which is documented through an unordered series of 18 blog posts by its author "well documented".

This is a very short-sighted perspective. It is unrealistic to assume the precise correct job descriptions for all components of a computer were perfected in the 1970s, and all it is now possible to improve is the precise implementations of each defined job. There is no stone tablet anywhere which says 'There Shalt Be An Init Daemon Which Handles Nothing But Process Creation'. It's just a design choice.

I never said that. Upstart, for instance, is much more recent than the 1970s. The value of a system where the boundaries and the functions of each of its components are well defined and well documented, on the other hand, has no age. An administrator can obtain complete knowledge of such a system, reasonably foresee its behaviour, and diagnose faults when things don't work as expected. A kitchen sink that leaves you with a dead console and a wall of text made up of unrelated diagnostic messages because something went wrong is the opposite of that.

As gregkh perceptively pointed out in that whole eudev kerfuffle, when udev first showed up, there were plenty of people who accused it of being too complex and doing too much compared to devfs or static /dev trees (remember those?) Now udev is the paragon of virtue, I don't see too many people clamoring to be allowed to return to maintaining a static /dev tree any more.

I remember well when udev appeared. It replaced devfs, which was a simple approach, of the kind that I like, to the problem of populating /dev. The kernel would automatically make device nodes appear when the related drivers were loaded. ( devfsd on the other hand was broken, but let's ignore that for simplicity. ) The udev design replaced that with an userspace daemon, with certain requirements of its own, which had to be invoked in a special way at a special time during the system boot process. Things that were automatic with devfs (such as booting without an initrd in all the cases where this was previously possible) became no longer directly available with udev, and the protests were quickly dismissed by the udev proponents in the usual way: "fix that in userspace". This meant that, for instance, obtaining a working early userspace changed from being fully automatic into something that required dances of pivot_root and file descriptor voodoo.

Recently, after going out from the door, devfs has come back through the window in the form of devtmpfs, so in the end the "simple" approach won somehow. And the attitude of systemd developers, and their propension to ignore certain problems of their users, are leading the kernel developers to kill udev altogether and have the kernel load firmware on its own again.

Er...seems to go out without saying, but so does systemd...

That's the funny thing, it should go out without saying, but it doesn't. One of the last systemd releases that I tried just didn't compile on 32 bit architectures because it contained a mismatch in a function signature between a header and the implementation. This means that systemd gets released without even checking if it compiles on x86, which I find quite unsettling when we're talking about one of the critical pieces of a Linux installation.

Neither does systemd. Both upstart and systemd can function as transparent drop-in replacements for sysv if so desired. But if you want to use most of the extended features of *either*, you have to write native services - both upstart and systemd have their own native formats that are different from and incompatible with sysv.

Just do a Google search and see for yourself how many third-party packages are being modified to respond to systemd's automatic activation rules. Do the same search for upstart and see which of the two init systems is more invasive. The fact that one should modify a server in order to match the behaviour of a superserver, of which the former shouldn't even know the existence, is a violation of the principle of separation of software components.

That said, in my personal experience, it is very easy to set up upstart as a replacement for sysV. Systemd - not so much. Systemd is even less a "transparent drop-in" for sysvinit than PulseAudio was for plain ALSA.

[kigurai]

I wouldn't call an init daemon which is documented through an unordered series of 18 blog posts by its author "well documented".

Those are not so much documentation as helpful tutorials. I like how you spin extra documentation as something negative.

I thought that "man systemd" looked quite substantial. What is missing?

[storma]

That said, in my personal experience, it is very easy to set up upstart as a replacement for sysV. Systemd - not so much. Systemd is even less a "transparent drop-in" for sysvinit than PulseAudio was for plain ALSA.

I just dropped in two systems to systemd, from Debian Wheezy, wasn't that hard. Follow the documentation. I'll have to brush up on the new way of doing things but that's expected.

[Artemis3]

and: "Debian GNU/Linux can now handle either SysVinit, systemd, and Upstart to handle a head-to-head system booting battle."

Just, please, Phoronix, don't run some benchmarks and Declare a Victor. The extended capabilities of both upstart and systemd versus sysv are far more significant and interesting than any potential improvement in boot times they offer.

And the test should include a system loaded with services (typical desktop, typical server) instead of only a base system.
It would be fair if the starting services include both systemd and upstart files, as explained in the article most things lack systemd and perhaps none has upstart (in Debian).

I think Debian should go with upstart, because systemd is very intrusive and the linux requirement is a big negative (there is kFreebsd, hurd, etc). Of course systemd might actually address those things with time.

Its a fact that upstart is the more mature choice.

Here is Canonical clearly contributing a project developed by them back to the parent distro, so its about time people stop complaining about the "not giving back" excuse, and support this and encourage them to continue.

[ryao]

As gregkh perceptively pointed out in that whole eudev kerfuffle, when udev first showed up, there were plenty of people who accused it of being too complex and doing too much compared to devfs or static /dev trees (remember those?) Now udev is the paragon of virtue, I don't see too many people clamoring to be allowed to return to maintaining a static /dev tree any more.

I hope that I did not contribute to this perception. udev is far from perfect and there are better ways of doing things. However, many packages now depend on udev and moving away from it would be a burden on maintainers, so we appear to be stuck with it.

With that said, there have been suggestions that FreeBSD's devd be ported as an alternative. If udev were not so well established, porting devd would probably work extremely well.

[Teho]

I think Debian should go with upstart, because systemd is very intrusive and the linux requirement is a big negative (there is kFreebsd, hurd, etc).

The planned addition of support for user sessions in Upstart states that:

By making use of a Linux-specific prctl(2) call, we effectively tie Upstart to systems running with a Linux kernel. This is a major restriction, but porting to other systems is already complicated by the fact that even the BSDs do not provide a full POSIX environment (missing "waitid(2)" for example).

So it seems that Upstart isn't properly portable even now and in the future it's even less. It's clearly not any priority either.

Its a fact that upstart is the more mature choice.

It's also a project developed by single company without really any community participation and that has very little developement activity. It's no longer widely used out side of Ubuntu either. It's developed under contributor licence agreement using Bazaar in Launchpad. It seems very Ubuntu/Canonical specific project to me whereas systemd is developed by various companies (Red Hat, Intel, ProFusion, SUSE...) and communites like Arch Linux. It also doesn't have CLA is developed by using git in freedesktop.org. It seems that RHEL7 (Oracle Linux, CentOS, Scientific Linux...) and SLES12 will also be using it.

Here is Canonical clearly contributing a project developed by them back to the parent distro, so its about time people stop complaining about the "not giving back" excuse, and support this and encourage them to continue.

Well they are also doing a lot more harm than good by fragmenting the Linux userspace by using their techically inferior solution.

[JanC]

It's also a project developed by single company without really any community participation and that has very little developement activity. It's no longer widely used out side of Ubuntu either.

Upstart is also part of ChromeOS and used in a number of embedded devices.

(And there is activity in some development branches at least.)

[AdamW]

The problem is that systemd's documentation is scattered all over many places, many of them informal or unofficial. Also, much of it is bitrotten as systemd changes the way it works quite often, pushing the burden of keeping up onto the users. I wouldn't call an init daemon which is documented through an unordered series of 18 blog posts by its author "well documented".

This is extremely unfair, as another responder pointed out. systemd is documented through its man pages, as is conventional. There is also considerable 'bonus' documentation consisting of user-friendly guides to various actions, a FAQ page with background detail, and so on and so on. The manpages alone constitute sufficient conventional documentation. I could just have referred to those, but I wanted to make the point that the systemd developers go above and beyond to provide useful and extensive supplementary documentation and guidance. It seems mean in the extreme to spin this as a bad thing.

I never said that. Upstart, for instance, is much more recent than the 1970s. The value of a system where the boundaries and the functions of each of its components are well defined and well documented, on the other hand, has no age. An administrator can obtain complete knowledge of such a system, reasonably foresee its behaviour, and diagnose faults when things don't work as expected. A kitchen sink that leaves you with a dead console and a wall of text made up of unrelated diagnostic messages because something went wrong is the opposite of that.

The boundaries and functions of systemd, udevd and journald are all perfectly well defined and documented. You can perfectly well obtain complete knowledge of this chain, foresee its behaviour, and debug it. The boundaries and behaviour are different from sysv, but they certainly meet your conditions.

This meant that, for instance, obtaining a working early userspace changed from being fully automatic into something that required dances of pivot_root and file descriptor voodoo.

I have to say I tend to read this line of argument as 'I took the time to learn how the old way worked, and now I don't want to do it again'. Learning new stuff is a pain, yeah, but describing it as 'voodoo' is unwarranted. The 'fully automatic' way that devfs worked was just as much 'voodoo' to someone who was used to the previous method as udev's method is to you. More than anything, your perspective on what is perfectly comprehensible and sensible code and what is 'voodoo' depends on when you came in...

Recently, after going out from the door, devfs has come back through the window in the form of devtmpfs, so in the end the "simple" approach won somehow. And the attitude of systemd developers, and their propension to ignore certain problems of their users, are leading the kernel developers to kill udev altogether and have the kernel load firmware on its own again.

This is a fairly inaccurate description of that whole kerfuffle. There was a bug, developers took potshots at each other as F/OSS developers always do and always have since the beginning of time (proprietary ones too, it just happens in private where you can't see it), Linus blew off steam with a ridiculously over-the-top rant as Linus is prone to do from time to time, then everyone settled down and fixed things. It's fun to read developers yelling at each other, but it doesn't really tell you anything substantive. If we all stopped using every F/OSS project whose developers had been involved in a shouting match with Linus at some point we'd be in some trouble.

That's the funny thing, it should go out without saying, but it doesn't. One of the last systemd releases that I tried just didn't compile on 32 bit architectures because it contained a mismatch in a function signature between a header and the implementation. This means that systemd gets released without even checking if it compiles on x86, which I find quite unsettling when we're talking about one of the critical pieces of a Linux installation.

So you hit a bug. Presumably it got fixed. I can't really discuss it in any more detail since I don't know anything about that specific case. But bugs happen...

Just do a Google search and see for yourself how many third-party packages are being modified to respond to systemd's automatic activation rules.

They're not 'being modified to respond to systemd's automatic activation rules'. They're being modified to *use* systemd's socket activation, because socket activation is an awesome feature and lots of developers want their software to take advantage of it. The whole point of systemd - and upstart - is to provide new capabilities for service initialization and management, capabilities sysv doesn't have. If they didn't do this there'd be no point in their existence. Projects converting to native systemd services in order to take advantage of the features it provides is a *positive* indicator for systemd, not a negative one. They didn't have to do that, after all - they could have just stuck with their sysv scripts.

Do the same search for upstart and see which of the two init systems is more invasive.

See above. The fact that projects are not buying into upstart is not a *good* thing for upstart, it indicates that they don't have confidence enough in that project to take advantage of the capabilities it offers. Why is it a good thing for upstart if upstart offers a native service format that provides extended capabilities, but few projects want to take advantage of that?

The fact that one should modify a server in order to match the behaviour of a superserver, of which the former shouldn't even know the existence, is a violation of the principle of separation of software components.

Again, it is not about 'match[ing] the behaviour' of systemd. It is about taking advantage of useful capabilities that systemd makes available. socket activation is a feature systemd offers for services, not a mandatory requirement. You don't have to make your service socket activated. The fact that developers are doing so is a clear statement that they consider it a beneficial and desirable feature which systemd is providing them.