Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))

[Ben de Groot]

On 26 May 2013 15:37, Michał Górny <mgorny@g.o> wrote:
> On Sun, 26 May 2013 00:14:36 +0800
> Ben de Groot <yngwin@g.o> wrote:
>
>> Systemd is diametrically opposed to the FreeBSD, customization,
>> extreme configurability, and top-notch developer community aspects of
>> that. Systemd upstream developers have made it abundantly clear they
>> are not interested in working with Gentoo developers to see to the
>> needs of source-based distros. They stand for vertical integration
>> instead of customization and configurability.
>>
>> And you misunderstood: it is systemd that is aggressively opposed to
>> Gentoo. But apparently that doesn't bother some of our developers and
>> Gentoo is becoming more and more welcoming to it.
>
> By the way, we should really keep the separation between systemd itself
> and the unit files. I agree that systemd is not the best thing we could
> have. But the unit file format is, er, good enough -- and has
> the advantage of eventually taking a lot of work from our shoulders.
>
> Although some of the ideas (esp. wrt targets) are near to crazy
> and awfully hard to understand, that's what we have and trying to do
> something else is eventually going to make people's lives harder.
>
> We should *really* work on supporting the unit files within OpenRC
> (aside to init.d files). That's a way to at least:
>
> a) reuse the work that has been done upstream already (when it was
> done),
>
> b) have common service names and startup behavior in all relevant
> distros (which is really beneficial to the users).
>
> Considering the design of OpenRC itself, it wouldn't be *that hard*.
> Actually, a method similar to one used in oldnet would simply work.
> That is, symlinking init.d files to a common 'systemd-wrapper'
> executable which would parse the unit files.

I think this idea actually makes sense. Re-using upstream work seems a
logical idea, and could ease maintenance. Of course the issue is
whether the OpenRC devs see any benefit in this.

> On the completely different topic, I agree that systemd design is far
> from the best and the way it's maintained is just bad. I was interested
> in the past in creating an improved alternative using compatible file
> format and libraries, while choosing a better design, improving
> portability and keeping stuff less integrated.
>
> But the fact is -- I doubt it will make sense, much like the eudev
> project. And it will take much more work, and give much less
> appreciation.
>
> First of all, working on it will require a lot of work. Seeing how
> large systemd become and how rapidly it is developing, establishing
> a good alternative (even dropping such useless parts as the Journal)
> will take at least twice that work.
>
> Then, it will require people working on it. People who know the details
> of various systems and who are willing to spend their time on it.
> And there wouldn't be much of people really willing to work on it.
>
> The systemd haters will refuse the project because of its resemblance
> to systemd. The systemd lovers will refuse it because of its
> resemblance to systemd. And the OpenRC lovers will want to design it
> to resemble OpenRC which is just pointless. Then the few remaining
> people will find systemd 'good enough'.
>
> And even if there are a few people who will want to work on it,
> and design a 'good systemd', they wouldn't get much appreciation.
> Fedora definitely won't care for it. It would have to be really
> definitely awesome for most Linux distros to even notice it.
> And I doubt *BSD people would be interested in something external.
>
> It is possible that systemd upstream will steal a few patches or ideas
> from it. Yet they will never apply any of the really important changes,
> so the project will have to be maintained indefinitely. The only hope
> for it would be to win over systemd users which I doubt will happen.
>
> So there's a lot of work, no fame or money in it, and most likely more
> work being the only future. Anyone volunteering?

I agree it would be pretty hard to carve out a niche for this.
Personally I would see more in runit.

--
Cheers,

Ben | yngwin
Gentoo developer