6 ms·

X11 was a great success because it was a protocol that you could write X servers and X clients and X window managers against. Nobody wants to do that anymore.

X11 was a great success because it was a protocol that you could write X servers and X clients and X window managers against. Nobody wants to do that anymore. There are two major forces to blame. First, open source. A well designed protocol is much more work, and you can avoid it by just pointing to the open source'd implementation, as this article (hilariously) shows for the case of DBUS. The second force is the adware/spyware model of web and app monetization. You don't want people to use their own clients against a protocol (email, usenet, web 1.0) because you can't serve ads as effectively and you can't run analytics on their every mouseclick, touch gesture and keypress. The whole systemd debacle would be much defused if systemd had been a couple of well thought-out and stable protocols, much like X11, instead of a big source-blob of underspecified and ever-shifting implementation.

drdaeman 12y ago
Well, you certainly have a point, but I'm not sure you're right or not. Pointing to a library instead of protocol isn't some recent fad. Say, this was the case with ALSA/libalsa. I guess OSS folks had ranted, yet ALSA is what we've ended with. So, it's certainly not something related to webapps and proprietary APIs. Well, I think in 2000s everyone who had some relation to FLOSS just hated such things. Microsoft's stuff had been a pain in the ass, probably more than they are now. Although, the webapp trend may have had influenced overall mentality with "aw, just link to this and you're good." Some sites, notably, Mega, had even switched to that model from a previous API-first approaches. There are also cases where implementation-first approach has worked well, though. For example SQLite - while most users just link to the library, the format is well-documented, thought out and is quite sane. So, systemd can recover. I'm not keeping myself up-to-date with news on that, but I think I've heard (maybe, incorrectly, though) there are some efforts in that direction. Just my thoughts on this.
nly 12y ago
It's interesting that you mention X11. The Wayland developers recognised that X11 had not only become fat, which isn't inherently problematic, but that almost all of the old fat had become dead weight. X11 essentially became a horrific over-engineered, vaguely graphics related, IPC mechanism... just like DBus. Wayland is an RPC protocol. I'm kind of hoping IPC mechanisms similar to those used by Wayland, which fell out of all the work on XCB (a clean X11 equivalent binary protocol for Xorg that, iirc libX11 is now built on top of), will ultimately be adopted by other projects. Interestingly they implemented RPC dispatch using libffi, which is pretty elegant. The Wayland FAQ, in fact, has a rationale for avoiding DBus[0]. The core Wayland framework certainly hasn't suffered in terms of bloat or complexity by avoiding it. Go look at the code[1], and compare it to DBus[2]. Admittedly the topologies are different, but as far as I'm aware nothing prevents Wayland clients from establishing their own P2P communications. [0] http://wayland.freedesktop.org/faq.html#heading_toc_j_10 http://wayland.freedesktop.org/faq.html#heading_toc_j_10 [1] http://cgit.freedesktop.org/wayland/wayland/tree/src http://cgit.freedesktop.org/wayland/wayland/tree/src [2] http://cgit.freedesktop.org/dbus/dbus/tree/dbus http://cgit.freedesktop.org/dbus/dbus/tree/dbus
- digi_owl 12y ago
  In large part because programmers started to assume they could talk directly to the hardware, rather than the hardware being at the other end of some random network connection. This then makes a large part of X11 redundant, as it is there to make things network transparent.
- panzi 12y ago
  > XCB (a clean X11 equivalent binary protocol for Xorg that, iirc libX11 is now built on top of) I thought XCB implements the same protocol but provides another (more modern) API. Am I mistaken? I never wrote code using libx11 or libxcb. Well, not 100% true, I forked and improved a tiny project that touches X11 at two small points. Doesn't really count. I don't get any understanding of X11/XCB from that: https://github.com/panzi/qjoypad/blob/88ee6c1ed82999febc64b965d4bcf27432f221e0/src/event.cpp#L5 https://github.com/panzi/qjoypad/blob/88ee6c1ed82999febc64b9... https://github.com/panzi/qjoypad/blob/88ee6c1ed82999febc64b965d4bcf27432f221e0/src/getkey.cpp#L47 https://github.com/panzi/qjoypad/blob/88ee6c1ed82999febc64b9...
  - dllthomas 12y ago
    This is basically true. It's the same packets on the wire - the biggest difference is that for most packets libx11 waits for a response while xcb returns a token representing a promise.
zanny 12y ago
Protocols are not exclusively a good thing. People constantly try to reinvent email, but because any attempt to fix the problems requires modifying the SMTP and IMAP protocols and formatting you are fucked from the get go because you break protocol compatibility. That is also why Wayland is having such a hard time. Every program and compositor is written against the X protocol and supplemental libraries, and any attempt to fix the protocol requires a backwards incompatible reimplementation. So protocols are not a catch all solution - they are better than just undocumented spaghetti, but protocols imply bureaucracy and inflexibility, whereas dbus and systemd and gstreamer can move fast and break things without being beholden to a big beefy documented protocol standard to also break and try to get people to transition on.
- quotemstr 12y ago
  Do you really think the world would be better place right now if email had been distributed as a library and not as a protocol anyone could implement? How could that possibly have worked? And how could it possibly have solved compatibility problems? It's not as if you can get everyone to upgrade libraries simultaneously.
  - zanny 12y ago
    The library becomes the de facto protocol. The difference is that there is a mindshare that updating libraries to stay current is less intrusive than having a protocol revision change break backwards compatibility. I don't necessary think it would have been better, or even feasible, just that it is a situational quandary, not just the black and white "protocols always win". Protocols enable interoperability at the cost of rigidity and resistance to change. You should protocolize when you are are damn sure you aren't changing anything else, and there have been very few technologies where you can say the protocols conceived a decade ago are still problem free today.
