User: Password:
|
|
Subscribe / Log in / New account

Bazaar on the slow track

Bazaar on the slow track

Posted Sep 12, 2012 20:41 UTC (Wed) by cmccabe (guest, #60281)
In reply to: Bazaar on the slow track by dlang
Parent article: Bazaar on the slow track

It is true that Upstart came before systemd. However, no other major distro is using upstart any more besides Ubuntu. wikipedia informs me that Maemo used it, and so did WebOS, but that's mostly a historical note at this point.

So yes, I would say that Canonical is very much going off on their own with this project. The fact that they require copyright assignment probably hasn't helped matters.

In general I feel like Canonical has been creating a lot of questionable forks: bzr versus git, upstart versus systemd, Unity versus GNOME. They've always claimed to be UI experts, but they don't seem to be focusing their effort where it counts.


(Log in to post comments)

Bazaar on the slow track

Posted Sep 12, 2012 20:55 UTC (Wed) by dlang (subscriber, #313) [Link]

I believe that Debian (and therefor almost all of the family of debian derived distros, of which Ubuntu is the biggest) is also using upstart.

really it's only the Fedora based distros that have switched, along with a few others, but for every other one that has switched, a non-debian derived distro can be pointed to that hasn't switched.

RHEL may or may not switch in the future. The systemd people will say that it will switch, but we'll see how the datacenter admins that RHEL is built for respond (they don't need many of the desktop based features of systemd and are are both more comfortable and more likely to have odd init stuff that will be affected.

As for Unity vs GNOME, as GNOME3 was released, the distros have splintered like a glass thrown onto concrete. Yes Unity is one of the fragments, but it's far from the only one.

Bazaar on the slow track

Posted Sep 12, 2012 21:11 UTC (Wed) by marcH (subscriber, #57642) [Link]

> RHEL may or may not switch in the future. The systemd people will say that it will switch, but we'll see how the datacenter admins that RHEL is built for respond (they don't need many of the desktop based features of systemd and are are both more comfortable and more likely to have odd init stuff that will be affected.

Plus: they don't care about systemd optimizations and dynamic features. And they'd rather hack and trace shell scripts than use gdb and cc.

Bazaar on the slow track

Posted Sep 12, 2012 21:13 UTC (Wed) by Teho (guest, #86286) [Link]

Debian doesn't use Upstart and RHEL 7 will be using systemd (it was confirmed in Red Hat summit 2012) and it's going to be released in 2013. Mageia and Mandriva have also already switched to systemd and Arch Linux and Chakra will be doing so shortly. systemd is very modular and designed to work well in embedded systems and servers and not just desktops. To my understanding it was first adopted by embedded systems and it's now part of GENEVI core platfrom so it's supported by numerous different distributions including Ubuntu IVI. It's also part of both Mer and Tizen mobile Linux operating systems.

Bazaar on the slow track

Posted Sep 12, 2012 21:19 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

"really it's only the Fedora based distros that have switched, along with a few others"

You are clearly trying to understate it. Among the popular ones, the distros that have switched:

* Fedora
* openSUSE
* Mageia
* Arch

"RHEL may or may not switch in the future."

RHEL 7 is switching to systemd as well

http://rhsummit.files.wordpress.com/2012/03/burke_rhel_ro...

Debian hasn't switched and is evaluating systemd along with OpenRC. Ubuntu has no plans to switch at this point.

Bazaar on the slow track

Posted Sep 12, 2012 21:39 UTC (Wed) by dlang (subscriber, #313) [Link]

and Gentoo and Slackware are not switching in the near term

your info about RHEL conflicts with other posters here.

Yes, several popular desktop distros have switched to systemd, that's far from the "everyone has switched, except for those lone wolves at Ubuntu who refuse to go along with everyone else" mantra that is being pushed.

Bazaar on the slow track

Posted Sep 12, 2012 21:55 UTC (Wed) by Jonno (subscriber, #49613) [Link]

> your info about RHEL conflicts with other posters here.
Yes, but he is the only one backing it up with sources...

> that's far from the "everyone has switched, except for those lone wolves at Ubuntu who refuse to go along with everyone else" mantra
Correct, but that is not what is being claimed here. What is claimed is that everyone but Ubuntu is either staying with sysvinit (or sysvinit + OpenRC) *or* are moving to systemd, no one else is staying with, or moving to, upstart.

Bazaar on the slow track

Posted Sep 12, 2012 22:17 UTC (Wed) by dlang (subscriber, #313) [Link]

do you really think that if Debian abandons upstart for OpenRC that Ubuntu will not follow along?

and if Debian remains with upstart (even if they replace the sysvinit option with OpenRC), then Ubuntu sticking with upstart is just staying with the upstream option.

Bazaar on the slow track

Posted Sep 12, 2012 22:52 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

" your info about RHEL conflicts with other posters here."

I have given you a public source from the company's roadmap slides presented in the company conference and your answer is this embarrassing hand waving?

" do you really think that if Debian abandons upstart for OpenRC that Ubuntu will not follow along?"

This is a poorly phrased question. Debian is not using Upstart now by default. So there is no real question of them abandoning it and yes, Ubuntu might very well decide not to follow if Debian decides to switch to OpenRC or Systemd considering how much they have invested in Upstart and that is quite understandable. Ubuntu has done considerably different things from Debian in many ways including the installer, Unity etc and there is no reason to automatically assume they will follow Debian in this case.

Bazaar on the slow track

Posted Sep 13, 2012 0:06 UTC (Thu) by dlang (subscriber, #313) [Link]

> Debian is not using upstart now by default.

actually, if I do an upgrade of a Debian system, it prompts me to convert to upstart from a sysv init. If this isn't using upstart by default, what is it?

Bazaar on the slow track

Posted Sep 13, 2012 2:52 UTC (Thu) by guillemj (subscriber, #49706) [Link]

> > Debian is not using upstart now by default.

That's right.

> actually, if I do an upgrade of a Debian system, it prompts me to convert to upstart from a sysv init. If this isn't using upstart by default, what is it?

The upstart package in Debian is not Essential, it's not on the base system either (Priority extra), and there's nothing except for live-config-upstart depending on it. So if it's being pulled in on an upgrade that's most probably some third party package doing that, either that or it got selected for upgrade at some point?

Bazaar on the slow track

Posted Sep 13, 2012 2:59 UTC (Thu) by dlang (subscriber, #313) [Link]

I ran into it on the raspberry pi debian image. installing it and doing apt-get update; apt-get upgrade includes getting a question along the lines of "this upgrade will switch you to a dependancy based init, this cannot be reversed, do you want to do this" I'm assuming that this is moving to upstart.

Bazaar on the slow track

Posted Sep 13, 2012 3:00 UTC (Thu) by clint (subscriber, #7076) [Link]

No, that is insserv, which comes from SuSE.

Bazaar on the slow track

Posted Sep 13, 2012 20:21 UTC (Thu) by Tester (guest, #40675) [Link]

And interestingly, OpenSuSe is also going the systemd way

Bazaar on the slow track

Posted Sep 13, 2012 2:59 UTC (Thu) by clint (subscriber, #7076) [Link]

There is no way an automatic upgrade should install the upstart package for you.

Bazaar on the slow track

Posted Sep 13, 2012 18:23 UTC (Thu) by smurf (subscriber, #17840) [Link]

You misunderstand. It asks you whether to switch to a dependency-based (i.e. possibly-in-parallel) execution sequence of init jobs. That's a somewhat more intelligent version of sysv-rc, but it's still sysv-rc, not upstart or systemd or whatever.

Anyway, there are upstart and systemd packages in Debian.
I don't know about upstart, but systemd works really well there.

Debian is probably going to do its usual thing and support both systemd and sysv-rc and/pr openrc and probably upstart long-term -- if for no other reason that tthe fact that systemd contains too many Linux-specific bits and pieces; debian wants to be able to run on top of FreeBSD kernels.

Now let's drop this side discussion and go back to VCS bashing please. ,-)

Bazaar on the slow track

Posted Sep 13, 2012 21:15 UTC (Thu) by zooko (guest, #2589) [Link]

bzr predated git just as upstart predated systemd. Now, maybe one could argue that, having already paid the cost of creating bzr, Canonical should be quicker to cut its losses and switch to git, but that's a lot different from accusing them of unnecessarily creating an alternative. bzr and upstart were first!

Bazaar on the slow track

Posted Sep 14, 2012 14:30 UTC (Fri) by smurf (subscriber, #17840) [Link]

I didn't say that Canonical were not first w/ bazaar and upstart (if my wording implied that, this was not my intent). At least not in absolute terms.

But you need to look at the actual use cases.

Take git. Linus developed the thing for the kernel. git supported *large* source repositories quite well, right from the start. All the others were "OK it works for ten files and ten revisions, I'm done with the basics. 10000 files and 1000 revisions? Oops, need to take our lunch break now, hopefully it'll be done when I get back." So git was the first DVCS that aktually worked for the "impatioen kernel developer" use case.

Or take systemd. Init's job, as Lennart has shown, isn't done after starting jobs: reliably discovering when a job has *stopped*, and hopefully not interrupting the service it provides while restarting it, is a worthwhile goal too.
Compared to upstart, sysv-init is good enough for me -- so why bother to switch to it? Compared to systemd, it no longer is. Conclusion: all my systems now boot with systemd. It's not the first init replacement out there, but it's the first worth switching to if you've done it the "/etc/init.d/foo start" way for the last 20 years (which, surprise, continues to work just fine with Debian's systemd).

I am not the only person out there who has written a whole bunch of software (some of whichtook a significant heap of my time+effort+money), which was "good enough" -- but then somebody else took a look at it, said "cool, but I can do better", did better -- and shared their code with me. So why should I not toss my code into the Great Bitbucket in the Sky, and use theirs (and then improve *that* instead of playing catch-up)?

I'm not going to let my ego get in the way of getting things done. Life's too short for that.

Bazaar on the slow track

Posted Sep 14, 2012 14:51 UTC (Fri) by paulj (subscriber, #341) [Link]

Init's job, as Lennart has shown, isn't done after starting jobs: reliably discovering when a job has *stopped*, and hopefully not interrupting the service it provides while restarting it, is a worthwhile goal too.

Though, there's no pressing reason why that job must be done by init…

Bazaar on the slow track

Posted Sep 14, 2012 16:23 UTC (Fri) by apoelstra (subscriber, #75205) [Link]

> Though, there's no pressing reason why that job must be done by init…

Well, init is the job's parent, so it's uniquely positioned to notice when a job crashes -- and since init started the job, it's also uniquely qualified to /re/start it.

Bazaar on the slow track

Posted Sep 14, 2012 17:51 UTC (Fri) by paulj (subscriber, #341) [Link]

Well, no, you can trivially have other process managers in between init and your service processes. You could have one that was dedicated to network services, hey it could even handle opening the sockets, watching them and only launching the actual services if there was activity (sound familiar?). You could have another that was specialised to watch TTY lines (Novell UnixWare had one of those I think). You could have another one for whatever.

Or you can have a kitchen-sink system, where you put all this into init, and it has to support every possible need any kind of service will ever have.

Bazaar on the slow track

Posted Sep 14, 2012 18:27 UTC (Fri) by bronson (subscriber, #4806) [Link]

Oo, hey! A micro vs. monolithic argument! Let's all voice our meaningless opinions.

Bazaar on the slow track

Posted Sep 14, 2012 20:07 UTC (Fri) by paulj (subscriber, #341) [Link]

FWIW, I'm not taking a side. Just noting that both ways are possible. :)

Bazaar on the slow track

Posted Sep 16, 2012 3:16 UTC (Sun) by bronson (subscriber, #4806) [Link]

Oh, ok. Can't disagree with that!

QotW material

Posted Sep 18, 2012 22:04 UTC (Tue) by man_ls (guest, #15091) [Link]

I would like to nominate your comment for "Quote of the week" for distributions, if it is not too late. It is sarcastic, it has the LOL factor, and it is true as life.

Bazaar on the slow track

Posted Sep 17, 2012 9:11 UTC (Mon) by pboddie (guest, #50784) [Link]

Take git. Linus developed the thing for the kernel. git supported *large* source repositories quite well, right from the start. All the others were "OK it works for ten files and ten revisions, I'm done with the basics. 10000 files and 1000 revisions? Oops, need to take our lunch break now, hopefully it'll be done when I get back."

I'm pretty sure Mercurial was developed for working with the kernel sources.

Bazaar on the slow track

Posted Sep 26, 2012 10:00 UTC (Wed) by makomk (guest, #51493) [Link]

Ubuntu are hardly the first distro to go off on their own with their init system, though. The days Debian's using a weird dependency-driven system (apparently derived from OpenSuse?), and Gentoo's pretty much always had its own init system (though I think some of its tools are Debian-derived). Once you've got something that's actually dependency-driven, switching to systemd suddenly starts to look a lot less worthwhile.

Bazaar on the slow track

Posted Sep 26, 2012 14:38 UTC (Wed) by smurf (subscriber, #17840) [Link]

I beg to differ; there are a couple of other good reasons why systemd is a good idea.

Before: "Owch, the job failed to start. Now which syslog file did it log its error message to? Oops, it was stderr, so hack the initscript; lather,rinse,repeat".
After: "systemctl status NAME.service"

Before: "This job needs to auto-restart when it dies for whatever reason. Write a hacky wrapper which utterly fails to *not* restart the thing when it *should* die."
After: "This job needs to auto-restart? Add a single well-documented line to the .service file."

And so on.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds