Adoption of Flatpak vs Snap (2018 edition)

This is an update to my blog post from last year.

Here some facts for context, should anyone read this sometime down the road:

  • Today is 8 June 2018
  • Latest Flatpak:
    0.11.8.1, released today (0.11.8.0 was released yesterday)
    0.10.4 “Stable” released on 14 February 2018 (last old stable was 0.8.9)
  • Latest Snapd:
    2.32.9 released 21 days ago

Because Flatpak comes in two types, regular release (0.11.x) and “Stable” (=LTS, 0.10.x), the latest Stable release counts as well. With Flatpak 0.11.8’s hotfix only released 4 hours ago, it could not have passed the QA of any serious distribution, so 0.11.7 counts as latest for now.

Green means the latest version is in an official repository.
Yellow means that either the latest version is in an add-on repo or the package is in an official repository but with some problems.
Red means either not available at all or in some barely maintained (or even abandoned) add-on repository.

Flatpak Snap
Arch Linux Extra / Latest release AUR only / Latest release
Debian Latest in Stretch Outdated everywhere (even Sid)
Fedora Latest release Outdated and clashing with SELinux
Gentoo Overlay with latest release Overlay outdated
Mageia 0.10.3 Not available
openSUSE Latest in TW / Latest LTS in Leap15 Outdated / In add-on repo only
RHEL/CentOS 0.8.8 Not available
Ubuntu Latest in Bionic Latest in Bionic

Flatpak is continuing to go strong. In case of Mageia it graduated from the development Cauldron branch into a proper Mageia release, even though they forgot to package 0.10.4 and only ship 0.10.3, so while more users can no use Flatpak packages, they went from green to yellow because of that update oversight.
openSUSE’s conservative Leap releases also carry Flatpak now, not only their rolling release, so things actually improved while staying green.
Weirdly enough CentOS, while shipping Flatpak and not Snapd, does not even ship the last Old Stable release.

Positive developments for Snap have been that it graduated in Fedora from a totally broken build in a user repository to the main one. There are problems with SELinux (which is enabled by default on Fedora) but I don’t know how serious they are, so I give them the benefit of the doubt and rate it yellow instead of red.

In Arch Linux Snapd got demoted from the Community repo to AUR, however that at least carries the latest release.

In an attempt to increase the adoption rate of Snap, Canonical hired people to package Snapd for competing distributors. To a degree it seems to have paid off because Arch, Fedora, and openSUSE packages at least have some outside contributors, however only the AUR package is not outdated. Even Debian’s Snapd package is no longer the latest release. So while Snapd managed to cut the number of red cells down, the Debian packagers also dropped the ball and now they’ve lost their green table cell.

Just like last year, smaller distributions seem to gravitate more towards Flatpak than Snapd (like OpenMandriva).

So while things changed here and there, IMO Flatpak is still the way to go, especially for those software vendors that target professional users with Flatpak being supported by CentOS/RHEL, Debian, openSUSE Leap, and even the current LTS release of Ubuntu. Snap packages OTOH are only 100% supported by Ubuntu. Even other distributions that carry it do with some downsides.

Advertisements

Qt Web Renderers Greatly Improved in openSUSE Leap 15 and TW

With the upcoming release of Leap 15.0 and current snapshots of Tumbleweed, the rolling release variant, openSUSE users get important updates to both QtWebKit and QtWebEngine.

QtWebKit

QtWebKit was officially abandoned by Qt Company in Qt 5.6. As the name suggests, it is a port of the WebKit engine primarily developed by Apple for Safari. Until recently openSUSE shipped the abandoned version of QtWebKit, however Konstantin Tokarev maintains an independent version of QtWebKit which merges work of the old Qt port with improvements the WebKit-GTK port made, like using CMake instead of QMake. More importantly, this new QtWebKit 5.212 raises the security patchlevel to that of WebKit-GTK 2.12 and also includes some additional backports. While that is hardly state of the art and I would strongly recommend against using a QtWebKit browser to surf the web, it is a huge improvement over shipping an abandoned release.

Shoutouts to Max Lin who brought QtWebKit 5.12 to openSUSE.

There are still good reasons why QtWebKit makes sense in certain controlled environments. WebKit works with more CPU architectures and uses less memory than QtWebEngine.

I have packaged a version of the QupZilla 1.8 web browser for evaluation purposes. You can use it to find and report bugs in QtWebKit but – as I said – I would not recommend using it as daily web browser.

