XBMC Ported To Run On Mir Display Server

[intellivision]

Once this whole Mir business blows up Canonical's face, they'll have to run back to Wayland with their tail between their legs, and all that will be accomplished is that they've wasted tons of money, resources and time of everyone involved.

I think that it's looking pretty good for Canonical, their phone project is gaining a lot of support and Mir is developing nicely.

[intellivision]

I don't claim Linux is innocent, either.
Also, I'm mostly ignorant on which approaches those follow. If the change is actually needed, the approach is really different and the goal as well, then maybe it's not an unnecessary breakage. As for Mir and Wayland and the several toolkits (well, only most of them), the goals seem to be shared, and in the particular case of the display servers, there doesn't seem to be significant difference on the approach, aside from Mir being a server (while Wayland doesn't mandate it to be that way, but gives you the freedom to) and doing server side allocation (same clarification for Wayland as before). I understand the difference between GTK and Qt for being a licensing issue, and at the time GTK started Qt was proprietary even. I, too, see the reason for FLTK, since this does differ in approach, trying to prioritize lightweight, while the rest try to be feature complete (this doesn't mean they are willing to waste resources, but they will prioritize features over frugality).

As for the competition, being loved and being healthy are two different things. I agree most people on the community love to compete. This doesn't make it any healthier for the ecosystem. In situations it is (different approaches might fit different users), in situations it isn't. I don't call it competition when goals and approach doesn't overlap, and that's why I can generalize competition is not healthy on open source. But having multiple solutions, if the approach and golas are significantly different may be a good thing.

EDIT: I just realized I completely misread your post. My correct answer follows.
Maybe it's true. But ALSA, I believe (I'm not really that into subject, so I might be wrong) is there to solve lots of problems. On upstart/systemd, based on the fact I toyed a bit with their configs, make it far easier to make a concurrent startup, so again, is not a breakage "just because". What I meant on the other point was actually hostile breakages, aimed mostly to break compatibility with everyone else. I don't know which the licenses are or if they depend on very specific Linux features, though.
What I do know is that apps don't usually rely on init systems nor are they aware of them, so it doesn't really break compatibility, and just improving owns system doesn't imply competition, but just looking for new features. With ALSA, I have to admit in some cases they do, in other cases they just use OpenAL which in turn chooses an available backend. ALSA I'm aware is GPL, since it's inside the kernel, and is likely to depend on Linux specific features, since there must be a reason why "Linux" is included on its name.

OpenRC does the same stuff as SystemD (without uDev) and OSS does the same stuff as ALSA, including simultaneous audio output from multiple applications. If they really wanted compatibility, there's no reason they can't fix that.

[mrugiero]

I'd recommend to post your distrubution you use in your signature and tell again that different aproaches are wasted resources.

I'm pretty sure nobody stated that. Personally, I repeated it to exhaustion, but again. Multiple projects with the same approach are wasted resources. Mir didn't show a significant difference to what Wayland does. All it does right now, and all I hear it's supposed to do, can be done with a Wayland compositor.

by the way Martin Luther didnt want to fork the church. And as far as i know he didnt.

Nope, the catholic church forked him out.

And as said we will see if its that bad. Like unity wasnt loved at the beginning.

Nobody is saying it will be technically bad, but that there is no reason to do so, because they proposed (as of now) no technical difference to Wayland

And as a company you need to tell investors that you have some kind of thing of your own that no one can change without your permission. they HAVE to do it.

[troll] So, they are a company when "they need something of their own" but they aren't when they request common folks to fund their phone prototype, so they don't share the profits. [/troll]
So, it's about politics, after all. Wasn't Wayland supporters the ones who only saw politics everywhere?

And stop being pissed off because others dont work the way you want. thats just so illeducated, self-righteous and intolerant! Pay them and then you'll get to judge their work and decisions.

Considering I'm doing free testing for them, I'm kind of paying them. Time is money.

and when someone writes it "SEEMS" then because the thing he is gonna say may not be 100% correct and WILL BARE some subjective portion. there really is no need to put him down because he doesnt have the time and maybe technical understanding to read the mailing lists himself. You ready newspapers dont you? But you probably dont read them all, compare and ask victims and witnesses for first hand information (though asking people is hardly the most objective thing in the world...)
And it is true, that there hasnt been much traffic on Phoronix over wayland just before Mir emerged.

[troll]So, the "it seems" allows me to say everything I want and expect people to believe me. It seems there are fairies downtown, guys, go see, go![/troll]

Mir probably will. It's developed in a much higher peace than Wayland. But I'm also thinking about the future when both are "done"
and Canonical says next Ubuntu version will have THIS and starts developing it with four months to go.

And there you have it again. A possible break in compatibility in Ubuntu?s Wayland compared to everyone else?s.

It's better for everyone to have two display servers than one that is incompatible with other builds of itself.

