Debian decides on systemd—for now
Debian decides on systemd—for now
Posted Feb 13, 2014 16:21 UTC (Thu) by madscientist (subscriber, #16861)In reply to: Debian decides on systemd—for now by anselm
Parent article: Debian decides on systemd—for now
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]
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