QtWebEngine

QtWebEngine is the official successor of QtWebKit. It is based on the Chromium codebase developed by Google for Chrome. In most cases, it is a very good choice but there is also a downside: Its releases are tied to the rest of Qt 5. This is less of a problem for Tumbleweed which usually gets the latest Qt 5 version anyway but it is a big problem for Leap which as a distribution with long-term support uses the latest LTS version of Qt 5. During the support cycle of a Qt 5 LTS version, updates ship less frequently until only the most crucial bugs are fixed. The previous LTS version, 5.6, was released in March 2016 and did not get a single bugfix release between October 2016 (v5.6.2) and September 2017 (v5.6.3) and there hasn’t been one since. While that may be fine for the rest of Qt 5.6, there have been a bunch of security fixes to the Chromium codebase that users did not get.

This changes now. Following the example of the Fedora KDE team, we now ship the latest QtWebEngine release regardless of the rest of Qt.

This means: Leap 15 has Qt 5.9 LTS and QtWebEngine 5.10.1 and will get QtWebEngine 5.11 and further future versions ASAP.

As an added bonus, we even ship additional security fixes that are not in 5.10.1. This is thanks to the work done in Fedora whose patches we could simply apply without much work on our part. Additional thanks to Fabian Vogt of openSUSE’s KDE team who helped me a lot with some scripting magic required when mixing different Qt and QtWebEngine versions.

Ishiiruka-Dolphin (GameCube/Wii Emulator) for Linux

You may have heard about Dolphin, not our file manager but the GameCube and Wii emulator of the same name. What you may not have heard of is Ishiiruka, a fork of Dolphin that prioritizes performance over emulation accuracy – and clean code if comments by an upstream Dolphin author on Reddit are to be believed.

Although Ishiiruka began as a reaction to remove the Direct3D 9 renderer in the Windows version of Dolphin (which is probably why the Linux community ignored it for the most part), it also began to tackle other performance issues such as “micro stuttering”.

Recently the Git master branch of Ishiiruka shipped compilation fixes for Linux, so I decided to dust off my old dolphin-emu.spec file and give it a try (I’m hardly an expert packager). So after some dabbling I succeeded. For now only Fedora 24, Fedora 25, and openSUSE Tumbleweed are supported. The packages are available from https://software.opensuse.org/package/ishiiruka-dolphin-unstable.

openSUSE Leap requires some workaround because it defaults to GCC 4. I plan to look into it at a later time. Once Tino creates a new Stable branch that incorporates the Linux fixes, I’ll post it under https://software.opensuse.org/package/ishiiruka-dolphin. (Quick update: It is now available on openSUSE Leap. The Stable builds as well. In addition to that, all openSUSE builds now build against shared wxWidgets 3.1 instead of statically linking the included one.)

If anyone of you is interested in Arch, Debian, Ubuntu,… packages (anything supported by OBS), I’ll gladly accept Submit Requests for PKGBUILD etc. files at https://build.opensuse.org/project/show/home:KAMiKAZOW:Emulators.

Get it from https://software.opensuse.org/package/ishiiruka-dolphin and https://software.opensuse.org/package/ishiiruka-dolphin-unstable.

Adoption of Flatpak vs Snap

A recent blog post says that KDE is still undecided on which containerized application format to support. Inspired by a post in a heated discussion on Phoronix I decided to investigate on my own how well various distributions support either format, so here’s a table with the results:

Flatpak Snap
Arch Linux Extra / Latest release Community repo /
Out-of-date
Debian Latest in Stretch Latest in Stretch
Fedora Latest release (F24 and newer) Not in main distro /
COPR outdated (no F25)
Gentoo Overlay with latest release Overlay outdated
Mageia Not available
openSUSE 0.8.0 in Tumbleweed, latest in review Failed and outdated builds in add-on repo only
Ubuntu Latest in Zesty Latest in Zesty

Given these results alone, I’m quite frankly pretty puzzled how the jury could still be out and that’s completely ignoring the centralized nature of Snap. Distributing AppImages via Steam makes more sense than Snap (Steam has the same centralized nature as Snap). Not only does every somewhat mainstream distribution ship Steam in some non-free repo, it would also allow us to distribute applications to Windows and macOS.

