Can I ignore flatpak indefinitely?

[email protected]

Some kinda wise guy over here

[email protected]

I personally like flatpak and its build system. Flatpak applications are sandboxed by default and don't require root during any part of installation, reducing the risk of malicious/broken software damaging the host. They also are available for basically any base distro, meaning i can use the same apps if a ever distrohop and i can even just copy over the config folders as if nothing happened.

[email protected]

You're just not the target user.

The whole OCI mindset is geared towards absolute noobs like me, and cloud native devs that develop inside containers on a daily basis.

Take me for example. I use Bazzite, it's the first distro I couldn't break. On top of that, flatpaks, appimages and brew are my only options for software. Since Bazzite is an atomic distro (think immutable ) I could also use Distrobox but I don't want to deal with it.

Everything just works for me, I don't care about anything. I broke so many distros before. Sure, I don't control every nut and cranny but I don't want to.

If you know how to not break your stuff then that's great, but I don't, and I don't want to learn that. I just want to learn other things.

[email protected]

I like package managers just fine. I don’t want to have to have a plurality of software management tools.

Same. I grumble when I have to install things through the AUR. I'd prefer if it was in the official repos.

can continue to blissfully ignore

That's what I've been doing. I haven't run into a situation where I've needed to mess with Flatpak. Curious to hear other folk's experiences though.

Also for your consideration, Flatpak seems to be mainly used for desktop GUI apps. You'll still need your regular package manager to install CLIs. So... if you wanna keep your software management tools to a minimum...

[email protected]

It depends a bit on perspective and use-case, really. A flatpak'd application can be a fully-featured (all dependencies bundled) package in order to be portable. However, most flatpaks you might commonly encounter don't quite do this. A good portion of the libraries may be distributed in common runtime packages. This will be the case if you use flatpaks from Flathub or Fedora. There still can be bundled libraries with vulnerabilities, but in many cases, there are basic dependencies from external, common library sets.

As far as varying dependency versions, a developer may be on a host with either newer or older dependencies than expected by the user, but as long as the developer's application (and any unique libraries) are compiled against a common runtime as previously mentioned, it does make distribution to a wide variety of distros (LTS, 6-month, and rolling alike) relatively easy.

In comparison to OCI images (the kind of images that make up Docker, Podman, and a good portion of Kubernetes container images), flatpaks are a bit less extreme. Flatpaks contain much the same kind of files and structure that a standard distro package would, but simply get sandboxed into their own environment (via bubblewrap). Additionally, flatpaks don't necessarily need system-level access for installation and usage (full userland confinement). It heavily depends on host environment and configuration, but typically OCI containers are a full, minimal, immutable filesystem structure run in a virtual environment. Not quite a virtual machine, as (in Linux anyway) they are run on the host (almost always in a sandbox) without extensive virtualization capabilities being needed. The general difference in security capabilities depends on the differences in sandboxing between a flatpak behind bubblewrap and an OCI container's runtime sandboxing. There is also the notion with OCI containers being able to run as virtualized users, including root. With OCI containers that can obtain root access and a flaw in the sandboxing of say Docker in its standard rootful mode could allow for root level processes in the sandbox to act upon the host.

From what I can think of in comparison, there is the big problem with Flatpak in that it really isn't suitable for packaging command-line applications: only GUI applications and libraries. OCI container images are often tailored for running web apps and other persistent CLI applications

[email protected]

I mostly do. 99.9% of the software I use is a Debian package. Well on debian anyway. I do have one AppImage.

[email protected]

doesn't yay simplifies the AUR installation? Things have been pretty easy for me after I started using yay

[email protected]

The risk of dependency vulnerabilities is real.

Also, flatpak packages are not digitally signed, unlike apt and all other major Linux distro package managers.

[email protected]

yay simplifies the AUR installation

Simple to me means not having to install some random extra tool and just using pacman like normal. That's why I grumble.

[email protected]

I don't develop distributed applications, but Im not understanding how it simplifies dependency management. Isn't it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?

