The cause of that accident was poor interaction between computer and human.

Short summary:
Due to a faulty sensor, the auto-throtle dediced to throtle down the plane.
The crew recognized that and manually throtled up again.
But then they made two errors: taking the the hands off from the throtle and without disconnecting the auto-throtle.
The auto-throthle then throtled down again and it took the crew 100 seconds to realize their mistake, at which point it was too late.

Chrisq's poins is that the US Airways plane which landed in the Hudson was also an Airbus, with the exact same type of automation as the Air France which crashed in the Atlantic.

One could also point out that, during the process of landing it into the Hudson, the pilot flew the aircraft into the alpha protection limit, which means the flight control system stopped the plane from landing.
One could argue that pilot knew what he was doing and simply to chose to make the best use of the flight control system
But the flight control system did play a role in landing that plane.

TLS 3.0 already allows for multiple sites on one IP.
The DANE proposal would eliminate the need to have a CA signed certificate, as long as you have DNSSEC on your domain.

Encrypted data does not compress well, but it's a common step to compress data before encrypting it (removing redundancy makes it harder to break encryption).
TLS (SSL) does this.
There are actually some security issue with TLS and compression (BEAST, CRIME) but they should be fixed by the time HTTP 2.0 is adopted.

The code in the benchmark runs a parallel for over a 10 billion element array but in steps of 100 elements.
It's going to be limited by the creation and destruction of threads.

Also, by not initializing the input array, the floating point arithmetic is vulnerable to eventual denormal values.

No, you need to make a distinction between using XRender and actually making efficient, network friently, use of XRender.

If you care about rendering across the network, the good/efficient way to use XRender, it to send many (typically small) pixmaps to the server, which can actually be reused (and cached) and then send XRender commands to draw your application, reusing those pixmaps.
Ie, you send a pixmap for an "a" in a given size and font and then you can reuse the pixmap to draw every A of that size and font in your application.

The problem is that increasingly, toolkit/application don't use XRender in this way.
Even if they do still use XRender to stitch the pixmaps together, the pixmaps they're sending are, increasingly, large non-reusable pixmaps.
Which means there's little, if any, bandwidth improvement.

The advantages of having server side rendering, like X does, are increasingly going unused by actual applications.

The problem is that modern application/toolkits need to send stuff to the server that it no longer works that well over the network.
In fact, they often need to send so much Xrender commands that modern application/toolkit developers just give up on trying to make efficient use of Xrender and just start dumping pixmaps to the Xserver, with a minimum use of Xrender to stitch them together.

http://blog.qt.digia.com/blog/2008/10/22/so-long-and-thanks-for-the-blit/
Even by Qt4.5, they found out that their pure software backend (Raster) was fast than the XRender one (Native).

Whatever the cause, more and more ssh -X only works well over high bandwidth, low latency and beyond that we need to use middlemen like VNC, RDP or NX.

Regarding Qt5, I guess the still need to call some XRender function actually draw the pixmap or some other hidden dependency.
But I can only find references to two backends on Qt5: Raster and GL.

Arguing about what features a display server protocol has or not to be worthy of being called X12 is a useless discussion to begin with.
Much more so when you consider how X1 to X10 looked.

- Even on X11, the client does not know where the pixels are going in the screen. In the end, the compositor does what it wants.

- XRender allows you to do a lot of things "efficiently" but we can do them more efficiently with direct or client side rendering and just push a shared memory buffer to the server. Even on X11. Qt5 will not use XRender.

X11 was introduced in 1986 and was not backwards compatible with X10.
So, it has happened in the (very distant) past, but not as you may think it did.

It's not possible to achieve what Wayland strives to achieve and keep X any more than Wayland does, unless you're satisfied with simply calling the Wayland protocol "X12" and be done with it.

There are two main problems.
First, there are problems in the X11 server/client protocol that can only be fixed by creating a new major extension, where a client connects and says "I'm a X12 client and I swear I won't ever speak X11 to you", and the X12 protocol would look awfully like Wayland.

Second, there are problems with the X11 model of display server (X.org), window manager/compositor (Mutter (GnomeShell), Compiz (Unity), Kwin, Enlightenment etc, etc ) and clients.
Wayland fixes those problems by merging the role of the display server and of the compositor are merged into the same piece of software, the Wayland compositor.
That has a number of advantages (better performance, the compositor has full control over the input the clients get) but it's only feasible because, due to the simplicity of the Wayland protocol, writing a Wayland compositor can be not much harder than writing a X compositor.
This is not feasible if we were to try and write compositors which also act as an X11 server, due to the sheer size and complexity imposed by the X11 protocol (core + modern extensions).

The Wayland architecture is much cleaner and much more feasible.
We'll have several Wayland compositors (Mutter, KWin, Enlightenment, etc), which are only burdened with speaking the Wayland protocol to Wayland clients.
And a modified X.org rootless X server (Xwayland), which is also a Wayland client, will support X11 applications (as good or better than before).

Check this presentation by Daniel Stone (one of the X.org developers) on the problems with X.~

http://www.youtube.com/watch?v=RIctzAQOe44

Yes and no.

Weston is only a reference implementation of a Wayland compositor.
Wayland developers don't expect it actually to be used by normal users.

Instead, they expect others to implement their own Wayland compositors, as it should not be any harder than writing a similar X Window Manager.
That is what the Gnome, KDE and Enlightmenment people plan to do, convert their current X compositors (gnome shell, kwin, e) into Wayland compositors.

So, eventually, you might get a dwm Wayland equivalent. But it doesn't exist yet.

Canonical may hope, but it's naive.
NVIDIA provides binary drivers for Linux for over a decade because it actually has paying customers, running (often expensive) 3D (and now GPGPU) applications on (often expensive) NVIDIA hardware.
Ie, the Oak Ridge National Laboratory has the world's 2nd most powerfull supercomputers. It has hundreds of NVIDIA K20 cards and it runs Linux.

And those customers tend to run RHEL or a clone or SUSE, because those are the supported platforms.

Err, no.
DRI get X out of the way a lot, but there still areas for improvement.

Besides using DRI for rendering (or doing it client side), once done rendering a frame, the X client needs to notify the X server so it can notify the X window manager so it can do it's job and notify the X server again so the frame can actually finally show up on screen on the correct place.
And while in theory an X server could do this very quickly and efficienty, the real X.org server is quite slow.

Clients also need to talk to the X server over other things like object property manipulation.
Once more, in theory an X server could handle this quickly and efficiently, the real X.org server is quite slow.

(And full screen does help, as there's less of this going on).

All in all, Wayland won't get you higher frame rates in Portal. But it will make your desktop smoother, with less CPU/GPU usage.

The Quote: http://www.youtube.com/watch?v=RIctzAQOe44

Of course, using direct rendering, specially on a full screen application, you're bypassing the X server and it's slowness as much as possible.

They already did, it's http://jntlesnev5o7zysa.onion/
You can get though a tor2web proxy at https://jntlesnev5o7zysa.tor2web.org/