Linked by Thom Holwerda on Fri 8th Mar 2013 16:13 UTC
Ubuntu, Kubuntu, Xubuntu Mark Shuttleworth: "I simply have zero interest in the crowd who wants to be different. Leet. 'Linux is supposed to be hard so it's exclusive' is just the dumbest thing that a smart person could say." He's right. Lots of interesting insights in this blog post - I may not agree with everything Ubuntu does, but at least it's doing something.
Permalink for comment 554778
To read all comments associated with this story, please click here.
RE[7]: Comment by Laurence
by Lunitik on Fri 8th Mar 2013 22:16 UTC in reply to "RE[6]: Comment by Laurence"
Member since:

I am quite sure their rationale for writing Mir was based on the situation when the project was started. It seems that in the mean time, Wayland/Weston have fixed the issue and so the rationale was no longer applicable. If you read the complaints pertaining to input, for instance, it seems to be something recently fixed in Wayland/Weston and thus something so fresh in the minds of those developers.

What about how Canonical has gone about things doesn't leave you hopeful? There were no false starts with Unity, there was a Netbook addition which was apparently started before bringing in real design people. Since then, there have been two implementations that shared most of their code: Unity2d and Unity3d. Unity3D was functional, and the lead developer of Compiz was around working on it. Whether he left because of Mir or Mir was written because of his complaints related to Wayland is unclear (he at least said in his blog that he doesn't want to implement Wayland in Compiz) but that situation changed. Unity2D was a test essentially, and was used in Ubuntu TV. It seems that Ubuntu Touch is using Qt5 though, along with QML2 - neither of which were around for Unity2D. Experimenting with this, they seem to have decided it was better, but prior it seems Compiz+Nux was better for their use. Compiz was a technology that served Unity well enough, but I think Qt5 offers far more for developers. For me, what you call false starts are really just a display of the developers being dynamic, utilizing the best technology available while maintaining a consistent feature set. Looking at the Ubuntu Touch interface, it seems to me they have made the right decision, I do not think that would have been possible with what they had before - yet, still we see the basic elements are the same, evolving naturally despite being radically different, amazing!

I have brought up SurfaceSlinger to show another example of a company neither going with Xorg or implementing Wayland. They have preferred to develop an alternative because these options are not aligning to their needs. We have to understand that SurfaceFlinger is C++ too though, and was what the Ubuntu Touch interface was implemented on in the examples we've all seen. It would be surprising to me if Mir didn't reuse a lot of SurfaceFlingers code, and I would bet the test-based development of Mir has been done based on it - they write test cases for what is required by a feature they want to implement, then see if the code matches the test case.

I think this kind of development lends itself to the complexity they are aiming for. By coding to satisfy a testcase, development is far more deliberate and thus can happen with a sort of tunnel vision. It also permits the developer to actually see their advancements and thus become more motivated to move onto the next step. I think this is how they have managed to keep Unity consistent across the four toolkits it has been implemented in - whatever it was before nux, nux, qt4 and qt5.

I think Mir is primarily being done because Canonical do not like the Wayland protocol, I do not think it makes sense for a whole other IPC just for the client and server side of the display server to talk. It is essentially repeating the mistake of X11, where again we have an IPC which probably made sense back then, but now no one really actually understands it. Something else I like is that Canonical has said they will only implement features that are necessary, that bloat will not become a factor.

Essentially, all a display server really ought to be doing is handling all form factors and different display configurations, and communicating that to hardware. Input is already in the kernel, drivers are already in the kernel, everything else should not be dependent on a particular IPC unless it is DBUS.

Reply Parent Score: 3