17 ms·

Varlink – IPC to replace D-Bus gradually in systemd

162 points by synergy20 2y ago

c0balt 2y ago
That looks interesting, I especially appreciate the intentional design decision for documentation and schemas. While it didn't work quite well with dbus Ime it is still a good idea to make APIs more accessible.
newpavlov 2y ago
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.
- nbbnbb 2y ago
  Lets take it a level up. I'm still not sure why we even need a message bus in there in the first place. The whole Linux boot, init, systemd pile is a Rube Goldberg machine that is very difficult to understand at the moment. The only reason I suspect most people aren't complaining is that our abstraction level is currently a lot higher (docker / kubernetes etc) and machines are mostly ephemeral cattle and few people go near it. As for JSON, please don't even start me on that. It is one of the worst serialisation decisions we ever made as a society. Poorly defined and unreliable primitive types, terrible schema support and expensive to parse. In a kernel, it does not belong! Give it a few months and varlink will be YAML over the top of that.
  - otabdeveloper4 2y ago
    > I'm still not sure why we even need a message bus in there in the first place. Because traditional POSIX IPC mechanisms are absolute unworkable dogshit. > It is one of the worst serialisation decisions we ever made as a society. There isn't really any alternative. It's either JSON or "JSON but in binary". (Like CBOR.) Anything else is not interoperable.
    - nbbnbb 2y ago
      This is a quite frankly ridiculous point. Most of that garb came from the HPC people who built loads of stuff on top of it in the first place. It's absolutely fine for this sort of stuff. It's sending the odd little thing here and there, not on a complex HPC cluster. As for JSON, are you really that short sighted that it's the only method of encoding something? Is "oh well it doesn't fit the primitive types, so just shove it in a string and add another layer of parsing" acceptable? Hell no.
      - otabdeveloper4 2y ago
        > ...it's the only method of encoding something? If you want something on the system level parsable by anything? Yes it is.
        nbbnbb 2y ago
        protobufs / asn.1 / structs ... Edit: hell even XML is better than this!
        baq 2y ago
        Thank goodness they didn’t pick YAML though.
        nbbnbb 2y ago
        Yet!
        RandomThoughts3 2y ago
        Structs are a part of C semantic. They are not an ipc format. You can somewhat use them like one if you take a lot of precaution about how they are laid out in memory including padding and packing but it’s very brittle. Asn.1 is both quite complicated and not very efficient. They could certainly have gone with protobufs or another binary serialisation format but would it really be better than the current choice? I don’t think the issue they are trying to solve is related to serialisation anyway. Seems to me they are unhappy about the bus part not the message format part.
  - jchw 2y ago
    I think it doesn't have to be a message bus per-se, that design decision is mostly just because it's convenient. Even D-Bus can actually be used without the bus, if you really want to. D-Bus is just a bus so it can solve a bunch of different IPC problems at the same time. e.g. D-Bus can handle ACLs/permissions on RPC methods, D-Bus can handle multiple producers and multiple consumers, and so on. I think ultimately all that's really needed is IPC, and having a unified bus is just to allow for some additional use cases that are harder if you're only using UNIX domain sockets directly. If there are going to be systemd components that have IPC, then I'd argue they should probably use something standard rather than something bespoke. It's good to not re-invent the wheel. Not that I think Varlink is any better. It seems like at best it's probably a lateral move. I hope this does not go forward.
    - nbbnbb 2y ago
      > If there are going to be systemd components that have IPC, then I'd argue they should probably use something standard rather than something bespoke. It's good to not re-invent the wheel. This is my point. My favourite DBus situation a number of years ago was a CentOS 7 box that reboot stopped working on with a cryptic DBus error that no one has ever seen before. I had to sync it, power cycle the node from the ILO card and cross my fingers. I really don't give a shit about this. I just wanted to run my jobs on the node, not turn into a sysadmin due to someone else's dubious architectural decisions.
      - jchw 2y ago
        Yes but the systemd developers don't want to implement their own protocols with e.g. ACL checking, and given some of their track record I kind of think you don't want them to, either. I'm pretty sure the error conditions would be even more bespoke if they "just" used UNIX domain sockets directly. Don't get me wrong, there's nothing particularly wrong with UNIX domain sockets, but there's no "standard" protocols for communicating over UDS.
        amluto 2y ago
        This is systemd we’re talking about. A service manager that already mucks with mount namespaces. It would be quite straightforward to map a capability-like UNIX socket into each service’s filesystem and give it a private view of the world. But instead… > Public varlink interfaces are registered system-wide by their well-known address, by default /run/org.varlink.resolver. The resolver translates a given varlink interface to the service address which provides this interface. …we have well known names, and sandboxing, or replacing a service for just one client, remains a mess. Sigh.
  - therein 2y ago
    Yeah, how will number/float serialization go? Are we going to serialize them as strings and parse them? That abstraction isn't handled the same way across multiple languages.
  - poettering 2y ago
    Varlink is not a message bus. Hence you should be happy?
- jchw 2y ago
  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 is also a problem (as in, the protocol design beyond serialization) but varlink looks like a very solid step backwards. In any single individual use case JSON serialization is unlikely to be a huge bottleneck, but in practice if this will be used for all kinds of things it will add up. I really wish the Linux desktop would coalesce around something like Cap'n'proto for serialization. P.S.: It'd probably be possible to shoehorn in multiple formats but I think that's a mistake too. Something like capnp will have a strong impedance mismatch with JSON; mixing formats with different degrees of self-describability is unwise. But then formats like MsgPack and BSON which are direct JSON analogues miss out on the best benefits of using binary serialization formats, which makes them almost the worst of both worlds, and you'd probably be better off with using a highly-optimized JSON library like simdjson.
  - arianvanp 2y ago
    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
    - theamk 2y ago
      What is the data rate (messages, bytes) that you expect for this "D-Bus replacement protocol"? Which fraction of CPU will JSON ser/des will take to justify using CBOR?
      - XorNot 2y ago
        I mean conversely every second week on HN someone complains about "inefficient modern development practices" and this is the sort of minor thing which would be trotted out as an example. So I'd argue it's not an unreasonable question (although I lean closer in: better types then JSON is the problem, since a decent text serialization format is always going to be needed for debugging and development).
- deivid 2y ago
  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=PLWYdJViL9EipIImmvuoGFAeS-lKeHH2DD&index=34 https://www.youtube.com/watch?v=emaVH2oWs2Y&list=PLWYdJViL9E...
  - gmokki 2y ago
    I do not understand where the 64bit integers not working with JSON comes from. JSON the format had no limit on integer size. And all Java JSON libraries I know can handle arbitrary prevsion integers (BigInt) and 32/64bit int/long types when serializing and deserializing. Quick googling shows that also JavaScript has proper support for 64bit integers with their BigInt type, and it can be used to deserialize incoming data correctly with the default parser, albeit requiring a bit more work to annotate the fields. Personally I often explicitly make sure that the integers I return in trust environments as identifiers in REST APIs are by default longer than 52bits so that buggy parser libraries are caught early.
    - GrayShade 2y ago
      Qt refused for almost a decade to support deserializing 64-bit integers from JSON because of compatibility concerns.
      - Spivak 2y ago
        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.
        capitainenemo 2y ago
        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.
