Planet Bazaar

A repost of Martin Gräßlin's blog Mir in Kubuntu for the benefit of Planet Ubuntu

As you might have seen in Jonathan’s blog post we discussed Mir in Kubuntu at the “Mataro Sessions II”. It’s a topic I would have preferred to not have to discuss at all. But the dynamics in the free software world force us to discuss it and obviously our downstream needs to know why we as an upstream do not consider Mir adoption as a valid option.
This highlights a huge problem Canonical created with Mir. I cannot just say “Canonical sucks”[1] to discard Mir as an option, I have to provide proper technical arguments why we won’t integrate Mir. I have to invest time to investigate the differences, advantages and disadvantages. As I have those arguments, I thought it might be a good idea to share them in a blog post.
The discussion started during a presentation about X11 and Wayland to my fellow team mates at Blue Systems. I decided to first explain X11 as I think one cannot understand the needs for Wayland without understanding X11. I did not intend to discuss Mir at all, but somehow the discussion drifted into the direction and the valid questions were raised about what are the differences and advantages of Mir or Wayland. What followed was kind of a rant about Ubuntu and Canonical [2]. So later the week we discussed “Mir in Kubuntu” in more detail to try to find answers to the many questions this raises for our downstream.
Introduction
Frustration and lost Motivation
Before I go into more detail I want to make one thing clear: Canonical is totally allowed to develop whatever they want. I’m totally fine with this and don’t care whether they develop another display server, an own os kernel or yet another desktop shell. I couldn’t care less. It’s Canonical/Mark’s money and he can invest it in any way he considers as useful. I wouldn’t even care if it would be proprietary software, that’s all fine.
What is not fine is causing a major disruption in the free software ecosystem by giving false technical arguments and doing bold statements about software Canonical does not contribute to. This is not acceptable. This was very frustrating and destroyed lots of trust I had in Canonical. It will be difficult to rebuild this trust. Canonical can be glad that it is the free software world and not the normal corporate world. There were quite some statements which could have raised the legal department in the normal corporate world[3]. It also cost lots of motivation at least on my side and I even questioned whether it’s still worth to be a member of the free software ecosystem. Instead of working together we now have a situation where members of the ecosystem become a competitor and which badmouth part of the software stack. A very frustrating situation.
There certainly are valid reasons for developing Mir which also make sense. Unfortunately they have not been presented so far. I’m quite sure that I know the reasons and if they would have been said straight away it would have been for me and other projects probably much easier. It would have taken away the frustration which the announcement caused and we would not need to discuss it at all, because those question marks would not exist. But apparently Canonical decided to give false technical arguments over the real ones.
Not ready yet
At the moment Mir is not there yet, this is important to remember. With the announcement we basically had four options on how to handle the situation.

1. Continue with the Wayland plan and ignore Mir
2. Switch to Mir and ignore Wayland
3. Support Mir and Wayland
4. Delay decision till Mir is ready

