Intel, Red Hat Working On Enabling Wayland Support In GNOME 168
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."
Re:More petty bickering (Score:4, Interesting)
Re:The real agenda? (Score:5, Interesting)
Re:Why? (Score:2, Interesting)
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.
Re:More petty bickering (Score:5, Interesting)
It's more like Canonical looking at the progress and direction of Wayland and saying, "we don't feel this product is going to be sufficient for our near term mobile goals and would rather roll our own to ensure product delivery"
Whether or not they were correct in this thinking is possibly open for debate. There's certainly been some things they've said publicly that were debunked, but that doesn't mean the core of their premise is wrong. They are moving to a mobile strategy that AFAIK just isn't a prime directive of Wayland, but I'm not well versed in all that is Wayland so maybe someone that is can clear that up.
The petty bickering is Wayland devs and fans getting butt hurt about some things Canonical has said publicly some of which has been proven wrong as I said above. Since then, it's been a cacophony of rants from the Wayland devs/fans with general Canonical/Ubuntu haters thrown in bashing on Canonical/Ubuntu/Mir/Unity at every opportunity.
I've just started tuning it out waiting to see how it all turns out. If there's room for more than one IDE, I don't see why there can't be room for more than one compositor. May the best product win where "win" is defined as the most market share.
Re:The real agenda? (Score:5, Interesting)
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.
Re:The real agenda? (Score:4, Interesting)
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.
Check out MicroXwin (Score:1, Interesting)
Re:Why? (Score:4, Interesting)
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.