First, no, they didn't "start developing four months ago", they just announced it four months ago, and they acknowledge it. Development started around 9 months before that moment. Also, for what they'll do in 13.10 and 14.04, there is nothing missing on Wayland. They could use their own patches out of tree to add support for XWayland running a desktop, if they want. But since running a desktop over XWhatever brings no benefits over running it on X.org, they won't bother. For running a desktop in XMir, basically, you need a pageflipper. That's it. So, if that's what makes you think it's getting developed faster, then you might as well had running desktops on XWayland last year. XMir is nothing but XWayland adapted to run on Mir, so I wouldn't call this a faster development, but a port. Porting is in most cases something a lot faster than writing from scratch.
On the breakage, you can't seriously compare Wayland with client side allocations versus Wayland with server side allocations against Wayland versus Mir. We have a case where a dev just need to make a macro for creating the window that implies allocating the buffer in the case of client side and only calls for the window creation in the case of server side, against a complete rewrite because the APIs are completely different.

One of the greatest strengths of free software is precisely in that name - we're free to do what we want with it and to combine it in any way we like. By saying "It's Wayland or the highway, pal" you are attempting to construct a monopoly - the very same kind that plague the proprietary software world, and the reason why Richard Stallman started the GNU project in the first place.

Richard Stallman actually cares more about the community, and that's why he states there is a difference between open source (even GPL open source) and free software. Also, he started the GNU project because of programmed obsolescence of a printer: the manufacturer didn't want to provide drivers for a newer version of an OS, so he started coding it himself. He wanted people to share, that's what he considers the four freedoms, and everyone to get the benefits. As it is right now, the only ones who could benefit from Mir are Canonical. I'd like to know his real opinion on the matter, I think I'll mail him.

I thought it was quite clear by now that the goals of Wayland and Mir are not the same. They're close, but they're not the same.

Oh, really? Point out the differences. As I said tons of times before, I'm open to change my mind if anyone gives me a good reason. As of now, I read all the articles I've found, and I saw nothing to justify this. Even when there are slight differences between how the reference compositor does things and how Mir does things, all of them seem to be shallow enough to just require a different compositor.

I think that it's looking pretty good for Canonical, their phone project is gaining a lot of support and Mir is developing nicely.

I'm still waiting for that ugly cursor to go out of my screen. It was supposed to be fixed in 0.0.7, but they didn't upload it to the PPA (it's in another one, mir-edge I believe, but testing that would make no good for anyone, since I'm using the one they want me to), even when just released 0.0.8.

[mrugiero]

OpenRC does the same stuff as SystemD (without uDev) and OSS does the same stuff as ALSA, including simultaneous audio output from multiple applications. If they really wanted compatibility, there's no reason they can't fix that.

I'll take your word, then. I didn't state they wanted compatibility, though, but not caring is not the same as actively trying to hurt them.

EDIT: I'd prefer them to care.

[Ishayu]

Richard Stallman actually cares more about the community, and that's why he states there is a difference between open source (even GPL open source) and free software. Also, he started the GNU project because of programmed obsolescence of a printer: the manufacturer didn't want to provide drivers for a newer version of an OS, so he started coding it himself. He wanted people to share, that's what he considers the four freedoms, and everyone to get the benefits. As it is right now, the only ones who could benefit from Mir are Canonical. I'd like to know his real opinion on the matter, I think I'll mail him.

As far as I know this is just what pushed him over the edge. He was an integral part of the hacker community back then, and he was disappointed with the corporatism of it which caused things like planned obsolesce, and restrictions on his freedom to inspect, change, and share his software with friends.

Anyway, you're most certainly welcome to send him an e-mail. I'm extremely interested to know this, myself. To be honest, I don't think it cares, but I'd love to know for sure.

His stated difference between open source and free software is purely in the naming as far as I know. He didn't like the term "open source" because it shifted the ideals of the movement away from the political implications and over to the practical implications of his ideas. Both terms are all about the community sharing and helping each other, but free software wants it because it is ethically right to let the users control the program, and open source does it because it means more people can inspect the code and fix bugs.

Oh, really? Point out the differences. As I said tons of times before, I'm open to change my mind if anyone gives me a good reason. As of now, I read all the articles I've found, and I saw nothing to justify this. Even when there are slight differences between how the reference compositor does things and how Mir does things, all of them seem to be shallow enough to just require a different compositor.

The main difference is not actually in the software itself, but in how it is maintained. Wayland is going to be defined as a standard, i.e. similarly to X.org there are a certain list of functions that must be there in exactly one and only one form. Mir does not try to make such a standard, and so the API may change over time.

Secondly, Mir is designed to switch smoothly between using the SurfaceFlinger drivers from the Android world and the free drivers we know from Linux on the desktop. As far as I know, Wayland can't do this. It can use both (although SurfaceFlinger support was added AFTER Canonical announced Mir) but it can't smoothly switch between them without a flicker, and due to the defined standard it can't do it. As far as I know this is because Mir uses server-allocated buffers while Wayland does not - and never will because of the rigid standard.

[V10lator]

although SurfaceFlinger support was added AFTER Canonical announced Mir

Libhybris was written for Wayland BEFORE Canonical announced Mir.

As far as I know this is because Mir uses server-allocated buffers while Wayland does not - and never will because of the rigid standard.

You can use client side buffers with Wayland just fine. But keep spreading the FUD!

[mrugiero]

The main difference is not actually in the software itself, but in how it is maintained. Wayland is going to be defined as a standard, i.e. similarly to X.org there are a certain list of functions that must be there in exactly one and only one form. Mir does not try to make such a standard, and so the API may change over time.

Yet, they say they'll keep the API stable. Will it change, or will it not change? Also, remember how Windows developers praise the fact on the Linux world APIs are broken periodically? Oh, right, they don't, they complain about it. So, if you want people to migrate to Linux, you want developers to code for it, and thus, you want them happy, with stable APIs. I'm aware of that difference, but since it's not in the software itself, it's not in the approach the software follows. Also, Wayland only mandates you to follow compliance to the protocol. Your compositor may do whatever it wants, as long as it respects the protocol.

Secondly, Mir is designed to switch smoothly between using the SurfaceFlinger drivers from the Android world and the free drivers we know from Linux on the desktop. As far as I know, Wayland can't do this. It can use both (although SurfaceFlinger support was added AFTER Canonical announced Mir) but it can't smoothly switch between them without a flicker, and due to the defined standard it can't do it. As far as I know this is because Mir uses server-allocated buffers while Wayland does not - and never will because of the rigid standard.

Wayland can use Android drivers, since the library Mir uses to do so is designed for Wayland.
As for server-allocation of buffers, Wayland lets you do so, just Weston (a reference compositor) doesn't use it. But nothing on the protocol (the standard you must follow) mandates either way of allocation. And there is a demo using server allocation on Wayland, so yes, it will be able, because it's able right now. In fact, even Canonical doesn't spread FUD about it, since Christopher Halse Rogers himself said it's only Weston the one who can't do server side allocation on his first article.
On switching drivers smoothly, I can't see how this is needed at all. Either you go with our drivers or you go with the others. Either they fit a particular user or doesn't. There's no reason to really care about switching smoothly, since this should be done at most once on the lifetime of the OS.

[Ishayu]

Yet, they say they'll keep the API stable. Will it change, or will it not change? Also, remember how Windows developers praise the fact on the Linux world APIs are broken periodically? Oh, right, they don't, they complain about it. So, if you want people to migrate to Linux, you want developers to code for it, and thus, you want them happy, with stable APIs. I'm aware of that difference, but since it's not in the software itself, it's not in the approach the software follows. Also, Wayland only mandates you to follow compliance to the protocol. Your compositor may do whatever it wants, as long as it respects the protocol.


Wayland can use Android drivers, since the library Mir uses to do so is designed for Wayland.
As for server-allocation of buffers, Wayland lets you do so, just Weston (a reference compositor) doesn't use it. But nothing on the protocol (the standard you must follow) mandates either way of allocation. And there is a demo using server allocation on Wayland, so yes, it will be able, because it's able right now. In fact, even Canonical doesn't spread FUD about it, since Christopher Halse Rogers himself said it's only Weston the one who can't do server side allocation on his first article.
On switching drivers smoothly, I can't see how this is needed at all. Either you go with our drivers or you go with the others. Either they fit a particular user or doesn't. There's no reason to really care about switching smoothly, since this should be done at most once on the lifetime of the OS.

I stand corrected.

However, I still believe that the API being controlled by Canonical is the main reason why Canonical decided to make their own.

But frankly, if nearly every component is the same anyway... why are people so pissed about it?

[mrugiero]

I stand corrected.

However, I still believe that the API being controlled by Canonical is the main reason why Canonical decided to make their own.

But frankly, if nearly every component is the same anyway... why are people so pissed about it?

Yes, most of us say the real reason is for the API to be controlled by Canonical, and one of the reasons most people is pissed off is because instead of saying so, they keep pointing fictitious problems, or making vague statements that tend to show Wayland as a half-assed, crippled solution it's not. For example, the bold claim Mark did about Wayland sharing all of the X.org problems, while not clarifying what he bases this claim on.
About being pissed despite both are almost the same anyway, it's because the API is different, and that means the software you write (except when targeting a toolkit, but there are cases where this is undesirable) can't run on both seamlessly, you need to make a backend for Wayland and another one for Mir. If they'd implement it as a Wayland compositor, they can expose their own API, but things written for Wayland will run on their compositor seamlessly, because they'd support also the standard protocol; if the Mir API is supposed to be used for apps, though, the incompatibility will still be there; it solves the problem if that API is meant only for Ubuntu and Unity specifics, since this could be done without messing with anyone else. In the worst case, you'd need to macro the window creation to allocate on the client or not, according to the model your compositor use (or maybe even be announced by the compositor, so you can check on runtime).

[jayrulez]

Yeah! Like the Suffragettes, the Solidarność, like the women in The March on Versailles, this old guy Mandela who spent many years on Robben Island and the Boston Tea Party participants. Fools all of them! Why did they ever bother complaining...

...Because complaining on Phoronix forums is equivalent to the Suffragettes, the Solidarność, like the women in The March on Versailles, this old guy Mandela who spent many years on Robben Island and the Boston Tea Party participants. They were doing what they did in the back streets among the 5 other people in their situations...