On Tue, 27.05.14 16:04, Eelco Dolstra ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
