Canonical's Mir Project Retracts Wayland Criticism
Phoronix: Canonical's Mir Project Retracts Wayland Criticism
If you are now to look at Ubuntu's Mir specification page for their new display server, you will see that their open criticism of Wayland/Weston has disappeared...
"different requirement" = nazi-style control and CLA.
so, classical NIH at its finest
Please folks (both Mir and Wayland devs), it doesn't matter that time has been wasted. What matters is that somehow you folks find common ground and work together openly.
It shouldn't really surprise me when Larabel's vitriol and narrow mindedness towards Ubuntu is reflected in these forums. I've lurked about here long enough to see it over and over.
Originally Posted by blackout23
It's still dead depressing though.
I guess Ubuntu will likely lose more users with moves like this, but lately, after reading these forums and comments like them, I wonder if that's actually a good thing. The more hate I see against Ubuntu, the less I'm tempted to start distro-hopping again. I sure as hell as don't love everything Canonical does, but they're the only ones I see trying to do better.
Better than... this.
To be honest I already hope they'll soon fork kernel (for the sake of completeness) close the sources of their own code and leave FLOSS and Linux be.
Originally Posted by blackout23
You mean like everyone uses Unity today? /facepalm
Originally Posted by BO$$
Yeah, for example by adding spyware/adware to their own half-baked DE.
Originally Posted by scaine
Last edited by prodigy_; 03-05-2013 at 03:56 PM.
well to be honest there is no technical reason to outcast wayland for mir, in fact im pretty sure wayland fullfil all their requirements and future plans too way more efficiently, so i suspect is a license issue[more than NIH] because they want nvidia/AMD/SOC blobs in their wagon fast, so mir is the faster way[if they ever deliver at all] to develop a server around blobs and not fully native drivers[wayland way].
about their input reason it sounds like bollocks to me, first is a very bad design idea to include input handling inside the main protocol since is way more efficient to pass the required action to the server/protocol and process the input handling outside, for example imagine this cases:
4. 3D input
5. future brainwave matrix tech
R1. in case 1 probably either solution is efficient enough since the information comming from any of those devices is quite simplistic but it can be way more interesting if they are processed separately and only send the server what action it should perform, so you dont have to rewrite half wayland/mir core code base to support 1080DPI 10 button uber mouse for mutants with 6 fingers
R2-5. same case, a hypothetical libgesture[and infrastructure] should handle/compare/process what your fingers are doing[touch movement/gesture/multitouch] and the client app should send a request to the server for X operation once libgesture send a positive match on a set of action the app preset to watch[two finger in a line rect if so tell server to show texture A otherwise hide it], now would you really want gesture processing inside the protocol/server definition? what happens if samsung release 6 months later a 10 finger touch screen instead of 5?. Now imagine this mess with something as massive a video processing for gestures in your carl heiss 40 MPixels tablet camera or you phone CPU locking trying to reduce background noise while you tell it to open a browser in rush hour, let me help you!! pure explicit pain.
so being wayland or any other system input should be handled and processed by specific subsystem that specialize in solving this events efficiently and pass to the protocol/server only what it needs to know and this that sense wayland seems the right solution[open to corrections if am wrong] beside i seriously doubt there is anything more efficient at power consumption/performance than wayland
Note that Canonical's Contributor License Agreement strongly discourages code collaboration. Requiring copyright assignment is pretty rare, and even rarer still when the assignee can take the code proprietary. It also discourages working together since it puts everyone not the assignee on a considerably lower footing.
Originally Posted by F i L