Today I got many questions about KWin and Mir, how it affects us, what it means for our Wayland plans and so on. I did not want to write anything about it because I think there is nothing to write about, but before answering the same question again and again I think it’s better to put down a few lines here. Wiki will be updated once Wayland wiki is updated so that we have something to link to.
First question: Does Mir affect us? Yes, obviously. Because of Mir I have to write this blog post, Wayland developers have to get the FUD out of the Mir documentation, it’s creating tension and it harms the development. We will have to face again and again the question whether Wayland is better or not. So yes it affects us and I’m not happy about it.
Second question: Does it affect our plans for Wayland? I think it would be very unprofessional if we would change our plans just because Canonical did an announcement that they want to do an own display server for Unity (we didn’t throw away Plasma because of Unity either). Whether Mir provides technical advantages or not cannot be judged right now, we will have to wait and see, then we can make a decision whether it’s worth to change our plans. So far I have not seen anything in the documentation that would look like an advantage over Wayland. Given the incorrect statements about Wayland I’m very skeptical whether there can be any advantages. I don’t want to go into detail, just look on the Internet there’s already enough information about that. Also one should consider that Canonical changes plans for their distribution every other day. Just consider the number of toolkits which have been used for Unity – given that I would not bet on Mir will be used next year and that means of course that we should not consider it for our planning.
Third question: Will KWin support Mir? No! Mir is currently a one distribution only solution and any adjustments would be distro specific. We do not accept patches to support one downstream. If there are downstream specific patches they should be applied downstream. This means at the current time there is no way to add support and even if someone would implement support for KWin on Ubuntu I would veto the patches as we don’t accept distro-specific code. If Mir becomes available on more distributions one can consider the second question. Given the extreme success of Unity on non-Ubuntu distributions I’m positively optimistic that we will never have to do the evaluation of the second question.
This whole Mir announcement just looks weird. Wayland took some time to just create the spec, after that it took some time to create reference implementation, now Canonical is just jumping in with Mir after (AFAIR) ~1 year of work? Is it Wayland core + some modifications made by them, or is it something completely new?
I really doubt that they have the man and brainpower to move this forward, they seem to be forking too much already. It seems that they want to be “the next Apple” and they are not willing to wait for this to happen.
Its ok to make custom DE or init, but creating whole new display server when X world is in so much flaky state since forever, it just seems wrong. They are shooting themselves in the foot with Mir.
as far as im informed it’s no fork.. its mostly some android input stuff and several new lines of code.. and the demo does not to much…
I saw a demo of it yesterday which was not very impressive at all until I saw this http://www.youtube.com/watch?feature=player_embedded&v=jWjsqcYJDLs I guess they should have included this when they released the news..
…might also just run on top of xmir.
And xmir It’s basically xwayland
https://twitter.com/hoegsberg/status/308706022447542272
Very disappointed in Canonical…
A lot of thoughts but no more comments…
so if canonical somehow manages to find a hundred top graphics developers that are experienced with the low level linux graphics stack and drivers and delivers a stable version of mir before 14.04 – and mir has suddenly become a great advantage over wayland – you hopefully will support mir even if no other distro uses it at this time..
but i think you are right to be optimistic..
but hey.. i wish him luck.. if they succeed.. i’ll definitely give it a try! i just wonder how they plan to pull it of..
No, as long as it is Ubuntu only we will not support it and cannot. To my knowledge no KWin developer is on (K)Ubuntu.
If you don’t mind me asking, what distro do you support / use?
I use Debian Testing
Maybe next move will be announcing Ubuntu PC (made by DELL or someone) so that they have a hardware platform they control as well.
This could cut a lot of development time if they want to do low level stuff.
It seems unlikely but those rumors about Mir were also unlikely.
The only advantage of Mir I can currently see is that its written in Qt/C++ and not in plain C. That should make the codebase a lot smaller and also better testable.
On the other hand, I don’t really blieve that the Mir-developers are very experienced, so the code could also be really messy.
I haven’t seen that it’s Qt based, the code I looked at was plain stdc++ and stl. Although I love C++ I’m not sure whether it’s the right language for low level systems.
And boost.
Why wouldn’t it be?
C++ sits halfway between trying to be like C and trying to have actual features like most any high level language. Problem with that is the two things tend to get in the way of each other, fundamentally the two are incompatible. Trying to paper over the incompatibilities (name mangling) introduces inefficiencies (support for exception handling needs to be provided even if your code does not use exceptions at all, because library code might; the job of the linker (ld) is vastly more difficult, too). Additionally C++ things like “objects” and “templates” simply have a certain amount of overhead (the need to maintain vtables, templates being essentially fancy copy-paste at compile time) which may not be acceptable for truly low level systems.
— That’s generic. Whether or not those issues matter for a display server (which inherently is going to be dealing with quite a lot of system resources anyway) is another matter.
— A major issue, though, is that writing C++ libs which can be consumed from non-C++ in any sane fashion is relatively difficult (starting with aforementioned name mangling), but also calling conventions. (Which for C tend to be relatively uniform across compilers and sometimes architectures but for C++ not so much.) That’s why C++ is often wrapped in C to generate reusable libraries, but that is not a solution once exceptions need to be thrown.
Totally agree. You just nailed it 🙂
C++ is not really good choice for a piece of software like display server.
I don’t think that writing a display server in C++/Qt is a good idea. A display server must be simple and slick without to many dependecies. Wayland does that right with it’s minimalistic C code base. But if you look at MIR’s example directory it has a really crappy code base (usleep to get 60Hz refresh rate and other bullshit).
It’s not using Qt. Don’t get confused. They plan to write the shell in QML but the window system is written in C++.
I don’t see a problem in using C++ over C. For such a thing, sure, would be preferable to use C.
The thing I don’t like in the code is that they use Boost. They should really avoid the overhead this adds, it is not just a simple desktop application…
Can you point out any *actual* overhead caused by the use of boost? Or is this just some random superstition?
using boost makes a *lot* of overhead
1) compilation takes much longer due to all the templates, and takes a lot more memory to build.
you probably won’t be able to build mir on a device with just 512MB of ram.
2) the templates will expand to much more code, bloating the binary
3) The C++ object model is heavily based on dymanic allocation. this is very slow and error-prone as it is hard to properly catch out-of-memory situations.
I just love your technical straight mind Martin!
So everyone wanting a real desktop for Ubuntu would have to run KDE on X on top of Mir?
No, they will install xorg packages, they will not be removed from the archive, just not installed by default (or the will install kde on wayland, but it may not be ready yet by that time :))
Cheers, now I can relax.
How far along is KWin for Wayland? I note that most of the blog entries I’ve read that speak about new Wayland developments is actually mostly about Weston getting closer to being a full window manager. Surely KWin should be ahead in some areas?
(…kwayland.)
On side note: I find it extremely funny how people say that “Red Hat is hurting Linux” (due to their work on Network Manager, systemd, Pulse Audio and other stuff), while almost no one says the same about Canonical. Hell, they even discourage people from installing Launchpad on own server! How is that “open source”?
The problem is not to publish the code or not. The problem is that the whole idea is permeated by control. That’s very different from systemd, Network Manager and PulseAudio, which have really been created with a better technical background and better collaboration mindset.
Canonical doesn’t need to create Mir, as all the community around Wayland have been saying for the last days. They haven’t even tried to reach for them. That’s my point of view.
What is Mir?
Mir is a russian space station crashed in to the pacific.
Good luck to Canonical and let’s hope history is repeating itself.
I surely hope history *won’t* repeat itself: the Mir space station lasted twice as long as it was meant to.
Mir is not just the name for a space station. In russian it is both the term for “earth” and “peace”.
“World” and “peace” to be correct.
Why people is whinning so much? This is just yet another project. I wish succes to the Canonical team
I find this whole thing very interesting, and hopefully our display server issue will be solved soon.
Honestly I dont see anyone puting X in the grave untill Nvidia and AMD are on board. And from my discussions with the Wayland group neather of those companys have showed any interest in Wayland “Note: Don’t ask Wayland devs about Nvidia or Ati!!”.
Situations the same on ARM, almost none of the vendors are willing to support anything other than Android.
Mesa isn’t doing so well eather, years behind Khronos specs and Nvidia offerings.
Then you have the whole Xlib vs XCB mess without going to much into this one ill just throw out a quote from stackoverflow in regards to xlib vs xcb. Note: I picked the first link I came across but those who actualy do lowlevel gfx programming the feeling is fairly universal…
“””
You can use both of them. XCB is simpler to use, has a better response to a multithread environment but lacks documentation, while Xlib is a more dated/complex tool, better documented and fully implemented.
In the end: if you aim to faster development, you should use Xlib, otherwise XCB is meant to be the future (but it’s still far from being such).
“””
and
“””
…the hardest thing to do is to find docs and good API references… Very true. Some of the official tutorials are riddled with errors and won’t even compile.
“””
I havent looked into Mir other than whats been reported online, now Wayland thats a differant story in its self, honestly everyone I know is hoping Wayland will offer a solution but its just not looking to good for Wayland at this point.
“We do not accept patches to support one downstream. If there are downstream specific patches they should be applied downstream.”, wow, then how KDE support Windows?
KWin is not supported on Windows.