(How does Mageia beat out OpenSUSE)
I can’t find any flatpak runtimes in the repos or https:\software.opensuse.org
Flatpak is a newish member for distributing applications in Linux. Runtime common to all (Missing in OpenSUSE right now)
Flatpak - Distributing applications on Linux is a pain: different distributions in multiple versions, each with their own versions of libraries and packaging formats. Flatpak is here to change all that. It allows the same app to be installed on different Linux distributions, including different versions. And it has been designed from the ground up with security in mind, so that apps are isolated from each other and from the host system. http://flatpak.org/
We have the sadly not used appimage format. Everything in One File
Appimage - Distribute your desktop Linux application in the AppImage format and win users running all common Linux distributions. Package once and run everywhere. Reach users on all major desktop distributions. http://appimage.org/
We also have snap (Ubuntu only right now (And always?))
snap - With snaps, applications run in a security sandbox under confinement and are isolated from each other. The default confinement allows apps within the same snap to work together but access to any other apps, the user’s session or the system is limited. https://developer.ubuntu.com/en/desktop/get-started/
As an interesting new tech concept, I read through available public info on the flatpack website…
As is often the case, the FAQ contains some technical stuff the Authors didn’t want the general public to get lost in. http://flatpak.org/faq.html
It’s a container technology. But, it’s not a container technology. Flatpack touts the security of running in isolated Linux kernel containers, but then turns around and says that Flatpack apps don’t necessarily run that way, that they run as session apps (like common apps). So, yes <and> no.
Its likely main feature is as advertised, it allows a Developer to pick a particular Gnome runtime (with KDE to come) for an app to be built against. This is a fancy way of saying that a particular set of Gnome libraries is packaged up and made available to all distros so that there isn’t the chance a User is running some incompatible dependency. Hmmmm… I don’t use Gnome so don’t know how rapidly libraries change and their effect, so can’t say whether this is a significant issue or not. I don’t see any posts in our Forums about this but that might be because “all” Gnome Users are using apps from the OSS or our openSUSE Gnome repos and not rpm packages from somewhere else.
We at openSUSE already know about, and offer to the world the Open Build Service, which essentially does the same thing (and perhaps better?) as Flatpack. Anyone can upload their codebase to their own OBS project and target builds to practically any distro in existence. The diff between OBS and Flatpack is very similar to the difference how Java and the CLR (Mono or dotNET) builds apps to run on a variety of targets… One is “write once and run everywhere” by ensuring a suitable runtime exists on every client, the other approach creates a custom build for every target (assumes no desired target is unsupported). Although both work, one has generally demonstrated a clear advantage in performance (I’ll let people argue about that elsewhere although IMO empirical evidence is conclusive).
If someone <really> wanted to run flatpack apps on openSUSE, that looks like a trivial issue that’s easy to solve. You only need the flatpack binary which can be downloaded unpackaged or likely install the Fedora rpm, then add the flatpack repo. Done.
If someone <really> wanted to distribute a containerized app, this might be a way (eventually, see drawbacks below).
If the Developer’s objective is to create a “stacked” package of smaller apps, this might be interesting. But the Authors are wrong that this can’t be done with competing container technologies, in fact this particular skill/ability is required for some Docker implementations.
Flatpack drawbacks (or at least limitations which might not be important to the Developer) are clear…
The Flatpack runtimes are only collections of Gnome libraries with promised KDE support to come(and I don’t see why not. Should not take too much effort to gather collections of KDE libraries). If you don’t build Gnome apps, this isn’t for you. BTW - the Flatpack FAQ states that there is no known IDE support… I’d guess that this wouldn’t be difficult to set up in Eclipse, and other IDE might also be similarly configurable to use specified libraries when building.
You can only build an app using Gnome libraries, and soon to come KDE apps. If the User is running some other Desktop, you can see this is an advantage to run the Gnome app in some alien Desktop, but to some extent you can do this already with a number of distros including openSUSE.
The penalty for running “alien” Gnome apps is that there’s no getting around having to install “the runtime” which are the libraries which aren’t already on the machine. I assume (without close inspection) that the entire runtime is not downloaded to the User, only specific dependencies are to support the specified app… Otherwise there would be extreme wastage and a significant performance hit as well.
Only Flatpack runtimes are hosted, not Flatpack apps. A Flatpack common public repository of apps does not exist (Why? is it that expensive or difficult to attract necessary funds and talent to set up?) This is a very significant issue because Flatpack first promises an easy, universal way to create and distribute apps and then does not provide the infrastructure to support the promise. Compare to OBS which provides a free home for the creations of any Developer.
If you want to write web apps in Haskell using Snap on openSUSE, go ahead and do it.
The required Haskell package manager and installer “cabal” is in the OSS, just install and run.
And, Snap is apparently not often installed through a distro repo but can be easily installed and run using “cabal” as documented on the Snap website http://snapframework.com/download
This is the first AND second hit on google when searching for flatpack and opensuse atm, so i wanted to chime in a bit so the thread doesn’t basicly end with this.
Flatpack is early in development, security features come later but segregation by cgroups and other tools to keep apps access limited is a strong goal of it. Apps are meant to run sandboxed, the extend they ARE sandboxed however is up to the developer of the app.
The idea is that you don’t have **a **set of gnome libraries, you have the set of gnome libraries regardless of which distro you are using. Imagine I’m on Leap 42, i like it. I don’t want to run tumbleweed. But i really dig the new gnome because it has a important feature that would ease my workflow. Right now i have to add a repository for obs, and it may or may not work well with my Leap version, OBS simply is not on the same level as a stable release. With Flatpack however i would install the new gnome-libs-runtime and gnome-apps-runtime at the exact version i want. I know they will work well together because these are the exact same libs and app versions the gnome-devs themselves run on their systems(not just same version, same compile options etc, literally identical). Also i can install several versions, i can have gnome-libs-runtime-3.20 installed at the same time as gnome-libs-runtime-3.16 if i have apps that need one or the other. The apps themselves contain the info so they know which runtime to use.
OBS isn’t better than flatpack, they have completely different goals. Flatpack is about a developer releasing a program, and knowing it will run without repacking or change on every linux distribution capable of handling flatpacks. He can say “Oh sure, it runs perfectly on fedora, arch, magaia, debian … You can send bugreports directly to me don’t bother the distro maintainers unless its a kernel or glibc bug”. Its also about the user knowing that the program he installed is working as intended by the developer while having very limited access to his system. Because lets face it, linux security atm is mostly meaning the system and its applications are secure, it doesn’t go out of its way to secure actual userdata which in most cases is much more valuable(especially as most people still don’t do backups) on desktop machines. Why does a webbrowser need access to every file i have access too? And if it doesn’t need that access, why does it have it?
Its very early days for flatpack. I expect this to be the system for installing rapid changing large security relevant programs like webrowsers and email clients in the future though. You need security updates on those asap, and nobody can provide them faster than the devs. Also, without any insult intended to the great maintainers at opensuse, its one less point of attack in the chain from sourcecode written by developers to software installed at the endusers pc. If everyone from fedora to ubuntu uses the same firefox package thats signed by the mozilla releaseteam, a attack on a distributor(like happened to linux mint recently) can’t affect my webbrowser. Also, this isn’t much of a point for a large distro like opensuse, but smaller distros would benefit much if core desktop components like gnome, kde, firefox, thunderbird and libreoffice are provided by their upstream instead of having to compile and package them every time a new version comes out. They can focus instead on the “soul” of their distro.
The kicker for me is that I’m able to run a stable base with new desktop apps. Kinda of what i like about leap. But better. Because it’s not a uncontrolled mix of OBS repositories(a single OBs isn’t uncontrolled since its handpicked to provide its function, add several however and things get random), but the exact version of the exact library that upstream intended for their specific apps. This why i gave up on debian years ago. I couldn’t run debian stable or even testing and have recent desktops, sure i could add unstable but it was a mess and even unstable lagged behind greatly on gnome during the systemd mess. With this people can run debian stable and the latest gnome-version(well in theory), and expect it to run very well without messing up the rest of the stable system since it would still be 100% debian stable, but running the latest gnome. This is because flatpack runtimes are only used for the flatpack gnome version.
Its just a very elegant system, just not quite there yet. Ignoring it even in its current state however would be not a very smart thing imho from a distribution pov.
Many good points by both sides. There has not been any more discussions around flatpak here in over 6 months. Is it dead end, or still really early?
Pros
Can run applications in sandbox.
Runs on every distributions without the need to recompile the source code or repackage the application.
No need to wait for distribution maintainers to deliver the latest features and fixes for any application you use. For instance the nuvolaplayer needs diorite library 0.2. This library has a fix in 0.2.1 which is 1 year old, but the maintainer of this package in obs://build.opensuse.org/multimedia
has not created any updated package with this fix.
Cons
Could be using out of date libraries with security vulnerabilities. Unless the KDE/Gnome runtimes is kept up-to-date with all the latest security fixes (Like SUSE and RedHat does with packages in their Enterprise Linux). What happens when a runtime is no longer supported or updated? Think of old games published in flatpack, could perhaps be using old runtimes with lots of security vulnerabilities. Though running confined within sandbox perhaps makes this con a moote point.
A lot of redundant libraries in various runtimes takes up more disk space.
Lack of official repositories for applications in flatpak. I for one do not want to go searching the web for applications like I did in the old days when I used Windows. Though flatpak website do list a few applications available.