Is there also a varlink dump utility?
Varlink – IPC to replace D-Bus gradually in systemd
221–230 of 273 posts
Re: Varlink – IPC to replace D-Bus gradually in systemd
#222Earlier quoted context omitted.
But .. how can anyone use strace? That's not JSON. And serialization is cheap !
Do you know what strace is? It's a command that prints the system calls (done via library). So you see write(55, "[1,2,3,4]\n")
Let me try again. You do see
write(55, "[1,2,3,4]\n", 10)
{
"syscall": "write",
"params": {
"fd": 55,
"buf": "[1,2,3,4]\n",
"len": 10
}
}
It can be parsed by any modern language, and deserialization is cheap.
Can we please rewrite strace with this in mind? Preferably in Rust.
Re: Varlink – IPC to replace D-Bus gradually in systemd
#223Related. Others? AllSystemsGo: Varlink Now [video] - https://news.ycombinator.com/item?id=41670431 - Sept 2024 (2 comments) Varlink: Interface description format and protocol for humans and machines - https://news.ycombinator.com/item?id=25621936 - Jan 2021 (5 comments) Varlink – A plain-text, type-safe, discoverable, self-documenting interface - https://news.ycombinator.com/item?id=20950146 - Sept 2019 (10 comments)
Re: Varlink – IPC to replace D-Bus gradually in systemd
#224Why 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
because systemd does what redhat clients ask for, not matter how obnoxious.
Re: Varlink – IPC to replace D-Bus gradually in systemd
#225So 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…
is this true of future desktop uses cases where every basic function will cause a torrent of traffic on that? or you're talking from a server start/stopping services only point of view?
Re: Varlink – IPC to replace D-Bus gradually in systemd
#226I 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 is other problems too, including problems with implementations (including JavaScript, which has a big integer type now but it is not the same type as numbers in JSON). I also think there are problems with the way that the message buses are working. D-Bus has some problems and Varlink has some other problems. And, it isn't true that "the whole world speaks JSON".
Re: Varlink – IPC to replace D-Bus gradually in systemd
#227Earlier quoted context omitted.
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 ju…
I thought about this for a bit. I think largely to do things with messages you don't know about is probably a bad idea in general; writing code that works this way is bound to create a lot of trouble in the future, and it's hard to always reason about from every PoV. However, there are some use cases where dealing with types not known at compile-time is useful, obviously debugging tools. In that case I think the right thing to do is just have a way to look up schemas based on some sort of identity. Cap'n'proto is not necessarily the greatest here: It relies on a randomly-generated 64-bit file identifier. I would prefer a URL or perhaps a UUID instead. Either way, carrying a tiny bit of identity information means that the relatively-niche users who need to introspect an unknown message don't cause everyone else to need to pay up-front for describability, and those users that do need introspection can get the entire schema rather than just whatever is described in the serialized form.
It's better to design APIs to be extensible in ways that doesn't require dynamic introspection. It's always possible to have a "generic" header message that contains a more specific message inside of it, so that some consumers of an API can operate on messages even when they contain some data that they don't understand, but I think this still warrants some care to make sure it's definitely the right API design. Maybe in the future you'll come to the conclusion it would actually be better if consumers don't even try to process things they're not aware of as the semantics they implement may some day be wrong for a new type of message.
Re: Varlink – IPC to replace D-Bus gradually in systemd
#228Hold on, (even though kicking JSON while it's down is funny) how do you make sure that the reply you've got is to the call you issued with this thing? Surely not pinky promise?
Re: Varlink – IPC to replace D-Bus gradually in systemd
#229So 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.
> So Varlink requires a proper specification of message types, but then uses god damn JSON to serialize messages? Why would you do that?
Someone took a look at D-Bus and decided "You know what? It just isn't shitty enough. It's 2024 and D-Bus runs halfway decently on the average laptop. Let's fix that."
I wouldn't be surprised if the Scooby Gang pulled the mask off the head dev, revealing ThePrimeagen, in a scheme of long-form comedy that's a cross between one of his "let's write a network protocol" streams and his new enterprise development satire series.
Re: Varlink – IPC to replace D-Bus gradually in systemd
#230Earlier quoted context omitted.
> 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 ju…
I thought about this for a bit. I think largely to do things with messages you don't know about is probably a bad idea in general; writing code that works this way is bound to create a lot of trouble in the future, and it's hard to always reason about from every PoV. However, there are some use cases where dealing with types not known at compile-time is useful, obviously debugging tools. In that case I think the righ…
> I think largely to do things with messages you don't know about is probably a bad idea in general
Versioning, at the least, is extremely difficult without this.
Look at the Vulkan API for an example of what they have to do in C to manage this. They have both an sType tag and a pNext extension pointer in order for past APIs to be able to consume future versions.