You list statements I made and rebut them as if every single sentence in that post is a reason why X is bad. Sometimes the sentences are used to introduce a reason why X is bad, or provide a comparison.

X is old, which explains why it has a lot of unused code. Wayland is an example of how you can replace X with something conceptually simpler, with other benefits. Dead code increases the barrier to entry for new developers, and causes the X project itself to be organizationally huge and lumbering.

Is Vista our gold standard for how good a composited desktop can be? If we can do better than Compiz, why shouldn't we?

Writing a compositor for X is harder because X has a lot of fiddly bits that compositor authors really shouldn't have to worry about, like global window positions and probing for COMPOSITE support. The Wayland protocol delivers bitmaps to compositors, and input events from compositors to client windows. That's it.

I meant developers no longer use it. If you know of a project started in the last 5 years that decided to use these features of X, and not use GTK or Qt or some other toolkit (which themselves don't use these features), I would like to hear about it because I genuinely don't know of any.

You will still be able to run xterm under a Wayland compositor, don't worry about that.

Input is a bit of a sticky wicket, but that's not exactly an insurmountable problem. Why should input devices be tied in with the display server (and in X's case, font rendering, vector graphics, ...)? I honestly feel like they're better off in a completely separate system that can be re-used elsewhere without bringing in all of X. Isn't that the unix philosophy?

See this cousin comment. All this old stuff it needs to support makes the X project huge and lumbering. Dead code stifles innovation because it scares off developers.

Yes, that is often the case with things you understand. I have tried and failed many times to understand X, I really have. I understood what the Wayland protocol does in about a day. As for the first part, code length is not the same as understandability, or even simplicity. You can have 1 kilobyte of brainfuck and 2 kilobytes of python, and the python is still simpler. Wayland provides bitmaps to compositors, and delivers input events from compositors to windows, and at no point do you need to probe some server for COMPOSITE support, or manage the child X window's global coordinates to correspond to where you're drawing them on screen, or muck around with who gets control of the root window. You get bitmaps, you draw them. You get input events, you distribute them however you please. It's really straightforward.

X is big and bloated, in the sense that X contains a lot of dead code. This severely limits how fast the project can move, and makes it hard to attract new developers. This is more important than (I think) most people realize. Nobody wants to work on a codebase where 90% of code isn't used (but has to keep working), and the 10% people actually do still use are all implemented as extensions. That's insane.

With regards to network transparency, see this other post of mine. I will never understand why this myth is perpetuated.

With regards to backwards compatibility, you can always run an X server on top of Wayland. It's not even particularly inefficient to do so, because Wayland is such a thin layer.

With regards to not gaining any features, removing X takes away one layer between applications and the screen. This matters, even today. If you're running a video game on a compositing window manager, that game's frame now has one less layer to pass through before it hits the screen. Using Wayland simplifies the Linux display process.

Basically, using Wayland will not prevent you from doing what you've always been doing, nor will it encourage developers to write programs that prevent you from doing what you're doing. What it will do is make it easier for those developers to make new things and be happy about it.

These two files, window.c and image.c, are an entire simple GUI toolkit and an example program using that toolkit, for use with a Wayland compositor.

This directory is an entire compositing window manager that speaks the Wayland protocol. This is already impressively small, but keep in mind that most of the complexity here is in actually drawing to the screen and getting input events from hardware, something that Wayland has nothing to do with, and it's *still* small.

Wayland is simple because it is small, and it's small because it only concerns itself with communication between compositors and applications. There are already good APIs for drawing (cairo, opengl), so Wayland lets application developers use those, or whatever else crops up in the future.

The feature I was referring to was demo'd here, where the presenter forwards a window from one display to the other, ending up with the same window on two displays. This is local in the demo, but he says that it's transferring graphics data over the network and I have no reason to not believe him. This presentation is from last month, almost a year after the blog post you linked.

I was not aware that this was a feature of X, but I would like to point out that this is not an *extension* of Wayland doing this, it's just a normal use of the Wayland protocol. It doesn't need special support in window managers or applications. This might also be true of X window forwarding, but you mentioned extensions/patches so it doesn't sound like it.

You will still be able to run X programs with Wayland. It's just a matter of running an X server that speaks the Wayland protocol as well. That's not giving up backwards compatibility. In fact, the demo uses an X11 program (IIRC).

Just because it can be added to X doesn't mean that's the best solution. X badly needs a cleanup, there is a lot of dead weight there and using Xlib is a pain in the ass. That's a breaking change no matter how you look at it. Most of what X used to do has been pushed into other libraries that do it better (like freetype, cairo, opengl, and kernel mode setting), and it no longer makes sense for there to be a central proxy server sitting in the middle and managing it all. If you get rid of X entirely, the only thing missing is a little bit of glue for applications to talk to window managers, and the Wayland protocol provides that. It's a much simpler model that provides the same features.

Wayland has an X compatibility layer, sure, but you may also be pleased to know that there are efforts underway to get native Wayland network transparency.

See, the cool thing about wayland is the protocol is written to be flexible enough to have some other program handle the network transparency part, seamlessly. It's not part of the core design of wayland simply because it doesn't have to be in the core at all.

An added bonus of this flexibility is the ability to do network-tranpsarency things that even X couldn't do, like move a window from one screen to another, possibly on another computer entirely. Yes, I'm serious. It's awesome.

X is a very old protocol, with a lot of things that need to be implemented in order for something to say that it "speaks X". Things like font rendering and 2d drawing routines. Things that nobody actually uses anymore.

X used to be in charge of providing font rendering and such, but now libraries like Freetype and Cairo do it instead (and do it better). X used to be in charge of accelerated video, but now we have good OpenGL support and Kernel Mode Setting. The only thing X really does now is act as a proxy between window managers and applications. But X still has support for all the old stuff, and so it's huge and lumbering.

Wayland is a new protocol designed to be used between window managers and applications directly. In a new breed of window managers, the window manager itself will set up the screen and draw to it using kernel mode setting and opengl, and it will communicate and delegate windows to applications by talking the Wayland protocol. So there's nothing like the X server sitting between them anymore: the window manager runs directly on the console, and talks directly to applications.

This might sound like it would cause a lot of duplication of effort, and in one sense that's true. However, the amount boilerplate code needed to set up a simple Wayland-speaking window manager is about the same as the amount of boilerplate code needed to set up a simple X11 window manager. Except with the Wayland case, there's no huge X server sitting between applications and the screen, because Wayland is so simple the window managers can speak it directly.

One side effect of this is the Wayland library API is *much* simpler to use than the X libraries, so it becomes a lot easier to write new experimental window managers. I expect we'll see a lot of new WM's after Wayland becomes standard. Another plus is that Wayland has built-in support for multiple pointers and arbitrary window transformations, and that's an extremely nice touch for multi-touch screens.

We got the sentiment that we could do anything, yes. But it also gave us, at least briefly, a reason to be humble.

To me, at least, this is the most important thing to come out of the Apollo program.

It might be whack-a-mole, but the law is having smaller and smaller ground to stand on.

All information is just a number; this sounds like a facetious remark but it's really central to this whole ordeal. A 3 megabyte MP3 file is an extremely large number (by our standards), usually somewhere around 2^3,000,000. A magnet URI is a much smaller number, usually around 2^128, and magnet URIs are literally just numbers.

The problem here is that current copyright law says numbers can't be copyrighted, and common sense even among non-math-literate folks says that no number should be illegal. I'm not about to argue that all data cannot be copyrighted, I'm just pointing out that there's a rather glaring inconsistency in copyright law that can be exploited by moving data needed to torrent something into a smaller string. Most people would be okay copyrighting 3 megabytes of data, but fewer would be okay with copyrighting 128 bytes. Especially if those bytes have no meaning other than just a number.

Wikipedia has a good article on Illegal Numbers. It's going to be a fun day when this all finally comes to a head.