- jude- 12y ago
  > whereas dbus and systemd and gstreamer can move fast and break things I think you will find that this attitude is exactly the opposite of what is expected at the plumbing layer. Move fast and break things is fine when no layers depend on you to remain stable (see also, the Web). Imagine how hellish life would be if Linus et al. took this attitude towards kernel development.

drdaeman 12y ago

Well, you certainly have a point, but I'm not sure you're right or not. Pointing to a library instead of protocol isn't some recent fad. Say, this was the case with ALSA/libalsa. I guess OSS folks had ranted, yet ALSA is what we've ended with. So, it's certainly not something related to webapps and proprietary APIs. Well, I think in 2000s everyone who had some relation to FLOSS just hated such things. Microsoft's stuff had been a pain in the ass, probably more than they are now. Although, the webapp trend may have had influenced overall mentality with "aw, just link to this and you're good." Some sites, notably, Mega, had even switched to that model from a previous API-first approaches. There are also cases where implementation-first approach has worked well, though. For example SQLite - while most users just link to the library, the format is well-documented, thought out and is quite sane. So, systemd can recover. I'm not keeping myself up-to-date with news on that, but I think I've heard (maybe, incorrectly, though) there are some efforts in that direction. Just my thoughts on this.

nly 12y ago

It's interesting that you mention X11. The Wayland developers recognised that X11 had not only become fat, which isn't inherently problematic, but that almost all of the old fat had become dead weight. X11 essentially became a horrific over-engineered, vaguely graphics related, IPC mechanism... just like DBus. Wayland is an RPC protocol. I'm kind of hoping IPC mechanisms similar to those used by Wayland, which fell out of all the work on XCB (a clean X11 equivalent binary protocol for Xorg that, iirc libX11 is now built on top of), will ultimately be adopted by other projects. Interestingly they implemented RPC dispatch using libffi, which is pretty elegant. The Wayland FAQ, in fact, has a rationale for avoiding DBus[0]. The core Wayland framework certainly hasn't suffered in terms of bloat or complexity by avoiding it. Go look at the code[1], and compare it to DBus[2]. Admittedly the topologies are different, but as far as I'm aware nothing prevents Wayland clients from establishing their own P2P communications. [0] http://wayland.freedesktop.org/faq.html#heading_toc_j_10 http://wayland.freedesktop.org/faq.html#heading_toc_j_10 [1] http://cgit.freedesktop.org/wayland/wayland/tree/src http://cgit.freedesktop.org/wayland/wayland/tree/src [2] http://cgit.freedesktop.org/dbus/dbus/tree/dbus http://cgit.freedesktop.org/dbus/dbus/tree/dbus

digi_owl 12y ago
In large part because programmers started to assume they could talk directly to the hardware, rather than the hardware being at the other end of some random network connection. This then makes a large part of X11 redundant, as it is there to make things network transparent.
panzi 12y ago
> XCB (a clean X11 equivalent binary protocol for Xorg that, iirc libX11 is now built on top of) I thought XCB implements the same protocol but provides another (more modern) API. Am I mistaken? I never wrote code using libx11 or libxcb. Well, not 100% true, I forked and improved a tiny project that touches X11 at two small points. Doesn't really count. I don't get any understanding of X11/XCB from that: https://github.com/panzi/qjoypad/blob/88ee6c1ed82999febc64b965d4bcf27432f221e0/src/event.cpp#L5 https://github.com/panzi/qjoypad/blob/88ee6c1ed82999febc64b9... https://github.com/panzi/qjoypad/blob/88ee6c1ed82999febc64b965d4bcf27432f221e0/src/getkey.cpp#L47 https://github.com/panzi/qjoypad/blob/88ee6c1ed82999febc64b9...
- dllthomas 12y ago
  This is basically true. It's the same packets on the wire - the biggest difference is that for most packets libx11 waits for a response while xcb returns a token representing a promise.

zanny 12y ago

Protocols are not exclusively a good thing. People constantly try to reinvent email, but because any attempt to fix the problems requires modifying the SMTP and IMAP protocols and formatting you are fucked from the get go because you break protocol compatibility. That is also why Wayland is having such a hard time. Every program and compositor is written against the X protocol and supplemental libraries, and any attempt to fix the protocol requires a backwards incompatible reimplementation. So protocols are not a catch all solution - they are better than just undocumented spaghetti, but protocols imply bureaucracy and inflexibility, whereas dbus and systemd and gstreamer can move fast and break things without being beholden to a big beefy documented protocol standard to also break and try to get people to transition on.

quotemstr 12y ago
Do you really think the world would be better place right now if email had been distributed as a library and not as a protocol anyone could implement? How could that possibly have worked? And how could it possibly have solved compatibility problems? It's not as if you can get everyone to upgrade libraries simultaneously.
- zanny 12y ago
  The library becomes the de facto protocol. The difference is that there is a mindshare that updating libraries to stay current is less intrusive than having a protocol revision change break backwards compatibility. I don't necessary think it would have been better, or even feasible, just that it is a situational quandary, not just the black and white "protocols always win". Protocols enable interoperability at the cost of rigidity and resistance to change. You should protocolize when you are are damn sure you aren't changing anything else, and there have been very few technologies where you can say the protocols conceived a decade ago are still problem free today.
jude- 12y ago
> whereas dbus and systemd and gstreamer can move fast and break things I think you will find that this attitude is exactly the opposite of what is expected at the plumbing layer. Move fast and break things is fine when no layers depend on you to remain stable (see also, the Web). Imagine how hellish life would be if Linus et al. took this attitude towards kernel development.