Mir 0.0.5 Released; Kubuntu Will Stick To X/Wayland

[mrugiero]

Wayland is a protocol that does not dictate an implementation. Wayland offers an already stable API for developing compositors that work within the Wayland standard. Wayland allows perfect frames, client-side rendering and client buffer allocation. Mir does not.

True.

Every distro other than Ubuntu is going to use Wayland. Every other desktop environment has plans to move to Wayland. Wayland will be used on many mobile and embedded Linux systems. It is something that has the chance to bring the entire Linux ecosystem together under one graphics standard. Every major toolkit will support Wayland.

Irrelevant (as advantage, but they are technical facts that make it reasonable to choose Wayland), since it's not an advantage of Wayland. Rather, its advantages leads to this.

By contrast, Mir is a fixed implementation - there is no "Mir standard", you can't develop your own Mir server because Canonical can just break the API. Mir is designed only for the needs of Unity, it does not take in account the needs of any other desktop or distribution. It will not benefit anyone other than Canonical. None of the major desktop environments or toolkits have plans to implement Mir support.

I think some of the points here are arguable, but true at the moment. The inability to develop another implementation is true, and will keep that way since they already stated they don't want clones. The benefits are arguable. You'd have to play by their rules if you want to get any benefit, though, and that doesn't fit already existing projects other than Unity.

When I looked at the claims by Wayland it was only indirectly supporting Android video drivers, no other drivers, and was doing it differently than Mir

No. Both Mir and Wayland use Android drivers, and that's definitive, according to Mir's announcement. The point was exactly not having to reimplement drivers without need, and that is a wise decision in my opinion, for both projects. And nope, it does not do it differently, because Mir uses libhybris, which was made for Wayland.

IMO, reimplementing the drivers should be a matter of choice ("do I want to use this closed source driver, or rather use open ones?"), not a matter of need because the infrastructure I use is incompatible.

My understanding is that the only offerings will be separate compositors for mobile and desktop systems.
No one else is really trying for a seamless convergence platform except for Ubuntu and the Plasma Active team, though with the latter the majority of the work seems to be X11 specific.

I'm not really into this specific part of the subject (as I said in another thread, I'm quite a few steps behind in cellphone tech ), but it makes sense to me that the protocol isn't strictly aware of where it's physically running (else, your convergence is ruined from the very beginning, with the protocol being different across platforms), rather the client should. The implementation will probably have to be different at the low level on both cases (Mir and Wayland). The platform aware client can be the system compositor, so the apps can be unaware, too. This unawareness is enough for convergence, I think. So, the only need for Mir we get until now is a system compositor, if my reasoning is correct.
There is one other advantage I'm not sure if is possible with Wayland (but I'm not sure if it's implemented on Mir either) that is the use of a smartphone as a thin client. I wonder how do they expect to do that.

just if anyone is still in the wrong direction, that all the Shitstorm on MIR is just based on technical arguments and not based on politics, and personal egos: https://plus.google.com/115606635748...ts/jdbSVidJyWH

this is just ridicolous :/ im very disapointed from the KDE side.

I see nothing new. A whole different stack and lack of manpower, where are the politics? The only disappointing thing I saw is Martin refusing to expose which the bug is exactly, but he does have strong arguments for everything else discussed there.

XMir is a transitional layer. It will be replaced or sit as a sideline for legacy, so expect Mir to be a direct layer that video cards will talk to for screen allocation and manipulation.

OK, so you gave a reason for Mir over XMir. Now we need a reason for XMir over X and for Mir over Wayland an we are done.

Be cool and collected, and enumerate Wayland advantages over X.org, and then provide TECHNICAL reasons why such advantages WONT apply to Mir.

You are looking it the wrong side, since what you need to prove to get to the conclusion Mir is no needed is that it does not do anything Wayland is unable to do, not the other way around. Name functionality that Wayland can not provide and Mir can, and then you have a case where it actually fulfills a real need.
Advantages over X.org were discussed since day zero until today. What are the advantages of Mir over Wayland?

You are forgetting that Ubuntu developers have already offered to do the work themselves. The Kwin developer is concerned that they won't maintain it for some reason. This seems counterintuitive to me, since obviously Canonical would want more distros (specifically the rest of the *buntu family) to use Mir but afaik that is where the discussion has ended.

Accepting patches upstream imply you need to test against that backend too when you change a common area, something that implies (since none of their devs use Ubuntu) building on a VM, testing on a VM, no real hardware tests (which may behave a lot different than the VM), and not only this, but it takes a lot of extra time. As they stated several times, they lack manpower, and that's why distro specific solutions are out the wishlist. In a link a user provided as a 'see how this is political' you can clearly see they also don't investigate issues on Debian because of this very same thing (specifically, they are 'specific' in having far older builds of everything on their stable stack). They hate Debian for being successful, too?