If I map our time line for Plasma Workspaces 2 against the time line of Mir I see no overlap. We want to support Wayland before Mir is ready. So delaying the decision would be a rather bad idea. It would just throw us back. This also means that option 2 is not valid especially as we would need to delay till Mir is ready for this to happen. So the only valid options are supporting both Mir and Wayland or only Wayland. At the moment the code is not ready yet to properly decide whether supporting Mir in addition to Wayland is a valid approach or not. Last time I checked the source base I hit a few stubs and then obviously stopped looking at the code as it’s not worth the effort yet. So we have to evaluate on the knowledge we already have and that doesn’t look good on the Mir side.
Wayland vs Mir
Possible Advantages of Mir over Wayland
The differences between Mir and Wayland are rather minimal. One of the differences is that Mir uses server allocated buffers while Wayland uses client side buffer allocation. I cannot judge whether this is an advantage or disadvantage. But I trust Kristian and the Wayland team more on that topic.
Another difference is that Mir uses test-driven development. To me development methodology is not a technical argument. I rather use a working system without unit tests than a system with unit tests that doesn’t work [4]. Also KWin does not use TDD. If I would consider TDD superior I would have to question my own development methodology.
But that’s it. That are the differences I found so far which could count as an advantage for Mir. But of course there is the advantage that Mir is going to be awesome. For the disadvantages I will spend a complete section on each point.
Distro specific
So far Mir is a one-distribution solution. So far no other distribution has shown any interest in packaging Mir even if it would become a working solution. Unfortunately I don’t have the ability to see into the future, but I can use the past and the present to get ideas for the future. The past tells me that there are other Canonical specific solutions which are not available in other distributions. I do not know of any distribution which packages Unity and from all I have heard it’s even impossible to package Unity on non-Ubuntu distributions. Given that it is quite likely that Mir will go the same road. It’s designed as a solution for Unity and if distros don’t package Unity there is no need to package Mir.
This has quite some influence on a possible adoption. I do not know of any kde-workspace developer using (K)Ubuntu. I do not see how anyone would work on it or how we should be able to review code or even maintain code. It would mean all the adoption would have to go into ifdef sections nobody compiles and nobody runs. This is the best way to ensure that it starts to bit-rot. Even more our CI system runs on openSUSE so not even the CI would be able to detect breakage. Of course a downstream like Kubuntu could develop the adoption and carry it as a patch on top of upstream, but I would highly recommend them to not do this as KWin’s source code churn is too high. Also we all agree that downstream patches are evil and we would no longer be able to help in any way downstream’s user from a support perspective.
Architecture
Mir’s architecture is centered around Unity. It is difficult to really understand the architecture of Mir as the specification is so full of buzz-words that I don’t understand it [5]. From all I can see and understand Unity Next is a combination of window manager and desktop shell implemented on top of Mir. How exactly this is going to look like I do not know. Anyway it does not fit our design of having desktop shell and window manager separated and we do not know whether Mir would support that. We also do not know whether Mir would allow any other desktop shell except Unity Next, given that this is the main target. Wayland on the other hand is designed to have more than one compositor implementations. Using KWin as a session compositor is an example in the spec.
License
Wayland is licensed like X under the MIT license, which served us well for a display server. I think this is a very good choice and I am glad that the Wayland developers decided for this license. Mir is licensed under GPLv3-only with CLA. I think this is very unsuited for such a part of the stack and would render quite a risk for usage in KDE Plasma. KWin (and most KDE software) is GPLv2-or-later, this would no longer be possible, it would turn our code into GPLv3-only as KWin (or any other software which would depend on mir-server) would be a derived work of Mir. I do not consider GPLv3-only software as a possible dependency of any core part of our application stack. It renders a serious threat for the future in case of a GPLv4 which is not compatible with GPLv3. I also dislike the CLA [6]. So from a licensing perspective Mir is hardly acceptable.
Unity Specific/No Protocol
One of the most important aspects from Wayland for us is the ability to extend the protocol. This has already been a quite important feature in X and we are using our own extensions over ICCCM and EWMH to implement additional functionality. Of course our workspace has own ideas and it is important for us to be able to “standardize” those and also make them available to others if they are interested. This is possible thanks to protocol extensions.
Mir doesn’t have a real protocol. The “inner core” is described as “protocol-agnostic”. This renders a problem to us if we would want to use it. Our architecture is different (as described above) and we need a protocol between the desktop shell and the compositor. If Mir doesn’t provide that we would need to use our own protocol. And that already exists, it is called “Wayland”. So even if we would support Mir, we would need the Wayland protocol?!? That doesn’t make any sense to me. If we need to run Wayland on top of Mir just to get the features we need, why should we run Mir at all?
But it gets worse, the protocol between Mir server and Mir clients is defined as not being stable. In fact it’s promised that it will break. That’s a huge problem, I would even call it a showstopper. For Canonical that’s fine – they control the complete stack and can just adjust all bits using the protocol like QMir.
For us this looks quite different. Given that the protocol may change any time and given that the whole thing is developed for the needs of Unity we have to expect that the server libraries are not binary compatible or that old version of the server libraries cannot talk with the latest client libraries. We would constantly have to develop against an unstable and breaking base. I know that this sounds overly pessimistic but I know of one case where a change got introduced in a Canonical protocol late in the release cycle completely breaking an application in Kubuntu which wanted to use the protocol. Given this experience I would not trust that the protocol doesn’t change one day before the release meaning that Kubuntu cannot ship.
This is not awesome, it’s awful. It means KWin will not work just fine on Mir.
I hope this shows that using Mir inside the KDE Plasma workspaces is not an option. There are no advantages which would turn Mir into a better solution than Wayland and at the same time there are several showstoppers which mean that we cannot integrate Mir – not even optionally in addition to Wayland. The unstable protocol and the licensing choice are clearly not acceptable.
What this means to Kubuntu
Question marks
For Kubuntu the Mir switch by Canonical created quite some questions. One of those questions is answered: Upstream has no interest in supporting it and would most likely not accept patches for support. With upstream not using Mir the question is how the graphics stack for Kubuntu will look like once Ubuntu switched to Mir? The questions cannot be answered right now but it doesn’t look good.
Patches to the stack
Ubuntu has always had one of the worst graphics stack in the free software world. I can see this in the bug tracker. The quality of the Mesa stack in Ubuntu is really bad. For Mir Ubuntu will have to patch the Mesa stack even further. This is nothing which I would like to see. Also Mesa needs to be packaged with Wayland support. But will Canonical continue to do this? If not, would Kubuntu (and other Ubuntu flavors) need to ship their own Mesa stack? What if the changes by Canonical are so large that a standard Mesa stack doesn’t run on top of the Ubuntu stack?
Switching Sessions
One of the advantages of free software is that one can select the desktop environment in the login manager. This looks like no longer be possible in a Mir world. Unity will run with a Mir system compositor with LightDM nested underneath. We will need either the X Server or a Wayland system compositor. So from the login manager it will not be possible to start directly into a session using a different system compositor. How will it continue to be possible to use both Unity and KDE Plasma on the same system? Running a Unity and a KDE Plasma (or GNOME or XFCE or anything) session at the same time seems to no longer be possible.
System Compositor
How deep into the system is the system compositor going to be? Will it be possible to disable the Mir system compositor and replace it with X or Wayland? What if the packages start to conflict? Will it still be possible to install Kubuntu and Ubuntu on the same system? Will Canonical care about it? Will the system compositor mean that one has to decide in Grub whether to boot Ubuntu or Kubuntu?
Packages from Where
So far X, Wayland and Mesa have been packaged by Canonical. But what about the future? Will there still be packages for X, will there be packages for Wayland? If not, where to take them from? Debian unstable, most likely. But Debian might be frozen. Will it be possible at all to use the Debian packages for X and Wayland in the Ubuntu stack? Will they meet the requirements for KDE Plasma[7]? If Canonical doesn’t provide Wayland packages, they would drop to universe, so Mesa in main cannot depend on them. How to get then Mesa with Wayland support?
Only Future can tell
Those questions cannot be answered right now. It will have to wait till Mir is integrated into the Ubuntu stack. Then Kubuntu developers will see how far the stack broke. I’m not really optimistic that it will still be possible to provide the Ubuntu flavors once the transition to Mir is done. I don’t think that Canonical has any interest in the community provided distributions on top of Ubuntu any more. There are many small changes in the direction which indicate that. But we will see, maybe I’m too pessimistic.
[1] Given how Canonical introduced Mir with incorrect information about Wayland I consider this as a valid approach to dismiss the technology.
[2] I was very fed up with Ubuntu at the time anyway because our bug tracker once again exploded after the Ubuntu release.
[3] I do admit that I thought about asking KDE e.V. to send an Abmahnung after the statement that KWin would just work fine on Mir.
[4] In fact I consider TDD as utter non-sense and as a useless methodology though some aspects are useful.
[5] “with our protocol- and platform-agnostic approach, we can make sure that we reach our goal of a consistent and beautiful user experience across platforms and device form factors”
[6] Yes I know that Qt also has a CLA, which I have signed. But for Qt there is also the KDE Free Qt Foundation agreement.
[7]Last week a feature hit KWin which I cannot test/use because the X-Server is too old in Debian testing.

