Shared publicly  - 
 
Chris writes straightforwardly about some of the thought processes that underpin our decision to write Mir, a fast, lightweight and completely tested graphics layer for next-gen Ubuntu.

Contrary to competitor FUD, from people who are not working as openly as they would have you believe, Mir is more likely to enable high-quality graphics for ALL flavours of Ubuntu, and any distro that chooses it. Graphics vendors have been happy to engage and ensure it works well on all architectures.

Delighted to give the Mir team my full support. It's classy work that will make all *buntu's sleeker, faster and more responsive. A great contribution to your open source options.
 
Reposted in such a way that it can be shared, because G+ hates me.

Standing on the shoulders of giants

We've recently gone public (yay!) with the Mir project that we've been working on for some months now.

It's been a bit rockier than I'd hoped (boo!). Particularly, we offended people with incorrect information the wiki page we wanted to direct the inevitable questions to - https://wiki.ubuntu.com/MirSpec#Why_Not_Wayland_.2BAC8_Weston.3F

I had proof-read this, and didn't notice it - I'm familiar with Wayland, so even with “X's input has poor security” and “Wayland's input protocol may duplicate some of the problems of X” juxtaposed I didn't make the connection. After all, one of the nice things of Wayland is that it solves the X security problems! It was totally reasonable to read what was written as “Wayland's input protocol will be insecure, like X's” which is totally wrong; sorry to all concerned for not picking that up, most especially to +Kristian Høgsberg and +Daniel Stone.

Now that the mea-culpa's out of the way…

Although we've got a section on the wiki page “why not Wayland/Weston” there's a bunch of speculation around about why we really created Mir, ranging from the sensible (we want to write our own display serve so that we can control it) - to the not-so-sensible (we're actually a front company of Microsoft to infiltrate and destroy Linux). I don't think the rationale on the page is inaccurate, but perhaps it's not clear.

Note: I was not involved in the original decision to create Mir rather than bend Wayland to our will. While I've had discussions with those who were, this is filtered through my own understanding, so treat this as my interpretation of the thought-processes involved. Opinions expressed do not necessarily reflect the opinions of my employer, etc.

1) We wanted to integrate the shell with a display server - there are all sorts of frustrations involved in writing a desktop shell in X. See any number of Wayland videos for details :). We therefore want Wayland, or something like it.

2) We didn't want to use Weston. Weston, the reference Wayland compositor, is a test-bed. It's for the development of the Wayland protocol, not for being an actual desktop shell. We could have forked Weston and bent it to our will, but we're on a bit of an automated-testing run at the moment, and it's generally hard to retro-fit tests onto an existing codebase. Weston has some tests, but we want super-awesome-tested code. We don't want Weston, but maybe we want Wayland?

3) At the time Mir was started, Wayland's input handling was basically non-existent. +Daniel Stone's done a lot of work on it since then, but at the time it would have looked like we needed to write an input stack. Maybe we want Wayland, but we'll need to write the input stack.

4) We need server-side buffer allocation for ARM hardware; for various reasons we want server-side buffer allocation everywhere. Weston uses client-side allocation, and the Wayland EGL platform in Mesa does likewise. Although it's possible to do server-side allocation in a Wayland protocol, it's swimming against the tide. Maybe we want Wayland, but we'll need to write an input stack and patch the Mesa EGL platform.

5) We want the minimum possible complexity; we ideally want something tailored exactly to our requirements, with no surplus code. We want different WM semantics to the existing wl_shell and wl_shell_surface, so we ideally want to throw them away and replace them with something new. Maybe we want Wayland, but we'll need to write an input stack, patch the Mesa EGL platform, and redo the WM handling in all the toolkits.

At this point, it looks like we want something like Wayland, but different in almost all the details. It's not clear that starting with Wayland will save us all that much effort, so the upsides of doing our own thing - we can do exactly and only what we want, we can build an easily-testable codebase, we can use our own infrastructure, we don't have an additional layer of upstream review - look like they'll outweigh the costs of having to duplicate effort. Therefore, Mir.

This is only possible because all the ancillary work done by Wayland developers, particularly Kristian. Mir is a Wayland-alike; we're piggybacking on a lot of good work done for Wayland. Hopefully we'll contribute back not just an awesome display server in the form of Mir and an awesome desktop environment in the form of Unity, but also low-level improvements that can be used by Wayland compositors. I'm particularly excited about our engagements with NVIDIA and AMD; although it's early days, I'm hopeful we can get a solution for “but what about proprietary drivers?” not just for Mir, but for everyone.
66
10
Carlos Araya's profile photoNicolas Thomas's profile photoPablo Estigarribia's profile photohari jayaram's profile photo
26 comments
 
