Varlink – IPC to replace D-Bus gradually in systemd

Original Article ↗ Hacker News Discussion ↗

Varlink, a proposed JSON‑based IPC mechanism intended to gradually replace D‑Bus in systemd, is drawing mixed reactions from developers. Supporters argue that using plain text JSON over simple sockets improves debuggability, lowers the barrier to writing services, and avoids the complexity and context‑switch overhead of a bus broker. Critics counter that JSON is ill‑suited for low‑level system IPC due to inefficiencies, weakly specified numeric semantics, lack of native binary and 64‑bit integer support, and see Varlink as another unnecessary reinvention amid existing binary formats and IPC systems.

Serialization format (JSON) choice

  • Many criticize JSON for IPC: text-based, larger payloads, expensive to parse on low-end or high-volume systems, poor numeric model (no precise universal 64‑bit ints), weak typing, and awkward handling of binary data (base64 overhead).
  • Others argue JSON parsing is extremely fast in practice, messages are small and infrequent for system IPC, and marshalling cost is negligible compared to context switches.
  • Ubiquity is a major pro: every language has JSON libraries, often in the standard library, making bindings trivial.
  • 64‑bit integer handling is contentious: some emphasize JSON/I‑JSON float constraints and real parser limits; others say large ints can be encoded as strings or that most systemd use-cases don’t actually need >2⁵³ precision.

Performance and IPC architecture

  • Many see D-Bus’s main performance problem not in serialization but in the broker: extra context switches, enforced rate limits, and multi-step “summary then details” patterns.
  • Varlink uses direct Unix sockets, fewer roundtrips, and can “upgrade” to raw connections for bulk data, which some view as a net win.
  • Skeptics question assuming “hundreds of messages/sec” is the ceiling; system buses can see heavy traffic (desktop plugins, file managers, mass events), where JSON size overhead might matter.

Alternatives discussed

  • Proposed alternatives: CBOR (or DAG‑CBOR), MsgPack, ASN.1 (PER/OER/DER), protobufs, Cap’n Proto, existing Android Binder, Wayland-style protocols, or even raw C structs over Unix sockets.
  • Long subthread debates ASN.1’s complexity vs completeness, and protobuf/Cap’n Proto’s TLV tradeoffs, extensibility, and tooling.
  • Some feel reinventing IPC instead of adopting mature alternatives is needless NIH; others note prior attempts (kdbus, BUS1) failed to land.

Debugging and observability

  • A core justification for JSON: messages are readable in strace, fitting Unix’s “text by default” ethos and making debugging dramatically easier without specialized tools.
  • Critics respond that better tooling (e.g., strace/wireshark-style decoders for binary formats) would avoid compromising on the protocol itself.

Scope, coexistence, and ecosystem impact

  • Varlink is not a bus; it’s a point‑to‑point IPC with schemas and a resolver. Some welcome its simplicity and low barrier to writing services (e.g., quick Python scripts).
  • Others worry about “yet another IPC layer” beside D-Bus: more complexity, attack surface, and long-term churn in fundamental Linux plumbing.
  • Current reality: systemd already uses varlink alongside D-Bus; coexistence is accepted, but long‑term direction and migration strategy remain unclear.