Ubuntu Plans To Move To Systemd's Logind

[Vim_User]

My completely speculative theory is that ubuntu is going to adopt systemd eventually, they just don't want to right now *because* they are busy working on all this other stuff, such as getting unity-next and mir ready for 14.04, adding switching over to systemd to that list would be pretty ridiculous (and IMO their goal of getting unity-next and mir solid by ubuntu 14.04 is already pretty unrealistic).

So for now they are taking the most important bits of systemd and tacking it onto upstart, this is less work in the short-term and this will make the eventual transition over to real systemd easier. If they do transition to systemd it would be after 14.04.

I don't think that it would make much sense to abandon Wayland for Mir over the issue of having control over the project and then switch a different part of their distro from a project they have control over to something that does not give them the control they want.

[bwat47]

Ok so Canonical has always gone ahead and added their own differentiators to the Ubuntu ecosystem - things like Upstart and Unity in Ubuntu itself, and things like Launchpad and Ubuntu One as revolving around and enhancing Ubuntu, but they've always done a little bit at a time. Now they're simultaneously developing multiple separate systems (at least until they start making progress on their convergence goals), developing their own display server, contributing resources to help new software like Steam come to Linux, continuing to maintain and evolve software that hasn't been widely adopted outside Ubuntu, talking about switching to a rolling release model, and now this? Does Canonical have an infinite credit line or something? I thought they still weren't profitable. First: do they really have the means by which they can support so many projects at once? And second, even if they have the money to undertake this much all at once, isn't so many changes all at the same time just a recipe for corporate and engineering confusion, and thus disaster?

I mean, shouldn't they at some point just say, "Fsck controlling everything, let's go back to letting someone else do the work on some of these subsystems." Granted, they can't keep using ConsoleKit if it's unmaintained, and forking it or taking over maintenance themselves is not the solution to being stretched out like this, but rather than throw energy into new stuff while they're still working out core issues with the old stuff, that to me is just, I don't know, crazy. If they're cherry-picking systemd components, wouldn't it be smarter to dump Upstart for systemd completely, take a little bit of time making sure that they integrate systemd correctly and that it does what they want it to, and then redirect the resources previously lost on Upstart towards one of their other projects?

My completely speculative theory is that ubuntu is going to adopt systemd eventually, they just don't want to right now *because* they are busy working on all this other stuff, such as getting unity-next and mir ready for 14.04, adding switching over to systemd to that list would be pretty ridiculous (and IMO their goal of getting unity-next and mir solid by ubuntu 14.04 is already pretty unrealistic).

So for now they are taking the most important bits of systemd and tacking it onto upstart, this is less work in the short-term and this will make the eventual transition over to real systemd easier. If they do transition to systemd it would be after 14.04.

[funkSTAR]

Because they're doing nothing of the sort. This has nothing to do with the debate over upstart vs systemd as system init daemons - it's about using parts of systemd for user session management, replacing the old Consolekit.

Yeah the init battle is kind a over. While Canonical sticks to upstart the majority moved to systemd init. The next battle is more crucial. CoreOS vs shit pulled from Canonicals ass. Im betting my money on CoreOS.

[snadrus]

Migration is hard. Good for these Devs!

There are many dependencies on the low levels (some hidden until testing finds them). Canonical's "Upstart works fine." is over now that they can't pay maintenance on the deprecated litany of services that SystemD unified.

But a move is difficult (laborious, bug-prone), so a progressive approach is safer: avoid maintenance nightmares while working from inside to nudge management into SystemD.

[Delgarde]

I don't understand why they are trying to bolt on a bunch of systemd pieces into upstart, instead of just switching to systemd, which is obviously superior.

Because they're doing nothing of the sort. This has nothing to do with the debate over upstart vs systemd as system init daemons - it's about using parts of systemd for user session management, replacing the old Consolekit.

[Delgarde]

It is called CoreOS (sans Gnome stuff). And it is great, because it minimizes the maintaince burden.

Agreed. I know some people don't like to have anything be mandatory, but as a developer, having to support multiple backends for this kind of stuff is a pain. Inevitably only one of them actually gets regular testing (the one the developers are using), the ones that do work are limited to lowest common denominator, and even then, you're spending half your time working around bugs in something you really don't give a crap about.

I'm not against modularity and replaceable components in general, but sometimes it's just a really bad idea.

[DrYak]

In a month we will be reading an article on Phoronix with the title: Ubuntu Plans To Move to Systemd

And after one year: Ubuntu Drops Mir, Plans To Move To Wayland

...but then they'll alienate everyone by announcing that they will be developping their own kernel (based on a microkernel architecture, supporting Linux APIs, POSIX APIs and Windows NT APIs, all to be finished within 12 months, here's some work-in-progress that doesn't even boot).

[Luke_Wolf]

Come on. You cant make such an assessment without looking at advantages/disadvantages. And the primary DISADVANTAGE these days are fragmentation like Canonicals complete fuck up. Demanding the developers provide the many extra hours of release management and testing to make separate versions of every modules is waste of time. And Canonical takes advantage of this situation and ships CLAed replacements all the time. THAT is helping fragmentation. If Canonical wants to fragment THEY should have the burden not everyone else.

While I agree that their fragmentation should be their problem, just because things are designed as modules doesn't mean that having people using them in their systems inherently places more maintenance demands upon the people writing the modules, and in fact being modularized helps the initial developer because it makes it easier to maintain through testing capability that it opens up and otherwise. Also just because a person is using it doesn't mean that the module developers have to cater to that person, they can like Martin (the Kwin Developer) say "We're not going to take your patches that support only you", thus forcing the individual to take care of their own fragments with rebasing them and such.

[funkSTAR]

I don't understand why they are trying to bolt on a bunch of systemd pieces into upstart, instead of just switching to systemd, which is obviously superior.

Control&CLA

[funkSTAR]

Actually funky, he's praising systemd and Canonical is showing here that those complaints about systemd being monolithic as opposed to modular were dead wrong. Also a Modular program is far superior to an equivalent monolithic program as a modular program is essentially a wrapper around a bunch of far smaller programs (which means far less maintenance burden although larger initial development burden) that are doing one or a small number of things and it being a bunch of small programs means we can test them far easier because we're able to shove sample data in at the component level and get results back and see if they're what we expect them to be. Also say someone comes up with something better than logind, well you've got a relatively easy time just switching things out, Also what if someone wants to use some of your standardized components but not all of them? Well instead of having to rewrite an equivalent component themselves (thus leading to more fragmentation) they just have to set things up so that they're using your standardized components (thus leading to less fragmentation). A monolithic application on the other hand is quite the opposite, it's a pain to replace, good luck with testing and you're forcing people to have to write their own components. You will also note that over the long run modular programs win out over monolithic ones, systemd replacing sysV is a perfect example of this, although it's but one of many success stories.

Come on. You cant make such an assessment without looking at advantages/disadvantages. And the primary DISADVANTAGE these days are fragmentation like Canonicals complete fuck up. Demanding the developers provide the many extra hours of release management and testing to make separate versions of every modules is waste of time. And Canonical takes advantage of this situation and ships CLAed replacements all the time. THAT is helping fragmentation. If Canonical wants to fragment THEY should have the burden not everyone else.