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."
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.
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.
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.
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.
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".'
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