Re: Integration with systemd
Russ Allbery wrote:
> Josh Triplett <josh@joshtriplett.org> writes:
> > Part of the problem is that the people interested in sysvinit don't tend
> > to care about those features and often argue that others shouldn't care
> > either, and the people interested in those features don't tend to care
> > about sysvinit. It's difficult to motivate people to work on
> > alternatives for a system they already have and prefer.
>
> *This* is the thing that I feel we need to tackle head-on. Because there
> are a lot of reasons to care about those features, but possibly more
> convincingly, as Ted points out, *upstreams* care about those features and
> are not going to stop caring about those features just because Debian
> packagers do not.
(And some Debian packagers care about those features, too.)
The problem isn't that nobody cares; the problem is that the people who
care most about those features have a solution that works and don't feel
the need for a new one. The more people are (or become) convinced they
want and care about these features, the more likely they are to *also*
want the existing system that already implements them. Resources
available to implement an alternative that compatibly supports those
features but doesn't use or work anything like the existing solution
would have to come from the small intersection of "wants those features"
and "doesn't want the existing system implementing those features".
I'm not suggesting that group doesn't exist, but conditions don't look
good for it to grow substantially, or become sustainable.
(And unfortunately, by comparison, the more acrimonious approach of
fighting against those features and their usage is relatively easier, at
least within Debian.)
> Sure, some systemd features are only marginally better than what came
> before (I admit to not being much of a fan of timer units, for instance).
> But this will vary by person. For example, as a security person, I care a
> *lot* about namespacing, capability reduction, and seccomp filters, and I
> want to use those features in my packages to make the default
> configuration more secure. Other people are going to care a lot about
> D-Bus integration, and some upstreams are going to fully embrace socket
> activation (which, again, I'll point out is one of the easiest features of
> systemd to implement outside of systemd; implementations of the same idea
> predated systemd by many years) and just not support any way of spawning
> their service that doesn't satisfy the systemd socket activation API.
>
> One can individually say that one doesn't care about those features, but
> we just cannot say Debian as a whole should not care about those features.
> It doesn't work. We have to take an affirmative stance on what Debian is
> going to do with software that does care about and use those features;
> whether we're committing to porting it,
"committing to porting it" isn't a stance that "Debian as a whole" can
take. (Nor is committing to reimplement those features in another init
system.) That's certainly a stance that developers could take,
individually or as a dedicated group, but otherwise it's just "someone
should bell the cat".
> But saying "no one should care about those features" isn't a choice and
> isn't a path forward and we can't stop there as a project.
Agreed.
> > That's leaving aside that a reimplementation of systemd's features will
> > tend towards becoming systemd, and we have one of those already. What is
> > the actual goal?
>
> The actual goal is to allow for different ecosystems that provide the same
> features while embracing different implementation philosophies. I know
> that you don't think this is a valuable goal
That wasn't the point I was making, and I'm sorry if it came across
otherwise.
My point was that that makes any potential reimplementation even
*harder*. A simple reimplementation won't suffice. Reuse of existing
code won't suffice. It wouldn't help for folks who like systemd to
reimplement those features, because the reimplementation is not going to
satisfy the additional constraints of people who don't like systemd.
And the dual constraints of "must be compatible with systemd" and "must
have a fundamentally different approach than systemd" *inherently*
creates impedance mismatches and implementation challenges.
There's a reason why this reimplementation work hasn't happened, and
doesn't seem likely to happen. And *because* of that, there's instead
effort directed to try to stop people from using and depending on such
features.
> > It seems evident based on the history of such efforts that there is
> > *not* sufficient people/interest/motivation to reimplement the majority
> > of systemd features, let alone doing so in a way that meets the
> > additional constraints imposed on such solutions.
>
> I don't think the question has yet been forced. Up through buster, one
> has been able to mostly run Debian on sysvinit without doing this work,
> with some pain and some gaps and some issues. I think we're coming up to
> a point where this issue will be forced because both packaging practices
> and upstreams are diverging away from sysvinit support.
>
> I think there are two questions here:
>
> 1. Do we as a project want to do the work to leave open the possibility
> that such resources will materialize? This means doing things like
> defining a subset of systemd unit features that packages can rely on,
> and requiring (some? all?) packages not use features outside of that
> set. "No" is a possible answer here, but this is a political question
> with significant consequences, and I think it should be decided
> democratically.
>
> 2. Are we as a project *capable* of producing a non-systemd alternative
> that's viable? If the answer to question 1 is "no," then this question
> doesn't arise. But it's entirely possible that the answer to question
> 1 is "yes" but the answer to this question is still "no."
That last point is precisely the stance I'd like to argue against. If
Debian decides that it never wants to use capabilities sysvinit-based
systems don't support, that's one thing. But I don't think it's
reasonable to continue saying "the resources *might* materialize to
reimplement those capabilities on sysvinit-based systems" indefinitely,
and let that influence the decision.
https://en.wikipedia.org/wiki/Belling_the_Cat
We should make a decision based on the *actual* availability or
likelihood of sufficient people willing and able to do the work, not the
hypothetical availability.
Reply to: