
The thought process that led Canonical to create Mir - cs702
https://plus.google.com/u/0/113883146362955330174/posts/PXc93m8nKwk
======
bjourne
It's well known that Canonical likes to do things their way and maybe suffers
from a slight NIH syndrome. But do people have to be so upset about it? Maybe
Rogers explanation is completely wrong and the real reason is "we thought it
would be fun to write a new display server!" Does it matter? Saying "you're
increasing desktop fragmentation" is silly and implies that writing Mir is
somehow worse than writing no code at all.

Graphics on desktop Linux currently kind of sucks. Windows and OS X are years
ahead while we are stuck on X11 with flakey, sometimes-working, compiz-quality
3d effects. I think any effort to remedy that situation should be cherised.

~~~
mtgx
As a non-Linux user, it's funny to me how Linux users complain about how this
will bring fragmentation to Linux, when Linux is one of the most fragmented
ecosystems ever. There are tens or hundred of different distros, and at least
several different application packages, and I'm probably not aware about a lot
of other stuff, too.

I support Canonical in this move, because they do need a very optimized
display server and interface for mobile hardware, and they are also the ones
who've pushed Linux the most into the mainstream, sometimes by taking steps
that are very annoying to regular Linux users, but in the same time very
pragmatic in bringing Linux closer to the non-technical current Linux user, or
future Linux user.

~~~
shmerl
Fragmentation can be very different. The sickest type of it is hardware
fragmentation caused by incompatible drivers. The most obvious example is
Android. Their choice of bionic libc makes running normal glibc Linux with
Android drivers impossible (unless you attempt to translate glibc into bionic,
like libhybris does). So this fragmentation creates a very strong barrier for
using hardware and everyone would agree such kind of rifts are not a pleasant
thing. Luckily in Mir's case Canonical seems to be interested in avoiding
drivers fragmentation with Wayland.

~~~
fluidcruft
Why is Android the bad actor for people writing non-portable software that
relies on non-standard GNU extensions?

~~~
shmerl
I didn't understand the question. libc lies in the core of the system, and if
libc is incompatible it translates to non reusable drivers, which translates
to "Android only" hardware. What do you call a "non-standard GNU extension"?

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

I'd accept this as reason alone to go with Mir, assuming it's correct. My
experience with window managers on linux has been riddled with constant bugs
and regressions that are the hallmark of software that isn't adequately
tested.

And he's absolutely right. If code isn't designed ahead of time to be modular
and decoupled (testable), you're going to have a hell of a time refactoring it
later to get good test coverage.

I'm not asserting Weston is these things. But, accepting what Christopher says
here, Canonical might actually be justified in creating Mir. I'd especially be
interested in hearing if someone can refute the mentioned point.

~~~
ibotty
kwin will be its own wayland compositor, gnome's mutter will be its own
compositor. why didn't canonical create unity as its own wayland compositor?

(in other words: criticizing weston is a strawman)

~~~
SEMW
The section the GP quoted was not the entire article. Rogers went on to end
the quoted paragraph with the rhetorical question "We don't want Weston, but
maybe we want Wayland?", and went on to address that question in the rest of
the article.

Whether or not you agree with the chain of reasoning, pretending he never
wrote anything other than a single step in it, and calling that a "strawman"
on the grounds that it isn't a whole chain, is a little silly.

------
Osiris
I find it interesting in the comments that most people are claiming that
Canonical's time would be better spent contributing to existing projects, but
isn't the nature of Open Source to be constantly forking, iterating, and
contributing new code when you think the existing stuff isn't good enough?

Aren't these attitudes the basis of why many subsystems in Linux have been
around for decades?

Others complain about fragmentation, which is another obtuse argument when you
count the number Linux distributions available, the number of open source
packages, and the entire nature of GitHub with their "please fork me" button.
Open Source is by nature fragmented.

If they want to go run off and do their own thing, what's the problem? It's
their time and money. If what they write is crap, no other distributions will
use it. If it's awesome, it has a lot of potential, but the community should
decide after it's released, not before.

~~~
andor
_isn't the nature of Open Source to be constantly forking, iterating, and
contributing new code when you think the existing stuff isn't good enough?_

You can always start from scratch if existing projects don't cut it. When
talking about a windows manager (like Unity) or display manager (like Mir),
starting from scratch is, financially, a pretty big decision, so you should
make it an informed decision. The weird thing is that Canonical never even
contacted the Wayland developers. It's weird because they should be interested
in any mistakes Wayland made on their way (to not make them again), and
because it's _so easy_ in the open source community. If you find a bug in your
Intel graphics driver you just go to freenode and talk to the developer that
_wrote that code_. Same for Wayland, and most other projects.

If they really want to be better than Wayland, they should learn from
Wayland's mistakes, not make the same mistakes again.

------
shmerl
I didn't get the answer. Why couldn't they work with Wayland to build the
missing pieces? Or Wayland developers had some principal objections? It looks
like Canonical didn't even make an attempt to collaborate. That's the main
point of criticism.

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

That's exactly the NIH problem. So in essence - no real reason, except selfish
interests.

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

At least this part sounds good. If drivers can be shared - hardware
fragmentation will be avoided - (i.e. Wayland will reuse the same drivers
especially on mobile).

~~~
adamors
Shuttleworth actually goes on to say in the comments _"The very people
protesting their super-collaborative credentials have a long history of being
super-antagonistic to Ubuntu in practice."_

I don't think it's even the NIH problem it's just sheer delusion.

------
networked
>4) We need server-side buffer allocation for ARM hardware;

Could someone explain why?

~~~
ibotty
something was said about it in irc a few days ago. i am not competent enough
to paraphrase the reason. so here is the quote from
<http://pastebin.com/KjRm3be1>

00:15 <Prf_Jakob> RAOF: why do you guys want server-allocated buffers?

00:15 <RAOF> Prf_Jakob: Mostly arm damage, there.

00:15 <Prf_Jakob> RAOF: so thats whats its really about then? Closed source
drivers?

00:16 <RAOF> No - arm hardware (apparently) has insane constraints that make
server allocation more attractive.

00:16 <RAOF> eg - you have at most 6 buffers that are framebuffer-compatible.

00:16 <krh> we have those GPUs at intel too

00:17 <krh> weston runs on those

(note that daniel stone said:

00:35 <daniels> RAOF: fwiw, i've got a wayland backend for arm hardware which
does server-side allocation right now. didn't require one single change to any
of the clients, or even compositors. it's all internal to the egl stack. )

~~~
zanny
I have a bad feeling this G+ post is about to be ripped apart as badly as the
initial wiki debacle.

I wonder when people will realize, though, that as Canonical tries to justify
itself on technical merits and having to backpedal every time, their answer of
"we want to control it so we can move it and change it as we want to without
having to wait for consensus or forking" is not good, but legitimate.

------
GhotiFish
for the record. this:

    
    
       "ranging from the sensible (we want to write our own 
        display serve so that we can control it)"
    

is sensible to him.

What the hell is going on at Canonical? I can't imagine how BADLY mir will
damage desktop development in linux if Canonical actually forces its adoption
and then holds the main repository.

It would have to be forked to get it away from them. Are we even allowed to
fork CCA code?

Why do I get the feeling that if any of this happens, canonical is going to be
suing linux end users.

what a mess.

~~~
Sanddancer
So why does RedHat seem to get a pass with GNUists when they do similar
things, such as with writing systemd instead of patching upstart?

~~~
andor
Some core concepts of upstart and systemd are incompatible. Even if they
patched upstart instead of starting from scratch it would now be a completely
different system.

In his initial blog post about systemd, Lennart Poettering writes: _"Well, the
point of the part about Upstart above was to show that the core design of
Upstart is flawed, in our opinion. Starting completely from scratch suggests
itself if the existing solution appears flawed in its core. However, note that
we took a lot of inspiration from Upstart's code-base otherwise."_

Link: <http://0pointer.de/blog/projects/systemd.html>

Unlike the Mir specs, this post is really detailed. Upstart is certainly an
improvement on sysvinit, but falls short compared to more modern init systems
like Apple's launchd.

~~~
Sanddancer
Mir likewise states that inherent incompatibilities is exactly why they're
creating a new project as well. Though a big difference being that Upstart is
actually in use, whereas no one's using Wayland.

To be quite honest, a lot Poettering's rationalizations with systemd,
especially when discussing other inits like launchd, seem to be purely NIH. He
could do this work and organize with what's already out there, but he'd rather
do our own thing. Instead of creating a system that is backward compatible,
he's saying for daemon writers to write for a completely new specification,
and to ignore any pretenses of compatibility, like not double forking. More
discouraging are the intentional incompatibilities, and statements that
they're only targeting the linux kernel and udev, and will reject patches that
make it more compatible with other systems.

~~~
ibotty
that's just not right.

see how many port activated upstart starting scripts there were before systemd
entered the scene.

there is the difference as well, that mir has no solid reasoning (or its
reasoning gets debunked shortly afterwards).

------
freehunter
I do wish that Canonical would fix their SSL issue. Here is what I see when I
visit from Chrome [1]. This is particularly frustrating because when I click
proceed, this is the next thing I see [2]. I surely am not going to make an
SSL exception in our corporate proxy just because Canonical can't fix their
certificates.

[1] <http://i.imgur.com/UMST00Q.png>

[2] <http://i.imgur.com/iv4ZCaq.png>

------
mongol
What will be the effects of this fragmentation? For example, will we see
Firefox for Mir and Firefox for X and Firefox for Wayland? Is there a risk
that one window system will be without applications? I am too distanced to
draw these conclusions myself.

------
eliben
I like it how Google Plus is being used as a micro-blogging platform

------
yarrel
"What can we do next to screw up Linux?"

~~~
freehunter
No one can screw up Linux. It's open source and there's a huge and disparate
community behind many projects spanning thousands of use cases. Even if Ubuntu
somehow managed to go closed source and charge a mandatory license fee, Linux
would still be Linux. Ubuntu is not the only project, by far. And you wonder
why Shuttleworth is getting pissed at you guys.

------
drivebyacct2
Mark is needlessly caustic in these comments, in my opinion.

~~~
da_n
I wouldn't say it was needless. As far as I'm concerned, it is the KDE and
Wayland guys who have come out screaming in a very public, very vitriolic
attack against Ubuntu. No matter what side of the argument you stand on, you
can't deny that they have been taking a shit on the Ubuntu brand (although a
lot of the worst comments have been deleted it appears). It is no wonder Mark
is reacting in a caustic manner in my opinion.

~~~
burntsushi
> it is the KDE and Wayland guys who have come out screaming in a very public,
> very vitriolic attack against Ubuntu

When blatantly false things are stated about your project by an organization
as big as Canonical, one really can't blame them for expressing frustration.
Especially when there is FUD about Wayland _everywhere_ you go.

