Slashdot Mirror
KDE Plans To Support Wayland In 2012
An anonymous reader writes "During the 2011 Desktop Summit plans were brought up by a KDE developer to support KDE on the Wayland Display Server, which is dubbed the successor to X11. The KDE Wayland support is expected to come in three phases, with the first two phases expected to be completed next year during the KDE SC 4.8 and 4.9 development cycles. Farewell X?"
This is a mistake! X is one of the most flexible and useful systems today. Granted dumb users won't ever realize what they have in front of them, but the utility of X should not be under-estimated. I DO use it on a regular basis. Eliminating X, or even making it a second class citizen, is a huge loss in the philosophy that has allowed UNIX to survive for decades.
What will happen is that X will be "supported" as an X emulation layer on top of the latest display layer. Unfortunately, apps will abandon X because it will no longer be vigorously supported. Then it will be lost.
Here's what X can do today that we will lose: Run applications on one virtual or physical machine and display on another. This is not the same as VNC or terminal services.
I hear all the dumbed down Linux users saying, that this isn't important, but like the people making these decisions, it is the point of view of ignorance. Computers are going in two directions..... Smaller devices and huge systems with many virtual machines. The huge systems with many virtual machines SCREAMS X for application display management. a 1:1 virtual desktop per virtual machine us unmanageable, but a window per app is. Eventually, there will only be a para-virtual manager and para-virtualized machines, each running apps. The VMs can be saved, restored, snap-shotted, backed-up, branched, etc. This will be the nature of how we run apps when we have a huge number of CPUs. X is a better fit now for the future, than any Windows/Mac inspired "improvement."
This is another Ill that is a direct result of people coming to Linux from a Mac or Windows background. They want to bring lesser ideas because they don't understand the capabilities of what they already have.
Typical slashdot: the article distorts the truth in order to get reactions.
It was pretty clear during that presentation that the goal was to make it possible to still run X applications -- using a rootless X server -- and that this would also allow X-over-the-network use cases.
X11 is not going away, the idea is to use Wayland -and- X.
The main problem with X11 is the complete lack of frame boundaries. Applications just send a stream of drawing commands with no indication of where one frame stops and the next one begins. Consequently the server has to keep drawing stuff as it comes in, resulting in flicker. Flicker is the first thing a novice X11 programmer complains about and online forums have been filled with pleas for help with this problem for decades. The traditional solution was to render to an offscreen image and send it to the server. This requires a lot of bandwidth, so the next step is to use MIT-SHM extension to avoid this traffic. Then came XComposite extension which automatically handles double buffering. XComposite has the luxury of being able to sync to vretrace, but not knowing where the frame boundaries are it can't do it lest it cut the instruction stream in the wrong place and draw half-a-screen. In the meantime, after two decades of deliberation, the XSync extension still does not implement the ability to detect vretrace.
Wayland solves the above by moving rendering into the client, as in the render-to-image solution above, and then copying the image to the server. This can be done though shared memory as well. The rendered image on the client represents the complete frame.
X is far from perfect (and I say this as someone who's written a compositing WM). There is a huge amount of the X11 protocol that no one actually uses anymore. Font rendering, for example, has to be done on the client or you get different sets of fonts for remote X11 (yuck!). For fast text rendering, you use the XRENDER extension, and store glyphs in the server then composite them. That takes care of text, but what about line drawings? X has basic drawing primitives, but most apps use something like Cairo to give a PostScript / PDF style drawing API, and Cairo doesn't use any of the X drawing primitives. It just draws everything into a pixmap and then sends it to the X server. This means that most of what people are actually using X for is getting a window that they can composite pixmaps into. And X sucks at that. The input model is also pretty horrible (take a look at how click-to-focus is implemented some time, it will make your brain hurt).
The problem with Wayland is that it doesn't seem much better. It's thinner, which is nice, but that's about it. It's also Linux-only (while X.org runs on all *NIX systems, plus Windows), and it is released under a less permissive license than X.org.
I am TheRaven on Soylent News
Nobody's forcing updates on you, old timer.
Sure. Except that you do want to get security fixes. And you probably also want to run a few new applications.
The Tao of math: The numbers you can count are not the real numbers.
The bug where KDE still is inferior to GNOME? :P
Oh, that one. I think that the Gnome 3 team is working on that bug!
It is dangerous to be right when the government is wrong.
Last time I checked, nobody was forcing you to switch from X to Wayland or Gnome 2 to 3.
And nobody forced me to switch from GNOME 1.4 to GNOME 2, right? Or from browsers that support HTML 1 to HTML 5? Or from FTP+{IPSec|SSL} to SFTP?Wherever the most users are, that's where developers will go. Developer time is a finite resource, and any time developers go somewhere, they have to leave something behind.
I'm not saying that we shouldn't move to new systems, but there are very stable and usable features in old systems which don't exist in new systems, and there's always some cost..
Some apps written for GNOME 1.4 were never ported to GNOME 2, because their developers abandoned them. (I can't think of examples off-hand, I just recall encountering the problem at the time of transition) HTML 1 was a very simple, straightforward means of conveying information for rendering and presenting to humans. It just wasn't fancy enough, so it was replaced. Did you know that FTP allows you to instruct one FTP server to transfer a file to another? That's pretty epic when the two servers have a connection 10-100 times as fast as your connection to either--and tools like IPSec, SSL or a secured layer 2 made that reasonably safe.
Yes, each of these older systems had their own faults, and newer versions sought to cope with those faults, but new versions often fail to retain the flexibility and existing utility of old versions. I shudder to think how many hours of coder's times are spent shoehorning existing things into new systems or on top of new paradigms. Worse, everybody thinks they've invented something new, when all they've done is (often inadvertently) re-invented something a decade or six old in a new context.
It feels like make-work for a stagnant field. Pay someone to tear down the old road and build a new road, except the new road isn't even expected to last as long. We're not accelerating innovation as fast as we tend to think, we're stuck in a mud puddle and spinning our wheels.
tasks(723) drafts(105) languages(484) examples(29106)
X is mature code and it works. It makes sense to replace it only if you replace it with something *better*, which is different from *shinier*. Dropping pretty basic features like network transparency because it doesn't make sense on tablets, or for n00bs, or etc is bad engineering, bad philosophy, and bad karma.
You should not condition the capabilities of a system on the capabilities of its least experienced users.