All of this happens EVEN IF Canonical do the work of maintaining. And except they put a full-time dev on it, this will generate breakages constantly, or a massive slow down (if they do wait till Canonical tests it still works to keep committing). Forget, for example, using the latest version on Ubuntu, since it will only work with the official packages which will involve first fixing again Mir backend which will be for sure broken for untested upstream changes.

I haven't seen any technical reasons why Mir is a bad idea at all. The only reason that I see people repeating is that it fragments the linux desktop.

That is a technical reason. This fragmentation creates testing problems at the very least, assuming even you only target toolkits to avoid display architecture specifics. Also, the point is not Mir being a bad idea, but Mir actually providing something Wayland doesn't. That's what 'being needed' means, provide a solution for a problem that isn't already solved. Then, you have 'being useful' which is providing a tool or a solution to a problem that is not solved or that is solved in a different way. Except for the use as a thin terminal I didn't saw yet any problem Mir solves that Wayland can't solve in the same way. There's an arguable point, too, of convergence, for what Wayland would only require a system compositor that keeps for itself all of the platform awareness if I get it correctly. And a similar solution might provide the only point I remember where X is better than Wayland, which is network transparency.

There is no technical reason that Mir is needed, just like there is no technical reason for gtk or gnome or even Linux itself. The reasons they chose not to use Wayland are here.

Linux is needed because of technical reasons, provided you either feel free software is important or you are not willing to pay for your OS. Linux is technically better in several areas than other free kernels. GTK fulfills different needs than Qt, specifically GNOME fulfilled different needs than KDE at its time. Where (IIRC) KDE aimed to be fully configurable, GNOME aimed to be simple. And, please, stop acting as nobody ever bothered pointing out this fragmentation was bad in some ways already (it wasn't that bad as having two different displaying architectures thanks to EWMH and ICCCM), because there were flamewars about this since the beginning of time.

Be cool and collected, and enumerate Wayland advantages over X.org, and then provide TECHNICAL reasons why such advantages WONT apply to Mir.

A simple technical reason why Wayland is better than X.org is because it does ONE thing instead of trying to do everything. That means it's easiear to maintain, to replace when it becomes obsolete (replacing X.org is hard because it handles too many things and not everyone becomes obsolete at the same time). I don't remember all the reasons right now, but most are on their freedesktop page IIRC.
And most do apply to Mir. The thing is, the charge of the proof is for the one proposing the change. The question "why Wayland?" was answered before Mir was even an idea. The new question is "why Mir?" and I didn't see any technical answer yet, except from the two I already mentioned on my post, that does not apply in EXACTLY the same way in Wayland. And even of those, one has no technical details of how it's done (or planned to be, if it isn't implemented yet), being that the reason I can't tell 'well, Wayland does the same', and the other would just require using a compositor abstracting the platform.

[Teho]

Do you have any links pertaining to this, specifically about Weston?

Not really. I know Weston has multiple shells and if I have understood correctly you can run same applications in all shells. I would assume that you can also change shells on runtime (at least something like that could probably be implemented).

I know Plasma Active is going for a similar concept (tablet/desktop neutrality, no smartphone mode planned as of yet) but that work is still incomplete and currently Xorg only.

KDE developers are actively working on Wayland support. However the "convergence" has nothing to do with Wayland; it's all about Qt/QML. In Weston it's bit different I guess because it's also a shell; In KDE the shell (Plasma) is separate from the compositor (KWin). The job of a compositor / display server doesn't change whether you have 5" or 20" screen or if you change the input device.

Ubuntu Touch is trying to push this concept onto the market before the competition has a chance to do the same, and with the way development is progressing they might actually achieve that goal.

Probably. The only point I'm trying to make here is that Mir has nothing to do with it and it's not something that Wayland couldn't do.

[GreatEmerald]

And a similar solution might provide the only point I remember where X is better than Wayland, which is network transparency.

X is not network transparent.

[dee.]

just if anyone is still in the wrong direction, that all the Shitstorm on MIR is just based on technical arguments and not based on politics, and personal egos: https://plus.google.com/115606635748...ts/jdbSVidJyWH

this is just ridicolous :/ im very disapointed from the KDE side.

Nothing political there. KDE devs are behaving rationally, and not bending over for Canonical and accepting their attempts of bullying everyone into doing things their way. Smart people, those KDE folks. Makes me want to try a KDE distro one of these days.

[spacetoilet]

Nothing political there. KDE devs are behaving rationally, and not bending over for Canonical and accepting their attempts of bullying everyone into doing things their way. Smart people, those KDE folks. Makes me want to try a KDE distro one of these days.

what he said no Usheep at KDE but the funny part is now KDE is going to help Kbunutu do to them going to use Wayland Epic win for Opensource

[mrugiero]

X is not network transparent.

Well, better for my point