I thought this too, for about a second. There's a lot of good IP that EA holds that could do with a very long and loving Valve-style update. But this would be a very dangerous move to make.

Valve is flat. Everybody decides for themselves what to work on. This is a hard environment to maintain, and so their hiring process is extremely important. It would be almost impossible to work in former EA employees without causing a major upset in Valve's company culture. The other option would be buying them but running them as a separate studio, which might work, but I would still fear culture leak.

Everything that Wayland does is possible under X, it just might be hard to write the X code to do it.

The biggest point to Wayland is that it is extremely simple (compared to X... X is huge), and it's capable of doing 95% of what people use X for. The other 5% is network transparency, a feature I hold dearly but one that I acknowledge not many people care about.

So what's so great about simple? For one, it's easier to maintain. It's also easier to write clients for, since it's almost entirely OpenGL (the Wayland part is small). The X library is a horrible horrible thing, and I would die happy if I never have to use it again.

This is almost exactly what Wayland is doing. Wayland is a communication protocol between compositors and the things they composite: usually, between window managers and applications. This means that the window manager is responsible for communicating with applications, and for pushing video data on to the screen (via OpenGL + Kernel Mode Setting). So instead of launching X, then launching a window manager on top of that, you just launch the window manager.

This is the primary advantage of Wayland: it's simple. Really really simple. It's basically just OpenGL and a protocol for delegating render surfaces to other applications (to render on to using OpenGL). By comparison, an X server needs font rendering, shape rendering, and a ton of other things that aren't used today anyway because everyone uses freetype and cairo and such. Wayland leaves those out and expects you to get that from other places (like, say, freetype and cairo).

(Wayland is also the name of a C library implementing the Wayland protocol. The Wayland project also produces the Weston compositor, as a reference implementation of a simple "window manager".)

The DSL Linux CD disk is read by a LASER radiation beam.

I initially wrote this to be facetious but laser radiation beam actually sounds cool.

Be very careful here. Most applications written for iOS are written in Objective-C, while most applications written for Android are written in Java. Yes, they share very similar underlying design philosophies, and some of the same underlying tech (OpenGL, posix), but porting can still be very difficult. Compiling Objective-C for Android would be a nightmare, and converting Java bytecode into something compiled for iOS is similarly hard, and that's after you write an API compatibility layer.

Mobile programs are only easy to port if they were written from the beginning with porting in mind, either by using an intermediate API and langage (like MonoTouch), or by writing everything in C and keeping the Objective-C/Java parts to a minimum. Unless this was planned, most people don't go this route, and porting those programs would be more appropriately called "rewriting".

The situation between OSX and Linux is similar (though not quite as bad). Porting from Linux to OSX is easy, because most Linux programs are written in languages also available on OSX. However, OSX to Linux is hard because, again, most OSX apps are written in Objective-C. You can compile Objective-C on Linux, and a lot of OSX APIs are re-implemented by the GNUStep project, but GNUStep is missing proper support for some language features that are heavily used in OSX. Which means that native OSX apps that were not written with porting in mind become extremely hard to port.

The good news in the specific case of Steam for Linux is that almost anything available on Steam for OSX is also on Windows, which means it has already been ported, and porting to Linux shouldn't be that hard. So yes, this statement is correct in this specific case, but your comparison isn't and "it's easy to port from OSX to Linux" is an extremely common misconception.

As RMS mentioned, the danger is not in Linux becoming a locked down system, the danger is in people using Linux because it costs nothing rather than because it gives its users freedom. Whether you agree with RMS's stance on freedom or not, it is pretty clear that making Steam on Linux a major selling point of the platform would detract from the message of freedom.

I would also remind you that the choices we hold so dear as Linux users are a direct result of these freedoms, such as the freedom to change the software you run as you see fit. Linux itself, and the GNU tools that run on top of it, will always remain free. But Linux is also a tool for promoting the idea of freedom, and Steam on Linux might weaken that.

(Personally I can't wait for it, though.)