Hi.

I have not been at the meeting. So of course I may be misunderstanding
the intention here. If so, please feel free to ignore my feedback.

Plasma - 24.10.18, 05:11:
> There is also an opportunity for embrace-extend-extinguish here. If
> the Linux ecosystem embraces systemd unit files as a de-facto
> standard (as good or bad as that might be), the first step is embrace
> (we support it), then we extend (add a killer feature only present in
> Devuan), then well ... bye bye systemd >:-)

I think I would not do this. Why?

I still think that strategy is part of what Systemd upstream did, maybe
not consciously or intentionally, but unconsciously. Back when I even
went for mediating user concerns with Systemd upstream, I said that how
Systemd upstream spreads Systemd reminds me of the embrace-extend-
extinguish strategy and got called out by Lennart for this ('now you are
being a dick')¹. Using the same strategy as a kind of revenge really
does not help here. It may even lead to unhealthy competition ("they can
extend to). And it invites a similar kind of resistance that Systemd
invited.

Also just to implement support for systemd unit files is basically
handing off your power to others. It is basically playing catch up
instead of coming up with something that you created freely the way you
liked it to be. So I recommend: Do not copy your "enemy".


For me it is important to step back and really consider what is good for
Linux and other operating systems regarding service management and other
system-level topics. Good in the Unix sense of doing one thing fast,
flexible and so on. And good in the sense of using and if need be
creating standards, so that everyone can implement another solution to
replace that part. For example if you had a part that uses control
groups, to have it modular and documented, so that someone could provide
this part ported to FreeBSD using whatever is suitable there. In short:
to develop it in a way that really allows and encourages for a modular
mix-and-match approach.

For me runit currently comes closest to that for a part of the
functionality. But in the end it may even be better to first fairly
evaluate shortcomings and advantages of the existing approaches and then
decide how to move on.


That written of course a systemd unit file to something else converter
can be helpful in order to provide full coverage for all services for
sysvinit, runit and so on. But I´d take the politics out of it.


[1] [systemd-devel] I wonder… why systemd provokes this amount of
polarity and resistance
https://lists.freedesktop.org/archives/systemd-devel/2014-October/
024180.html

Thanks,
--
Martin