[Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))

[Ertugrul Söylemez]

Hi there Tobias,

>> One thing most of us seem to agree about [...]
>
> Maybe that's true (I don't see a consensus on the list, only the usual
> sparse FUD. I don't follow IRC) but arguments that start this way
> always give me the willies.

I understand why, but I'm not very good at English rhetoric.  Please
don't let that overshadow the rest of the mail.


>> [...] is that conceptually NixOS does not depend as much on something
>> like systemd as most other distributions do.
>
> "Something like systemd"? Nix doesn't magically make *nix less *nix,
> for better or worse. The meat of systemd is still service management,
> which NixOS needs as much as any distribution.

NixOS needs service *management*, but it doesn't necessarily need a
service *manager*.  In traditional distributions services are managed by
destructive update (enable/disable).  Normally we don't have that.


>> Switching to it was a huge step back from the ideals of NixOS,
>> because it represents all the traditional views on what a system
>> should look like: a giant pile of interconnected mutable variables.
>
> That's what a running system is, though. Immutability *is* just for
> file systems. You plant a pretty tree, and hope it describes a sane
> system that will do the right thing most of the time. Then, something
> will happen that will kick all your pretty algebraic assumptions off
> the table very quickly. Most of your OS is in buggy C, whether you
> like it or not...

The assumptions are not that the programs will do what I expect them to
do, but rather that "two instances of nginx each with one virtual host"
is equivalent "one instance of nginx with two virtual hosts".  This does
not assume anything about the correctness of nginx itself, but it does
help building systems, containers and networks componentwise.


> You seem to have some very nice ideas about describing "services" (or
> something better), if still very rough around the edges. But if you
> can't implement your ideas on top of systemd, so much for
> init-agnosticism. And probably conceptual purity, too.

This may be a misunderstanding.  Init-agnosticism means that the
complexity of translating this concept to an actual set of services that
systemd can work with is the responsibility of a single
function/script/whatever.  We achieve separation of concerns.

Should we, at any point, decide to turn our back on systemd or even just
provide the option to use another manager, then all we need to do is to
reimplement this one function/script/whatever.


> Those who don't understand systemd are doomed to reinvent
> it. Poorly. :-)

I do understand systemd very well and still don't like it.  However,
reinventing it is certainly not something I have planned for the near
future. =)


>> As a final bonus this is so difficult and ugly to solve with systemd
>> that we would feel a much greater temptation to get rid of it. =)
>
> Because your plan is centred entirely around it not being systemd.

Not at all.  It would be a nice bonus, but I doubt that it's going to
happen.  The motivation for my proposal, as the motivation for most of
the things I do right now, is easy, composable, transparent
containerisation as well as a configuration DSL that is easy to reason
about.


Greets,
Ertugrul