Migration from pre-exisiting non-flatpak installations In order to migrate from pre-exisiting non-flatpak installation and preserve all settings please copy or move entire ~/.thunderbird folder into ~/.var/app/org.mozilla.Thunderbird/.thunderbird In case Thunderbird opens a new profile instead of the existing one, run: flatpak run org.mozilla.Thunderbird -P then select the right profile and tick "Use the selected profile without asking on startup" box.

Flatpaks are comfortable for users. It does not matter if you're on Debian, Linux Mint or Fedora. It won't break your system as aplications eg. from ppas etc. Distributions are not coming with updates of Audacity, so installations of it are a big problem. Flatpaks solve it...

I have yet to see a Snapd or Flatpak build of Audacity that I'm happy with. Those builds are beyond our control as they are made by 3rd parties. I do find it mildly annoying that Flatpak direct users that have problems with their builds to us.

Flatpak says this is so that apps can share runtimes. But the whole point of their runtime system is to let apps use different runtimes.

Flatpak is built on top of a technology called OSTree, which is influenced by and very similar to the Git version control system. Like Git, OSTree allows versioned data to be tracked and to be distributed between different repositories. However, where Git is designed to track source files, OSTree is designed to track binary files and other large data.

Internally, Flatpak therefore works in a similar way to Git, and many Flatpak concepts are analogous to Git concepts. Like Git, Flatpak uses repositories to store data, and it tracks the differences between versions.

Although Flatpak is similar to Snap, I think it matches the freedom standards that many Linux users are usually looking for, much better than Snap.

I'm having this problem too. Trying to use chromedriver with com.github.Eloston.UngoogledChromium (also tried org.chromium.Chromium) on Pop!_OS and selenium/webdriver (I'm using it with Ruby/capybara).This was the only post I could find (so far) about using chromedriver with a flatpak chrome/chromium... I wish someone would answer how or if this is possible.I created a chrome wrapper script that launches the flatpak, so that I could point to the script as my binary location. Did you do the same?It manages to open a window but the window is empty, and it just hangs for a hwile, and then eventually fails with:unknown error: DevToolsActivePort file doesn't exist (Selenium::WebDriver::Error::UnknownError) Any ideas how to get it working? I'd rather not install the "official" (proprietary software) Chrome binary on my system.Like you said, I never had any problems back in the good old days when we had deb packages for chromium. But now that we have to use a flatpak, I wonder if that's what the problem is — maybe chromedriver can't communicate directly with the chrome process because it is isolated/containerized??

Could someone guide me how to set up chromedriver with selenium using chromium flatpak properly? I can't seem to find any tutorial doing it like this... I never had issues with chromedriver using the "old" sudo apt way and I also got it working using snapd. But since I am using Pop!_OS I'd like to just use flatpaks if there is no sudo apt repo.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepoflatpak install flathub org.chromium.Chromium

Because flatpaks are distro agnostic, while you may prefer to have the distro's native package format you have to understand maintaining a a deb, rpm, etc simultaneously can be a real pain in the ass that you either deal with or you simply choose not to support certain formats and thus certain distros. With Flatpak is one package for all distros, or at least that's the idea.

I am concerned with duplicated dependencies though, that's my primary aversion to flatpak/snap/AppImage/etc.

This doesn't solve the problem of supporting where the users are; not everyone wants to use a rolling release, not everyone has the same kernel version, and so on. Not all distros support deb packages.If everyone was on Arch, then AUR would solve everyone's problem. If everyone was on Fedora, then RPM would solve everyone's problem but we don't have that universal packaging system.Freedom to pick and choose what you want to use on Linux is what makes it fun but for people that are trying to develop software and share it with their customers on linux, it's super complicated; they don't have a way to ship software to everyone in one simple package.Software devs can't just ship a deb package. That eliminates the large number of RPM based users such as Fedora, RedHat Fedora Enterprise, CentOS Stream or other distros. Then you have the Arch users, etc.That's what Flatpack/snap/appimage can help with.

packaging is difficult to maintain on linux with so many different distros that software companies to support.Flatpak, snap, and appimage makes it easier to ship once for a lot of distros that support them.

Flatpack is just a slightly less crappy snap.

That's not how flatpack works; the executable is hidden in a container and you need to set up the whole environment to be able to call it. Delivering a well-isolated, not-to-be-run-from-outside environment is the whole point.

Okay thank you. I'll need to do some thinking then on how to apply that to things like git config --global core.editor

should be really flatpack run com.visualstudio.code --wait, far as I know, never tried. (--wait is really important.)

Flatpak as a truly cross-distro application solution that works equally well and non-problematic for all

It appears that Canonical is continuing it's vice grip of unliateral, maybe dictatorial control on the development of Snap to the benefit of Ubuntu, but to the detriment of groups like Linuxmint, and all other non-Ubuntu based Linux distributions - like CentOS/Redhat, Suse/openSuSe, Solus, Arch/Manjaro, PCLinuxOS, etc, that are pushing Flatpak as a truly cross-distro application solution that works equally well and non-problematic for all. .

My biggest issue with snap is not the concept per se but that it's a mostly Ubuntu thing and FlatPak and AppImage are similar ideas. For once it would be nice if the Linux world would consolidate around a single technology instead of fragmenting like this.

Flatpak is the best application distribution mechanism for Linux.