Originally posted by dee.
View Post
Announcement
Collapse
No announcement yet.
XBMC Ported To Run On Mir Display Server
Collapse
X
-
Originally posted by mrugiero View PostI 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.
Comment
-
Originally posted by jakubo View PostI'd recommend to post your distrubution you use in your signature and tell again that different aproaches are wasted resources.
by the way Martin Luther didnt want to fork the church. And as far as i know he didnt.
And as said we will see if its that bad. Like unity wasnt loved at the beginning.
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.
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.
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.
Originally posted by Pajn View PostMir 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.
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.
Originally posted by Ishayu View PostOne 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.
Originally posted by Ishayu View PostI 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.
Originally posted by intellivision View PostI think that it's looking pretty good for Canonical, their phone project is gaining a lot of support and Mir is developing nicely.
Comment
-
Originally posted by intellivision View PostOpenRC 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.
EDIT: I'd prefer them to care.
Comment
-
Originally posted by mrugiero View PostRichard 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.
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.
Originally posted by mrugiero View PostOh, 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.
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.
Comment
-
Originally posted by Ishayu View Postalthough SurfaceFlinger support was added AFTER 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.
Comment
-
Originally posted by Ishayu View PostThe 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.
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.
Comment
-
Originally posted by mrugiero View PostYet, 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.
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?
Comment
-
Originally posted by Ishayu View PostI 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?
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).
Comment
-
Originally posted by CrvenaZvezda View PostYeah! 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...
Comment
Comment