As for pushing back work to the toolkit developers, the Qt developers made the software (client side) backend the default back in Qt 4.4, because it was so much faster than the XRender based one for local clients. And for Qt5, they simply didn't bother to implement a XRender based one.
Yes I could. Or that we're just a dream of some creature.
But that doesn't mean science is pointless. The point in science is to have repeatable experimental results and produce reliable knowledge to advance our understanding and life.
If a christian-like God exists, then he his apparently content in letting us use the scientific process to find how the Universe he built works. He clearly doesn't screw around with the laws of physics on a daily basis. Scientists worth the title who also happen to believe in a God are as skeptical of physics defying events as any one.
But again, we have no scientific proof that he exists or not. The christian concept of God, of a sentient all power being, makes it impossible to have such proof.
If there's a God, like the christian one, he is conscious and all powerful. He can do whatever he wants, including making the Universe work as if he did not exist. He can subvert any experiment you can can come up to test his existence. The end conclusion is that it is scientifically impossible to prove that God exists or doesn't exist. Stating that God probably does not exist is not science.
Don't take this the wrong way, but I think people who, like you, try to use this kind of pseudo scientific argument to state that God does not exist are just giving science a bad name.
It has been implemented for Windows server, AFAIK. But saying rootless RDP is network transparent is a hell of an abuse of the term "network transparent". Which of course is the root of all this drama. People confuse rootless remote applications with network transparency and they jump in anger when they hear Wayland isn't network transparent.
No, this is Slashdot, you can't have a serious discussion. It's full of idiots who don't like shiny new things, idiots who adore shiny new things and both types of idiots love to shout at each other.
Ok. Seriously. Wayland is a new architecture for the Linux graphics stack. It merges the role of the display server and the window manager/compositor into one piece, called the Wayland compositor. It is envisioned that writing a Wayland compositor is not more complicated than writing a X window manager/compositor. Buttet point: We will not have A Wayland compositor, but serveral of them to choose from: Weston, Enlightenment, Mutter/Gnome Shell, KWin. This is made possible because a) Linux now has a proper graphic driver stack and b) the Wayland protocol is much simpler.
The new model and the simplified protocol will allow A) better control of the input (keyboard, mice). Currently, the X window manager/compositor do not have absolute control about the input. Besides posing some security risks, it makes it hard to implement some behaviors sanely. Things as simple as being able to mute the sound when you have a full screen application running are hard to do. Wayland compositors, of course, get all the input and then they forward them to applications as they see fit.
B) better performance (except OpenGL full screen applications which already mostly bypass X). This will come from a number of place. - Reduced number of rountrips (W app/W compositor/kernel instead of X app/X server/X compositor/X compositor/kernel). - Better implementation (the X.org server isn't the fastest cookie in the world, but the protocol is so complex it's hard to do better) - On embedded platforms (phones, tablets, Raspberri Pi) the compositor can be written to exploit hardware compositing capabilites (there's no good way to expose it though the X server).
Additionally, the Wayland protocol fixes several issues, some of which could be fixed with more extensions, some need breaking. - Artifacts/tearing. X doesn't specify when the data sent by applications is drawn on the screen, so sometimes you get artifacts as the server or compositor draw the contents of a window in the middle of an application drawing. Wayland fixes this by making every frame perfect. - Saner input model. The currently used X input extensions are too complicated (by the authors own admission), as they need to maintain backward compatibility with the X Core input model. - Saner dynamic reconfiguration (resolution, orientation). Again, by authors admission, XRandR is too complicated. - Binding versioning. Currently, if you have an application built upon components who support different versions of an extension (ie, input), it's a russian roulette on how it will pan out.
Bullet point: despite all the drama going on on Slashdot and other sites, the simple truth is that the majority, if not all, of the developers who actually put in time and effort to maintain and upgrade the X.org server, the X window managers we use, the application toolkits, etc seem convinced Wayland is the way forward and are putting in the time and effort needed to make it happen.
Wayland is not network transparent. And despite the drama, that's OK. Nobody cares about network transparency. People (including me) do care about having rootless remote applications. We care to have something that works at least as well as "ssh -X". For the short/medium term, Wayland desktops will run a X compatibility server (XWayland) and most Wayland capable applications will have a X fallback mode. So "ssh -X" will just keep working. For a longer term solution, when we get Wayland only applications, we'll need to implement something like NX or Xpra for Wayland. Which is OK too, because for many of us, it's better than running X over the network. Despite the capabilities of the X protocol, most X applications are in fact too bandwidth intensive and latency sensitive to run remotely outside LANs. And their developers can't be arsed to do it otherwise. That's why we use things like NX and Xpra in the first place.
I can't even remember what trying to use X under Windows was like. $DEITY bless memory loss.
For Mac OS X, you have XQuartz. It consists of a modified X.org server and a custom window manager and from what my Mac OS X wielding colleagues say, it works pretty well. I don't think it suffers of any of the issues you mention.
XWayland is a modified version of the X.org server, which instead of rendering though the kernel/hardware, renders as a Wayland client. It makes no sense to try and maintain XWayland as a separate fork of the X.org server.
Correct, between two flushes any number of writes may have been executed or not.
Software deals with this by using proper data structures and write / flush sequences. The most common is write ahead logging, also known as journaling, which is used by pretty much every modern file system and database.
In this approach, any changes to the data structure are first written to the WAL. Only after they've been safely committed to the WAL, the software will issue the writes to the main data structure. Performance wise there are slight variations but the basic sequence is: 1. Write the log segment describing changes, which may need any number of HDD blocks to be written. 2. Flush cache. 3. Write the commit block. This is a write to a single HDD block, and it usually contains a checksum of the rest of the log segment. 4. Flush the cache. 5. Write changes to the main data structure.
In case of power loss or another crash, upon restart, the software will re-apply the changes described in the WAL. A log segment which as a missing or invalid commit block is ignored.
Writes to a block are (expected to be) atomic. The HDDs have enough momentum and energy storage to, in case of power loss, finish writing that last block (HDD blocks are 4 kB plus a bit more) and park the heads (failure to park the heads would thrash your HDD in case of power loss, by the way). Additionally, blocks have error detection/correction code. A partially written block will yield a read error.
Depends on the kind of documentation you're asking for. The behavior is described in the HDD interface standards (ATA/SATA, SCSI/SAS). The interesting bits are the description of the desired behavior of - write through caches - write back caches and FLUSH CACHE EXT or SYNCHRHONIZE - write back caches and FUA or DPO
If you want documentation on how many drives support and honor this behavior, then I can't give you much pointers.
I don't think there's a SATA HDD in the market which doesn't support and tries to honor FLUSH CACHE EXT. Many support FUA/DPO. Bugs are known, but seem rare: http://forums.seagate.com/t5/Desktop-HDD-Desktop-SSHD/ST3250823AS-7200-8-ignores-FLUSH-CACHE-in-AHCI-mode/td-p/82046.
The PostgreSQL folks keep a page with some information about this issue. http://wiki.postgresql.org/wiki/Reliable_Writes They recommend a test for drives.
HDDs, even the cheapest ones nowadays, allow the software to enforce the order in which pending data is written to safe permanent storage and software to known that pending data has indeed been safely committed to permanent storage.
The operative systems, file systems and applications build upon this to ensure that, in case of an unexpected crash, you don't end up with a corrupted file system or data. You may lose files created in the last 5 minutes, but you won't end up with a file system so corrupted that you need to re-install your computer. Databases uses this to ensure that, once you've clicked "pay" in a e-commerce site, it will either record it properly or not at all, so you don't end up with half-way situations where you get charged and don't get the product you paid for or vice-versa.
According to reports like TFA and the article TFA was attempting to reproduce, a lot of cheap SSDs break this guarantees.
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).
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.
Slashdot Mirror
No, you are misleading.
If you take a look at Wayland source code, you'll see stuff like Copyright © 1988-2004 Keith Packard and Bart Massey. quite often.
https://gitorious.org/wayland/wayland/source/0b29a2fec7801d2530bd004ae68eb9242417bafd:wayland/wayland-hash.c#L2-3
As for pushing back work to the toolkit developers, the Qt developers made the software (client side) backend the default back in Qt 4.4, because it was so much faster than the XRender based one for local clients.
And for Qt5, they simply didn't bother to implement a XRender based one.
Yes I could. Or that we're just a dream of some creature.
But that doesn't mean science is pointless.
The point in science is to have repeatable experimental results and produce reliable knowledge to advance our understanding and life.
If a christian-like God exists, then he his apparently content in letting us use the scientific process to find how the Universe he built works.
He clearly doesn't screw around with the laws of physics on a daily basis. Scientists worth the title who also happen to believe in a God are as skeptical of physics defying events as any one.
But again, we have no scientific proof that he exists or not. The christian concept of God, of a sentient all power being, makes it impossible to have such proof.
I'm an atheist.
However, your argument is wrong.
If there's a God, like the christian one, he is conscious and all powerful. He can do whatever he wants, including making the Universe work as if he did not exist. He can subvert any experiment you can can come up to test his existence.
The end conclusion is that it is scientifically impossible to prove that God exists or doesn't exist.
Stating that God probably does not exist is not science.
Don't take this the wrong way, but I think people who, like you, try to use this kind of pseudo scientific argument to state that God does not exist are just giving science a bad name.
It has been implemented for Windows server, AFAIK.
But saying rootless RDP is network transparent is a hell of an abuse of the term "network transparent".
Which of course is the root of all this drama. People confuse rootless remote applications with network transparency and they jump in anger when they hear Wayland isn't network transparent.
No, this is Slashdot, you can't have a serious discussion.
It's full of idiots who don't like shiny new things, idiots who adore shiny new things and both types of idiots love to shout at each other.
Ok. Seriously.
Wayland is a new architecture for the Linux graphics stack.
It merges the role of the display server and the window manager/compositor into one piece, called the Wayland compositor.
It is envisioned that writing a Wayland compositor is not more complicated than writing a X window manager/compositor.
Buttet point: We will not have A Wayland compositor, but serveral of them to choose from: Weston, Enlightenment, Mutter/Gnome Shell, KWin.
This is made possible because a) Linux now has a proper graphic driver stack and b) the Wayland protocol is much simpler.
The new model and the simplified protocol will allow
A) better control of the input (keyboard, mice). Currently, the X window manager/compositor do not have absolute control about the input. Besides posing some security risks, it makes it hard to implement some behaviors sanely. Things as simple as being able to mute the sound when you have a full screen application running are hard to do.
Wayland compositors, of course, get all the input and then they forward them to applications as they see fit.
B) better performance (except OpenGL full screen applications which already mostly bypass X). This will come from a number of place.
- Reduced number of rountrips (W app/W compositor/kernel instead of X app/X server/X compositor/X compositor/kernel).
- Better implementation (the X.org server isn't the fastest cookie in the world, but the protocol is so complex it's hard to do better)
- On embedded platforms (phones, tablets, Raspberri Pi) the compositor can be written to exploit hardware compositing capabilites (there's no good way to expose it though the X server).
Additionally, the Wayland protocol fixes several issues, some of which could be fixed with more extensions, some need breaking.
- Artifacts/tearing. X doesn't specify when the data sent by applications is drawn on the screen, so sometimes you get artifacts as the server or compositor draw the contents of a window in the middle of an application drawing. Wayland fixes this by making every frame perfect.
- Saner input model. The currently used X input extensions are too complicated (by the authors own admission), as they need to maintain backward compatibility with the X Core input model.
- Saner dynamic reconfiguration (resolution, orientation). Again, by authors admission, XRandR is too complicated.
- Binding versioning. Currently, if you have an application built upon components who support different versions of an extension (ie, input), it's a russian roulette on how it will pan out.
Bullet point: despite all the drama going on on Slashdot and other sites, the simple truth is that the majority, if not all, of the developers who actually put in time and effort to maintain and upgrade the X.org server, the X window managers we use, the application toolkits, etc seem convinced Wayland is the way forward and are putting in the time and effort needed to make it happen.
Wayland is not network transparent. And despite the drama, that's OK. Nobody cares about network transparency.
People (including me) do care about having rootless remote applications. We care to have something that works at least as well as "ssh -X".
For the short/medium term, Wayland desktops will run a X compatibility server (XWayland) and most Wayland capable applications will have a X fallback mode. So "ssh -X" will just keep working.
For a longer term solution, when we get Wayland only applications, we'll need to implement something like NX or Xpra for Wayland. Which is OK too, because for many of us, it's better than running X over the network.
Despite the capabilities of the X protocol, most X applications are in fact too bandwidth intensive and latency sensitive to run remotely outside LANs. And their developers can't be arsed to do it otherwise. That's why we use things like NX and Xpra in the first place.
I can't even remember what trying to use X under Windows was like. $DEITY bless memory loss.
For Mac OS X, you have XQuartz. It consists of a modified X.org server and a custom window manager and from what my Mac OS X wielding colleagues say, it works pretty well. I don't think it suffers of any of the issues you mention.
XWayland is expected to work seamlessly as well.
XWayland is a modified version of the X.org server, which instead of rendering though the kernel/hardware, renders as a Wayland client.
It makes no sense to try and maintain XWayland as a separate fork of the X.org server.
Correct, between two flushes any number of writes may have been executed or not.
Software deals with this by using proper data structures and write / flush sequences.
The most common is write ahead logging, also known as journaling, which is used by pretty much every modern file system and database.
In this approach, any changes to the data structure are first written to the WAL. Only after they've been safely committed to the WAL, the software will issue the writes to the main data structure.
Performance wise there are slight variations but the basic sequence is:
1. Write the log segment describing changes, which may need any number of HDD blocks to be written.
2. Flush cache.
3. Write the commit block. This is a write to a single HDD block, and it usually contains a checksum of the rest of the log segment.
4. Flush the cache.
5. Write changes to the main data structure.
In case of power loss or another crash, upon restart, the software will re-apply the changes described in the WAL.
A log segment which as a missing or invalid commit block is ignored.
Writes to a block are (expected to be) atomic. The HDDs have enough momentum and energy storage to, in case of power loss, finish writing that last block (HDD blocks are 4 kB plus a bit more) and park the heads (failure to park the heads would thrash your HDD in case of power loss, by the way).
Additionally, blocks have error detection/correction code. A partially written block will yield a read error.
Depends on the kind of documentation you're asking for.
The behavior is described in the HDD interface standards (ATA/SATA, SCSI/SAS).
The interesting bits are the description of the desired behavior of
- write through caches
- write back caches and FLUSH CACHE EXT or SYNCHRHONIZE
- write back caches and FUA or DPO
If you want documentation on how many drives support and honor this behavior, then I can't give you much pointers.
I don't think there's a SATA HDD in the market which doesn't support and tries to honor FLUSH CACHE EXT. Many support FUA/DPO.
Bugs are known, but seem rare: http://forums.seagate.com/t5/Desktop-HDD-Desktop-SSHD/ST3250823AS-7200-8-ignores-FLUSH-CACHE-in-AHCI-mode/td-p/82046.
The PostgreSQL folks keep a page with some information about this issue.
http://wiki.postgresql.org/wiki/Reliable_Writes
They recommend a test for drives.
HDDs, even the cheapest ones nowadays, allow the software to enforce the order in which pending data is written to safe permanent storage and software to known that pending data has indeed been safely committed to permanent storage.
The operative systems, file systems and applications build upon this to ensure that, in case of an unexpected crash, you don't end up with a corrupted file system or data. You may lose files created in the last 5 minutes, but you won't end up with a file system so corrupted that you need to re-install your computer.
Databases uses this to ensure that, once you've clicked "pay" in a e-commerce site, it will either record it properly or not at all, so you don't end up with half-way situations where you get charged and don't get the product you paid for or vice-versa.
According to reports like TFA and the article TFA was attempting to reproduce, a lot of cheap SSDs break this guarantees.
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/