Phoronix: Systemd's Network Support Frustrating Some Users
The latest controversy within the systemd camp is the new networkd support that appeared in this week's systemd 209 release. It seems the new systemd-networkd is forced upon users by default and not everyone likes this approach...
I'm all for it if systemd can consolidate all the network functionality. For example on some OSes having the network be managed by one system for desktops and another for servers is ridiculous.
I thought networkd was only meant for embedded systems and servers with static network configuration.
Even as a fan of systemd I think this is the wrong approach. It should just be another service you can enable if you want it. Most people will probably be using NetworkManager anyway.
I think there's one important facet that people are ignoring here... Systemd releases in kind of a vacuum; it doesn't know what your setup is, but its a fairly safe assumption that you will need networking for SOMETHING.
So it enables by default, so what? The only people affected by it will be Distros pre-release and people who compile from source (who most of them are in the first group as maintainers / packagers). Everyone else will encounter systemd 209+ in the form of an update from their distro, who will probably be shipping NetworkManager, and therefore should have systemd-networkd disabled as part of the package update since they already have NetworkManager installed by default in their distros.
Caveat: I'm making the assumption here that Fedora did NOT ship systemd 209 as an update already. If they shipped it, with networkd enabled by default, despite the fact they already have NetworkManager installed by default on ALL their spins then I'm calling human error on the packager and he needs a smackin upside the head.
Zawinski's law of software envelopment:
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
This article is pretty misleading in a few ways. If you drop me an email next time I'd be happy to help you out to make sure you at least get the facts straight (I assume there is no way to dissuade you from including the hyperbole, so I won't even try).
Firstly, I don't really understand what is causing this "frustration" you are writing about. It would be helpful if you would include some details about what problems people have faced, as they apparently have been telling you about it rather than filing bugs. Is it only about seeing a process running, or is there some real measurable ill effects that I need to look into?
There have always been several simple ways to disable networkd. It can be disabled with a compile-time switch. It can be masked with "systemctl mask systemd-networkd" (which is certainly no harder than 'systemctl disable systemd-networkd'). As mentioned before, even when running, it will not do anything unless configured to. At the request of some gentoo developers, we have now made sure that the service can also be disabled in the regular way. There are good reasons why we recommend having networkd running, even if your main network interfaces are configured by something else. A few examples of why this is cool should hopefully appear in the next few days.
You mention two commits, and make it sound like an 'edit-war' is going on. Please not that I was the one who committed both of them (which explains why they were so close to each other in time), so there was nothing controversial going on there.
These commits implement the policy we usually stick to: systemd from upstream will by default behave the way we recommend, but we will not stand in the way of people or distributions doing things differently. Distros can very easily (one line in a .spec/.ebuild file) ship systemd with networkd installed but disabled by default, and even if they don't admins can very easily (one command) disable it.
Hopefully that will make everyone happy
What precisely is networkd? Will it (yet again) replace netctl on Arch Linux? Seems like a waste when netctl seems to be designed to fit well with systemd in the first place.