Re: Tentative summary of the amendments

[Josh Triplett <josh@joshtriplett.org>]

Aigars Mahinovs wrote:
> On 24 October 2014 13:33, Ansgar Burchardt <ansgar@debian.org> wrote:
> > So, if P has a hard dependency on systemd-as-pid1, why do you want to
> > take P away from me? Because people not liking systemd are more
> > important than people not caring about it or even being okay with it?
> 
> It is not about "people not liking systemd". It is about people using
> other init systems. The question is about how strongly do we feel
> about supporting this group of users.

"we" don't consistently feel any way in particular about supporting this
group of users.  People who care can do the work, as always.

> > I don't like some software too, but am sometimes required to use it
> > without an alternative. Can I demand that I can use packages without
> > said software? Like demanding libraries having to provide language
> > bindings for at least two languages so I don't have to use PHP[1]? :)
>
> Init system is special because there can be only one active in the
> system. If app1 depends on systemd (as PID 1) and app2 depends on
> runit (as PID 1) then it becomes impossible to use both apps (without
> changing init system and rebooting). Also IMHO init system should be a
> user choice and not dictated by other, unrelated, software.

Kernels are special because there can be only one active in the system.
If app1 depends on Linux and app2 depends on FreeBSD, then it becomes
impossible to use both apps (without changing kernels and rebooting).

And yet we don't stop applications from declaring "Architecture:
linux-any".  And the world has not ended.  People who maintain non-Linux
kernels have a substantial amount of work to do, and I find it very
impressive how much they've gotten working.  Yet nobody has proposed a
GR forcing support for kFreeBSD or the Hurd; the people working on them
have simply *done the work*, and in some cases successfully convinced
others to do the same.

(And analogously, non-Linux kernels such as FreeBSD often have
substantial shim layers providing Linux APIs for the purposes of porting
software.)

> In any case, this is uncharted territory, because (to my knowledge)
> until systemd started integrating system level services into init
> system itself, applications never depended on particular APIs of init
> systems.

Sure they did.  Applications depended on daemons which depended
specifically on sysvinit functionality: /etc/init.d, /etc/rc?.d, LSB
init script metadata, dependencies on specific scripts and their
functionality.  It wasn't much, but it was something.  Consider the
burden that placed on other init systems.  Consider what would happen if
a new init system came along, which did *not* implement the sysvinit
interfaces; would we suddenly force applications to stop depending on
sysvinit features?  Or would we simply say "patches welcome"?

In any case, even if this problem were new to init systems, it's not new
to many other things: kernels, C libraries, compilers, and many other
things.

> We need to make a conscious decision on how to handle that. If we
> don't then it is likely that the process will go on as before:
> * systemd introduces a great new system level service,

How dare they build software people want?

> * key apps depend on that service to do great things (and stop working
> on all other init systems),

How dare they take advantage of time-saving common code, or introduce
new functionality for which no support previously existed?

> * people using other init systems are sad,

"How dare other people do work on init systems other than ours?"

> * after a lot of hard work a new ugly hack shows up to patch out or
> fake out the new service (making apps kind of work again, but not as
> good as before),
> * another flamewar/GR is started to stop systemd dependencies breaking
> software for other people

Yeah, sadly, I don't expect this to be the last flamewar on the topic,
even after it gets voted down.

> * (repeat)

Modulo the flamewar/GR, that's the normal, expected, and desirable
process.  It also has the critically important property of only
continuing as long as enough people actually want to do the work, rather
than becoming self-perpetuating as a GR-enforced requirement would.

> I am sure that there will be several more rounds of these because
> systemd has a *lot* of very interesting and useful services coming up
> in their plans.

I already expect to see several more rounds over *existing* services
that the systemd package hasn't yet enabled.  For instance, timesyncd,
networkd, systemd-nspawn, etc.  I anticipate a painfully long delay
before I can actually count on those.

> I can't wait to use most of them, but at the same time
> it sound like they are developed in a tight coupling with systemd
> itself thus making all those very useful features unavailable to users
> of all other init systems. Like the upcoming wifi management changes -
> those sound great, but there doesn't seem to be a reason why it
> couldn't have been designed in such way that users of other init
> systems could simply call some executable with some params and have
> their wifi configured with those tools.

I'm going to assume you're not particularly interested in hearing the
Nth iteration of someone explaining reasons for such a design.

> Being the default init system should not be the mandate to
> break/rewrite everything else. In fact being the default init system
> should bring great responsibility *not* to break stuff.

First of all, software that does not work with systemd is not "broken";
it works just fine with its dependencies installed.  If you want it to
work with other software, that's a wishlist request, not a bug.

In the more conventional sense of "break", systemd has in fact taken an
extraordinary amount of care not to break stuff, frequently succeeding;
I find it quite impressive how painless the transition has managed to be
given the magnitude of the change.

I would suggest directing your concerns either at upstreams to convince
them to not use systemd functionality (good luck), or better yet into
the development of alternatives that people want to use *more* than the
versions in systemd.  Absolutely nothing stops you.  If you (and the
entire set of people who agree with you) do not collectively have the
time to keep up with the astonishingly rapid development pace of
systemd, the right answer is *not* to hobble systemd or shout "wait up"
at it, nor is it to hobble other software that wishes to use systemd
until a duplicate implementation exists.

- Josh Triplett