If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

And it won't be Mir. As Canonical stated, they develop Mir aimed especially for Unity, so everyone that does not use Unity (like Red Hat or Suse, you know, those companies that actually make money with Linux, unlike Canonical) will rather back up Wayland, since Mir may just break (intentionally or not) for other DEs. No sane company will make use exclusively of a product where they have no say about the development at all, so Wayland is naturally the way to go, not Mir.

since Mir may just break (intentionally or not) for other DEs. No sane company will make use exclusively of a product where they have no say about the development at all, so Wayland is naturally the way to go, not Mir.

Orly?
Let's just assume, Mir will be fucking awesome and will beat the shit out of Wayland:
Why exactly would anyone NOT use Mir and go for Wayland instead? If Canonical decides to go another direction, Mir can be forked and everyone is still happy.

If this happens and looking at the deveolpment pace of wayland it looks like we will be on X.org for a long time. Which I have nothing against. I still consider both Wayland and Mir as just fads adding nothing for the end user, just ways for those programmers to think they're the shit. X.org could have been improved, no need to reinvent the wheel. This whole thing will create horrible pains for the end user just so these people can get their way.

the problem witb "Xorg could have been improved" is backwards compaitibility and an established standard. X12 would be assumed to be backwards compatible with X11, and despite X.org being the X consortium now (I'm actually not sure if they are the sole member..) they'd still have to listen to anyone with any stake in X11 for X12 development.

hence Wayland. No one beyond the Wayland devs has any say in what happens, limited politics, no guarentee of backwards compatibility and therefore no mandatory legacy cruft. that being said Wayland IS BC due to XWayland which is good.

oh also X12 would probably be forced to speak the traditional X protocol which you can see why on the Wayland faq that's an issue. also it was a chance to experiment with the idea of "clients in control" instead of "centrallized server in control" though Mir is going back on that.

We've reached the point where the current usage of desktop graphics (compositing bitmaps painted by clients application running toolkit libraries like Qt, GTK, ... and the compositing isn't even done by X.org. The X server only passes things around) has absolutely nothing to do with what was X11 back when it was developed (a way to send synchronously a stream of painting commands [draw/fill/blit/print text] to the X server for it to paint them on the framebuffer).

Under the hood X11 is already a huge "turtles-all-the-way-down"-style pile of patches trying to circumvent and fix all the current short-commings. All this with an increasing complexity due to partly the sheer number of patchings/fixing that has been going on lately, and partly due to the fact that the same modern X server that has to live in a world of application-bitmap-compositing, has to be backward compatible all the way back to the "stream of painting commands" days, including all the various cruft accumulated along this way.

At some point of time, it might be a good idea to start implementing something modern, that ditches all the historic backward-compatible shit, and does more efficiently what is currently expected from modern display stacks. Hence experimenting with Wayland (on which several X veretans are working, so they develop it knowing very well what all the past problems where and what all the current X short comings are).
But this kind of complete rewrite should NOT be rushed. Devs need to take time to make sure that everything works nicely, that by trying to run away from old problems, we didn't run into newer ones, that everything works nicely, and that the end-user experience isn't disturbed by the change. (In other terms: avoid the outrage that Gnome 2 to 3 or KDE 3 to 4 switching provoked).
Hence the slow pace of development of Wayland development.