Distrowatch is a handy site to check out the history of Kubuntu. Today they put up a review of Kubuntu 13.04. "Kubuntu gave me a very responsive graphical environment, an application menu which was free from advertisements and the distribution did not insist I install third-party drivers just to use my desktop." Ubuntu Unity comes in for some critisism though, probably when they post (back) to Qt their graphics requirements will become sane again.

P for Vendetta

Konqi suffers fourth nerve palsy. He gets very upset at pirate comments.

Barcelona Office, KDE has a home in the sun!

Me and Rohan and Harald spent the day playing with the cheapo Sony Vaio laptop I got with Windows 8 and UEFI firmware.

This laptop has many partitions:
sda1 is fat32 and contains a Boot and a Microsoft EFI boot loaders
sda2 is ntfs and contains Windows Recovery bits
sda3 is efi/fat32 and contains a Boot, a Microsoft, a kubuntu and a ubuntu EFI boot loader
sda4 is a Microsoft reserved parition and won't mount, spooky
sda5 is an ntfs partition and has Windows 8 on it
sda6 is ext4 and I install Ubuntu and Kubuntu to it
sda7 is a linux-swap partition

I've no idea why there are two efi partitions
I've no idea why there's both an ntfs windows recovery partition and a microsoft reserved partition.

We installed Kubuntu but it didn't set up Grub and we couldn't do much useful at the Grub command line.

