Hacker News Reader

Comment by jauntywundrkind | Hacker News Reader

Worth pointing out that there's now a second bus in systemd, varlink. https://www.freedesktop.org/software/systemd/man/latest/varl... https://varlink.org/

Varlink is a bit simpler, I'd say. It's more about individual services opening their own listening sockets, although there is an optional broker too. This somewhat simplifies the addressing model, a little. Messages are in JSON.

More and more of the systemd internals are being written or rewritten to rely on varlink for IPC, and the scuttlebutt is that eventually there's a goal to be able to run dbus free.

View on HN

D-Bus will never be removed. Varlink was added because the kernel refused to provide usable IPC primitives, like other OSes have, so a brokered IPC is simply unfeasible in early userspace. So now we have two IPCs that will work in parallel, forever, because such is life on Linux.

It would be hella interesting to me to see internal uses of dbus vs varlink. I don't think the proposition was that dbus is removed or goes away (it's the standard FreeDesktop IPC after all), but the scuttlebutt I ran into was that there was an intent to be able to run without it. That a large part of the systemd mono-repo ought be able to do what it does without it, and especially critical & especially especially boot critical systems. It would be interesting to see & weigh over time which parts have support for which IPC, to see if varlink is indeed growing or converging.

You are 100% dead on, btw; thank you for saying! The overwhelming reason for varlink adoption is early boot, where dbus isn't up yet. That's a crucial fact here.

I think that using JSON is rather inefficient and restrictive compared with using a binary format.

Using complex custom binary encodings is an inefficient use of human's time.

It's error prone. The constraints are well known & optimized for. The binary protocol will also have people implementing their own, poorly. Where-as one can get piping hot SIMD optimized JSON encoder/decoders.

I'm not 100% JSON all the time. But this response strikes me as crufty neckbeardy shit that ignores the obvious & good & uses negativity to step on a pretty clear & straightforward path. Having use d-feet & busctl dozens of times in my life, it's miserable. The encoding scheme is terrible & unpleasant. JSON is an obvious counter reaction, to try to make some damned sense. Given that these bus capabilities are more control plane than data plane (but it's not a hard line), it's ok.

A binary format does not need to be complicated, and does not need to be the same as D-Bus (which has many problems). Furthermore, it can avoid some of the things in JSON, e.g. requiring escaping, requiring Unicode, not properly supporting 64-bit integers, embedded binary data cannot be made directly, etc.

Sure yeah dude, in far off fantasy land it can all be perfect. There's no tradeoffs up in the clouds.

Strikes me as a super bad attitude walking around with your nose way up in the air, leaving these farts behind you as you go. These comments aren't really couched in reality as far as I can see. They don't point anywhere specific, they're just broad swideswipes.

Here in the real world we keep reusing maybe so so protocols because they are scrutable & well implemented & we humans have lots of experience and tools using them.

Reply on news.ycombinator.com