[systemd-devel] [PATCH 17/17] networkd: add dhcp server support

[Lennart Poettering]

On Tue, 27.05.14 16:04, Eelco Dolstra (eelco.dolstra at logicblox.com) wrote:

> > I am very sure this should be in networkd. 
> [snip]
> 
> That sounds reasonable. However, to be honest, I've never really understood why
> networkd needs to be part of systemd in the first place. It seems to
> me that it

Well, it shares a lot of code with the rest of systemd, and the rest of
systemd inetgrate with it in many ways. For example, timsyncd is able to
follow network state changes and only do NTP when  there's actually an
IP address up. Or it can recieve NTP servers via DHCP, and so on. 

or you have all that integration for the initrd and the early boot environment.

> would work just as well as a separate package with its own
> releases. To me as a

No, it wouldn't, we couldn't share much of our code, we couldn't simply
rely on the various interfaces between the components, we'd enter
dependency hell. 

The reason why something like networkd so quickly became useful and at
its minimal footprint is precisely that we can share so much code and
systemd's trove of utility functions makes it so easy to write code.

> downstream that would be preferable, since such a package can be upgraded
> (mostly) independently from systemd. For instance, in NixOS we can upgrade
> dhcpcd or wpa_supplicant pretty much in isolation from the rest of the system;
> but getting the latest networkd would require getting the latest systemd, which
> is typically a much bigger step since it potentially impacts much more of the
> system.

Well, philosophically, I think the major weakness of the current Linux
system is the fact that everything can be upgraded completely
independently. That makes it incredibly hard to test anything it
explodes the test matrix, annd it makes it equally hard for developers
to target the OS, since they never know what they will be runnin on.

You are welcome to split systemd up into multiple packages when you
package it, but it's an absolute requirement that you always update them
in sync. 

> You often point out (correctly) that systemd is not monolithic as it consists of
> dozens of separate programs. But it *is* a monolithic package: those dozens of
> programs can only be upgraded as a set.

Well, that's a weird definition of "monolithic". But yeah, we
*absolutely* require that systemd and its components is updated in
sync. That's a core design principle of what we do.

> > Remember that the goal here is not to write another ldap enabled
> > monstrosity. 
> 
> A package becomes a monstrosity one "small" feature at a time. (And one person's
> bloat is another person's essential feature.) For instance, networkd currently
> lacks a WPA supplicant, which you surely need in a modern system. So should
> systemd accrete a WPA supplicant? How about Bluetooth support? Etc. etc. I mean,
> is there any concrete criterion about what should or shouldn't go into systemd?

That is always a good question, and a hard one to answer. But it's
usually a question of specific vs. generic. IP configuration and stuff
is generic, inherently so. Hardware like Bluetooth is specific in my
eyes, so it's beyond the line.

But yeah, systemd is a *platform*, and we will cover the bits sooner or
later, than the ajority of systems will obviously need. And for me DHCP
is one of those things...

Lennart

-- 
Lennart Poettering, Red Hat