- jsnell 2y ago
  I've done similar things in the past (json over udp-to-localhost, with a schema description used to generate the code for both parsing and generating on each end). It's a totally reasonable point in the design space, and I literally never saw a reason to revisit the decision to use json for that system. You'd do that because everything under the sun knows how to generate and parse json. Performance looks like a total non-issue for this use case. The messages are tiny, local and infrequent. You wouldn't want to do this on some kind of a high performance application on the data plane, but on the control plane it's totally fine. Even if you expect that all production use cases will use some kind of higher level library that does schema validation, it can still be quite nice during debugging to a) be able to inspect the messages on the wire when debugging, b) to be able to hand-write and inject messages.
  - ptx 2y ago
    > Performance looks like a total non-issue for this use case. The presentation brings up performance as one of the problems with the D-Bus though, so it seems like it is an issue.
    - jsnell 2y ago
      Fair. What I meant is that the performance delta between JSON and any other interchange data format should be a non-issue in this context. I would be quite surprised to hear that any performance problems systemd has with D-Bus was with serialization/de-serialization.
      - IshKebab 2y ago
        Yeah... it's easy to say JSON won't be an issue. It's difficult to switch from JSON when it turns out you were wrong. https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h... Given how central this is going to be why would you skip the tiny bit of extra work needed to use a binary format?
      - dathinab 2y ago
        > performance delta between JSON and any other interchange data format should be a non-issue it's hard to say, for most D-Bus taks perf. is an absolute non issues, but still you have bus-1 and all kind of tries to make D-Bus perform faster, reason is there are edge cases where it matters and even if the marshaling speed might not matter the size can, like if something goes really wrong and tens of thousand of system events get spammed the difference between the memory usage of in-flight messages of a compact format vs. json can make the difference between memory pressure effectively killing your server and you recovering reliable though what is an open question is how relevant that is in pracive and that is quite hard to say without inside information for companies running systems where such a thing could happen on a scale where such a thing does happen (e.g. google)
- Asooka 2y ago
  To be honest I don't see why they don't use the existing IPC mechanism created for Android - binder and ashmem. It has been tested and developed in real world scenarios for over a decade by now.
  - RandomThoughts3 2y ago
    Varlink was specifically designed to be available as early as possible when the kernel is booting and requires virtually nothing apart from good old sockets. But yes, definitely getting yet another one vibe from this. Then again, Dbus is not really what I would call an incredible piece of software - we are very much in the adequate territory if even - so anything shaking up the status quo can’t be too bad.
    - deleted 2y ago
      [deleted]
  - AshamedCaptain 2y ago
    Same reason Android (or PalmOS) didn't decide to use any of the existing IPC mechanisms, and why then Luna/webOS also didn't decide to use Binder even though they had experience with it and reinvent something else. That urge that forces every developer to reinvent RPC every other week.
    - altfredd 2y ago
      Not really. Binder solves a real-world problem — priority inversion. It is also the only IPC on Linux that allows to perform a blocking call from process A to process B (and have process B synchronously call back to process A if needed). D-Bus, Varlink and other "IPC solutions" on top of sockets can not do those things. Android uses synchronous Binder calls for 90% of it's application APIs, so there is clearly a real use case for it. Incidentally, Binder itself does not specify message format. A message is a simple memory buffer. Android runtime uses a custom binary serialization format, but you can use JSON or whatever. Binder is an alternative to sockets/pipes, not D-Bus or other wrappers on top of them.
- hi-v-rocknroll 2y ago
  Sigh. Cap'n Proto already exists. Reinventing the wheel yet again because NIH.
  - NekkoDroid 2y ago
    (Varlink also isn't something new)
  - IshKebab 2y ago
    CapnProto is kind of awful though. I had to use it for several years and the API is extremely unfriendly.
    - kentonv 2y ago
      Which implementation were you using? (I.e. which programming language?)
      - IshKebab 2y ago
        C++
- theamk 2y ago
  Sigh. Varlink is designed for IPC, so the expected data rate is maybe hundreds of messages per second in the worst case. JSON can be parsed at 3 Gigabytes/second [0]. Even unoptimized stdlib parsers in scripting languages get 50 MB/sec. That's more than enough, standard library support is much more important for a project like this. And if there is ever a reason to send tar archive or video data, there is always "upgrade" option to switch to raw TCP sockets, with no JSON overhead at all. [0] https://news.ycombinator.com/item?id=19214387 https://news.ycombinator.com/item?id=19214387 [1] https://github.com/TeskaLabs/cysimdjson https://github.com/TeskaLabs/cysimdjson
  - fanf2 2y ago
    Hundreds of messages per second sounds like the performance I would expect from a 1980s computer. Why so incredibly slow?
    - orf 2y ago
      Read the comment you’re replying to. In it OP says it’s not slow, and the “hundreds of messages per second” you are referring to is not regarding the performance but the expected rate. It’s possible for something to be fast, but only happen infrequently.
      - ptx 2y ago
        It just seems strange that the message rate is assumed to be in some very specific range where the performance of D-Bus is a problem (mentioned in the slides) yet the performance overhead of JSON is not a problem.
  - userbinator 2y ago
    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.
    - 2y ago
- deleted 2y ago
  [deleted]
- m463 2y ago
  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!)
