On 11.07.2017 13:55, Simon Hobson wrote:

> There are (IMO) three things needed : >
> 1) Have an alternative - ie Devuan.

And there're other non-systemd-Distros out there. Just collaborate with
them and ignore the others. (we could also set up some tiny patch-
sending bots that penetrate nasty upstreams w/ patches ...)

> In that, I salute those who are actually doing the hard stuff I wouldn't know where to start with.

ACK.

> 2) Make people aware that there is an alternative.

A bit media appearance is fine, but I wouldn't waste too much resources
with that. Better be present on various upstream maillists and post
systemd-removing patches there.

> 3) Explain (in rational, technical, non-political) terms why people should care that there is a choice - and why we think they would be wise to take it.

I wouldn't waste time on that. They have to learn by themselves -
preaching doesn't help.

> Without 2 and 3, there won't be large scale adoption of the alternatives

NAK. 1) is enought.
In the past we fought bigger dragons, eg. getting free from M$.

> - and without that, there is distinctly less incentive for the upstream devs to keep support for the alternatives.

Optional. We patch out the crap for packages we need, and drop those we
don't need. Forget about Gnome3 - let it die alone and silent, as it
deserves.

> As has been mentioned before, part of the "battle plan" for systemd
> seems to be to keep taking more and more "standard stuff", deprecate
> it, and introduce new systemd versions with a new API. Thus, a package
> they needs to run on a systemd infested system has to support the
> "new improved" API.

Just patch out the crap. And ignore the totally broken packages that
aren't worth the effort.

> do they keep support for the old API ? To do so means more work -
> effectively they have to maintain two bits of code everywhere
> they use that function, and that means more work.

Not, quite. Just rapair and support the original API - drop the
systemd crap entirely.

> If that happens, then the job of maintaining that package in a
> non-systemd distro becomes harder.

Well, partial / downstream fork is more work, but all we need is to
be consequent. Of course, we should directly cooperate w/ other
systemd-free distros.


--mtx