The Mir Display is a mix of Wayland x and Weston, its taking the best parts and making a new display server. Qt is then the way forward. 
 
This explanation should go in the wiki and be linked to the main page introducing Mir , so people get it . I was one of those people who bashed Ubuntu for not working or talking with Wayland devs , and that text cleared things up a lot for me.
 
What about CLA?

And most defietievly:
If Mir is succesful (wish so!) and Wayland is seen as inferrior solutions (as protocol or as available implementations), will Canonical be ready to be host to community driven developemnt process? Will Canonical let Mir grow BEYOND Canonical needs?
(And why require CLA? Isn't Sun/Oracle example sufficient to drop CLA non-sense for CRITICAL code for The Linux?)

In other words if Mir is technical succes for Linux, can Canonical make it political success too for THE Linux (not just Ubu)?
 
Criticism is information that will help you grow.
Hendrie Weisinger, Ph.D

I'm curious now Mark, who are the competitors? Explain how are they not working openly? I have seen cogent and thoughtful analysis within the Ubuntu community and upstream projects about what it is they have issues with.
 
sigh... The listed issues should have been raised openly 9 months ago. I like how no justification was given for that point... instead, Mark claims Wayland isn't "working as openly" and calls Mir criticisms "FUD".. that sounds ridiculously hypocritical, but please, do elaborate. I'm especially interested in how he thinks Mir is "more likely" to enable high-quality graphics.

Moreover, Mr. Rogers "reasoning explained" points 3 & 4 are, apparently, completely addressable by Wayland's protocol and even if they weren't addressed back then, it doesn't make sense that the Mir developers didn't try and communicate these concerns, or make public your debates with the Wayland devs at the time (which i doubt even took place).

Point 5 is very unclear, you wanted to wl_shell & wl_shell_surface semantics how? I'm generally interested in what the Mir team feels wanted changed, but again, i ultimately feel this is something that should have been raised long ago.

But even if you leave in point 5, Mir's choice to secretly start development 9 months ago without attempt at communication doesn't sit well, and I think the outcry surrounding Mir is a good indication that such moves aren't appreciated by the community.

That said, if Mark's claims about working with Nvidia and AMD to bring proprietary drivers to BOTH Mir and Wayland is true, then the situation isn't all that bad. There will most likely still be compatibility issues in some cases, but it won't be near as bad as if only the (currently) lesser system was able to play tomorrows Steam Games, or run Blender at decent frame-rates, etc.
 
This clarifies a lot of things. Mark, I have to apologize for bashing Canonical when I first heard of Mir.
 
I have to agree with +Philip Witte  that all the points are adressed/adressable within Wayland, and that no reason is given for why not to do it through contribtion/leading the Wayland effort. However, what's done is done; I'd be very interested to know how, specifically you are going to contribute to Wayland?
 
Christopher Halse Rogers
-4) We need server-side buffer allocation for ARM hardware; for various reasons we want server-side buffer allocation everywhere.-
This is where you go world of fail zone.

The reason why wayland does not do server-side buffer allocation by default is 4 fold.

1 remove the huge memory leaks problems X11 suffers from due to not knowing when a buffer is no longer required.
2 if kernel is controlling allocations when application dies that application will die by out of memory and other things the memory is free imedentaly.  Also can disappear off screen imedentaly.
3 finally very clear to see what application is bleeding memory if it don't end up all stacked in the server.
4 Linux Security Modules controling application to application interactions.  Inside the display server you have hidden the creater  memory from the Linux Secuirty Modules.  So now you have todo some form of super hack like X11 to work around that. X Access Control Extension (XACE).  You don't need this super hack when you give memory management to the kernel and have applications place there allocation reqests direct to kernel.

From what Christopher has said Mir is going to bleed memory exactly like X11 does.   Be hard to secure like X11 is.  Be hard to find what application is causing the server to bleed memory like X11 is.   Worse its going to be insecure like X11.   Server side buffer allocation is basically not workable.  Server side buffer allocation is where the secuirty of X11 starts falling apart.

Christopher Halse Rogers why should we be happy to see Mir.  Drop the allocate in server idea please it just don't work.  It is never going to work we have tried for 30+ years to make it work.  Windows and OS X don't do display server memory management they also don't bleed memory in the display server.  Display Server Memory allocation is a huge error of X11.  We need that feature gone.. 

Memory management is the job of the kernel.  When its not in kernel you are asking for trouble.  So if ubuntu wants more memory control that is add feature to the kernel.

Weston is never going into production.  Mutter for Gnome and Kwin for KDE are currently lining up to be there wayland compositor.  This is the problem KDE and Gnome will not want a display server back at all.