So we installed Ubuntu Unity 13.04 and it successfully set up Grub so we could boot from Grub into Ubuntu. Grub also listed Windows 8 but it gives an error on trying to boot "error: can't find command drivemap error: invalid EFI file path". Grub also listed windows recovery and this does boot and lets us boot into Windows 8 but that then stops Grub being loaded so there's no way to reboot into Ubuntu. see log.

Then we tried to install Kubuntu again and it give an error during install about the grub setup package not configuring right see bug for log.

If you go to ubuntu.com to download it points Windows 8 users to this scary UEFI wiki page with scary headings like "Installing Ubuntu Quickly and Easily via Trial and Error".

Conclusion: UEFI is a giant MS conspiracy to make installing Linux more faffy than it already is. Kubuntu is slightly more broken then Ubuntu but not much. Only silver lining is that Windows 8 is rubbish and when we tried it there genuinely was a notification saying "Warning: your children might not be protected". Think of the children and don't use Windows 8!

Oh well, here's some pretty pictures to keep you amused.

Les Frogs sont hypercool

The view of Catalunia is great for contemplation

Murdering a water mellon

VHanda ignores Doctor Who.

Notes from breakout on Homerun:

• Needs to move to Extragear
• no upstream designer in Plasma so hard to change fundementals like app menu
• KWin would be against it as default, uses full screen blur, no visual consistency between it and dashboard
• Does not show app generic names
• netrunner says full screen is distracting for a menu
• no filters
• no recent apps

Notes from breakout on High DPI sceens:

• see the wiki page
• faking it with large font not really accurate, many more problems, see screenshot
• needs someone with a high dpi monitor to test and fix

Post-it Kanban

The talks

Acrobatics

KDE People talking about KPeople

Since there's no UDS we have a room booked at Akademy to spend the day discussing things in Kubuntu

if you're coming put yourself on https://notes.kde.org/p/kubuntu-akademy

Would be good to have as many Kubuntu people there as possible.
The Kubuntu Council has funds if you need sponsorship for travel, don't be afraid to ask.

Here's some notes from the breakout sessions we had yesterday for my own recolation.

KWin and Wayland on Kubuntu

• Differences between Wayland and Mir are minimal, only client vs server side buffer allocation, so no benefit from it for a desktop distro
• dri3000 is a project to make X do client side buffer allocating
• KWin won't support Mir, (unless canonical wants to do it) it has no ABI stability
• KWin was working on Wayland suppport, now shifted effort to Qt 5 support before going back to Wayland work.
• KWin in 4.11 might work with Qt 5 but not for distros to use
• X wayland is a rootless X server used in both Wayland and Mir, no use for KWin which needs a rooted X server.
• wayland has libwaylandserver and libwaylandclient libraries, libwaylandclient for use in toolkits like Qt.
• current KWin architecture not fully planned but probably Weston as system compositor and KWin as client compositor
• worry that Canonical might havily patch mesa for Unity/Mir making Kwin/Weston break (more then it already is)
• Only Weston needed for LightDM then Kwin started same as currently by startkde (maybe a bit earlier in the script)
• Change to Wayland for Kubuntu about 14.10 or 15.04
• Wayland & Weston release every 3 months, KWin every 6 months
• Unity will have 1 binary equivalent to X, compiz and unity
• Weston can be run on X for testing
• current thinking is to ensure Debian's Weston packages are in Ubuntu archive and use those for Kubuntu, might make ubuntu-desktop and kubuntu-desktop not easily co-installable
• Installer ubiquity-dm a tricky point

Kubuntu SRUs

• KDE people get frustrated when their point releases don't get into distros or get in very slowly
• ubuntu SRU process is beurocratic for a reason - introducing new bugs is really nasty
• lightdm did introduce a new bug recently in a point release which was caught in the SRU process
• building SRUs in a PPA first to test unnecessary and time wasting, just test it locally then upload to -proposed
• possible scope to have approved from ~ubuntu-sru during the 7 day testing period rather than before to remove one blocker?
• delay in KWin updates causes bug reports to keep coming into KWin bugzilla, very time consuming for upstream
• work items too brief - danger of not understanding later what a point is
• use of trello to be encouraged for work item tracking with enough info to understand each point from someone coming fresh
• UEHS unknown if it works reliably, needs to be investigated and improved to update packaging as much as possible itself, at lp:dehs
• public kde-packager e-mail list (discussion has been done several times in past)
• automated copyright file from upstream?

