And Ubuntu for phones and tablets will eventually support Android apps.

Share this story

Mir, Canonical's replacement for the X window system, will not make it into the next version of the Ubuntu desktop.

Canonical initially planned to turn Mir on by default in Ubuntu 13.10, the version shipped in October 2013, but it was dropped due to compatibility problems in multi-monitor setups. It's especially important not to add any buggy technologies to 14.04, the version coming in April 2014, because that is a Long-Term Support (LTS) edition that Canonical must maintain for five years. Mir itself seems to be working fine, but there are problems with XMir, an X11 compatibility layer that ensures Mir can work with applications built for X.

Further Reading

"We will only bring Mir into 14.04 if we can be assured that we're not going to have any support issues," Ubuntu Community Manager Jono Bacon told Ars last month.

It now appears Mir won't make it into the next edition. "It was affirmed today that Ubuntu 14.04 LTS will still be shipping with the stable and proven Unity 7 experience, which is designed around using an X.Org Server with Compiz," Phoronix's Michael Larabel wrote today. "It doesn't appear they will try for using XMir by default in this next Long-Term Support release with Unity 7. It was also said today that point releases to Ubuntu 14.04 LTS will not be adding in Mir or Unity 8."

The comments came at the Ubuntu Developer Summit, an online event. Canonical founder Mark Shuttleworth stressed that the 14.04 desktop has to be rock-solid for customers with large-scale deployments, such as educational institutions.

"On the desktop, this will be sort of the crowning release of the Unity 7 code base," he said. "We've been working on that code pretty consistently since round about 10.04, and so we've had four very good years of continuous improvement. We can reasonably expect 14.04 to be a really fast, slick, stable, and reliable release on the desktop. That's the commitment we want to make to anyone who is deploying large volumes of Ubuntu in any large-scale environment."

Shuttleworth was asked whether Mir and Unity 8 will make it into 14.04 in the form of post-release updates and responded as follows:

No. What we'll do with 14.04 is we'll do point releases which introduce support for new hardware at the kernel level and at the X level, but we won't do point releases of 14.04 which introduce Mir and Unity 8. Now, Mir and Unity 8 are in the archive, and they will become, I imagine, more and more useful and usable, and by not making them part of the base release we probably have more flexibility to update them so they may become usable for people. But we certainly will not switch from vanilla X to Mir during the course of the maintenance life of 14.04.

Bacon expanded upon Shuttleworth's remarks in an e-mail to Ars. The goal from the start was to "deliver Mir + XMir + Unity 7 in Ubuntu 14.04 Desktop, and Mir + Unity 8 on the phone and tablet," he wrote.

However, "for the 14.04 Desktop, we are very conscious that this is an LTS release," Bacon continued. "This means that our already fairly conservative assessment of when to land significant new foundational pieces is even more conservative from a quality, technology, and support perspective. We feel that while Mir is on-track (hence its current delivery on the phone and scheduled for tablet too), we have more reservations about quality in terms of the XMir, and we didn't want to risk the LTS experience for our users."

While it won't be enabled by default, adventurous types can still get Mir from the Ubuntu archives if they wish. It could become the default on the desktop in 14.10 in October 2014, since that release won't have the burden of being a Long-Term Support edition.

Canonical has said Mir is the best option to power its Unity interface across desktops and mobile devices, but in doing so it broke with others in the Linux community supporting a rival technology, Wayland. Notably, an Intel developer said the company will refuse XMir patches contributed by Ubuntu.

"Some of the benefits that Mir will eventually offer include lower overhead in the display pipeline, more seamless transitions between display modes during the boot process, richer input handling that will make it easier to support things like touchscreen gestures, more seamless support for systems with switchable graphics hardware (like laptops that can dynamically shift between using embedded and discrete graphics), and better application interchange (which will help improve things like the clipboard and drag-and-drop)," Ryan Paul wrote in the Ars review of Ubuntu 13.10.

Before the 13.10 release, Bacon told Ars that Canonical will have an easier time maintaining Mir than Wayland in Ubuntu because Mir is lighter-weight.

"We want Wayland to do less, we want it to be thinner," he said. "Wayland has in many ways a wider scope; it tries to be more things to more people than we wanted a display server to be."

Canonical's Oliver Ries, head of engineering product strategy, said in March of this year that getting Wayland onto a mobile device would be too challenging. "[T]here is the rather sizable challenge of pulling Wayland/X onto a mobile device, working with SoCs on driver support, tuning this stack for power consumption and performance and dealing with other issues of a stack that hasn’t been designed for a convergence setup as we envision it," he wrote at the time.

Mir and Unity 8 are already powering Ubuntu for phones, which was released with 13.10. Unity 8 with Mir will power the first stable release of Ubuntu for tablets in 14.04.

Ubuntu, Android, and 64-bit ARM

Shuttleworth answered a few other questions, including whether Ubuntu for phones and tablets will be able to run Android applications. The answer is yes, but likely not in the first releases.

"That certainly is a goal," he said. "To us, Android is Java and Java runs really well on Ubuntu. Yes, that's a goal. It's not a primary focus for us in this cycle."

Canonical will try to make dual-booting of Android and Ubuntu as easy as possible. "Dual-boot with Android is something I've seen in the labs, as it were. We think that would be a very cool way to encourage people to keep track of Ubuntu development and Android evolution," he said.

Canonical will not be making its own tablet hardware, Shuttleworth said. He admitted to being "a little crushed inside" when the Ubuntu Edge smartphone wasn't funded, but he said multiple "household names" are looking to put Ubuntu on tablets and phones.

Canonical has been working on supporting ARM chips for several years and is now focusing on compatibility with 64-bit ARM processors.

"You've seen 64-bit mobile processors from Apple, we will see 64-bit mobile processors from other companies on which Ubuntu might run, and we're seeing 64-bit ARM-based processors for hyper-dense server infrastructure as well," Shuttleworth said. "ARM 64 is going to be a key focus for us this cycle."

62 Reader Comments

Tragically, you are quoting misinformation that Canonical spread and were rightly called out on for being completely full of shit. All of Mir's SoC GPU support is handled by libhybris which, again, was developed by the Mer Project for use with Wayland. Wayland is not large by any means and is already being used on ARM devices ranging from the Raspberry Pi (which has neither copious amounts of RAM nor a very open GPU) up to the Nexus 7, in addition to other less common devices.

Canonical really, desperately needs to get Ubuntu on a phone from a name-brand vendor. I was excited about Ubuntuphone last year, but at this point I've written it off as vaporware. I think continuing to make lofty promises is just making things worse. No one takes it seriously anymore. Shut up till you have something to show.

Edit: I understand, of course, that it's open source and, in that sense, not vaporware, but I mean an actual shipping product I can buy. Unfortunately, open source phone OSes are not nearly as useful as open PC OSes due to lack of drivers. Of course, that was a problem at one point, so maybe it'll get better, but that's not what Canonical is aiming for anyone, so a moot point.

Canonical really, desperately needs to get Ubuntu on a phone from a name-brand vendor. I was excited about Ubuntuphone last year, but at this point I've written it off as vaporware. I think continuing to make lofty promises is just making things worse. No one takes it seriously anymore. Shut up till you have something to show.

Edit: I understand, of course, that it's open source and, in that sense, not vaporware, but I mean an actual shipping product I can buy. Unfortunately, open source phone OSes are not nearly as useful as open PC OSes due to lack of drivers. Of course, that was a problem at one point, so maybe it'll get better, but that's not what Canonical is aiming for anyone, so a moot point.

There's a stable build on the Nexus 4. You can install it yourself, right now, with drivers and all.

While I don't condone their fragmenting the display server space, I do have to applaud them for holding back on releasing something until it's ready for once. Hopefully this means we won't be getting another Unity fiasco.

I have no doubt they can eventually run Android apps. BlackBerry 10 already does. ;-)

After all, it's just Java. Just run those APKs with IcedTea...

Oracle desktop Java and android Java may be the same language, but there are quite a lot of API differences. Just like you can't run a swing application on android, you won't be able to run pretty much any android application under HotSpot/IcedTea (well you could obviously, but you'd have to get the missing libraries from somewhere)

Maybe Ubuntu could have made it to market with a next gen Linux desktop and unified mobile/desktop display server if Canonical had stuck with Wayland instead of crying NIH, pouted and walked off to play on their own.

I have no doubt they can eventually run Android apps. BlackBerry 10 already does. ;-)

After all, it's just Java. Just run those APKs with IcedTea...

Oracle desktop Java and android Java may be the same language, but there are quite a lot of API differences. Just like you can't run a swing application on android, you won't be able to run pretty much any android application under HotSpot/IcedTea (well you could obviously, but you'd have to get the missing libraries from somewhere)

It is worse then that. Those APKs are compiled to DEX instead of java bytecode. You need a Dalvik runtime, not the JVM.

Maybe Ubuntu could have made it to market with a next gen Linux desktop and unified mobile/desktop display server if Canonical had stuck with Wayland instead of crying NIH, pouted and walked off to play on their own.

The Jolla phones that will be launched this month, you mean?

At least some sanity prevailed inside Canonical and they didn't try to squeeze Mir into a Long Term Support build.

Maybe Ubuntu could have made it to market with a next gen Linux desktop and unified mobile/desktop display server if Canonical had stuck with Wayland instead of crying NIH, pouted and walked off to play on their own.

Why do you think that it would have been any different with waylaid?

EDIT: As a matter of fact, i see now that the Jolla's phone is a custom in-house hardware and software product by Jolla

Jolla is basically a independent spin off or continuation of the ill-fated nokia's MeeGo project

Maybe Ubuntu could have made it to market with a next gen Linux desktop and unified mobile/desktop display server if Canonical had stuck with Wayland instead of crying NIH, pouted and walked off to play on their own.

When I see people disparaging Mir in favor of Wayland, I'm always curious whether they have actually looked at the code of both projects, either in terms of interfacing with it or developing it. When I did so, I was amazed at how awesome the Mir code really is (C++11 FTW), compared to the tedious and banal Wayland/Weston (X11 TNG).

You should check out the Mir code sometime. Of course, if you like incomprehensible C libraries like libX11, you might prefer Wayland anyway. But for me the choice is pretty clear.

Maybe Ubuntu could have made it to market with a next gen Linux desktop and unified mobile/desktop display server if Canonical had stuck with Wayland instead of crying NIH, pouted and walked off to play on their own.

When I see people disparaging Mir in favor of Wayland, I'm always curious whether they have actually looked at the code of both projects, either in terms of interfacing with it or developing it. When I did so, I was amazed at how awesome the Mir code really is (C++11 FTW), compared to the tedious and banal Wayland/Weston (X11 TNG).

You should check out the Mir code sometime. Of course, if you like incomprehensible C libraries like libX11, you might prefer Wayland anyway. But for me the choice is pretty clear.

Thanks for the information. In the end this is the most important information for an open source project. I don't like Unity too much but have an immediate distrust for anything INTEL does. (in the software space)

I still think that INTEL helping Nokia with Tizen was what finally killed that company. If they would have just done it on their own from the start they might have had a chance.

I have no doubt they can eventually run Android apps. BlackBerry 10 already does. ;-)

After all, it's just Java. Just run those APKs with IcedTea...

Oracle desktop Java and android Java may be the same language, but there are quite a lot of API differences. Just like you can't run a swing application on android, you won't be able to run pretty much any android application under HotSpot/IcedTea (well you could obviously, but you'd have to get the missing libraries from somewhere)

It is worse then that. Those APKs are compiled to DEX instead of java bytecode. You need a Dalvik runtime, not the JVM.

True, but it's certainly not impossible to convert the dex files to java class files. No idea if such a tool exists, but I think that'd be the easiest problem to solve - both file formats aren't especially complicated.

I have no doubt they can eventually run Android apps. BlackBerry 10 already does. ;-)

After all, it's just Java. Just run those APKs with IcedTea...

Oracle desktop Java and android Java may be the same language, but there are quite a lot of API differences. Just like you can't run a swing application on android, you won't be able to run pretty much any android application under HotSpot/IcedTea (well you could obviously, but you'd have to get the missing libraries from somewhere)

It is worse then that. Those APKs are compiled to DEX instead of java bytecode. You need a Dalvik runtime, not the JVM.

While I've switched from Ubuntu to Debian 7 on all my computers, I'm kind of glad that Canonical won't be relying in American multinationals, as they will have to if they go the Wayland way. That might not mean anything, considering Canonical is in the UK, but still. In these NSA / GCHQ days, I prefer that Euro firms stay away from American tech. At least in the UK, we don't have that kind of industry that could have been corrupted - yet. Canonical is more of an exception. Our political masters haven't subverted it, and sold it off to the yanks or the Chinese yet.

When I see people disparaging Mir in favor of Wayland, I'm always curious whether they have actually looked at the code of both projects, either in terms of interfacing with it or developing it. When I did so, I was amazed at how awesome the Mir code really is (C++11 FTW), compared to the tedious and banal Wayland/Weston (X11 TNG).

You should check out the Mir code sometime. Of course, if you like incomprehensible C libraries like libX11, you might prefer Wayland anyway. But for me the choice is pretty clear.

What does this even mean? C++11 vs X11, you are comparing a language standard to .. what, the X11 lib? You realize that is apples != oranges, and Wayland is not X11? Oh the high code quality in Mir you speak of must be the XMir code that is pretty much copy pasted from Wayland?

ETA:Every technical reason given by Canonical for the switch from Wayland to Mir has been soundly and easily refuted.

The reason for the switch is licensing. Mir is GPL, but in order to get patches into upstream Canonical requires copyright assigned to them, allowing them to re-license the code and ship products with closed bits.

"...Dual-boot with Android is something I've seen in the labs, as it were..."--Mark Shuttleworth.

Imagine that you're a research scientist delivering the Final Report to the National Institutes of Health on the existence of very rare condition, Dystopic Fibromyopathic Apoptosis, for which you've gotten a HUGE government grant to prove.

Now further imagine that the summary of your Final Report contains the phrase,

"...Dystopic Fibromyopathic Apoptosis is something I've seen in the labs, as it were..."

When I see people disparaging Mir in favor of Wayland, I'm always curious whether they have actually looked at the code of both projects, either in terms of interfacing with it or developing it. When I did so, I was amazed at how awesome the Mir code really is (C++11 FTW), compared to the tedious and banal Wayland/Weston (X11 TNG).

Could you go into detail with some examples? It's easy to bash, but hard to actually back up one's attacks. Also, Wayland is a protocol, and exists independent of any one implementation.

Thanks for the information. In the end this is the most important information for an open source project. I don't like Unity too much but have an immediate distrust for anything INTEL does. (in the software space)

Given Intel's rather intense support for Linux platforms, I'm curious as to why.

Quote:

I still think that INTEL helping Nokia with Tizen was what finally killed that company.

Nokia had nothing to do with Tizen. And Nokia did themselves in, frankly, Intel was doing with MeeGo what they're doing with Tizen now: throwing code, developers, and money at it.

Quote:

If they would have just done it on their own from the start they might have had a chance.

Which they had already done in the form of Maemo - internal politics are what doomed Nokia, not technical failings.

What does this even mean? C++11 vs X11, you are comparing a language standard to .. what, the X11 lib?

The Mir code I looked at consisted of beautiful C++11 code (i.e. C++11 FTW). The Wayland/Weston implementation I looked at was incomprehensible C code, which looked like libX11 both in terms of structure and form, with an ugly multitude of lots of C structs and functions which operated on them (X11 TNG).

ETA:Every technical reason given by Canonical for the switch from Wayland to Mir has been soundly and easily refuted.

The reason for the switch is licensing. Mir is GPL, but in order to get patches into upstream Canonical requires copyright assigned to them, allowing them to re-license the code and ship products with closed bits.

Yawn. The FSF also requires copyright assignment, so it's kinda hard to use that to paint Canonical as evil...

When I see people disparaging Mir in favor of Wayland, I'm always curious whether they have actually looked at the code of both projects, either in terms of interfacing with it or developing it. When I did so, I was amazed at how awesome the Mir code really is (C++11 FTW), compared to the tedious and banal Wayland/Weston (X11 TNG).

Could you go into detail with some examples? It's easy to bash, but hard to actually back up one's attacks. Also, Wayland is a protocol, and exists independent of any one implementation.

Thanks for the information. In the end this is the most important information for an open source project. I don't like Unity too much but have an immediate distrust for anything INTEL does. (in the software space)

Given Intel's rather intense support for Linux platforms, I'm curious as to why.

Quote:

I still think that INTEL helping Nokia with Tizen was what finally killed that company.

Nokia had nothing to do with Tizen. And Nokia did themselves in, frankly, Intel was doing with MeeGo what they're doing with Tizen now: throwing code, developers, and money at it.

Quote:

If they would have just done it on their own from the start they might have had a chance.

Which they had already done in the form of Maemo - internal politics are what doomed Nokia, not technical failings.

They really got killed when they tried to merge their OS platform with the platform INTEL was developing. Which cost them a year or more and essentially doomed the project. In the end they published a pretty amazing phone that wasn't even using Meego yet but still their own "stopgap" platform Harmattan.

And the kicker Mobling/Meego exists mostly because INTEL wanted to ensure Atom support. Which was idiotic since there is still no widely sold phone based on Atom.

Instead of going full speed ahead with the development of their own OS Nokia spend a lot of resources trying to merge with the albatross Intel created. You can say what you want but if they had published the N9 a year earlier and fully supported it they might have had a chance.

INTEL may put developers into Linux but they have no freaking idea about front-end or solution development. They may fix drivers and the OS layers near the CPU but thats it. For Nokia there was no benefit they would have needed to go ARM for 5 years anyway. Have you seen the Moblin UI? Looks like a drunk intern created it.

The Moblin/Maemo merger sounds like an idiotic idea a doomed company might have. Two albatrosses tied together do not make an eagle in this case. Which is sad because with QT and the Maemo interface they actually had a potential winner.

I'll lookup an analogous Mir code sample, but surely you can see that this would be a couple of lines of C++11, max. And while the internals may be superior to X11 in every way, interfacing with it is just as horrible.

What does this even mean? C++11 vs X11, you are comparing a language standard to .. what, the X11 lib?

The Mir code I looked at consisted of beautiful C++11 code (i.e. C++11 FTW). The Wayland/Weston implementation I looked at was incomprehensible C code, which looked like libX11 both in terms of structure and form, with an ugly multitude of lots of C structs and functions which operated on them (X11 TNG).

Was that really so hard to parse from my acronyms?

From a quick look at the Wayland/Weston code, I only see pretty nice and idiomatic C code. So it seems your problem isn't actually bad/horrible code, but just your personal preference for C++. If you want to judge the quality of some code you really ought to learn to differentiate between personal preferences and objective code quality measurements.

PS: And easily interfacing with C++ code? In what world? There's pretty much no commonly used language these days that makes that more error prone if you don't want to recompile everything you depend on (doable certainly, but that's true for most things if you try hard enough).

I'll lookup an analogous Mir code sample, but surely you can see that this would be a couple of lines of C++11, max. And while the internals may be superior to X11 in every way, interfacing with it is just as horrible.

So what you're saying is that you believe Mir to be superior to Wayland not because there is any actual deficiency in the protocol, but because Weston is written in C.

Given that KWin, which is written in C++, is being transitioned from a basic window manager to a Wayland compositor, I think your primary complaint is solved?

Yawn. The FSF also requires copyright assignment, so it's kinda hard to use that to paint Canonical as evil...

Get your facts right. From Eben Moglen at FSF

"Explanatory note added in Jan 2013: this point applies to the packages that are FSF-copyrighted. When the developers of a program make it a GNU package, they can decide either to give the copyright to the FSF so it can enforce the GPL for the package, or else to keep the copyright as well as the responsibility for enforcing the GPL. If they make it an FSF-copyrighted package, then the FSF asks for copyright assignments for further contributions, and this page explains why."

The FSF does not REQUIRE you you give them anything. Doing so would obviously violate that whole freedom thing. So what's Canonical's excuse now?

EDIT: The real difference is that the FSF is never going to re-license and sell the software people contribute. It appears to be the main reason why Canonical is asking for copyright assignment.

"Explanatory note added in Jan 2013: this point applies to the packages that are FSF-copyrighted. When the developers of a program make it a GNU package, they can decide either to give the copyright to the FSF so it can enforce the GPL for the package, or else to keep the copyright as well as the responsibility for enforcing the GPL. If they make it an FSF-copyrighted package, then the FSF asks for copyright assignments for further contributions, and this page explains why."

The FSF does not REQUIRE you you give them anything. Doing so would obviously violate that whole freedom thing. So what's Canonical's excuse now?

Please re-read that again. If you contribute to a FSF-copyrighted GNU project (pretty much all of them last I checked), then you must do copyright assignment. Isn't that the same thing you claimed Canonical did for contributions to Mir?

Contrast the mir::run_mir call with wl_open_display/etc. It's really rather shocking.

The two blocks of code are doing very different things. The wayland code is build a touch surface from scratch while the Mir code is simply loading some surfaces from it's arguments.

So far, your agrument boils down to "C++ apis are less verbose than C ones": I doubt anyone would deny that. Of course, C++ introduces all the problems associated with an unstable ABI. That's not a problem for an internal project like Mir, but for a industry wide project, a C API is the better choice. Regardless, if Canonical was unhappy with the clumsy interface to Wayland, it would have been vastly simpler to just write a C++ wrapper.

Tragically, you are quoting misinformation that Canonical spread and were rightly called out on for being completely full of shit. All of Mir's SoC GPU support is handled by libhybris which, again, was developed by the Mer Project for use with Wayland. Wayland is not large by any means and is already being used on ARM devices ranging from the Raspberry Pi (which has neither copious amounts of RAM nor a very open GPU) up to the Nexus 7, in addition to other less common devices.

So why is Canonical spending extra resources to develop an equivalent of something they could have got for free?

Tragically, you are quoting misinformation that Canonical spread and were rightly called out on for being completely full of shit. All of Mir's SoC GPU support is handled by libhybris which, again, was developed by the Mer Project for use with Wayland. Wayland is not large by any means and is already being used on ARM devices ranging from the Raspberry Pi (which has neither copious amounts of RAM nor a very open GPU) up to the Nexus 7, in addition to other less common devices.

So why is Canonical spending extra resources to develop an equivalent of something they could have got for free?

I don't know if the game plan has changed, but in theory this Ubuntu phone can also be used as a desktop computer. So you have an Ubuntu computer in your pocket as well as an Android phone.

Mind you I'm not saying this is a good idea. Computers are cheap these days. But in the 3rd world, all they have are phones. It would be useful in some markets.

LTS is about stability and they've been pretty conservative with low level transitions in previous LTSes. This also means anyone who absolutely wants to avoid Mir for some reasons has five years of guaranteed Ubuntu support to look forward to.

So far, your agrument boils down to "C++ apis are less verbose than C ones": I doubt anyone would deny that. Of course, C++ introduces all the problems associated with an unstable ABI. That's not a problem for an internal project like Mir, but for a industry wide project, a C API is the better choice. Regardless, if Canonical was unhappy with the clumsy interface to Wayland, it would have been vastly simpler to just write a C++ wrapper.

a) Why is C++11 an unstable ABI? b)Don't both Wayland and Mir servers have to talk to the kernel which will always have an unstable ABI, or do they live entirely in userland?([rant]which has crippled my Radeon 4850 fuck you AMD [\rant])

So far, your agrument boils down to "C++ apis are less verbose than C ones": I doubt anyone would deny that. Of course, C++ introduces all the problems associated with an unstable ABI. That's not a problem for an internal project like Mir, but for a industry wide project, a C API is the better choice. Regardless, if Canonical was unhappy with the clumsy interface to Wayland, it would have been vastly simpler to just write a C++ wrapper.

a) Why is C++11 an unstable ABI? b)Don't both Wayland and Mir servers have to talk to the kernel which will always have an unstable ABI, or do they live entirely in userland?([rant]which has crippled my Radeon 4850 fuck you AMD [\rant])

A) because there hasn't and never will be a defined c++ ABI (probably the prime example of implementation defined), which is why I found your post about the easier interfacing with c++ rather entertaining. The way to get a stable ABI for a c++ project is to use extern c after all..B) probably, but I don't see what that has to do with anything, your program doesn't link against the kernel after all

a) Why is C++11 an unstable ABI? b)Don't both Wayland and Mir servers have to talk to the kernel which will always have an unstable ABI, or do they live entirely in userland?([rant]which has crippled my Radeon 4850 fuck you AMD [\rant])

a) C++ has stable ABIs. In Linux, since GCC 3.something. We have ton's of C++ libraries which we use. We could say C++ is more prone to making changes to a library in ways that break the ABI than C, but it's not fundamentally different

b) the kernel's interface to user space is stable. The kernel's internals are unstable, but that's the same issue you have now (same drivers actually).

Tragically, you are quoting misinformation that Canonical spread and were rightly called out on for being completely full of shit. All of Mir's SoC GPU support is handled by libhybris which, again, was developed by the Mer Project for use with Wayland. Wayland is not large by any means and is already being used on ARM devices ranging from the Raspberry Pi (which has neither copious amounts of RAM nor a very open GPU) up to the Nexus 7, in addition to other less common devices.

So why is Canonical spending extra resources to develop an equivalent of something they could have got for free?

Quite honestly, I think Ubuntu management has lost it.

That said, they would not have gotten it for free, only for cheaper. Wayland is a protocol, not a display server.Ubuntu would have to, surely, put effort into converting Unity into a Wayland compositor/display server. Same type of work they are doing into converting Unity into a Mir compositor/display server.

Same type of work Gnome, KDE and Enlightenment folks are doing to convert to Wayland.

But if they used the Wayland protocol, they wouldn't have to reinvent the wheel without upstream support.XMir, Mir support in Qt, GTK and MESA are all things that they have to do and on their own, since upstreams are not interested in supporting a Ubuntu only solution.

To me, the thing that says the most that Ubuntu management has lost is not Mir itself, but this proposition of shoving XMir (full X system on top of Mir, instead of having a native Mir compositor) down their user's throats.It provides no benefits to users, except a nicer boot and transitions between login and sessions.Otherwise, it's same thing as X with extra overhead, new bugs and inability to use proprietary drivers.