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

171–180 of 273 posts

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

#171

Post by orf »

There is something impressive about Lennart’s work, in that treads a thin line between “completely triggering” to some people and “genuinely quite a good idea” to others.

Lots of discussion here has been around the choice of JSON as a format, with some valid points being brought up about specific limitations and possible footguns.

But these miss the point: this massively moves the needle with regard to lowering the barrier to entry when writing services. I’m confident I can write a simple Varlink service in about 20 lines of Python, with no dependencies after reading the linked docs. You cannot in good faith say the same thing about dbus.

That’s nuts. Yeah - if my service is for some reason sending/receiving high-precision 128 bit numbers or huge binary files then it’s not perfect.

But nothing really does that. It’s not worth making the entire stack more complex and less performant for a possible use case that doesn’t really fit.

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

#172

Post by criticalfault »

djbusby wrote: post #86
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...

Cool, readable messages in strace but still some odd binary log format?

He explained it here

https://news.ycombinator.com/item?id=41694711

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

#173

Post by jabl »

quotemstr wrote: post #112
cryptonector wrote: post #107

Earlier quoted context omitted.

That "convoluted telco/ITU-T style" yields amazingly high quality specifications. I'll take X.68x / X.69x any day over most Internet RFCs (and I've written a number of Internet RFCs). The ITU-T puts a great deal of effort into its specs, or at least the ASN.1 working group did. ASN.1 is not that complicated. Pity that fools who thought ASN.1 was complicated re-invented the wheel quite poorly (Protocol Buffers I'm loo…

For our sins, our industry is doomed to suffer under unbearable weight of endless reinvented wheels. Of course it would have been better to stick with ASN.1. Of course we didn't, because inexperience and hubris. We'll never learn.

One thing I liked about a Vernor Vinge sci-fi novel I read once was the concept of "computer archeologist". Spool the evolution of software forwards a few centuries, and we'll have layers upon layers of software where instead of solving problems with existing tooling, we just plaster on yet another NIH layer. Rinse and repeat, and soon enough we'll need a separate profession of people who are capable of digging down into those old layers and figure out how they work.

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

#174

Post by ahartmetz »

eviks wrote: post #119
quotemstr wrote: post #108

Christ almighty, I have seldom seen a technical proposal as bad as this one. I want off Mr. Poettering's wild ride. No 64 bit integers? No file descriptor transport? No message sequence numbers? Just cut it out already. Dbus doesn't do something? Extend dbus. Don't make some other random and worse things.

> Extend dbus. How would you address the issue of dbus unavailability in early boot listed in the presentation via extension?

How have we survived without such a feature up to now?

It is a common occurrence that whatever Lennart comes up with fulfills several, erm, novel requirements while not fulfilling some old ones that aren't even mentioned. The parallels to binary logging are there. "Fancy" features that no one asked for - check. Simplicity and thoughtful use of existing functionality (the "full exploitation" principle of the Unix design philosophy) - nope.

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

#175

Post by jcelerier »

KerrAvon wrote: post #118
nly wrote: post #70

Earlier quoted context omitted.

It's not the data format that is important, but the tooling, code generation and binding quality.

Data format is absolutely important for operating system IPC. JSON is raw text. Messages occupy more RAM than a binary format, which increases your working set, and it requires at least some nontrivial parsing. This ultimately limits the number of messages you can send per second.

It's not that simple:

    [1.2,1.3,1.4]
is 13 bytes, the equivalent binary storage is 3*sizeof(double) (24 bytes) + whatever overhead exists for representing a dynamic array in your language

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

#176

Post by otabdeveloper4 »

nbbnbb wrote: post #23
otabdeveloper4 wrote: post #21

Earlier quoted context omitted.

> ...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!

You don't quite understand how this works.

One requirement is being able to strace a misbehaving service and figure out quickly what it's sending and receiving.

This is a system-level protocol, not just a random user app.

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

#177

Post by immibis »

gpderetta wrote: post #170
poettering wrote: post #158

Earlier quoted context omitted.

You are writing this as if JSON was a newly invented thing, and not a language that has become the lingua franca of the Internet when it comes to encoding structured data. Well understood, and universally handled, since 1997. A 100 digit number cannot be encoded losslessly in D-Bus btw, nor in the far majority of IPC marshallings on this word. Having done systems-level OS development since 25y or so I never felt the…

> A 100 digit number cannot be encoded losslessly in D-Bus btw I think the concern is that large numbers can in fact be encoded in JSON, but there is no guarantee that they will be decoded correctly by a receiver as the format is underspecified. So you have to cater for the ill defined common denominator.

The format is properly specified; its mapping onto actual hardware people use is not.

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

#178

Post by immibis »

jcelerier wrote: post #175
KerrAvon wrote: post #118

Earlier quoted context omitted.

Data format is absolutely important for operating system IPC. JSON is raw text. Messages occupy more RAM than a binary format, which increases your working set, and it requires at least some nontrivial parsing. This ultimately limits the number of messages you can send per second.

It's not that simple: [1.2,1.3,1.4] is 13 bytes, the equivalent binary storage is 3*sizeof(double) (24 bytes) + whatever overhead exists for representing a dynamic array in your language

What's the chance the data you want to transmit is exactly 1.2 rather than 1.205338843375?

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

#179

Post by pjmlp »

guappa wrote: post #161
pjmlp wrote: post #129

Earlier quoted context omitted.

This looks like a joke, naturally D-BUS without JSON is what is preventing Linux on Desktop to take off.

You surely are aware that systemd and dbus aren't only used on desktop, right?

A side effect of its adoption, D-BUS was created as replacement for Bonobo and DCOP.

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

#180

Post by gpderetta »

jcelerier wrote: post #175
KerrAvon wrote: post #118

Earlier quoted context omitted.

Data format is absolutely important for operating system IPC. JSON is raw text. Messages occupy more RAM than a binary format, which increases your working set, and it requires at least some nontrivial parsing. This ultimately limits the number of messages you can send per second.

It's not that simple: [1.2,1.3,1.4] is 13 bytes, the equivalent binary storage is 3*sizeof(double) (24 bytes) + whatever overhead exists for representing a dynamic array in your language

If you expect to routinely send small numbers your serialization protocol can use floats or some small fix point format.

Variable length binary number encodings are also an option.

The dynamic array overhead in a language is immaterial when discussion serialization formats.

Post reply on HN