taking Unity to the next level

Tue Mar 5 10:31:38 UTC 2013

Hi all,

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!
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!
I'm asking all this because I care about the future of ubuntu!

On Mon, Mar 4, 2013 at 6:46 PM, Oliver Ries <oliver.ries at canonical.com>wrote:

> After thorough research, looking at existing options and weighing in
> costs & benefits we have decided to roll our own Display Server, Mir
> (rf. http://wiki.ubuntu.com/MirSpec).
>
> None of the existing solutions would allow us to implement our vision
> without taking major compromises which would come at the cost of user
> experience and quality. We will be running sessions at UDS to discuss
> questions and take feedback.
>

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!

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).

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.
In my dreams, here are some example of valid reasons:
* 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
* 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.

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?
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:
* either you do something vastly different from wayland, and you will still
need lots of time to get tons of details right
* 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)

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?

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?
I suppose you plan a Mir backend for cairo and clutter (probably needed for
GTK support), what about SDL and similar libs?
Any plan for network transparency?

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 ;)

Also, driven by Ubuntu Touch we are starting to move Unity over to a
> Qt/QML based implementation, embracing Qt as a community backed
> technology for our offerings. We are looking at tackling the transition
> from the Nux based implementation to a Qt/QML based implementation
> component by component and are striving to do that in a transparent way
> for the user. This topic is also up for discussion at UDS and we are
> providing a spec at http://wiki.ubuntu.com/UnityNextSpec.
>

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.
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 ;)

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!
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!
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!

Best

-- 
Aurélien Naldi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130305/61dab943/attachment-0001.html>