I have always had somewhat mixed feelings when talking about ubuntu.

I have always had somewhat mixed feelings when talking about ubuntu. mostly because I have never tried it. Not once. In many ways that disqualifies me from saying anything about the user friendlyness (I understand it's good) and Unity (a little more mixed I understand). My reason for staying away has always been that Canonical seem to suffer from some kind of amnesia in all their PR. Where do you find any mention of Linux or GNU? No, it's all Ubuntu. Even 'Ubuntu kernel'!

This is the third article here on G+ today in my circles about the same issues. As with the posters, I do not deny Canonical the right to build their own silo or otherwise make money on Linux. That is just fine. But I must say Red Hat feel like they are contributing immensely more back to the open source community than canonical does. They also let Fedora free, so they do not suffer from the kind of top-down attitude Canonical seems to have with their community.

This piece by Aaron Seigo is very good. Even if I haven't tried KDE for years his points should be easily understood.

Originally shared by Aaron Seigo

I'm not one to shy away from discussion for fear of being right or wrong, but simply in the attempt to actually get things straight and share my current best understanding with others. A week or two ago I wrote a bit here about Canonical's vision for device-spectrum computing and how it was nowhere to be seen in their code, at least not in the fashion that their PR bits would like people to believe.

So today we get a fresh new bunch of information (see link below), and here's a not-so-quick review of what this new info brings to the discussion.

One of the important assertions made is that convergence is achieved by having a single display server and application API across devices. If this were so, then we'd have it today already since we commonly use X.org and various toolkits across device formfactors. XFCE on X.org would be a convergence UI. Which it isn't. So that's rubbish and should simply be ignored as any sort of valid motivation for writing a new display system.

The existing application API also does not provide what is needed for device-spectrum interface development. I won't go into why that is since it would not only make this posting even longer, but because I have no desire to help Canonical by pointing out actionable problems in their stack. Why this is so will become apparent below.

Where Canonical's claim to be working on a "convergence" system does start to conform to reality is the idea of a single desktop shell and window manager that adjusts depending on context. Interestingly, that's what we've been doing in Plasma Workspaces for a few years now. So that part is not rubbish.

(By the way: the practice of changing the names on everything they use that could remotely be traced back to others says something about the thought processes. See, they don't use Status Notifiers .. no, they have Application Indicators. They don't do "device spectrum" they do "device convergence", etc. It would be understandable if they were the first to any of these ideas, but they aren't; and it makes having conversations about these issues so much more complex than it needs to be. Anyways ...)

Turns out Canonical is working towards that vision by re-writing desktop-Unity  in Qt/QML. They state that there will be some UI pieces that are form factor specific, and that's sensible; nothing to quibble with there. This rewrite is still nowhere to be seen, and given the number of direction changes we've seen this far it's anything but a sure bet, but I'll give them the benefit of the doubt here. Once they have that beast done (April 2014 is the target, apparently) they will possibly be one step closer to having the device spectrum technology I called them out on. So it is possible that in a year's time I will be wrong on that one part. It's also possible that their shell doesn't .. well .. again, I really don't feel like pointing out the obvious (to me, anyways) technical limitations in their current designs.

The truly crazy part is that they are writing their own display manager to accomplish this. They dismiss Wayland, though it has pretty much the same design. The main differences are that Canonical doesn't control Wayland development and Canonical's system will weld everything into one process: display manager, desktop shell, window management, output management, input event handling ... It's an interesting approach. Not one I'd take for technical reasons, but hey ..

The biggest issue I see is that they are going it on their own and diverging from the rest of the Free software ecosystem with a software stack they have been developing behind closed doors and which will require you to sign over your copyright in order for you to contribute to it.

They have effectively sealed themselves off from the rest of the Free software world. They will shoulder porting and maintaining Qt, Gtk+, XUL, etc. to their system. They will shoulder porting applications to the integration points (most of which will be delivered in Qt apps). They will not be sharing desktop shell infrastructure with anyone else, and using their Free software on other platforms will become increasingly more difficult.

All of this depends on a couple of high level designs that are filled mostly with TODOs. So perhaps in a year's time (probably more) they will have delivered what they have said they are doing right now, and my objection will then be erase. If that happens, it will be at the cost of becoming another "not really Linux" Linux that lives in its own universe. It will be Android minus Google.

Before closing, I would like to point out that Canonical is once again trying to rewrite the present as well as history as can be seen in the intro of the UnityNextSpec: "From the very beginning, Unity's concepts were tailored with a converged world in mind, where the overall system including the UI/UX scales across and adapts to a wide variety of different form factors." Looking at the very beginning of Unity right up until today, this is obvious nonsense. The rest of the spec spends its time explaining why none of the original design decisions in Unity will also translate other than it being a shell "a shell, with a launcher, indicators, switcher, dash etc.". Well .. yeah.

Moreover, in http://www.markshuttleworth.com/archives/661 Mark Shuttleworth stated that "Unity was simply the new name for work which has been ongoing since 2007: The Ubuntu Netbook Remix interface." and if we look at the original UNR none of these principles are seen to be at work. None. Eventually UNR was made to use Unity but still with none of the ideas apparent in the implementation. Ubuntu TV is similar in this regard.

Also keep in mind how the move to Qt was positioned by Canonical: "The decision to be open to Qt is in no way a criticism of GNOME. It’s a celebration of free software’s diversity and complexity. [..]  Our work on design is centered around GNOME, with settings and preferences the current focus as we move to GNOME 3.0 and gtk3." From http://www.markshuttleworth.com/archives/568 just two years ago.

What is perhaps a more accurate statement is that Canonical fumbled through various ideas and technologies iteratively until they landed on the current concepts, dictated in part by technology and in part by business. There is nothing wrong with this, it's often how creativity happens. It is not, however, the 6 year prescience being claimed .. especially as we're still at least one year away from possibly seeing the current vision being achievable in practice.

So we have a new separate silo competing with the rest of the silos plus the open efforts (e.g. Wayland) while we are asked to accept a rewrite to a history Canonical is evidently not proud of ... "but this time it will be different, guys!"

All that said, by next spring, I might end up being wrong about the shell being form factor specific. If that does end up being the case, I apologize in advance, and I will reiterate that statement if it comes to pass.

(To be clear: Other than the shell itself, I stand by my claims as strongly as I did a week ago. That is based on reading code, going through design documents and published specs. I would suggest that if you haven't done that, you aren't in a place to offer a critique.)
https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/036776.html