Upstart Still Has A Bright Future On Ubuntu Linux

[Daktyl198]

Systemd passed beyond init longtime ago. The staff behind did not force you, it is your own distribution who packaged systemd into a single package.
You can build systemd without these optional files should you wish.

So say I want to use udev (not the forked eudev) without systemd. Oh what's that? I can't? Well doesn't that SUCK. Especially since up until a little while ago, it had no reason to be connected to Systemd... (and in fact, it works just fine without systemd running in the background, BUT YOU HAVE TO HAVE ALL OF SYSTEMD INSTALLED to install it)
What's that? D-Bus is being merged into Systemd as well? WELL FUCK. Guess Ubuntu/Gentoo or somebody is going to have to fork that too!

I find it slightly ironic that Systemd, which wanted to unify the init system between distros, is causing fragmentation on the layers above it for no perceived reason other than to try and force people to use systemd. Like, if udev actually used stuff from Systemd it would be different, but seeing as I know people who have run udev without systemd running, it seems odd.

I mean, I'm using it right now because my Distro (Manjaro) uses systemd, but I've been thinking about switching to a different init system (upstart, maybe?).

[AdamW]

So say I want to use udev (not the forked eudev) without systemd. Oh what's that? I can't?

Yes, you can. http://packages.debian.org/sid/udev

[liam]

...Upstart's not going anywhere...

Just like Ubuntu!

ZING

[liam]

Really? They believe in portability? Install Gnome 3.10 on OpenBSD (or a Linux distro not running systemd) and hibernate the machine. Oh, wait, you can't. Because you need systemd for power-management.

I think Gnome targeting only linux is smart...but I don't think they are doing that. The targetted platform approach is a good idea if you don't have monstrous resources or you want very tight coupling (like apple). The later can result in a better experience (in terms of stability, agility, and resource usage).

[profoundWHALE]

The Linux echo system is swimming with fun camps.

Alsa vs Pulse vs oss vs jack

Open drivers vs blobs

X vs mir vs wayland

