It’s a neat concept. The distro-agnostic aspect is definitely a plus for some people but I still distro-specific installation methods. The only time I would seek out the Flatpak version of a particular software is when it’s the only version available.
I prefer Arch Linux’s use of flatpaks, which is none at all ever
Joke’s on you, I use Flatpaks on Arch
Why, it’s totally unnecessary.
Mostly because of detailed and easy permissions, and also because I have other distibutions on my other computers and want my programs to be consistent everywhere - same programs, same version.
i have a couple on arch also, mostly because of dependency issues breaking the program and it being a pain in the ass to fix
Which ones? Everything in the arch main repos are compiled for your system, and most things in the AUR can either be built from source, or have -bin installs.
aleph one from the AUR refused to run properly, often crashing on startup so i just grabbed the flatpak
the weirdest one was ghostwriter from the official repos, for some reason one day the preview window showed heavily corrupted output and tinkering with it on and off for a week did nothing, including a complete purge and reinstall of the program
the flatpak was the only version of it that worked after that
Me pretty much only ever using arch Linux: “what the fuck is a flatpak”
I once had to install Firefox into wsl (Ubuntu) and I wanted the kms on the spot.
But maybe it’s not that bad for newer people to get started with Linux.
there’s a gui for flatpaks?
No gui’s to my knowledge, but there are package managers that can install them, such as Bauh.
KDE Discover and GNOME Software can install from FlatHub (or other Flatpak repos, if you add those).
That reminds me, is Flatpak packaging CLI tools already?
AFAIK, no
deleted by creator
I’ve packaged a CLI that I made as a flatpak. It works just fine. Nothing weird was required to make it work.
The only thing is that if you want to use a CLI flatpak, you probably want to set an alias in your shell to make running it easier.
I’m not sure why more CLIs aren’t offered as flatpaks. Maybe because static linking them is so easy? I know people focus on flatpak sandboxing as a primary benefit, but I can’t help but think of static linking was easier for bigger applications, it wouldn’t be needed as much.
Looks like it does? Or at least could?
https://unix.stackexchange.com/questions/740712/does-flatpak-support-command-line-applications
I’ve never seen one so far though
deleted by creator
deleted by creator
It destroys the beautiful and carefully cultivated ecosystem of distributed packages that has been the bedrock of Linux for decades. They’re bloated, often not quite as sandboxed as claimed, have created packaging chaos, and assume availability of system services that may not be there.
All of this is true and precisely zero normies care about any of it.
The fact that I can put my
idiotsfamily on any modern distro and tell them to use the app store alone makes flatpaks king of the app management
I like the sandboxing of Flatpak, but I prefer AppImage as I don’t like having the Flatpak runtime requirement.
Don’t AppImages also have a similar requirement just with stuff that is already installed on many popular distros so many people just don’t notice it? I think I read somewhere that running AppImages on systems that even slightly differ from the big popular distros is a pain since you still have to ship this stuff with them but it is more cumbersome than with flatpaks.
That is technically true with things like glibc, but I’ve never seen a system that did not already include baseline packages.
Flatpaks are good, especially compared to snap.
The future is atomic OS’s like silverblue, which will make heavy use of things like flatpak.
Snap is not all bad if you’re on a Ubuntu based distro, I just don’t like the way it’s pushed and that it comes from Ubuntu mostly. Startup time is a major issue for me also, but all in all it works.
I’m still sitting on the fence, heavily prefer flatpak but when Ubuntu is going to package nvidia drivers in a snap it’s a thing I’m up for trying.
My understanding is that if I’m on Ubuntu and the snap uses the same underlying Ubuntu version as my distro it should be fast but I haven’t seen it.
deleted by creator
Atomic distros are cool, and I’m sure they will only get more popular, but I don’t buy the idea that they’re “The” future. They have their place, but they can’t really completely replace traditional distros. Not every new thing needs to kill everything that came before it.
They have their place, but they can’t really completely replace traditional distros.
As it stands, I kinda agree. But I truly wonder to what extent we might be able to close the current gap.
Immutable OSes are difficult to use for coding or other tasks that include installing many terminal utilities and for that reason, I don’t recommend them and certainly don’t want them to be the future of Linux distros. And if I’m going to create a container running a different distro to install and run the apps I want to use, then I may as well use that distro on my host.
You just move to user directory installation of most tools via brew on Linux. It’s not difficult. The Bazzite distro handles all this incredibly well via brew, flatpaks, and distrobox.
Having nails driven into my testicles is better than snap. It’s not a high bar.
Haven’t had much opportunity to use snap, what’s the problem with them?
And also the fact that the store backend is proprietary
Haven’t had much opportunity to have nails driven into my testicles.
Wanna meet? /s
For me, it’s the unrenameable, unmoveable, non-hidden snap directory in my home directory’s root that doesn’t even follow the naming convention of the other directories in there.
What everyone else has already said, plus sudden updates that nuke active applications.
> plus sudden updates that nuke active applications.This is not what’s supposed to happen. If an app installed through flatpak is active while it’s receiving an update, then the update is not supposed to affect the running application until it’s closed/restarted.Edit: Somehow I didn’t realize the concern was raised against Snap and not Flatpak.
The thread is about snap and why it’s worse than flatpak.
Luckily this was about Snap.
My bad. Thank you for clarifying!
We’re talking about snaps in contrast.
My bad. Thank you for clarifying!
Mostly start up time for me. It just takes the programs longer to launch.
I don’t like how so many distros ship with discover configured to install flatpaks by default. It’s a huge newbie trap when you click “open file” and uh where are all my files?? You should only install a flatpak if the program is not available for your OS, or if the native version doesn’t work for some reason.
Former OS security here (I worked at an OS vendor who sold an OS or two and my job involved keeping it secure).
Fuck no.
Sorry if that makes you downvote, but it doesn’t make them safer.
Would you mind elaborating?
A few reasons security people can have to hesitate on Flatpak:
- In comparison to sticking with strictly vetted repos from the big distros like Debian, RHEL, etc., using Flathub and other sources means normalizing installing software that isn’t so strongly vetted. Flathub does at least have a review process but it’s by necessity fairly lax.
- Bundling libraries with an application means you can still be vulnerable to an exploit in some library, even if your OS vendor has already rolled out the fix, because of using Flatpak software that still loads the vulnerable version. The freedesktop runtimes at least help limit the scope of this issue but don’t eliminate it.
- The sandboxing isn’t as secure as many users might expect, which can further encourage installing untrusted software.
By a typical home user’s perspective this probably seems like nothing; in terms of security you’re still usually better off with Flatpak than installing random AUR packages, adding random PPA repos, using AppImage programs, installing a bunch of Steam games, blindly building an unfamiliar project you cloned from github, or running bash scripts you find online. But in many contexts none of that is acceptable.
I thought flatpaks were created to make packaging easier, not to solve all security issues. Still sounds like a win to me.
I mean, they added “bash scripts you find online”, which are only a problem if you don’t look them over or cannot understand them first… Their post is very much cemented in the paranoid camp of security.
Not that they’re wrong. That’s the big thing about security once you go deep enough: the computer has to work for someone, and being able to execute much at all opens up some avenues of abuse. Like securing a web based service. It has to work for someone, so of course everything is still vulnerable at some point. Usually when private keys or passwords are compromised if they’re doing things remotely correctly, but they’re still technically vulnerable at some point.
The parent comment mentions working on security for a paid OS, so looking at the perspective of something like the users of RHEL and SUSE: supply chain “paranoia” absolutely does matter a lot to enterprise users, many of which are bound by contract to specific security standards (especially when governments are involved). I noted that concerns at that level are rather meaningless to home users.
On a personal system, people generally do whatever they need to in order to get the software they want. Those things I listed are very common options for installing software outside of your distro’s repos, and all of them offer less inherent vetting than Flathub while also tampering with your system more substantially. Though most of them at least use system libraries.
they added “bash scripts you find online”, which are only a problem if you don’t look them over or cannot understand them
I would honestly expect that the vast majority of people who see installation steps including
curl [...] | sh(so common that even reputable projects like cargo/rust recommend it) simply run the command as-is without checking the downloaded script, and likewise do the same even if it’ssudo sh. That can still be more or less fine if you trust the vendor/host, its SSL certificate, and your ability to type/copy the domain without error. Even if you look at the script, that might not get you far if it happens to be a self-extracting one unless you also check its payload.Yea, that’s why I added the, “not that they’re wrong…” part. Interesting how no one actually understands what those simple words mean.
cool, thanks
I have used rpms, AppImages, Flatpaks, and source. I have even used a snap or two when I had no other choice.
If you can’t work with them all, can you even say you Linux Bro?
Bro, TRUTH. I have preferences but when you gotta get something done, it doesn’t matter how the app comes bundled. I’d run .exe’s through Wine if I needed to.
If you don’t compile everything from source, you may as well get a Chromebook!
Never, ever, ever do more effort than is required.
There are merits to using flatpaks. With flatseal application, you can fine-tune the permissions given to a certain flatpak application. The best thing is restricting internet usage.
deleted by creator
I get the convenience, I really do, and works on every linux distro which is a plus, but I usually stay clear of them because of the bloat. Maybe that is a misconception on my part. I should preference that with the fact I use Arch (btw)…so AUR usually has everything I need.
deleted by creator
FP and Electron both are brutal on limited storage, so being able to pick and choose where needed can be helpful.
It just doesnt work half the time. I avoid them as much as possible.
It’s not my fault they make running apps from the cli so irritating. Broken by design. Even snaps work better.
Write name of program
Enter
