Nah, more like why do systemd include anything to do with DNS at all.
The shoggoth keep sprouting pseudopods as devs gets bored and think they can reimplement a time tested daemon in a weekend.
The shoggoth keep sprouting pseudopods as devs gets bored and think they can reimplement a time tested daemon in a weekend.
"Ph'nglui mglw'nafh Cthulhu Raleigh[1] wgah'nagl fhtagn" ("In his house at Raleigh, dead Cthulhu waits dreaming.")
1. I'm so sorry, but I couldn't keep myself from punning Red-Hat-sponsored systemd with the Cthulu mythos. For the non-Lovecraft fans, the original city is named "R'lyeh"
Specifically, DBus does not use XML for any message passing or data serialization. It uses its custom binary on-wire format.
Also to consume or provide DBus services you do not need to interact with any XML whatsoever (except maybe for Polkit but that’s not DBus).
Except backwards compatibility? Something that any user of a supposedly-universal IPC bus requires out of the gate?
> It uses its custom binary on-wire format.
Even better, as we all know that custom binary on-wire formats have been proven to be more secure than any other option. Especially when written in C and exposed to a processes of all privilege levels.
You can put DBus server behind a proxy that handles that for you. The XML format is very simple and it doesn’t change.
My point was simply that XML use is very limited, not exposed by any high-level APIs and can be easily ignored.
XML is only used for introspection, a debug protocol on top of DBus.
> Even better, as we all know that custom binary on-wire formats have been proven to be more secure than any other option. Especially when written in C and exposed to a processes of all privilege levels.
DBus is a message-passing protocol. You can write it in anything you like.
You could have DBus server that talks Protocol Buffers or JSON if you like, as long as you provide gateway for legacy clients.
Saying "you can change it to whatever you want" is not a helpful thing to say. I understand your point (it's not "baked in" or wahtever) but you're not helping your cause by stating that "oh, we could just change this part of the protocol whenever we want and it would all just work". Because it gives an aura of instability and "we can move fast and break things" in my eyes (even though DBus has been around for a long time).
> DBus is a message-passing protocol. You can write it in anything you like.
The message passing daemon is written in C, and kdbus is a plan to put it inside the kernel (written in C). Just because "you can write it in whatever language you want" doesn't change that it is currently written in C, and I doubt that anyone is going to rewrite it in Rust any time soon.
Again, I understand that DBus is a protocol and an implementation and you can swap out the implementation if you want. But how many implementations currently exist? One. So currently the dangers of having custom binary formats in C is a valid concern even if you might be able to switch to some other implementation in the distant future.
I get your point about the inertia of there being one de facto implementation, but that’s not quite true. For example Glib’s DBus library contains an (almost) fully featured server implementation.
Anyway I’m not all that worried about the parser in particular. For one DBus wire format is well defined and pretty straightforward. This isn’t ASN.1. Actually it’s probably way simpler than modern DNS with EDNS, DNSSEC etc.
You're spot on.