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

21–30 of 273 posts

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

#21

Post by otabdeveloper4 »

nbbnbb wrote: post #8
otabdeveloper4 wrote: post #6

Earlier quoted context omitted.

> I'm still not sure why we even need a message bus in there in the first place. Because traditional POSIX IPC mechanisms are absolute unworkable dogshit. > It is one of the worst serialisation decisions we ever made as a society. There isn't really any alternative. It's either JSON or "JSON but in binary". (Like CBOR.) Anything else is not interoperable.

This is a quite frankly ridiculous point. Most of that garb came from the HPC people who built loads of stuff on top of it in the first place. It's absolutely fine for this sort of stuff. It's sending the odd little thing here and there, not on a complex HPC cluster. As for JSON, are you really that short sighted that it's the only method of encoding something? Is "oh well it doesn't fit the primitive types, so just…

> ...it's the only method of encoding something?

If you want something on the system level parsable by anything? Yes it is.

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

#22

Post by jchw »

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.

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.

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

#23

Post by nbbnbb »

otabdeveloper4 wrote: post #21
nbbnbb wrote: post #8

Earlier quoted context omitted.

This is a quite frankly ridiculous point. Most of that garb came from the HPC people who built loads of stuff on top of it in the first place. It's absolutely fine for this sort of stuff. It's sending the odd little thing here and there, not on a complex HPC cluster. As for JSON, are you really that short sighted that it's the only method of encoding something? Is "oh well it doesn't fit the primitive types, so just…

> ...it's the only method of encoding something? If you want something on the system level parsable by anything? Yes it is.

protobufs / asn.1 / structs ...

Edit: hell even XML is better than this!

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

#25

Post by arianvanp »

jchw wrote: post #5
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.

Unfortunately I concur. There are a lot of problems with D-Bus, but that it wasn't using JSON wasn't one of them. The tooling for D-Bus is terrible. It has composite types but they are very primitive, e.g. you can't name fields in a structure without extensions (there's like three different extensions for this.) A lot of the code generators can't actually handle real-world schemas. Now I understand that D-Bus itself…

CBOR is the obvious choice here.

I've suggested it before and the systemd folks didn't seem completely opposed to it. Also because cbor parser is already in the dependencies due to FIDO2 disk unlocking

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

#26

Post by GrayShade »

gmokki wrote: post #17
deivid wrote: post #9

Earlier quoted context omitted.

There was a Varlink talk[0] a few days ago at All Systems Go, in that talk, Lennart mentioned that JSON is unfortunate (primarily due to no 64 bit ints) but it has the surprising benefit of being able to understand the bus messages when using `strace` for debugging. [0]: https://www.youtube.com/watch?v=emaVH2oWs2Y&list=PLWYdJViL9E...

I do not understand where the 64bit integers not working with JSON comes from. JSON the format had no limit on integer size. And all Java JSON libraries I know can handle arbitrary prevsion integers (BigInt) and 32/64bit int/long types when serializing and deserializing. Quick googling shows that also JavaScript has proper support for 64bit integers with their BigInt type, and it can be used to deserialize incoming d…

Qt refused for almost a decade to support deserializing 64-bit integers from JSON because of compatibility concerns.

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

#27

Post by NekkoDroid »

jmclnx wrote: post #20

Does this mean Lunux will need both Dbus and varlink if using systemd ? I ask because I believe Firefox uses Dbus. https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future

systemd has been using varlink for a while now along side dbus, its not something just now being introduced. They don't have a problem living side-by-side.

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

#28

Post by hi-v-rocknroll »

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.

Sigh. Cap'n Proto already exists. Reinventing the wheel yet again because NIH.

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

#29

Post by jchw »

nbbnbb wrote: post #15
jchw wrote: post #13

Earlier quoted context omitted.

Yes but the systemd developers don't want to implement their own protocols with e.g. ACL checking, and given some of their track record I kind of think you don't want them to, either. I'm pretty sure the error conditions would be even more bespoke if they "just" used UNIX domain sockets directly. Don't get me wrong, there's nothing particularly wrong with UNIX domain sockets, but there's no "standard" protocols for c…

Well there sort of is but people don't tend to know or use it. If it's within the same machine and architecture, which should be the case for an init system, then a fixed size struct can be written and read trivially.

C structs are a terrible serialization format, since they are not a serialization format at all. Nothing guarantees that you will get consistent struct behavior on the same machine, but also, it only really solves the problem for C. For everything else, you have to duplicate the C structure exactly, including however it may vary per architecture (e.g. due to alignment.)

And OK fine. It's not that bad, most C ABIs are able to work around this reasonably OK (not all of them but sure, let's just call it a skill issue.) But then what do you do when you want anything more complicated than a completely fixed-size type? Like for example... a string. Or an array. Now we can't just use a struct, a single request will need to be split into multiple different structures at the bare minimum.

And plus, there's no real reason to limit this all to the same machine. Tunneling UNIX domain sockets over the network is perfectly reasonable behavior and most* SSH implementations these days support this. So I think scoping the interoperability to "same machine" is unnecessarily limiting, especially when it's not actually hard to write consistent de/serialization in any language.

* At least the ones I can think of, like OpenSSH[1], Go's x/crypto/ssh[2], and libssh2[3].

[1]: https://www.openssh.com/txt/release-6.7

[2]: https://pkg.go.dev/golang.org/x/crypto/ssh#Client.ListenUnix

[3]: https://github.com/libssh2/libssh2/pull/945

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

#30

Post by nbbnbb »

jchw wrote: post #29
nbbnbb wrote: post #15

Earlier quoted context omitted.

Well there sort of is but people don't tend to know or use it. If it's within the same machine and architecture, which should be the case for an init system, then a fixed size struct can be written and read trivially.

C structs are a terrible serialization format, since they are not a serialization format at all. Nothing guarantees that you will get consistent struct behavior on the same machine, but also, it only really solves the problem for C. For everything else, you have to duplicate the C structure exactly, including however it may vary per architecture (e.g. due to alignment.) And OK fine. It's not that bad, most C ABIs are…

Note within the domain of this problem was the point. Which means on the same machine, with the same architecture and both ends being C which is what the init system is written in.

You are adding more problems that don't exist to the specification.

As for strings, just shove a char[4096] in there. Use a bit of memory to save a lot of parsing.

Post reply on HN