Slashdot Mirror
Official Wayland Support Postponed From GNOME 3.12
An anonymous reader writes "GNOME 3.12 was going to have official Wayland support as one of its main features for the upcoming desktop release. The developers have now decided to delay the official Wayland support until at least GNOME 3.14 while the support found there will be shipped as a preview. Missing features like drag 'n' drop and clipboard support are still missing from GNOME's Wayland code, which made them decide another six months of development work is needed. Other GNOME 3.12 features are mentioned on the GNOME Wiki."
Here I was thinking they were going to shove it in there all half baked and kind of broken like most of the other things Gnome 3 has replaced. I hope this isn't because Wayland is that bad, but rather because the Gnome team has learned some lessons about removing the stuff that works and putting in stuff that is not ready for prime time yet.
I read the internet for the articles.
I thought Gnome was going to remove support for drag-n-drop and clipboard anyway. Those things are options in all other OSes, right? And they are too complicated and nobody uses them, right?
I don't care what happens with GNOME at this point. I will be using either KDE or Xfce. I have been GNOME free for long enough to know that I am not going back. I evaluated Xfce long enough to know that it is quite satisfactory, if not as perfect as GNOME2 was. Now I have been on KDE for five weeks. I have issues with the control over icon placement on desktop and taskbar, and the putrid weather applet - otherwise, absolutely no issues whatever.
I'm afraid the MATE DE is not yet good enough to live with. I evaluated it; it is very promising; I support the effort, but it's no replacement for GNOME2 yet. I'm not sure anything will ever be, but that's life. No car is anywhere near as perfect as the glorious 1978-1982 Audi 5000 either, and nothing has come along to equal the late Icom IC-R75.
Patches are welcome. =)
for i in /usr/bin /usr/sbin ; do
"${i}" --version
done
systemd 208 ... ...
+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
and once it reaches wayland the output says
wayland 1.10
not yet depending on systemd
The real reason!
Change, because... change!
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
This video (from 2013) provides good information about the push towards Wayland: http://www.youtube.com/watch?v...
__WHY__
X is a farcical, bloated mess that sucks. A lot.
Some X developers (real, credible ones) saw what Apple has accomplished with their high quality compositors and correctly factored display stack and are trying to bring that to open source systems.
> Some X developers (real, credible ones) saw what Apple has accomplished with their high quality compositors and correctly factored display stack and are trying to bring that to open source systems.
Which is what exactly? I've owned Macs and I really don't see the appeal. If anything, Enlightenment blew the whole lot out of the water back in the 90s and made the whole idea of eye candy on the desktop a stale idea.
Copy Apple? Stop swimming in the Kool-aid.
A Pirate and a Puritan look the same on a balance sheet.
The story so far in a nutshell:
The Xorg developers got tired of spending their time working around the way X was designed in 1980 (which made sense at the time) to try and make it fit 2010 workloads and hardware.
They started to think about how to do the stuff that actually needs doing in an efficient manner, while removing the roadblocks they currently have to contend with.
Turns out that when you take what Xorg actually does nowadays, streamline the fuck out of it, and take away all the needless obstacles, you end up with a pretty straightforward buffer sharing protocol. They called it Wayland and started to work on an implementation.
And then the countless people in the peanut gallery who obviously know X much better than the X developers beheld the notion and started giving... loud feedback, shall we say. Without ever stepping forward to take over the maintenance of Xorg, mind you.
TL;DR: Xorg developers make what they concluded is the soundest technical choice. People on the Internet lose their shit. Business as usual.
-- B.
This sig does in fact not have the property it claims not to have.
Wayland waylaid; now way late.
It must have been something you assimilated. . . .
Please watch this video: http://www.youtube.com/watch?v... And then shut up about how Wayland is crap. Seriously. The people that wrote X and maintain it say that X is crap and are working on Wayland... X is nonsensical and is the reason that linux UIs struggle to not suck. Wayland will bring things FORWARD not backward.
You're right! I don't actually need remote windowing, I'm glad that's cleared up.
And a perfect example of a peanut gallery comment right there. Somehow people think just because a remote window isn't defined in the underlying display protocol it won't work. That would be news to Microsoft, Citrix, VNC and pretty much everyone except for the "Coalition of Wayland Is Bad" who seem to believe that everything must be defined in the display protocol or else it won't exist.
Now the actual reality is that with Wayland the client now has the choice to implement VNC, RDP, whateverthefucktheywant, without being subjected to a 1980s era network protocol that doesn't even support such advanced technologies like data compression.
Oh and Weston has a very early alpha example implementing RDP to do remote windowing but don't let that stop your uninformed comments, and I really mean VERY uninformed given how there was even a Slashdot story about it.
Hi! Thank you for taking the time to reply.
I don't personally know the X protocol well enough to comment either way; I can only report on the opinion professed by the X developers themselves.
Here is what I understand are the answers to the points you raise. You'll probably want to check out the talks by Daniel Stone (core Xorg developer) that have been linked elsewhere in the thread, in case I missed something.
Essentially, their opinion is that the X protocol is unsuited to what computers do nowadays. From what I understand, the only task that X11 still performs in current graphic stacks is IPC for the actual rendering extensions, and sadly, IPC is something it's very poor at.
Core X11 is network-transparent by design, but rendering is done through non-core, non-network transparent extensions nowadays. This appears to be a common misunderstanding about the meaning of network-transparent; remote display of application does in fact not require network-transparency because transparency means a lot more than just "remote capable". And Wayland as a protocol is already as remote capable as Xorg because Xorg was already filling buffers remotely and feeding that into SSH connections.
So if you want network-transparency, you'll have to disable all those rendering extensions in your Xorg configuration. But, correct me if I'm wrong, I believe what you really want, is to fire up apps remotely and have them display locally, right? And this has already been implemented in the reference Wayland compositor.
Until then, you will probably not miss the loss of network-transparency because you already lost it in current Xorg servers. I think that this, there, is the number one misunderstanding about both Xorg and Wayland.
You are correct about a window system being more than just about sharing buffers. All the things you mention are being redesigned as part of Wayland with the purpose of fixing issues that the X developers claim were unsolvable with X. (Don't take my word for it, though. Check out those talks.)
So in essence, the X developers think that Wayland stacks will be better than Xorg stacks at everything that Xorg does. Including remoting.
I do actually have one reservation about that general claim, and interestingly, it's one that I haven't seen come up from the aforementioned peanut gallery. But time will tell.
But until then, the X developers think that designing a new API from scratch is more straightforward than monkeypatching the old one into doing the same things. If you sincerely think they are wrong, maybe you'll want to step forward and take over the maintenance of Xorg? I'm sure some people out there would be grateful.
I, for one, am going to trust that they know what they are doing, but you may feel otherwise about that, and that's fine. There's just a "put up or shut up" line there that people who share your opinion seem unwilling to cross, and I think that's worth pointing out.
-- B.
This sig does in fact not have the property it claims not to have.
And a perfect example of a peanut gallery comment right there. Somehow people think just because a remote window isn't defined in the underlying display protocol it won't work. That would be news to Microsoft, Citrix, VNC and pretty much everyone except for the "Coalition of Wayland Is Bad" who seem to believe that everything must be defined in the display protocol or else it won't exist.
Well, this is the stupid FUD of the wayland crew showing its ugly head again.
No one is stupid enought to claim remote windowing won't work with wayland: a pig can fly given enough thrust. It will, however suck just as hard as all the other pixel-scrapers.
I guess I should have pedantically said: you're right I don't need good remote windowing.
On that topic you have Wayland developers claiming stuff like X11 remote windowing is the "worst". This leads old X11 users to believe they are either liars or incompetent (and hence the lack of trust) because having experienced them all over many years, I know for a fact it is a long way from the worst.
Finally, the best by a conutry mile is NX which is more like X12 and is certainly not a pixel scraper.
Oh and Weston has a very early alpha example implementing RDP to do remote windowing but don't let that stop your uninformed comments, and I really mean VERY uninformed given how there was even a Slashdot story about it.
Da fuq? The remote windowing is built into the compositor/windowmanager? I really, really hope someone is making a more sensible architecture than that out there otherwise we're going to wind up with a lot of deficient compositors or a lot of duplicated code.
The nice thing about X, you see is that it all just works like magic. Any old WM from Unity to XMonad all support remoting with zero effort. If what you've said is true, then there's a nice step backwards there.
But hey it's the future and not at all legacy.
SJW n. One who posts facts.
Hi, I have to catch a flight. No time to discuss this now. But somehow you think the Wayland developers are "the X developers", who gave up on X. Some Wayland developers are also X developers would be more accurate. And there are other X developers who don't work on Wayland. And even the Wayland developers do not really claim that X is unsuitable for a modern desktops. Just check the Wayland FAQ: it spells out pretty explicitely that you could do everything Wayland does also within X. They just want to get rid of old code, which is currently needed for backwards compatibility. The whole point is Wayland is to break compatibility to get rid of this maintainance burden in the long run. This - IMHO - is stupid. But I guess it depends on how much you value backwards compatibility.
Hi,
Thank you for the additional details. You are right -- I meant to make it clear that the Wayland design was thought up by people with some serious experience of the internals and limitations of X, and not a competing team of newcomers, as appears to be assumed all too often. But yes, things aren't as simple as I made them look and there is only a partial overlap between the Wayland devs and the Xorgs devs. Thank you for the correction.
I also agree that Wayland is largely about canning the legacy in order to make current and future needs easier to tackle.
I don't agree with your opinion of the move as a technical choice, though, for three reasons.
1/ Taking X out of the rendering loop does not mean dropping X altogether. It just means that future X servers, when and where they are still needed, will run on top of Wayland. It does deprecate X as the default API, yes. But that's not remotely the same as breaking compatibility.
2/ The comments that Daniel Stone (core Xorg and Wayland dev) made in that oft linked video aren't in agreement with the idea that everything Wayland does can be done on top of X, let alone done well. In his talk, DS mentions e.g. issues with input management when one window wants to grab every input that can't be solved in X.
3/ As a more general philosophical principle, the world moves and everything changes. Everything has a shelf life, up to the universe itself, and there is a point where resisting change for the sake of keeping past things going becomes harmful. And this is the actual reason I've been so active in this thread. Not just because I've got a pretty good hunch that once the dust settles Wayland will largely work better than X. But because I think that we, Slashdotters, Linux users, geeks and nerds, are becoming fearful of change, and that's not a good thing. This, here, is an entire new toy and it opens entire new possibilities! It may break shit and it may be awesome and it will probably be a bit of both. Let's freaking check out the code and play with it! Is this not exactly what we should be about? :)
Have a safe flight, and thank you for the constructive reply!
-- B.
This sig does in fact not have the property it claims not to have.