A) Canonical does not want a stable interface to Mir. It would have to be a cat and mouse game chasing Canonical's erratic interface changes of Mir.
B) Mir has zero technological benefit over Wayland. In fact is way behind in development compared to Wayland.
Note that this text isn't generated by a machine, but written by a human being with intentions in mind. The antipathy is pretty obvious. Reasonable? Yes. Use/helpful? No.
a) Drivers for none-MIR setups:
Corporations want RHEL or SLES.
AMD makes binary drivers for those customers
b) Ubuntu Software Center.
Lindows had a similar thing. didn't work out at the end.
c) Steam. Steam works fine on none-ubuntu platforms.
d) canonical contributes nothing back. Without all the other distributions, canonical can pack up and die.
Last edited by energyman; 06-15-2013 at 01:52 PM.
And : https://lists.ubuntu.com/archives/ub...ne/037287.html
+ 1I think most of the points have been covered in this thread but I'll just emphasise a few points:
- The use of Mir in Ubuntu should have no effect on using any alternative display systems. Some things will gain Mir backends but everything will continue to support X and Wayland if the upstreams support it and developers package and support it in Ubuntu.
- There are a number of different levels of co-existence with Unity/Mir that are possible:
a) Unity on X and KDE on X - the current case. You can install both and choose a session from a greeter
b) Unity on XMir and KDE on XMir using Mir as a system compositor  - this is the case you can test from the PPA  today. Looks and behaves much the same as a).
c) Unity on Mir and KDE on XMir using Mir as a system compositor - this is the case we're working towards. For KDE it will be the same as b).
d) Unity on Mir and KDE on Mir using Mir as a system compositor - IF KWM was able (have not seen any technical reason this can't be done) and wanted to create a Mir backend this would work like b) (see discussion later in this thread).
e) Unity on Mir and KDE on Wayland using Mir as a system compositor - IF Wayland is able (have not seen any technical reason this can't be done) and gets a Mir backend this will work IF LightDM support is added like b) (see below).
f) Unity on Mir using Mir as a system compositor and KDE on Wayland using Wayland as a system compositor - Would not be able to switch between
sessions. Would either need to switch LightDM configuration or display managers.
g) Unity on Mir and KDE on Wayland using Wayland as a system compositor - Would be technically possible but the Mir team has no plans to add a Wayland backend. Would not be shipped as a default so would not be well tested by Canonical.
- Canonical will need to support XMir for the foreseeable future. XMir is just X.org with a Mir backend. This means supporting XMir will mean supporting most of the case of running X.org in the traditional sense.
- LightDM will continue to support the traditional VT switched X display. We have extensive regression tests for this case and it is used by a number of other desktops.
- While Canonical is not going to add Wayland support to LightDM the work we are doing to support Mir in LightDM is much the same as would be required to support Wayland in LightDM. Anyone is welcome to implement this. Note it's not clear to me at the moment how different desktops plan to use Wayland (no system compositor, shared system compositor, differing system compositors, same/differing Wayland socket naming conventions). I'll leave it to Kubuntu/KDE to decide the value in sharing the rest of the display manager codebase.
 The "system compositor" is a display server that switches between running sessions. The purpose of this is to control the graphics during the whole boot / session lifetime. It replaces handing over between display servers and VT switching.
It's interesting and rather telling that the Canonical employees in this discussion don't seem to have read Martin's blog post. For example, Robert Ancell says he "has not seen any technical reason" that KDE can't support Mir when one technical reason for this is quoted in the very message he's replying to and more are in Martin's blog post:
Given that the protocol may change any time and given that the whole thing is developed for the needs of Unity we have to expect that the server libraries are not binary compatible or that old version of the server libraries cannot talk with the latest client libraries. We would constantly have to develop against an unstable and breaking base.And, most importantly:But it gets worse, the protocol between Mir server and Mir clients is defined as not being stable. In fact it’s promised that it will break. That’s a huge problem, I would even call it a showstopper.
As far as I know, no one at Canonical has not addressed any of these concerns in any way, instead opting to ignore them and pretending that the whole thing is just an angry rant with no technical basis.Mir doesn’t have a real protocol. The “inner core” is described as “protocol-agnostic”. This renders a problem to us if we would want to use it. Our architecture is different (as described above) and we need a protocol between the desktop shell and the compositor. If Mir doesn’t provide that we would need to use our own protocol. And that already exists, it is called “Wayland”. So even if we would support Mir, we would need the Wayland protocol?!?
I don't mean to pick on Robert Ancell specifically, since most Canonical employees seem to be operating on a similar level of information. If Canonical wants to be taken seriously with Mir, it needs to step out of the void it exists in and look at what the people outside of Canonical are saying about the project - especially the people they are expecting to support Mir upstream.
And Mageia's net_applet is a nightmare in the making; to date it has never successfully connected to any non-open network for any machine I have used it on. In fact manual invoking wpa_supplicant / iw dev wlan0 connect with dhclient always produced better results than net_applet. Even networkmanager and nm_applet are way ahead of net_applet in the game.