I'm not stating such a thing. They didn't state any valid technical reasons that I know of and that weren't refuted. They might be evil, as much as any other company that just cares about their money. Red Hat is such another, and Intel the same. I happen to agree with some of the things they are doing right now, but that doesn't blind me to know they do it because it's good business for them and nothing else.Quote:
I really don't see the problem with multiple display servers. In the end I am not willing to believe that Canonical decided to spend resources, receive never ending bashing and risk their existence just because they don't want to collaborate or because they are evil.
However, there is the matter of control, which is the only speculation I can come up with, based on the few things that I got to know (for example, that most technical reasons, at least the ones given on the announcement, were wrong). It could have also been a mistake. But if so, they are just making it worse by not admitting it and stopping the resource waste. Business-wise, the control they get might be good business, but it might also be a mistake, since carriers could just take Wayland for free if they want.
It is not the same old story as Unity, for a simple reason: you might dislike the flavor, but the only fragmentation it introduced are the resources Canonical invest on it. It doesn't bring problems to anyone else, nor extra work. The only valid reason to complain is that it doesn't suit you, and that's easily solved by not using it. I don't extremely dislike it (I use it at college), but it's far from being my favorite. I like better the traditional desktop metaphor. I'm aware such a thing is a matter of personal taste, though. Mir and Wayland are a different story, it's closer to toolkits conflicts than to DE conflicts, and you should be aware of that.Quote:
It is the same old story like Unity. And in the end Unity became a masterpiece of speed and productivity...
I'm not bashing Mir to the ground, either. The only thing I stubbornly dislike is XMir for running desktops, and even though I do (I have my reasons, which I won't discuss if you don't want me to), I admit most of the problems it could have brought are solved by now; the only remaining I can think of, aside for the current lack of blobs support (not a problem that could remotely affect me), is the possible confusion on who to blame for bugs; this one will probably mean upstream will not check possible bugs on X if they appear in Ubuntu, until further confirmation by someone running stand alone X. I'm just tired of the denial of the problems that could arise because of such a choice to create Mir, and I think it was reckless to create it before trying to go the upstream way. The way I see it, you need a very good reason to take the risk of fragmenting the desktop, and I haven't seen any technical one. Remark the "risk" word, because I don't think it's something that will inevitably happen, but that is possible.Quote:
I don't say I like or not Mir. I want to see it. I didn't see any fragmentation or lower development pace for Wayland yet, so.. Don't forget XBMC was ported to Wayland and Mir in a week.
On the tastes front, my favorite DE is XFCE, so I will probably use the infrastructure I think is most advanced that it can run on, which right now and probably for the next year is X.org. Later, I think it will be Wayland, but there are no proofs to such idea.
EDIT: Also, the fragmentation will obviously not appear ON Wayland, but it would (if it does) appear on the apps relying directly on some part of the display infrastructure. As I said in another post, this is almost completely alleviated by toolkits, except for DEs. As long as nobody dares to talk directly to libwayland or libmirclient, the fragmentation will be reduced to the same introduced by DEs, which is just multiplied efforts on such projects. On the XBMC thing, I'm aware, but I didn't look through the code to check how it was done. If done through an abstraction layer, this means extra overhead. It's kind of like having the compatibility layer like I said before. Of course, such a thing would be needed to support at the same time X.org and Wayland, so the only difference would be when/if X.org support was dropped. If it were just Wayland, you would be able to drop the extra abstraction, reducing function calling overhead, while being there Mir and Wayland it will still be two different platforms on Linux to support, meaning the abstraction should stay there. Anyway, I think it's probably just minor overhead, I was just pointing it out.