Hacker News Reader

Comment by newuser88273 | Hacker News Reader

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.

View on HN

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

[1] http://cgit.freedesktop.org/wayland/wayland/tree/src

[2] http://cgit.freedesktop.org/dbus/dbus/tree/dbus

> 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/88ee6c1ed82999febc64b9... https://github.com/panzi/qjoypad/blob/88ee6c1ed82999febc64b9...

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.

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.

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.

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.

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.

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.

> 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.

The kernel does not have a stable ABI, and none of the developers really commit to significant backwards compatibility - they just maintain LTS kernel tree branches for those that want to stay in one spot.

The same thing happened with the gstreamer 0.x and 1.x forks, except every Linux release is effectively a new GST release, albeit the APIs userspace uses against the kernel rarely break, it is a huge spread of APIs and one or another usually does change each release.

Can I use software written for an release (lets say 0.8.x) of gstreamer, and have it run correctly against a modern release (such as 1.2.x or 1.4.x)?

Because that works with th kernel, as it most certainly does have a stable userspace ABI. Internal stability is not a big concern unless you're trying to hide the source code (proprietary driver). Linus' guarantee about not breaking userspace is very widely known, so I'm sure you know this.

The GP was absolutely correct: while you have the luxury of being able to "move fast and break things" as a leaf app that nobody depends on[1], for most everything else "reliability" and "doesn't give me lots of extra work" are far more important than any other feature.

This is really just an extension of why it is considered a good idea to write maintainable, modular code instead of leaving people with a mess of spaghetti to debug.

[1] That changes if your userspace grows and people ARE depending on it.

Reply on news.ycombinator.com