Why Mir
voices.canonical.com
voices.canonical.com
Edit: those are not direct quotes by any means.
[Unless the Mir haters are not as large in number, but merely a lot louder]
It may well have started with Anonymous, but turned nasty somewhere around Gamersgate.
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.
I have learned to hate this term. Sometimes it means choice other times it means different solutions to the same problem. I much rather have choice then be placed in a box.
> repeating problem in open source, it's a repeating problem for Unix
Since Open Source and Linux aka *Unix has won I fail to see your point.
The big issue was they went with their own solution and didn't add to Wayland which is something they could have done this wasn't fragmentation.
"When Mir was started we needed a mechanism for client-server communications (and Wayland wasn’t in the state it is today). We did something that worked well enough (libmirclient) and, because it’s just a small, intentionally isolated part of the whole, we could change later."
Starting Mir after and if investing on Wayland failed would have been much wiser.
"Starting deb after and if investing on rpm failed would have been much wiser" except that Debian developers already knew rpm didn't meet their needs.
But these arguments are always selectively applied to certain parties (e.g. Canonical) and not others (e.g. Red Hat).
Besides, deb/rpm is the perfect example of our failure as a community. To the end user, having both standards bring nothing. Neither are better than the other for 99% of use cases, and we ends up needing twice the tool, documentation and community effort that we should.
And because it's such pain, any languages created their own package managers. gem, pip, goget, npm...
Now we are replaying the same with flatpak/snap.
After dealing with the various walled gardens and their concomitant limitations, and after dealing with any system of linux package management, the Windows way feels like some sort of joyous escape from captivity.
I don't know what you mean, but I can make my point a little more explicit: Unix has fragmented the graphics stack in the past and it just hurt the software ecosystem for no particular benefit. In the eighties, users had to choose between mutually incompatible desktop environments. Later, users had to choose between sort-of compatible desktop environments like kde and gnome (progress!). Looking beyond desktop environments to the rest of the system, there are plenty of more specialized bits that administrators and developers (and end users, if linux can truly be said to have those) have to choose between, even though no sane person should have to care.
And that's basically fine. This kind of stuff is why desktop linux is mostly just a tool for developers and students, while the real world uses Windows, iOS, and Android for everything. It's a little inconsistent for Canonical to be fragmenting the ecosystem, however, since they (maybe I'm wrong about this?) aim to bring about The Year Of Linux On The Desktop.
> Unix has fragmented the graphics stack in the past
Yes I remember these days. We were just having different solutions to the same problem. It got settled fairly fast, but I never had the issue of I paid for this Unix and now I have to decide what display manager was going to be. Each vendor pretty much made the choice already for you.
> Later, users had to choose between sort-of compatible desktop environments like kde and gnome (progress!).
I have been a KDE guy forever, but I could always use whatever programs I wanted. They might not look decent but they all worked together with a few tiny exceptions in the early 2000s. Today I mostly use a tiled window manager but I still use KDE programs with my command line programs. I don't ever get the issue with mutliple of Desktops since that is a strong plus for people to discover what works best with their workflow.
> developers (and end users, if linux can truly be said to have those)
WHAT???? You mean the people that developed Mir????
> the real world uses Windows, iOS, and Android for everything
http://google.com is Linux, Android is Linux. MacOS is a Unix. The web is majority Linux. People use Linux everyday and I guess your one of the people that doesn't realize it or it doesn't count? But the vast majority of CPU ticks on this planet are all Linux ticks.
You keep trying to make Linux Desktop = Linux and while desktop is a part of Linux. Your mixing and matching to make a point that is inconsistent.
Well, there are a few different points here. Fragmentation messes up the desktop software ecosystem, and I started with that. This is a thread about Mir, after all.
But fragmentation is not unique to the desktop portion of the Linux world. I think the same problem of fragmentation and multiple standards creating choices no end user should have to worry about applies to the rest of Linux.
> http://google.com is Linux, Android is Linux. MacOS is a Unix. The web is majority Linux. People use Linux everyday and I guess your one of the people that doesn't realize it or it doesn't count? But the vast majority of CPU ticks on this planet are all Linux ticks.
And if you have some reason to regard that as a victory, congratulations! But to get back to the point: in most of those cases, someone has abstracted away and hidden from the user - through a lot of needlessly difficult work - the gratuitous bullshit of choosing between competing GUI environments or package managers or service managers or distributions or whatever other stupid thing Linux hasn't standardized yet.
A web user doesn't care about this stuff at all. On Android, grown-ups have dictated the direction of the platform and the whole end user experience is identical to that of a closed operating system. Ditto for iOS and MacOS.
This is all slightly interesting in light of the fact that Canonical always sort of aspired to make a more streamlined and straightforward product for users, while (debatably) operating within traditional open source development norms. Going off and doing Mir (in secret, although I don't think that's really the big deal) doesn't seem conducive to that.
Anyone framing these issues as fragmentation is using it as a buzzword. Fragmentation isn't a thing when you're comparing three things that provide meaningfully different pros and cons.
Fragmentation is an issue when it means having the same 6 solutions to the problem, all poorly implemented, compared to 3 good solutions.
Nothing inherently wrong with that, but for someone outside of Canonical it's hard to be interested in a competing solution which only exist in order to pad Canonical's bottom line.
Which was also the reaction from the rest of the Linux ecosystem.
They can't license Ubuntu any way they want, because Ubuntu is 99% software which comes from (and are owned by) other sources, not Canonical.
I have nothing against Canonical wanting to follow this. I do not like only one company being able to offer a different license (their CLA). So anything like that is a no-go for me.
From the old blogs it sounds like they really wanted buffer memory allocation done in the server/compositor due to limitations on some ARM GPUs. Wayland was never about resource allocation and doesn't want to be. One of the complaints about X was that it had a bunch of OS features like memory management, font rendering, etc. At a high level I agree that it seems dumb to have memory management in the display server, but that just in principle. In practice I can't say if the mobile concerns would be best addressed with Mir or Wayland, but I think it has been addressed in both. You can run Wayland on RasberryPi after all.
In the case or Mir:
- it's like creating an alternative linux kernel. Very few chances it will succeed.
- even they roadmap didn't list anything wayland couldn't do.
- canonical doesn't have that much cash to waste.
I would have get Mir if they would have said:
- we will do X that wayland clearly can't do and that we can't contribute to wayland;
- we have tons of cash and devs and can spare a few to experiment.
It's just not the case here.
This is open source, we all want a better linux desktop, not a war. Mir felt more like starting a battle than solving a problem.
In open source, making your own project is not starting a war. This kind of flaming and demanding to control other people's allocations of resources is what makes a battle.
Since I spend easily 50 hours every year on the Ubuntu project and give to the project, I think I have the right to post a comment on HN saying "I disagree".
That's not a too much to ask is it ?
Especially since people disagreeing ending up being right.
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?
Resources are not just for dev. You have documentation, integration, adaptation of dependencies, packaging...
But even if you just don't spend the resources on wayland nor mir, then you can use them for stuff the users want. Like fixing external monitor handling, wifi and battery life .
Having basic features working on your project should be a more important priority than building an alternative compositor anyway. Even more when one is already on it's way and in good shape.
> They aren't your resources to spend. Canonical doesn't tell Red Hat what it can do, so why the other way around?
Just because they aren't my resource doesn't mean I can't express my view on it. I'm not actively preventing canonical to do anything.
But as an Ubuntu user with priorities, as an active member of the community doing bug reports and trying beta software, as an Ubuntu evangelist spending personal time to sell Ubuntu/install it/maintain it on my relative laptops and as somebody who gives financial support to the project, it's fair that I express my thoughts on the matter.
I don't even know why I have to tell that to you. It should be obvious. It's a community. Communities communicate.
Also since, me and the others like me, where right about it (that mir would fail and waste resources), I'd say I wished we would have been listened to.
I'm not playing the blame game. I'm certainly not questioning Canonical competence and I'm not angry at them. I love the company and the product. I just happen to disagree with their politic on this particular decision.
I'm now very glad they choose to invest in wayland.
I will miss unity, which was a project I liked. So it's a not just about "reinventing the wheel" and "competition". I like gnome shell less than unity, but I think it's a good decision to work on it instead for the community.
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.
Why do we need multiple of projects (By developers) to replace one project (X 11)? This has taken 10 years longer then it should have already and Mir doesn't have a declared reason why to separate from the community and do it's own alternative and how it would help all of Linux.
Likewise no one outside Canonical bothered to support Mir, because it offered no advantages over Wayland.
If you want to use Mir, go ahead, that doesn't mean anyone owes you support.
Sure you can use both, but if you choose mir you are limited to just the applications ubuntu chooses to provide. If you choose wayland, you get almost everything else because all the toolkits all choose wayland.
* I'm not actually a framework or window manager maintainer. I follow their blogs though, and this is essentially what they say.
http://blog.cooperteam.net/search/label/mir
Seems they were originally G+ postings, btw.
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.
This noted in how Fedora maintainers will often clash with those project devs, while RH basically sits and skims Fedora at intervals to form RHEL (freezing the state of Fedora at that point in time, and applying backports of various fixes etc).
Meaning that RH/Fedora, being the big dog in the distro pack, gets used by certain developers to ram through their agenda no matter if the larger Linux community wants it or not.
[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...
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.
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.
Systemd broke tons of stuff, apparently permanently, unless you're willing to switch distros.
Similarly, wayland and mir apparently will eventually break the window manager I run (which was written over a decade ago, and still works better for me than the alternatives). From this article, is sounds like Mir would have broken it even more by making it harder to reproduce the existing functionality.
The real kicker is projects like Unity and Gnome 3, which broke the parts of my laptop workflow that relied on a few modular parts of gnome 2. (Including selecting wifi, Bluetooth and audio settings) I've had to resort to re-learning forgotten command line utilities. (Unity was always unusable, and Gnome 3 was broken on Ubuntu because NIH, so those aren't viable options either).
I can't be the only one with this problem. If I were, Mint wouldn't constantly be at the top of distrowatch.
It works just fine on many distributions.
> Similarly, wayland and mir apparently will eventually break the window manager
No they won't. E.g. any DE still relies on Xwayland (often impossible to run pure Wayland). So basically relying on X11. You're making things up.
> relied on a few modular parts of gnome 2. (Including selecting wifi, Bluetooth and audio settings
I can change wifi, Bluetooth and my audio just fine.
Please be more specific. For the things you give some detail it seems things I've never seen before (else would've noticed the 1000s of bugreports). For others your problems are vague "broke tons of stuff": huh?
But now that you mention it, it's true that wayland was stagnating and that when Mir arrived, everything accelerated. Sometime having a common enemy is a good motivator.
This seems to be something a lot of people believe, but when you look at the history of it all it's really not the case.[1] I have a feeling it's because the controversy sparked a number of articles which talked about things in a more public way which made it feel like Wayland was suddenly making progress after stagnation, while in actuality development pace was chugging along as it always had been.
[1] Canonical announced Mir early 2013[2], you'll notice there is no great spike around that time in any of:
[1a] the Wayland repo https://github.com/wayland-project/wayland/graphs/code-frequ...
[1b] the weston repo: https://github.com/wayland-project/weston/graphs/code-freque...
[2] http://www.omgubuntu.co.uk/2013/03/canonical-announce-custom...
From the Qt/KDE side of things we have work on QtWayland[2] and work on Plasma/KWin[3]. The former had development increase as work on Wayland continued and follows a general upward trend, especially after Plasma started using it. For the latter, the article covers the timeline pretty clearly.
From what I can tell my point still stands, even when talking about support from integrators.
[1] https://wiki.gnome.org/Hackfests/WaylandHackfest2012
[2] https://github.com/qt/qtwayland/graphs/code-frequency the spike you see happened Jan/Feb which was prior to the Mir announcement and if you check the number of commits there was no major increase at that time
[3] http://blog.martin-graesslin.com/blog/2013/04/the-history-on...
Not true at all. Various years before Mir started, Canonical publicly said the future was Wayland. Canonical promised to do some work on Wayland. They started Mir, didn't do that work, then 6-9 months later announced Mir.
They delayed that work for 6-9 months due to keeping Mir a secret.
There's NO speedup due to this. It caused delays. Wayland was already at 1.0 by the time Mir was announced. However, that 1.0 was for basic things. After this it needed desktop environment standards. That's what the various desktop environments needed to work on. Initially that was GNOME, Enlightenment and KDE.
Due to those agreements you could finally actually see the results of many years of work. Practically though, things could've been faster with Canonical also joining in (making/agreeing/discussing standards, etc).
Whilst commit frequency does not display this, I still believe that developing Wayland was taken more seriously after Mir was announced. This is however my suboptimal opinion, and I am willing to concede that I am wrong and discuss the matter further.
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).
http://voices.canonical.com/alan.griffiths/2017/04/11/a-new-...
The actual blog post from the developer in question is at Canonical: http://voices.canonical.com/alan.griffiths/2017/04/12/why-mi....