This weekend I read a blog post by Robert Ancell from Canonical claiming that the display server doesn’t matter . To quote the direct message:
The result of this is the display server doesn’t matter much to applications because we have pretty good toolkits that already hide all this information from us.
Now I don’t know how to put it, the best description is that I’m shocked that Canonical is still not seeing the problems they created by having multiple display servers. I do not know how much experience Robert has with making applications work with multiple display servers, but I at least have this experience as shown in my blog post on making KF5 not crash on Wayland. Granted in this blog post I write that “basically if your application compiles on frameworks it will run on Wayland out of the box”. But that is a strong simplification of the issues which can be present.
With this blog post I will prove Robert’s claim that the display server doesn’t matter due to the toolkit wrong by contradiction. I could just stop here, because I already wrote that KF5 applications were crashing on Wayland prior to me starting to fix these issues. If the toolkit would just abstract away all the display server differences our applications libraries would not have crashed.
Also the assumption that the toolkit behaves the same is just wrong. One of the issues I fixed was Qt returning a nullptr from QClipboard::mimeData on platform Wayland while it returned a valid pointer on all other platforms. It’s obviously an application bug but the documentation doesn’t say that there could be nullptr returned or not. There can be hundreds or thousands of such small behavior differences. An application developer is not able to ensure that the application is working correctly on a distro-specific display server. If the application developer recieves a crash report for such an issue, the developer cannot reproduce the issue – not even on running the same distro with another DE – cannot write a failing unit test, cannot integrate it into the CI system. The most sane thing he could do is declaring that proprietary display server as unsupported. And this should show the problem: each developer will see issues caused by Mir – it doesn’t matter whether it’s in the toolkit, application libraries or in the application itself. Thus an application developer will have to care about the display server. The applications will have to decide whether they want to support Ubuntu.
Another example is different behavior. Look at this screenshot:
 |
| Aus Weston |
This is the KColorDialog running on Wayland and when I click the pick color button nothing happens and the debug output just says: “This plugin does not support grabbing the keyboard”. It uses QWidget::grabKeyboard – functionality provided by the toolkit. Again the documentation does not tell that it’s not supported on all platforms, it also doesn’t offer API hooks to figure out whether grab is supported. What will be a possible fix for this?
#if Q_OS_LINUX
if (!QX11Info::isPlatformX11()) {
colorPickButton->hide();
}
#endif
We just hide the button if we are building for Linux but are not on X11. Why is that wrong? Well what if other platforms still support it. So a better way?
#if Q_OS_LINUX
if (QGuiApplication::platformName().toLower().contains(QStringLiteral("wayland"))) {
colorPickButton->hide();
}
#endif
It’s better, it only hides it for Wayland. But what if the same feature is also not supported on Mir? How should a developer find out to fix that problem properly? How does a developer figure out what the platformName for Mir is? The documentation doesn’t know anything about Mir, the Qt sources (yes I have them on my system) don’t know anything about it. How long will it take till a user reports that the button is broken? Will the user tell that it’s Mir and not a normal system? After all our bug reporting tool reports “Ubuntu” for both Ubuntu and Kubuntu. And on Kubuntu, which the dev might be running, it’s working just fine.
Another example from a patch I prepared to fix an issue:
#if HAVE_X11
d->display = qgetenv("DISPLAY");
+ if (d->display.isEmpty()) {
+ // maybe we are on Wayland?
+ d->display = qgetenv("WAYLAND_DISPLAY");
+ if (!d->display.isEmpty()) {
+ // don't go into the xauth code path
+ return;
+ }
+ }
#else
Now will that code work with Mir given the way it is written? Obviously not. Could I have fixed it? Obviously not, because I have no idea whether Mir has a system like these env variables. What will happen if someone tries to fix it for Mir? I expect the maintainers to tell that this doesn’t scale and needs to be reworked. For two it’s a solution to just test one after the other, but with three systems it doesn’t scale any more. It becomes too complex. So yes the maintainer of this application library has to care about the fact that there are multiple Display Servers.
In summary: Canonical created a huge problem by introducing another Display Server and it’s affecting all of us and they are still in denial state. It’s not a simple the toolkit will solve it. It can cause issues everywhere and that affects the development and maintenance costs of all applications. My recommendation to application developers is to never accept patches for this mess Canonical created. If they want that fixed, they should do it in their downstream patches. Distro specific problems need to be fixed in the distros. I certainly will not accept patches for the frameworks and applications I maintain. This is not for political reasons as it’s so often claimed, but for technical, because I cannot test the patches (Mir not available on Debian) and our CI system cannot build it.
I have noticed a mistake in third paragraph. You wrote ‘With this blog post I will proof’, but it should be ‘With this blog post I will prove’.
Other than that, great post! Keep up the good work.
thanks, updated
Not saying anything about that whole Mir thing, but you do realise that these “technical reasons” are just plain bad API?
Instead of complaining about Qt having incomplete documentation and missing error handling, you put the burden on Mir. Sure, I can see how support for Mir makes your life as a programmer more complicated. But the same holds true for wayland – after all you still have the check for wayland in your code that requires the same ugly workarounds as the Mir code does.
I honestly couldn’t care less if Mir is supported or not, but in this case the blame is really on Qt (as much as I love Qt otherwise).
no, the blame is not on Qt and it’s not trying to add blame to Qt. The aim of the post was to show that the claim is false.
I get that you don’t want to blame Qt and prefer to blame Mir instead. But Johannes and I do blame Qt for this (note that I am not a Canonical fanboi and I actually do not understand the necessity for Mir). The examples that you gave (QClipboard::mimeData returning a nullptr on Wayland but returning a valid pointer everywhere else, and QWidget::grabKeyboard not working on Wayland but working everywhere else) are obvious bugs in Qt. Either Qt’s Wayland support should implement these features correctly, or the Qt documentation should clearly state that using these functions doesn’t guarantee success and then Qt should provide a way to test for success. It is a bug in Qt that the app developer has to produce distorted “if” statements for functionality that supposedly is implemented in the toolkit. If you do not see that having such a terrible “if” each time QWidget::grabKeyboard is used in a KDE library or Qt application is a problem, then I start having serious doubts about the maintainability of the KDE Frameworks code. I sincerely hope that the KDE Frameworks code is not littered with such ugliness (or at least is hidden in a function isGrabKeyboardEnabled(), my point is that this function should be a member of QWidget) and that it is simply your hate against Mir which makes you blind for the real problem here. Qt is supposed to be a cross-platform toolkit after all and such ugly “if” statements do not contribute to the “Code less, create more” mantra.
If your point is that such bugs in Qt may appear for Mir too and users will blame the application developer instead of the real culprit, and that app developers shouldn’t have to deal with such bugs, then I agree.
Furthermore, this blog post contradicts a point made in a comment in one of your previous blog posts that the user shouldn’t see any difference when switching from X to Wayland. If the color dialog loses its pick color button, then I see a difference (and I don’t like it).
In the last paragraph above I refer to this comment.
Very good points. It’s amazing how QT supports so many different diverse platforms*, but when Canonical builds a new display server, it’s “OMG what about all of the QT bugs this will expose!? Platform diversity is wrong! There can be only one!”
* Windows, Windows Embedded, X11, Mac OS X, Android, DirectFB, EGLFS, KMS, Wayland, QNX, VxWorks, Integrity, iOS, BlackBerry, Sailfish, WinRT, Tizen
I had the same thought. QT is now supporting Android and I didnt see anybody complaining about Android has another display server.
Actually I do, I would love to see Android using Wayland instead of SurfaceFlinger
Let’s assume, Qt introduces an API isGrabKeyboardEnabled. Still applications need to use this API, which is currently not the case, so they fail on wayland, but work on X
So Martin found missing functionality in Qt, but adding this to Qt does not change existing application code
You are right. But my point is: if Qt introduces QWidget::isGrabKeyboardEnabled, then the applications have to introduce it in their code only once (to make it work with Wayland) and then the application’s code will work for any display server that may be introduced in the future (Mir, …) without further modifications.
It doesn’t fix the point which I wanted to raise: it needs adjustments in the application and it needs the applications to be aware of the problem in the first place (which is honestly rather unlikely).
The applications are not aware of the problem because the Qt doc doesn’t give any indication that there might be a problem. I agree that adding a display server may cause the need for modifications, but so does adding an OS. If some new fancy Chinese OS appears and it becomes widely used and Qt is ported to that and it does not support QWidget::grabKeyboard either, then we have exactly the same problem. The purpose of a cross-platform toolkit is to minimize such problems, so the point that the display server doesn’t matter much to application developers should be valid. At least it shouldn’t matter more than the OS. If this isn’t the case, then this is a shortcoming of the toolkit and/or its documentation.
Furthermore, the last paragraph of your blog post blames Mir for this mess, but your examples show that this mess is actually already visible with Wayland. The mess is caused by Qt which assumes that QWidget::grabKeyboard always works. Once this problem is attended to in a cross-platform way (e.g. by adding QWidget::isGrabKeyboardEnabled and by modifying the applications), then the problem is solved forever and then Canonical can create 1000 display servers without ever breaking the application’s code again.
Personally, I have no need for Mir and I dislike it for all the reasons that are already mentioned in the other comments on this blog post. But I think that we should be honest and not blame Mir for problems in the Qt toolkit.
The point of my blog post was to show that Robert’s statement that it doesn’t matter is wrong. Yes in a perfect world, apps would not need to be adjusted. But we don’t live in it and even the fixes to the docs or introduction of new methods in the API will fix the applications which are out there right now.
It could be argued that the claim is temporarily false because of flaws in the toolkits. The solution to this problem is not to test for every single specific DE, but rather to add a feature to the toolkit that allows you to check if a feature is available. It would be the toolkits responsibility to know the DE.
Of course, I can think of very few instances where the differences in features between display servers should be very important to the application, but when it is, that test should be added to the toolkit.
This would not fix any of the three issues I highlighted. It’s completely irrelevant whether the toolkit has flaws or not. Fixing flaws doesn’t make the application use new API not needed before and also doesn’t fix bugs which get exposed by other code paths.
Where the blame lies is irrelevant. The question is whether the display server matters. It does.
AFAICS the display server matters as much as it matters that you are writing code for Windows instead of for Linux: some functionality may be available or not, but the fact that it may be unavailable is clearly documented and there are ways to test the availability of the functionality. In the QWidget::grabKeyboard example, the Qt doc should say that it is not available on every platform and there should be a QWidget::isGrabKeyboardEnabled function. Since both are lacking, I consider this as a bug in Qt. Note that my reasoning holds independently of the fact that we are talking about different display servers instead of different OSes.
That doesn’t change the fundamental problem: what Robert said is factually incorrect. The display server does matter. Using a toolkit will not change this.
Whether it should change this is another question, but developers have to deal with the real world, not the world they would like.
That is of course true, but then you could also argue that having more display servers around makes it easier to find flaws in the toolkits. Because the display server _shouldn’t_ matter. The fact that we have bugs right now, should not be used as an argument to make the situation permanent.
That’s true, but he is not trying to prove Mir is the problem here (Mir is faulty for being created after an equivalent alternative was already there, without convincent technical reasons, but for nothing else), but that it is not true that the display server doesn’t matter and toolkits are the panacea that will fix human kind and release us from the dark ages. That’s an idealisation that goes too far, and Martin proved it without flaw. The point is, Robert seems to be expecting Qt and the other toolkits to deal with the mess Canonical created. This is an extra burden for them, an unsolicited burden, and the ones paying the consequences are likely to be them, the app makers, etc.
The mess is not created by Canonical. The mess is already visible in Wayland, as Martin’s examples show. The mess is created by Qt which assumes that all functionality is always present, when reality shows that this is not true. The reason why there is an extra burden on the app makers that is harder than a simple “if” or “#ifdef” statement, is because Qt assumes that Linux has only one display server, namely X. There are for example no such assumptions for Mac, as the existence of the macros Q_OS_DARWIN, Q_OS_MAC, Q_OS_IOS, …shows. Why can many Mac versions be supported by Qt but only one Linux version? So the mess uncovered by Wayland should be solved in Qt (and somehow Mir didn’t even come into the picture yet).
The mess is created by the simple fact that everyone has always assumed that a desktop GNU+Linux system runs X, so the toolkits doesn’t have tools to check for differences, which is completely understandable. It is something that should be fixed.
The biggest problem with Mir, along with all of these issues, comes from the fact that its one of a kind, and ONLY supported by Canonical’s Ubuntu. No other distro wants it, or will use it. Even other flavours of Ubuntu (kubuntu, xubuntu, etc.) even say that they will run Wayland/Weston, and will not use Mir.
That should say it all; the whole Linux community of super-users and developers are all rejecting it, and Ubuntu will alienate itself from the community, just like when it switched to Unity (a touch interface for non-touch devices? jeez).
Mir will fall by the wayside, and honestly, they have pushed the release date back more and more over the last year, and now its not even supposed to ship with a distro until 2015? Bet 10 bucks that they will push it back again and again.
If they would have got behind Wayland instead of creating proprietary code and giving it to us like we should be thankful, Wayland would probably be a lot closer to “done”, so to speak.
Unity and Gnome Shell was not intended to be a touch interfaces when they arrived on the desktop. I don’t understand where that rumour comes from. I don’t see it at all. And particularly wrt Unity; why would it be so very good at keyboard control if it was primarily intended to use on a device that didn’t have a keyboard? That’s completely nonsense. The first Unity touch interface arrived years after the first Unity desktop interface.
One of the issues I fixed was
The link in that part doesn’t work (should be absolute instead of relative).
thanks, fixed.
I totally agree with you!
Thanks Martin, great rebuttal, much appreciated.
As a technical outsider looking in at all the X11/Wayland/Mir hand waving and debates I value most the perspectives of those few who are actually working and coding in the technical details. Thanks for taking the time to share your knowledge.
I stopped at “the developers should think about supporting also ubuntu or not”. You shall see that the question will be ” shall we support things that ARE NOT ubuntu or not.” You are making sentences that do not make sense in light of current and future market share projections.
and that’s why SteamOS uses Debian and not Ubuntu, right?
wrong.
SteamOS chose Debian over (initiailly attempted) Ubuntu over licensing issues.
I don’t get your “wrong”. If Ubuntu would have been so more important Valve and Canonical would have figured out a way.
It seems kind of obvious to me that Valve chose Debian for the same reasons that Ubuntu chose Debian. I haven’t seen any statements from Valve claiming that it was about licencing or anything like that. Well, there was a blog post on OMG!Ubuntu, which was very easy to disprove as a case of bad Google Translating.
Many major open source vendors have already stepped into the Wayland wagon. For them the question will only be “should we support Ubuntu” because the other option is already somewhat close to being implemented.
Sure, I can see why the commercial vendors could feel a tad differently about it. Though at the moment it seems that the first big wave of commercial stuff arriving to Linux will be games and I’ve no idea how much work it would be to wrap the OpenGL-based engine inside a display server -specific window. (Which would be the most basic form of support needed to run the games.)
I thought the point of Wayland was that the program wouldn’t have to care (i.e. that it could just render graphics and push them to a buffer for the compositor to pick up and ultimately display however it and/or the user desires)? Wouldn’t it then be “simple” (nothing’s simple when programming…) to wrap that with X or Mir or SurfaceFlinger or rio or SuperDuperDisplayServer4000 windows providing their own Wayland “compositors”?
the sdl included into the steam runtime sdk has both mir and wayland support, you code against it (it’s really impractical to do otherwise) so there is no problem there.
And yes, i am speaking from a commercial standpoint. And also, i shall remember you that steam has official support only for ubuntu, outside his own steamos. I am not a big fan of this mir madness, dont’ get me wrong. It’s just that we are going to see a clear split between OSS systems and ubuntu, somewhat like a mach/bsd /macos split , and we need to do something about it or it will be like” commercial and proprietary on ubuntu, foss on the other side”
Hi Martin,
Why do you respond again to them? Don’t you see it’s just provocation? Let them say…
Thank you for your work.
Because I think it’s important to point out such incorrect claims. People tend to believe it and that there are no problems. We need to show both sides. Thus I provided the other side. People have now both sides and can do their own judgement.
Also to have simplified application packaging and make it easier for maintainers we should eradicated distributions and leave one true distribution. Sounds like a plan?
well having just one format would simplify a lot, wouldn’t it?
No, it wouldn’t. Because toolkits needs to support other desktops in any case. Creating good ways to handle exceptions is what will make things easier. This is what they’ve chosen to do in HTML, for exactly that reason; it no longer makes any sense to assume that web devs can handle differences in every version of every browser. Instead, you’re now supposed to check for _features_. That makes things easier.
Having more display servers is a good thing as long as you can properly handle the differences. That’s the issue.
Are we possibly reaching the point where us, the developers, would just stop caring what Canonical does? Do you think this would make them come to their senses, or do they already have to big of a userbase for us developers to simply ignore?
I can perfectly understand that you won’t try to support Mir yourself (I wouldn’t either!), but if Ubuntu developers send patches to you that add such support, and if those look acceptable, you should accept them, and not reject them merely because they have “Mir” in them.
I also agree with Johannes Zarl and “anonymity is great” that checking for platforms by name is very broken and there should be a feature-test function somewhere instead. In the worst case, something like KPlatformInfo::isGrabbingSupported that checks for X11, Wayland and maybe Mir explicitly. But I also agree that this really belongs into Qt (and the information should come from the platform backend/plugin, which knows whether it implements that feature).
It isn’t a matter of it being “Mir”, it is a matter of it being platform-specific. If he is going to accept code, he needs to be able to check whether the code actually works. He can’t do that with Mir.
Testing the code is the job of those who care about Mir support. If they say it works, you’ll have to take their word for it. It is just not possible to test on every possible and imaginable target platform, that does not mean you shouldn’t allow your code to work on those platforms if the people who actually care send you the patches to make it work. This is no different from support for things such as the SunPRO compilers which is also tested by a handful developers at most.
I beg to disagree as I consider it as the task of the maintainer to ensure that it works and continues to work. Thus accepting a patch means the maintainer is willing to fix bugs arising in future. If there’s a team like in the Windows case which is responsible, the situation is different.
If you’re a toolkit developer targeting a desktop you don’t have access to, then you’re doing something very wrong. Yes, there are bugs in the toolkits right now, because the situation of having lots of different display servers is a very new one. It needs to be handled properly. After all; Qt supports OS X, Win32, WinRT, Android, X, Mir and Wayland.
Would you really want to perform all those tests for every single platform in your app? You wouldn’t. Mir doesn’t change this situation at all.
At least KDE has developer teams working on different platforms and there are certainly KDE application developers who test their applications on all supported platforms (right now for KDElibs4 based applications thats X11, Windows and MacOS). Yes I think it’s safe to assume that developers will continue to test the apps they ship on a platform, thus Mir increases the work load.
Where’s our CI for it? I’m not going to add patches for code which cannot be put under CI. I would do a bad job as a maintainer if I would allow that. And that’s quite a technical reason, isn’t it?
Anyway it’s hypothetical, there are no patches. Once there are we can look into it.
I am just wondering how one may stand up and complain now about Linux vs GNU/Hurd vs. BSD or Apache HTTPd vs Lighttpd vs Nginx. They all share a common use, but are by far not compatible to the upper layer. I kind of get what you’re trying to say, but for me, it’s just a layer with two different (more or less) incompatible interfaces that the upper layers however can adapt to. True, with an additional effort, but still, between the display server and the app is still the toolkit, that – for the casual applications – abstracts away the most of them. 🙂
Just wondering,
how many people work on Kwin?
how many kwin contributors share your views against Mir?
If another kwin developers decides to start mainting Mir specifc code paths,will that be ok? why/why not?
You seem to speak very authoritatively on what code gets in or not.Are you to Kwin what linus is to linux in terms of what code gets into the mainline tree?
Its kind of concerning to have someone in high places speak very forcefully against one project simply because the project is in competition with their their choice.To speak against it is one thing,to take deliberate steps like refusing patches even when you will not be responsible for them is very troubling.
So far I have not refused any Mir patch because they don’t exist. This post btw. was not about KWin, so your questions are rather irrelevant and well Google will answer most of your questions. For example I mentioned in my blog posts in the past about Mir that no KWin developer to my knowledge is using Ubuntu.
True,to this post,the kwin questions are irrelevant but i always get these questions when i read your posts that make very strong and authoritative statements.Perhaps,i should reask them next time when Kwin/Wayland/Mir is the topic discussed.
Google works when one knows what to google about.If you prefer not to answer my questions,i hope somebody else will be allowed to chip in and answer them as i have so far been unable to find answers for them.
I was having the same thoughts about the refusal. What if someone stands up and would like to support Mir with all good intent to get more userbase for KWin.
Mir patches won’t make it possible to get more userbase for KWin. It’s not possible to replace the Unity shell and everywhere else there’s Wayland or Xorg.
Could you at least spell our name right?
Thanks, fixed
Years back it was decided X11 needs to be replaced and nobody achieved that until this day. When somebody has something i can test/use then i will have opinion again if it is suitable as X11 replacement or not.
We are still far from that day!
And i forgot to mention something i seen and heard few years back when Wayland project was born. I watched presentation video where it was said toolkits indeed will take over substantial amount of functionality and Wayland will not try to mess with that because that is toolkits job.
If that is true then Ancell does have a point.
I think many people here has confused the message Martin was intended to tell.
he says that toolkit carry many swtuff but for many reasons (QT’s bugs, or any kind of case) many apps are ging to have troubles, so apps developers does care about the display server, because toolkits hardly can deal and prevent the whole scope of cases, such niche caces must be treated downstream. so, when you have many display servers to maintain in the same plataform you must spend more time (and maybe money) maintaining everything, all of this for no benefist. more work to have the same. that is the problem and that is specially true when we are talking about companies that only worry about money, so for example privative drivers are only be available on one plataform or are not gonna be as good as they could be.
exactly!
I agree with the idea that display server matter and Martin prooved it: there are some differences that in fine change the application behavior.
But I don’t agree when someone is saying that this should be fixed downstream! These subtles functionning differences between display servers should be handle in the toolkit! It’s its very job and goal.
What wayland AND mir will do is only reaveals pre-existing flaws in whatever toolkit is used in their way of implementing a multi-platform API. Fix these flaws in the toolkit upstream will make it stronger for the future and some hypothetical new display server to come.
So in that thought, I agree with “anonymity is great” saying that it should be fixed in the toolkit. How? That’s a question that the tookit maintainers and developpers should ask themselves. Maybe that there is a clever fix than QWidget::isGrabKeyboardEnabled?
If the Qt people decides that Qt should support Mir, then Qt must implement all of the documented behavior. The same way that there are different behaviors for some functionality on Windows, I see this as totally acceptable on Mir as long as this behavior is documented too. Then it becomes an application maintainer issue.
But if Qt decides that Mir support should not be added to the framework, then you can use it by your own risk, and do not complain when something go wrong.
I believe this somewhat restrict the options for the KDE people, since if Qt people decides not to support Mir, KDE is left with not so many options.
I don’t know what is the official position of the Qt board/developers about this.
Anyway, I couldn’t care less about Mir. I recently (3 weeks ago) installed Ubuntu in my notebook and I’m formatting it again because of speed issues, stability issues, screen handling issues and a lot of terribly implemented features. The only advantage I’ve seen so far is that it took me less then 15 minutes to get my notebook working.
Hope I made some sense… my english is so poor…. ;D
The display server shouldn’t matter, but in practice it does matter. The toolkits/frameworks should hide the display server from the applications, but support for some display servers is work in progress. Creating another display server means more work for toolkit/framework developers. Is that a fair summary?
no, that’s not what my blog post was about. It’s about that the toolkit cannot hide all differences and that it’s not just about the toolkits. It’s stressing different code paths which can result in bugs (see the missing nullptr check in my first example) or it needs code which cannot be in the toolkit (my diff example) and so on. This post was really not about the toolkit being incomplete, that’s how some persons wanted to read it 😉
I think everyone is essentially ignoring what Canonical is really trying to do. They are trying to be the Apple of Linux and want to create a mobile App Store situation where they can generate revenue from sales of hundreds of thousands of NEW apps written in their new scripting framework. They are not trying to create a new desktop. This is a mobile play. The desktop is entirely secondary. Desktop applications don’t work on mobile anyway, so if Rhythmbox doesn’t work on Mir they don’t care. They want NEW apps because then they can charge for them. The delay for Mir on the desktop will essentially become infinite. All they want to do at some point is allow the mobile apps to scale to a larger screen when you dock your Ubuntu phone.
I have seen various articles and comments which basically say: “Shame on Canonical for trying to profit from Linux.” Then I see other articles which basically say: “Ubuntu will die because Canonical cannot turn a profit.”
http://www.internetnews.com/blog/skerner/canonical-ubuntu-linux-is-still-not-profitable.html
http://www.devside.net/articles/ubuntu-linux-dying
In some ways I think that Linux development efforts are wasted if the product of those efforts is not embraced by the masses. In order for this to occur, desktop Linux must become available on new hardware sold by the major retailers. I suppose there are some reasonable arguments on both sides of the display server debate, but the fact remains that nobody is working as hard as Canonical to make desktop Linux accessible to people with limited technical knowledge who would never attempt to install an operating system. Those people represent the vast majority of the hardware market and you must cater to their needs if you want the concept of open source to succeed. A popular platform attracts more developers (which in turn attracts more users).
“All they want to do at some point is allow the mobile apps to scale to a larger screen when you dock your Ubuntu phone.”
That is not correct: In the following video clip, they clearly express an intent to support desktop applications on phones when the phone is paired with a large screen and keyboard. A tablet would also serve the same purpose.
http://www.youtube.com/watch?v=h384z7Ph0gU#t=303
In my opinion, NetBSD might be more suited to this role because the OS and the apps are more easily ported to different CPU architectures, but the nature of the BSD license could be discouraging developers from contributing to the project. In any case, the focus right now seems to be on debate, and I wonder if it would be a worthwhile exercise to hold some kind of developer’s congress which focuses on trying to establish a consensus instead, because open source operating systems will never become a popular alternative to proprietary operating systems without a greater degree of cooperation.
“The delay for Mir on the desktop will essentially become infinite.”
The delay for desktop Linux to ship on hardware that can be purchased in retail stores is already infinite, and this is what I believe Canonical is trying to change. We can debate their methods infinitely too, and sometimes they may be deserving of criticism, but the primary focus must shift from debate to cooperation if we want to see desktop Linux succeed in the marketplace. I cannot say whether Mir is the best solution, but I can say that desktop Linux will never be a commercial success if we cannot present a standardized software platform and app ecosystem to the general public. If Canonical does not lead the way, who will?
“I think everyone is essentially ignoring what Canonical is really trying to do.”
Yes, they are ignoring the fact that Canonical is trying to make Linux popular by creating a standardized platform that appeals to the general public (which does not want to be forced to use the Terminal, or install apps from packages found on the web.)
They are trying to be the Apple of Linux and want to create a mobile App Store situation where they can generate revenue from sales of hundreds of thousands of NEW apps written in their new scripting framework.
How else would you propose to fund the rapid development of a standardized open source platform which the public will embrace as a practical alternative to proprietary solutions? At least Ubuntu will not be restricted to Canonical’s app store.