Linked by Thom Holwerda on Mon 4th Mar 2013 18:26 UTC
Ubuntu, Kubuntu, Xubuntu "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.
Order by: Score:
v Oh no, not yet another standard
by No it isnt on Mon 4th Mar 2013 18:30 UTC
Finally
by leos on Mon 4th Mar 2013 18:31 UTC
leos
Member since:
2005-09-21

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.

Reply Score: 10

RE: Finally
by No it isnt on Mon 4th Mar 2013 18:44 UTC in reply to "Finally"
No it isnt Member since:
2005-11-14

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

Reply Score: 2

RE: Finally
by WorknMan on Mon 4th Mar 2013 19:11 UTC in reply to "Finally"
WorknMan Member since:
2005-11-13

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.


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

Reply Score: 7

RE[2]: Finally
by Nelson on Mon 4th Mar 2013 20:20 UTC in reply to "RE: Finally"
Nelson Member since:
2005-11-29

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.

Reply Score: 5

RE[3]: Finally
by WorknMan on Tue 5th Mar 2013 01:36 UTC in reply to "RE[2]: Finally"
WorknMan Member since:
2005-11-13

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.

Reply Score: 4

RE[4]: Finally
by Nelson on Tue 5th Mar 2013 02:00 UTC in reply to "RE[3]: Finally"
Nelson Member since:
2005-11-29


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?


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.


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.


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.

Reply Score: 3

RE[5]: Finally
by WorknMan on Tue 5th Mar 2013 05:57 UTC in reply to "RE[4]: Finally"
WorknMan Member since:
2005-11-13

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

Reply Score: 4

RE[6]: Finally
by Nelson on Tue 5th Mar 2013 06:32 UTC in reply to "RE[5]: Finally"
Nelson Member since:
2005-11-29


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.


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.


Personally, I hope they continue to improve it and make Metro in Windows 9 something that is actually usable.


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.


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.


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.

Reply Score: 3

RE[7]: Finally
by WorknMan on Tue 5th Mar 2013 08:32 UTC in reply to "RE[6]: Finally"
WorknMan Member since:
2005-11-13

Right Mouse buttons have never been particularly discoverable, in my own analytics


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.

Reply Score: 2

RE: Finally
by Soulbender on Tue 5th Mar 2013 04:16 UTC in reply to "Finally"
Soulbender Member since:
2005-08-18

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


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

Reply Score: 5

RE[2]: Finally
by TechGeek on Tue 5th Mar 2013 05:28 UTC in reply to "RE: Finally"
TechGeek Member since:
2006-01-14

"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


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.

Reply Score: 2

Qt!
by piotr.dobrogost on Mon 4th Mar 2013 18:38 UTC
piotr.dobrogost
Member since:
2011-10-04

Qt, at last!

Reply Score: 9

rimzi
Member since:
2009-12-17

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.

Reply Score: 7

r_a_trip Member since:
2005-07-06


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.

Reply Score: 3

dsmogor Member since:
2005-09-01

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.

Reply Score: 2

r_a_trip Member since:
2005-07-06

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

Reply Score: 3

dsmogor Member since:
2005-09-01

Just wiser that community driven desktop is an utopia.

Reply Score: 2

r_a_trip Member since:
2005-07-06

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.

Reply Score: 3

мир
by frajo on Mon 4th Mar 2013 19:21 UTC
frajo
Member since:
2007-06-29

Does anybody know why they chose the Russian word ΠΌΠΈΡ€?
Maybe they tried to imitate fedora's ΛΡωνίδας naming style?

Edited 2013-03-04 19:23 UTC

Reply Score: 1

RE: Mir
by frajo on Mon 4th Mar 2013 19:24 UTC in reply to "мир"
frajo Member since:
2007-06-29

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

Reply Score: 1

Re: Mir
by jessesmith on Mon 4th Mar 2013 22:53 UTC in reply to "мир"
jessesmith Member since:
2010-03-11

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.

Reply Score: 6

RE: ми�
by prokoudine on Tue 5th Mar 2013 00:01 UTC in reply to "мир"
prokoudine Member since:
2005-08-09

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

Reply Score: 2

bhhenry Member since:
2005-07-06

"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.)

Reply Score: 2

zima Member since:
2005-07-06

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.

Reply Score: 3

RE: ми�
by Lobotomik on Tue 5th Mar 2013 11:10 UTC in reply to "мир"
Lobotomik Member since:
2006-01-03

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.

Reply Score: 3

JAlexoid Member since:
2009-05-19

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.

Reply Score: 4

Really cool if Canonical can pull it off
by nej_simon on Mon 4th Mar 2013 19:24 UTC
nej_simon
Member since:
2011-02-11

But it will not be an easy task.

Reply Score: 3

Qt was smart move. We'll see about Mir
by andrewclunn on Mon 4th Mar 2013 19:25 UTC
andrewclunn
Member since:
2012-11-05

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.

Reply Score: 4

Comment by shmerl
by shmerl on Mon 4th Mar 2013 19:29 UTC
shmerl
Member since:
2010-06-08

It doesn't sound good. Why can't they use Wayland?

Edited 2013-03-04 19:30 UTC

Reply Score: 3

RE: Comment by shmerl
by fran on Mon 4th Mar 2013 20:31 UTC in reply to "Comment by shmerl"
fran Member since:
2010-08-06

It doesn't sound good. Why can't they use Wayland?


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

Reply Score: 3

RE[2]: Comment by shmerl
by shmerl on Mon 4th Mar 2013 20:38 UTC in reply to "RE: Comment by shmerl"
shmerl Member since:
2010-06-08

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.

Reply Score: 3

RE[2]: Comment by shmerl
by shmerl on Tue 5th Mar 2013 01:52 UTC in reply to "RE: Comment by shmerl"
shmerl Member since:
2010-06-08

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

Reply Score: 5

RE[3]: Comment by shmerl
by cyrilleberger on Tue 5th Mar 2013 07:59 UTC in reply to "RE[2]: Comment by shmerl"
cyrilleberger Member since:
2006-02-01

Wayland / X.org developers take on this:

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.

Reply Score: 3

NIH Syndrome!
by intangible on Mon 4th Mar 2013 19:55 UTC
intangible
Member since:
2005-07-06

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.

Reply Score: 9

RE: NIH Syndrome!
by shmerl on Mon 4th Mar 2013 20:17 UTC in reply to "NIH Syndrome!"
shmerl Member since:
2010-06-08

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

Reply Score: 2

RE[2]: NIH Syndrome!
by intangible on Mon 4th Mar 2013 20:22 UTC in reply to "RE: NIH Syndrome!"
intangible Member since:
2005-07-06

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

Reply Score: 4

RE[2]: NIH Syndrome!
by Nelson on Mon 4th Mar 2013 20:23 UTC in reply to "RE: NIH Syndrome!"
Nelson Member since:
2005-11-29

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.

Reply Score: 2

RE[3]: NIH Syndrome!
by shmerl on Mon 4th Mar 2013 20:27 UTC in reply to "RE[2]: NIH Syndrome!"
shmerl Member since:
2010-06-08

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

Reply Score: 4

RE[4]: NIH Syndrome!
by Nelson on Mon 4th Mar 2013 20:43 UTC in reply to "RE[3]: NIH Syndrome!"
Nelson Member since:
2005-11-29

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


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.


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


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.


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.


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


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.


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.

Reply Score: 2

RE[5]: NIH Syndrome!
by shmerl on Mon 4th Mar 2013 20:48 UTC in reply to "RE[4]: NIH Syndrome!"
shmerl Member since:
2010-06-08

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

Reply Score: 3

RE[6]: NIH Syndrome!
by Nelson on Mon 4th Mar 2013 21:06 UTC in reply to "RE[5]: NIH Syndrome!"
Nelson Member since:
2005-11-29

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)

Reply Score: 3

RE[4]: NIH Syndrome!
by Soulbender on Tue 5th Mar 2013 04:22 UTC in reply to "RE[3]: NIH Syndrome!"
Soulbender Member since:
2005-08-18

It's called competition. Deal with it.

Reply Score: 2

RE[4]: NIH Syndrome!
by Soulbender on Tue 5th Mar 2013 04:27 UTC in reply to "RE[3]: NIH Syndrome!"
Soulbender Member since:
2005-08-18

it will create totally unnecessary and very sick competition for drivers including on the desktop


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?

Reply Score: 3

RE[5]: NIH Syndrome!
by shmerl on Tue 5th Mar 2013 04:33 UTC in reply to "RE[4]: NIH Syndrome!"
shmerl Member since:
2010-06-08

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.

Reply Score: 2

Risky
by Nelson on Mon 4th Mar 2013 20:28 UTC
Nelson
Member since:
2005-11-29

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.

Reply Score: 8

RE: Risky
by backdoc on Mon 4th Mar 2013 21:30 UTC in reply to "Risky"
backdoc Member since:
2006-01-14

Agreed.

Reply Score: 2

Win for X?
by malxau on Mon 4th Mar 2013 22:58 UTC
malxau
Member since:
2005-12-04

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.

Reply Score: 2

RE: Win for X?
by renox on Tue 5th Mar 2013 12:11 UTC in reply to "Win for X?"
renox Member since:
2005-07-06

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

Reply Score: 2

Re:
by kurkosdr on Tue 5th Mar 2013 12:25 UTC
kurkosdr
Member since:
2011-04-11

When in doubt, rewrite.


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?

They should stick to what they do best, which is to repackage other people's work, and not try to fork the Linux desktop.

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

Reply Score: 3

RE: Re:
by the_trapper on Tue 5th Mar 2013 23:18 UTC in reply to "Re:"
the_trapper Member since:
2005-07-07

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

Reply Score: 3

Re:
by kurkosdr on Tue 5th Mar 2013 19:42 UTC
kurkosdr
Member since:
2011-04-11

Just wiser that community driven desktop isan utopia.


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.

Reply Score: 1

Re:
by kurkosdr on Wed 6th Mar 2013 14:10 UTC
kurkosdr
Member since:
2011-04-11

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


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

Reply Score: 1