3 ms·

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 confusin

by hp 12y ago

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.

krig 12y ago
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.
- hp 12y ago
  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.
  - krig 12y ago
    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.
  - krig 12y ago
    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.
    - hp 12y ago

by hp 12y ago

krig 12y ago

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.

hp 12y ago
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.
- krig 12y ago
  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.
- krig 12y ago
  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.
  - hp 12y ago