Voting Proposed For Debian Jessie's Init System

[mrugiero]

voting huh? It's not a democracy it's a technical issue that needs a technical analysis. If they cannot perform such an analysis they should leave it as it is.

Voting doesn't imply democracy, you know. And it's a technical issue that needs a technical analysis, yes, and where the weights of the pro and cons is not clear, so the ones who do weigh them have to decide how they think it is. And to come to a decision means exposing it as a vote.

Most open source developers not associated with Canonical prefer SystemD. These include the GNOME guys, KDE, Wayland etc. Even kernel developers seem to prefer the SystemD way of things (e.g. KDBus).

Not sure whether that fact affects what Debian is going to choose, but maybe it should.

I don't think popularity should directly affect a technical decision. Even though I do believe systemd is better (but should probably study the subject more), lots of people in Wayland and GNOME have common interests with people working in systemd, so it may be the same kind of bias as Canonical employees seem to have towards upstart. However, using systemd by default would ease configuring a GNOME desktop., so if they go back to using it by default, the sane default will probably be systemd.

Ah, but the way the question is phrased, I could see either Armstrong or Barth going for either options 4 or 5. This is about what should happen immediately, not which direction to head.

Yeah. IMO, they should stick to sysvinit until they actually decide for good. Changing the default init system means extra work, it's not like it's just changing a package. They need to make sure most services have the correct scripts, then they will almost surely have an unusually high amount of bug reports because of the change, and if all this gets changed again in the next release that would be utterly stupid. IMO, either they stick to sysvinit for now or they hurry up and decide what will they use later too.

I'm wondering what will happen to Debian GNU/Hurd and Debian GNU/kFreeBSD if they switch to systemd

at least upstart would be easier to port and they said that they will accept patches (source: https://www.gnu.org/software/hurd/op...s/systemd.html ``<azeem>Steve said he would happily take porting patches'')

Answer: nothing. They are choosing a default for Debian GNU/Linux. Neither Hurd nor kFreeBSD needs to share this default, and neither sysvinit nor OpenRC nor Upstart will be removed from the repos.

And it took them FOUR years to say so? Why didn't they try to influence its development? Raise their concerns? And please don't hide behind the CLA. It is a simple stupid document that can be renegotiated between the companies and individuals willing to contribute since the start system is fundamental part of the OS. In the worst case scenario said individuals and companies can fork the original project and rename it to something else. Problem solved.

From my perspective this is another attempt to derail one company's effort and replace it with something own. It's not like it hasn't happened before. The latest upstart vs. systemd is nothing new on that front.

Isn't enough to point it out to raise a concern? They probably weren't interested in having to rewrite an init system under conditions they probably don't like (yes, the CLA is a condition they probably don't like) to fix a core design problem (assuming it exists), nor they should have obliged to. If the design flaw is real, they already did the right thing by saying so. When Canonical chose to use a CLA to have better control, they chose to let go some developers that don't agree with that, plain and simple.
Also, forking, for what? Why would you fork something that is fundamentally flawed? When it's like that, you need to redesign and rewrite almost the whole code base, so it actually makes sense to just write a new one, because you are doing so already. Also, what difference would have made? You have two different projects, you have two projects most likely incompatible (because, again, whatever was wrong, if any, was in the core design), what changes between the actual situation and that hypothetical situation? Only that Canonical gets to choose the license of the new project, as the fork needs to comply with copyleft.

[smani]

and on the 2'nd part:
what ?
check distrowatch again
not even RHEL

You do realize thet RHEL6 was released when systemd was still in it's infancy? And RHEL7 *does* use systemd.

[liam]

I think referencing the G+ thread with sjr is better. There you have the actual involved with said situation.
In the end systemd is the project that has contributors from many companies (such as Samsung, for one). If the systems devs were so difficult to work with that wouldn't be the case.

[gens]

You do realize thet RHEL6 was released when systemd was still in it's infancy? And RHEL7 *does* use systemd.

y, my bad
i was saying about 7, couple months ago it wasn't official

anyway still, even high profile, distros without systemd

[CTown]

Why are you limiting yourself to system daemons? A user session has processes in need of management too. At least when you use a beast such as Gnome or KDE. There's a shell script to start KDE named, wait for it, startkde. But systemd --user is much better at doing the things startkde does. Right now we have a hodgepodge of things started by the init system, of things started by homegrown solutions such as startkde, and of things started by dbus-daemon. All of these work disjoint from each other. systemd aims to replace that hodgepodge with a unified way to start and monitor processes. All processes.

logind and polkit are far more granular than what groups and SUID provide. An example would be "a user can shutdown/reboot the machine from a local session, but only if he's the only user logged in". Or "a user can plug in and mount portable storage devices, but is not allowed to un/mount persistent storage devices". Not really doable with just groups and SUID helper binaries. You need something that tracks sessions (logind or consolekit, but the latter is unmaintained) and something that understands more fine-grained permissions (polkit).

Actually, it seems that Martin Gr??lin wants to make an alternative to startkde that depends on systemd AND Wayland. Though, startkde will remain for non-systemd based AND/OR X11 systems.

https://plus.google.com/+MartinGr%C3%A4%C3%9Flin/posts/GMtZrNCeaLD

[pizzapill]

There is no doubt in my mind that if the end user had to decide the process would already be over and systemd would win by a land slide.
I've made a poll to verify my suspicion and the results speak for themselves.

I'm currently using systemd on Arch/Manjaro boxes and I think this is the only real option for Debian.

[prodigy_]

You do realize thet RHEL6 was released when systemd was still in it's infancy? And RHEL7 *does* use systemd.

You do realize that RHEL7 isn't even released yet, don't you? Come back when RedHat starts drinking their own kool-aid at last.

[bkor]

You do realize that RHEL7 isn't even released yet, don't you? Come back when RedHat starts drinking their own kool-aid at last.

What an interesting argumentation. It was pointed out that RHEL6 uses Upstart, but actually not. It uses about 1% of the functionality. If you've ever looked at RHEL6 you'd know that. For the next release, it will use systemd. Because with RHEL6 it wasn't available. Now during all that time, Upstart is pretty much broken by design, as mentioned by the original author. See the various bugs listed at https://lwn.net/Articles/582585/. So systemd was started. It is used by many distributions, yet hand waved away because it is inconvenient for you.

That Upstart has been used for such a long time and still has design flaws is NOT a good thing!

[prodigy_]

That Upstart has been used for such a long time and still has design flaws is NOT a good thing!

Yes, from a purely technical standpoint upstart isn't any better than systemd. But systemd is more dangerous because its developers are actively trying to make it a dependency for everything else. Not to mention they break UNIX principles at whim and seem to be proud of that.

[valeriodean]

Yes, from a purely technical standpoint upstart isn't any better than systemd. But systemd is more dangerous because its developers are actively trying to make it a dependency for everything else. Not to mention they break UNIX principles at whim and seem to be proud of that.

Well, this is not true.
They (systemd's devs) cannot make systemd a dependecy for everything, because they are not the mainteiners of the other project.
What they can certainly do is to provide a continuos flow of new, elegant, robust features. When the other projects' mainteiners look to those features can decide to use one or more of them, then, and only then, the systemd starts to be a dependecy for those projects.
Do you recognize the difference?
UNIX's principles remain just a point of view because they depend on what you mean for "do one thing". Does the Linux Kernel does a lot of things or just one: be the layer between you hardware and the rest of the stack?
So, all depends about what is your project's mission because, to reach your target, you could be forced to do "a lot of things" under the hood.