That's correct. This simplifies the dependency management system because not every distribution ships with every version of every package, so when software requires a version of a package that the distro dosesn't ship with or have in its repositories, the end user has to either build the package from source, or find some other way to run their software. Flatpaks developers will define the versions of dependencies that are required for an application to run and that exact version is pulled in when the flatpak is installed. This makes the issue of every distro not having every version of every package moot.

Don't maintainers have to release new bundles if they contain dependencies with vulnerabilities?

They don't have to, no. But they absolutely should.

Is it because developers are often using dependencies that are ahead of release versions?

Sometimes, yes. Or the software is using a dependency that is so old that it's no longer included in a distro's package repositories.

Also, how is it so much better than images for your applications on Docker Hub?

I would say they're suited to different purposes.

Docker shines when availability is a concern and replication is desired. It's fantastic for running a swarm of applications spread across multiple machines automatically managing their lifecycles based on load. In general though, I wouldn't use Docker containers to run graphical applications. Most images are not suited for this by default, and would require you install a bunch of additional packages before you could consider running any graphical apps. Solutions to run graphical applications in Docker do exist (see x11docker), but it doesn't really seem like a common practice.

Flatpaks are designed to integrate into an existing desktops that already have a graphical environment running. Some flatpaks include the packages required for hardware acceleration (Steam, OBS) which can eliminate the need for those packages to be available via your distro's package manager.

What this means is that a distro like Alpine Linux that doesn't have an nvidia package in its repos can still run Steam because the Steam flatpak includes the nvidia driver if you have an nvidia GPU installed.

Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it's something I should adopt, or if I can continue to blissfully ignore.

¯_(ツ)_/¯ It's a tool. Use it when it's useful, or don't.

[email protected]

The AUR is a different kettle of fish entirely, though. I do see your point, but the AUR is solving a problem common to all distros; hosting a repository for applications that there isn't willingness or capacity to host in the official binary repos.

Installation, removal, dependency management, etc are all still handled by pacman. As others have pointed out there are great tools available to aid in AUR usability. My favorite is aurutils.

[email protected]

Just make sure to not post bugs to the upstream project and keep them at the distro level

[email protected]

Thanks for the detailed answer. I think I have a clearer picture of the problems it's trying to solve and the solutions it's delivering.

It also now seems connected to immutable distros I've also heard about recently. So I guess the idea there that the OS is just a tiny core set of libraries that never have to change, then the applications have their dependencies bundled, instead of requiring them as system dependencies.

I'm not convinced it's something I want as a user, but more importantly not something I need.

From a development perspective, it seems downright seductive, allowing almost total freedom of opinion.

? Offline

Is it because developers are often using dependencies that are ahead of release versions?

That has been my experience recently. I had the same mindset as you until a critical piece of software I use shat the bed on Arch (LiveCaptions) that affected my being able to watch training videos for work.

Because it was time critical and I didn’t feel like possibly breaking other things for one package, I grabbed the flatpak. It came with its own nvidia driver package (mine was newer) and it worked out of the box without having to mess with anything and that was enough to change my hardline view on that.

Now it’s just another tool to use in an emergency when important things randomly break.

[email protected]

Correct, horse_battery_staple

[email protected]

Just as my two cents, as a user - I like flatpaks because I can have up to date versions of certain applications on a more stable Debian base. I also like that application configs all go in one spot (~/.var/app/com.Example.example), and granular permissions management per application.

[email protected]

I might be an exception here, but I really like flatpaks. I like their sandboxed nature and using Flatseal, you can cherry pick the permissions you want to give to a flatpak application. Don't want to give n/w access, boom done, like that. And finally if anything goes wrong, delete the app data and you are fresh to go. Also from a security standpoint, you can grand or deny access to specific directories and most apps don't have root access.

[email protected]

Yes you can. I do. If a software does not offer build instructions, which is rare, I just do not use it.

[email protected]

Not to be that person, but you aren't restricted to those solutions for software, that's what rpm-ostree is there for. It layers applications over your system image and installs software in a similar manner to a "normal" package manager.

[email protected]

I just use it if the package/dependencies aren't available or functional in the default arch repo. I like to be able to turn nuts and bolts but also avoid it when it's inconvenient.

2 package managers is fine for me.

agnos.is Forums

Can I ignore flatpak indefinitely?