Even Snap’s home turf, Ubuntu, supports Flatpak since 16.10. Canonical employee Zygmunt Krynicki (zyga) was tasked to package Snap for various distributions but didn’t touch most packages since about half a year (no idea why). The COPR for Fedora does neither ship the latest Snap release nor does it support the latest Fedora version (F25). Builds in the OBS repo for openSUSE all fail, even though openSUSE also uses AppArmor, which Snap relies on for its security features instead of SELinux. The only distribution outside the Debian/Ubuntu ecosystem that adopted Snap at all in an official repository was Arch and that one does not even ship the latest release – despite Arch’s rolling release nature. Meanwhile Flatpak was adopted by every somewhat major distribution except Gentoo (and even there the 3rd party overlay is more up-to-date than Snap’s). Smaller distributions like Intel’s ClearLinux and Solus also adopted Flatpak (I encourage to read the Solus post for some great insight).

Note: I’m not a developer, so I see myself as an outsider looking in on that topic who just wanted to contribute some stats. Although my current focus is packaging (RPM), I had no closer look at either format other than distribution support for the table above. I also disabled comments in this case, just because I don’t want to fragment discussion further. Head to the original blog post if you want to comment on this topic.

Xbox pads under Fedora 24

After the release of Rocket League beta for Linux, I decided to install Steam under Fedora 24 and try it out.

The Xbox controller driver is not installed by default. Get it via

sudo dnf install kernel-modules-extra

Apparently the SteamOS variant of the xpad driver has some additions the normal kernel driver does not (yet) have.

To install it:

  1. Uninstall kernel-modules-extra (if installed; the upstream driver conflicts with the SteamOS version):
    sudo dnf -y remove kernel-modules-extra
  2. Enable negativo17’s Steam repo:
    sudo dnf config-manager --add-repo=http://negativo17.org/repos/fedora-steam.repo
  3. Install the dkms-xpad driver:
    sudo dnf -y install dkms-xpad kernel-devel
  4. Build the kernel module:
    sudo dkms install -m xpad/4.1

Not sure if I did a sudo modprobe xpad afterwards but now it works. Have fun.

Send Firefox tabs to your phone via KDE Connect

EDIT: This guide no longer works because the Launchy extension is not compatible with recent Firefox versions!

Even though I criticized Mozilla in the past on my blog, in the end I always returned to Firefox as my main browser, as it the most customizable browser while also (nowadays) very fast and stable.

Today I want to talk about how to marry to KDE Connect, one of the most awesome pieces of technology to come from KDE in recent years.

Everybody who once used KDE Connect is immediately hooked to it. Some say it even was the inspiration for Apple’s Continuity feature.