The wayland change is secuirty work must now move to kernel.  Cgroups and other functionality that systemd has implemented solve lot of the problems that you have most likely done this stupidity for.

Basically everything else Christopher Halse Rogers said I could go fine.  Just number 4 is complete foolishness.

The intel developer of wayland spent years trying to fix up server side allocation.  Unless you are willing to commit more than 10+ years to it and still have the risk of failure don't do server side allocation.  Client side allocation is far simpler to manage and not get wrong.
 
+Thijs Heus

Thing is simple. Shell's written for Wayland WILL use API Canonical DO NOT WANT. So Canonical would NEED to REWRITE that code in  shells...

And Wayland devs wont change that API..

So Canonical would at best come up with partial implementation of Wayland..
 
And I still do  want to know if Mir is success, will Canonical be ready/willing to be host for project developed for THE Linux and not just Ubuntu.
 
Looking forward to it, brilliant work :)
 
Still no response to some very real Concerns/Qns raised here, disappointing... :-/
 
In Brazil, most people liked Mir. Why? it's open source ... and we cannot oppose open source. The competition between the two servers display is good. What survives without competition? Good luck Mark!
 
^I doubt you're in any position to "conclude" that most people there prefer Mir, that would be somewhat irrational/illogical.
 
It's not illogical. Just follow the major sites and Ubuntu forums from Brazil. And I said that MOST was receptive to Mir, not everyone. What's wrong with that? We are forced to follow the UK/US trend about it? And what is your position to complete for me and for my country? Anyway, think what you want ... I'm anxious to Mir and Wayland!
 
It's illogical because it's not a real product yet in the same way other display-server/compositors are, so it's impossible for people to "prefer" it, & if you're using Ubuntu sites as your reference, then ofc you'll get "ringing endorsements" irrespective of that.

Plus, even if it was a real product, there's no way to quantify easily that "most people in Brazil" prefer it, & it's incorrect to use Ubuntu-related sites as the basis for that quantification. It's got nothing do with me not liking Brazil, I find Brazil to be a very interesting country.

Plus generaly speaking, even linux sites at aren't ubuntu-centric tend to have a slight bias towards ubuntu (irrespective of country), so you'll often get ringing endorsements because of that. Or simply because they have little technical appreciation of everything that's been happening.
 
Most people (in Brazil) are receptive to the existence (or the "idea") of Mir. There are people who are happy to see the Gnome and KDE going faster to Wayland, and attribute this to the announcement of  Mir. It's a effect of competition. And i love it. Competition is good, that's the point...
 
I'd still have to (respectfully) disagree that you can immediately leap to that assertion, it's something that's too had to properly quantify, especially at this early stage.

Regarding your latter point about competition, well yes, that's possibly a positive consequence of all this, although it's not necessarily the BEST possible outcome that could've arisen.
 
Let us wait the future. I just want the best for free software - and I think the competition is good. You're welcome.
 
Competition of another nature/form would've been great, what we have "so far" is OKAY. We share a common value in that we want the best for free software longer-term. Cheers.
 
Well Westion is just reference compositor. Its not ready for production in the sense that its devs do not target production requirements.
And for sure Weston can not run on Ubuntu Touch nor on Ubuntu TV.

For Ubuntu Weston as its now do not make sense.

Lets not deviate into world of fantasies (or wishful thinking) here. We can disagree on the topis of choosing base for devleoplemnt for Ubuntu, but stating that Weston is READY for Ubuntu purposes is just plain false.
 
Who said anything like that....

Wayland implementations have however been used on commercial devices for quite some time, some of which are more graphically demanding than the avg. smartphone. A implementation that's not suitable for Canonical's needs != it's not ready for other devices/uses.

I see Qns in your earlier posts still haven't been answered yet, I hope they are...
 
I think its absolutely fine that Canonical is going with Mir.  Great!  Bringing some sophisticated tek to Free Software is a fantastic thing.

The only issue I had is with the lack of candor that left people working on Wayland when (if they wanted to be contributing to Canonical's efforts) they would have been doing better to work on Mir or something else.  Some people were spending lots of effort on something that in many cases they would not have had they known.  Openness, transparency, accountability to the community.  These are the areas where and +Mark Shuttleworth have been falling down.  Please focus on this aspect and please make it a priority from now on.  Please do.
 
I do not think that going forward it will be a big problem anymore. BIG ANNOUNCEMENT happened already so there is not more incentive for secrecy.
And IIRC Canonical did warned people that they are keeping some things hidden during 11.x/12.x development. Not that it made whole thing easier.
Add a comment...