Hacker News Reader

Here is the full context about the auth protocol in the spec:

Authentication Protocol

Before the flow of messages begins, two applications must authenticate. A simple plain-text protocol is used for authentication; this protocol is a SASL profile, and maps fairly directly from the SASL specification. The message encoding is NOT used here, only plain text messages.

In examples, "C:" and "S:" indicate lines sent by the client and server respectively.

Protocol Overview

The protocol is a line-based protocol, where each line ends with \r\n. Each line begins with an all-caps ASCII command name containing only the character range [A-Z_], a space, then any arguments for the command, then the \r\n ending the line. The protocol is case-sensitive. All bytes must be in the ASCII character set. Commands from the client to the server are as follows:

Yes, there's an auth protocol before the actual dbus protocol - there are two protocols in the spec. I think that's what you are missing.

Perhaps it's confusing but slow down and understand the tech before criticizing. It is not in fact an ASCII-only binary protocol. Other engineers do sometimes know what they are doing.

Let me get this straight. To you, there is nothing wrong with embedding a separate ASCII protocol for authentication inside a binary protocol? Of course I realize that the quoted text about ascii-only describes a subset of the full protocol. To do this is ridiculous and bad engineering.

I also note that you completely ignored "If you know what this means, please contribute documentation via the D-Bus bug tracking system." appearing in the specification. Seriously. This is not a specification. This is a poorly written description of an existing mess of a wire protocol.

Other engineers clearly do not know what they are doing.

I don't see the problem with having two protocols on one socket, as long as its defined how it works (how to switch over). HTTP for example supports switching to websocket.

The spec has always said it was informal and needed more work, for at least a decade now. Many people have implemented dbus and rewriting the spec hasn't been enough of a priority for any of them to do it. To me that says that while many are willing to say "it should be better" (including me) none of them are willing to say "and it's important enough to spend my next few months on" (including me). But the beauty is that at any time someone is free to change that.

I think it's wrong to say something is must-have when it obviously by existence proof has not been must-have. And in fact a lot of tech that had the must-have failed. Say CORBA, which certainly had specs. They were just specs that specified the wrong thing. I'd rather have the (approximate, good enough) right thing with an informal but good enough spec (to a motivated reader giving it a chance), than pay a bunch of committee people to write down a design that failed to solve the requirements.

I would absolutely argue that websockets is a terrible protocol as well, and the only justification for it that I can see is that it was created as a hack on top of HTTP. It's certainly not the model of an ideal protocol design or the correct way to design things from scratch.

I also think it is perfectly fine to have a reference implementation without a formal specification in many cases, and I don't think specification-first necessarily leads to a better protocol. As you point out, CORBA is certainly horrible as well.

Just because no one has replaced dbus it isn't good enough. The ever-appearing mantra of "if you don't like it, write your own" is boring. It is perfectly reasonable to point out what is wrong with a protocol in wide(ning) use without immediately presenting a fully formed alternative. It could be that most people have more pressing concerns than individually fighting Red Hat and all the projects invested in dbus for control over Linux userspace.

There is no dichotomy here, the only choices are not silently accepting the protocols we have or "paying a bunch of committee people".

I don't think you're seriously proposing that anyone could just step in and redesign dbus from within the existing project structure at this point. Any changes would be fought tooth and nail by the people invested in it right now. Any replacement would necessarily be a completely separate project, and it would have extremely slim prospects of succeeding. It's not surprising that people aren't doing that, even though dbus is flawed.

We are stuck with a lot of terrible things. The only way any of them will be fixed is for enough people to get angry enough to do something about it.

Alright. I didn't realise that I was talking directly to one of the designers of dbus, which makes some of the things I said unnecessarily harsh and perhaps even personal. Apologies for that.

I have to ask, though - why engage in a thread like this? Clearly, dbus is successful, it is being integrated into the kernel, it is used all over Linux user space by now and whatever flaws it has are clearly not impeding its use. So why bother arguing about the spec on HN?

I could sit down and discuss what an improved protocol might look like, but I don't even know if I agree that /any/ protocol that does what dbus does is the right approach, and either way, this is not the place to do so.

Why engage is a good question :-) I had the misfortune to see a link on Twitter and discover people were wrong on the Internet.

I do think there's useful stuff to learn and discuss here about software development and dbus itself if people dig in and understand it. Perhaps some bystanders will learn something.

I welcome improving and even disrupting and replacing dbus but I don't think the kind of criticism found in this article will lead to that.

I did learn a lot, thanks for commenting. It also seems like you agree with the premise of the article that there is confusing stuff in, what you called 'informal' spec, but explained why. So, thanks again.

>I have to ask, though - why engage in a thread like this?

Does he need an excuse for wanting to correct misinformation ?

No, I am just curious. It seems overly defensive. In game development, there was/is a guy named Derek Smart who is famous for popping up in every thread on the internet about one of his games and defending it relentlessly. The result is that every thread on the internet about one of his games devolves into endless flamewars. There are multiple examples of authors writing long responses to every single review of their books on amazon, resulting in a sort of game of insults between author and reviewers.

As the designer of something, you are too invested in it to handle someone going "this sucks!" well. My advice would be to sit back, recognize that the other person saying this is not invested to the same degree, is looking at the problem from the completely opposite perspective and is not familiar with the reasons behind every single compromise made, or why a certain feature seemed like a good idea at the time but turned out not to work in practice. Let someone else handle the defense.

It doesn't matter if there are valid criticisms to be made - inevitably, everyone describing the specification who weren't involved in writing it will misunderstand something, or leave something out, or quote something out of context or incompletely, or have completely different concerns in mind than the authors did - and as that author you are drawn to such things like a moth to the flame. But you have to resist the flame. After all, you wrote it, it does what you intended, you released it. If someone else wants something different, let them be unhappy and maybe if they are unhappy enough they will come up with their own thing.

>It seems overly defensive.

Based upon this one instance where he shows up and correct misgivings ? Seriously ?

If anything you come across annoyed that your uninformed ranting was corrected.

I didn't find any of hp's comments defensive in the slightest.

Every one of hp's posts in this thread have been informative. Many of them were written as responses to cries arising from the mob with pitchforks and torches, but that doesn't reduce their utility. Given that both the original article, and your comment, made much of the "ASCII binary protocol", explaining the apparent contradiction certainly raised the signal to noise ratio here.

Well, I don't disagree with any of that. I wrote my comments in a bad mood and they came out harsher than I wish they had. I'm just thinking that if I was the author of dbus, I wouldn't engage the noise on HN. It was an honest question and I got an honest reply, and that's great.

Hey, all I did in my comment was to quote from the spec. My complaint (well, one of them) is that it's a "binary" protocol but it requires parsing just like an ascii protocol, it encodes data as ascii values and it even embeds a full ascii protocol in the auth sequence. (not to mention XML for reflection with an embedded type DSL in attributes, ...)

In my experience (having submitted many patches) it is very hard to get patches accepted to fdo projects. It may be because the maintainers are salaried by RedHat, so they get new task assignments and are removed from maintainership of the packages. E.g here is a six year old patch lingering:

https://bugs.freedesktop.org/show_bug.cgi?id=16783

Someone certainly could write a bunch of patches to make the dbus specification better. But to get those patches included into the official dbus specification is a completely different problem. And you know that. Having spent a lot of effort in this thread defending the dbus spec as adequate, you wouldn't be the one spending your time integrating their patches.

You could see the blog post as a bug report. Pointing out weaknesses in the spec that could use improvement. Or you could see it as just another guy ranting on the internet.

If I had touched any of this stuff in years I might treat it that way in part (after expressing annoyance), but I'm not currently involved - my ssh key probably doesn't even work anymore, but if it did I'd still go through the current maintainers like anyone else because I haven't been keeping up with the latest.

The current people doing this kind of work deserve non-abusive informed criticism. It isn't OK to post a long diatribe of BS and then expect people to take it as if it were a helpful bug report. It isn't helpful. It's jackassery and unacceptable and this kind of abuse has done more damage to Linux than anyone knows.

It is entirely OK to ask questions or file bugs without sending patches. Just don't be an ass about it like this article was.

> A nul byte in any context other than the initial byte is an error

Oh, just found this in the spec, too:

"The marshalling formats for the string-like types all end with a single zero (NUL) byte"

The first quote talks about the auth protocol, while the second talks about the DBus protocol proper.