On Tue, 11 Jul 2017 14:02:47 +0100, Simon wrote in message <98028782-f385-412e-aeab-2edf14663...@thehobsons.co.uk>:
> "Enrico Weigelt, metux IT consult" <enrico.weig...@gr13.net> 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng