Slashdot Mirror
Intel, Red Hat Working On Enabling Wayland Support In GNOME
sfcrazy writes "After shooting down Canonical's Mir, Intel and Red Hat teams have increased collaboration on the development of Wayland. Developers at Intel and Red Hat are working together to 'merge and stabilize the patches to enable Wayland support in GNOME,' as Christian Schaller writes on his blog. The teams are also looking into improving the stack further. Weston won't be used anymore, so GNOME Shell will become the Wayland compositor. It must be noted that Canonical earlier committed to supporting and embracing Wayland. Despite that promise, the company silently stopped contribution, and it was later learned that they were secretly working on their own display server, Mir. Intel's management recently rejected patches for Mir, leaving its maintainance to Canonical. Before Intel's rejection, GNOME and KDE also refused to adopt Mir. Intel's message is clear to Canonical: if you promise to contribute, then do so."
It's exactly what the Linux desktop needed! Thanks, everyone!
There's no -1 for "I don't get it."
KDE's support is also in the works but further down the line. I think later 2014 or early 2015? Can't find the schedule at the moment. Enlightenment 18 has partial wayland support with full support expected in 19.
FINALLY we're going to be free of X. Of course, I still suspect it will take some time to iron out the wrinkles to the point where the experiences on wayland for the various DE's are relatively bug free and are as smooth as butter.
The code base is old and hard to work with from what I've heard from the X hackers. It has reached a point where it might make sense to start over.
Additionally, X11 does a lot of things that have been taken over by toolkits. GTK and Qt don't even use X11's drawing and font facilities anymore, they handle it themselves and then dump a buffer for Xorg to display.
He means a total NIH mentality. Ubuntu won't use systemd because they wrote Upstart, which is functionally inferior to systemd. Ubuntu ships with Unity, which they wrote, and is functionally inferior to Gnome-Shell. Ubuntu decided Wayland is not here right now and for some reason they absolutely must move off X11 now, so rather than supplying code to Wayland they've decided to write Mir from scratch. Ubuntu uses Canonical-developed Bzr, not Git, with their own Launchpad management system developed in-house.
Support my political activism on Patreon.
There are certain things you cannot do with a pure X solution, much related to seamless transitions at login.
They argue that the seemed advantages of X, don't get used in the real world. In practice, rather then truly using network transparency, most of the time they just send bitmaps across the wire to update the screen. Because of this, by starting from scratch without this unused functionality they can make a faster, less resource-intensive, and prettier UI. For over-the-network usage they can just use a protocol to sent the updates, after they are rendered on the side with the application (clients and servers with X always feel backwards to me), which is what gets done in practice with X anyway.
Basically, if you aren't a developer, you wont care. It just gets more pretty. If you are, it gets easier to make things look better.
Canonical bashing might be all the rage at the moment, but I can see how they are feeling a bit hard done by with all these accusations that they should have used subsequent products instead of the ones they wrote first.
Care to supply actual evidence of these claims? Because anyone can make wild claims, what gets attention is evidence, which your post is lacking.
This video seems to provide a good explanation of the motivation for Wayland.
Shuttleworth is threatening Linux users' elite club by finally showing signs of actually making Linux work on the desktop and popularizing it. That's what pisses people.
Debugging and maintaining old code that no one is using is annoying and pointless. Particularly when you know you can do better, but are hamstrung by the X11 requirements.
no, no I dont.
Read what I said again.
In the real world, the network transparency support features are not used, EVEN WHEN YOU ARE USING A REMOTE DISPLAY because it's easier and more effective to actually render on the remote machine and bang the interface, so that's exactly what every widget toolkit does.
Why not? If no one uses it anymore, it's dead code that simply increases complexity. And once you start removing those dead bits, you can't call it X11 anymore. So you fix it to better fit the most common use cases and the easiest way to do that now is by rewriting it. Particularly when that code was written against a 30 year old standard that has been receiving workarounds to account for new hardware for years.
Actually it's telling, mostly about Canonical's outward attitude. They created all of these solutions, but none of them were widely adopted. Few people use Launchpad, bzr, Upstart, etc. Perhaps it's related to Canonical's seeming desire to develop internally and release when they see fit, rather than develop in the open and take community input?
And Wayland is out there. It was already being tested on devices when Mir was announced. Of course, no one knew Mir was coming because Canonical likes to work behind closed doors, the larger Linux world be damned.
Upstart was written before systemd started; Fedora and RHEL used Upstart for a while. Newer, better has come along.
Unity was a quick response to Gnome Shell, which was available as a functional pre-release in 2009 3 months before Unity. Gnome Shell was up-and-coming and Canonical headed it off. The big move to Unity was highly politicized as "Oh no! Gnome is changing! People hate that! They will be angry at the new Gnome interface! ... Unity!!!!" It was integrated into the distribution as the primary desktop environment one release prior to integration of Gnome Shell, when Gnome Shell was already released and stable.
Mir came about well into the Wayland development cycle, citing "Wayland is coming too slowly. And we don't like it."
Bzr is the third generation of a number of unrelated pieces of software. The original Bzr, now renamed Bazaar, was a slow bloated piece of shit that didn't work right at all. The current Bzr started pretty bad, and has been improved; it was easily surpassed by Git at one point, but had caught up. There was also Mercurial and darcs, but that's not really of much import. The reason Bzr isn't more popular isn't that it's not great; it's that Git was better way before Bzr was usable.
Launchpad took forever to become open source, but that's not really a huge issue. It's sensible, but it is on their laundry list of stuff they've written that's not the same as everything that was already out there. To be fair, all other stuff out there sucks; I'd like to have Launchpad with Git integration (it'll import a Git repo by converting it to Bzr, rather than actually integrating with Git), or something like Gitlab but in Python instead of Ruby (running Ruby apps is really fucking hard; it's like the old days of wild wild Java west when nothing worked unless you were a Dark Invoker, and even then only one app per server... look up RVM and such to get an idea).
Support my political activism on Patreon.
Easier programming wise, maybe, but not easier on the network, or on admins'/users' sanity when using a remote connection. Transferring bitmaps around is bandwidth intensive and annoyingly slow, even on high speed connections.
Maybe they're not used, but they should be.
I have a vastly different criticism from what I typically hear about Canonical and Ubuntu. Circa Ubuntu 12.04, I started noticing severely degrading quality in the underlying platform scripts, default configurations, and over platform management in Ubuntu. Command line sysadmin conventions typically left alone by the sprawling masses of "gotta change for change's sake" developers suddenly came under fire. What was once a very stable system under the hood was suddenly forgotten and uncared for, so I left. I didn't care about Unity because I've been using Fluxbox for nearly 8-9 years prior, but I did care that it was suddenly ridiculously difficult to bring up a stable NFSv4 w/ krb5 auth, that they were by default using linux software raid partition versions that weren't compatible with CentOS, and that iptables wasn't integrated into the baseline OS in a very sane way. I found out that the default build configuration of ntp didn't support autokey. I found out that the default build configuration for OpenSSL and other crypto related packages had no support for FIPS 140-2.
In other words, with the release of 12.04, ubuntu told me that they suddenly didn't care about enterprise users any more, so I moved on to what I have found to be a superior option for my needs. I understand that I could have rolled my own packages from scratch, but I didn't feel that was an efficient use of my time since switching to Fedora or RHEL/CentOS/SL gave me what I needed by default. I had already cast away the bottomless time sink that was managing gentoo machines, and I wasn't interested in dealing with another only a year later with Ubuntu.
The API is strictly procedural and out of date, a new API can add the benefit of design pattern architecture (no, that doesn't mean it needs to be C++, this is an architectural point, not a language one). X is also full of serious security problems.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
There's the thing. X was written when there were no other toolkits, at least not of note (Motif?) so X does everything. As newer toolkits were added (GTK, etc) it made sense for them to do certain things, and many of those have become redundant in X. X is many layers of old code, a refresh is in order. Sometimes you have to stop saying "why fix it if it ain't broken" and just fix it. You don't really want to drive a model A while everyone else is driving a Tesla, do you? Besides, rather than create a successor to Ruby on Rails, which is a solution in search of a problem, IMO, why not create a successor to X, which is actually useful?
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
If all toolkits have to implement something then X is the proper place to put it.
No, if all toolkits have to implement something then a shared library is the proper place to put it. For the most part, that's what's been happening. For example, both Qt and GTK+ need to render fonts, so they rely on FreeType.
The problem with putting drawing primitives and font rendering in the X server is that applications generally want to compose these operations together in ways the standard APIs don't support, which would imply either lots of round-trips and wasted effort or moving the application's drawing code into the X server (like DPS). When both the X server and the application are local, it's obviously both easier and more efficient to hand all of the rendering over to the application. The interesting part is that even if the application is remote, it can be more efficient to communicate a compressed form of the result over the network rather than all the drawing commands and raw data required to assemble the same image locally.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
"Care to supply actual evidence of these claims?..."
Oh, please. If I had actual physical evidence, I'd be in some NSA sub-basement right now.
you seem to be supplying plenty of evidence to suggest you are a paranoid schizophrenic. no, seriously, i think you need professional help.
Anons need not reply. Questions end with a question mark.
second-time-is-no-longer-clever.png
Il n'y a pas de Planet B.
Easier programming wise, maybe, but not easier on the network, or on admins'/users' sanity when using a remote connection. Transferring bitmaps around is bandwidth intensive and annoyingly slow, even on high speed connections.
Maybe they're not used, but they should be.
If you want your programs' icons to be rendered with new-in-1988 stippled lines rather than Cairo and your text rendered with blew-my-mind-in-1992 bitmapped fonts rather than OpenType, then yes toolkits could use the original X11 drawing conventions. However not many people actually want that.In any case, if you are happy with every toolkit implementing everything twice, why not be happy with one of those implementations being Wayland and the other being traditional-style X11?
There's also the problem that X11 is far too 'chatty' a protocol. While network bandwidth available to a typical user has increased exponentially in the last twenty years, the latency has not reduced by nearly as much. This leaves a serious problem with all the excess round-trips that can't be fixed without making completely incompatible changes to the protocol.
but I can see how they are feeling a bit hard done by with all these accusations that they should have used subsequent products instead of the ones they wrote first.
The question one must ask at this point is why has Canonical's work on all these products not been widely accepted? They do all this work, create lots of stuff, and the rest of the world routes around it.
Are we all participants in some global anti-Canonical conspiracy? Are Linus and Kristian Høgsberg and Redhat and Gnome and github.com and the Mint guys and everyone else meeting every second Tuesday to plot the demise of Canonical?
Obviously not. What I believe we have here is an insular and unapproachable organization that independent contributors and peer organizations simply will not tolerate. Until that changes we're going to continue to see more Canonical work rejected.
By failing to engage its peers, Canonical is squandering its early success at nailing together a tolerable desktop rendition of Linux. I for one hope that changes, but Canonical has demonstrated a truly amazing level of stubbornness and indifference.
Maw! Fire up the karma burner!
In the real world, the network transparency support features are not used, EVEN WHEN YOU ARE USING A REMOTE DISPLAY because it's easier and more effective to actually render on the remote machine and bang the interface, so that's exactly what every widget toolkit does.
I have three headless Linux machines and the only display I have is on my laptop. My remote X11 clients run on these machines and present their UIs on my local X11 display server running on my laptop. While it is probably true that these clients are not transmitting XDrawLine and XFillArc protocol elements to render their UIs, they are still mostly assembling pre-rendered bitmaps, widgets, and font glyph assets to send down the wire for rendering on the local server. How is this going to work on Wayland?
I keep reading that this will be supported through some backward-compatible protocol, but has anybody actually worked out the details of how existing X11 clients will migrate to this new protocol? My fear is that these clients will stop working with future versions of Linux and their replacements will not support network transparency.
Wayland has a real use case for mobile devices, but why make the same mistake as Microsoft by gratuitously trying to unify mobile with desktop? On a desktop, the only advantage to Wayland is that it facilitates implementing a pretty compositing desktop. This is a fad that is already starting to fade from fashion.
My remote X11 clients run on these machines and present their UIs on my local X11 display server running on my laptop. While it is probably true that these clients are not transmitting XDrawLine and XFillArc protocol elements to render their UIs, they are still mostly assembling pre-rendered bitmaps, widgets, and font glyph assets to send down the wire for rendering on the local server. How is this going to work on Wayland?
Actually, what the clients are doing right now is assembling bitmaps, widgets, and font glyph assets into a pixmap on the client side, most likely without the benefits of GPU acceleration, and sending the result as an uncompressed pixmap over the wire to the X server, which hands it off to a compositor, which combines the pixmap with images from other applications and hands the result back to the X server. If they're luck enough not to need any special transformations or compositing effects, the clients may be able to leave the rendering of the individual font glyphs to the server, but that's about it.
With Wayland the clients are doing the same work to assemble the surfaces for their windows, but they get to use the local GPU to do it, and the result is compressed by a local off-screen Wayland proxy server using modern video codecs before being transmitted over the network for compositing.
On a desktop, the only advantage to Wayland is that it facilitates implementing a pretty compositing desktop. This is a fad that is already starting to fade from fashion.
Distracting toys like "wobbly windows" may be fading from fashion, but composited desktops are here to stay.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat