Wayland and its never-ending stream of stories seems to be going the way pulseaudio did. It's heavily criticized, cuts down some features or is somehow buggy, but seems to give many users what they want, or at least that's what all these crazy stories point to.

As long as I can still run X atop Wayland, I don't really care. I loved pulseaudio when it was being bashed already. Maybe I'll love Wayland too? Has anyone here actually seriously tried this thing before bashing it?

It's highly likely that Wayland's remote display will beat X. Virtually none of the features (remote drawing) that X provided over the network are used today (line/polygon drawing) and tool kits like Qt/GTK+ have you shipping framebuffers across the network, something built around manipulating frame buffers should be able to stream them over the network, individually, to a compositor on your system.

And Wayland remote display is going to happen when, exactly? Is it on the roadmap? I'm asking seriously -- if there is a roadmap, point me to it, I don't follow Wayland devopment outside of the occasional rant-fests on Slashdot like we are having now.

There are certain environments where remote display is the *only* display, so if Wayland doesn't have it, Wayland doesn't go into those environments.

not any time soon.Problem is not with Wayland.Problem is with NVIDIA binary drivers. They simply have no support of it and are rather in very initial stage of Wayland compatibility development. AMD open source drivers also suck at the moment when it comes to many aspects. So there is long road ahead.

RDP protocol support was merged [slashdot.org] into Wayland over a year ago. Wayland's original developer prototyped [youtube.com] a remote display implementation almost two years go, before 1.0 was released. This is in addition to XWayland [freedesktop.org] already providing an X server to host legacy X apps.

Wayland will have good remote display. The peanut gallery rant-fests around here not withstanding.

While I think Wayland remote display will end up working just fine, "get a refund" is exactly the wrong attitude, and one that is doing a great deal to hold back open source. Don't like your Firefox buttons switching places every two weeks? Get a refund. Unity's window management for retards driving you up a wall? Get a refund. Newest GNOME version missing half the features you depend on? Get a refund. Guess what? Nobody is going to ask for a refund. They are

No one is asking for feature refunds. They are simply bitching about users who demand every piece of software be 100% feature complete the moment it's first alpha team is announced and then continue to spew crap about it long through the development process.

Yes Firefox has abandoned geeks in favour of more simple users, well guess what there are many other packages out there that de-crappify the interface. Funnily enough that is EXACTLY the stance Wayland developers have taken from the very start. Design a flexible light weight modern protocol that does away with X's cruft and offloads stuff to the client. The users demand remote. Well if it matters that much to that many then the compositor can be written to support that. That is the flexibility that is missing from X.

The attitude was fine early on, but seeing every other bloody post on slashdot spewing the same crap, even after the Wayland team have announced remote desktop is possible, and even after the Wayland team have demonstrated code that does that, what do you think the answer is going to be?

Reread. I didn't say Wayland was in Alpha. I said the network transparency bitchfest by the uninformed started back at the alpha releases and even now when remote application display was shown to be working in Weston the bitchfest by the uninformed continues.

People somehow believe that every new effort needs to be 100% feature complete and ready to go from day dot. Guess what, there's a reason compatibility layers are written when new software is released. Magically making everything out of nothing is not h

It started back in Alpha because it had to.
It's still not ready to go, at version 1.5.
I still need remote display functionality.
It's still not ready to go, at version 1.5.
It doesn't have to be feature complete in alpha.
It's still not ready to go, at version 1.5.
Cool RDP patches, bro. How do I use them?
Have they made it as easy as ssh -X?
Don't argue the merits of half-baked software that is incapable of providing equivalent functionality to the pre-existing solutions as if that's acceptable, that's

Except that there's no reason you would expect your computer to send you to the moon. I'm not about to ride my bike across the sea. It's not an argument against Wayland, it's an argument against pushing for things that Aren't Ready and pretending like they're suitable replacements for what they're intended to replace.
If the product is not up for the task, it's not up for the task. There are a lot of potentially good reasons for Wayland but every single one of them falls short until it matures to the point

I've built a few open source projects and been heavily criticized for my design choices but you know what? I agree with this. A lot of developers are too stubborn to make changes and it drives people away then they wonder why no one is using their project anymore.

