OSNews

Ubuntu have written a lot of things, but, AFAIK, none of it has been picked up by any other distro. They should stick to what they do best, which is to repackage other people's work, and not try to fork the Linux desktop.

[edit:] Of course, if Ubuntu actually for once make a superior product in shorter time than the competition, then that's a welcome contribution. For some reason, I just don't have any faith in them at all -- but the X.org developers behind Wayland hasn't really shown any reason why I should trust them more.

Edited 2013-03-04 18:55 UTC

Sounds a lot like MS, doesn't it? Seems like every 3-5 years, MS is 'betting the company' on some new technology.

There's something seriously wrong if you can't evolve and modify your direction in light of new industry trends and realities.

Remaining steadfast in the face of a sea of change is what made Microsoft miss the boat on mobile.

Microsoft's client side evolution (from a managed POV, native has always been a mess until Win8) has always been about XAML and a GPU accelerated framework.

WPF -> WPF
-> WPF 3, 3.5, 4, and 4.5
-> Silverlight
-> Silverlight 2,3,4,5
-> Silverlight for Embedded
-> SL 2.0 for Symbian
-> Moonlight
-> Silverlight for WP
-> Silverlight for XBox

So we had two divergent technology branches based on the same core technology for the last half a decade. WPF was the result of a botched Vista dev cycle and showed it. Silverlight was slimmed down, almost beautiful in how simple it was, but ultimately a science project (albeit one that got too successful for WinDiv to stomach)

However, despite the differences in API surface, a lot of the architectural design decisions remained persistent:

XAML
Dependency Properties
Storyboard time based and keyframe animation
GPU acceleration
Databinding

Sharing code between SL and WPF was easy, share code from WPF to SL was hard (since WPF is a superset, put simply)

From there we got the convergence of native and all the managed stacks into the Windows Runtime.

This unified not only WPF and Silverlight by bringing SL into the client, but it unified .NET and COM in a much more natural way.

Prior to WinRT, Microsoft released great COM based APIs for Windows (Win7 Taskbar APIs for example) but .NET wrappers came months, sometimes years later.

With WinRT the projections are automatically generated and the ABI is uniform so calling into native code from .NET is much more natural and faster (for coarse grained ops)

I think over the past 7 or so years Microsoft's vision has remained consistent, but the means to get there has changed slightly. Silverlight went from an RIA plugin , to an OOB solution, to being reborn as the XAML platform in WinRT (gross simplification).

Thankfully, WinRT has restored sanity to native code. I can write super fast native code, interop with my C# app, and not have to see a single IUnknown or AddRef (save for DirectX). Its great.

Going forward I expect almost every new API out of MS to use WinRT.

Doesn't look like WinRT/Metro is really taking off on the desktop quite the way they hoped it would. So you reckon they'll toss that to the side and 'bet the company' on something else for Windows 9? If not, when are we getting fully-functional winRT versions of MS Office and Visual Studio? THAT is when I'll know that they're really serious.

Well, I disagree with the notion that Windows 8 (which I assume you meant) isn't taking off. Its likely selling modestly at best, and at worst being held back by a couple of OEM conditions:

- Shortage of touch screen components and high costs
- Lack of a complete product range. The Windows lineup had holes in it. This was badly fumbled.
- Global economic conditions
- Elongated upgrade cycles for PCs.

The good news is that assuming OEMs can get their act together and put together some sub $1000 touch screen devices, then they'll have winners on their hands.

Windows 8 shines best with a touch screen and a lot of the models sold were decidedly non-touchscreen.



WinRT isn't there yet in a few places, but I agree with you they should port both apps. Especially Visual Studio.

Last time they did this, they ported large parts of VS to WPF. It greatly moved the ball forward towards them addressing architectural deficiencies in the platform while they were dogfooding WPF on such a massive scale.

But I think its important to separate WinRT, the technology, from what you perceive the reception of Windows 8 to be. Its like saying the DWM was going to be removed in Windows 7 because of people claiming Vista wasn't selling. That's not really how things work.

Prime example being WPF, it was never terribly successful, but the innovations in WPF eventually led to WinRT. These are game changing events.

WinRT has far reaching implications. Beyond Windows 8, beyond Metro, and changes the game for Windows.

It now has a first class, native, ABI safe, object oriented API. That's incredibly powerful.

They can describe APIs as Async operations with continuations and using stuff like generics and exceptions. Compare that to the mess that was classic COM.

Agree with you there, and I think it is a welcome improvement. But if they can't manage to build a desktop environment around it that doesn't suck ass, it's going to flop, just like WPF and Silverlight, albeit for different reasons.

Personally, I hope they continue to improve it and make Metro in Windows 9 something that is actually usable. Whoever it was that decided that right mouse button menus were no longer relevant, and that horizontal scrolling was a good idea on the desktop should be summarily executed. And I don't mean that figuratively either In fact, we should put them into a lion's den, alongside the asshole at MS who invented the F-lock key, and then charge for admission.

Edited 2013-03-05 05:59 UTC

I don't think they're going to build a Desktop environment as we know it. Period. I just can't see them going back at this point.

I do think that Metro Style apps will become a lot more powerful. The XAML stack will become more feature filled and support more scenarios.

They'll presumably show a lot of love to Mouse+Keyboard users. They don't really need to do much to dramatically improve the experience.

What they need more than anything is a standardized generic gesture driver for laptop touchpads. Every new Laptop with Windows 8 I saw did swiping gestures on the touchpad differently.

It ranged from completely terrible to mildly amateur. Its a nightmare. This needs addressing.



Well just look at the growth from WP7.0 to WP7.5 to WP8. Its night and day. With some time behind it, Microsoft will mature the platform to be very powerful.



Right Mouse buttons have never been particularly discoverable, in my own analytics, people that use my apps and don't use tablets have a hard time discovering the App Bar (opened by a right click).

I've always seen the context menu used as a dumping ground for options which is annoying. There's a better way in Metro.

But Metro allows you to write Context Menus pretty easily using Popups (which is how they were made under the hood in WPF/SL. In fact, you can easily port the WP7 ContextMenu from the SL Toolkit if you want, there's a better one in Callisto a WinRT Toolkit).

I just don't think context menu's fit into Metro. A combination of app bars, content as chrome, and flyout menus can address all of the context menu scenarios.

The focus on horizontal scrolling is an artifact of their stupid obsession with 16:9 aspect ratios. I hate it. It makes portrait views on tablets useless. My Surface feels like a skateboard in portrait mode.

This is a typical response from developers. They look at various statistics and decide 'well, since 90% of people aren't using this, we might as well take it out', thereby alienating the other 10%.

Personally, I think there's a way to please both camps with the same product, but nobody seems to even be making an attempt these days. Even Google is dumbing down Android, claiming that things such as SD cards are too complicated, and so they just rip it out.

This is what I like to refer to as the war on power users. I guess I shouldn't be surprised though, since it seems that any minority group in this world are the ones that get shit on and ignored.

Better to change direction now before everyone's on the Python/GTK train.

Better to change direction now before everyone's on the Python/GTK train. "


If I remember, Gnome settled on javascript, not python. I wonder if this is the reason for the change now. Maybe Canonical has lost faith in the Gnome community. They would not be the first to wonder where the heck Gnome is going. Personally I don't see how you can base all your desktop apps on javascript, unless they are all web apps, but I am not really a dev.

Ubuntu apps, Ubuntu desktop environment, Ubuntu desktop server, Ubuntu operating system. Nice.

That is only if you like an Ubuntu everywhere world and if only Ubuntu gets the brunt of the developers working in the ecosystem.

If it becomes Ubuntu OS and apps, Fedora OS and apps, OpenSUSE OS and apps, Mageia OS and apps, Arch OS and apps, etc. We'd be worse of than today where GNU/Linux still scratches the single digits n the desktop.

It is exiting in a geek kind of way, but this doesn't do anything for the much needed unification in the lower levels of Linux' plumbing.

Ubuntu wants to become a desktop Android, a platform friendly for commercial, closed source software.
Present free desktop efforts failed at that, among others because the OS/Distro split that has marginalized Linux as a platform.
The situation you've described has defacto existed for commercial developer for years due to pointless distro incompatibilities on system level and lack of backward compatibility. Canonical is simply catering to the reality and sitting in the driver seat.
The remaining distros will remain as they are in the semi coherent free desktop world, while ubuntu might get to become a true platform. The free apps will eventually get ported to it.

And then we are back to square one. A "proprietary" vendor calls the shots on your computer.

Just wiser that community driven desktop is an utopia.

I'll admit that my "ideal" of having a huge joint venture of commercial and volunteer interests producing a truly usable and free(dom) software ecosphere were naive. It's just that the same old, same old attitude of "Winner takes it all (or dies trying)!" is the worst possible outcome.

Sorry, but the editor doesn't allow to edit the title.

The word "mir" usually means peace, world, village or community (or a combination of those). It's sort of like the idea of "global unity" in English. In short, the term "mir" perfectly fits with Canonical's naming scheme. Ubuntu, Unity and Mir all carry a strong meaning of many people coming together for the greater good.

Mir is the name of the international space station. Several products by Canonical bear a name related to Mark's experience in the space.

"Mir (Russian: Мир, IPA: [ˈmʲir]; lit. Peace or World) was a space station that operated in low Earth orbit from 1986 to 2001, at first by the Soviet Union and then by Russia." (Wikipedia.)

Though it's worth noting that the core module of the International Space Station is a twin of Mir core module, built as a backup. ISS core module even had "Мир 2" painted on it during the years it was in storage.

So, in a way, ISS is Mir 2.

Or is it the German word "Mir" which means "to me"?

Or the Persian "Mir" which is something like "Sire" or "Your Highness"?

It is also a not very common family name in Spain.

We are talking Ubuntu here. Considering that Shuttleworth( wasn't really worth for a shuttle ride ) had a lot of exposure to Russian language(it's one of the courses he had to take during his training for his flight to ISS) we can safely say that it's a Russian word.

They discussed this in the MirSpec page.
I don't know if/how valid it is but below are the excerpt.

"Why Not Wayland / Weston?

An obvious clarification first: Wayland is a protocol definition that defines how a client application should talk to a compositor component. It touches areas like surface creation/destruction, graphics buffer allocation/management, input event handling and a rough prototype for the integration of shell components. However, our evaluation of the protocol definition revealed that the Wayland protocol suffers from multiple problems, including:

1.The input event handling partly
recreates the X semantics and is thus likely to expose similar problems to the ones we described in the introductory section.

2. The shell integration parts of the protocol are considered privileged from our perspective and we'd rather avoid having any sort of shell behavior defined in the protocol.

However, we still think that Wayland's attempt at standardizing the communication between clients and the display server component is very sensible and useful, but it didn't fit our requirements and we decided to go for the following architecture w.r.t. to protocol-integration:

1. A protocol-agnostic inner core that is extremely well-defined, well-tested and portable.

2. An outer-shell together with a frontend-firewall that allow us to port our display server to arbitrary graphics stacks and bind it to multiple protocols.

In summary, we have not chosen Wayland/Weston as our basis for delivering a next-generation user experience as it does not fulfill our requirements completely. More to this, with our protocol- and platform-agnostic approach, we can make sure that we reach our goal of a consistent and beautiful user experience across platforms and device form factors. However, Wayland support could be added either by providing a Wayland-specific frontend implementation for our display server or by providing a client-side implementation of libwayland that ultimately talks to Mir."

Edited 2013-03-04 20:35 UTC

I'm not so sure how valid those reasons are. But they didn't address the drivers fragmentation (of the lack of it) that can arise because of their shift.

Wayland / X.org developers take on this:

http://www.phoronix.com/scan.php?page=news_item&px=MTMxNzY

Edited 2013-03-05 01:52 UTC

s/Wayland \/ X.org/Red Hat/

That said I agree with them. But it is worth reminding that except for Haitzler, all the people expressing their opinions on that phornix page either work or used to work for Red Hat.

I'm not so sure we aren't getting any fragmentation problems here.

What about drivers development? Will their server share the same drivers with Wayland or not? If not, it's going to be a horrible fragmentation bordering on intentional diversion. Nvidia excused their lack of Wayland support with waiting for wider adoption. With this move by Canonical they just won't release it at all.

Of course if drivers could be shared - this can be avoided.

Edited 2013-03-04 20:19 UTC

Ah, but that was my point, the vendors are already supporting Android's SurfaceFlinger, Mir is somewhat/mostly? compatible from the driver stand-point, so it actually reduces complexity if it gets adopted over X and Wayland (which has almost no vendor support yet).

More importantly, more drivers exist for SurfaceFlinger than exist for Wayland because of Android. If anything, Android is the standard, not Wayland.

Both are unproven, and its a big risk for Ubuntu, but lets not pretend like Wayland has critical mass or clout at this stage in the game.

I'm personally not interested in SurfaceFlinger in this context, since it has hard dependency on bionic.

Wayland and Mir have no adoption yet, but if they will rely on incompatible drivers, it will create totally unnecessary and very sick competition for drivers including on the desktop, since Canonical stated they plan to switch to Mir everywhere (desktop and mobile).

The sickness of this is well demonstrated by Android already.

Games developers will just shrug and say that Linux is way to messy to support, or they'll say they only support Mir (and not Wayland) and so on. Either way it sounds pretty unpleasant.

Edited 2013-03-04 20:31 UTC

I think that's silly. It is likely less work to adopt SF (or Mir) to use a full libc imp. than to flesh out Wayland.



Mir standardizes around the way Android drivers interact with SF, if Mir becomes commonplace(and not Wayland), then vanilla Linux would reap these benefits and it would increase the accessibility of these drivers to all screens using Linux.



There's two ways to deal with this: Get rid of Android (Good luck) or standardize around Android. Mir chose the latter.



Game developers should be an abstraction above SF/Mir at all times. I cannot think of a single instance where a game developer will need to interact with the compositing core of the OS. There's a serious issue if this is the case.

That's the point - will their abstraction work on Wayland? Or they'll say "game for Mir only"?

This can work out better if:

1. Drivers will be shared (i.e. same drivers will enable Wayland and Mir) - so no stupid competition for drivers there.
2. Wayland will have a Mir plugin, and vice versa allowing programs designed for either one to run on another seamlessly and with insignificant overhead.

If that would be the case - things can turn out good. If these issues will be ignored - things will turn into a horrible mess.

Edited 2013-03-04 20:49 UTC

If you're coding to an abstraction, by definition, you should not care about whats underneath. Devs using OpenGL don't know about the implementation details (be it DRI, or routed through X, or whatever Android does)

It's called competition. Deal with it.

Lets not overstate this problem. The majority of the code in the driver will be the same regardless if it runs on mir, wayland or X. The only thing different will be the part that integrates with the video system.
If this is a major obstacle for the driver developers, well, wtf are they doing writing drivers?

Time will tell if that will be true. Android created sick drivers fragmentation precisely because they didn't care about the community. Canonical doesn't seem to care much either.

Agreed.

What you forget in your "analysis" is that Wayland developers are the same as X developers..

Actually, X got pretty good once the community forked XFree86 and told them to go fuck themselves. Xorg has actually been pretty good.