- surajrmal 2y ago
  Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. If their average message size is small and they don't expect to ever need high volume or large messages, then it's not really likely to be a problem in practice. He also pointed out that they waste far more cycles today on context switches (he suggested something on the order of 6 per IPC message). Even if they eventually come to the conclusion they need something more performant in the future, it's probably still a net win to make the switch today. It's also possible it turns out fine for their use case. I personally would think they would want to benefit from an IPC system that includes provisions for sending file descriptors.
  - markasoftware 2y ago
    > Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. from the guy who brought you binary logfiles!
    - solarengineer 2y ago
      One can view the binary log files using journalctl. Per https://systemd.io/JOURNAL_FILE_FORMAT/ 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 Sealing As a user system-administrator, I see the cryptographic checksum as a benefit of being able to show tampering evidence of on-system log files.
      - Dunedan 2y ago
        > Primarily append-based, hence robust to corruption It's so robust, it doesn't even let you modify the journal if you want to (e.g. https://github.com/systemd/systemd/issues/20673 https://github.com/systemd/systemd/issues/20673). > Support for in-line compression Mind that journald only supports compressing single lines, but not the whole journal (https://github.com/systemd/systemd/issues/31358 https://github.com/systemd/systemd/issues/31358), which is pretty limiting.
- poettering 2y ago
  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 does matter though are roundtrips. In Varlink there are much fewer required for typical ops than there are in D-Bus. That's because D-Bus implies a broker (which doubles the number of roundtrips), but also because D-Bus forces you into a model of sending smaller "summary" messages when enumerating plus querying "details" for each listed objects, because it enforces transfer rate limits on everything (if you hit them, you are kicked off the bus), which means you have to refrain from streaming too large data. Or in other words: marshalling is quite an irrelevant minor detail when it comes to performance, you must look at roundtrips instead and the context switches it effects, instead. Using JSON for this has two major benefits: the whole world speaks JSON, and modern programming languages typically pretty natively. And it's directly readable in tools such as strace. With a simple "strace" I can now reasonably trace my programs, which a binary serialization will never allow you. And if you tell me that that doesn't matter, then you apparently live in an entirely different world than I do, because in mine debuggability does matter. A lot. Probably more than most other things. Lennart
  - steventhedev 2y ago
    The danger I see is that JSON has lots of edge behavior around deserialization, and some languages will deserialize a 100 digit number differently. If the main benefit is removing the broker and the need for rate limiting - it could have been accomplished without using JSON.
    - poettering 2y ago
      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 burning urge to send a 100 digit number over local IPC. Not that 100 digit numbers aren't useful, even in IPC, but typically, that's a cryptography thing, and they generally use their own serializations anyway.
- pjmlp 2y ago
  This looks like a joke, naturally D-BUS without JSON is what is preventing Linux on Desktop to take off.
  - ChoHag 2y ago
    [dead]
  - guappa 2y ago
    You surely are aware that systemd and dbus aren't only used on desktop, right?
    - pjmlp 2y ago
      A side effect of its adoption, D-BUS was created as replacement for Bonobo and DCOP.
      - guappa 2y ago
        That was 15 years ago? I was talking about the usage today.
        pjmlp 2y ago
        And I was being sarcastic, as there are things much more relevant to spend brain cells on.
        guappa 2y ago
        Wasn't sarcasm frowned upon here?
- thayne 2y ago
  I think it is primarily for compatibility. Practically every language has a readily available library, often part of the standard library, for json. That is less true for something like Msgpack or cbor, and even less so if make a new binary format. Also, there are benefits to the format being human readable.
- jeroenhd 2y ago
  Not a fan of JSON per se for this type of messaging, but I don't think binary parser+validator combinations are that much faster. Plus, this forces C(++) developers to actually validate the data they're exchanging rather than casting raw structs from data buffers, which solves a huge vulnerability. Then again, the lack of 64 bit integers makes the protocol design comically unsuited. I don't think the serialization/deserialisation overhead matters much when also taking into account the bus connection overhead. I would've preferred a better data exchange format but out of all problems I have with Linux IPC, the performance of JSON is the least of my worries.
  - poettering 2y ago
    The 64bit issue is certainly an issue, but very much overblown. First of all, in systemd, which is a heavy D-Bus user, we effectively IRL only send integers > 2^53 when we use UINT64_MAX as a special "niche" marker meaning "unlimited"/"unset"/"undefined". But the thing is that JSON has a proper concept for this: the "null" value (or simply not specifying a specific JSON field). Hence, in reasonably clean APIs this is mostly a non-issue. That said, sd-varlink/sd-json (i.e. systemd's implementation of it), of course is 64bit signed and unsigned integer clean when it processes JSON. More-over it automatically handles if you do what the various specs on the internet suggest you do if you have an integer > 2^53: you encode it as decimal value as a string. Would it be better if JSON would have been more precise on this, yes. Is it a big issue? No, not at all.
    - Netch 2y ago
      > if you do what the various specs on the internet suggest you do if you have an integer > 2^53: you encode it as decimal value as a string. Hexadecimal is better - more compact, much less encoding/decoding effort. Alternatively, array of two integers does as well. Text forms for any error, not NaN, are also useful. But issues with non-UTF-8 encodings - as in CJK world - may spoil the picture pretty more.
    - accelbred 2y ago
      Are strings used for timestamps? Those are usually why I'm sending 64-bit ints over IPC.
- foul 2y ago
  It's probably the first time in 14 years of systemd I appreciate a technical choice coming from the systemd team. It's a small format, it has limited pitfalls, it's fast to marshal and unmarshal (and with simd gets even more fast), it's deflate-friendly, would performance be an issue they can pack that through CBOR or msgpack or what-have-you.
- bitwize 2y ago
  > 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.
- deleted 2y ago
  [deleted]
- eternityforest 2y ago
  How many messages is this actually gonna handle? If it's tens per second, should you maybe be using something else? JSON is so prevalent I'm pretty sure it's a lot of people's mental model of what non relational structured data looks like, if it's not just a file. It's nice from a dev perspective to always work directly with the same high level concepts that you use when thinking about this stuff. Other data formats are often advertised in terms of JSON, either subsets or supersets, or equivalent representations. I'd use something else for high performance stuff.... But for everything else it's pretty awesome.
edelbitter 2y ago
But what is the excuse to start from scratch? Rather than a compat layer that convinces the world that raw your interfaces, libraries and clients are so much nicer to work with that the other thing should be demoted to compat layer eventually?
- ChoHag 2y ago
  [dead]
- foul 2y ago
  >But what is the excuse to start from scratch? Red Hat FOSS system software is imposing foss-ified client work to the general public. The cloud industry benefited greatly from their work, the other users are involved in a multi-decade flamewar.
jmclnx 2y ago
Does this mean Lunux will need both Dbus and varlink if using systemd ? I ask because I believe Firefox uses Dbus. https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future
- NekkoDroid 2y ago
  systemd has been using varlink for a while now along side dbus, its not something just now being introduced. They don't have a problem living side-by-side.
  - cryptonector 2y ago
    It's more code, more bloat, more complexity, and more attack surface area.
    - throwaway984393 2y ago
      [dead]
    - NekkoDroid 2y ago
      Ok? I don't see how that is relavant to the question at hand (to be fair, I did assume the parent meant "will this cause any problems since firefox relies on dbus?"). Anything that add new features (early boot IPC in this case) is going to require "more code, more bloat, more complexity, and more attack surface area" unless you rip other features out at the same time.
- cryptonector 2y ago
  Hello Nth system syndrome.
arianvanp 2y ago
Accompanying talk from Lennart Poettering a few days ago: https://media.ccc.de/v/all-systems-go-2024-276-varlink-now- https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-
6SixTy 2y ago
So 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?
- RandomThoughts3 2y ago
  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?
  - 6SixTy 2y ago
    My point is, what's stopping me from creating yet another IPC standard?
    - Xylakant 2y ago
      Nothing. It might not see adoption, but you can create as many IPC standards as you desire.
  - dfox 2y ago
    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.
    - Iwan-Zotow 2y ago
      Could you name it?
    - orf 2y ago
      Naming the system would be useful context to add to this point.
dang 2y ago
Related. Others? AllSystemsGo: Varlink Now [video] - https://news.ycombinator.com/item?id=41670431 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 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 https://news.ycombinator.com/item?id=20950146 - Sept 2019 (10 comments)
- naveen99 2y ago
  https://hn.garglet.com/similar/stories/41687413 https://hn.garglet.com/similar/stories/41687413
ptx 2y ago
Setting the serialization format issue aside, why is the D-Bus broker an issue? Why was it designed that way in the first place if all we need (supposedly) is a socket and a simple request/response protocol? If it wasn't needed, why does D-Bus have it? And if it is needed, what will replace it when systemd switches to Varlink?
greatgib 2y ago
[flagged]
- nmz 2y ago
  Poettering does work for microsoft.
- LooseMarmoset 2y ago
  “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.
- ahupp 2y ago
  Is modularity an unalloyed good? Modularity comes with tradeoffs that mean you end up with, well, a bunch of discrete modules rather than something that works cohesively. That's why systemd was adopted pretty much everywhere, ignoring the arbitrary modular boundaries results in a more useful tool. Some analogs: modern filesystems like ZFS and BTRFS that combine volume management with the filesystem, every service that's consciously chosen to deploy a monolith instead of microservices, and so on, every deployment that chooses to statically link, etc.
nly 2y ago
Why 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 https://wayland-book.com/protocol-design.html
- WhyNotHugo 2y ago
  I often wonder why that protocol isn’t used in other fields. It has clear schemas with documentation, and existing codegen implementations. OTOH, it’s too complex for simple protocols with a few messages. IIRC, Pipewire uses a variation of the Wayland protocol.
- pjmlp 2y ago
  That would be going full circle, given that D-Bus was predated by Bonono on GNOME side, and DCOP on KDE, which was based on X11 Inter-client communication. D-Bus evolved from merging their needs into a single approach.
  - loa_in_ 2y ago
    But would that be necessarily bad? It's like merging back a long detached branch in version control
- 1oooqooq 2y ago
  because systemd does what redhat clients ask for, not matter how obnoxious.
Vegemeister 2y ago
>reverse-domain name Why do people keep replicating this terrible design decision? It puts the lowest-entropy part of the name at the beginning, so that you have to parse (or type) the maximum number of characters before you get a unique specification. Try tab-completing a "flatpak run" command sometime.
- Netch 2y ago
  If you mention tab-completing, if starting with the detailest component it wonʼt work at all because of context search problems. If you press something like "alice<Tab>", in deepest-first order it will have to search the whole tree which could contain millions of entities. Worse than, some subtrees may be dynamically loaded during the completion request. To mitigate senseless tree top listing, IDEs propose a bunch of means like context-related hints or unpacking forms like "o.e.t" to "org.example.test".
- icar 2y ago
  You might be interested in https://github.com/Aloxaf/fzf-tab https://github.com/Aloxaf/fzf-tab
yazzku 2y ago
[flagged]
quotemstr 2y ago
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.
- eviks 2y ago
  > Extend dbus. How would you address the issue of dbus unavailability in early boot listed in the presentation via extension?
  - ahartmetz 2y ago
    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.
- btreecat 2y ago
  >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?"
  - Netch 2y ago
    > Are these required or useful in this context? At least 64-bit numbers are crucial in any system context.
    - btreecat 2y ago
      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.
throwaway984393 2y ago
[dead]
tarasglek 2y ago
All the the hate for json here, but at the bottom there is a bridge screenshot. Varlink is designed such that it can trivially be piped across different systems and be maximally interoperable due simple to parse and encode protocol. We might end up with some IPC interface that a lot me tooling can understand. Eg imagine that instead of some daemons supporting sighup to reload, they could also confirm that they reloaded, provided Prometheus style metrics etc
rurban 2y ago
They finished varlink in 2018 already https://github.com/varlink/libvarlink https://github.com/varlink/libvarlink
orf 2y ago
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.
- guerrilla 2y ago
  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.
  - deng 2y ago
    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.
    - guerrilla 2y ago
      If that were all it is, I'd agree but you may have missed the constant stream of other radical changes over the years.
asim 2y ago
This is JSON-RPC basically. Microkernel architecture personified where everything is a service. Unix was all about files. The emerging next standard is probably an OS built entirely of services.
- criticalfault 2y ago
  This is overblown reaction t
guerrilla 2y ago
Who is behind this? I just happened to read Lennart Pottering's original post on sd-dbus yesterday actually. It gives a good introduction to D-Bus for those not up to date. https://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html https://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html
dmitrygr 2y ago
Next time someone asks you why computers are getting slower despite hardware being faster, everyone who thinks this is a good idea, please remember to blame yourselves.
vardump 2y ago
Is there also a varlink dump utility?
zzo38computer 2y ago
I 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".
- dezgeg 2y ago
  Yeah, using serialization format that doesn't even have obvious way of representing every possible Linux filename (nothing mandates filenames to be valid UTF-8, only thing they can't contain is NUL and '/') seems bad fit for low-level system services. I can't wait to have apps and services crash and burn left and right due to accidentally (or maliciously) created non-UTF8 filenames in world readable directories.
  - zzo38computer 2y ago
    > Yeah, using serialization format that doesn't even have obvious way of representing every possible Linux filename That is hardly the only problem with such a serialization format, although it is one of them. > I can't wait to have apps and services crash and burn left and right due to accidentally (or maliciously) created non-UTF8 filenames in world readable directories. It is not only accidentally or maliciously. Sometimes it may also be done deliberately because it is a character set other than Unicode, without the intention to be malicious. (A user might also deliberately want to display file names using a different character set, perhaps in order to ensure that all characters can be displayed unambiguously. Of course, this is not necessarily what everyone intends, but some people will.)
XlA5vEKsMISoIln 2y ago
Hold 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?
xarope 2y ago
Someone explain to me please, how type-safe and JSON can even exist in the same sentence? JSON has so many edge cases for handling numbers, floats, bools etc. Why would you not use gRPC or even something like CapnProto if you want to maintain that type-safety-ness?
- manuel_w 2y ago
  Which edge cases do you mean? Are you confusing it with YAML? I know YAML has some serious footguns [1]. In JSON I'm not aware of any. [1] https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...
petiepooo 2y ago
Looks like the transformation of RHEL into a Windows clone is nearly complete. I'm all for it, as I expect a modern fork without systemd will coalesce for those of us that prefer Linux over Windows.
hi-v-rocknroll 2y ago
Cramming more NIH garbage down GNU/Linux users' throats. Nanomsg ng and cap'n proto already exist.

162 points by synergy20 2y ago

That looks interesting, I especially appreciate the intentional design decision for documentation and schemas. While it didn't work quite well with dbus Ime it is still a good idea to make APIs more accessible.

newpavlov 2y ago

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.

nbbnbb 2y ago
Lets take it a level up. I'm still not sure why we even need a message bus in there in the first place. The whole Linux boot, init, systemd pile is a Rube Goldberg machine that is very difficult to understand at the moment. The only reason I suspect most people aren't complaining is that our abstraction level is currently a lot higher (docker / kubernetes etc) and machines are mostly ephemeral cattle and few people go near it. As for JSON, please don't even start me on that. It is one of the worst serialisation decisions we ever made as a society. Poorly defined and unreliable primitive types, terrible schema support and expensive to parse. In a kernel, it does not belong! Give it a few months and varlink will be YAML over the top of that.
- otabdeveloper4 2y ago
  > I'm still not sure why we even need a message bus in there in the first place. Because traditional POSIX IPC mechanisms are absolute unworkable dogshit. > It is one of the worst serialisation decisions we ever made as a society. There isn't really any alternative. It's either JSON or "JSON but in binary". (Like CBOR.) Anything else is not interoperable.
  - nbbnbb 2y ago
    This is a quite frankly ridiculous point. Most of that garb came from the HPC people who built loads of stuff on top of it in the first place. It's absolutely fine for this sort of stuff. It's sending the odd little thing here and there, not on a complex HPC cluster. As for JSON, are you really that short sighted that it's the only method of encoding something? Is "oh well it doesn't fit the primitive types, so just shove it in a string and add another layer of parsing" acceptable? Hell no.
    - otabdeveloper4 2y ago
      > ...it's the only method of encoding something? If you want something on the system level parsable by anything? Yes it is.
      - nbbnbb 2y ago
        protobufs / asn.1 / structs ... Edit: hell even XML is better than this!
        baq 2y ago
        Thank goodness they didn’t pick YAML though.
        nbbnbb 2y ago
        Yet!
        RandomThoughts3 2y ago
        Structs are a part of C semantic. They are not an ipc format. You can somewhat use them like one if you take a lot of precaution about how they are laid out in memory including padding and packing but it’s very brittle. Asn.1 is both quite complicated and not very efficient. They could certainly have gone with protobufs or another binary serialisation format but would it really be better than the current choice? I don’t think the issue they are trying to solve is related to serialisation anyway. Seems to me they are unhappy about the bus part not the message format part.
- jchw 2y ago
  I think it doesn't have to be a message bus per-se, that design decision is mostly just because it's convenient. Even D-Bus can actually be used without the bus, if you really want to. D-Bus is just a bus so it can solve a bunch of different IPC problems at the same time. e.g. D-Bus can handle ACLs/permissions on RPC methods, D-Bus can handle multiple producers and multiple consumers, and so on. I think ultimately all that's really needed is IPC, and having a unified bus is just to allow for some additional use cases that are harder if you're only using UNIX domain sockets directly. If there are going to be systemd components that have IPC, then I'd argue they should probably use something standard rather than something bespoke. It's good to not re-invent the wheel. Not that I think Varlink is any better. It seems like at best it's probably a lateral move. I hope this does not go forward.
  - nbbnbb 2y ago
    > If there are going to be systemd components that have IPC, then I'd argue they should probably use something standard rather than something bespoke. It's good to not re-invent the wheel. This is my point. My favourite DBus situation a number of years ago was a CentOS 7 box that reboot stopped working on with a cryptic DBus error that no one has ever seen before. I had to sync it, power cycle the node from the ILO card and cross my fingers. I really don't give a shit about this. I just wanted to run my jobs on the node, not turn into a sysadmin due to someone else's dubious architectural decisions.
    - jchw 2y ago
      Yes but the systemd developers don't want to implement their own protocols with e.g. ACL checking, and given some of their track record I kind of think you don't want them to, either. I'm pretty sure the error conditions would be even more bespoke if they "just" used UNIX domain sockets directly. Don't get me wrong, there's nothing particularly wrong with UNIX domain sockets, but there's no "standard" protocols for communicating over UDS.
      - amluto 2y ago
        This is systemd we’re talking about. A service manager that already mucks with mount namespaces. It would be quite straightforward to map a capability-like UNIX socket into each service’s filesystem and give it a private view of the world. But instead… > Public varlink interfaces are registered system-wide by their well-known address, by default /run/org.varlink.resolver. The resolver translates a given varlink interface to the service address which provides this interface. …we have well known names, and sandboxing, or replacing a service for just one client, remains a mess. Sigh.
- therein 2y ago
  Yeah, how will number/float serialization go? Are we going to serialize them as strings and parse them? That abstraction isn't handled the same way across multiple languages.
- poettering 2y ago
  Varlink is not a message bus. Hence you should be happy?
jchw 2y ago
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 is also a problem (as in, the protocol design beyond serialization) but varlink looks like a very solid step backwards. In any single individual use case JSON serialization is unlikely to be a huge bottleneck, but in practice if this will be used for all kinds of things it will add up. I really wish the Linux desktop would coalesce around something like Cap'n'proto for serialization. P.S.: It'd probably be possible to shoehorn in multiple formats but I think that's a mistake too. Something like capnp will have a strong impedance mismatch with JSON; mixing formats with different degrees of self-describability is unwise. But then formats like MsgPack and BSON which are direct JSON analogues miss out on the best benefits of using binary serialization formats, which makes them almost the worst of both worlds, and you'd probably be better off with using a highly-optimized JSON library like simdjson.
- arianvanp 2y ago
  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
  - theamk 2y ago
    What is the data rate (messages, bytes) that you expect for this "D-Bus replacement protocol"? Which fraction of CPU will JSON ser/des will take to justify using CBOR?
    - XorNot 2y ago
      I mean conversely every second week on HN someone complains about "inefficient modern development practices" and this is the sort of minor thing which would be trotted out as an example. So I'd argue it's not an unreasonable question (although I lean closer in: better types then JSON is the problem, since a decent text serialization format is always going to be needed for debugging and development).
deivid 2y ago
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=PLWYdJViL9EipIImmvuoGFAeS-lKeHH2DD&index=34 https://www.youtube.com/watch?v=emaVH2oWs2Y&list=PLWYdJViL9E...
- gmokki 2y ago
  I do not understand where the 64bit integers not working with JSON comes from. JSON the format had no limit on integer size. And all Java JSON libraries I know can handle arbitrary prevsion integers (BigInt) and 32/64bit int/long types when serializing and deserializing. Quick googling shows that also JavaScript has proper support for 64bit integers with their BigInt type, and it can be used to deserialize incoming data correctly with the default parser, albeit requiring a bit more work to annotate the fields. Personally I often explicitly make sure that the integers I return in trust environments as identifiers in REST APIs are by default longer than 52bits so that buggy parser libraries are caught early.
  - GrayShade 2y ago
    Qt refused for almost a decade to support deserializing 64-bit integers from JSON because of compatibility concerns.
    - Spivak 2y ago
      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.
      - capitainenemo 2y ago
        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.
jsnell 2y ago
I've done similar things in the past (json over udp-to-localhost, with a schema description used to generate the code for both parsing and generating on each end). It's a totally reasonable point in the design space, and I literally never saw a reason to revisit the decision to use json for that system. You'd do that because everything under the sun knows how to generate and parse json. Performance looks like a total non-issue for this use case. The messages are tiny, local and infrequent. You wouldn't want to do this on some kind of a high performance application on the data plane, but on the control plane it's totally fine. Even if you expect that all production use cases will use some kind of higher level library that does schema validation, it can still be quite nice during debugging to a) be able to inspect the messages on the wire when debugging, b) to be able to hand-write and inject messages.
- ptx 2y ago
  > Performance looks like a total non-issue for this use case. The presentation brings up performance as one of the problems with the D-Bus though, so it seems like it is an issue.
  - jsnell 2y ago
    Fair. What I meant is that the performance delta between JSON and any other interchange data format should be a non-issue in this context. I would be quite surprised to hear that any performance problems systemd has with D-Bus was with serialization/de-serialization.
    - IshKebab 2y ago
      Yeah... it's easy to say JSON won't be an issue. It's difficult to switch from JSON when it turns out you were wrong. https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h... Given how central this is going to be why would you skip the tiny bit of extra work needed to use a binary format?
    - dathinab 2y ago
      > performance delta between JSON and any other interchange data format should be a non-issue it's hard to say, for most D-Bus taks perf. is an absolute non issues, but still you have bus-1 and all kind of tries to make D-Bus perform faster, reason is there are edge cases where it matters and even if the marshaling speed might not matter the size can, like if something goes really wrong and tens of thousand of system events get spammed the difference between the memory usage of in-flight messages of a compact format vs. json can make the difference between memory pressure effectively killing your server and you recovering reliable though what is an open question is how relevant that is in pracive and that is quite hard to say without inside information for companies running systems where such a thing could happen on a scale where such a thing does happen (e.g. google)
Asooka 2y ago
To be honest I don't see why they don't use the existing IPC mechanism created for Android - binder and ashmem. It has been tested and developed in real world scenarios for over a decade by now.
- RandomThoughts3 2y ago
  Varlink was specifically designed to be available as early as possible when the kernel is booting and requires virtually nothing apart from good old sockets. But yes, definitely getting yet another one vibe from this. Then again, Dbus is not really what I would call an incredible piece of software - we are very much in the adequate territory if even - so anything shaking up the status quo can’t be too bad.
  - deleted 2y ago
    [deleted]
- AshamedCaptain 2y ago
  Same reason Android (or PalmOS) didn't decide to use any of the existing IPC mechanisms, and why then Luna/webOS also didn't decide to use Binder even though they had experience with it and reinvent something else. That urge that forces every developer to reinvent RPC every other week.
  - altfredd 2y ago
    Not really. Binder solves a real-world problem — priority inversion. It is also the only IPC on Linux that allows to perform a blocking call from process A to process B (and have process B synchronously call back to process A if needed). D-Bus, Varlink and other "IPC solutions" on top of sockets can not do those things. Android uses synchronous Binder calls for 90% of it's application APIs, so there is clearly a real use case for it. Incidentally, Binder itself does not specify message format. A message is a simple memory buffer. Android runtime uses a custom binary serialization format, but you can use JSON or whatever. Binder is an alternative to sockets/pipes, not D-Bus or other wrappers on top of them.
hi-v-rocknroll 2y ago
Sigh. Cap'n Proto already exists. Reinventing the wheel yet again because NIH.
- NekkoDroid 2y ago
  (Varlink also isn't something new)
- IshKebab 2y ago
  CapnProto is kind of awful though. I had to use it for several years and the API is extremely unfriendly.
  - kentonv 2y ago
    Which implementation were you using? (I.e. which programming language?)
    - IshKebab 2y ago
      C++
theamk 2y ago
Sigh. Varlink is designed for IPC, so the expected data rate is maybe hundreds of messages per second in the worst case. JSON can be parsed at 3 Gigabytes/second [0]. Even unoptimized stdlib parsers in scripting languages get 50 MB/sec. That's more than enough, standard library support is much more important for a project like this. And if there is ever a reason to send tar archive or video data, there is always "upgrade" option to switch to raw TCP sockets, with no JSON overhead at all. [0] https://news.ycombinator.com/item?id=19214387 https://news.ycombinator.com/item?id=19214387 [1] https://github.com/TeskaLabs/cysimdjson https://github.com/TeskaLabs/cysimdjson
- fanf2 2y ago
  Hundreds of messages per second sounds like the performance I would expect from a 1980s computer. Why so incredibly slow?
  - orf 2y ago
    Read the comment you’re replying to. In it OP says it’s not slow, and the “hundreds of messages per second” you are referring to is not regarding the performance but the expected rate. It’s possible for something to be fast, but only happen infrequently.
    - ptx 2y ago
      It just seems strange that the message rate is assumed to be in some very specific range where the performance of D-Bus is a problem (mentioned in the slides) yet the performance overhead of JSON is not a problem.
- userbinator 2y ago
  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.
  - 2y ago
deleted 2y ago
[deleted]
m463 2y ago
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!)
surajrmal 2y ago
Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. If their average message size is small and they don't expect to ever need high volume or large messages, then it's not really likely to be a problem in practice. He also pointed out that they waste far more cycles today on context switches (he suggested something on the order of 6 per IPC message). Even if they eventually come to the conclusion they need something more performant in the future, it's probably still a net win to make the switch today. It's also possible it turns out fine for their use case. I personally would think they would want to benefit from an IPC system that includes provisions for sending file descriptors.
- markasoftware 2y ago
  > Lennart pointed out the fact you can see readable messages via strace to be a benefit of json. from the guy who brought you binary logfiles!
  - solarengineer 2y ago
    One can view the binary log files using journalctl. Per https://systemd.io/JOURNAL_FILE_FORMAT/ 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 Sealing As a user system-administrator, I see the cryptographic checksum as a benefit of being able to show tampering evidence of on-system log files.
    - Dunedan 2y ago
      > Primarily append-based, hence robust to corruption It's so robust, it doesn't even let you modify the journal if you want to (e.g. https://github.com/systemd/systemd/issues/20673 https://github.com/systemd/systemd/issues/20673). > Support for in-line compression Mind that journald only supports compressing single lines, but not the whole journal (https://github.com/systemd/systemd/issues/31358 https://github.com/systemd/systemd/issues/31358), which is pretty limiting.
poettering 2y ago
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 does matter though are roundtrips. In Varlink there are much fewer required for typical ops than there are in D-Bus. That's because D-Bus implies a broker (which doubles the number of roundtrips), but also because D-Bus forces you into a model of sending smaller "summary" messages when enumerating plus querying "details" for each listed objects, because it enforces transfer rate limits on everything (if you hit them, you are kicked off the bus), which means you have to refrain from streaming too large data. Or in other words: marshalling is quite an irrelevant minor detail when it comes to performance, you must look at roundtrips instead and the context switches it effects, instead. Using JSON for this has two major benefits: the whole world speaks JSON, and modern programming languages typically pretty natively. And it's directly readable in tools such as strace. With a simple "strace" I can now reasonably trace my programs, which a binary serialization will never allow you. And if you tell me that that doesn't matter, then you apparently live in an entirely different world than I do, because in mine debuggability does matter. A lot. Probably more than most other things. Lennart
- steventhedev 2y ago
  The danger I see is that JSON has lots of edge behavior around deserialization, and some languages will deserialize a 100 digit number differently. If the main benefit is removing the broker and the need for rate limiting - it could have been accomplished without using JSON.
  - poettering 2y ago
    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 burning urge to send a 100 digit number over local IPC. Not that 100 digit numbers aren't useful, even in IPC, but typically, that's a cryptography thing, and they generally use their own serializations anyway.
pjmlp 2y ago
This looks like a joke, naturally D-BUS without JSON is what is preventing Linux on Desktop to take off.
- ChoHag 2y ago
  [dead]
- guappa 2y ago
  You surely are aware that systemd and dbus aren't only used on desktop, right?
  - pjmlp 2y ago
    A side effect of its adoption, D-BUS was created as replacement for Bonobo and DCOP.
    - guappa 2y ago
      That was 15 years ago? I was talking about the usage today.
      - pjmlp 2y ago
        And I was being sarcastic, as there are things much more relevant to spend brain cells on.
        guappa 2y ago
        Wasn't sarcasm frowned upon here?
thayne 2y ago
I think it is primarily for compatibility. Practically every language has a readily available library, often part of the standard library, for json. That is less true for something like Msgpack or cbor, and even less so if make a new binary format. Also, there are benefits to the format being human readable.
jeroenhd 2y ago
Not a fan of JSON per se for this type of messaging, but I don't think binary parser+validator combinations are that much faster. Plus, this forces C(++) developers to actually validate the data they're exchanging rather than casting raw structs from data buffers, which solves a huge vulnerability. Then again, the lack of 64 bit integers makes the protocol design comically unsuited. I don't think the serialization/deserialisation overhead matters much when also taking into account the bus connection overhead. I would've preferred a better data exchange format but out of all problems I have with Linux IPC, the performance of JSON is the least of my worries.
- poettering 2y ago
  The 64bit issue is certainly an issue, but very much overblown. First of all, in systemd, which is a heavy D-Bus user, we effectively IRL only send integers > 2^53 when we use UINT64_MAX as a special "niche" marker meaning "unlimited"/"unset"/"undefined". But the thing is that JSON has a proper concept for this: the "null" value (or simply not specifying a specific JSON field). Hence, in reasonably clean APIs this is mostly a non-issue. That said, sd-varlink/sd-json (i.e. systemd's implementation of it), of course is 64bit signed and unsigned integer clean when it processes JSON. More-over it automatically handles if you do what the various specs on the internet suggest you do if you have an integer > 2^53: you encode it as decimal value as a string. Would it be better if JSON would have been more precise on this, yes. Is it a big issue? No, not at all.
  - Netch 2y ago
    > if you do what the various specs on the internet suggest you do if you have an integer > 2^53: you encode it as decimal value as a string. Hexadecimal is better - more compact, much less encoding/decoding effort. Alternatively, array of two integers does as well. Text forms for any error, not NaN, are also useful. But issues with non-UTF-8 encodings - as in CJK world - may spoil the picture pretty more.
  - accelbred 2y ago
    Are strings used for timestamps? Those are usually why I'm sending 64-bit ints over IPC.
foul 2y ago
It's probably the first time in 14 years of systemd I appreciate a technical choice coming from the systemd team. It's a small format, it has limited pitfalls, it's fast to marshal and unmarshal (and with simd gets even more fast), it's deflate-friendly, would performance be an issue they can pack that through CBOR or msgpack or what-have-you.
bitwize 2y ago
> 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.
deleted 2y ago
[deleted]
eternityforest 2y ago
How many messages is this actually gonna handle? If it's tens per second, should you maybe be using something else? JSON is so prevalent I'm pretty sure it's a lot of people's mental model of what non relational structured data looks like, if it's not just a file. It's nice from a dev perspective to always work directly with the same high level concepts that you use when thinking about this stuff. Other data formats are often advertised in terms of JSON, either subsets or supersets, or equivalent representations. I'd use something else for high performance stuff.... But for everything else it's pretty awesome.

edelbitter 2y ago

But what is the excuse to start from scratch? Rather than a compat layer that convinces the world that raw your interfaces, libraries and clients are so much nicer to work with that the other thing should be demoted to compat layer eventually?

ChoHag 2y ago
[dead]
foul 2y ago
>But what is the excuse to start from scratch? Red Hat FOSS system software is imposing foss-ified client work to the general public. The cloud industry benefited greatly from their work, the other users are involved in a multi-decade flamewar.

jmclnx 2y ago

Does this mean Lunux will need both Dbus and varlink if using systemd ? I ask because I believe Firefox uses Dbus. https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future

NekkoDroid 2y ago
systemd has been using varlink for a while now along side dbus, its not something just now being introduced. They don't have a problem living side-by-side.
- cryptonector 2y ago
  It's more code, more bloat, more complexity, and more attack surface area.
  - throwaway984393 2y ago
    [dead]
  - NekkoDroid 2y ago
    Ok? I don't see how that is relavant to the question at hand (to be fair, I did assume the parent meant "will this cause any problems since firefox relies on dbus?"). Anything that add new features (early boot IPC in this case) is going to require "more code, more bloat, more complexity, and more attack surface area" unless you rip other features out at the same time.
cryptonector 2y ago
Hello Nth system syndrome.

arianvanp 2y ago

Accompanying talk from Lennart Poettering a few days ago: https://media.ccc.de/v/all-systems-go-2024-276-varlink-now- https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-

6SixTy 2y ago

So 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?

RandomThoughts3 2y ago
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?
- 6SixTy 2y ago
  My point is, what's stopping me from creating yet another IPC standard?
  - Xylakant 2y ago
    Nothing. It might not see adoption, but you can create as many IPC standards as you desire.
- dfox 2y ago
  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.
  - Iwan-Zotow 2y ago
    Could you name it?
  - orf 2y ago
    Naming the system would be useful context to add to this point.

dang 2y ago

Related. Others? AllSystemsGo: Varlink Now [video] - https://news.ycombinator.com/item?id=41670431 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 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 https://news.ycombinator.com/item?id=20950146 - Sept 2019 (10 comments)

naveen99 2y ago
https://hn.garglet.com/similar/stories/41687413 https://hn.garglet.com/similar/stories/41687413

ptx 2y ago

Setting the serialization format issue aside, why is the D-Bus broker an issue? Why was it designed that way in the first place if all we need (supposedly) is a socket and a simple request/response protocol? If it wasn't needed, why does D-Bus have it? And if it is needed, what will replace it when systemd switches to Varlink?

greatgib 2y ago

[flagged]

nmz 2y ago
Poettering does work for microsoft.
LooseMarmoset 2y ago
“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.
ahupp 2y ago
Is modularity an unalloyed good? Modularity comes with tradeoffs that mean you end up with, well, a bunch of discrete modules rather than something that works cohesively. That's why systemd was adopted pretty much everywhere, ignoring the arbitrary modular boundaries results in a more useful tool. Some analogs: modern filesystems like ZFS and BTRFS that combine volume management with the filesystem, every service that's consciously chosen to deploy a monolith instead of microservices, and so on, every deployment that chooses to statically link, etc.

nly 2y ago

Why 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 https://wayland-book.com/protocol-design.html

WhyNotHugo 2y ago
I often wonder why that protocol isn’t used in other fields. It has clear schemas with documentation, and existing codegen implementations. OTOH, it’s too complex for simple protocols with a few messages. IIRC, Pipewire uses a variation of the Wayland protocol.
pjmlp 2y ago
That would be going full circle, given that D-Bus was predated by Bonono on GNOME side, and DCOP on KDE, which was based on X11 Inter-client communication. D-Bus evolved from merging their needs into a single approach.
- loa_in_ 2y ago
  But would that be necessarily bad? It's like merging back a long detached branch in version control
1oooqooq 2y ago
because systemd does what redhat clients ask for, not matter how obnoxious.

Vegemeister 2y ago

>reverse-domain name Why do people keep replicating this terrible design decision? It puts the lowest-entropy part of the name at the beginning, so that you have to parse (or type) the maximum number of characters before you get a unique specification. Try tab-completing a "flatpak run" command sometime.

Netch 2y ago
If you mention tab-completing, if starting with the detailest component it wonʼt work at all because of context search problems. If you press something like "alice<Tab>", in deepest-first order it will have to search the whole tree which could contain millions of entities. Worse than, some subtrees may be dynamically loaded during the completion request. To mitigate senseless tree top listing, IDEs propose a bunch of means like context-related hints or unpacking forms like "o.e.t" to "org.example.test".
icar 2y ago
You might be interested in https://github.com/Aloxaf/fzf-tab https://github.com/Aloxaf/fzf-tab

yazzku 2y ago

[flagged]

quotemstr 2y ago

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.

eviks 2y ago
> Extend dbus. How would you address the issue of dbus unavailability in early boot listed in the presentation via extension?
- ahartmetz 2y ago
  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.
btreecat 2y ago
>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?"
- Netch 2y ago
  > Are these required or useful in this context? At least 64-bit numbers are crucial in any system context.
  - btreecat 2y ago
    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.

throwaway984393 2y ago

[dead]

tarasglek 2y ago

All the the hate for json here, but at the bottom there is a bridge screenshot. Varlink is designed such that it can trivially be piped across different systems and be maximally interoperable due simple to parse and encode protocol. We might end up with some IPC interface that a lot me tooling can understand. Eg imagine that instead of some daemons supporting sighup to reload, they could also confirm that they reloaded, provided Prometheus style metrics etc

rurban 2y ago

They finished varlink in 2018 already https://github.com/varlink/libvarlink https://github.com/varlink/libvarlink

orf 2y ago

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.

guerrilla 2y ago
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.
- deng 2y ago
  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.
  - guerrilla 2y ago
    If that were all it is, I'd agree but you may have missed the constant stream of other radical changes over the years.

asim 2y ago

This is JSON-RPC basically. Microkernel architecture personified where everything is a service. Unix was all about files. The emerging next standard is probably an OS built entirely of services.

criticalfault 2y ago
This is overblown reaction t

guerrilla 2y ago

Who is behind this? I just happened to read Lennart Pottering's original post on sd-dbus yesterday actually. It gives a good introduction to D-Bus for those not up to date. https://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html https://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html

dmitrygr 2y ago

Next time someone asks you why computers are getting slower despite hardware being faster, everyone who thinks this is a good idea, please remember to blame yourselves.

vardump 2y ago

Is there also a varlink dump utility?

zzo38computer 2y ago

I 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".

dezgeg 2y ago
Yeah, using serialization format that doesn't even have obvious way of representing every possible Linux filename (nothing mandates filenames to be valid UTF-8, only thing they can't contain is NUL and '/') seems bad fit for low-level system services. I can't wait to have apps and services crash and burn left and right due to accidentally (or maliciously) created non-UTF8 filenames in world readable directories.
- zzo38computer 2y ago
  > Yeah, using serialization format that doesn't even have obvious way of representing every possible Linux filename That is hardly the only problem with such a serialization format, although it is one of them. > I can't wait to have apps and services crash and burn left and right due to accidentally (or maliciously) created non-UTF8 filenames in world readable directories. It is not only accidentally or maliciously. Sometimes it may also be done deliberately because it is a character set other than Unicode, without the intention to be malicious. (A user might also deliberately want to display file names using a different character set, perhaps in order to ensure that all characters can be displayed unambiguously. Of course, this is not necessarily what everyone intends, but some people will.)

XlA5vEKsMISoIln 2y ago

Hold 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?

xarope 2y ago

Someone explain to me please, how type-safe and JSON can even exist in the same sentence? JSON has so many edge cases for handling numbers, floats, bools etc. Why would you not use gRPC or even something like CapnProto if you want to maintain that type-safety-ness?

manuel_w 2y ago
Which edge cases do you mean? Are you confusing it with YAML? I know YAML has some serious footguns [1]. In JSON I'm not aware of any. [1] https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...

petiepooo 2y ago

Looks like the transformation of RHEL into a Windows clone is nearly complete. I'm all for it, as I expect a modern fork without systemd will coalesce for those of us that prefer Linux over Windows.

hi-v-rocknroll 2y ago

Cramming more NIH garbage down GNU/Linux users' throats. Nanomsg ng and cap'n proto already exist.