But the flipside is true too. A lot of the time 'flaws' are actually sober and sane design choices which you have to get into the internals of the system to understand. People often don't get this and then bitch and moan about why something hasn't been done the way they like.

The Wayland devs seem pretty sober and sane so far, and I think they've made a lot of nice design choices. The problem of displaying graphics on a PC is an inherently ugly problem (and X is an ugly piece of software which visibly reflects that). If they can make it just a little bit better, it will be worth the wait, in my opinion.

It's an ugly problem, but it's one that isn't half as ugly as they want to make it.
In fact, I would go so far as to say they're actively trying to make it uglier.
At the end of the day, we're just drawing colored rectangles on the screen.
Is it too much to ask that they not fuck that up?

It's ugly because there are a lot of different ways of rendering those graphics to your screen, and they are highly variable depending on your graphics hardware and what exactly you intend to do. If you're just drawing a bunch of browser windows you can get by with communicating with your graphics hardware on a per-pixel basis. But if you want to get into games and so on you have to provide an interface for your software to communicate with the hardware's OpenGL implementation. And you have to support a sys

2 years later: "Yeah, Wayland has RDP support... But it's kind of broken and buggy. It requires these patches to be applied, manual creation of this 1000-line configuration file, and the sessions have always to be started from command line. Also, you have to use this certain distro. We are waiting it to be fixed, but the component has insufficient manpower and resources for the task to ever be actually completed anyway. Just use VNC, sigh..."

It's a reference implementation, a proof of concept to demonstrate to people complaining that yes wayland can in fact be remoted assuming a compositor provides with the support. It's not wayland's job to do the remoting, it's the compositor's. I see no reason to think that once wayland is switched on by default in a dist or two that compositors will explicitly support remoting, or there will be dedicated compositors for that purpose.

Wayland is just the API and protocol for clients and servers to allocate & release buffers and pass input and display events around. It doesn't say how those buffers get shown to the user - that's the compositor's job. Weston provides a a reference implementation of remoting demonstrating it is possible. It doesn't mean it's perfect, or comes with a pile of advanced options.

I expect it will improve and there will also be dedicated compositors for headless servers and the like.

I expect it will improve and there will also be dedicated compositors for headless servers and the like.

So... you';d have one compositor (on the headless machine) which does nothing but send the bitmap over the network and a client program on the display server machine which collects that and opens windows in whatever compositor you're running?

What I mean by this is I don't understand at all why it would be in Weston: it sounds like one want a couple of utility programs instead to do that job, not a whole c

On Windows I can login into a PC, walk over to another machine and remote login to that same session. For that you probably want the window manager to host the remote session. But if you have headless machine that is only used in a specific way then perhaps something simpler will do. I don't see that either is precluded.

Apparently something good enough to be a bullet point on that was done last year but the fanboys don't know any details other than an announcement they point to. Maybe a Wayland developer will comment on one of these Wayland stories some day apart from the fanboys and we'll get some real information instead of links to a video of a half finished powerpoint presentation with no Wayland screenshots.

Robots don't have displays. It's really difficult to get your work done if your monitor keeps skittering away across the lab. Visualization tools for various pieces of robot state are much better than text dumps -- not surprisingly. Display across the WiFi network is a requirement. Also, all the generic basic tools need to run in a headless environment.

But robots aren't the only embedded environment where Linux is popular. Again, with those it is nice to be able to display to a large monitor for development work, even though the device might have a small display of it's own.

Second, X11 is not going away immediately, and no one expects it to. Qt and GTK+ will remain compatible with X11 for some time to come precisely because of this. And you'll still be able to access those remote X applications via XWayland.

Robots don't have displays. It's really difficult to get your work done if your monitor keeps skittering away across the lab. Visualization tools for various pieces of robot state are much better than text dumps -- not surprisingly.

For this use case wouldn't it be a lot more appropriate to stream raw data from the robot to software running on a desktop machine to represent it visually? Surely it's a waste of CPU effort drawing a GUI on the robot itself?

Because the webpage data will likely have a higher footprint. Once you pack on the full distribution of a web application that does everything you need it to onto the embedded device, does it have any space left? There are certainly ways to save space with web applications, but for the most part we're talking distributing and executing raw source code which is often orders of magnitude larger than compiled binaries. This matters in the embedded space.

Actually, you were moderated down for your overly vitriolic rant full of factual errors, logical fallacies and heroic assumptions in the guise of fact. A perfect example of the "peanut gallery rant-fest" as a comment above yours mentions. And seriously, you got moderated down, then threw a strop, and then posted it again with a hissy fit preamble? How long have you been posting here?

The cases where people have argued such a thing are the strawman you've taken up on as streaming bitmaps, which is not always (in fact very rarely outside of gnome3) the case. So there's equivalent performance (streaming bitmaps the same speed in both) or better when you have a situation where one can do something other than just stream bitmaps. Of course every time this gets mentioned we get the "only dinosaurs want remote access/shaped windows/whatever feature of X does not apply on phones - then the di

Multi-second lag on X sounds like misuse of the protocol. Unfortunately, this is largely the fault of Xlib. The X11 protocol was carefully designed to be asynchronous, but then they wrapped the whole thin in a synchronous C API. This means that you end up sending a small amount of data to the server then blocking while you wait for the reply. Used correctly, you'd send all of the display updates sequentially, get the updates as the arrive, and later handle any errors that appear. Similarly, input events would be handled as they arrived, rather than synchronising everything. Unfortunately, although XCB fixes this, most toolkits are designed around the synchronous model so they don't really take advantage of it.

I've seen this, (a while ago it's true). I was curious about why some GTK applications had such terrible remote performance. When I ran the applications through xscope, before the first window materialized, I saw thousands of calls to XGetGeometry(). What made that doubly silly is that any window geometry change is provided to the client as an XConfigureEvent. So, a local copy of window geometry information can be easily kept up to date.

That's nice but what you describe is for GTK3, and not GTK2. Seems like the latter is still used a lot, and frankly GTK3 has gone rogue, deleting features, adding ones only Gnome developers will use etc.Developers of applications run away from it and migrations from GTK2 to GTK3 seldom made (though there are dual mode GTK2/GTK3 applications where you can select the UI).

Recently with GTK 3.10 they removed icons in menus and the highlighting of letters to help you with keyboard navigation (e.g. Alt-F opens File menu). It's the Slashdot Beta of the toolkit world.

Remote display on Wayland will be much better and more modular than X11. X11 mandates a chatty, slow, obsolete protocol for remote display and applications MUST be network-aware. With Wayland, you can run a compositor on the remote server that doesn't display its clients on the screen but rather transmits streaming video of the clients back to a Wayland client on your desktop which decodes and displays these streams. And neither your local Wayland compositor nor the remote clients need be network aware.

Except that X11 over the network with any modern toolkit is already effectively forcing X11 to do what Wayland will do - only X11 does it badly and without compression

Well, you could run it over SSH with compression enabled.

Though, run something like firefox over remote X, and that's a real dog. You could pretty much download and install firefox locally before the remote X version of firefox would even give a hint that it's starting.

