Debian decides on systemd—for now
Debian decides on systemd—for now
Posted Feb 13, 2014 9:57 UTC (Thu) by ovitters (guest, #27950)In reply to: Debian decides on systemd—for now by Thue
Parent article: Debian decides on systemd—for now
http://article.gmane.org/gmane.linux.debian.devel.ctte/5491
Quoting:
> * 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.)
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:
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."