Systemd vs upstart vs sysvinit vs OpenRc (included so a gentoo user doesn't knife me whilst I sleep).

Fragmentation as difficult as it can be has it's pluses. Imagine if we all had to use gnome shell or unity? If we all were stuck with vi for editing.

Let ubuntu do what it wants, other non buntu based distros just ignore them anyhow...

So the bigger question is if we should have:
fragmentation + choice
or
focus + little choice

The biggest problem with having so much choice is there really isn't enough development happening on one particular, say, audio system to make it significantly better than alternatives. But more importantly, it wouldn't be significantly better than say the Windows alternative which is who you want to beat if you want more people on linux (bringing more developers and all that with it) Sometimes we run into issues where there's a fork of a fork of a fork of a fork because of the slow development and other reasons.

The biggest problem with little choice is that when there's the single one something that is being used is everyone designs exclusively for that and don't leave room for alternatives to grow big enough to be a competitor. Also, they don't think about making it to be swap in swap out. How easy is it to replace ALSA with OSS and not have anything broken?

The positives for each of them should be obvious. With choice you get choice. With less choice you get more focus because they are developing less different things.

Ubuntu went the focus and little choice path and has been doing the best as far as the linux distros go. So either do something about itor stop complaining about Canonical you trolls.

[Alex Sarmiento]

"Lennart didn't start working on systemd because Red Hat told him "we, Red Hat, want to build a new init system which we control, and you, Lennart, are going to write it for us!"

Do you honestly believe that a company is going to keep hiring a developer whose work on a project goes against the interests and goals of the company? or do you believe otherwise?

Maybe, Lennart is working for Redhat just because he likes to *work for* Redhat. I really doubt that his contract with RedHat is just about letting him to do whatever he wants for whatever reason , even if he works on a project of a competitor .

[TheBlackCat]

Ubuntu went the focus and little choice path and has been doing the best as far as the linux distros go. So either do something about itor stop complaining about Canonical you trolls.

If Ubuntu had gotten most of their success while doing the "little choice" approach, then you might have a point. But Ubuntu became successful back when they had a lot of choice. Then, once they became successful, they began progressively reducing the amount of choice available. So you can't ascribe their success to their lack of choice, the restrictions on choice are too recent and too ongoing to really know what affect they will have on the distro long-term.

[Bernard Swiss]

The story is always the same: Canonical wants the control more than the features.
By the technical point of view, systemd is superior.
But, as per the display server, the possibility to control the project is more important than its technical aspects.
Doesn't matter how much upstart will remain behind systemd, they will never switch. End of the story.

...... at the time of upstarts creation there wasn't systemd. The point of upstart was to address issues seen with sysV int. systemd was created after upstart in order to solve the similar problems seen with sysV int. Canonical was trying to fix the same problem as Red Hat was trying to solve with systemd. I don't see why you claim upstart as trying to control anything, they didn't refuse any patches from Red Hat. I don't see any evidence that Red Hat tried to work with Canonical on upstart to add features they deemed important. Nor is there any evidence that Canonical rejected attempts for others to contribute.

If you look at what actually happened, you could easily make the same aeguement that systemd is just an attempt for Red Hat to control the int. process. Especially considering how aggressively they have been breaking the int process such that other software HAVE to use systemd components just to start up thier system, something that wasn't needed before.

I don't see upstart breaking the int process to force other people to use components for it just to use linux.

I would have said that Upstart (unlike Mir, Unity, built-in unified web/system search, PulseAudio, Banshee monetization, etc.) was the one big Ubuntu innovation that was something they actually got right. (If you want to argue the only thing, I might even agree -- does extensive desktop driver development and newbie-friendly nvidia graphic handling count?)

I groused a bit about having to learn something new, but it had clear advantages over sysvinit, and made sense over all, in that it followed the standard "Unix philosophy".

Systemd was a whole other story -- I can see that it has some advantages in certain usage cases, but it not very unix-y at all (in fact, it's kind of anti unix-y). It can easily be argued that in many respects the disadvantages of systemd outweigh the advantages. It certainly doesn't make me sit up and say to myself "Hey, that's pretty cool -- not only is it useful, it's elegant and clever, too." Rather, my response is more along the lines of, "well, it may be useful to some people, but god is it an ugly beast -- is it really worth it?"

And as far as asserting corporate control, that applies just as well to systemd as to upstart -- but in a way that insinuates itself much more thoroughly into the Linux OS system/ecosystem as a whole. Some distros have acknowledged in about as many words that some of their significant design decisions were being driven by the tentacular influence systemd has beyond it's own proper sphere.

[anda_skoa]

Qt cares more about doing Blackberry support than shaping the linux platform.

I doubt there has been a shift in resources regarding those two platforms. BlackBerry support in Qt is mostly carried by BlackBerry themselves, supported by a couple of contractors they've engaged.
Individual and corporate contributors to the Linux support are not involved with the BlackBerry efforts.

BlackBerry and QNX work is basically an addition to the Qt ecosystem, not diminishing the work done for other platforms.
They are too different to pull in or otherwise take resources allocated to Linux or any other platform.

Cheers,
_

[anda_skoa]

Systemd was a whole other story -- I can see that it has some advantages in certain usage cases, but it not very unix-y at all (in fact, it's kind of anti unix-y).

This is an interesting assessment.
My personal take was always that is was in fact very unix-y:
- It is configured through simple, text based, configuration files. The Unix principle of keeping the system maintainable with simple tools.

- It is a collection of daemons (logind, journald, timezoned, hostnamed), each specialized for a single task or a very small group of tasks. The Unix principle of separation of concerns.

- The daemons provide their functionality through standard communication channels (e.g. D-Bus). The Unix principle of communication instead of linking. Also keeps the option of replacability should it become necessary to switch to an alternative implementation.

Cheers,
_