(I had to remote firefox because we were diagnosing an issue where some mac

If I can stream a game from my desktop to a tablet and play it with virtually no latency, on Windows it should be possible for something implementing Wayland to stream individual application frame buffers across a network effortlessly - hell, it could do it with applications that are live on a remote screen and keep them alive if the remote server disconnects, something that always annoyed me.

To me that sounds like complete and utter bullshit unless gvim is now seriously broken. In my workplace complex interactive geophysical packages with a lot of graphical information are used remotely over X by dozens of people at once to (in some cases) substandard MS Windows implementations of X without running like a dog - even over wireless to laptops, so how is your gvim over GigE example even possible unless somethign else is going on

I've had to remote Firefox too, chiefly to access papers that are behind paywalls my university has access to but I have no access to at a university I'm visiting, or at home. You're making Firefox over X sound a lot better than it actually is.

Wayland is the protocol that clients talk with the compositor, not the compositor itself. The reference compositor Weston already implements an RDP server and does so in a remarkably small amount of source code.

As for it's performance, it will be no worse than X (or Xvnc) on modern apps because as everyone has stated, most modern apps are pushing pixmaps around anyway. If anything performance has the potential to be better because the remoting protocol can be asynchronous (unlike X) and the server doesn't have a handful of X and extensions processes with all their context switches to worry about.

Wayland is critically important, which is why (unlike Pulseaudio) it hasn't already been rolled out yet. Qt has integrated it, Gnome has, KDE is porting KWin to implement it. There have been fairly few technical criticisms, the only one I've seen made with any muster has been network transparency - but even that could be solved rather easily given the way Wayland works with framebuffers.

On the flip side, Xorg has you dragging around unused cruft and the way it interfaces with the kernel forces some possible security holes be left open, holes that Wayland will fix.

Clipboard? It's a framebuffer with a compositor on top. Clipboards are a client problem (as are many other things).Now do you get why the "X sux" stuff from Wayland fanboys is annoying? Wayland is designed to be something different to X with different goals. Those of us that "want to run software from 1996" are made fun of in Wayland presentations, which would be fine if they were not also telling us to stop using X.

Because it's a windowing system and it turns out that just a compositor alone isn't enough (who knew, eh?). It's also interesting. Apparently Wayland implements passing of data by just passing a file descriptor, apparently instead of reimplementing 10 pages of ICCCM grot. The thing about the 10 pages of ICCCM grot is it's really REALLY well specified and a random person from the internet can come along, read the ICCCM, grok it (yes, I have actually implemented copy/paste and XDnD from the specs) and get it working. It's not that hard.

The wayland one seems poorly specified by comparison. For example they don't specify teeny-tiny details liekl whether the FD must be seekable, for example. So, do you have to write a local file, or can you pass a socket? Who knows! It's really easy to have a short, simple spec when it's full of ambiguity and people haven't had 26 years to beat it into a definitive, unambiguous state. Anyway, I digress.

Now do you get why the "X sux" stuff from Wayland fanboys is annoying?

Yes, but it's more annoying when it comes from the Wayland author FUDmonsters who understand X11 and yet still make silly claims about it. For example, from the link above, Packard claims:

X was created before there was MIME or Unicode, so there are many pages expended in the X specifications to do things that are more easily handled with MIME types and UTF-8 these days. For cut-and-paste and drag-and-drop, Wayland uses MIME-labeled UTF-8 encoded objects.

Well, that sounds all like OMG X sucks we need MIME and UTF-8. Well the thing is, in order to list types from a copy/paste transfer, applications exchange a string (i.e. atom) with the type name(s) available. And guess what? Almost everything these days except for plain text is exchanged using MIME types. If the MIME-type specifies UTF-8, then the data will be in UTF-8 format. So basically, X names types with a string, just like MIME, and MIME works *perfectly* without modifying or respecifying anything.

You can verify this easily: download and install a copy/paste debugger/sniffer and look at the list of types available that programs offer.

The ICCCM also specifies a few (non-MIME) types that you might like to support, such as TEXT, which maps perfectly on to text/plain and is all of 1/2 a line to implement (if(typeAtom == TEXT || typeAtom == textPlainAtom)...). And X11 sends arbitrary data (including NULs) because it represents data as data+length not a string, so you can exchange anything, such as UTF8.

Anyway, KP implies that that doesn't work with X11 copy and paste, whereas in truth it works perfectly and without any faff or hacking.

Wayland is designed to be something different to X with different goals.

Not so much. It's designed to replace X wholesale. It does windowing, compositing, input, copy/paste/DnD, and a bit opf inter client communication.

Those of us that "want to run software from 1996" are made fun of in Wayland presentations,

Yeah us with our legacy programs. From stroustrup:

"Legacy code" often differs from its suggested alternative by actually working and scaling.

Meanwhile, I shall keep using legacy programs productively. XTerm works amazingly well, still. gvim works great---though I find I sometimes have to compile it with GTK disabled and with XAW (seriously WTF??) support because GTK can't seem to get its shit in order with fonts and everytime ubuntu updates itself/reboots, the font size changes. Xfig is old but works really well within its domain for producing simple, effective figures.

You seem to be all for the X11 side of things. Yes it's well specified and there are many benefits.

Do you care to put as much detail into the downsides? Such as that it's so well specified that things like the volume keys on the keyboard can't be passed onto a music player because the laptop lid is closed and the lockscreen is fullscreen and the way X works means that any fullscreen program completely monopolises the input system? Yes I'm all for specification, but if network systems were specified the same

You seem to be all for the X11 side of things. Yes it's well specified and there are many benefits.

Yes, but I restricted myself to only talking about the anti-X FUD.

Such as that it's so well specified that things like the volume keys on the keyboard can't be passed onto a music player because the laptop lid is closed and the lockscreen is fullscreen and the way X works means that any fullscreen program completely monopolises the input system?

Actually, they are variable length for TCP, and you must pad the TCP header to a 32bit boundary if you decide to add extra fields.

Options (Variable 0–320 bits, divisible by 32): The length of this [header] field is determined by the data offset field.

IPv4 also has a variable header

The second field (4 bits) is the Internet Header Length (IHL), which is the number of 32-bit words in the header. Since an IPv4 header may contain a variable number of options, this field specifies the size of the header

IPv6 actually has a fixed header, but it can have a reference to data to extend the header, but that "extended" information is not part of the actual header.

s/TCP Headers/MTU Size. The point I make is the same yet you seem to grasp only the equivalent of spelling mistakes to make your counter argument.

Over specification is a problem for something as fluid as display technology. I'm not talking on the GUI level but on a system interaction level. Just have a read about the Xinput multitouch extension and the problems in creating it. In the past three years we've gone from mouse to multi-touch inputs as an emerging computer trend. Yet due to over specification X11

The most common use case today is local applications. This must be optimised for. Have a separate server and protocol to network transparency for the classes of applications that network transparency is useful for (simple GUIs, text editors and suchlike, rather than nonlinear video editors and 3D games). Likewise with audio, there is a need for a simple high performance backend for some applications, and network friendliness for others. In both cases there should be two layers, a fast light low level ba

Slashdot is not "news for the Linux world," and even if it was, not everyone in "Linux world" is so deeply involved as to keep up to date on every developing piece of software.

All a summary writer has to do is drop in a brief, casual couple of words about what (roughly) it is, and those who need informing are slightly better informed, while those who are already informed don't notice and aren't offended.

Ever notice how the BBC will often refer to "US President Barack Obama," or drop in a reference to the team a famous footballer player plays for, even though one would think those would both be widely known facts among the readership of such articles? Chances are, you didn't notice and didn't care.

Well windows has Remote Desktop (RDP), but I think that supports your point. I use xrdp for remote gui connects to my linux boxes as it performs a hell of a lot better than X, which is unusable on anything except a local LAN.

Yeah, I mean, X forwarding is one of those things that you very rarely need, and when you do, it either doesn't work at all because [inexplicable reasons that can't be fixed without admin on a machine you don't own or having to restart a machine that's 200 miles away], or it sort of works but makes you wish it didn't because it's too slow/glitchy. Typically ssh does the trick, sometimes combined with forwarding gnome-open to view images/pdfs/whatever (which is terrible due to the aforementioned reasons), be

