Canonical's Multipass 1.1 Brings Proxy Support, Fixes

[jo-erlend]

Snap
https://thenewstack.io/canonicals-sn...good-bad-ugly/

Mir ...everyone (Redhad Suse Arch Debian etc ) have been questioning the future of xserver - there was a agreement - well let us develop wayland as a common alternative...Canonical opted out with mir ...

Mir is a display server, not a protocol. Wayland is a protocol, not a display server. There were real reasons to believe that Gnome Shell would not be the ideal system to use for low-powered phones. People talk about Gnome as if it's the epitome of software, but the fact is, it isn't and Gnome 3 wasn't designed for ultimate performance. Sure, Canonical could've ditched Gnome entirely and switched to KDE, but I think that would've been a mistake for a different set of reasons.

Mir still seems to be the closest alternative for people who want a common display server.

[Mez']

The only ones whining about FUD are the fanbois here.

Thanks for raising the level so much with your deep insights.

[starshipeleven]

Thanks for raising the level so much with your deep insights.

what would you be doing without me

[CochainComplex]

Mir is a display server, not a protocol. Wayland is a protocol, not a display server. There were real reasons to believe that Gnome Shell would not be the ideal system to use for low-powered phones. People talk about Gnome as if it's the epitome of software, but the fact is, it isn't and Gnome 3 wasn't designed for ultimate performance. Sure, Canonical could've ditched Gnome entirely and switched to KDE, but I think that would've been a mistake for a different set of reasons.

Mir still seems to be the closest alternative for people who want a common display server.

Ok lets split hairs and let us call the class of Servers using the Wayland Protocol simply Wayland compositors. So the Protocol sets the standard and its implementation can be rather "independed" (like Mutter, Weston, KWin ...or what ever). Exactly this makes it even less understandable what Canonical did.... Wayland is not tied to a reference server like it is with x.org.server . You can implement your own solution to use that protocol e.g. a lightweight compositor for phones.
Concerning Gnome - this is a window manager (no compositor) - You would have still needed their support to make Gnome runable on Mir. So the basic question is:
Why was Mir not designed like it is now as a Wayland Compositor which fullfills the Desktop, Ubuntu Touch kind and IoT needs whilst remaining on a common standard?
Why is it necessary to have a new Protocol? If I would create a new Webbrowser does it mean I immediatly need to implement a new protocol? Im already seeing ....Cisco Switch Google edition supporting GoogleTCP ....next TP-Link MozillaUDP Edition.

Nvidia is already struggling with proper Wayland support. Now what If they would need to support x, wayland and mir ?

[Michael_S]

You do understand that the GPL does not apply to the owner, right? So unless you're saying that Red Hat never releases its own software, your statement is false. I don't know the RHEL policy for hosting third-party patches, but personally, I would never want to allow contributions if it meant that I lost all my rights. If I do 99.5% of the work, I made the decisions and not random strangers.

I think you misread Britoid's post. He's being critical of Canonical, not Red Hat.

I like Canonical. I'm typing this from Ubuntu MATE and my two other computers are running vanilla Ubuntu and Kubuntu.

But Red Hat's approach to free-as-in-freedom software is flat out better because they don't require contributors to sign a Contributor License Agreement. If I contribute GPL code to Red Hat, they can use it as GPL code. If I contribute GPL code to Canonical I have to sign a Contributor License Agreement with Canonical, which means they can use it under any license they want - Apache, MPL, EPL, BSD, MIT, proprietary. Why would they require a CLA if they planned on keeping it GPL forever?

Many people suspect the biggest single reason Canonical switched from Wayland to Mir was because Mir contributions had to be under Canonical's CLA. They might not have been pivoting for technical reasons but for the purposes of having a display technology they owned completely. If Mir became wildly popular, they could re-license it in a proprietary way. That's why Canonical gets a lot of abuse and negative focus from the free software community. If there was no Mir CLA, I think everyone could be persuaded to believe Canonical switched to Mir in good faith. Even if it might have been a technically poor decision, it would have been in good faith.

Instead, it looks like Canonical was at least considering a switch to a proprietary software model. That rightly upset a lot of people that love Linux partly because of its free software connection.

[jo-erlend]

Ok lets split hairs and let us call the class of Servers using the Wayland Protocol simply Wayland compositors. So the Protocol sets the standard and its implementation can be rather "independed" (like Mutter, Weston, KWin ...or what ever). Exactly this makes it even less understandable what Canonical did.... Wayland is not tied to a reference server like it is with x.org.server . You can implement your own solution to use that protocol e.g. a lightweight compositor for phones.

You ask some legitimate questions and I'll take them seriously. I have to start by saying I'm not an expert on this at all. I read about it a long time ago, and I think I basically understood the arguments, but that's pretty much it.

But I'm not trying to split hairs. There really is an important difference between an API and an open standard of public protocols. It's not about whether you name them compositors or display servers. And you demonstrate my point a bit; the protocol used by the xorg server, is really a public protocol called X11. There are actually a number of different X11 display servers out there. Xorg is the most popular, but the situation used to be more diverge. It is the protocol itself that makes it difficult to make good X11 display servers because you have to deal with a lot of irrelevant things. An extreme example of this is apparent when you compare HTML&al with something like Qt. Even someone who doesn't particularly like Qt, would have to agree that it's far superior to the web platform for app development, even if you have Apple, Microsoft and Google cooperating on building the web platform.

As I understood it, the purpose of Wayland was to simplify and speed up the display stack by reducing the responsibilities of the DS. Clients would get a set of resources and just use them as they see fit and the compositor would just put it on the screen. That's a good thing on desktops, where you have a lot of open windows, but also have a lot of resources. The DS should just get out of the way. I think it's also a good thing on phones, where you have much more limited resources, but also typically a lot less open windows.

The basic purpose of Mir was the polar opposite of the popular use-cases for Wayland. Mir was designed for the specific scenario in which you would use phones to provide full desktops, meaning you would have lots of open windows on a device with very little resources. So, in Mir, the display server would be in total control at all times. Apps would not be assigned resources like buffers and paint jobs, but would have to ask for them every time they wanted to use one. That introduces round-trips, which was specifically mentioned as one of the things Wayland developers wanted to get rid of, because there are negative aspects to those round-trips, like being very sensitive to latency and of course, the extra work in and of itself adds overhead. But the benefit of doing it this way, is that the DS can reuse memory and police bad apps, like a video player continuing to process video while its window is invisible, burning battery.

So for me, the question is, if two groups are have polar opposite ideas, does it make sense for them to use the same protocol? Maybe, but I don't think it's obvious. It was said at the time that Wayland was extensible and would be able to provide the features Canonical needed, but none of the others were interested in what Canonical was doing and they're still not. Let's use the HTML vs Qt example again. Imagine if Qt would've had to wait for the W3C to come to a consensus regarding web app development. What do you think Qt would've looked like today? None of the other big players wanted to use the web as a platform for app delivery. You could argue that HTML is extensible the way Wayland is extensible and Qt could've just made up new elements and properties to make it fit their needs. But then it would still have been incompatible with other HTML products and you'd have to ask whether it was worth it. [/QUOTE]

Concerning Gnome - this is a window manager (no compositor) - You would have still needed their support to make Gnome runable on Mir. So the basic question is
Why was Mir not designed like it is now as a Wayland Compositor which fullfills the Desktop, Ubuntu Touch kind and IoT needs whilst remaining on a common standard?
Why is it necessary to have a new Protocol? If I would create a new Webbrowser does it mean I immediatly need to implement a new protocol?

Mir was never going to be a new protocol or standard, but only an API, hiding the actual protocols, hence enabling internal changes to take place without affecting clients. You import a library and use it, allowing the library to figure out how to get things done internally. The developers doesn't have to worry about global consensus and that sort of thing, so they can just rush ahead and make things work. It's the Qt vs HTML thing; they wanted to do things differently than the major players did.

I'm still not convinced that it would've been more beneficial for the server-side guys to rely on the consensus with the client-side guys. It might've been, but it isn't obvious to me.