Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Varlink – IPC to replace D-Bus gradually in systemd

varlink.org

Post reply on HN
Print view View original

251–260 of 273 posts

Re: Varlink – IPC to replace D-Bus gradually in systemd

#251

Post by thiel_is_hitler »

poettering wrote: post #125
newpavlov wrote: post #3

So Varlink requires a proper specification of message types, but then uses god damn JSON to serialize messages? Why would you do that? Apparently, we don't have enough wasted cycles in modern software, just add a bunch more in a fundamental IPC infrastructure.

The marshalling cost for JSON is negligible. Yes, it might be a bit slower than GVariant for example, but only by some fractional linear factor. And on small messages (which D-Bus currently always is, due to message size constraints enforced by broker) the difference is impossible to measure. To a point it really doesn't matter, in particular as JSON parsers have been ridiculously well optimized in this world. What d…

[dead]

Re: Varlink – IPC to replace D-Bus gradually in systemd

#252

Post by cryptonector »

RandomThoughts3 wrote: post #236
cryptonector wrote: post #206

Earlier quoted context omitted.

If it's IPC, it's the same architecture (mostly; typically there's at most 3 local architectures). The receiver can always make right. If there's hidden remoting going on, the proxies can make things right.

> The receiver can always make right. Certainly but that’s hardly structs anymore. You are implicitly defining a binary format which is aligned on the sender memory layout then.

It's "structs" when the sender and receiver are using the same architecture, and if they're using the same int/long/pointer sizes then the only work to do is swabbing and pointer validation / fixups. That's a lot less work than is needed to do just about any encoding like protocol buffers, but it's not far from flat buffers and capnp.

Re: Varlink – IPC to replace D-Bus gradually in systemd

#253

Post by zzo38computer »

dezgeg wrote: post #240
zzo38computer wrote: post #226

I think that there are problems with both Varlink and D-Bus. JSON is one of them but not only one. One of the problems with JSON is the data types it uses. There is no support for character codes other than Unicode (I think that "Unicode string types considered harmful"; they are not needed for handling text (even Unicode text)), and binary data must be encoded as hex or base64, which just makes it inefficient. There…

Yeah, using serialization format that doesn't even have obvious way of representing every possible Linux filename (nothing mandates filenames to be valid UTF-8, only thing they can't contain is NUL and '/') seems bad fit for low-level system services. I can't wait to have apps and services crash and burn left and right due to accidentally (or maliciously) created non-UTF8 filenames in world readable directories.

> Yeah, using serialization format that doesn't even have obvious way of representing every possible Linux filename

That is hardly the only problem with such a serialization format, although it is one of them.

> I can't wait to have apps and services crash and burn left and right due to accidentally (or maliciously) created non-UTF8 filenames in world readable directories.

It is not only accidentally or maliciously. Sometimes it may also be done deliberately because it is a character set other than Unicode, without the intention to be malicious.

(A user might also deliberately want to display file names using a different character set, perhaps in order to ensure that all characters can be displayed unambiguously. Of course, this is not necessarily what everyone intends, but some people will.)

Re: Varlink – IPC to replace D-Bus gradually in systemd

#255

Post by otabdeveloper4 »

jchw wrote: post #22
otabdeveloper4 wrote: post #19

Earlier quoted context omitted.

Sorry, but bash isn't a "niche language" and it doesn't have an FFI story.

I don't know how to tell you this, but, you don't need to implement an RPC protocol in bash, nor do you need FFI. You can use CLI tools like `dbus-send`. I pray to God nothing meaningful is actually doing what you are insinuating in any serious environment.

I'm trying to tell you that something that isn't straceable and greappable shouldn't belong in your system services stack.

Re: Varlink – IPC to replace D-Bus gradually in systemd

#256

Post by guappa »

pjmlp wrote: post #205
guappa wrote: post #195

Earlier quoted context omitted.

That was 15 years ago? I was talking about the usage today.

And I was being sarcastic, as there are things much more relevant to spend brain cells on.

Wasn't sarcasm frowned upon here?

Re: Varlink – IPC to replace D-Bus gradually in systemd

#257

Post by manuel_w »

xarope wrote: post #234

Someone explain to me please, how type-safe and JSON can even exist in the same sentence? JSON has so many edge cases for handling numbers, floats, bools etc. Why would you not use gRPC or even something like CapnProto if you want to maintain that type-safety-ness?

Which edge cases do you mean? Are you confusing it with YAML? I know YAML has some serious footguns [1]. In JSON I'm not aware of any.

[1] https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...

Re: Varlink – IPC to replace D-Bus gradually in systemd

#258

Post by basique »

poettering wrote: post #125
newpavlov wrote: post #3

So Varlink requires a proper specification of message types, but then uses god damn JSON to serialize messages? Why would you do that? Apparently, we don't have enough wasted cycles in modern software, just add a bunch more in a fundamental IPC infrastructure.

The marshalling cost for JSON is negligible. Yes, it might be a bit slower than GVariant for example, but only by some fractional linear factor. And on small messages (which D-Bus currently always is, due to message size constraints enforced by broker) the difference is impossible to measure. To a point it really doesn't matter, in particular as JSON parsers have been ridiculously well optimized in this world. What d…

i honestly don't really get the angle of debugging via strace - i'd much rather prefer something more wireshark-like, where I can see all messages processes are sending to each other, since that would make it easier to decipher cases where sending a message to a service causes it to send other messages to its backends

Re: Varlink – IPC to replace D-Bus gradually in systemd

#259

Post by Communitivity »

poettering wrote: post #125
newpavlov wrote: post #3

So Varlink requires a proper specification of message types, but then uses god damn JSON to serialize messages? Why would you do that? Apparently, we don't have enough wasted cycles in modern software, just add a bunch more in a fundamental IPC infrastructure.

The marshalling cost for JSON is negligible. Yes, it might be a bit slower than GVariant for example, but only by some fractional linear factor. And on small messages (which D-Bus currently always is, due to message size constraints enforced by broker) the difference is impossible to measure. To a point it really doesn't matter, in particular as JSON parsers have been ridiculously well optimized in this world. What d…

The marshalling cost might be negligible for come use cases, but the bandwidth usage definitely is not. I think the best interface description protocol is one where the serialization format is unspecified. Instead, the protocol describes how to specify the structure, exchange sequences, and pre/post-conditions. A separate document describes how to implement that specification with a certain over the wire format. That way the JSON folks can use JSON when they want (unless they are using large longs), and other folks can use what they want (I like CBOR).

Re: Varlink – IPC to replace D-Bus gradually in systemd

#260

Post by loa_in_ »

pjmlp wrote: post #132
nly wrote: post #73

Why don't they just adopt the same fundamental IPC design as Wayland? Swap out the root wl_display singleton object for something dbus appropriate and away you go? More or less all the display specific stuff is an extension on top of the core design. https://wayland-book.com/protocol-design.html

That would be going full circle, given that D-Bus was predated by Bonono on GNOME side, and DCOP on KDE, which was based on X11 Inter-client communication. D-Bus evolved from merging their needs into a single approach.

But would that be necessarily bad? It's like merging back a long detached branch in version control
Post reply on HN