The ACTUAL Mir and Wayland Comparison

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?

Advertisement

24 thoughts on “The ACTUAL Mir and Wayland Comparison

    1. 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.

      1. Or just that Mark Shuttleworth seems to think buzzword-oriented development and sleazy marketing is the most important thing to have in a project.

      2. 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..

  1. 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?

    1. *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.

  2. 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?)

    1. No reason why there shouldn’t be co-operation, I can just understand why the divide might have happened.

    2. 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.

    1. I believe that is what the “unified” EGL is all about. Presumably proprietary vendors are/will provide that interface.

    1. Fuduntu is gone and replaced by the apparently not really yet existing Cloverleaf Linux (based on (open)SUSE … *barf*).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s