As someone who has experience with both codebases, I feel qualified to answer this question.
Mir: More focus on unit testing, less experience with the linux graphics stack.
Wayland/Weston: Less focus on unit testing, more experience with the linux graphics stack.
Done. Can we move on to something else now?
24 thoughts on “The ACTUAL Mir and Wayland Comparison”
what does “experience with the linux graphics stack” mean?
In terms of the people behind each.
If there aren’t any other differences between Mir and Wayland, then why does Mir even exist?
Different development approach. “I want to do things this way, you want to do things that way”. See GNOME and KDE and every window manager ever.
Or just that Mark Shuttleworth seems to think buzzword-oriented development and sleazy marketing is the most important thing to have in a project.
That is circular reasoning. What you’re saying is that what they are doing different in Mir and Wayland is that they are doing things different in Mir and Wayland.
You are never mentioning WHAT it actually IS, that they are doing different.
Anyway… They are both shat out of the ass of the iTard generation that invaded Linux, destroyed ETIAF, and holds KISS (read: dumbing down to crippling “simplicity”, like W[i]nd[O]w[S] [X]8.) as its highest “ideal”.
Most of them can’t even handle text config files anymore. Hell, they don’t even comprehend the concept of a package manager, and try to replace it by a “app shop”, despite the latter being a retarded content-Mafia-enabled abomination of the former..
Sounds like there could be some synergy there…
Okay, so here’s a question: If Wayland is a protocol / tech spec / library dealy, with Weston being the reference implementation of Wayland, is there any way for Mir to also support Wayland clients?
*shrug* The compositor and protocol on each are separated. I don’t see any reason why the mir compositor couldn’t support graphics buffers being communicated over the wayland surface protocol, though that would depend on whether or not mir’s compositor “bit” actually has similar attach/commit semantics as weston.
Question: Do you know if the MIR system will support input transformation? (I think wayland was going to support that, but I could also be mistaken?)
*shrug* I don’t work on Mir. I’ve just worked with the codebase.
“With wayland, we are lucky in that right now that we only have weston as the more or less de-facto compositor and window manager.” (https://smspillaz.wordpress.com/2012/12/24/sideways/)
So “[l]et’s work together and make something amazing” instead of reinventing the wheel because of a lack of focus on unit testing (?)
No reason why there shouldn’t be co-operation, I can just understand why the divide might have happened.
Also I might add that having a rigorous QA process is something that is severely under-appreciated within the free software world, probably because it tends to inflate both codebase size and development time, neither of which the hacker types particularly like.
Maybe cannonical should hire developers to write unittest for wayland. 🙂
so……….. could “proprietary” drivers for Mir be made to work on wayland/weston?
I believe that is what the “unified” EGL is all about. Presumably proprietary vendors are/will provide that interface.
You realize that the official Intel driver is 100% open-source?
Not everything at Intel is evil. Only most.
For the compiz stuff, there’s Fuduntu for example. I guess they are in the right direction….
Fuduntu is gone and replaced by the apparently not really yet existing Cloverleaf Linux (based on (open)SUSE … *barf*).
I am sure you noticed the date of my reply, hadn’t you BAReFOOt?
Reblogged this on txwikinger's blog.