A new hope

Disclaimer: With the changes in progress at Canonical I am not currently in a position to make any commitment about the future of Mir.

It is no secret that I think there’s value to the Mir project and I’d like it to be a valued contribution to the free software landscape.

I’ve written elsewhere about my efforts to make it easy to use Mir for making desktop, phone and “Internet of Things” shells, I won’t repeat that here beyond saying “have a look”.

It is important to me that Mir is GPL. That makes it a contribution to a “commons” that I care about.

The dream of convergence dies hard. Canonical may have abandoned it, but I hope it survives. A lot of the issues have been tackled and knowledge gained.

I read that UBPorts will be using Mir “for the time being”. They sensibly don’t want to maintain Mir and are planning a migration to an (unidentified) Wayland compositor.

However, we can also see from G+ Mark Shuttleworth is planning to keep “investing in Mir” for the Internet of Things.

This opens up an interesting possibility: there’s no obvious technical reason that Mir could not support clients using libwayland directly. It would take some research to confirm this but I can’t foresee anything technical blocking such an approach.

There could be some benefits to Canonical from this: the current design of Mir client-server interation makes sense in a traditional Debian (or RPM) repository based world, but less so for Snap (or Flatpak).

In a traditional environment where the libraries are a shared resource updates simply need to maintain ABI compatibility to work with existing clients. That makes it possible to keep Mir server and client and server libraries “in step” while making incompatible changes to the communications protocol.

However with Snaps the client and server “snap”s package the libraries they use with the applications.That presents issues for keeping them in step. These issues are soluble but create an additional burden for Mir, server and client developers. Using a protocol based solution would ease this burden.

For the wider community native support for Wayland clients in Mir would make the task of toolkit maintainers and others simpler.

If Canonical could be persuaded to add this feature to Mir and/or maintain it in the project would anyone care?

Is anyone else willing to help with such a feature?

14 thoughts on “A new hope”

  1. Mir certainly looks like worthy piece to keep maintaining and developing and GPL is the right choice in my opinion. Too bad I don’t have expertise to help 🙁

  2. I always meant to try out tiling under Mir, but didnt have the time or the expertise. I love tiling in a DE, but everything out there is just combine MATE + i3 for example.

    1. What do you mean by “try out tiling under Mir”?

      Currently there’s only one near-complete desktop environment based on Mir: Unity8.

      The miral-shell example provides a tiling option, but that’s very limited.

  3. This sound like a great plan: Mir-Server that can handle Mir- and Wayland-Clients. I think it’s the best way to keep Mir alive, because lot toolkits will not interested to add or maintain a “Mir-support” for the Clients. Even GTK+ has only an experimental support.

    I looking forward for this plan. It would even help all Unity-8-forks!

  4. Would Mir gain Vulkan support this way? From what I have read Vulkan support in Mir was pushed back again and again and again. Vulkan clients work on Weston since Vulkan was officially released over a year ago.

  5. You talk about Mir as if its value is a foregone conclusion – That it must be good, because it exists, and is open source – but where is the factual explanation of what attributes Mir possesses that makes it a better choice for DE developers or GUI app developers to target?

    Do you think people should use it just because you spent a bunch of time building it, even when an obviously more widely supported and functional alternative is available (Wayland)?

    Canonical has spent years working on this project, but putting aside the issue of current installed base – if we assumed that the Linux display server landscape was a hypothetical meritocracy, why should Mir come out on top in a architecture/performance/security comparison?

    Nobody is denying the right of the project to exist, but, just as with the HURD vs Linux – if your advantages are all purely theoretical, what is the rationale for widespread adoption?

    It seems like Mir only exists because it let Canonical work faster to bring convergence to Ubuntu, without needing to collaborate with the community to get the product to ship. Can you explain the other reasons why the world needs it?

    1. Agreed. I’m not seeing anyone making the case for *why* anyone should persevere with Mir, no argument for the merits or continuing relevance.

      I don’t know enough about the project to judge for myself – but when the developers are asking us rather than telling us why it’s useful, that doesn’t sound like a vote of confidence…

    2. This is not the blogpost you are looking for. 🙂

      I’ve written quite a bit about Mir and MirAL here and on “insights” [https://insights.ubuntu.com/2016/11/28/mir-is-not-only-about-unity8/] over the past months, I’ll try to put a summary together later today.

      BTW I hate “comparisons” by people whose knowledge of the competing technologies is uneven. So I won’t be writing a comparison with Mutter, KWin, libweston, qtwayland, etc.

  6. What can Mir do that Wayland doesn’t? As a typical GNU/Linux user, I would like to see less fragmentation and more contribution toward Wayland as it is the de facto protocol now. Take anything that Mir has and Wayland doesn’t and converge it into one project.

    I think you should contribute to Wayland.

    1. People seem to be slightly confused about what Wayland is. When most people talk about improving Wayland, they’re not talking about improving Wayland, but about improving _support_ for Wayland. That’s something entirely different. For instance, when Gnome improves their Wayland support, that does not affect KDE, because they use a different Wayland system.

      1. wouldn’t be better to have a single display server than everyone could improve instead of a protocol where everyone has to start over again?

  7. yeah wayland in mir.

    but What I want is reduce the patchwork on the other programs.
    Is possible to move the functionallity added to a patch for… lets say mesa and use an external library so vanilla mesa can be used to run mir?

  8. I want it, I also was hoping unity 8 would be easier to use on arch without having to pull down old modded gtk libs. I prefer unity overall but did not want to leave arch so been stuck on gnome. From what I read mir has some technical and design aspects i would like to see stay in the linux world, so I am behind anything that can make it more relevant.

  9. The reality is flatpak is wayland. Toolkits will have to-do wayland protocol. Mir doing wayland would me X.org could reduce to only have Xwayland backend supporting both.

    Very quickly Mir gets reduced to nothing more than another Wayland compositor. Question here is what features Mir ABI/API had that need to be integrated in Wayland. If Mir is going to remain you can fairly bet there will be almost no Mir particular applications.

    http://blog.qt.io/blog/2016/06/13/new-compositor-api-qtwayland/
    Also you need to wrap you brain around this.
    –(unidentified) Wayland compositor.–
    Unity 8 is Qt so Unity with extra Wayland Qt parts is it own compositor.

    One of the thing about Wayland is shell and compositor are not two independent parts needing to talking to each other. What Mir did for unity in a Wayland version of unity would be reduced to a Library. The library if it Qt would be shared effort with everyone who is using QT like with KDE and other Qt based Wayland compositors.

    Even in IOT we are seeing Wayland compositors. You have to be able to justify why the overhead of the communication between the shell and the compositor of Mir or Mir is simple dead in the water. Wayland protocol allows the compositor to be restarted without the applications needing to be.

Comments are closed.