Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Riddell: Kubuntu Won't be Switching to Mir or XMir
Posted Jun 27, 2013 23:54 UTC (Thu) by maxiaojun (subscriber, #91482)
Posted Jun 28, 2013 0:31 UTC (Fri) by airlied (subscriber, #9104)
Posted Jun 28, 2013 16:37 UTC (Fri) by maxiaojun (subscriber, #91482)
"The future of GNOME is pretty clear. The world's premier and, in fact, only truly free software operating system."
I guess systemd and/or Wayland proponents probably have similar mindset.
Posted Jun 28, 2013 11:45 UTC (Fri) by aseigo (guest, #18394)
Any direction in this requires making choices. You seem unhappy with the choice the majority are making in not adopting Mir and, as with most people I've seen who are supportive of Mir, do not seem to understand why. This seems to lead to quite a bit of angst, as is evident in the pro-Mir comments here.
The bottom line is that Mir does not solve any problems that Wayland does not already solve (often with more mature code); Mir is used by a minority of 1 distribution who insists on having control of its direction thanks to a CLA and closed in-house development practices; several other groups already have their stack running on Wayland (in case you missed it, KWin devs demo'd Plasma Desktop on the Wayland equivalent of XMir some weeks ago; though they had the wisdom to call it a 'hack' that was not suitable for actual deployment)
So it is should come as little surprise that interest in Mir is not great.
I noticed you've made the assertion in your comments that not electing for Mir means Kubuntu will ship crap to its users. I'd love to hear your fact-based reasoning for that one.
Posted Jun 28, 2013 16:44 UTC (Fri) by maxiaojun (subscriber, #91482)
Posted Jun 28, 2013 17:45 UTC (Fri) by jspaleta (subscriber, #50639)
Currently Mir is essentially untestable outside of specific Ubuntu environments without aggressive vendor specific patchsets to both mesa and xorg's xserver. Patchsets not officially submitted for upstream mesa and xorg to consider for inclusion.
Everything about how Mir development is done still tastes like alpha in-house development. Not a project meant to be used widely by external projects.
The inability to spin up xmir capable xorg from xorg upstream development tip is a somewhat serious issue. How is Debian really going to justify pulling in the xmir-enabling xorg patchset into their xorg packages in experimental? It's just not a reasonable expectation for the Mir _upstream_ project to be making concerning Debian's workflow. And if Mir as an _upstream_ project isn't thinking about getting their work into Debian experimental ahead of Mir becoming a default stack tech in Ubuntu..a derivative of Debian...then they've absolutely lost sight of the forest for the trees. The push to make this _default_ is just absolutely crazy. Crazy.
It's one thing to treat the needs of Unity as a special case, because Unity is so tightly tied to Mir's development roadmap and to flip the switch and turn on Mir by default specifically for the Unity environment because Canonical management has committed the resources to make sure they address the Unity stack issues. Unity developers don't do their development work on Debian so they don't need to worry about Mir working on Debian.
Its quite another to turn it on by default for all the other environments..with upstream developers..who can not play with Mir release tarballs on the platform targets they develop on. This is crazy, and its absolutely strategically poor decisioning both politically and technically. Mir's development model borders on being hostile to externals. And forcing it as a default as Ubuntu project strategy without it being testable in Debian binaries at all...is actively hostile to external DE devs and is going to cause serious political blowback across project lines.
You would think at this point Canonical would have a very good sense of evaluting blowback potential ahead of decisions like this..considering they've had wild success at generating blowback it in the past. The lack of empathy for the needs of other projects in the ecosystem..both upstream and downstream developers in the ecosystem relative to Caonical projects continues to amaze me. They just don't seem to think about it at all, ever, until someone shows up and yells at them for being clueless about it.
Posted Jun 28, 2013 18:27 UTC (Fri) by maxiaojun (subscriber, #91482)
I still yet to see any issue technically unsolvable.
BTW, I guess Debian is not the upstream of many Ubuntu packages these days. And few people, if any, cares Debian on desktop. Debian is stable sounds like an old myth to me.
Posted Jun 29, 2013 3:11 UTC (Sat) by jspaleta (subscriber, #50639)
The way forward is to flip the switch to use Mir/Xmir by default for DE upstreams that have affirmed interest in supporting the tech. So right now.. that's just Unity7/Unity8. No other DE installed by users should be defaulting to xmir in 13.10. NONE of them. No other DE has upstream buy-in to work out the issues with the Mir stack. And there will be issues. Furthermore Canonical does not have the manpower to deal with issues across multiple DEs. They need to focus on delivering Unity+Mir and commiting to an agressive SRU policy just for that stack. Focus, focus, focus. Get through one release cycle of real-world usage by real-world users of Mir/Xmir with just Unity and show you can keep up with the bugreports generated from that.
So how do you make sure the Canonical teams can focus? Without overburdening them with bugreports from DEs they are not going to have time to deal with? Make Unity8 default to Mir/Xmir(as a fall back for proprietary drivers), have Unity7 defaults to Xmir and all other DEs in 13.10 use x.org. That's it.
Problem solved and available manpower gets used in a focused manner without burning any bridges with upstreams unnecessarily. There are going to be more than enough users running Unity7 or Unity8 to be the test bed, generating more than enough bug reports for the Mir/Xmir stack than can be handled...without the complication of other DEs.
This is solvable.
But Canonical has to put down the gasoline can and the match and step away from the bridge they are hellbent on burning with external developers of competing DEs projects.
Posted Jun 29, 2013 3:30 UTC (Sat) by dlang (✭ supporter ✭, #313)
I've seen a lot of non-canonical folks expressing disappointment over the anti-mir attitudes
By the way, your prescription of what they need to do seems to match fairly well with what they are actually doing, concentrating primarily on Mir/Unity for 13.10, with XMir supporting everything else, but they are not refusing to help anyone else who expresses any interest.
Posted Jun 30, 2013 2:44 UTC (Sun) by jspaleta (subscriber, #50639)
For 13.10 the compromise solution here is to default Unity8 to Mir and Unity7 to Xmir and everything else runs over xorg X11 by default with the option for users to switch over to xmir for any DE. This approach gives external upstream devs and DE users the piece of mind of being able to work with a known stack by default while at the same time giving them all the ability to approach xmir on their own terms and to hopefully gain some confidence in it being something they can support upstream without being forced to abruptly deal with it without a FULL ubuntu release cycle to come to terms with the tech.
Canonical is on a forced march with Unity and Mir over the precipice . And that's fine for them, their engineer and their management team. But they can't not expect to drag all the competing DEs developers along with them and its foolhardy and wasteful in terms of political capital to even attempt it (they've burned so much trust already with the announcement). The way forward is to make Mir and Xmir an optional tech preview for all the other DEs in the Ubuntu repository. Gives those projects a chance to come to terms with Mir/Xmir as delivered in 13.10 with the hope they'll affirm its a supportable stack for 14.04.
Posted Jun 30, 2013 19:15 UTC (Sun) by speedster1 (subscriber, #8143)
If I were on the mir dev team, I would be wishing strongly that management switch to the more conservative roll-out that jspaleta recommends. I would want to be focusing on shaking out all the mir issues with Unity, and trying to recruit some other DE that wants to be adventurous to be the next guinea pig. A smaller one, that would have something to gain by the publicity of having a mir port, not KDE or Gnome.
Smart Ubuntu devs may already have this as their fallback plan: they can install xorg alongside xmir, and put in a user-friendly way to switch between backends. When compatibility issues crop up in RC testing, they can also switch the default backend to classic xorg for Lubuntu and Xubuntu installs (and Kubuntu could follow suit).
Posted Jul 1, 2013 2:08 UTC (Mon) by maxiaojun (subscriber, #91482)
If any DE/WM have trouble running on top of XMir, then either side might have bugs. And debugging can help either side.
Do you think it is OK for a display server to only work with Unity?
DO you think it is OK for a DE/WM to only work with Xorg as X implementation?
Posted Jul 1, 2013 6:53 UTC (Mon) by speedster1 (subscriber, #8143)
I can tell you didn't follow my train of thought at all, so I'll try to explain better: carefully planned roadmaps can make roll-outs of significant changes a lot less painful to other people, so that you get a lot more cooperation in the long run.
Supposing you're in charge of the mir team with fairly limited manpower -- it's not a good idea to do a big switch-over with millions of users and suddenly break hundreds of applications at the same time, including plenty of apps with peeved maintainers who will go around telling everyone not to use mir because "it is a piece of junk" that "breaks everything".
Now suppose instead you just focused a second totally independent project to integrate with mir. This will bring out a lot more of the important bugs, especially since this second implementation is done with a lot less direct influence from the original in-house devs. After fixing the critical bugs turned up in this key effort, pick some more projects to persuade to try a mir port, and that will make it even more robust without turning the world against you.
Then mir is stable at the point you can reasonably include xmir as an alternative to xorg, but making sure that xorg is still available for users to easily switch in case they run into serious bugs that you can't quickly fix. Bugs in some obscure legacy apps may never get fixed, but who needs to waste time with those because the users will either continue to use a system frozen in time or else eventually find a replacement; on the other hand, properly maintained X apps should only have the occasional bug to deal with, and not a flood that makes them rebel and start closing all the xmir bugs. Plus having a quick way to switch to and from xorg allows users to work around bugs as they discover them, and less likely to get upset and rude on bug trackers (both for mir and for the affected apps).
Do you see anything wrong with the second, more conservative, approach? Is it likely to be bad for mir or unity in any way?
Posted Jun 28, 2013 22:44 UTC (Fri) by rgmoore (subscriber, #75)
For those who want to be blind followers of some self-appointed upstreams, I guess Ubuntu is probably not their cup of teas.
The problem for Kubuntu is that they're trying to follow two upstream developers that are pulling them in different directions. Ubuntu's long term plans involve switching to Mir, and KDE's long term plans involve switching to Wayland. Kubuntu is left in the middle, forced either to figure out a satisfactory way of getting KDE to run on Mir or to keep X.org (and eventually get Wayland) running on Ubuntu. There simply isn't any way of avoiding this kind of challenge when two upstream projects disagree about long-term strategy.
Posted Jun 29, 2013 4:23 UTC (Sat) by maxiaojun (subscriber, #91482)
Posted Jun 29, 2013 13:38 UTC (Sat) by kitterma (guest, #4448)
Personally, I disagreed with that change, but the fact is, sometimes, where people think it makes sense, Kubuntu will follow along with the rest of the distribution. LightDM is another example.
Posted Jun 29, 2013 16:10 UTC (Sat) by maxiaojun (subscriber, #91482)
If you are unable understand there is some ambiguity in natural languages, well, you'd better do something else.
Posted Jun 29, 2013 16:16 UTC (Sat) by kitterma (guest, #4448)
In any case, I'm now convinced you're just trolling and not actually caring about facts or anything but stirring up trouble, so you'll get no more replies from me. Have a nice life.
Posted Jun 29, 2013 16:28 UTC (Sat) by maxiaojun (subscriber, #91482)
Do you have difficulties understand what does "We'll be staying with X on the images for our 13.10 release now in development and the 14.04LTS release next year." mean?
You said you've just decided for 13.10? What a plain lie.
Posted Jun 29, 2013 21:02 UTC (Sat) by mathstuf (subscriber, #69389)
He didn't say that they didn't decide for 14.04, just that the decision to not use Mir in 13.04 has been made and isn't going to change. I certainly wouldn't want my users to be subjected to the first attempt at Mir/XMir for an LTS. Are you trying to be adversarial at this point?
Posted Jun 30, 2013 2:43 UTC (Sun) by maxiaojun (subscriber, #91482)
Posted Jun 30, 2013 3:19 UTC (Sun) by rahulsundaram (subscriber, #21946)
Posted Jun 30, 2013 5:12 UTC (Sun) by maxiaojun (subscriber, #91482)
But anyway, LXDE/Lubuntu people is much less annoying than their KDE/Kubuntu counter part.
Posted Jun 30, 2013 3:32 UTC (Sun) by mathstuf (subscriber, #69389)
Posted Jun 30, 2013 5:02 UTC (Sun) by maxiaojun (subscriber, #91482)
But again, he said "The future is unpredictable and we'll do what makes sense when we get there." to prove my "No, I've never seen Kubuntu devs showed any interest following Ubuntu as upstream. They just repeat Mir FUD all the times and never show people anything concrete." in the context of Mir issue wrong?
As for not good switching display server for an LTS, this is the reason why one should start from 13.10, if the team concerned has non-zero interest.
Posted Jun 29, 2013 21:12 UTC (Sat) by dlang (✭ supporter ✭, #313)
I will say that this is the first post that I can remember seeing that left the future open. Everything else I've seen could be summed up as "Mir is Evil and KDE/Kubuntu will not support it now or ever"
playing the 'wait and see' game to see how well it works in 13.10, and how much churn there is going to need to be in 14.04 to fix the things they didn't get right in 13.10 seems like a very prudent approach.
Posted Jun 30, 2013 2:57 UTC (Sun) by maxiaojun (subscriber, #91482)
Posted Jul 1, 2013 18:16 UTC (Mon) by rgmoore (subscriber, #75)
I said "never" in the context of Mir issue, because that's the context of rgmoore's comment.
Posted Jul 2, 2013 3:18 UTC (Tue) by rodgerd (guest, #58896)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds