Systemd Looking At A Future With More Varlink & Less D-Bus For IPC

[Espionage724]

leave it to systemd to get away from well polished solutions like dbus and infest my system with this bloated nonsense...

Darn systemd-malware may as well be it's own CVE website

[Vermilion]

[...] but the decision-making process is rarely based on technical merit - instead, it is political/ideological.

Is it really that there is no technical merits, or is the technical reasoning there in the open but people are too lazy to check, so they chalk it up to politics/ideology? Did you by chance bother to watch the linked presentation in which Lennart explained their reasoning, or at least skim through the slides?

[Vorpal]

After reading through the slides, most of it seems sensible. The only real issue I see is motivating JSON with "web native", which doesn't really seem relevant for this use case? On the other hand, JSON is probably going to be "fine" here, as far as I know systemd IPC tends to be about smaller control messages, not bulk data transfer. It is also not latency critical (we are not sending real time audio over JSON). Lack of 64-bit integer support is likely a bigger issue though. On the plus side, it makes it easy for a human to inspect and debug without specialised tools.

Not something I'll likely adopt in my own software (due to these issues), but for systemd it is going to be ok.

[gmokki42]

[QUOTE=Vorpal;n1494700]Lack of 64-bit integer support is likely a bigger issue though. On the plus side, it makes it easy for a human to inspect and debug without specialised tools.

JSON has no limitation foe integer sizes, you can use 128bit integers if you want.

All Java implementation I have seen allow parsing integers of arbitrary length, or optimize for fixed length if you know the maximum size.

And even the ugly JavaScript default parser has a proper way to parse 64bit integers as BigInts, or alternatively one uses some 3rd party library to do the parser.

[reba]

From the benchmarks posted above I get JSON is "quite good" to "quite okay". It is neither very slow (which I would have guessed, but it's not) to serialize and neither to de-serialize. YAML is the worst here (of course), binary protocols the fastests (of course), but JSON stands up for itself well.

Then JSON is something machines and humans can understand very very well as it's self-describing, not too difficult to create and understand and has a huge toolset in its ecosystem.

With addiitons like text-compression one can produce very very small messages if needed.

With JSON Schema one can validate the structure, every field, every piece of data and what you like (like XML Schema) to ensure the messages you create and receive conform to a defined standard and it also has a great tool support.

So +1 from me for choosing JSON.

[discordian]

I was tempted to look at state-of-the-art JSON parsing, I knew about RapidJSON claiming roughly strlen performance, but this one is even crazier: https://github.com/simdjson/simdjson

if someone manages to hook this up with https://github.com/jorgen/json_struct , then stuff like MessagePack/CBOR seems pretty redundant (use plain strutcs/flatbuffers on the "performance" end, or simd_json_struct at the "convienient" end)

[iznogood]

I think they are moving in the wrong direction using json for this.
Also still not sure why everyone hates dbus

[varikonniemi]

I think they are moving in the wrong direction using json for this.
Also still not sure why everyone hates dbus

that was also my first reaction, but after considering all the arguments it seems fine in all other aspects except that it adds yet another ipc system to the OS.

[ahrs]

my guess is web compatibility. at least it was mentioned in the slide.
but well.... i guess web is the reason why we can't have nice things anymore

The web already has a solution to that, it's called "Accept: application/json". I don't know why an IPC mechanism couldn't support format negotiation of some sort.

Is the web even a real concern though? DBus is seldom exposed to the web even though it's a networked service so theoretically could be. What from the web world would need this? Web software like Cockpit maybe?

[fitzie]

I think they are moving in the wrong direction using json for this.
Also still not sure why everyone hates dbus

do you program dbus? infrastructure programming is mostly json these days with some notable xml holdouts like aws and libvirt.