"Enrico Weigelt, metux IT consult" <enrico.weigelt@???> wrote:

>> 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.

Preaching is probably the wrong word to have used. But it clear from reading comments on any article mentioning systemd that a great many people really have no idea why they should care. it's not uncommon to see one comment saying why one person doesn't want to run it (perhaps to do with debuggability when it won't boot), to get a reply along the lines of "I use <distro du jour with systemd> and it works just fine - what's the problem ?"
So there really is a problem to solve there. People are using it, many don't know, but of those who are, they don't see why it's a problem (and in particular, why someone should want to/be able to not use it) because "it works" for them.

>> 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$.

I don't think that's comparable.

>> - 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.

But it's a lot less ongoing effort to keep that support in upstream. Yes you can patch it, but the more embedded systemd becomes, the more patching is needed. Keep/get a critical mass so that upstream devs see a case for keeping the non-systemd stuff, and maintaining the non-systemd distro is less work.
I cannot see a case for saying that (in total) it's less work to patch a package after the fact than it would be to maintain that package in a compatible state to start with.

>> 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.

I think you've missed the point. "Repair and support the original API" isn't an option if the upstream dev wants his package to be runable on a systemd system - because systemd dev policy appears to be deliberately forcing that binary choice of "systemd APIs or nothing" into anything it can. And the team behind systemd have shown that they have no intension of fixing anything when they can better support their aims by deprecating it and bringing something new (and in their eyes, improved) to the table.
If the systemd devs showed the sort of attitude to the rest of the world (devs and users) that others espouse, then there'd be no problem. It's the very fact that they appear to be forcing this binary choice (systemd or nothing) is why we're having this discussion.

That's why I suggest it's important to keep the upstream devs onside - because it's a lot easier to keep support for the traditional APIs etc as an integral part of a package than it is to go through patching after the fact. And it's easier to keep them onside if we can show that there's a large (ie significant) user base for the non-systemd version.

At present it's (I assume) fairly easy to patch out systemd-isms as it's not been around long enough to get major tentacles into most stuff. Over time that will change - systemd will get deeper and deeper into packages, and it will get harder and harder to remove it, and to add in the now missing parts.