Varlink – IPC to replace D-Bus gradually in systemd • Hacker News Board

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

#271

Post by btreecat » Mon, Oct 07, 2024, 12:02 PM UTC

Netch wrote: post #262

btreecat wrote: post #188

Earlier quoted context omitted.

>No 64 bit integers? No file descriptor transport? No message sequence numbers? Are these required or useful in this context? >Dbus doesn't do something? Extend dbus. How are you so certain that this is the best use of resources, do you have personal XP in the problem domain? > Don't make some other random and worse things. How did you determine that these changes are "worse" or "random?"

> Are these required or useful in this context? At least 64-bit numbers are crucial in any system context.

You're saying you can't think of one context where a trade of between largest supported int value vs total bytes of the message is a reasonable one?

I would encourage you to work with either data at scale or embedded hardware for a fresh perspective.

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

#272

Post by Netch » Tue, Oct 08, 2024, 5:15 AM UTC

btreecat wrote: post #271

Netch wrote: post #262

Earlier quoted context omitted.

> Are these required or useful in this context? At least 64-bit numbers are crucial in any system context.

You're saying you can't think of one context where a trade of between largest supported int value vs total bytes of the message is a reasonable one? I would encourage you to work with either data at scale or embedded hardware for a fresh perspective.

> You're saying you can't think of one context where a trade of between largest supported int value vs total bytes of the message is a reasonable one?

Seems you have pretty misread me. Well, "any system" (where systemd is useful in principle) "context" and not "any" "system context", if I correctly guessed where is your point.

As the whole protocol shall be supporting Linux, in a fully universal manner, support of 64-bit values for pointers (even in crash reports), file offsets (including 32-bit systems), etc. is a must.

> I would encourage you to work with either data at scale or embedded hardware for a fresh perspective.

Thanks, I got used to, different platforms (like ARM) including 32- and 64-bit ones. Also ancient beasts like 6502, PDP-11, and even S/360 (Soviet clones) at good old school times. Beg your pardon, no experience with 8051, 8042, ESP8266 and so on, but they arenʼt in question here. Again, the very topic is full-scale Unix context - more so, closer to desktop/laptop/server, which are nearly always 64-bit now (mainstream distribution vendors deliberately abandoned 32-bit versions for these domains a few years ago), so I donʼt expect much digression.

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

#273

Post by GrayShade » Sat, Oct 12, 2024, 7:17 AM UTC

capitainenemo wrote: post #79

Spivak wrote: post #40

Earlier quoted context omitted.

jq couldn't handle them until relatively recently. This isn't a few bad parsers. You can't assume a json parser will handle bigints correctly and when you're angling to be low-level plumbing and work with every language and software that hasn't been recompiled in years you have to be pretty conservative in what you send.

Yeah, and it isn't like jq is being incorrect in this, the JSON RFCs recommend not using values that can't be represented as a 64 bit float (pasted links to a few RFCs in another response). So if you want to represent a large number safely, better to put it in a string, where special handling can be done after the initial JSON parse without loss of information.

No, it doesn't. It's not a SHOULD.

And why should Qt be concerned with what jq can or can't do? If you're writing and reading back from Qt, the limitations of other implementations don't apply.