<div dir="ltr"><div>Hi all,</div><div><br></div><div>I usually do not comment on this list but this message raises so much hope and fear at once that it gets hard to resist!</div><div style>Let me be clear: the mir announce is a surprise, kind of a big deal and raises a lot of questions. I do not mean to be overly critical here, but these questions have to be addressed if canonical want devs and tech-enthusiasts to follow them!</div>
<div style>I'm asking all this because I care about the future of ubuntu!</div><div><br></div>On Mon, Mar 4, 2013 at 6:46 PM, Oliver Ries <span dir="ltr"><<a href="mailto:oliver.ries@canonical.com" target="_blank">oliver.ries@canonical.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">After thorough research, looking at existing options and weighing in<br>
costs & benefits we have decided to roll our own Display Server, Mir<br>
(rf. <a href="http://wiki.ubuntu.com/MirSpec" target="_blank">http://wiki.ubuntu.com/MirSpec</a>).<br>
<br>
None of the existing solutions would allow us to implement our vision<br>
without taking major compromises which would come at the cost of user<br>
experience and quality. We will be running sessions at UDS to discuss<br>
questions and take feedback.<br></blockquote><div><br></div><div><br></div><div><div>For sure it is hard to judge at such early state, but the mir code repository is several months old, it seems far from complete and you have barely more than one year left to finish it and send it into the wild according to your plan, so it does seem ambitious!</div>
</div><div><br></div><div>The rationale behind Mir sounds good, a move from X to something simpler and better suited for modern expectations is highly welcome, but it remains unclear why this could not have been done in wayland (which was the designed successor for many including ubuntu until very recently).<br>
</div><div><br></div><div><div>I'm probably missing something here as the ubuntu devs are a lot more familiar than me with all this. Yet providing good reasons for your choices is important if you want devs to follow you.</div>
<div>In my dreams, here are some example of valid reasons:</div><div>* canonical want complete control of the stack and has the gut to maintain it all. It is scary, but it is bold. It will raise critics and you will have to prove that you can pull it off, but if you do it is worth it</div>
<div>* a set of use cases that are relevant and that can not be achieved using existing code. This has to be detailed and discussed with maintainers of these project if they claim that it is possible.</div><div><br></div>
</div><div style>The spec page does not talk about control but only about technical reasons, so let's focus on them. For me, the scary part is that wayland involved many experienced people for a fairly long period of time: are you sure you can do better with less resources in a much shorter amount of time?</div>
<div>For sure large chuncks of wayland time was spent defining a good protocol and you can learn a lot from it, but I see two options here:</div><div>* either you do something vastly different from wayland, and you will still need lots of time to get tons of details right</div>
<div>* or you take most of wayland ideas and tweak some parts, and it would probably have been as fast (and way more popular) to (try) integrate these changes in wayland itself (or fork it)</div><div><br></div><div style>
The mirspec page mentions a "protocol agnostic core", which wayland does not provide. Indeed, wayland is all about the protocol itself, but a different wayland server could probably provide this. The mir client lib would probably not be used by clients directly but rather by toolkit backends, so it is fairly irrelevant. If Qt already runs on top of wayland, what does Mir improve for clients?</div>
<div><br></div><div>Beyond these doubts, I have a couple of questions about interoperability with existing applications. You plan a proxy X server, but will this support DRI efficiently?<br></div>
<div>I suppose you plan a Mir backend for cairo and clutter (probably needed for GTK support), what about SDL and similar libs?</div><div>Any plan for network transparency?</div><div><br></div><div>
I imagine there are tons of such "details" to be ironed out before you can replace X, and you probably thought about many of them already, a few more wiki pages to clarify them would probably calm down some of the flamewars ;)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Also, driven by Ubuntu Touch we are starting to move Unity over to a<br>
Qt/QML based implementation, embracing Qt as a community backed<br>
technology for our offerings. We are looking at tackling the transition<br>
from the Nux based implementation to a Qt/QML based implementation<br>
component by component and are striving to do that in a transparent way<br>
for the user. This topic is also up for discussion at UDS and we are<br>
providing a spec at <a href="http://wiki.ubuntu.com/UnityNextSpec" target="_blank">http://wiki.ubuntu.com/UnityNextSpec</a>.<br></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div>Unity moving to QML sounds like the right choice to implement what you want. One more rewrite sounds like a lot of trouble but this one is probably worth it.</div>
<div class="gmail_extra">Does this mean no more compiz at last? I mostly hope it will mean that the dash stops being painfully slow on a computer where gnome-shell flies ;)<br clear="all"><div><br></div><div><br></div><div>
Now I guess we will have to wait and see how this turns out, but it looks like canonical is making a huge bet here: if it succeeds, it could be the first really popular linux distro (beside android) and bring fantastic improvements for all of us. If it fails, canonical would loose a lot of money and more importantly trust for other open source communities!<br>
</div><div>I really think that to succeed, some open source leader need to have strong opinions and make tough decisions, thus I like seeing you take such risks, hoping it will be for the best if you succeed, but it will be a tough journey!<br>
</div><div>I only regret the apparent lack of communications with other projects. While this worked out well for apple, it is also part of why I avoid them as a customer, I really hope canonical will not follow this path too far!</div>
<div><br></div><div>Best</div><div><br></div>-- <br>Aurélien Naldi
</div></div>