So the advantage is supposedly that it's extremely simple (just NUL-terminated JSON over a stream socket!) except that, when you look at the spec, it's actually not that simple, so they have only implemented a subset, and then they have also extended it with more features, so in the end it's not simple and not really even Varlink?

And it's now 40% slower at serialization and it can't embed binary data, but that's OK because now "web native folks" can be OS infrastructure developers without learning a new format? Except the interface definition format, which is not JSON, but for some reason the wire format has to be.

And all the D-Bus stuff, with all the problems enumerated in the presentation, will still be kept around, so we'll have D-Bus + systemd's "quite different" D-Bus variant + Varlink + systemd's Varlink variant that "does not bother with" the spec but has "additions", all at the same time.

It doesn't sound "extremely simple" to me.

Why bother with Varlink IPC, and why now?

The Varlink IPC has been around for a while, but recently we started using it heavily in systemd. In this talk I'd like to explain what Varlink IPC is, and why we are now adopting it so heavily. And I also want to explain why I think that Varlink is a good candidate as IPC of choice for any Linux software, both low-level and higher-level. We'll compare it with D-Bus in particular, and highlight where it shines (and where it doesn't shine so much).