Systemd's Networkd Now Supports Bridging

[phoronix]

Phoronix: Systemd's Networkd Now Supports Bridging

The latest feature of systemd is its networkd component now supporting network bridging...

http://www.phoronix.com/vr.php?view=MTUyNjY

[profoundWHALE]

Finally! I like to bridge every once in a while, so it's nice to know that it'll be available.

[-MacNuke-]

Hmm, never heard of networkd before. Will this be a replacement for NetworkManager?

[89c51]

Hmm, never heard of networkd before. Will this be a replacement for NetworkManager?

I read that they target basic stuff and not the advanced things you can do with NM.

[kertoxol]

Next on systemd: alsad, pulseaudiod and waylandd. Oh, and linuxd.

[Rexilion]

I read that they target basic stuff and not the advanced things you can do with NM.

Since when is bridging considered basic? If bridging is basic, then also include DHCP (already there) and a WPA client.

Systemd assimilated udev, sysvinit and dbus. Tell me, what is stopping them from going forward to NetworkManager?

[prodigy_]

Next on systemd: alsad, pulseaudiod and waylandd. Oh, and linuxd.

In full accordance with the UNIX principles systemd is written to do one thing...

[Teho]

Hmm, never heard of networkd before. Will this be a replacement for NetworkManager?

It's meant for initrds, containers and servers so pretty much everything that NetworkManager is not used. The ConnMan developers from Intel have contributed dhcp client for systemd (libsystemd-dhcp) that will be used by at least systemd-networkd and ConnMan in the future. They also plan to use libsystemd-bus (dbus client) and its event loop. The plan is to push the shared components between ConnMan and systemd-networkd to systemd but the one will not replace the other.

Tell me, what is stopping them from going forward to NetworkManager?

Nothing. It's just not something they are planning to do. The project is done in collaboration with ConnMan developers.

I have a little bit different viewpoint here. I do not look at what are the low-level technical tasks or the implementation, I look at the users. We have two types of users for networking. The first type is sysadmins and the second type is end users. These two groups are as different as it gets in their use cases and how they expect things to be done.

When I look at sysadmins, then you target servers, datacenters, could and containers. So headless systems that are not mobile. They are mainly Ethernet based and configure once and not worry about anymore. As an extra added benefit some of these have to configure everything as early as the initramfs. And they want simple configuration files and command line tools.

Looking at end users, I see desktop, laptops, phones and all these embedded devices like thermostats, fridges and whatever you can think of. Things where networking can mean also WiFi, cellular even sensor networks like Bluetooth 6loWPAN. It is a dynamic world and needs configuration that is targeted for non-technical people. And end users need a nice UI for their needs. It is also not one UI, there will be many and so APIs need to be simple and designed for that user base in mind.

You normally do not take your 12-core Xeon server to the coffee shop around the corner and want to use its public WiFi with a hotspot login. If you do, please take a picture

Trying to smash these together seems rather crazy to me. I looks simple in the beginning, but the devil is in the details. There is a reason why ConnMan stayed out of the datacenter world. So the way I see it is that networkd should own the initramfs and sysadmin side of things. And ConnMan will handle the end user side. What this means is that both work in harmony together.

Think of it like this, the system boots with networkd in initramfs and then you either start networkd for taking over the initramfs configuration and running in datacenter mode. Or you start ConnMan for running in desktop mode. It is a little bit over-simplified, but I think you get the basic idea.

So networkd and ConnMan for example will share a lot of code. And what we will be doing is to contribute the shared pieces into networkd. One prime example is DHCP of course. And the rest we will figure out as networkd progresses.

-Marcel Holtmann, ConnMan developer

In full accordance with the UNIX principles systemd is written to do one thing...

Like with virtually everything in systemd, systemd-networkd does one thing. It shared code with other systemd components and takes use of the features that it provides but it's still separate component. The people who don't like this aspect of systemd must really hate BSDs, I mean they even cram kernel together with init and network management! /s.

[prodigy_]

Like with virtually everything in systemd, systemd-networkd does one thing. It shared code with other systemd components and takes use of the features that it provides but it's still separate component. The people who don't like this aspect of systemd must really hate BSDs, I mean they even cram kernel together with init and network management! /s.

BSDs have their issues. But having a corporation that tries to hijack the whole system by writing an init replacement that is incidentally a dependency for everything else is not among those issues.

[Teho]

BSDs have their issues. But having a corporation...

Corporation? You do understand that systemd-networkd is developed by Tom Gundersen, an Arch Linux developer, and the dhcp stuff is written by Intel? Also systemd as a whole is collaboratively developed project with ever increasing number of contributors.