On Tue, 11 Jul 2017 14:02:47 +0100, Simon wrote in message
<98028782-F385-412E-AEAB-2EDF146634F1@???>:

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


..we _could_ "preach" by testing for systemd features and throw warning
screens in the faces of the downstream etc users, and offer info links
(and/or buttons) and an "I know WTF I am doing."-button to click thru.


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


..sometimes, with certain people, this is not a viable option,
that's _when_ we need to fork these packages.


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


..that's _why_ these upstream packages needs to be forked, by us.


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


--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.