[flagged]
“but its just an init system, you don’t have to use these pieces!“
/s
Here’s a vote for Devuan - you don’t have to accept systemD if you don’t want to. I didn’t.
Varlink – IPC to replace D-Bus gradually in systemd
71–80 of 273 posts
Re: Varlink – IPC to replace D-Bus gradually in systemd
#72Earlier quoted context omitted.
The number type in JSON is 64 bit float, limiting integers without loss of precision to 2⁵³-1. BigInt is a new concept and not technically supported. So whether it works in your random library of choice is probably a potshoot. "Use within JSON: Using JSON.stringify() with any BigInt value will raise a TypeError, as BigInt values aren't serialized in JSON by default. " https://developer.mozilla.org/en-US/docs/Web/Java…
That's not true. The number type in JSON is an arbitrary sized number. You're thinking of JavaScript which is not the same thing.
https://datatracker.ietf.org/doc/html/rfc7493#section-2.2
No.
(which expands on the slightly fluffier text in https://datatracker.ietf.org/doc/html/rfc7159#section-6 which broadly says the same thing... and https://datatracker.ietf.org/doc/html/rfc8259#section-6)
If you look at a parser matrix, flouting this rule is asking for trouble. Which is why the recommendations on MDN for bigint recommend an explicit parsing from a string as needed.
(I'm genuinely curious why this is being downvoted. Does someone out there feel so strongly that because an arbitrary string of characters technically can be parsed as any infinitely large number, that it's wise to ignore RFCs and dozens of existing implementations when making use of JSON as a common interchange format?)
Re: Varlink – IPC to replace D-Bus gradually in systemd
#73Why 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.
Re: Varlink – IPC to replace D-Bus gradually in systemd
#74So does this mean I can shove SQLite databases into the file structure, abstract away an entire SQLite engine into a single header that you are forced to use, and declare that IPC? And you know, since we _are_ already hiding databases within the file structure, why not use it to also unify configuration and installation files too? What could go wrong?
I’m having trouble following what you mean. Yes, you can certainly send a whole SQLite database using any binary communication protocol as a way to exchange data today. You can even compress it before if you feel like it. It will not make for a good ipc format because, well, it’s not designed to be one but it would most definitely work. What’s your point?
There is this one somewhat widely deployed niche system that uses sqlite databases as RPC serialization format. The original idea behind that was limited virtual address space of the CE-based embedded devices, but the design got stuck.
Re: Varlink – IPC to replace D-Bus gradually in systemd
#75Earlier quoted context omitted.
Binder was not even designed for Linux. The primary reason it is used is that (at the time) they wanted to abstract from Linux. "They" here is not Android/Google. Binder also specifies a message format -- even if not fully, since the kernel is going to peek into your message for things like FDs, binder objects, etc. Or your userspace is going to need to "special treat" these fields somehow. It competes in the same sp…
> WTF? Sure you can do on top of even pipes. Even XDR could... Of course, you "can". Implement message-based communication on top of streaming. Emulate blocking calls on top of non-blocking socket API. Implement authentication via ancillary data (try not to throw up in process). Use some clever tricks to solve priority inversion. Somehow distinguish your fds from all others file descriptors to ensure that no confused…
> Of course, you "can".
What is your point here? You claimed that "other IPC solutions" _could not_ do this on top of sockets, but as I've shown and now you admit, you definitely _can_. Obviously I'm not suggesting you roll this by hand, nor claiming that a plain UNIX pipe is a fully featured RPC system; just that there's a million RPC systems out there that do it and don't need anything else than sockets.
Re: Varlink – IPC to replace D-Bus gradually in systemd
#76Earlier quoted context omitted.
Binder was not even designed for Linux. The primary reason it is used is that (at the time) they wanted to abstract from Linux. "They" here is not Android/Google. Binder also specifies a message format -- even if not fully, since the kernel is going to peek into your message for things like FDs, binder objects, etc. Or your userspace is going to need to "special treat" these fields somehow. It competes in the same sp…
Binder was invented at Be, Inc. for BeOS, and many Be refugees joined Android in the early days. (I just learned this recently on HN, so congratulations!)
[deleted]
Re: Varlink – IPC to replace D-Bus gradually in systemd
#77Earlier quoted context omitted.
Sigh. Cap'n Proto already exists. Reinventing the wheel yet again because NIH.
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?)
Re: Varlink – IPC to replace D-Bus gradually in systemd
#78So 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.
As a little bit of perspective, I thought along the same lines when I saw the first web browser. Text was good, but why did they have all these inline images. It was so wasteful of bandwidth.
(also, unix uses files for everything, including /proc talking to drivers!)
Re: Varlink – IPC to replace D-Bus gradually in systemd
#79Earlier quoted context omitted.
Qt refused for almost a decade to support deserializing 64-bit integers from JSON because of compatibility concerns.
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.
Re: Varlink – IPC to replace D-Bus gradually in systemd
#80So 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…
The obvious choice is ASN1 /s