Debian decides on systemd—for now
Technical Committee (TC) chair Bdale Garbee has made his casting vote in favor of systemd as the default init system for Debian "jessie" (8.0). That would seem to put an end to a contentious whipsaw of multiple calls for votes (CFVs) on competing proposals, CFVs ending because the wording was sub-optimal, and other bits of drama, at least for the TC. It is hard to imagine that we have seen the end of this controversy for Debian as a whole, but it is a concrete step toward resolution. There are a number of developments to report since we last looked at the tussle back at the end of January.
Another CFV
On February 5, Ian Jackson called for a vote on his ballot that included language about "loose" vs. "tight" coupling for whatever default init system was chosen. Essentially, "loose coupling" means that no other package can depend on a particular init system running as PID 1, while "tight coupling" would allow such dependencies. Jackson is concerned about GNOME and other packages that depend on systemd for "proper" functioning and would like to see Debian reject that approach. His ballot would also choose the default init system; the various combinations made for ten separate options (each of the four init systems with each coupling possibility, plus the general resolution and further discussion options).
Jackson's CFV came about after several revisions on the tech-ctte mailing list, as well as an IRC meeting to discuss wording. But he eventually withdrew support for the proposal by voting for further discussion (FD) first, after complaints from Steve Langasek and Debian project secretary Kurt Roeckx. Both of them were concerned about wording issues, so Jackson rolled up his sleeves and went back to work.
Another IRC meeting was scheduled and Jackson posted a
timetable for how he thought the voting
process should proceed. He also made it abundantly clear that any CFV
posted without allowing him to amend it to tie it to the coupling question
would be, in his eyes, "a clear breach of process
".
YA CFV
But posting a CFV is exactly what Garbee did on February 8. From that message, it is clear that Garbee saw no value in complicating the ballot by tying it to the coupling question:
While it was confrontational to call for a vote (and thus preclude amendments) in the face of Jackson's stated plans and warning, it's not clear what else Garbee could have done. There was obviously no consensus on the committee about the contents of the ballot and Jackson made it quite clear that he would offer amendments to a minimal ballot if offered the chance, so Garbee had to circumvent that to put a minimal question before the TC. As TC member Russ Allbery put it:
Garbee acknowledged that the members could override his choice by voting
FD, and that Jackson almost certainly would, "but I
sincerely hope the rest of you will not do that and instead vote this
ballot to a useful conclusion
". The question was what the default
init system for Debian Linux (and not the Debian kFreeBSD or Hurd ports)
should be for the jessie release. It also included
language that would allow the project to override the TC's choice via a
general resolution (GR) with a simple majority vote (rather than the usual
2:1 majority required for overriding the TC).
Decision
The vote came down much as expected, with a 4:4 split between systemd and Upstart proponents. Anthony Towns analyzed the votes and declared a tie between systemd and Upstart, which left it up to the chairman to decide by using the casting vote. Garbee did just that, voting for systemd, which makes it the Debian Linux default init for jessie. At least for now, since the prospect of a GR to decide is being bandied about.
There is another concern that Garbee expressed in his CFV: does the TC have the "jurisdiction" to decide on the coupling question at all. Opinions vary, but coupling was certainly not part of the original question that was asked of the TC.
The coupling question is a bit murky from a
Debian Constitution standpoint, as Roeckx is concerned that a binding
decision from the TC (rather than just an advisory one) would run counter
to the committee's mandate. In section 6.3.5 of the Constitution, the committee is restricted
from "engag[ing] in design of new proposals and policies
" and
should be "choosing from or adopting compromises between solutions
and decisions which have been proposed and reasonably thoroughly discussed
elsewhere
". Deciding on loose vs. tight coupling might violate
either or both, though Roeckx has not offered a formal opinion on that
question. Jackson took strong exception to Roeckx's concerns and
claimed that the Project Secretary should not be able to overrule the
TC:
I think all of these things are very dangerous territory for the Secretary. The Secretary should avoid getting involved in the substance of these kind of subjective disputes about what is and is not sufficiently ripe, or what is or isn't detailed design, or what is or isn't sufficient consultation.
Roeckx did not disagree about the Secretary's powers, but he did see the possibility that a dispute might arise. He would have to make a decision at that point, which would presumably be handled by a GR if other Debian Developers (DDs) agreed. Mostly, he would like to avoid the problem altogether:
Aftermath
Garbee's CFV clearly made Jackson extremely angry. As Garbee predicted, Jackson voted FD above all other choices (and ranked the init choices in the following order: sysvinit, OpenRC, Upstart, systemd), but he also let his anger get away from him. He quickly called for three separate votes on various earlier proposals, as well as a call for the TC to ask Garbee to resign as its chair. That was quickly followed up with a note that he would be stepping away from the keyboard and taking a break from TC business for a few days.
As Allbery noted in the message linked above and another, both of which were in response to a
call for
Jackson to be removed from the TC, it is not surprising that Jackson got so
angry at what he sees as a "betrayal
". Allbery
argued that Jackson retreated into the details of the process because the
decision was so divisive:
He goes on to show how "real world" legislative bodies suffer from some of the same troubles. The US Senate has been fighting about its procedures for some years, and a unilateral change to those traditions led to some of the same kind of rancor we see here. But Allbery brought up another important point: the tradition of consensus ballot-building (and, in general, largely consensus-based decisions) in the TC meant that the corner cases when things got messy had never been tested. This particular incident has shown a number of those corner cases, any or all of which might lead to GRs to fix them.
One of those corner cases was alluded to by Garbee in his latest CFV: that
the Condorcet
voting method, coupled with Debian's vote resolution procedure could
produce results that were, at best, unexpected. As Allbery said, the
procedure fails the
"later no
harm" criterion. In a nutshell, that means that a participant can cause
their preferred outcome to fail by ranking less-preferred outcomes (e.g. an
Upstart proponent could cause systemd to win by ranking it second to
Upstart).
Sébastien Villemot posted an analysis
showing one possible surprising outcome: "In particular, if the ballot had not included the options about
coupling, then systemd would have won because of the casting vote of the
chairman.
"
It is not exactly clear why Jackson is so insistent that the two questions be tied together. He said that the coupling question was the most important in his mind and that voting for the default init first would make it difficult for him to decide where to rank systemd as he is trying to avoid the systemd-tight-coupling pairing. But there is nothing stopping him from assuming that tight coupling wins and voting down systemd accordingly. In the end analysis, there never seemed to be enough votes for loose coupling to win, either on its own or in a ballot with the default init question, which is part of why some saw Jackson's actions as largely just delaying the inevitable.
There are ongoing discussions between Langasek and Allbery to reach some kind of accord on the coupling question (or at least a ballot that may be agreeable). TC member Keith Packard is optimistic that enough progress is being made in that discussion that it may be resolvable without the TC having to make a decision at all:
§6.3.6 says the TC should only be applied when other efforts have failed. Frankly, it's pretty darn hard to see the current discussions as 'failed' given how much progress has been made.
Next steps
Jackson reappeared on the mailing list on February 12. He posted a draft of the coupling question (along
with the wording to allow a majority override via GR) that he plans to put
up for a vote on February 14 (with amendments as suggested by other TC
members in the interim). He also issued an ultimatum: he will propose
and/or sponsor a GR on the init question (presumably the default init
system and the coupling question) under a few different scenarios. If his
proposal results in a vote of FD or if anyone calls an immediate CFV on a
related issue without giving him the opportunity to amend it, he will
immediately propose a GR. Beyond that: "If the TC's conclusion on the coupling question is IMO not
sufficiently robust I will probably canvass opinions before deciding
whether to propose a GR.
"
The GR question is, of course, the big one moving forward. It's hard to imagine that six DDs—the number required to put a GR to a vote—won't come together to try to push the decision in one direction or the other, so the only real question may be what form it will take. Will there be push to switch the default to Upstart? Or, as some think more likely, a move back to the status quo of sysvinit? Or will Jackson sponsor a GR? The possibility of multiple conflicting GRs also exists. There are, undoubtedly, wagers being made about various possible outcomes, but for now the default for Debian in the jessie release for Linux will be systemd. Stay tuned for further updates ...
Posted Feb 13, 2014 8:01 UTC (Thu)
by Felix (guest, #36445)
[Link]
To me the reference to "the ballot" was confusing because I assumed this was the latest ballot which systemd actually "won" by the casting vote. But Sébastien's analysis refers to Ian's previous ballot (init + coupling, just a bit simplified) and shows that upstart coupling could have won Ian's ballot because of the ranking of the L/T options.
Maybe you can amend the citation a bit so it's clear which ballot Sébastien refers to?
Posted Feb 13, 2014 9:46 UTC (Thu)
by Thue (guest, #14277)
[Link] (26 responses)
So his argumentation for wanting the full ballot is that it might enable him to vote for systemd instead of upstart. But systemd already had a majority without him, so the result would still be the same.
Holding the systemd vote separately also doesn't preclude him from proposing a separate T v L vote. So he has not right to be angry about the systemd vote.
Posted Feb 13, 2014 9:57 UTC (Thu)
by ovitters (guest, #27950)
[Link] (25 responses)
Quoting:
Ian wants "loose coupling". It seems he noticed that systemd would win, but he wants all init systems to always be supported, no tight integration. Saying ok to systemd could allow package maintainers to quickly to fully depend on systemd. Once this happens, good luck trying to undo this.
That's why he wanted it in one ballot. To get both answered at the same time. Avoid "facts on the ground" (dependencies added since passing of systemd default).
Posted Feb 13, 2014 10:02 UTC (Thu)
by kugel (subscriber, #70540)
[Link] (24 responses)
Posted Feb 13, 2014 10:24 UTC (Thu)
by ovitters (guest, #27950)
[Link]
Only thing I noticed is due to talking about it, I need to explicitly tell that some things are NOT part of GNOME. E.g. ConsoleKit is on freedesktop.org. UPower, freedesktop.org. Gstreamer, freedesktop.org. I haven't done that and this results in people assuming that GNOME is forcing things. IMO we're just really aware.
End October 2013, UPower (freedesktop.org) removed the standby functionality that overlapped with systemd. I highlighted this, see https://mail.gnome.org/archives/distributor-list/2013-Oct.... It is a highlight because it is a potential issue to package GNOME. I'll inform whenever I see potential issues, irrespective of where the maintenance lies. This so people have enough time to act (prepare for the change, argue against it, whatever).
What's now happening at the moment is that projects which rely on UPower to directly rely on that standby bits from systemd. AFAIK, that's all dbus and Canonical AFAIK already has a shim layer which does the same thing on Upstart. But that's Upstart, that's not every single init system out there (what Ian is after).
As I see it, I'm highlighting, but it is up to distributions to do something with it (though I'll try and assist if reasonable).
Posted Feb 13, 2014 10:24 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (22 responses)
And since Ubuntu is now alone in its use of Upstart, upstream projects are free to say "we don't support single-distro solutions", and depend directly on systemd features without fallback.
I still don't get why all the anger against systemd (you'd think it was responsible for ruining the economy of several nations, with the amount of Serious Business in this discussion), but that might be a cause: once all major distributions (except one) concede that systemd won, resistance becomes futile.
Posted Feb 13, 2014 12:30 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (18 responses)
I don't know what's so bad about this. After all, all major distributions have standardised on things like glibc, bash, GNU coreutils, and so on. This is generally considered a good thing. Nobody argues that glibc is part of an evil conspiracy to control Linux, even though it is possibly just as essential for the system as systemd, and resistance against glibc is just as futile (and has been for quite some time).
The systemd development community now consists of a fairly large number of people with all sorts of affiliations. The idea that systemd is controlled exclusively by a single company's agenda is nothing but a conspiracy theory without any sort of evidence.
Posted Feb 13, 2014 13:52 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (1 responses)
Me neither. I'm still trying to understand why some people are acting as if systemd will bring about the End Of The Linux World. But if they think systemd must be stopped at all costs, I can see why they can believe that the Debian decision is the last chance to stop systemd's progress.
Posted Feb 13, 2014 19:05 UTC (Thu)
by luya (subscriber, #50741)
[Link]
Posted Feb 13, 2014 14:46 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
The difference, I think, is that people see the things systemd is doing without understanding the rationales, reading the blog posts, or trying it out and instead tend to just assume, go off of other people's anecdotes born of other's assumptions, and more. *That* is what leads people to discuss systemd so vigorously. It sounds like "try it, you'll like it", but I'd vastly prefer even "I didn't like the way A, B, or C worked because of X, Y, and Z. I'd be happier if..." to "this blogger posted this a year ago which was out-of-date and misinformed when it was new. Don't you see why you're going to hell?". There's a lot of ignorance about the reasons behind things and it seems to be a willful ignorance in a number of the more…vitriolic commenters.
Posted Feb 13, 2014 16:21 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (14 responses)
Plus the standardization is not nearly as great as you seem to think. Debian, for example, does not use bash as "/bin/sh" and this is a constant generator of bugs as people who believe "all the world's a RHEL" write bash scripts with #!/bin/sh at the top.
And in fact, the "standardization" of things like glibc, bash, and even GNU coreutils, insofar as they are standardized, _is_ a major hassle and _is_ a seemingly endless source of frustration. Just ask anyone working on an embedded system which use a minimal libc and a small shell and busybox coreutils, or a non-GNU/Linux system, and they'll regale you with stories of silly requirements by packages that are just due to laziness or ignorance.
"Resistance against" these so-called standardized components is in fact alive and well and happening all the time.
systemd is a completely different thing, because there can be only one PID 1, and the wider the scope of the system that systemd relies on, and that rely on it, becomes, the less flexible the system becomes. The fear is that there will be a Gordian knot of interdependent components at the core of the system, which will reduce the ability to develop, experiment with, and use alternatives.
Any and all steps to reduce these interdependencies and introduce clearly-defined and standard interfaces between them is to be encouraged, EVEN IF IT ADDS COMPLEXITY. This is the place where I have worries about the current culture of systemd development. However I've not investigated any of this myself so all I have to go on are statements from LP that I've read on G+ etc., and the vociferous arguments from the pro- and con- sides.
I do agree that all the FUD related to Red Hat "owning" systemd is silly. It's free software, ultimately it's not "owned" by any one company or person.
Posted Feb 13, 2014 17:34 UTC (Thu)
by RobSeace (subscriber, #4435)
[Link] (2 responses)
This makes me want to write a new init and name it Highlander...
Posted Feb 13, 2014 18:41 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (1 responses)
Posted Feb 16, 2014 11:10 UTC (Sun)
by lab (guest, #51153)
[Link]
Posted Feb 13, 2014 18:54 UTC (Thu)
by Thue (guest, #14277)
[Link] (9 responses)
But things like the logind interface can be implemented in a non-PID 1 process. How else are Ubuntu running logind without systemd? http://www.phoronix.com/scan.php?page=news_item&px=MT...
So since what seems to be is the core of your argument is based on a false premise, then...
Posted Feb 13, 2014 20:19 UTC (Thu)
by peter-b (guest, #66996)
[Link] (3 responses)
systemd's implementation of the logind interface is implemented in a non-PID 1 process...
Posted Feb 13, 2014 20:57 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
Posted Feb 13, 2014 21:53 UTC (Thu)
by peter-b (guest, #66996)
[Link] (1 responses)
systemd-logind's interface is covered by systemd's Interface Stability Promise, so it's not subject to change on a whim. If someone else wants to make a competing implementation of the logind interface to replace systemd-logind, then they can do so. systemd-logind uses the public interfaces to systemd's PID 1, which are also covered by the Interface Stability Promise. If you want to run systemd-logind without the rest of systemd, then you will need to provide an alternative implementation of those interfaces. None of the interfaces that logind exposes or uses are "private", as far as I'm aware. Of course, you may have an example of one, and I would be delighted if you could highlight it for me. Now, I suspect you are alluding to the changes in systemd 205. That was a case where a new (public) interface was added to the systemd PID 1, and systemd-logind was modified to utilise it. May I venture to suggest that (a) the systemd devs wouldn't have added the interface unless it did something they consider novel and useful and (b) if they think the interface is useful, it fairly obviously follows that they'd want to modify related software make use of it! It's certainly hardly evidence of unreasonable, incompetent or unfriendly behaviour. This scaremongering about concealed interfaces that shift like quicksand beneath the feet of users and reimplementers (all subject to the malicious whim of the dark and mysterious cabal of systemd hackers) is neither accurate nor a valuable contribution to the init system discussion. Please stop it.
Posted Feb 13, 2014 22:50 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link]
The most important thing to note is that noone has yet gone through the trouble of building an independent implementation of a daemon to service the documented and stable D-BUS protocal. Nobody.
What Ubuntu has done is forked logind as a quick fix to avoid needing to run systemd as init. Logind prior to v205 was written with the PAXControlGroups multiple hierachy cgroups API in mind. logind prior to v205 did not depend on a single cgrourp manager entity and was free to write into the cgroup heirarchy itself..and it did so. But as of v205, systemd's provided logind daemon talks to the cgroup manager on the system as per the roadmap and guidance provided by kernel maintainers.
So it a lot of ways what we are seeing in v205 is a direct result of the kernel cgroup maintainer's decision (discussed widely in 2012!) to require a single writer model as part of cleaning up the cgroups API. systemd's implementation of the logind service provider as of v205 conforms to kernel's side expectations with regard to that.
The difficulty presented by logind change as of v205 has more to do with the fact that Ubuntu chose to fork logind as implemented by systemd instead of rolling an independent implementation to provide logind dbus API. Ubuntu could have chosen to spend the resources to re-implemented logind protocol using an independent daemon codebase that did not rely on cgroups at all. Using kernel cgroups is a design choice internal to the service talking the protocol...its not exposed in the protocol.
The Ubuntu devs are working hard to spin up cgmanager to be the single provider so they can patch logind v205 and beyond to work with cgmanager as a provider because they are still relying on a logind implementation that uses cgroups internally. And let me remind you cgmanager doesn't have a documented stable API yet for cgroup manipualtion. So the only cgroup manager API available for logind to support at present is systemd's.
All of this is entirely implementation details inside the scope of how a single logind daemon implementation can choose to work. The applications talking to it via D-BUS don't care about whether the logind daemon uses cgroups or not... or uses slices or not and systemd devs are not disrupting the stable protocol or creating new expectations on consumers at all. And given that systemd's implementation of logind service provider has always used cgroups heavily as part of its design, then it makes perfect logical sense for newest logind to require a central writer now that its been decided by the kernel cgroups maintainer that its the path forward for the cgroup rewrite.
I can't stress this enough, nobody as far as I know, is working on a independent implementation of the logind daemon to provide the stable documented logind protocol. I think that was a mistake on Ubuntu's part to fork this daemon instead of writing an independent implementation. If they had their own independent implementation, none of the changes in logind v205 would have impacted their ability to provide a working logind service and Debian would have a drop-in replacement to provide logind right now without the threat of holding up systemd or GNOME.
-jef
Posted Feb 13, 2014 20:25 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (4 responses)
Second, as I understand it, logind is actually a primary example _supporting_ the people concerned about systemd. Prior to systemd 205 logind was indeed separable from systemd, and Ubuntu uses logind version 204 (because GNOME requires logind). But starting with systemd 205, now logind is no longer usable without systemd, which means that any system must either switch to systemd, stay with version logind 204 and maintain it themselves, replace logind with something equivalent on at least an API level (and maintain THAT), or give up the features in GNOME that require it.
I've heard differing opinions on how feasible it is to replace logind and maintain that so I won't speak to that. I also won't speak to how reasonable it was to make this change in logind: I have no idea what the technical issues involved were.
The important point here is that regardless of the technical merits or the intentions of the people behind the decisions, the result looks to some, especially those old enough to remember the battles of the 90's :-), like a classic embrace, extend, extinguish play. The more core components are intertwined with systemd, and the more upper layers of the system are modified to require those core components, the more rigid the entire system becomes and the less experimentation and radical change is possible.
Look at it this way: what is the likelihood of "the next systemd" being developed if instead of just replacing PID 1 with something that provides a simple set of well-defined behaviors, you must also replace all the other aspects that systemd now provides before anyone can use it?
Posted Feb 13, 2014 21:07 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
This is a key difference between kernel development and "Desktop Environement" development (including systemd)
On the kernel side, Linus expects that some day he will get tired of running the kernel or that there will be reasons for the community to want him to stop running it. He also expects that some day there will be a smaller, leaner, faster kernel developed that will replace the old, crufy, fat, and slow linux kernel of the day.
His development process and tools make it so that the only thing preventing these from happening is that people are happier with the linux kernel under current management.
On the other side, the developers don't understand the idea that anyone would ever not want to use their software, and anyone who disagrees with them is wrong, a fossle who refuses to get with the times, or incompetent.
Posted Feb 14, 2014 2:03 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link]
OK, so the fundamental difference is ... <drumroll> systemd and Linux are developed with exactly the same strategy: each crowd develops what they consider is right, if others don't agree, it's up to them to come up with their own solutions</drumroll>. Many thanks for that earthshattering insight!
Posted Feb 13, 2014 21:54 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Or, let me rephrase what you're saying. (And just FYI, I'm not referring to "you" specifically)
You're unhappy that the logind authors are not doing the work necessary for you to use new functionality they've written (ie their work), when that new functionality depends on something you don't like, and then complaining that you'll have expend ongoing effort to work around the implications of removing that dependency yet still take advantage of the ongoing work that the logind authors continue to create.
Oh, the reasons for this complaint are because that the logind authors might possibly change something in the future, and that other third parties may independently chose to depend on those changes.
This entitled attitude really irritates me, because it both demands third parties do work on your behalf, while also insulting their integrity.
> The result looks to some, especially those old enough to remember the battles of the 90's :-), like a classic embrace, extend, extinguish play.
Except for one crucial difference -- the EEE play relied on proprietary software (and the BSD licenses that enabled them), and that isn't possible here due to systemd (et al) being released under the GPL.
Posted Feb 13, 2014 23:00 UTC (Thu)
by Thue (guest, #14277)
[Link]
glibc is replacable, if you write a new library with the same interface. logind is replacable, if you write a new implementation with the same interface. I fail to see the significant difference.
Posted Feb 14, 2014 15:38 UTC (Fri)
by oconnorcjo (guest, #2605)
[Link]
Posted Feb 13, 2014 23:49 UTC (Thu)
by xtifr (guest, #143)
[Link] (2 responses)
Posted Feb 14, 2014 8:37 UTC (Fri)
by ebirdie (guest, #512)
[Link]
I'm ready for systemd and I support that Debian makes a decision here and now to systemd than prolong the process. I fully trust both the decision-makers and the process they came to conclusions. The future will tell whether the old dogs fall in love with systemd and be quiet or feel the pain and rejoice at reinvented bone, init.
Just my cents to the discussion.
Posted Feb 21, 2014 15:49 UTC (Fri)
by Kluge (subscriber, #2881)
[Link]
As I understand it, this is precisely the POV of the OpenSSH project: core development is done solely for OpenBSD. Portability is handled by a separate group.
From http://www.openssh.com/history.html:
Posted Feb 13, 2014 11:00 UTC (Thu)
by stevan (guest, #4342)
[Link] (1 responses)
It seems to me that the process we see from time to time within Debian is probably a better example of "real world" institutional interaction than nation state politics, but the point is well made. However, while comments on these deliberations have seen them as amusing, unwelcome, necessary, tedious, petty or important, I find myself regarding very highly those involved, not just holding particular views and articulating them, but doing so in such a transparent and public forum that demands appreciation of the validity of other views. It is to be hoped that no-one will be harmed by these deliberations. Debian and its contributors are too important for that, but it is comforting that history suggests that they will find the right path.
I, for one, wish them all well.
Posted Feb 14, 2014 19:22 UTC (Fri)
by bdale (subscriber, #6829)
[Link]
Posted Feb 13, 2014 12:46 UTC (Thu)
by sml (guest, #75391)
[Link] (1 responses)
Frankly, I think everyone's a bit tired of debate. The T v L discussion isn't likely to get as emotional, so hopefully the TC can deal with it quickly (well, Debian-quickly).
Posted Feb 13, 2014 14:44 UTC (Thu)
by Thue (guest, #14277)
[Link]
Well, systemd is basically a rewrite of upstart, fixing those problems which were found with upstart, without CLA, and with more features. There is little reason to be enthusiastic about upstart over systemd, as I see it.
So if you don't like change, then of course you prefer sysvinit
> There is some noise on debian-devel in the aftermath of the decision, but not from DDs. And those making the noise are proposing to stay with sysv!
From skimming the discussion on debian-devel, the it is more like "rants" rather than "arguments" in favor of sysv. Certainly no serious discussion of sponsoring a GR to overturn the systemd decision.
Posted Feb 13, 2014 15:22 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (23 responses)
Posted Feb 13, 2014 15:42 UTC (Thu)
by Thue (guest, #14277)
[Link] (11 responses)
Does the OpenBSD init software work on Linux, then?
Posted Feb 13, 2014 15:47 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (10 responses)
Posted Feb 13, 2014 16:07 UTC (Thu)
by Thue (guest, #14277)
[Link] (9 responses)
The idea of having a relatively small unportable core of userspace code able to take advantage of the special features of the kernel makes a lot of sense to me.
Posted Feb 13, 2014 16:42 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (3 responses)
Posted Feb 13, 2014 22:45 UTC (Thu)
by rahvin (guest, #16953)
[Link] (2 responses)
Posted Feb 13, 2014 23:11 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
That being said, Chrome isn't a dynamic or complex an init target right? It's not really a general purpose desktop or server is it where you can install lots of addon services? As a typical Chromebook user, how much control do you have over what services are starting up or not?
It's most likely that Chrome represent a very well defined init target with a well defined, nearly uniform, set of services that will be running on all installs and that upstart's service management suffices without running afoul of the problems in the event model that other service configurations will hit.
Posted Feb 14, 2014 8:11 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Google is plenty clear in it's position: upstart tested and works, it's fast [enough] and thus there are no need to change it. It's not as if they looked at systemd and rejected it, no, they have never looked and since they have patches which tie the rest of ChromeOS to upstart switch to systemd is not trivial. As you can see they are very, very, very pragmatic and not wedded to upstart at all.
Posted Feb 13, 2014 23:29 UTC (Thu)
by xtifr (guest, #143)
[Link] (4 responses)
As someone whose interest in providing portable, cross-platform daemons is much higher than his interest in nursing every possible second out of the startup time for one particular platform (even though it happens to be the platform I use for my desktop), I'm dismayed at the recent proliferation of incompatible init systems.
Yes, I'd like to have Linux work better and be more powerful. But I still hate people who make portability their lowest priority. Open, cross-platform standards are one of the main things that helped Linux get where it is today, and I really hate to see them abandoned by the very people who benefited from them in the first place.
I can't help wonder what the Apache folks think about all this. Or the various mail server projects. Or all the other folks working on assorted cross-platform daemons.
Still, as long as systemd maintains backwards compatibility with Sysv init, I'm not going to sweat it too much.
Posted Feb 14, 2014 0:28 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link] (2 responses)
Oh, come on. The mess of SysV init scripts is almost as far from portable as humanly possible.
Posted Feb 14, 2014 7:41 UTC (Fri)
by dgm (subscriber, #49227)
[Link] (1 responses)
Posted Feb 14, 2014 8:47 UTC (Fri)
by Thue (guest, #14277)
[Link]
Posted Feb 14, 2014 2:16 UTC (Fri)
by rodgerd (guest, #58896)
[Link]
(MS are hardly the only notable exception, unless your world of "most OSes" is sufficiently small to exclude VMS, AS/400, and so on and so forth. And given that SMF has been around 9 years, upstart is almost 8, and launchd is also 9 years old, "recently" is torturing the language a bit. People have been revamping the Unix init/process management space for a decade now.)
No one implementation of which is compatible with another platform. That's even more true when considering the assumption a particular shell will be /bin/sh and the many and varied possible permutations of the system layout. It's not like you can take a script from Fedora and assume it'll work on Debian, never mind BSD. So that would be "not very portable at all."
systemd is actually pretty late to the game, which is IMO a good thing. It means it hasn't been tempted to e.g. have XML based config files like SMT, because that's not fashionable any more. There's been time to learn the lessons of previous attemps to do this. One may or may not like all the decisions (I really don't like binary logs, for example), but it's not like this hasn't been a common idea.
> I'm dismayed at the recent proliferation of incompatible init systems.
I'm dismayed that so many people seem to think "it sort of worked in 1982" is a good reason to never ever change anything.
> I can't help wonder what the Apache folks think about all this. Or the various mail server projects. Or all the other folks working on assorted cross-platform daemons.
Given they already have to either (a) tailor scripts to every single distribution or (b) leave it up to the distro I fail to see how things are in any way worse.
Posted Feb 13, 2014 16:06 UTC (Thu)
by pizza (subscriber, #46)
[Link] (7 responses)
So this is why OpenSSH has what is effectively a permanent fork solely dedicated to porting OpenSSH to anything/everything other than openbsd?
You have chosen a pretty poor example of a champion of portability.
Posted Feb 13, 2014 16:38 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (6 responses)
Posted Feb 13, 2014 17:44 UTC (Thu)
by pizza (subscriber, #46)
[Link] (5 responses)
(and that information is also on the Portable OpenSSH webpage, FYI. Maybe you need to take your own advice?)
Meanwhile; A simple "you are incorrect, this is why" reply would have sufficed, without resulting to "hater" insults that accomplish nothing but make you look like an imbecile.
But I digress.
Theo De Raat has done (and continues to do) many great things for the Free Software community. He is many things, but a champion of interoperability is not one of them.
Posted Feb 13, 2014 17:59 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (4 responses)
Posted Feb 13, 2014 20:59 UTC (Thu)
by khim (subscriber, #9252)
[Link]
I think you've set some kind of record. You've talken a project with a very-well documented history publicly avalaible on it's web site and you try to construct some kind of alternate reality on another public web site. Don't you think that it's… well… too much? Please go and read about OpenSSH history! Then you'll find out that you should question not the existence of OpenSSH-portable, but the existence of OpenSSH proper! Before OpenBSD and Theo involvement OSSH supported at least the following environments: OpenBSD developers initially had zero interest in supporting these other environments, they removed all the the kludges (which were needed to support that zoo) in their efforts to cleanup the code and went with “OpenBSD-only” approch. Theo himself is listed as guy who removed these non-portabilities which made the code harder to read (but which were required to support wide range of non-completely-standard-OSes). Since these versions had many features which original version lacked various non-OpenBSD groups got very, very interested. After that Damien Miller, Philip Hands, and handful of others started porting OpenSSH to Linux and various other Unix operating systems. Note: Theo is surprisingly missing even if he was featured prominently in the first, “OpenBSD-only”, version. This is not something I've cooked up from some random sources, it's all written right there, on the web site of OpenSSH itself! I'm pretty sure if various non-OpenBSD will become very, very interested in systemd then people (not necessarily Lennart) will be able to create portable systemd fork. Indeed, nosh can be considered a kernel for such an effort—but I just don't see interest from various BSDs, MINIXes and QNXes in such a fork.
Posted Feb 13, 2014 21:30 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
But back to my original point.
If anything, Theo is more of a poster child for "my way or the highway" and "I don't care about implications for other systems, I'm making mine the best there is" attitudes than is attributed (often deservedly) to Pottering, and that attitude has helped make OpenBSD what it is today.
OpenBSD's kernel (and libc) is a world unto itself; anything that interacts with the kernel isn't even portable to the other BSDs, much less Linux. (And why should it? I don't say this as criticism; they are doing what they want, for their own goals, and appear to be successful)
Meanwhile, OpenBSD is only relevant to the vast majority of Linux users (and distributions) due to it being the upstream of Portable OpenSSH and the occasional security problem the OpenBSD folks find in 3rd-party software.
So, please, explain how Theo is an advocate of portability, and how his attitude (and practice) is different/better than Lennart's -- Because on the face of it, Lennart seems to come out on top in such a comparison.
Posted Feb 14, 2014 1:43 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Posted Feb 14, 2014 13:39 UTC (Fri)
by pizza (subscriber, #46)
[Link]
In areas where they are not forced work with the outside world (eg kernel+libc, syscall interface, system configuration, and even the userspace ABI) they are completely non-portable (even when only compared to other BSDs) and non-standards compliant (unless you consider themselves to be compliant with themself).
(Nevermind you're trying to draw a comparison between a by-definition interoperable network service and something that *launches* network services. Apples and oranges...)
So, two of three of your items are irrelevant, you just now added a fourth ("interoparability") which is equivalent to the first two (and still irrelevant), and the third has been demonstrated to be completely false using the very documentation you accused me of not reading.
Even if one accepts your attempt to move the goalpoasts, you still haven't supported your original assertion that Theo de Raat (and the other core OpenBSD developers) are more dedicated to "standards, compatibility, and interoperability" than the systemd developers.
Posted Feb 13, 2014 17:29 UTC (Thu)
by rsidd (subscriber, #2582)
[Link]
Posted Feb 21, 2014 16:12 UTC (Fri)
by Kluge (subscriber, #2881)
[Link]
I don't know how committed Theo is to standards and compatibility in general, but see my comment above about his feelings in regard to portability (for OpenSSH, at least).
Posted Feb 25, 2014 15:59 UTC (Tue)
by mattrose (guest, #19610)
[Link]
Last I checked, OpenSSH only works on OpenBSD, anything else is in a "portable" directory, and it's portable, but only because of the efforts of a lot of people, I don't think Theo cares whether it works anywhere but OpenBSD.
So, you're wrong about that...
Posted Feb 17, 2014 6:44 UTC (Mon)
by cyperpunks (subscriber, #39406)
[Link] (1 responses)
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
http://article.gmane.org/gmane.linux.debian.devel.ctte/5491
> * The vote on the proposal above results in FD. (I think it is
> important to make a decision on this quickly before "facts on the
> ground" are established to make this more difficult; the passage of
> the default resolution makes that urgent.)
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
once all major distributions (except one) concede that systemd won, resistance becomes futile.
Debian decides on systemd—for now
> I don't know what's so bad about this.
It could be a blind obsession to anything related to Debian as good and Red Hat bad.
Despite clear clarification about systemd, some people simply chose to believe their own opinions as facts like systemd being a Red Hat tool just because Poettering started that project as Red Hat employee.
Now change Red Hat by Debian and see how those people will scream systemd is the best init ever made from Debian developer.
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
it doesn't matter if it's running as a separate process if all the interfaces to it are private, subject to change at the whim of systemd, and unable to be replaced or run without the rest of systemd.
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
And since Ubuntu is now alone in its use of Upstart, upstream projects are free to say "we don't support single-distro solutions", and depend directly on systemd features without fallback.
That's true only for Linux-specific projects! I mean, can you seriously imagine Apache or Sendmail or OpenSSH telling people "you must use one of the major Linux platforms to run our system"? :)
Since I try to avoid using platform-specific software wherever possible (I may not have any immediate plans to switch to BSD, but I'd really like to retain the option, and I always try to support BSD at least in whatever I might write), such a statement would probably result in that software being purged from my system, even though I run Debian.
Debian decides on systemd—for now
Debian decides on systemd—for now
> one of the major Linux platforms to run our system"? :)
"From the start of our own efforts, we have felt that even the original ssh code was too complicated, it simply had too many operating system dependencies to deal with. Our approach to writing completely secure and rock solid code avoids dealing with excessive differences like that. Thus, to make the entire development process easier on us all, we decided to split our core development efforts from portability developments."
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
As someone who doesn't mess with the init system or care what it is, but does want a usable system two years down the line, I'm conflicted:
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
It seems that historically pretty much every OS has written their own init system implementation.
Actually, until fairly recently, most OSes (with MS being the notable exception of course) used BSD init or SysV init, or something compatible.
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
386BSD 0.1; i386
AIX 3.2.5, 4.1; RS6000, PowerPC
BSD 4.4; several platforms
BSD/OS 1.1, 2.0.1; i486
BSD/386 1.1; i386
ConvexOS 10.1; Convex
DGUX 5.4R2.10; DGUX
FreeBSD 1.x, 2.x; Pentium
HPUX 9.0x, 10.0; HPPA
IRIX 5.2, 5.3; SGI Indy
IRIX 6.0.1; Mips-R8000
Linux 1.2.8 Slackware 2.1.0; i486
Mach3; Mips
Mach3/Lites; i386
Machten 2.2
NetBSD 1.0A; Pentium, Sparc
OSF/1 3.0, 3.2, 3.2a; Alpha
Sequent Dynix/ptx 3.2.0 V2.1.0; i386
SCO Unix; i386 (client only)
SINIX 5.42; Mips R4000
Solaris 2.3, 2.4; Sparc
Sony NEWS-OS 3.3 (BSD 4.3); m68k
SunOS 4.1.2, 4.1.3, 4.1.4; Sparc
SysV 4.x; several platforms
Ultrix x.x; Mips
Unicos 8.0.3; Cray C90Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
Debian decides on systemd—for now
"Scott James Remnant, the originator of Ubuntu,"
Ugh, of course I meant the originator of upstart.
OpenSSH and portability
Debian decides on systemd—for now
Debian decides on systemd—for now