KDE Connect works both ways but the user interface mostly just exposes sending stuff from your phone to your PC which has been an annoyance for me.
Luckily it is solved now. Today I’ve read about indicator-kdeconnect by Viko Adi Rahmawan (EDIT: Looks like the project was abandoned. Bajoja forked the project and applied a few fixes recently. You can find it at https://github.com/Bajoja/indicator-kdeconnect).
indicator-kdeconnect is mostly a port of KDE Connect to desktops that use App Indicators, such as Ubuntu Unity. However it also comes with a very handy tool called kdeconnect-send that allows you to do just what I was missing: Send links and files from the PC to the phone.

Sending files is IMO not that important as KDE Connect allows to browse the phone’s file system (at least when the phone is running Android 4.4) but sending the current tab to read it on the go is where the fun is.

To do that you obviously first have to install KDE Connect on both your PC and Android device and then pair your devices.

Then install indicator-kdeconnect. For (K)Ubuntu the necessary steps are outlined here. I packaged the tool for Fedora myself, available here.

The third step is installing Launchy for Firefox.

The fourth and final step is to manually edit launchy.xml. Details how to do that are outlined in Launchy’s Preferences window.
The code you have to add to Launchy is:

<?xml version="1.0" encoding="UTF-8"?>
<configurations xmlns="http://launchy.mozdev.org/configurations">
<application>
<label>KDE Connect</label>
<type>1</type>
<command>/usr/bin/kdeconnect-send</command>
</application>
</configurations>

After you restarted Firefox you should have this button:
Launchy

On Android it then looks like this in the notification drawer:
Screenshot_2014-11-22-01-21-28

Have fun!

PS: I didn’t yet investigate why it’s not building under openSUSE. I send the spec file upstream. If you have a fix, please sent it upstream as well. Also no (Build)Requirements for Mageia are currently in the file. Again: If you have Mageia and want to make this tool available there as well, please send your additions directly upstream.

Very short 4.8 first look (from a user’s perspective)

The release candidates of the 4.8 generation are out since a few days and now also openSUSE packages are available in the KDE Unstable repository.

Release candidates by KDE are usually very solid with incomplete translations as biggest drawback but since translating is usually done during RC phase, it’s to be expected.

Plasma Desktop

I’m not a friend of bright desktop themes which is why I always change the Plasma theme from Air to something else on the first day and never see Air again until I do a fresh install for whatver reason. So I can’t comment if the Air theme itself has changed. What I noticed when I switched to Air out of curiosity was the giant size of the clock:


This is in Air alone. In the dark Oxygen theme the clock looks not like someone screaming at me that my eyes are bad. 😉

Possible theme changes aside, from an end-user point of view, the desktop hasn’t changed.  The device notifier uses new technology inside but it looks and behaves just like the old one.

There is a slight graphical glitch in Plasma Network Management but openSUSE has some random (likely untested) git checkout of that in its Unstable repository, so I’m not sure if that’s a Plasma Desktop bug or a PNM bug.

A small but nice change in the Oxygen window decoration is that the X button now glows red when hovering it. IMO that improves usability quite a bit:

Dolphin

A big user-visible change is Dolphin 2.0. As Peter explained last August, 2.0’s file directory code is a complete rewrite and it shows immediately. Dolphin 2.0’s workflow hasn’t changed, so there’s no need to re-adjust, but what’s there is a whole new level of polish:

As you can see in that YouTube video (WebM version available), all operations that require icons to be re-sorted have a fluid animation (lags in that video are due the recording process – it’s 100% fluid on my low-end laptop). Directory reading speed is also much better now.

I encountered three small bugs, though. I’m not sure if I’m the exeption or if those bugs are the rule with the new version:

Bug 264434 Dolphin doesn’t remember the columns widths in details view

Bug 281598 Geometry issues when increasing width of information panel (not exactly my problem but Peter closed my Bug 289851 as dupe)

Bug 289850 Size column uses KiB only
Other than those minor bugs, the experience is great!

Kontact

With 4.8 I also bit the bullet and switched to Kontact 4.8. I kept using Kontact 4.4 under KR 4.7 because of its bad reputation. My personal mail accounts – thanks to mailing lists I subscribed to – contain several tens of thousands e-mails. So any migration naturally takes its time.

Overall the experience with Kontact 4.8 is OK. From what I see the biggest problems aren’t actually problems with the programs itself but bad communication by the applications.
I also use Thunderbird for my work-related e-mail because I like to keep work and private mails separate. So I can actually compare both.
Kontact just like Thunderbird index mails for quick search. With as many mails as I have, both TB and Kontact take their time but here the bad communication comes into play:
TB says in its status bar in an unobtrusive manner that it indexes the mails. Kontact says nothing. It sits there, some Akonadi process eats roughly 30% CPU power and no common user knows what’s going on.

So there the problem is that Kontact does not talk at all. In another case Kontact talks too much. When I put my laptop in standby and later wake it  up, I get a notification for each mail account that the resource is broken and that the account if offline because of that.
No, nothing is broken. Standby simply caused the internet connection to be severed.
In another case – when I manually flag a mail as spam – I get the notification that the mail can’t be moved, even though it was successfully moved to the Trash folder at the same time.

So what would common users think? Probably something like this: “Kontact causes high workload and admits it’s broken all the time.”

Another problem is the result of an actual bugfix. KMail 1.x could only handle one operation at the time. This occasionally caused the GUI to freeze. The Akonadi back-end still can only do one operation at the time but now the GUI is responsive. So KMail2 downloaded 7,000 mails from one IMAP account and I could still use the application. So I went to another account (already synced) and wanted to read a mail just to get a “Retrieving folder contents” message for the time it synced the other account. Well, at least KMail told me what was going on.

Luckily such large-scale syncs are a one-time thing. After setting Kontact 4.8 up initially, the experience is smooth. In fact I find it smoother than Kontact 4.4. The GUI freezing fix may cause irritation during large-scale syncs but on a daily basis it’s way better. Bug 193514 has also been fixed. Those two have been two of the most hated bugs in KDE history.
I can’t tell how Kontact 4.6 and 4.7 have been but 4.8 is a solid improvement over 4.4. And no, Thunderbird is not better. It has better notifications but that’s it.

That’s it for now. I didn’t notice other changes so far but from what I gathered from blogs, most changes are under the hood anyway. So you may or may not benefit from them.