Of course in practice it might be very difficult to change your employer, but it's still easier than changing your government.
Is it? It seems like this is another case where theory and practice are quite different. How often does the government change compared with your employer?
Are you claiming the government changes with every election?
I'd say that while the individual members of the government may change with each election, it's still the same government that I've lived under all my life.
Pff. This is why "unnotable" material is deleted from wikipedia, because the material isn't notable to the majority.
So some articles, that people spent hours, if not days or months writing is deleted because one person thinks it's unnotable and gathers the meat puppets to kill the article. They succeed most of the time because the material in question isn't interesting to the nerds that run Wikipedia. But oh yes, we must have an article on every goddamn pokemon thing.
The pokemon articles and the star wars articles and the Simpsons articles and nearly every damn article ever written with the word "fictional" in the first paragraph is part of the problem - just the part that's harder to deal with. If you want to take that stuff on, feel free. I will applaud the effort.
Anyone who needed ZDNet to tell them this clearly hasn't been on Slashdot very long.
That's the first thing I thought as well.
Then I thought "Why is this story tagged 'craigslist' and not 'slashdot'?"
Because the author of the article listed something on Craigslist and it got flagged and removed. The article is his petty revenge against the system that has inconvenienced him.
I don't think info ever had a valid niche to begin with... maybe as an add-on to man pages, but never as a replacement for them. "use info $APP for the man page" is a sad indictment to that poor design judgment.
Oh, agreed. I hate those stub man pages. Especially when (due to some documentation package not being installed, no doubt) calling up the suggested info page just leads me straight back to the same stub man page, except in the info viewer instead of the man page viewer.
But my point about info was that it's actually more of a full-featured help system, and much better suited to presenting large amounts of information than man is, because it can organize and cross-reference it better. In the face of HTML it seems largely superfluous, so it loses out 'cause it's neither as convenient as man nor as fully-featured as HTML. But info first appeared... what, early 1980s? Late 70s? A help file browser with hypertext functionality was a pretty substantial merit at that point.
Actually, I signed it "co-founder". And I have a video of me acknowledging Richard Stallman, at the U.N. no less, so don't fault me on that.
I didn't actually fault you on anything... I was just clarifying a point in the summary which, honestly, gave me the same initial (if momentary) reaction as that of the AC.
Bruce Perens, founder of the open-source software movement?
Are you kidding me??
Yeah, you know, "Open Source", the movement started in the late 90s, defined in terms that make it a superset of all the various licenses that allow access to and adaptation of the source code? Bruce Perens was one of the founders of the Open Source Initiative and the primary author of the OSI's definition of Open Source Software. That Open Source movement.
Much as "Open Source" isn't the same thing as software libre or "Free Software" in the FSF sense, so too are the founders of the "Open Source" software movement not necessarily the same as those of the software libre movement or similar movements, or the authors of the software in question.
The publisher supposedly has the book in stock, as well as other stores such as ecampus.com, but it ranges from slightly more expensive to 33% more expensive ($100 vs $63 is a big difference to me).
Damn. I thought the whole "information wants to be free" ethic would apply here.
As usual: that phrase does not mean what you think it means.
And $100 is over 50% more expensive (not 33% more expensive) than $63.
That's RMS for you. I'm surprised GNU-based systems don't say "Use emacs to edit $FILE" when you try to use vi....
Well, there's actually a functional reason for info's existence. It's a hypertext system, it's got hyperlinks and table of contents and hierarchical organization for documents... This makes it much more useful for relatively large documentation than a man page would be.
But I never liked actually using the info reader, I never took the time to learn all its key bindings. These days I think HTML documentation is a much better choice... Man pages still do well in their own little niche - brief summary-style documentation with a consistent, convenient interface... But I don't think info has a valid niche any more.
Well, SYNC has been a pretty standard component of X.org for a long time, so I wasn't sure whether you didn't know about it or whether you wanted something else.
Didn't know about it - and from searching online I saw no mention of it being used to sync to vblank... Though I suppose if that's one of the things the extension is for then that must be one of the events you can sync to.
Sorry , but no other book comes close to Advanced Programming in the Unix Enviroment.
You know, I was thinking more or less the same thing when I read this story. How can a review like this not make the obvious comparison with the glorious APUE? I love that book. I have to admit, I didn't even know you could pass file descriptors from one process to another before I read it... And its descriptions of job control, TTYs, process hierarchies and so on have been very valuable to me.
It seems like this book covers a lot of the same ground, though presumably without the same level of cross-platform coverage. Though I don't think APUE covered xattrs (can't remember offhand)... I had hoped that this book, being more Linux-specific, would cover more of the stuff that's more current and fairly specific to current Linux distros: FUSE, dbus, the current state and direction of kernel drivers for graphics and sound, any Linux-specific process jail or virtual machine mechanisms, and so on...
Still, I'd really like to browse through this book. If there's enough useful information that doesn't overlap APUE it might be worth getting. Maybe my local bookstore will get a copy sometime...
What do you know about the vblank syncing issue that the Wayland FAQ cites? Is there really no way to sync display changes to vblank on X? Or is something like that offered in, say, the compositing extension, or GL?
There's the SYNC extension (pretty standard). What else do you need?
Well, admittedly there are bits of the whole situation I don't understand fully enough. But I am trying to make sense of this situation with Wayland... And in the process, learn a thing or three.
I know there's kind of a knee-jerk reaction to assume X11 should be done away with simply because it's old. (Or more precisely, that it has a long history...) I try not to make this mistake myself - but with the things people are trying to accomplish on Linux desktops these days (i.e. slick effects, and with no particular demand for network transparency as far as most users are concerned) I can see why people might feel X isn't necessarily the right choice. If the code you're writing is fundamentally not well-suited to working over the network (for instance, animated transitions) - then X has little to offer over a simplified local-display system.
I also think the way they're expecting Wayland to be used in Ubuntu - as a layer under X or other remote display technologies - could make a lot of sense. It seems more sensible to start with a layer that emphasizes performance and implement network transparency on top of that rather than the other way around.
What do you know about the vblank syncing issue that the Wayland FAQ cites? Is there really no way to sync display changes to vblank on X? Or is something like that offered in, say, the compositing extension, or GL?
come back to earth. You guys have been making some absolutely STUPID decisions as to the direction you are trying to go. I will be moving away from ubuntu because it is getting worse and worse. Wake up, you can't even call your crap linux anymore
PulseAudio does come to mind, doesn't it?
Still, they certainly can call it "Linux" as long as Linux is the kernel they use. Although I do like a lot about what has defined "The Linux Platform" so far, I prefer to think that the definition of the "platform" is subject to interpretation and change.
The X server is an efficient, widely used, and standard graphics platform. And the X server is where all the drivers are being developed. Finally, the X server actually gets things like multi-monitor support, resolution switching, etc. right.
Why go now with something totally new and largely unproven? What problem is this solving?
The basic "problem" that's existed in X forever is that it's network-transparent first and local-optimized second, via extensions.
Whether this is a "problem" is largely a matter of perspective. Obviously many people, myself included, consider it an asset.
However, a lot of Linux usage is moving away from this scenario. Or perhaps it's better to say, this scenario is no longer considered the primary use case. Even software implemented on top of X is often written without remote operation in mind: the result is software that could be run remotely via X, but which in practice is too network-intensive to be useful in this mode. And, of course, there are some programs that simply don't make sense to run via remote display.
The problem this solves is X, basically. Most of what X has to offer has become extraneous for many users. They don't use remote display, very little of the software they use in practice is really implemented in a way that makes it viable over a remote display anyway, and they want to run a lot of software that really does need a short path to the display hardware in order to run properly. So the idea is to "cut out the middleman", trim a couple decades of legacy cruft.
We've heard this story before, of course. It's not the first time people have tried to unseat X as the dominant display system on the Linux desktop. Still, despite my attachment to X, I'm not convinced that getting rid of it would be a bad thing. It seems to me that most software written to run on it today isn't really written to work well on remote display.
X has a LOT of power, but remains poorly understood.
Now we are going to get applications targeted to a single user GUI, and with that all the problems the other OSes have with their single user GUI.:(
I would argue that we're already getting this: applications targeted to a single user local-display GUI, that just happen to be implemented on top of a protocol capable of remote display.
When someone tried to implement effects like animated sliding menus or whatever on top of X, what you get is a program that can technically operate network-transparent - but doesn't necessarily perform well.
And X has an enormous advantage : it works NOW, not when pigs will fly.
Some of this I heartily agree with - and some of it feels like the kind of attitude that gets people locked into bad design decisions with decades of backward-compatibility issues.
It's hard for me to contemplate Linux without X. The network transparency is something I will miss if we get rid of it. At the same time, though, I feel like it's become a fairly minor piece of how I use the system. A lot of the apps I run just aren't worth running over a network. I doubt I'd ever run Firefox or Blender remotely, for instance. If I did, my usual "remote" display server (my cheap-ass netbook) has a lot less graphical rendering power than my application server (my desktop PC) - so X doesn't bring a lot to the table. GLX probably isn't going to serve me as well in that case as a network transparency layer like VNC. I believe a lot of the modern software written to run in X isn't really written (or tested) to work well over the network - if people aren't writing the software itself to work well over a network, then what use is a network-transparent display system?
Basically, yes. The X Window System is a very old architecture by computing standards. It has served us well and I am not entirely comfortable with dismissing it... but the basic difference in approach here is that "Wayland" is strictly a local-display implementation, where X is built from the ground up to be network-transparent, with local-display enhancements added via extensions. The idea behind ditching network-transparency is to optimize graphics performance, making applications running on the local machine perform and behave better (i.e. giving video players the control they need to be able to synchronize video frames with the monitor's vertical blanking).
If so, does that also make it a replacement for the KDE and GNOME or do those two things sit on top of X windows?
The latter. Both KDE and GNOME can work directly on Wayland, I believe, if compiled for that.
What is Unity and how does it relate to GNOME or the KDE?
As I understand it, Unity is a window manager/desktop environment on which other applications can run. So it's like GNOME or KDE in that regard, but the GNOME and KDE projects themselves include a bunch of applications which could be run within the Unity environment... So they're not mutually exclusive things.
Is Ubuntu moving to these technologies because they use less resources are faster and will allow Ubuntu to work better on devices other than PCs?
Well, I think "less resources and faster" is basically what they're after with Wayland. A lot of what's included in X just isn't necessary or useful for modern applications. A lot of the things people are doing with slick GUI transitions and the like really aren't compatible with X's network transparency anyway.
With Unity I guess they're just trying to build a better GUI. Among other things it's supposed to be good for use on touchscreens (meaning, for instance, items on-screen have to be big enough to tap accurately with a finger...)
The main problem with linux is how terribly quirky it is. this will not be solved by moving to a new graphical platform which will yet again not work on many machines simply because it is not getting tested enough.
...
Moving to Wayland (or even working on Unity) will not solve ANY these problems.
Improving infrastructure does address these sorts of problems. If your infrastructure is better-suited to what you're trying to accomplish, some of the complications introduced by the old infrastructure decisions will disappear and it'll be easier to accomplish your goals.
As a specific example: a goal of Wayland is to provide compositing and window management on top of a rendering layer that's close enough to the hardware that applications can easily do things like synchronize video playback to vertical refresh. Hence, one "quirk" in Linux video playback goes away.
This isn't going to solve everything, of course, but what they're going for is a step in the right direction. Since Wayland is a relatively new design (i.e. built with present-day assumptions about hardware expectations) it very well may help with the issues you mentioned - especially things like adding a display. (X handles that via the XRandR extension - which is a relatively recent development.) Similarly, for developers who are looking to add visual flair to their apps, it's probably going to be easier to implement that correctly with Wayland than X, and thus they'll have more time to address the bugs in their work.
Big changes like this can introduce a lot of pain up front, in the transitional period. It's not trivial to move away from a display technology that's been the basis of most Unix GUI work for the last 20+ years. But the reason they're doing this is because they hope it will pay off in the long run, in the form of simpler, more reliable, better-performing, and better-looking application software. If this really is the right direction to move - still it's not an easy choice, but an important one nonetheless. If one considers basing Linux GUI on X to be a mistake, then the apparent choice here is to go on building and fixing software that was based on that poor decision, or face the short-term transition pain and go for something better.
Personally I'm not sold on the change. I am fond of the way X apps work, and to some extent I fear losing its capabilities, and the underlying assumption that every GUI app is network-transparent (even if there are numerous problems with this in practice...) But, personal attachments aside, still I think this move could be a very important and valuable improvement to the way GUI is handled on Linux.
Exactly. VNC is usable over low latency links, X is not.
You're confusing me here. A low latency link is exactly what you want for a networked display. By "low latency links" do you actually mean "high latency links"?
Slashdot Mirror
Of course in practice it might be very difficult to change your employer, but it's still easier than changing your government.
Is it? It seems like this is another case where theory and practice are quite different. How often does the government change compared with your employer?
Are you claiming the government changes with every election?
I'd say that while the individual members of the government may change with each election, it's still the same government that I've lived under all my life.
Pff. This is why "unnotable" material is deleted from wikipedia, because the material isn't notable to the majority.
So some articles, that people spent hours, if not days or months writing is deleted because one person thinks it's unnotable and gathers the meat puppets to kill the article. They succeed most of the time because the material in question isn't interesting to the nerds that run Wikipedia. But oh yes, we must have an article on every goddamn pokemon thing.
The pokemon articles and the star wars articles and the Simpsons articles and nearly every damn article ever written with the word "fictional" in the first paragraph is part of the problem - just the part that's harder to deal with. If you want to take that stuff on, feel free. I will applaud the effort.
Confound you and your blasted Vulcan logic!
I guess so! I must have been wrong, and the crowd here loves the Lord! Honestly though, it doesn't matter to me how it's modded - I win either way.
How very convenient for you.
Anyone who needed ZDNet to tell them this clearly hasn't been on Slashdot very long.
That's the first thing I thought as well.
Then I thought "Why is this story tagged 'craigslist' and not 'slashdot'?"
Because the author of the article listed something on Craigslist and it got flagged and removed. The article is his petty revenge against the system that has inconvenienced him.
You mean you were expecting the usual crowd of horse's asses on Slashdot and suddenly there's the horse's mouth :-)
Heh. Maybe I'll be a horse one of these days. If that doesn't work out I guess I could chase my dream of becoming the king of the pirates. :)
I don't think info ever had a valid niche to begin with... maybe as an add-on to man pages, but never as a replacement for them. "use info $APP for the man page" is a sad indictment to that poor design judgment.
Oh, agreed. I hate those stub man pages. Especially when (due to some documentation package not being installed, no doubt) calling up the suggested info page just leads me straight back to the same stub man page, except in the info viewer instead of the man page viewer.
But my point about info was that it's actually more of a full-featured help system, and much better suited to presenting large amounts of information than man is, because it can organize and cross-reference it better. In the face of HTML it seems largely superfluous, so it loses out 'cause it's neither as convenient as man nor as fully-featured as HTML. But info first appeared... what, early 1980s? Late 70s? A help file browser with hypertext functionality was a pretty substantial merit at that point.
How can we have a neutral internet with Bruce Perens appearing to nose about right in the middle of all our chin-wagging?
I know, right? I mean, here I am expecting a bunch of chins and suddenly there's this nose to deal with...
Actually, I signed it "co-founder". And I have a video of me acknowledging Richard Stallman, at the U.N. no less, so don't fault me on that.
I didn't actually fault you on anything... I was just clarifying a point in the summary which, honestly, gave me the same initial (if momentary) reaction as that of the AC.
Bruce Perens, founder of the open-source software movement?
Are you kidding me??
Yeah, you know, "Open Source", the movement started in the late 90s, defined in terms that make it a superset of all the various licenses that allow access to and adaptation of the source code? Bruce Perens was one of the founders of the Open Source Initiative and the primary author of the OSI's definition of Open Source Software. That Open Source movement.
Much as "Open Source" isn't the same thing as software libre or "Free Software" in the FSF sense, so too are the founders of the "Open Source" software movement not necessarily the same as those of the software libre movement or similar movements, or the authors of the software in question.
The publisher supposedly has the book in stock, as well as other stores such as ecampus.com, but it ranges from slightly more expensive to 33% more expensive ($100 vs $63 is a big difference to me).
Damn. I thought the whole "information wants to be free" ethic would apply here.
As usual: that phrase does not mean what you think it means.
And $100 is over 50% more expensive (not 33% more expensive) than $63.
That's RMS for you. I'm surprised GNU-based systems don't say "Use emacs to edit $FILE" when you try to use vi....
Well, there's actually a functional reason for info's existence. It's a hypertext system, it's got hyperlinks and table of contents and hierarchical organization for documents... This makes it much more useful for relatively large documentation than a man page would be.
But I never liked actually using the info reader, I never took the time to learn all its key bindings. These days I think HTML documentation is a much better choice... Man pages still do well in their own little niche - brief summary-style documentation with a consistent, convenient interface... But I don't think info has a valid niche any more.
Well, SYNC has been a pretty standard component of X.org for a long time, so I wasn't sure whether you didn't know about it or whether you wanted something else.
Didn't know about it - and from searching online I saw no mention of it being used to sync to vblank... Though I suppose if that's one of the things the extension is for then that must be one of the events you can sync to.
Stevens.
Sorry , but no other book comes close to Advanced Programming in the Unix Enviroment.
You know, I was thinking more or less the same thing when I read this story. How can a review like this not make the obvious comparison with the glorious APUE? I love that book. I have to admit, I didn't even know you could pass file descriptors from one process to another before I read it... And its descriptions of job control, TTYs, process hierarchies and so on have been very valuable to me.
It seems like this book covers a lot of the same ground, though presumably without the same level of cross-platform coverage. Though I don't think APUE covered xattrs (can't remember offhand)... I had hoped that this book, being more Linux-specific, would cover more of the stuff that's more current and fairly specific to current Linux distros: FUSE, dbus, the current state and direction of kernel drivers for graphics and sound, any Linux-specific process jail or virtual machine mechanisms, and so on...
Still, I'd really like to browse through this book. If there's enough useful information that doesn't overlap APUE it might be worth getting. Maybe my local bookstore will get a copy sometime...
Man pages are written in [ng]roff format, so no, they're not just text files.
It's even worse than that. They're all just strings of zeroes and ones
I think I saw a two in there!
What do you know about the vblank syncing issue that the Wayland FAQ cites? Is there really no way to sync display changes to vblank on X? Or is something like that offered in, say, the compositing extension, or GL?
There's the SYNC extension (pretty standard). What else do you need?
I don't know. That's why I asked! :)
Well, admittedly there are bits of the whole situation I don't understand fully enough. But I am trying to make sense of this situation with Wayland... And in the process, learn a thing or three.
I know there's kind of a knee-jerk reaction to assume X11 should be done away with simply because it's old. (Or more precisely, that it has a long history...) I try not to make this mistake myself - but with the things people are trying to accomplish on Linux desktops these days (i.e. slick effects, and with no particular demand for network transparency as far as most users are concerned) I can see why people might feel X isn't necessarily the right choice. If the code you're writing is fundamentally not well-suited to working over the network (for instance, animated transitions) - then X has little to offer over a simplified local-display system.
I also think the way they're expecting Wayland to be used in Ubuntu - as a layer under X or other remote display technologies - could make a lot of sense. It seems more sensible to start with a layer that emphasizes performance and implement network transparency on top of that rather than the other way around.
What do you know about the vblank syncing issue that the Wayland FAQ cites? Is there really no way to sync display changes to vblank on X? Or is something like that offered in, say, the compositing extension, or GL?
come back to earth. You guys have been making some absolutely STUPID decisions as to the direction you are trying to go. I will be moving away from ubuntu because it is getting worse and worse. Wake up, you can't even call your crap linux anymore
PulseAudio does come to mind, doesn't it?
Still, they certainly can call it "Linux" as long as Linux is the kernel they use. Although I do like a lot about what has defined "The Linux Platform" so far, I prefer to think that the definition of the "platform" is subject to interpretation and change.
The X server is an efficient, widely used, and standard graphics platform. And the X server is where all the drivers are being developed. Finally, the X server actually gets things like multi-monitor support, resolution switching, etc. right.
Why go now with something totally new and largely unproven? What problem is this solving?
The basic "problem" that's existed in X forever is that it's network-transparent first and local-optimized second, via extensions.
Whether this is a "problem" is largely a matter of perspective. Obviously many people, myself included, consider it an asset.
However, a lot of Linux usage is moving away from this scenario. Or perhaps it's better to say, this scenario is no longer considered the primary use case. Even software implemented on top of X is often written without remote operation in mind: the result is software that could be run remotely via X, but which in practice is too network-intensive to be useful in this mode. And, of course, there are some programs that simply don't make sense to run via remote display.
The problem this solves is X, basically. Most of what X has to offer has become extraneous for many users. They don't use remote display, very little of the software they use in practice is really implemented in a way that makes it viable over a remote display anyway, and they want to run a lot of software that really does need a short path to the display hardware in order to run properly. So the idea is to "cut out the middleman", trim a couple decades of legacy cruft.
We've heard this story before, of course. It's not the first time people have tried to unseat X as the dominant display system on the Linux desktop. Still, despite my attachment to X, I'm not convinced that getting rid of it would be a bad thing. It seems to me that most software written to run on it today isn't really written to work well on remote display.
X has a LOT of power, but remains poorly understood.
Now we are going to get applications targeted to a single user GUI, and with that all the problems the other OSes have with their single user GUI. :(
I would argue that we're already getting this: applications targeted to a single user local-display GUI, that just happen to be implemented on top of a protocol capable of remote display.
When someone tried to implement effects like animated sliding menus or whatever on top of X, what you get is a program that can technically operate network-transparent - but doesn't necessarily perform well.
All this fuss reminds me of how GtkFB was supposed to storm the handheld realm circa 2001. Never happened, never will.
Truth is, for all its assumed weaknesses, X is still the more polished, thought-out graphical protocol in widespread use. It's there, it works, it boasts features (network transparency for instance) no single other GUI system can provide. There may be more eyecandy in windows©® or MacOS©® (and then, it remains to be proven, when I can run 'aero like' effects under X on Intel hardware not cutting the set minimum for windows), but when it comes to sheer possibilities, X beats everything else hands down.
And X has an enormous advantage : it works NOW, not when pigs will fly.
Some of this I heartily agree with - and some of it feels like the kind of attitude that gets people locked into bad design decisions with decades of backward-compatibility issues.
It's hard for me to contemplate Linux without X. The network transparency is something I will miss if we get rid of it. At the same time, though, I feel like it's become a fairly minor piece of how I use the system. A lot of the apps I run just aren't worth running over a network. I doubt I'd ever run Firefox or Blender remotely, for instance. If I did, my usual "remote" display server (my cheap-ass netbook) has a lot less graphical rendering power than my application server (my desktop PC) - so X doesn't bring a lot to the table. GLX probably isn't going to serve me as well in that case as a network transparency layer like VNC. I believe a lot of the modern software written to run in X isn't really written (or tested) to work well over the network - if people aren't writing the software itself to work well over a network, then what use is a network-transparent display system?
Is "Wayland" a replacement for X Windows?
Basically, yes. The X Window System is a very old architecture by computing standards. It has served us well and I am not entirely comfortable with dismissing it... but the basic difference in approach here is that "Wayland" is strictly a local-display implementation, where X is built from the ground up to be network-transparent, with local-display enhancements added via extensions. The idea behind ditching network-transparency is to optimize graphics performance, making applications running on the local machine perform and behave better (i.e. giving video players the control they need to be able to synchronize video frames with the monitor's vertical blanking).
If so, does that also make it a replacement for the KDE and GNOME or do those two things sit on top of X windows?
The latter. Both KDE and GNOME can work directly on Wayland, I believe, if compiled for that.
What is Unity and how does it relate to GNOME or the KDE?
As I understand it, Unity is a window manager/desktop environment on which other applications can run. So it's like GNOME or KDE in that regard, but the GNOME and KDE projects themselves include a bunch of applications which could be run within the Unity environment... So they're not mutually exclusive things.
Is Ubuntu moving to these technologies because they use less resources are faster and will allow Ubuntu to work better on devices other than PCs?
Well, I think "less resources and faster" is basically what they're after with Wayland. A lot of what's included in X just isn't necessary or useful for modern applications. A lot of the things people are doing with slick GUI transitions and the like really aren't compatible with X's network transparency anyway.
With Unity I guess they're just trying to build a better GUI. Among other things it's supposed to be good for use on touchscreens (meaning, for instance, items on-screen have to be big enough to tap accurately with a finger...)
The main problem with linux is how terribly quirky it is. this will not be solved by moving to a new graphical platform which will yet again not work on many machines simply because it is not getting tested enough.
Moving to Wayland (or even working on Unity) will not solve ANY these problems.
Improving infrastructure does address these sorts of problems. If your infrastructure is better-suited to what you're trying to accomplish, some of the complications introduced by the old infrastructure decisions will disappear and it'll be easier to accomplish your goals.
As a specific example: a goal of Wayland is to provide compositing and window management on top of a rendering layer that's close enough to the hardware that applications can easily do things like synchronize video playback to vertical refresh. Hence, one "quirk" in Linux video playback goes away.
This isn't going to solve everything, of course, but what they're going for is a step in the right direction. Since Wayland is a relatively new design (i.e. built with present-day assumptions about hardware expectations) it very well may help with the issues you mentioned - especially things like adding a display. (X handles that via the XRandR extension - which is a relatively recent development.) Similarly, for developers who are looking to add visual flair to their apps, it's probably going to be easier to implement that correctly with Wayland than X, and thus they'll have more time to address the bugs in their work.
Big changes like this can introduce a lot of pain up front, in the transitional period. It's not trivial to move away from a display technology that's been the basis of most Unix GUI work for the last 20+ years. But the reason they're doing this is because they hope it will pay off in the long run, in the form of simpler, more reliable, better-performing, and better-looking application software. If this really is the right direction to move - still it's not an easy choice, but an important one nonetheless. If one considers basing Linux GUI on X to be a mistake, then the apparent choice here is to go on building and fixing software that was based on that poor decision, or face the short-term transition pain and go for something better.
Personally I'm not sold on the change. I am fond of the way X apps work, and to some extent I fear losing its capabilities, and the underlying assumption that every GUI app is network-transparent (even if there are numerous problems with this in practice...) But, personal attachments aside, still I think this move could be a very important and valuable improvement to the way GUI is handled on Linux.
Exactly. VNC is usable over low latency links, X is not.
You're confusing me here. A low latency link is exactly what you want for a networked display. By "low latency links" do you actually mean "high latency links"?
Five-digit Slashdot UID megabonus included.
Damnit, damnit, damnit, damnit, damnit, damnit, damnit...