Svante Signell <svante.signell@???> wrote:

> See above, the DNG mailing list is mostly full of discussions and not
> much actions, except for from a few people.

That is the impression I'd got as well.

Now I'll preface the next bit with ... this is not meant to be an insult or criticism, so please don't take it that way. It's intended to be constructive suggestions from the POV of a sysadmin looking to avoid SystemD - a refugee from Debian Jessie if you like. I'll add that my programming skills these days don't extend much beyond Bash scripting and some SQL. And also add that as a fairly new arrival here, I'm aware that some of the "bits I perceive as missing" may actually be there but I haven't found them yet.

ISTM that the priorities need to be :

1) Get something working !
That means having the systems in place so that the target audience can get a system up and running without too much hassle. And also having all the needed files/packages present.
If in the short term that means having SystemD (or bits of it) then so be it - IMO it's better to have something that works, and a clear strategy for disinfecting it, than to have nothing at all.
I've seen some threads regarding installation issues, so I can see that there is both progress and work still to do there.


2) Get devs on board. As hit on by Svante, that means having the processes in place so that those that are capable and willing to support the project can do so - ie having the systems in place to manage and build the packages.
Just in this thread I've seen evidence that at least one person has their own repository of "fixed" packages. That's great, but for production servers, the PHBs out there expect to see "official" packages that have gone through the projects QA process at least. PHBs tend to get nervous about using packages that have some similarities with the electronic version of "I got it from a bloke in the pub".

2) Get users on board. That needs 1 and 2.


4) Properly disinfect the remnants of SystemD out. Now I've refused to upgrade to Debian Jessie (I tested one server, rolled it back to a backup) because packages I need have added gratuitous SystemD dependencies. The weightings to that decision change significantly when it's "SystemD is there but we're working really hard to get rid of it" vs "shut up it's here to stay".


Notice that there's 2off number 2 there ? I think there's a chicken and egg problem - and a limited time window.
Without the user base, there's perhaps less appeal for devs; without the devs, there's the risk of not providing a compelling "product" for the users.

If it takes too long, refugees from Debian+SystemD will come along enticed by the references in the trade comics/blogs etc - and if there's nothing useful to see then are likely to get disillusioned and wander off. How many times have you seen something announced, there's a lot of buzz (and hype - though not necessarily from the project), and then when reality sinks in it all sort of deflates as potential users find out it "doesn't deliver".
As to timescale, at present Wheezy is in support - and so security updates should still come through. C.f. clamav-daemon has been updated for Wheezy without the libsystemd0 dependency it has in Jessie. So to a large extent I (as a sysadmin) have some legitimate reason why I can hold off "upgrading" to Jessie.
As soon as Jessie+1 is released, then Wheezy becomes unsupported. At that point, it's hard(er) to argue against having to upgrade.


So I'd say ... Yes, remove SystemD please. But it's not the first thing that needs to happen.