31–40 of 166 posts
Hypothesis: HN story up-voters are heavily drawn from Free / Open Source Software folks interested in issues that were broadly discussed in "tech" two decades ago (Linux for the desktop!) and are much less broadly discussed today.
Flatpacks solve no problem that I have, and bring their own headaches, so for me, flatpack is certainly not the future. Same with snaps, although I dislike snaps more.
I found Keepass to be a snap/flatpak once: so many extra layer of complexity for a passwrd manager? No way that's good for security.
I just want to point out that Windows actually has similar packaging problems. For some reason, Windows didn’t ship with C/C++/.NET runtimes. So practically every app ships with either a copy of the runtime DLLs or an installer to install those runtimes globally. Every Windows installation inevitably gets a million msvcrt dlls across random places, never getting any security updates. I believe this situation is a lot…
It has different tradeoffs to the glibc model.
Just built a new Gaming Linux PC which is intended to replace my aging Dell XPS 13 as my daily driver. Decided to go all-in on flatpaks, as I've been trying to stay away from rpm-fusion. The Steam Flatpak has been an adventure, to say the least. I added a second SSD just for games that gets automatically mounted on boot, and I gather that having the games installed somewhere outside of steam's /home/ directory was no…
They also assume that having distributions and end users produce a multi-MB security policy written in an arcane, poorly-documented policy language will somehow lead to a correctly configured sandbox.
I greatly prefer the OpenBSD approach, where the upstream application developer builds calls to things like pledge(2) into their program, and then tests that it behaves correctly before releasing it:
Just built a new Gaming Linux PC which is intended to replace my aging Dell XPS 13 as my daily driver. Decided to go all-in on flatpaks, as I've been trying to stay away from rpm-fusion. The Steam Flatpak has been an adventure, to say the least. I added a second SSD just for games that gets automatically mounted on boot, and I gather that having the games installed somewhere outside of steam's /home/ directory was no…
It is strange to watch everyone fight about snaps, flatpaks, silverblue ad nauseam when Nix (or its full-OS version, NixOS, or the GNU alternative, Guix) has already definitively solved this problem but is still considered too arcane for most people to use. It only uses the disk space it must, AND every app only accesses the dependencies it needs. It's the best of all worlds (except for the learning curve, which is o…
Doesn't matter, Flatpak won over Appimages and Snaps in adoption numbers. And the example given here for GIMP having r/w permission to your home doesn't hold water. The distro-packaged app probably has the same permissions in comparison. At least with Flatpak, to deny it this permission is a simple toggle with Flatseal.
I think it's an unfortunate necessity for some kinds of applications. Eg, we make this: https://overte.org/ We're currently using AppImage because that was the first thing that worked for us, but most of the reasons are the same either way: We want to spend time developing the software, and that means it's hard to justify packaging every release for a dozen distributions. And I'd say nobody particularly wants to do i…
Personally I prefer an environment where people are free to experiment and not be held back by backwards compatibility and opinions. Any utility that can automate backwards compatibility is good imo.