Nomachine (NX) removed a lot of the pain that I had with X over VPN. I used it several years ago on a project and the performance was such that I barely noticed that I wasn't on the host's LAN. I liked it better than VNC at the time because I was still allowed to open a single X window without having to put up with an entire remote desktop.

You might be interested in this podcast [javascriptjabber.com] if I'm reading your post right... they talk quite a bit about using js-git [github.com] to mount GitHub repositories as file systems, so that you can mount a repository, copy files into it and then run a commit and have the stuff you've copied automagically pushed to GitHub.

It seems the real remote drawing / display technology these days is HTML/CSS, carried via HTTP. It even supports running client-provided code locally on the display server, as did NeWS and DPS 20 years ago, to render animations and depressed beveled buttons without incurring a server roundtrip (and Javascript is generally much nicer than PostScript -- you can even run the whole program on the display server if you want). And the protocol is a bit backwards in that the display server (aka "web browser"), rat

I personally make a distinction between "using" and "administering" a machine, and as a user, I tend to run X11 (these days often with a tiling window manager). When I want to perform some administrative tasks, I'll often just run a terminal emulator within that environment. Face it, while great for many things, the command line--especially in its raw, no-X11 form, is pretty limited in many areas from the point of view of a typical user.

Don't get me wrong though; I'll often use wget instead of Firefox to download files, do basic file system operations in a terminal, even play an occasional podcast in mplayer. But really, it is not optimal to use the CLI 100% for everyday use for semi-normal people.

