Today KDE released Plasma 5.12 with Long Term Support–the culmination of more than a year of work. It’s really awesome, and we think you’ll love it!
But how do you get it!?
It all depends on your distro! Let’s look at Linux distros today.
What makes a distro a distro?
Today it’s mostly the choice of release model. “Stable release” distros like Ubuntu and Linux Mint lock everything to a specific version, only offering feature upgrades only when a new major version of the distro is released. “Rolling release” distros like Arch and openSUSE Tumbleweed give you everything as close to the developers’ schedules as possible.
Each model has drawbacks:
- Stable release distros will often saddle users with ancient, years-old software. For example, users of Debian Stable might not get to experience KDE Plasma 5.12 for another 2 or 3 years–or even longer.
- Rolling release distros expose users to the latest version of everything, turning them into QA. Underlying system libraries often change and break apps that use them. The breakage is usually fixed quickly, but users are exposed to it in the first place.
Certain distros additionally try to go beyond mere packaging and releasing, and actually try to ensure some QA and polish in the final product. Distros like Ubuntu, Linux Mint, Manjaro, and Elementary that follow this model quickly rocket up to the top of the popularity pyramid. Users are desperate for distros with better QA and polish!
But it’s exhausting; if you package all the software, you’re responsible for it too. It’s a huge job, even for distros that base themselves on others, as they find themselves having to patch on top of patches, and manage two release cycles (their own, and the parent distro’s). Turnover and burnout are common.
Flatpak and Snap to the rescue
Flatpack or Snap provide the solution: 3rd party packaging. Instead of the distros doing the packaging, it comes either straight from the developers, or from a 3rd-party intermediary like Flathub.
For distros, the benefits are enormous: liberated from the grunt work chores of packaging and patching software, distros will be free to step wholeheartedly into their natural roles as arbiters of the final user experience, concentrating on impactful tasks like integrating diverse components, managing hardware support, performing QA, polishing the final product, and delivering it to users in an easy-to access manner. Fixes and patches can be submitted upstream, instead of duplicated locally. This is KDE’s relationship to Qt, in fact. It works great.
Snap and Flatpak also improve things for users and developers:
- Users get to choose whether they want each app to be stable, up-to-date, or cutting-edge according to their preferences, and they get a clear chain of responsibility when there’s a bug.
- Developers get to package their apps only once to make them available to everyone, and get to determine for themselves their software’s presentation, branding, and release schedule–rather than hoping that packagers for 500 different Linux distros do it for them, and then having to deal with bug reports about versions of their software that are years old.
Ultimately, Flatpak or Snap liberate us from the tyranny of low-quality distros that make Linux software look bad because they don’t do QA, integration, or UX testing to make sure that the final product is of high quality. Many will rightly vanish because they’re not providing much value for users or generating enough developer interest to continue existing. Once this happens, developers and users will gather around the smaller number of remaining distros, increasing each of their levels of manpower and user bases.
So no, distros don’t go away. In fact, the distros that are worth keeping will be able to focus on tasks that offer more value to users than mere software packaging. Far from erasing diversity, this will empower real and meaningful diversity–where we have a handful of really good and strongly differentiated distros whose products embody different philosophies, instead of an overwhelming number of mediocre distros with often only minimal differences, none of which really work well once you dig deeply. We’ll all win, and all of these vastly superior distros will be far stronger contenders when compared to Windows, macOS, and ChromeOS.
How you can help
There are many ways for you to help enter this brave new world of actual QA and polished products.
Users: If your favorite app offers a Flatpak or Snap version, use it! Quite a lot do. If you find problems, file bugs! If you find an app listing in KDE Discover or GNOME Software that doesn’t look good, submit better information! If you find cases where duplicate apps appear when browsing, submit patches to fix it!
Software developers: Provide high-quality AppStream metadata and please submit your apps to Flathub! This goes for KDE developers, too. Krita and Kdenlive are already up, but I want to see Dolphin, Konsole, Kate, and all the rest!
Distro developers: don’t fight Flatpak or Snap; embrace them (and Flathub) and liberate yourself from packaging chores. Focus less on packaging software for your users, and more on performing the QA necessary to make sure that that software actually works well.
As always, consider becoming a KDE contributor if you like what you see! We can’t do this without you.
Adventures in Linux and KDE 
openSUSE Tumbleweed is slightly delayed, too, because Tumbleweed developers do test builds before releasing updates. For example, I remember a KF5 frameworks update appearing nearly four weeks late, because there were issues that needed to be sorted.
LikeLike
Yes, Tumbleweed is one of the better rolling release distros for QA. Still, things slip through, e.g. https://bugzilla.opensuse.org/show_bug.cgi?id=1041837 and https://bugzilla.opensuse.org/show_bug.cgi?id=1042090
LikeLike
@kdepepo Which is why openSUSE Argon and Krypton exist, for various values of “bleedingest edge”. They don’t get much exposure, but AFAIU are all about automated builds (so not much packaging effort) and more about the QA before tumbleweed.
LikeLike
> so not much packaging effort
Actually there is some kind of effort. 😉 They’re also used to track dependencies and changes for the stable packages.
LikeLike
Just a thought, Will Dolphin (or any file manager) be limited in their flatpak/snap version because of the sandboxing? This method will restrict the reaches of the file manager just to ‘compatible and contained’ (flatpak and snap are not compatible between them, aren’t they?) files; not that useful.
Anyway, I totally embrace flatpak/snap. It makes our (as users) life way easier, and I use them every chance I get.
LikeLike
No, you can package Flatpak apps in such a manner that allows them full filesystem access (which is the only thing that makes any sense for a file manager!) If you find an app that’s mis-packaged, go file a bug against the folks who run the Flatpak repo you got it from!
LikeLike
I can see there are several benefits with Snap and Flatpack, etc. But there is one thing I never understood and can’t seem to find the answer for. Do they give access to some sort of automatic update system? Either like a rolling distro or something like PPA:s for Ubuntu, etc. Having all installed apps getting automatically updated to the latest version was one of the main things that sold me on Linux back in the day as constantly scouring the internet for new versions of Windows programs was terribly time-consuming (not to mention each program having a unique background process to keep it updated *shudder*). Can any of these formats give me the latest version by some sort of automation, I’m all in. 🙂
LikeLike
In fact, they give you access to the *best* update system: updates on developers’ own schedules. You get all the benefits of rolling release distros for apps, without having to have all of your critical system packages be rolling.
LikeLike
except developers don’t care that much for opensll 1.0.2.n which fixes a rare but remotely exploitable bug. Also, all of the 100 flatpak apps would need to get updated separately and no, most of them won’t be
LikeLike
Thankfully, that isn’t the case! Flatpak isn’t like AppImage or macOS App bundles where all dependencies are bundled. Rather, as many dependencies as possible are pushed into runtimes, which are really just big meta-packages. And openSSL is in the FreeDesktop runtime, so once you get an updated version of that runtime, then boom, all the vulnerable apps on your system are safe–same as when openSSL is its own package.
LikeLike
Hi Nate, indeed bundled packages seem to be gaining momentum and once (if ever) they become the standard, distributions will have no other option than to redefine themselves and their implementations of software delivery to users.
Packaging in GNU/Linux distributions is a major resource hog and FlatPak and Snap applications will improve on that by outsourcing this procedure to developers. On the other hand, the ability to build something from source is a key component of FOSS and it will probably always have an audience in a similar way that F-Droid has on Android.
In regards to release models, I don’t know if you are aware of Chakra’s half-rolling model, I gave a talk about it just days ago at FOSDEM2018:
https://fosdem.org/2018/schedule/event/half_rolling_repository_model/
Keep it up! =)
LikeLike
Thanks Neofytos! Chakra’s release model looks *exactly* right, and that’s essentially what you’ll get if you put Flatpaks on top of a stable release distro like Fedora or Ubuntu. Sell me on Chakra! What else is awesome about it? Our users keep asking for the best KDE distro…
Flatpak and Snap don’t prevent you from building anything from source, and you don’t need to structure your app in a special way to make use of them. It’ll still be totally 100% possible to download the source and fire up make.
LikeLike
What’s unique about Chakra, in addition to the half-rolling model we propose, is the complete focus on KDE/Qt software and of course our usage of ArchLinux technologies (PKGBUILDs, makepkg, pacman etc). We are a small distro but we strive to be friendly and inclusive.
We are also working on akabei (a pacman replacement) for several years now, as we want a package manager that can play better with modern GUIs and software centers like Discover, which btw keeps getting better with each release! Resources are limited but we hope we can soonâ„¢ push a first testing release out.
Having said all these, I avoid getting into “the best” discussions, I prefer to appreciate each distro as a tool that can be useful depending on the case. 😉
About building from source, yes you are spot on, I wasn’t saying they prevent you, just that there might still be an audience for that after bundled packages are the mainstream.
LikeLike
So Chakra is like KaOS but with a half-rolling release model?
LikeLike
KaOS is like Chakra, also considering that KaOS developer was a member of Chakra team 😉
LikeLike
Even Fedora is half-rolling, at least all those components that don’t break compatibility (that means KDE components are fine, Kernel is as well, Qt most of the time, Gnome not).
LikeLike
I don’t want to sound rude but maybe KDE Neon should first get their act together and work on Flatpak instead of promoting the single-vendor solution Snap that doesn’t fully work on non-Ubuntu distributions because several core features (such as sandboxing) need to be disabled in order to work on e.g. Fedora. In other cases Snap does not work at all (openSUSE TW). Meanwhile Flatpak is available of pretty much every distribution under the sun (even Ubuntu) without compromising security.
I find it weird to advocate KDE’s own binary packages when at the same time the KDE community itself can’t unite behind the truly cross-distribution technology and instead waste manpower on a package format that only works well on a single distribution and its derivatives. How is KDE supposed to have superior QA when resources are needlessly divided?
LikeLike
Harsh but true. I happen to agree and I think Flatpak will be the winner. It seems to have generally greater momentum and seems to work a lot better. We even have our own Flatpak nightly build repository that includes all KDE apps: https://community.kde.org/Guidelines_and_HOWTOs/Flatpak
Most within KDE seem to be on board, but as with anything it’s hard to get people to all get on the same page!
LikeLike
I wouldn’t jump to conclusions here.
I can’t deliver any links at the moment but if I can remember right, there are still two open issues here:
1. Flatpaks don’t offer sandboxing on AppArmor based distributions. The same problem here in the opposite way, of course.
2. Snaps shall cover a broader range of usage. Coming from server side and more and more covering the desktop part. Flatpaks are probably stronger at the desktop area at the moment but Snaps are catching up.
So, for me, until the first issue is solved, there must (!) be both formats.
Correct me please if there is no advantage in snapping more than desktop apps so that the more general purpose of Snaps doesn’t make sense.
Regards and thank you for all the work!
LikeLike
1. Were do you get your information that Flatpak is not sandboxed on AppArmor systems? openSUSE uses AppArmor and there is nothing in https://build.opensuse.org/package/view_file/openSUSE:Factory/flatpak/flatpak.spec?expand=1 that disables Flatpak’s sandboxing (Flatpak does NOT rely on SELinux, it bundles its own sandboxing tech called Bubblewrap which should also interfere with SELinux is there were sandboxing conflicts).
And even if that were true, the fact still stands that Flatpak is available on a broader ranger of distributions than Snap. This is the status of Snap under openSUSE: https://build.opensuse.org/project/monitor/system:snappy?failed=1 Fails and breaks everywhere.
2. Flatpak is the desktop implementation of the OSTree technology. The server-side is covered by https://www.projectatomic.io/
LikeLike
ad 1. Indeed, Flatpak seems to be more independent from the underlying MAC solution. Once LSM stacking is supported completely there shouldn’t be any problem for usage of AppArmor next to SELinux too. Interesting reading here:
https://forum.snapcraft.io/t/assorted-questions-about-snapd-use/1738/5
“BoF: Extreme Security Module Stacking – Issues and Directions” – https://tyhicks.com/2017/09/22/2017-Linux-Security-Summit-Day-1/
ad 2. Would the atomic server-side applications then be available through the same infrastructure and software as Flatpaks do? For me it looks like you have two different ways of delivery whereas the same snap would fit well for both (server/desktop).
LikeLike
>> Meanwhile Flatpak is available of pretty much every distribution under the sun (even Ubuntu) without compromising security.
Does Flatpak offer sandboxing on AppArmor based distributions already? Please provide a link, I would very appreciate it!
LikeLike
AFAIK Flatpak doesn’t rely on SELinux for security
LikeLike
It doesn’t. Flatpak uses a self-contained sandboxing solution called Bubblewrap.
LikeLike
Many thanks for the hint! There were several sources saying that (SELinux) in the past, e.g.
https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others
LikeLike
> Does Flatpak offer sandboxing on AppArmor based distributions already? Please provide a link
How about you provide a link that backs up your claim. https://github.com/flatpak/flatpak/search?q=apparmor&type=Issues&utf8=%E2%9C%93 says nothing that Flatpak does not work at all under AppArmor systems. One is a hickup with environmental variables the other is about debugging.
I can’t provide a link to “it works now” when there is no “it does not work” bug report in the first place.
LikeLike
I’m confused about flatpak app bug reporting: an app from flathub that uses kde runtime cannot open a file browser – where do I report the bug, to the flatpak or the app devs?
LikeLike
That would be a bug report for the app’s Flatpak packagers.
LikeLike
Flatpak and Snap have all the advantages you listed, but two major drawbacks still exist:
– They do not inherit users’ font, theme, or icon settings, making them look foreign and inconsistent.
– They cannot interact with other Flatpak or Snap apps without manual setup. For example Zotero flatpak cannot auto-detect Libreoffice flatpak (or ‘normal’ Libreoffice) to insert citations.
LikeLike