The Story of Ubuntu's Mir Abstraction Layer (MirAL)

[shmerl]

You skirted the main question. Why is Mir needed? I see no benefits that it brings, only damage to many projects and progress of Linux desktop in general. To all my examples you had nothing to say but "yes, that extra work is needed". But you omitted, because Canonical pushed out Mir for no good reason. Yes, I hold Canonical responsible for causing an unnecessary duplication of effort and rift in the Linux desktop. And arguments like "why Wayland and not Mir" are demagoguery, because Wayland started way before Mir, and a lot of effort was put into and around it. Saying "let's do it all over now" is extremely wasteful. I'd agree with "let's make XYZ", if Wayland was really deficient. But it isn't! Linux desktop moves slowly as it is, and such diversions are making things worse.

So again, no one stopped Canonical from making Unity a Wayland compositor, once they realized, their whole Mir idea was based on mistaken assumptions. That would have avoided all this major mess. But now it's just the question of swallowing pride and admitting, a lot of time was wasted (and for others too). The longer it goes, the harder it becomes (it's painful to throw out a lot of work).

[bregma]

You misunderstood my question, so let me rephrase it. If mirAL isn't supposed to do Wayland's job of guaranteeing a stable API/ABI for client developers, is there a different component that does that? If Mir's API/ABI isn't stable yet then I guess an abstraction layer for client developers is more important than an abstraction layer for window managers, or are you saying that libmirclient is that client abstraction layer?

Quite.

Wayland does not guarantee a stable API or ABI for client developers. It is a wire protocol. It guarantees that a client using the wire protocol can speak to a server using the wire protocol. Just like X11. The protocol changes: it gets stuff added all the time, and big chunks are optional. A client has to be written to take that into account and either have fallbacks in place or fail gracefully at runtime if there is a critical protocol mismatch or the server does not support the requested functionality. It's good, sound engineering.

Mir provides a stable client API and a backwards-compatible ABI across major SO versions, like other libraries do. It makes no guarantees about wire protocol compatibility (perhaps arguably) but instead relies on close coupling between the client and server libraries to guarantee if a program can start, it will run.

Mir also provides a server API/ABI, and a platform API/ABI, which have proven to be less stable as they evolve with consuming software such as Android and Mesa (for the platform) and Unity 8 (for the server). MirAL is an attempt to provide a stable interface for window managing shells, which is especially useful for applications such as displays in embedded systems where a full-blown personal device UI is inappropriate. It's neither the server API nor client API, but some of both with some extra thrown in.

I'm not sure if this is a clear explanation either, but I hope I demonstrated how the Wayland protocol and the MirAL library serve completely different purposes.

[finalzone]

Quite.

Wayland does not guarantee a stable API or ABI for client developers. It is a wire protocol. It guarantees that a client using the wire protocol can speak to a server using the wire protocol. Just like X11. The protocol changes: it gets stuff added all the time, and big chunks are optional. A client has to be written to take that into account and either have fallbacks in place or fail gracefully at runtime if there is a critical protocol mismatch or the server does not support the requested functionality. It's good, sound engineering.

Then why didn't Canonical bring those issues to Wayland development where all the following points could be addressed without the need to waste effort?

[jacob]

So what's Wayland's equivalent in Mir world? How do client programs communicate with Mir?

AFAIK in Wayland clients are expected to use a protocol, in MIR they are expected to use an API which abstracts the protocol away. Mir's protocol can and does change, the stable and backward-compatible level is the API.

But I may be wrong about this.

[sarmad]

I'm not sure if this is a clear explanation either, but I hope I demonstrated how the Wayland protocol and the MirAL library serve completely different purposes.

This was clear enough. Thanks for taking the time to explain.

[darkblu]

So again, no one stopped Canonical from making Unity a Wayland compositor, once they realized, their whole Mir idea was based on mistaken assumptions. That would have avoided all this major mess. But now it's just the question of swallowing pride and admitting, a lot of time was wasted (and for others too). The longer it goes, the harder it becomes (it's painful to throw out a lot of work).

You seem to start with taking your assumptions as ground truth. In reality, Unity8/Mir has been a viable platform for more than a year on Ubuntu Touch, running on top of Android EGL stacks. So Mir has been a major enablement component to Ubuntu Touch. Just giving you an example here (I'm fully Wayland/Mir-neutral).

[Sesivany]

I happen to know someone from the community working on a Mir port for WINE. Firefox uses GTK+, which already has a port (but consider FireFox still has hard-coded X11 calls in in places, so it requires XWayland or XMir to run).

I run Firefox on Wayland natively although it's still experimental. BTW Mir backend in GTK+ doesn't help that much here because Firefox uses it only for a subset of functionality. It does a lot of stuff directly with X11 and newly with Wayland, so supporting Mir will be a non-trivial amount of work on the Firefox side.

[Sesivany]

You seem to start with taking your assumptions as ground truth. In reality, Unity8/Mir has been a viable platform for more than a year on Ubuntu Touch, running on top of Android EGL stacks. So Mir has been a major enablement component to Ubuntu Touch. Just giving you an example here (I'm fully Wayland/Mir-neutral).

Wayland has been on phones since 2013 and then on TVs and other gadgets without major problems. It's the desktop with all the legacy apps, lots of input devices, multiple screens, a lot of required functionality etc. where the stuff gets really hard.

[bregma]

I run Firefox on Wayland natively... It does a lot of stuff directly with X11...

So, you've run Firefox on XWayland. X11. Not native Wayland. Most desktop systems using a Wayland compositor also run a single session-wide X11 server, providing all the security holes and disadvantages of X11 right out of the box. Screen scraping, key grabbing, snooping and surveillance, it's all there.

[andre30correia]

Again the same shitxxx. Canonical wants to control their product is simply like that and most likely they don't want to use wayland because it will become something like X11 with a lot of thing nobody uses with all type of security issues. But stop with this, their distro, their choice if you don't like mir use another with wayland is simple like that.