flatpak is like a cross-distro snap that actually works. some of the apps are buggy at the fringes, but i've been opening issues to smooth them out. some of the apps like VS Code claim to be from microsoft, but are... unofficial?
> some of the apps like VS Code claim to be from microsoft, but are... unofficial?
Unless they have a verified checkmark next to the company/owner of the project it will be a 3rd party package of it. The name is mainly intended as a "This is from X" instead of "This is packaged by X" (unless you actually see the verified badge)
I so far have been disappointed because some of the main things I I shall and had are a browser and password manager and they can’t talk to each other and flatpak refuses to fix it.
> flatpak is like a cross-distro snap that actually works
You are right. Besides proprietary app store, Snap lacks even basic sandboxing in non-Debian based distros. I can't believe that Canonical engineers thought this was a good idea when designing a cross platform packaging format.
Flatpak got everything right from it's initial design. Multiple repositories, Sandboxing that actually works in any Linux distro, OSTree to reduce disk space usage etc.
I think that flatpak is the future. It would be nice to have some level of shared read only packages, like UI frameworks (gnome/kde etc) and a few other features could be better.
A nice permissions interface so the manifest can declare, this app needs x, that you can approve instead of needing secondary apps to change permissions.
I don't mind snaps. I'd like to see better integration to move AppImage downloads to a single location and add them to the apps menu directly.
I really like flatpaks, easy to install and work with. Definitely superior over Ubutnu's snaps. As a user you do have to be somewhat aware that the application is running in a sandbox and won't behave exactly like one running without a container. For example the Belgian digital ID card software does not work in a sanboxed browser. At least not by default a the moment.
One day we will be able to talk about Flatpak without being sidetracked into deconstructing this stupid post. (And the one at flatkill.org — I've seen it posted so many times it's burned in my brain)
>"The current solutions involve packaging entire alternate runtimes in containerized environments. Flatpak, Snap, AppImage, Docker, and Steam: these all provide an app packaging mechanism that replaces most or all of the system’s runtime libraries, and they now all use containerization to accomplish this."
[...]
>"All of these technologies are essentially building
an entire OS on top of another OS
just to avoid the challenges of backwards compatibility."
This is basically using containers to replace all system libraries -- to insure that a downloaded binary app always works.
From this point forward, we'll use the term "API" to represent not just Linux kernel syscalls, but the totality of all library calls (system and otherwise!) used by a given downloaded binary application!
Observation: API (in-)consistency (AKA "Stability") one Linux version to another, one Linux distro to another -- is the real problem!
That's the real cause!
Because everything else, everything else, is effect, not cause!
The containerization, the bloated "everything but the kitchen sink" downloads, are the effect of the problem of API (in-)consistency!
Phrased a simpler way -- there is absolutely NO guarantee of consistency between the libraries, system and otherwise, of any two Linux distros!
So if a binary app is to run on all Linux distros -- then it had better damn well better make sure that the exact specific version of all of the libraries that it needs -- are managed by it, not the host operating system!
Containers and bloated library downloads -- are (unfortunately) currently necessary to provide this!
Is flathub.org not a great GUI for browsing apps. If you click the down arrow next to 'Install', it gives you the command to install from the command line, so it's just a quick copy and paste.
Or you can download the .flatpakref and define your own app handler instead of gnome-software. The handler just has to run `flatpak install /path/to/app.flatpakref`. A quick bash script + something like zenity (for gui dialogs) could take care of that.
Really enjoying Mint's approach to this.
When the flatpak for Audacity fails to launch, uninstall and switch to a working version from apt all within the same window.
[+] [-] Kalanos|2 years ago|reply
flatpak is like a cross-distro snap that actually works. some of the apps are buggy at the fringes, but i've been opening issues to smooth them out. some of the apps like VS Code claim to be from microsoft, but are... unofficial?
[+] [-] NekkoDroid|2 years ago|reply
Unless they have a verified checkmark next to the company/owner of the project it will be a 3rd party package of it. The name is mainly intended as a "This is from X" instead of "This is packaged by X" (unless you actually see the verified badge)
[+] [-] xcrunner529|2 years ago|reply
[+] [-] different_base|2 years ago|reply
You are right. Besides proprietary app store, Snap lacks even basic sandboxing in non-Debian based distros. I can't believe that Canonical engineers thought this was a good idea when designing a cross platform packaging format.
Flatpak got everything right from it's initial design. Multiple repositories, Sandboxing that actually works in any Linux distro, OSTree to reduce disk space usage etc.
[+] [-] tracker1|2 years ago|reply
A nice permissions interface so the manifest can declare, this app needs x, that you can approve instead of needing secondary apps to change permissions.
I don't mind snaps. I'd like to see better integration to move AppImage downloads to a single location and add them to the apps menu directly.
[+] [-] zdware|2 years ago|reply
[+] [-] banger180|2 years ago|reply
[+] [-] palata|2 years ago|reply
[+] [-] sph|2 years ago|reply
Alas, today is not that day.
[+] [-] peter_d_sherman|2 years ago|reply
My takeaways:
>"The current solutions involve packaging entire alternate runtimes in containerized environments. Flatpak, Snap, AppImage, Docker, and Steam: these all provide an app packaging mechanism that replaces most or all of the system’s runtime libraries, and they now all use containerization to accomplish this."
[...]
>"All of these technologies are essentially building
an entire OS on top of another OS
just to avoid the challenges of backwards compatibility."
This is basically using containers to replace all system libraries -- to insure that a downloaded binary app always works.
From this point forward, we'll use the term "API" to represent not just Linux kernel syscalls, but the totality of all library calls (system and otherwise!) used by a given downloaded binary application!
Observation: API (in-)consistency (AKA "Stability") one Linux version to another, one Linux distro to another -- is the real problem!
That's the real cause!
Because everything else, everything else, is effect, not cause!
The containerization, the bloated "everything but the kitchen sink" downloads, are the effect of the problem of API (in-)consistency!
Phrased a simpler way -- there is absolutely NO guarantee of consistency between the libraries, system and otherwise, of any two Linux distros!
So if a binary app is to run on all Linux distros -- then it had better damn well better make sure that the exact specific version of all of the libraries that it needs -- are managed by it, not the host operating system!
Containers and bloated library downloads -- are (unfortunately) currently necessary to provide this!
Related:
"Linux Library Mismatch":
https://www.google.com/search?q=linux+library+mismatch
"DLL Hell" (the MS-Windows equivalent)
https://en.wikipedia.org/wiki/DLL_Hell
Software Engineering: Bertrand Meyer, "Design By Contract":
https://en.wikipedia.org/wiki/Design_by_contract
API Contracts: "What is an API Contract?":
https://www.youtube.com/watch?v=-qM__ozdHCU
Eelcho Dolstra: "The Purely Functional Software Deployment Model":
https://edolstra.github.io/pubs/phd-thesis.pdf#page=11
Image-based Linux distributions and associated tools:
https://github.com/castrojo/awesome-immutable
Spencer Baugh: "Managing Dependencies":
https://catern.com/posts/deps.html
[+] [-] anthk|2 years ago|reply
[+] [-] l72|2 years ago|reply
Or you can download the .flatpakref and define your own app handler instead of gnome-software. The handler just has to run `flatpak install /path/to/app.flatpakref`. A quick bash script + something like zenity (for gui dialogs) could take care of that.
[+] [-] reddit_clone|2 years ago|reply
[+] [-] unintendedcons|2 years ago|reply
[+] [-] 2OEH8eoCRo0|2 years ago|reply
Keep up the good work Flathub team!