Bug#727708: init system other points, and conclusion
Le mardi 31 décembre 2013 à 19:01 -0800, Steve Langasek a écrit :
> It's not true that it's unrelated. In v205, logind hands off the cgroup
> heirarchy creation to PID 1, precisely because it's preparing for the
> anticipated future kernel requirement of a single cgroup writer.
This change would have happened sooner or later. The fact that logind
used to work without systemd as init was purely coincidental, since
logind was designed as an integral part of systemd from the very
beginning (particularly because of the cgroups design). This specific
change might has been triggered by anticipation for a kernel change (a
change that still doesn’t exist), but if not for cgroups, it would have
been for another reason.
> If we're
> expecting this "single cgroup writer" requirement to manifest, then it makes
> sense to move cgroup writing out of logind. The problem is with moving it
> to PID1, causing increasingly tight coupling between the components of
> systemd.
Let’s imagine for a minute that the systemd developers would have
listened to this request and put the cgroup manager outside of PID 1.
Since systemd starts up everything it spawns using cgroups, the very
first thing it would need to do would be to start up the cgroups manager
at boot time, before anything else. For systems with systemd in the
initramfs, the cgroups manager needs to be in the initramfs too.
A new protocol would be introduced for PID 1 to talk to the cgroups
manager, and every time a process is spawned, every time a query comes
from an interface, PID 1 would talk to the cgroups manager through this
protocol. Other processes would talk to PID 1 through one protocol, and
to the cgroups manager through another one, having to gather the
information afterwards, unable to obtain it in an atomic way.
What, exactly, would be the benefit of such a situation for systemd
users?
> > Let’s say that GNOME migrates to systemd user sessions, like what is
> > planned for GNOME 2.12 (yes, the version we intend to ship in jessie,
> > ain’t that sweet).
>
> "It's important to note that with these patches, we still support
> non-systemd systems (as well as older systemd). How far into the future we
> do so is an open question, but it should not be too difficult to leave
> non-systemd systems with the previous model over the next few cycles."
Oh but of course we can cripple our packages by disabling systemd
support and live without user sessions. We can always do that. That was
exactly my point.
> There are
> advantages to using systemd for user session management, particularly when
> coupled with Wayland...
And maybe after upstart, you intend to try forcing Mir upon us when
GNOME packages introduce a dependency on Wayland?
> but these can just as well be delivered on top of
> upstart rather than systemd. It does not follow that GNOME upstream should
> dictate to Debian that they adopt systemd rather than upstart.
You’re acting like a good salesperson, but I’m afraid your product is
inferior. These advantages cannot be provided by upstart. Just like for
system services, the available features for user sessions are not
comparable.
> I think the current Debian GNOME team has a not-undeserved reputation for
> being obstructionist with respect to bugfixes that require divergence from
> upstream's stated direction.
This criticism is totally undeserved. The GNOME team is involved with
GNOME upstream and understands where that stated direction comes from.
And usually agrees with it, but not every time: we have maintained large
sets of patches in Debian because of disagreements with the way
PulseAudio and GDM were managed upstream.
It shouldn’t come as a surprise that it is hard for developers to
respect the TC’s decisions when we see disrespectful sentences like the
one above from some of its members.
It strikes me that in general, the init system discussion has been
polluted by hateful comments directed towards the GNOME, freedesktop and
systemd projects and the Debian developers involved, by people who don’t
even try to understand the technicalities behind. Too many people have
let this happen, and too many developers have been hurt and demotivated.
Do not expect a TC decision that would rely on political arguments
instead of technical ones to improve that situation.
> If the team demonstrated they were open to
> contributions of the kind you described, volunteers to do the work would not
> be hard to come by.
You don’t just need volunteers to dig patches in the Ubuntu patch
tracker and email them. You need volunteers to maintain the resulting
packages.
In other words, if you disagree with the ways the GNOME team maintains
their packages, and appeal to the TC in order to change these ways,
you’d better discuss with all current maintainers whether they are ready
to abide by your rules, and have a proposal for what to put in the
Uploaders: field of the resulting packages. I am pretty sure the same
holds for a systemd package that would be required to remain at version
204, stripped of stuff that doesn’t work with upstart.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Reply to: