“Canonical has today publicly confirmed that they are working on a new cross-platform displayer server for Ubuntu. Called ‘Mir‘, the X Window Server replacement is tasked with ‘enabling development of the next generation Unity’. Which, in yet another about-turn, is to be rebuilt in Qt/QML.” It’ll be used for all Ubuntu variants (phone, tablet, desktop), and the first version will be released come May.
Time to die, Ubuntu.
When in doubt, rewrite.
They’ve finally made the right choice of toolkits, but I can’t help but feel they’re being way too scattered about this. Just a couple weeks ago they were recomending everyone use Python and GTK to develop their “apps” and now they’re pulling that rug out again.
If you know you’re going to standardize on Qt, then don’t make major announcements based on a completely different environment just weeks before. For a small company, Canonical sure behaves like a massive one where the left arm doesn’t know what the right is doing.
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.
Well, its more important in mobile where every bit counts with code size since it helps cold boot time.
If I can shave time off of my app startup by loading less code or dependencies then that’s obviously a trade off I’m going to make.
Not that Context Menus add that much more code, but its my philosophy in general. Its also less code to maintain, less XAML to be parsed so you have a simpler visual tree, etc.
Windows Phone deals with the appbar nicely by having the three dots and slightly transparent mini bar “…” hinting that you can swipe up.
Windows 8 offers no hints that there might be an app bar, its hit or miss. maybe there is, maybe there isn’t. Its dumb.
I think its fundamentally the problem right click has though, either its there or the user is burned because he didn’t get gratification for an action.
I opted for a solution where the app bar auto-shows when you select an item, and the buttons in the app bar are contextual. That way there’s no right-click guess work, and it serves the same purpose as a right click menu albeit with a little more mouse travel.
Its hard. Touch and Mouse don’t map 1:1 all the time. To beat this App Bar example to death, while swiping from the bezel is fun and natural with touch, its weird and awkward with a Mouse, and right click (or Ctrl+Z) feels like an afterthought.
Likewise with Right clicking on an item for a context menu vs long pressing for one. They don’t map 1:1 so you either implement one, the other, or both.
I think Windows 8 is good, very good, but they didn’t get this aspect of it quite right. There’s still more than a trivial amount of work to accommodate mouse and keyboard users.
Above I was nitpicking and being specific, but I do get your point in general that there is an overall simplification of everything in UX.
That’s not too bad, and I welcome it, so long as the knobs are still there behind the scenes. Hide it in the registry, a group policy, an obscure control panel applet, whatever, but give me my knobs. Let me tweak things if I want, if I break the warning stickers, let me do what I want.
This is a little less likely on phones because the carrier relationships are fragile, but on tablets, it should be possible and pretty much is, at least on Windows 8 tablets.
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.
Qt, at last!
It’s a very good and natural thing: evolution.
I just hate it when people start screaming: no, nobody else does that, it’s non-conformant, evil, etc etc.
I’d like for the so-called distributions to evolve into independent fully fledged os’es, not just another “distros”.
I.e. just like Android. Nobody calls it a linux distro. And that’s a good thing.
Ubuntu apps, Ubuntu desktop environment, Ubuntu desktop server, Ubuntu operating system. Nice.
And Qt. Couldn’t be a much better example of a match made in heavens.
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.
Does anybody know why they chose the Russian word D 1/4 D,~NEUR?
Maybe they tried to imitate fedora’s ^I>^Iu"I‰^I 1/2 ^I^I'^I±"I‘ naming style?
Edited 2013-03-04 19:23 UTC
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: DoeD,~NEUR, IPA: ["E^m^E^2ir]; 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 “DoeD,~NEUR 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.
But it will not be an easy task.
Qt is improving rapidly, leaving gtk behind. The big argument for gtk has been its natural integration with gnome, but gnome has become fragments to all hell as of late (which saddens me as a gnome 2 lover, but c’est la vie). Unity has been the biggest reason NOT to use Ubuntu for many former fans, and reworking it on new technology (because the issue wasn’t the front end, it was the buginess to be frank) is a good way to fix it. This is a smart move by Canonical.
Now mir on the other hand… This is going to be a real engineering task. I understand the why (see ubuntu phone), but we’ll see just how well the actual implementation is. Best case scenario this becomes what we hoped Wayland would be and all of linux is made better by it. Worst case scenario, this makes development for Ubuntu super specialized so that it becomes more like Android in being a full on fork than a linux distro.
It doesn’t sound good. Why can’t they use Wayland?
Edited 2013-03-04 19:30 UTC
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.
At first I thought this was just another case of NIH from Ubuntu, but after giving it some thought and reading their reasoning, I think it’s a good idea, especially from the security of input events perspective.
https://wiki.ubuntu.com/MirSpec#Motivation_-_Why_Mir.3F
There are problems with X that just aren’t easily addressable because of unforeseen architecture decisions (hot-plug GPU swapping, input events security, etc), hence the perpetual “just around the corner” Wayland. That said, building a display server that can use the Android drivers is a great idea that short-circuits the problem of getting Intel, AMD, Nvidia, and others on-board.
They’re also implementing a rootless X server for backwards compatibility, and it can support Wayland clients if someone feels strongly enough to write the code to support it.
Since Wayland is perpetually 12 months away, and Android’s SurfaceFlinger already has vendor support (better than X.org has even), so we’re not really getting any typical fragmentation problems here.
I’m also a big fan of QML, especially since the Gnome devs went bonker-nuts with Gnome 3 decisions, so pretty excited about that too.
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.
Its a risky move for Canonical, but it also underscores something interesting, they’re a pragmatic and confident company.
Its smart to reuse as much code as possible, but if it runs contrary to your core vision or requirements, and you can make a compelling argument in favor of invoking NIH syndrome, then I don’t see why not.
Sometimes the wheels needs to be reinvented if they’re square.
It also incidentally helps Qt that they’re pooling resources in that direction. Finally, there’s a winner emerging from the pointless and counterproductive toolkit wars, and it will only benefit every app developer as a whole.
If Canonical can beat the Wayland guys to the punch and engineer something that can be slapped onto a mobile OS like X currently is, then they could have a winner on their hands.
Agreed.
Wayland already had an uphill battle convincing people to ditch compatibility and adopt it. Mir takes away a good chunk of the market that would want Wayland and forces toolkit authors to try for yet another backend. Can’t help but conclude the winner is likely X, which remains more functional compared to two competing fledgeling efforts than one. Will be interesting to see where Wayland goes now.
What you forget in your “analysis” is that Wayland developers are the same as X developers..
Wasn’t X.org the thing even die hard Linux fans hated with the fire of nine suns? Someone is developing a replacement for it, in case the Wayland thing doesn’t go anywhere. Why is this bad?
Some could say that the reason Ubuntu didn’t manage to make a dent in the mainstream all these years is because they are passively packaging what upstream sends, without worrying to much about how the final product will behave (how stable it will be, whether it will preserve back compat etc). Here are some examples: The PulseAudio fiasco, the constant X.org breakages caused from bundling new versions of X.org without proper testing because “that’s what upstream sent” etcetcera. Essentially, Canonical is trying to do an open source Quartz which will replace the broken and older-than-most-people-here X.org. Why is that bad?
Edited 2013-03-05 12:31 UTC
Actually, X got pretty good once the community forked XFree86 and told them to go fuck themselves. Xorg has actually been pretty good.
Since “the community” hasn’t managed to replace X.org even when it was high time, and since “the community” gave us Gnome 3, does anybody feel bad about that?
Sometimes, too many cooks do spoil the food, and sometimes being able to choose between 4 competing audio systems and a dozen of GUIs isn’t for the best.
Get over it folks. There wilk be a schism between consumer/mainstream linux and hobbyist linux. And maybe it will be for the best.
No. It has a broken DRI/DRM system that Nvidia had to replace in their closed drivers so that they can get support for things like pbuffer and off-screen rendering that are neccessary for the recent versions of OpenGL so that they can provide the only GPU driver that really works. Yes, people, what looks like an ordinary driver actually replaces the bottom third of X.org.
And what happened to the open source ATI drivers? Despite ATI opening their specs, the community still hasn’t managed to make a working driver with full support for the recent versiond of OpenGL, because this requires rewriting a significant part of X.org. Aka X.org is like the days of DOS, requiring driver writters to essentially rewritte parts of the OS, like Nvidia did for their closed drivers.
X.org doesn’t need to just be a bit better than Xfree86. It needs to be scrapped.
Edited 2013-03-06 14:12 UTC