
Why Mir - dbcooper
http://voices.canonical.com/alan.griffiths/2017/04/12/why-mir/
======
phkahler
The question has never been "Why Mir?", but rather "Why Mir instead of
Wayland?" and I don't think they've ever really addressed that. Looking back,
the one thing I do remember is that Mir was going to work with the closed
source nVidia driver where the Wayland guys just said "this is the future and
nVidia needs to make some accommodations or they won't get to play". I don't
recall the details, but nVidia waited until the future was inevitable and then
came around - and I can't blame them for waiting, given how long it actually
took it could have been a waste of effort.

Edit: those are not direct quotes by any means.

~~~
j0lly
Why not both? I want to use Mir instead of Wayland, who are you to tell me
what to use?

~~~
sametmax
You can have both if both eventually exists. The problem is that a graphic
server is a really hard software to make, integrate and maintain. We kept X
for decades for this reason.

Trying to build and make a standard of a new one is hard enough.

Spending resources for a 3rd one, that we all knew has less chance of
succeeding, was considered a waste by many.

As a community, some like me analyzed that Mir was a bad strategic move and
just said it. There is nothing wrong with expressing this opinion. It's not
stealing your freedom away.

Turns out we were right. Mir was too big of a project to chew for canonical,
and the effort, that could have been invested in getting a better wayland
sooner, was wasted.

This is a repeating problem in open source. It's hard to find the balance
between innovation and playing as a team.

Given the fantastic track record of canonical though, we can't blame them.
They tried. I'm glad they have this spirit, they made the Linux desktop
better.

I'm also glad the Mir fad is over.

~~~
pekk
"Spending resources for a 3rd one"

1\. Doubling the number of people on a project does not double the speed of
its production. It may actually hurt matters. This is the classic problem of
estimating with man-hours and ignoring coordination costs

2\. They aren't your resources to spend. Canonical doesn't tell Red Hat what
it can do, so why the other way around?

~~~
bluGill
Your point 1 is wrong. The original quote is "adding people to a late project
makes it latter". This quote is true, but it only applies to late projects. A
project that is not late is in a more complex situation, and can often benefit
from adding more people. Once you pay the price to get everyone up to speed
they can all contribute which in many cases can double the long term speed.

There is of course a limit, eventually you get too many people, but Wayland is
not in danger of that. I believe Wayland would be better off with triple the
team size long term. It would let them fix numerous bus problems, allow more
code review, and speed them up. I would gladly take slower progress short term
to get faster progress long term.

Unfortunately code like wayland demands the best programmers. A .01% speed
increase in many parts is noticeable to the end users. There are tons of bugs
in graphics drivers (and hardware) that have to be worked around at the
wayland level. There are many variations of what the hardware can do and they
need to take advantage of each one while still working on systems without that
feature. As such wayland (like X before it) is unlikely to ever get enough
people.

------
eptcyka
The only good thing Mir brought to the world was competition. As soon as
Canonical announced that they had been working on Mir for a year, everyone and
their dogs jumped on making Wayland a success. And Canonical has to be
commended for this. Even if it was hugely unethical of them, as whilst they
were developing Mir in secret, they had publicly stated that they will fully
commit to Wayland.

~~~
sweden
Nobody jumped on anything when Canonical announced Mir. The only thing that
happened is that the world asked a bunch of questions to Canonical and to Mark
Shuttleworth and no one was able to explain exactly "Why Mir?". In fact, not
even this blog post.

Mir was not a threat, in fact, thinking about "threats" in open source is so
silly. It is not even suppose to be a competition.

~~~
addicted
The answer was fairly clearly stated right from the beginning.

[quote]Canonical chose the latter., with Mir built specifically to meet the
aims and goals of Unity.[/quote]

Where the goals of Unity was convergence across all platforms.

[http://www.omgubuntu.co.uk/2013/03/canonical-announce-
custom...](http://www.omgubuntu.co.uk/2013/03/canonical-announce-custom-
display-server-mir-not-wayland-not-x)

A lot of people chose not to believe this, but it doesn't change the fact that
the Ubuntu team clearly articulated that they thought that their goal of
convergence across several form factors required a new display server which
was focused more on that than Wayland.

~~~
Etzos
It's not that people chose not to believe this, it's that the whole point
doesn't make sense at all when looked at in detail.

When asked to provide specific technical reasons for the existence of Mir
beyond the nebulous ones stated in the article, Canonical was unable to list
anything of any real value. Input was one of the things mentioned, but in the
end they ended up going with the Wayland solution (libinput). The whole point
of Mir's existence, that is a goal of convergence across several form factors,
is also filled perfectly by Wayland. Mir provided no advantages over Wayland
for that goal.

This is kind of frustrating because Canonical spent time working on a system
which provided almost exactly the same thing as Wayland instead of
contributing to Wayland. And that alone may not have been that bad if they had
been open about it, but Mir development happened in the dark for a long time
prior to announcement and when it finally was announced Canonical listed off a
bunch of issues they had with Wayland which they had never even brought up
with the Wayland developers.

All that would probably still be okay if at the end Mir offered something over
Wayland, but that's just not the case. Even now there doesn't seem to be any
technical reason for Mir to exist or have existed at all.

------
JBReefer
This is an odd posting. It's a (very) short history of the reasoning behind
and purpose of the Mir project at Canonical, but doesn't hint at the future of
the project or the team.

It's a dictionary definition more or less, but the timing seems like it has a
great deal of meaning (in the wake of the Unity abandonment).

~~~
Symmetry
The previous post had a bit more info.

[http://voices.canonical.com/alan.griffiths/2017/04/11/a-new-...](http://voices.canonical.com/alan.griffiths/2017/04/11/a-new-
hope/)

~~~
qznc
That one actually makes sense. It states that there are issues with Mir and
Snap/FlatPack packaging. It ponders its future and to use libwayland within
Mir.

------
GnwbZHiU
Canonical stop supporting Unity. I guess it will stop supporting Mir as well

------
unwind
Is this blogspam? It's a blog post about a blog post.

The actual blog post from the developer in question is at Canonical:
[http://voices.canonical.com/alan.griffiths/2017/04/12/why-
mi...](http://voices.canonical.com/alan.griffiths/2017/04/12/why-mir/).

~~~
mathw
Yup, that's the link that should have been posted. Phoronix added nothing
useful to a fairly sparse article.