It's not that bad once you get used to it. What you now see as random characters falling on the screen will soon become something you'd recognize like that hot blonde in the smoking red dress walking down the crowded sidewalk.

And how often do you need to watch youtube on a remote desktop when administering a remote computer?

That brings me back to the second sentence in my post.

"I personally make a distinction between "using" and "administering" a machine,..."

Did you even read the post at all? Obviously, you are talking about administering a system. But I can guarantee that I am not administering a system while I sit here wasting time posting crap on Slashdot, and I have this funny feeling you're not either.

I personally do on occasion. I sometimes run R on an EC2 instance to be able to use a beefy box and use it remotely from a device of my choice. I don't think that's a particularly odd use case for the types of people that use X today. If Weyland/Weston are not targeting those people, then so be it. If they are, then the remote display use-cases are going to suffer.

No, what IS news is self-righteous experts wanting a feature they don't use while not knowing an equivalent feature has already been merged into the compositor. I mean fuck it's not like there was a Slashdot notice about remote desktop support being added to Weston last year sometime. Oh wait....

I can't understand why network transparency is something SO important, especially when a lot of ugly hacks are necessary to make it work and compromising the performance of much more important parts like the presentation of local desktop.

It's not. People heard the fancy term "transparency" and went oooooooh I'll use that without realising that network transparency does not mean the ability to display an app on a remote desktop. The same people also think that the very specific term "network transparency" which has a very specific meaning still applies. It doesn't. Most Linux desktops have lacked network transparency since the mid 90s in favour of nasty fallback hacks and rendering in different ways depending on the target server.

Most Linux desktops have lacked network transparency since the mid 90s in favour of nasty fallback hacks and rendering in different ways depending on the target server.

Nope. I've used Linux desktops since the 90s with X clients running on numerous platforms. Many of which were developed not even knowing what Linux was. So the need for server specific 'hacks' could never have been satisfied. And Linux works just fine, thanks.

For you. Didn't you hear? Last year was the year of Linux on desktop, and it doesn't work very well. If open source is to compete with proprietary then you need to actually provide functionality that users want. You know really complicated edge case crap like plugging in a projector and expecting it to work out of the box.

Oh, they've got a good reason. Marketing wants to reduce the expectations of the users. 20 years ago, I could run video over networked X and run a remote CATIA session on my Linux desktop. So why can't you run your precious Auotocad or Adobe suite apps over X? Per seat licenses.

20 years ago, when Microsoft was a joke in the engineering world, things worked fine. And then they (and other vendors, no fair picking on only MS) tried to convince management that every seat needed an office productivity suite. S

Well it's not. As said network transparent has a specific meaning. You use it every day? So do I. But I'm under no delusions that the application is entirely transparent to the system its rendered on. Mind you it still just works, and it's quite right for you to expect it to just work in the future under Wayland.

But if it "just works" why would you care about the details of how the protocol works?

As for no good reason. You really should try some other form of remote application. There is a very good reason

Because this is Slashdot, and people always need something to complain.
Wayland will be clean, fast, and, more important, maintenainble. But, OMG, if it don't offer remote desktop in its bones, it'll be crap.

Let me see... At least for me, the big problem with the network transparency is that to get it working, the X server needs to follow a number of architectural decisions that are highly detrimental to the performance of a local desktop and you can not work around this without a lot of (broken or unstable) hacks. That said, how many users use the transparency and how many users needs an efficient local desktop? Why I should hurt the performance of the entire server to meet a situation that is used for only 2%

What's funny is we've been slowly getting into a situation where all PC are fast so we can afford the waste of using X even more.On the other hand we're now down to three graphics vendors and the drivers are improving.. but at lot of time using the GPU for the GUI will result in less stability, potential overheating or lock up, and instead of Xorg using your CPU it will be a graphics driver and its OpenGL implementation.All so that a fraction of the userbase can look at windows flying around and zooming in/