The Ubuntu Developer Summit should have been this week but got cancelled in order to increase transparency. But you wouldn't want to let an expensive hotel booking go to waste so there seems to have been a meeting of Canonical engineers this week anyway just without the community. Twitter says some grumpy things. Well two can play at that game: I've been to every UDS except the Mataro Sessions back in 2004 so this week I'm down the road from Mataro with a dozen KDE and Kubuntu people to discuss what we're all working on. So far mgraesslin has shown his plans for KWin (including no small part of slagging off Mir and the instability of X in Ubuntu) and now Kevin is talking about the status of KDE Frameworks 5.

Sebas makes a good manager

Martin draws diagrams of KWin

Alex takes on the British Empire

Lunch time

Some time ago I got a phone call saying Canonical were stepping back from their support of Kubuntu. But Free Software doesn't like to quietly disappear and I've been spending the last year getting back what went missing. Last week I had a meeting to get the last bit in place, commercial support. A nice guy called Niall from Emerge spent a lot of time and energy getting an agreement from Canonical to be able to provide the commercial support then found a company to actually provide that. So I drove down to a part of England called Huddersfield to visit the offices of With Support, a small company doing Linux support. Their office has a fresh cut wood smell coming from all the fresh cut wood. Tariq is the head man having built up the business from scratch. He started off doing Linux desktop support but has moved away from that due to lack of business, hopefully being an official Kubuntu partner will fix that.

We installed Kubuntu to take a look from a user support point of view and found a bunch of issues. The main one was krfb not working to share the desktop, this is important as a way to get access to the user's computer. We didn't look at Kiosk but he considers it important to be able to lock down KDE's settings for companies that want it, I think this should still work but it'll need testing. Muon was a lovely package manager but no good if it doesn't know about packages which if you install without a network connection is the case until the cron job runs, ug. QApt seemed to not be doing what it needs to either installing .deb packages or working with the directory share plugin to install samba. And then he had some features he thought the users would expect like new applications highlighted in the application menu.

Then we had a conference call to talk business. The important thing about this deal is all profits go to the Kubuntu Council to spend on things to help Kubuntu. We'll need to set up a Paypal account or other way to pay and a transparent way to split money between us. And it'll need putting that on the website in some suitably clear marketing talk. I'm very excited.

We need you to test candidates for the 13.04 Kubuntu release. ISO tracker has the tests needed and links to the images. Chat in #kubuntu-devel to coordinate. Happy testing!

Some slick new artwork has arrived in Kubuntu 13.04. 13.04 is due for release a week today so all hands on deck for testing, join us in #kubuntu-devel to help out.

Plymouth boot screen

Ubiquity installer

Hugs to agateau, sheytan and apachelogger for the artwork polishing.

Google+ topic to name 100 things that are great about Kubuntu

"Community involvement."

"I like KDevelop, KDE and Debian packages combined with the fast update service of Kubuntu."

"I have to hand it to the Kubuntu package team, they really get the updates out fast"

"Everything is highly customizable."

Add your reason today :)

Bienvenue au Planet KDE Francais, un grand planet pour tout la monde francophone.

"C'est cool ça un planet en français pout KDE!" Cédric Bellegarde

"Une planète en français s’il vous plait!" Jean-Nicolas Artaud

"So that is the place to go for reading montel blogpost" afiestas

Myself and Paul and Nicky and Carry judged the entries. They were all winners. They all showed what could be done when you put people with ideas together with people who can hack. They all showed the power of open, collaborative and friendly development.

The winner was: Pocket TherAPPist, Michael Richardson learnt how to code Android in two days and mastered Eclipse to make a way of recording a patient's anxiety levels for later review.

Second was NHS Quick Help a PR campaign and simple webpage to point people towards the best place to go when you have a problem, could be A&E but could also be your local Pharmacy, Minor Injuries Unit or NHS 24.

Third was: South East Scotland Anesthesia information, they didn't add themselves to the project list so I don't know more :(

Fourth was GP Provision Planner, which used open source, open data and open street map to show where GP surgeries are over subscribed or under subscribed for future planning needs.

Code can be found on github/nhshackscotland and on the Project List. Hopefully the NHS staff can take this back and convince their departments and managers to go forth with Freedom.

Judging Mode

The Judges Contemplate

Coding on NHS Quick Help