[gnoack]

I think you are misrepresenting this;

Varlink is based on much more conventional UNIX technology than Dbus, which is decades old: You connect to a named UNIX socket through its socket file in the filesystem (man page: unix(7)).

This is an old mechanism and it is known to work well. It does not require a broker service, it works right at system startup, and it does not require a working user database for permission checks (which would be a circular dependency for systemd in some configurations). If at all, I am surprised that systemd didn't use that earlier.

The main thing that Varlink standardizes on top of that is a JSON-based serialization format for a series of request/response pairs. But that seems like a lightweight addition.

It also does not require kernel support to work, the kernel support is already there. He mentioned in the talk that he'd like to be able to "tag" UNIX sockets that speak varlink as such, with kernel support. But that is not a prerequisite to use this at all. The service discovery -- and he said that in the talk as well -- is simply done by listing socket files in the file system, and by having a convention for where they are created.

[direwolf20]

What do you connect to, when you connect to varlink, if there is no broker service?

[ahartmetz]

It's kinda weird to present this as a DBus alternative when it doesn't even offer the same facilities, particularly many-to-many communication.

Though I have a pretty good idea of where a Varlink broker would turn up and which init system it would be tied to.

[direwolf20]

Very typical systemd–developer style.

[gnoack]

Those are pathname UNIX domain sockets, so you address them through the socket file, which is conventionally stored somewhere under /run.

You can run "netstat --listening --unix" to list the UNIX domain servers on your system, to get an impression.

See https://man7.org/linux/man-pages/man7/unix.7.html

[direwolf20]

And what does the socket connect to?