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

131–140 of 273 posts

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

#131

Post by bsder »

jchw wrote: post #95
bsder wrote: post #69

Earlier quoted context omitted.

> As for strings, just shove a char[4096] in there. For the love of God, use a proper slice/fat pointer, please. Switching over to slices eliminates 90%+ of the issues with using C. Carrying around the base and the length eliminates a huge number of the overrun issues (especially if you don't store them consecutively). Splitting the base and the offset gives a huge amount of semantic information and makes serializati…

Broadly, I agree with you. C strings were a mistake. The standard library is full of broken shit that nobody should use, and worse, due to the myriad of slightly different "safe" string library functions, (a completely different subset of which is supported on any given platform,) which all have different edge cases, many people are over-confident that their C string code is actually correct. But is it? Is it checkin…

> But at that point, you've basically invented part of Cap'n'proto

The only problem I have with Cap'n Proto is that the description is external to the serialization. Ideally I'd like the binary format to have a small description of what it is at the message head so that people can process messages from future versions.

ie. Something like: "Hmm, I recognize your MSG1 hash/UUID/descriptor so I can do a fast path and just map you directly into memory and grab field FD. Erm, I don't recognize MSG2, so I need to read the description and figure out if it even has field FD and then where FD is in the message."

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

#132

Post by pjmlp »

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.

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

#133

Post by IshKebab »

kentonv wrote: post #77
IshKebab wrote: post #59

Earlier quoted context omitted.

CapnProto is kind of awful though. I had to use it for several years and the API is extremely unfriendly.

Which implementation were you using? (I.e. which programming language?)

C++

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

#134

Post by solarengineer »

markasoftware wrote: post #103
surajrmal wrote: post #96

Earlier quoted context omitted.

Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. If their average message size is small and they don't expect to ever need high volume or large messages, then it's not really likely to be a problem in practice. He also pointed out that they waste far more cycles today on context switches (he suggested something on the order of 6 per IPC message). Even if they eventually c…

> Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. from the guy who brought you binary logfiles!

One can view the binary log files using journalctl.

Per https://systemd.io/JOURNAL_FILE_FORMAT/, the benefits of the binary format are:

The systemd journal stores log data in a binary format with several features:

Fully indexed by all fields

Can store binary data, up to 2^64-1 in size

Seekable

Primarily append-based, hence robust to corruption

Support for in-line compression

Support for in-line Forward Secure Sealing

As a user system-administrator, I see the cryptographic checksum as a benefit of being able to show tampering evidence of on-system log files.

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

#135

Post by xorcist »

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…

But .. how can anyone use strace? That's not JSON. And serialization is cheap!

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

#136

Post by xorcist »

akira2501 wrote: post #88
rkeene2 wrote: post #82

Earlier quoted context omitted.

FWIW, ASN.1 BER supports an indefinite length encoding (though DER does not; ASN.1 JSON and ASN.1 XML do as well)

ASN suffers from some of the other problems regardless of the encoding. I was thinking about this more and I think FTP actually had a lot of the right ideas here. You want two channels. One for fast interactive command messaging and a second one coordinate especially just for bulk transfers arranged over the command channel. The design flaw in FTP of putting these on two separate ports put it immediately in conflict…

One channel, multiplexing, sequenced packets. It looks like you are describing SSH.

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

#137

Post by ChoHag »

pjmlp wrote: post #129
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.

This looks like a joke, naturally D-BUS without JSON is what is preventing Linux on Desktop to take off.

[dead]

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

#138

Post by [deleted] »

markasoftware wrote: post #103
surajrmal wrote: post #96

Earlier quoted context omitted.

Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. If their average message size is small and they don't expect to ever need high volume or large messages, then it's not really likely to be a problem in practice. He also pointed out that they waste far more cycles today on context switches (he suggested something on the order of 6 per IPC message). Even if they eventually c…

> Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. from the guy who brought you binary logfiles!

[deleted]

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

#139

Post by ChoHag »

otabdeveloper4 wrote: post #19
jchw wrote: post #11

Earlier quoted context omitted.

There are a world of serialization formats that can offer a similar interoperability story to JSON or JSON-but-binary formats. And sure, implementing them in every language that someone might be interested in using them in might require complication, but: - Whatever: people in more niche languages are pretty used to needing to do FFI for things like this anyhow. - Many of them already have a better ecosystem than D-B…

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

FFI is the shell's only job.

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

#140

Post by seba_dos1 »

brookst wrote: post #51
anotherhue wrote: post #47

Earlier quoted context omitted.

With this logic (oft repeated) we should be sending TCP as JSON. { sourcePort: 443, destinationPort: 12345,...} Debugability is important but the answer is to build debugging tools, not to lobotomise the protocol for the vanishingly tiny fraction of packets that are ultimately subject to debugging.

I love your TCP over JSON idea. Maybe we can implement layer 2 that way as well, with CSMA/CD: {startTime:2024-09-29T13:56:21.06551, duration:00:00:00.0024, packet: …}

You forgot quotes. JSON has no date or time types :)
Post reply on HN