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

211–220 of 273 posts

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

#211

Post by guerrilla »

deng wrote: post #200
guerrilla wrote: post #196

Earlier quoted context omitted.

He's living churn. It's just constant change often for gains that don't matter to a lot of people and losees that do. Linux is radically different because of him. People were deeply invested in how things were. Think about how hard it is to learn a laguage as an adult compared to when you're a kid. Even when some of his stuff is amazing, it's still going to cause stress for a lot of people due to its radical nature.

D-Bus is 17 years old by now, introducing a replacement is hardly "living churn", especially since D-Bus will still be supported, probably for years.

If that were all it is, I'd agree but you may have missed the constant stream of other radical changes over the years.

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

#212

Post by Joker_vD »

packetlost wrote: post #203
Joker_vD wrote: post #201

Earlier quoted context omitted.

> CBOR would be a better choice, you aren't limited to IEEE 754 floats for your numeric types. The other side of this coin, of course, is that now you have to support those other numeric types :) My usual languages of choice somehow don't support "negative integers in the range -2^64..-1 inclusive".

I mean, you don't have to support those? You still would need something on the other end to produce that type of datatype, which can be documented that it will never happen: you're making an interface anyways. The problem is if you literally don't have the option to represent common datatypes it will be a problem, not a hypothetical one just because the encoding layer can support it. Those are different problems.

And JSON, technically, allows use of unlimited-precision fractions, but also allows implementations to set arbitrary limits (it actually does, you're not required to parse JSON numbers as doubles). So the situation is not really different from CBOR, isn't it? Just™ make both sides to agree to stick to some common subset (e.g. integers-in-int64_t-range-only for some fields) and you're done; no need to support double-precision floating point numbers.

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

#213

Post by kentonv »

bsder wrote: post #131
jchw wrote: post #95

Earlier 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…

But how do you know that the field called "FD" is meaningful if the message is a totally different schema than the one you were expecting?

In general there's very little you can really do with a dynamic schema. Perhaps you can convert the message to JSON or something. But if your code doesn't understand the schema it received, then it can't possibly understand what the fields mean...

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

#214

Post by [deleted] »

cryptonector wrote: post #209
RandomThoughts3 wrote: post #149

Earlier quoted context omitted.

> That's very wrong. ASN.1 is complicated because it's quite complete by comparison to other syntaxes So, it's quite complicated. Yes, what I have been saying from the start. If you start the conversation by "you can define a small subset of this terrible piece of technology which is bearable", it's going to be hard convincing people it's a good idea. > Cavalier attitudes like "ASN.1 is too complicated" lead to bad r…

> So, it's quite complicated. Subsets of ASN.1 that match the functionality of Protocol Buffers are not "quite complicated" -- they are no more complicated than PB. > Still, ASN.1 is a telco protocol through and through. Not really. The ITU-T developed it, so it gets used a lot in telco protocols, but the IETF also makes a lot of use of it. It's just a syntax and set of encoding rules. And so what if it were "a telco…

[deleted]

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

#215

Post by packetlost »

Joker_vD wrote: post #212
packetlost wrote: post #203

Earlier quoted context omitted.

I mean, you don't have to support those? You still would need something on the other end to produce that type of datatype, which can be documented that it will never happen: you're making an interface anyways. The problem is if you literally don't have the option to represent common datatypes it will be a problem, not a hypothetical one just because the encoding layer can support it. Those are different problems.

And JSON, technically, allows use of unlimited-precision fractions, but also allows implementations to set arbitrary limits (it actually does, you're not required to parse JSON numbers as doubles). So the situation is not really different from CBOR, isn't it? Just™ make both sides to agree to stick to some common subset (e.g. integers-in-int64_t-range-only for some fields) and you're done; no need to support double-p…

Huh, I went and referenced the ECMA JSON spec and you're right that it treats numbers only as sequences of digits which would make these effectively the same problem

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

#216

Post by thayne »

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…

What if varlink supported both JSON and a subset of cbor with the "cbor data follows" tag at the beginning (so the server can determine if it is json or cbor based on the beginning of the message)?

It would add a little complexity to the server, but then clients can choose if they want to use a human readable format that has more available libraries or a binary format.

As for strace, tooling could probably be added to automatically decode cbor to json, either as part of strace, or in a wrapper.

There could also be a varlink proxy (similar to varlink bridge) that could log or otherwise capture requests in a human readable format.

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

#218

Post by Retr0id »

akira2501 wrote: post #60
arianvanp wrote: post #25

Earlier quoted context omitted.

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

I genuinely dislike CBOR. Formats which require me to calculate the length of the message before sending it lead to bad library design which often leads to easily compromised code. Add in an "indefinite length" option and you've got potentially unbounded client memory usage to watch out for. As if that wasn't enough you get extensible tags so the meaning of any message is entirely dependent on the context it was sent…

I'm a fan of DAG-CBOR, which is a deterministic subset of CBOR with most of the weird bits excluded (like indefinite lengths, multiple floating point formats, etc.), but it can still represent any sensible JSON object.

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

#219

Post by petre »

Spivak wrote: post #111
userbinator wrote: post #100

Earlier quoted context omitted.

It doesn't matter what the rate is. Of all the things they could do, they decided to choose one of the worst possible formats for IPC data[1], maybe to pander to the web crowd. [1] Maybe XML would be a close competitor.

It's the lingua-franca serialization format that has bindings to every programming language already, doesn't require agreeing on the payload layout beforehand, is beyond overkill for the task being asked of it, and is human debuggable over the wire. I'm begging you to read the format it's replacing. https://dbus.freedesktop.org/doc/dbus-specification.html Ctrl+f Type System. JSON is beautiful, elegant, and minimal by…

> JSON is beautiful, elegant, and minimal by comparison.

True, but binary formats like CBOR or MessagePack are also that and efficient and have support for binary strings. This JSON is human readable thing is the nerverending argument of high level programmers. Anyone can read hex given enough time.

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

#220

Post by tssva »

orbisvicis wrote: post #198
solarengineer wrote: post #134

Earlier quoted context omitted.

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 Sealin…

> Primarily append-based > Seekable Text logs are append-based and seekable as well. > Support for in-line Forward Secure Sealing I once typed an SSH password in the username field, and the only way to erase that was to erase all the logs. So this has some significant downsides. Also, I am tired of waiting minutes for a journalctl query to load.

> I once typed an SSH password in the username field, and the only way to erase that was to erase all the logs. So this has some significant downsides.

I hope this was a personal system. Changing logs in this manner would have almost certainly led to your dismissal anywhere I ever worked. This anecdote just re-enforces the need for Forward Secure Sealing.

Post reply on HN