13 ms·

Flatpak is not the future (2021)

108 points by shrvtv 3y ago

gjsman-1000 3y ago
Most of this is obsolete, especially the complaints about size. Worth reading: https://news.ycombinator.com/item?id=29316024 https://news.ycombinator.com/item?id=29316024 https://news.ycombinator.com/item?id=31406556 https://news.ycombinator.com/item?id=31406556
Tomte 3y ago
But it's the present. And a godsend. I'm using it for current Firefox, Zotero, Joplin and two or three more programs, none of which are packaged in Debian (except Firefox, but only the LTS version that doesn't work with all my extensions). Unless you can offer something better, I'll keep using it.
- 5- 3y ago
  > Firefox should be able to just use the mozilla's official build which comes with an auto-updater (and it implements the sandbox itself, so no need for another one on top). > Zotero > Joplin both electron shells. also come with their sandbox already. most rolling release distributions would just package these with a system-provided electron build.
  - pengaru 3y ago
    > (it implements the sandbox itself, so no need for another one on top). "An unexpected message in the WebGPU IPC framework could lead to a use-after-free and exploitable sandbox escape." [0] Defense in depth applies here, you definitely want to sandbox any network application as complex as a modern web browser. [0] https://nvd.nist.gov/vuln/detail/CVE-2022-26486 https://nvd.nist.gov/vuln/detail/CVE-2022-26486
  - teruakohatu 3y ago
    > Zotero > both electron shells Zotero is a XUL application, not Electron. The soon to be released version 7 is a major rewrite and is based on Firefox. Zotero is one of those cruitual applications where Flatpak is nice. I want it to be self contained. I don't want anything messing it which could lose me weeks of research.
  - smashed 3y ago
    > both electron shells. also come with their sandbox already. Not sure about the 2 specific apps posted, but web applications packaged as electron apps often do so in order to easily escape the normal browser sandbox without having to prompt for permissions? Or even call into native code which would be impossible from a web app. I would not think that because an app is electron based, it is sandboxed from your system. Ideally if you can run the same app under your normal web browser, you'd be fine. I see many people install the Slack app for example, but the web version works just as well within the full browser sandbox.
    - c-hendricks 3y ago
      You're correct. In fact, they can even let webpages break out of the sandbox. So, some random JS loaded from the web can now compromise your system. The person you're replying to is quite mistaken.
  - Hamcha 3y ago
    I always assume Electron apps are going to be more vulnerable than your average app. They tend to have the same vulnerabilities as web browsers (who are a big target for exploits given the reach) but have 2 additional layers of "bureaucracy" (the App's own update schedule and Electron's) before the underlying vulnerable engine is patched.
- tombert 3y ago
  I always get a little annoyed at "X is not the future" post because we don't live in the future, we live now. Much as we like to personalize them, computers are tools that we use to get things done, and Flatpak is among the better things we have right now for dealing with the awfulness of Linux packages. If a better thing comes in the future I'll use that.
  - phalf 3y ago
    But this is Hacker News where people who build things hang out. If you are fine with the state of the world and are not involved in advancing it, good for you, you can close this discussion. But many people around here are building the next things. And in that context it makes sense to think about what's the future and what's not.
    - delfinom 3y ago
      You sound like every other person responsible for the rampant NIHism in Linux and the reason why the "year of the Linux desktop" is in the year 6002 at this rate.
      - mid-kid 3y ago
        I swear the only people going on about the "year of the linux desktop" are its detractors.
      - phalf 3y ago
        Sorry, I don't see how my post relates to NIHism. Could you elaborate?
      - biasedestimate 3y ago
        If "the year of the linux desktop" requires turning linux into a windows/macos clone, I am happy to postpone it.
  - regularjack 3y ago
    > Flatpak calls itself “the future of application distribution”. The post is making the author's case against this claim, so I think the title makes sense.
- prmoustache 3y ago
  Isn't that just because you aren't using a decent distro? I mean I am surprised that firefox or librewolf or whatever fork is not packaged by Debian in a current version.
  - jdiff 3y ago
    That's kinda Debian's shtick. Its ethos is to be rock-solid stable no matter what. No changes but bug fixes, and it gets those in a very timely manner. It's an amazing distro for what it is, but in a desktop or workstation sometimes you just need up-to-date software and for that, Flatpak makes a whole lotta sense. Stable OS core with the latest applications shipped on top. It may not fit your own use case but it's one of the leading distros that exist, it far exceeds just "decent."
    - JohnFen 3y ago
      Yep. That "solid, not cutting edge" philosophy is one of the main reasons why Debian is my favorite distro.
- Dwedit 3y ago
  If you want a more recent Firefox, try backports?
- banthar 3y ago
  Zotero Flatpak comes with 4 year old Firefox binary and full access to your home directory. The compromise currently being made here is your security.
- paddim8 3y ago
  Or just use Arch and have almost everything in official repos (and the rest in the AUR). I have had less issues with arch than with debian, because Arch is so simple. If you want to install something, you install it, and the it's installed. One command. Always. I found that debian would break more easily because I had to mess around with unofficial repos and things like flatpak just to get basic programs. More complexity, more that can break, more reliance on 3rd parties. Arch has been rock solid.
  - chronogram 3y ago
    I've been using Arch for over a decade and never liked using the AUR. Too much vetting and building. So I use flatpak for the non-DE graphical applications now.
- kaba0 3y ago
  Nix, NixOS. It has firefox LTS and nightly, and the other two packaged as well. You can in fact freely go back and install any combination of versions/configurations for each of these, even multiple times. Flatpak mixes up packaging and sandboxing, these two imo should not be that close coupled. Especially that it doesn’t even solve the former properly (not sure about the latter).
HeckFeck 3y ago
If the future is Snap I don't want to be around for it.
jasoneckert 3y ago
I wonder if the author of the article feels differently about Flatpak today (a great deal has changed in the past 2 years, and Flatpak seems to have a vibrant future today).
- prmoustache 3y ago
  There are a lot of points that are still valid. Like the fake security feeling people have using flatpak because of the advertised sandboxing, the size of the software being downloaded or the slower startup of applications.
JohnFen 3y ago
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.
- cies 3y ago
  Same for me. I had really weird stuff to debug. Could not save from FF to /tmp for instance (and I really like that for downloads I should use immediately and can be removed). 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.
- ibejoeb 3y ago
  Yeah. I can never seem to get the fonts to work with flatpak/snap Firefox. Seems kind of essential.
- curt15 3y ago
  What about transactional updates? Applications might have undefined behavior if their libraries or other assets are changed under their feet.
  - JohnFen 3y ago
    If there's a security issue, I want to be able to update libraries and such independently of applications rather than waiting for the application devs to do it. I don't think it's caused a problem for me in the last 10 years or more. It may have and just forgotten about it, though. If it happens, it's not a huge problem to fix it.
emersion 3y ago
Related: https://blog.brixit.nl/developers-are-lazy-thus-flatpak/ https://blog.brixit.nl/developers-are-lazy-thus-flatpak/
- teddyh 3y ago
  This is a much better argument against Flatpak (and its ilk) than the linked article.
unixhero 3y ago
I for one dont care about disk space and think Flatpack is great
- jcastro 3y ago
  The disk space thing is a myth, once you start to install apps people actually use it ends up being about the same. If you test it with VMs you can check it out for yourself: https://www.ypsidanger.com/wasting-disk-space/ https://www.ypsidanger.com/wasting-disk-space/
  - ekianjo 3y ago
    Tell me again when you dont end up with 20 different versions of Nvidia drivers
    - jcastro 3y ago
      Your system should be cleaning up unused runtimes. That's perhaps a distribution integration issue that should be filed and fixed?
      - ekianjo 3y ago
        it's not cleaning runtimes if you have 20 different flatpaks using different versions of the runtime. That's the whole weakness of this system.
  - WesolyKubeczek 3y ago
    What is not a myth, though, is that if you think you have patched some bug or hole in a system library, think again, because flatpaks are a distro in your distro (old yo dawg meme slide follows), sometimes a few even. And their update cadence is not the same. Yes, it means that sometimes they will be ahead on patches, why not. So at the very least, two systems on your system. Given that there are hacks to share some of your fd.o stuff, let’s say one and a half.
pmarreck 3y ago
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 of course why it's considered "arcane"). As a use-case where its capabilities came in handy just today, I had some old files I encrypted with gpg1 which didn't cleanly decrypt with gpg2. Accessing the old version of gpg, just for this one console and this one time for this one task, was a one-liner: "nix-shell -p gnupg1orig". With that one command it installed everything that version required, and put its executables at the front of my PATH in my shell, so I was able to do the decryption. When I exit, that stuff will get collected on the next garbage collection.
- sanderjd 3y ago
  I really like Nix, but I think "is still considered too arcane for most people to use" is a contradiction of "has already definitively solved this problem". Being usable for most people is an important part of solving this problem, which I unfortunately don't think Nix has accomplished. Maybe there is some way to improve its UX while keeping the fundamental model intact, in order to solve this problem.
  - pmarreck 3y ago
    The core idea of Nix that has basically "solved this problem" is simply trying to control for all possible inputs to a build-time and run-time environment, and lock them all down with hashes, which is in essence basically treating a build like a pure function. (In theory, this should result in deterministic builds and deterministic runs. And in practice, nearly 100% of the time, it does.) The point of a "derivation" is to provide that for code that does not. Nix, and derivations in general, are thus sort of a "scaffolding" over all the existing build tool and dependency managers out there that bring them "over the line" regarding this. If these build tools and dependency managers all embraced the Nix way of specifying dependencies, and they all agreed to store it in a Nix store (i.e. a Merkle tree), then hypothetically, Nix would not even be necessary (except perhaps as a group of small tools to manage the store). 1) This is probably too much to ask of people. 2) This still leaves behind decades of software that would still need to be built in the future and would thus still need something like the "scaffolding". But again, the fundamental idea is really just this: Treat builds and runs as pure functions. Every other advantage derives directly from that principle. If someone else can figure out how to do this as simple as possible, I'm all for it! In the meantime, I think every developer should read Eelco's thesis paper on this idea: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf Of course, the OTHER way to solve this problem is just to statically-compile everything, leading to an explosion of disk-space usage. And even then, you wouldn't get guaranteed rebuilds.
gclawes 3y ago
I'm curious how all of this compares to macOS's .app packages.
- harrego 3y ago
  .app packages are merely the binary with assets and a bunch of metadata for code signing, entitlements, icons and locales. If you "Show Package Contents" there's not much to them.
- mike_hearn 3y ago
  Apple bundles compared to Flatpaks: • Both use reverse DNS to globally identify themselves, neither actually verifies DNS ownership. • Almost everything is a bundle, except for CLI apps. FlatPaks on the other hand are being auto-converted from previous packaging systems. • Bundles don't have dependencies. In theory they can, but in practice they never do. You depend on macOS/iOS as a unitary platform and bundles expose what the min version they require is. • There is no update mechanism except the app store. If you want that you need to use something like Sparkle. A tool like Hydraulic Conveyor [1] can create a bundle with integrated Sparkle for your cross platform application without needing a Mac. Likewise no attempt to deduplicate redundant files. Interestingly, if you use the latest MSIX tech on Windows then the OS will deduplicate shared files (including libs) that are bundled with apps, in a transparent manner. • Sandboxing is optional on macOS. If you don't opt in, you are put inside a relatively weak sandbox that just blocks access to a few folders in your home directory and stops you tampering with other apps/the OS. If you do opt in, you get a PowerBox design that's like what FlatPak is trying with portals. There's no way in the UI to see if an app is sandboxed because it's intended as a vulnerability mitigation and not a way to run untrusted code. • Both bundles and the binaries within those bundles advertise which version of macOS/iOS they're expecting, and the OS frameworks can change behaviors depending on that for backwards compatibility reasons. It's a bit easier to maintain compatibility with Objective-C APIs than with C++, but still, Apple does it for all their APIs including the C++ ones. [1] https://hydraulic.dev/ https://hydraulic.dev/ (disclosure: my company)
AdmiralAsshat 3y ago
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 not jiving with flatpak's security model. It took some non-trivial editing (thanks, flatseal) to finally let the Steam flatpak be able to write outside of its own directory and install the games. I still get occasional weirdness, especially on older games. I wasn't hearing any sound effects on Team Fortress 2, which I eventually discovered was tied to an selinux alert. At last check in, I still can't launch CS:Go, because of some backend problem while trying to play the opening movie...
- PurpleRamen 3y ago
  I had similar problems with Lutris, but never came around to fully solve them. Now I'm using the native debian-package, and never had any problem again. Flatpaks overall are working fine, I use them for portable apps on my mobile SSD. But the security can be a hassle on a hacking friendly-system which is doing too much outside the expected. So one should be aware that Flatpaks might be a tad different from native packages.
- post-it 3y ago
  It's insane that flatseal isn't a native part of flatpak. Problems like you encountered mean that the packaging system is incomplete by default.
- hedora 3y ago
  Fine fine-grained permissions systems like selinux end up introducing bizarre error conditions that are outside of upstream's test suite. Those error conditions are often exploitable. 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: https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
Octabrain 3y ago
Flatpak is good overall but it has one things I dislike: - Not being oriented to also CLI apps. Apart from that, I like it for its convenience and I think it will be the future (or a similar approach). The reason for my thinking that is that, putting myself in the shoes of a distro maintainer, I can see the appeal and benefit of "isolating" the system packages and libraries from the packages installed by the user. I find it similar to the great relief that Docker brought back in the day when reduced the system administration overhead as it reduces the amount of moving parts on the functioning of an app.
dale_glass 3y ago
I think it's an unfortunate necessity for some kinds of applications. Eg, we make this: https://overte.org/ 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 it. We also expect our users to keep reasonably up to date, not whenever it's convenient to the distribution. Code changes can change the networking protocol, and some of those can require everyone to upgrade. So at least to me it makes perfect sense to package some kinds of applications this way. Maybe not KDE's calculator, but definitely things like games and tools with specialized markets, where it may be difficult to find people wanting to do the work of packaging them for a distribution.
- avhception 3y ago
  While the problems you cited certainly need to be solved by the Linux ecosystem, I don't see why that solution should involve the heavy-handed sandboxing with a thousand overlayfs, containers and whatnot. I wish there was a more straightforward solution that didn't have so many complicated moving parts, more like the static binaries that I get from Go or Rust.
  - dale_glass 3y ago
    I want sandboxing. One reason is that big applications can have many dependencies, and once in a while I find something dlopens something from the host filesystem, finds something incompatible and crashes. So I really want my stuff to run in a sandbox where I know exactly what it's loading and there are no surprises. The other is that we've got a complex system under development and there may well be security exploits. I like the idea of that if somebody breaks our code it's going to take some work to get to the user still.
- pmontra 3y ago
  I install only debs because I don't want too much redundant code around and having to update all of it, if it ever updates. I prefer Debian to care about updating shared libraries. I make few exceptions, none for snaps and flatpacks so far. I installed Firefox from the tar.bz2 on their site, as I did with Windows before my switch to Linux in 2009. It auto updates and so far it's OK. I'm on Debian 11, I'll upgrade to 12 to stay more current. Other exceptions: docker containers for redis and the PostgreSQL versions I have to run for compatibility with the production servers of my customers. I use asdf for that sometimes and also for languages, of course. We can't rely on the versions coming with distros. If I'd really have to use Overte I would do an exception for that too.
Timber-6539 3y ago
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.
- deleted 3y ago
  [deleted]
- prmoustache 3y ago
  The point is the proponent raise the security flag like it is a huge advantage and you could trust anything coming from flathub while it is mostly pixie dusk. Untrustable apps aren't more trustable because they are delivered as flatpaks.
  - Timber-6539 3y ago
    You missed my point. > The point is the proponent raise the security flag like it is a huge advantage and you could trust anything coming from flathub while it is mostly pixie dusk. Okay then, as you criticize Flatpaks give us your alternative to a trusted application. > Untrustable apps aren't more trustable because they are delivered as flatpaks. Nobody made this claim.
    - prmoustache 3y ago
      > Okay then, as you criticize Flatpaks give us your alternative to a trusted application. I am not criticizing, I am saying it is mostly a moot point. The sandboxing allow a bit of isolation but this it ranks quite poorly in term of actual security benefits for the typical end users use cases. > Nobody made this claim. Well, not the authors of flatpak, but yes some did. On medias that many people watch such as youtube videos.
      - Timber-6539 3y ago
        > The sandboxing allow a bit of isolation but this it ranks quite poorly in term of actual security benefits for the typical end users use cases. Ranked poorly in what checklist? > Well, not the authors of flatpak, but yes some did. On medias that many people watch such as youtube videos. Let's try to stay on topic. The point I made was that, the author's example about Flatpak GIMP doing something unauthorized on your system applies to any package format. The differentiating factor here is that Flatpak/Flatseal allows you to sandbox the application easily and quite effectively if I may add.
osmsucks 3y ago
I had to stop using elementary OS when they doubled down on Flatpak because I ran out of disk space. Those runtimes add up. :-/
invokestatic 3y ago
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 better on recent versions of Windows 10/11.
- JonChesterfield 3y ago
  That lets Microsoft break ABI on every release if they see fit. I thought the model was to install the runtimes globally, so you only have one copy of each version, but you install whatever version a given program wants. So you end up with lots, all somewhat different to each other. It has different tradeoffs to the glibc model.
zamalek 3y ago
On my old NVIDIA (never again) laptop, Flatpak left around 30GB of NVIDIA runtimes lying around. Each version approaches 1GB in size, and Flatpak will install updates for all versions of the driver you have ever installed. Downloading a few GBs just to update Firefox is just bloody annoying, even with cheap disk space and fast internet. Fixing it was easy enough, but it took figuring out what's going on, and requires regular maintenance (two things the target user for this project probably wouldn't know how to do). The drivers also never work properly. I've attempted to use several official game flatpaks, and have run into various forms of crashes (including the entire system stalling).
gumballindie 3y ago
Neither are snaps. The future, for regular daily use, are appimages. Much like MacOS dmgs, these are a "single" file (from an end user perspective) that you download, double click, and run. That's it. Ideally we'd see more work in this area. I am slowly trying to figure out how to automate builds for GUI apps and I am considering somehow settings up an inexpensive server to pull, package, and submit appimages to appimagehub. A crowdsourced effort would be cool. Imagine a distro where by default if you place apps in ~/Applications you can just execute them. Comes with risks, but having them "signed" by appimage a lot of it would be mitigated. Linux, while excellent as a desktop, and I am referring to the many awesome distros available, is really user friendly. Let's make it even more user friendly.
- jeroenhd 3y ago
  AppImages waste even more disk space. At least with Flatpak I only need to install libraries once, with AppImages I'm getting a second copy of everything with every application I download. If AppImages were actually directories, like they are in macOS, I could at least run duperemove to fix the disk space issue on BTRFS, but with full images that become a lot harder.
  - gumballindie 3y ago
    Technically speaking appimages are compressed files so maybe someone clever can come up with an idea on how to dedupe them. With mass adoption this issue i think may be solved by someone concerned about disk space. Personally, and probably many casual users, are not as worried about space as they are about convenience. But I think your point is valid, and I think this would make an interesting side project for someone out there. For me, I'd like to see more adoption. The nice to haves will follow.
    - tomrod 3y ago
      Something like docker's layers?
      - 3y ago
samcat116 3y ago
> Personally, I’m much more interested in how to get Excel and Photoshop on Linux rather than untrustworthy drive-by apps and games, so I don’t really care about sandboxing, permissions, portals, app stores, alternate runtimes or really any of the stuff Flatpak does. Guess what Excel and Photoshop will want if they were to ever port their software to Linux.
jasonthorsness 3y ago
vscode flatpack just didn't work for me - found a workaround for terminal not working, but CoPilot extension refused to authenticate. No issues with non-flatpack version :(.
spenrose 3y ago
The #1 story on Hacker News at 2023:08:21T15:41Z is a 2021 discussion of Linux desktop packaging tools. 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.
- spenrose 3y ago
  Five net downvotes (and counting?) for this anodyne observation.
CapsAdmin 3y ago
The fundamental problem to me has always been that people cannot agree on standards, so this a relatively good solution to that problem. I can't think of a better one that doesn't involve people needing to come together to agree on a standard. 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.
danShumway 3y ago
This debate will never die, but while people have been complaining about it, Flatpak has quietly just become a better way to package software for end users. My criteria is that I'm a user, I don't care about what's elegant to developers -- and I have fewer problems with Flatpak than I have with non-Flatpak software. The vast majority of Flatpak problems I do have as a user come down to sandboxing permissions that I actually quite appreciate. The (very) few architectural problems are problems I would have had with other bundling systems too. "Developers are lazy" -> No, no user ever wants to debug dependency issues, and developers can't get rid of dependency issues. This feels like a repeat of the Rust debates where C developers kept complaining that good developers just don't have memory errors. Okay whatever you're very talented, congratulations; but most software isn't written by people who can reliably support multiple distros and lowering the skill requirements to maintain software is good actually because I use hobby projects all the time. Even outside of hobby communities, GoG's Linux installer is so borked that half of the time it's easier to install the Windows versions of the games and run them through Wine (because then you can use Bottles which provides dependency isolation). And I am completely convinced that dependency management is the problem -- Flatpak apps don't have these issues, at least not nearly as many. I'm not saying everything should be a Flatpak, but certainly at the very least most Linux games should be, anything that's graphical that isn't being distributed through an official package manager is a good candidate to at least consider Flatpak. I'm always grateful when I can install a graphical app through Flatpak instead of AUR. Is it the future? Flatpak critics spend a lot of time bashing Flatpak and very little time proposing equivalent fixes or acknowledging why Flatpak exists in the first place. If those issues were solved and the solutions popularized on mainline distros, maybe Flatpak wouldn't be the future. But I'm not holding my breath. This article proposes GoG's system as an alternative and says the existing problems are minor and easy to solve. 2 years later, I have literally never gotten a GoG native Linux installer to run without problems on the Steam deck. I'm not even saying it has to Flatpak, but whatever system you want to propose (Snap, AppImage, whatever) very clearly dependency isolation is better for end users and results in fewer bugs. "It takes up too much space" just isn't a real critique when the alternative being proposed almost universally fails to run on my hardware.
- prmoustache 3y ago
INTPenis 3y ago
I was kinda forced into flatpaks with Fedora silverblue and 10 months later I don't really mind them. They are good enough for a laptop with no special requirements. I have Dino, Steam, Gnome Tweaks, Fractal, Signal, Gimp (crashes a lot), Firefox (because it comes with codecs, unlike the Fedora flatpak), Transmission, Chromium (mostly to run Teams and Outlook for work).
rvz 3y ago
Just goes to show the amount of third-party fragmentation that goes on in the Linux Desktop ecosystem which tons competing alternatives of alternative system components and now installers all in conflict and fighting against the users system. Snaps are only available in the default install in Ubuntu and Flatpaks is not in the default install of other Ubuntu-based distros [0]. Even other distros have neither in their default installs. It is not the same thing with macOS with its first party installation methods provided by Apple that just works. [0] https://www.omgubuntu.co.uk/2023/02/ubuntu-flavors-no-flatpak https://www.omgubuntu.co.uk/2023/02/ubuntu-flavors-no-flatpa...
wudangmonk 3y ago
I only use linux for daily use but deploying software on it is the worst out of any OS that I know of with windows being the best. Every update can potentially break things because who knows what changed in that library you depend on, and its not like you can avoid that by shipping static libraries to prevent this since for whatever reasons everyone has conspired against static libraries, I'm guessing because they take up more space?. Instead of having some minimal set of conventions of where things are supposed to be stored, instead of allowing static libraries to actually work it seems that the solution is to now include the whole system instead. After all storage is cheap right?.
- teddyh 3y ago
  Maybe Guix is for you?
travisgriggs 3y ago
Random tangent. When I see articles linked from this time frame, my brain automatically thinks "Ah, but that was during Covid when a disproportionate amount of people were working from home and a lot of the normal feedback loops weren't running normally. Those were lonely/different times. I'll consider this article accordingly." It's not really rationale/logical/founded, but that's where my brain kind of initially goes. Do others experience this?
bobajeff 3y ago
Flatpaks break a number of apps that I use. So no, it's not the future. Come up with something that works before making it the solution to distribution packaging.
TOGoS 3y ago
One major headache with trying to run precompiled binaries on Linux is that if they were compiled using a newer version of glibc than the target machine, they won't be able to run. Back while working on Factorio, I was trying to get around this problem with endless Docker containers, but coworker Wheybags came up with a much simpler solution to this, which is simply to, at compile time, link to the oldest compatible version of glibc by including a header: https://github.com/wheybags/glibc_version_header https://github.com/wheybags/glibc_version_header It's too bad this hasn't been standard practice for the past 30 years!
ape4 3y ago
Flatpak is the best of all the other alternatives.
OJFord 3y ago
Is there anything that offers mobile-style sandboxing & permissions API like described? I'd love that, but I'm not even sure how it would work, I don't want it via walled-garden app store where you basically have to target it as an extra platform, because of dealing with those APIs... It would need to somehow just sort of slot into Unix, and if you didn't have it 'enabled' on the system it would just plough on uncontrolled as it does today. What's the story or usual recommended practice on NixOS? Seems like the overlap with security-minder types would be quite high, and if you did use something like Flatpak wouldn't that interfere with Nix's own management? (Or at least not use it.) (I didn't learn much from the Flatpak Nix wiki page.)
phkahler 3y ago
A related part of the problem is apps that have a large number of dependencies. We should all be careful about which dependencies we use, keep that to a minimum, and try to use things with a stable API. The other part is library developers need to aim for backward compatibility so apps don't need to care so much about what specific version they're using.
ceronman 3y ago
Flatpak seems to follow a similar path as many other Linux technologies like Wayland or Systemd, in the sense that they seem to arouse the anger of a small but very vocal crowd who really can't stand any challenge to the status quo. So this is the template of the story: There is a new tool or workflow trying to replace or complement an old one. This new tool tries to solve many different complex problems that the old tool, usually designed decades ago, doesn't solve well in this the current world. To do so, obviously, some sort of compromise is required, the new tool won't do certain things that the old tool used to do, but in exchange of that it will do a lot of new things that many users really want. However this small crowd is really pissed by this, without understanding that there is no holly grail solution and some sort of compromise is always required. Additionally, as it's natural with any new technology, the very first incarnations of the new technology are not very mature and there is a lot to polish, a lot of tooling missing, and a chicken and egg problem of not enough users to drive its take off. And the small crowd will use all this as much as they can to try to prevent the world from moving on. However, as time passes, the new tool starts becoming more mature, the obvious shortcomings get fixed, and all the new possibilities that the tool enables start to really shine. And while the initial compromise will always remain, the majority of users realize that the tradeoff was worth it. This has happened with Systemd, it's starting to happen with Wayland, and I believe it will happen with Flatpak was well. We'll see.
- c-hendricks 3y ago
  Great argument calling out similar histories with then-new technologies, posted 4 minutes ago, already turning grey on HN. Please change, HN.
- JohnFen 3y ago
  > without understanding that there is no holly grail solution and some sort of compromise is always required. Why do you assume that such people don't understand this? Sometimes those compromises mean that the tool can no longer accomplish something important to some users. I don't think that being upset that software has become less useful is terribly unreasonable or hard to understand. > Additionally, as it's natural with any new technology, the very first incarnations of the new technology are not very mature and there is a lot to polish, a lot of tooling missing And while the software is in that state, it shouldn't be forced on anyone. It's not unreasonable for people to want to use software that actually works well in the present.
dcow 3y ago
Not dissenting generally, just want to point out that the author is wrong about the file permissions dialog thing: > This is the most complicated and brittle way to implement this. It’s also not at all how other sandboxed platforms work. If I want file access permissions on Android, I don’t just try to open a file with the Java File API and expect it to magically prompt the user. I have to call Android-specific APIs to request permissions first. iOS is the same. So why shouldn’t I be able to just call flatpak_request_permission(PERMISSION) and get a callback when the user approves or declines? On macOS you try to open a file and it’s handled transparently. “iOS is the same” also could use a citation (I don't recall off hand if it is, and kinda doubt it based on the macOS behavior, so I feel a citation is appropriate). I’m slightly confused why the author is comparing Linux desktop with mobile rather than existing desktop implementations of sandboxing… feels a tad disingenuous.
- Dan42 3y ago
  Fully agree. When the user selects a file via the file selection dialog, that automatically implies s/he has given permission to read that file. So the Flatpak libportal approach has really good UX. Having a second popup to grant access to the file would be horrible UX. Which is why apps ask for coarse-grained permissions like "access to all files" in order to bother the user as little as possible with multiple permission dialogs. Which then kinda defeats the point of sandboxing. I'm reminded of how Android apps need to know your "location" in order to scan for wifi networks. In general I think all permission dialogs should be reframed as selection or confirmation dialogs. • Open file dialog -> grants permission to read that file. • Open file for edit dialog -> grants permission to read/write that file. • Save as -> grants permission to read/write that file. • Select which wifi network to connect to -> grants permission to use internet • Do you want to display events in your neighborhood? -> grants permission to location data • Select which camera & mic to use for this call -> grants permission to record video & audio -- I have to say though, apart from that permissions thing, the author makes a lot of good points I hadn't realized before.
nologic01 3y ago
What is the linux app endgame in an ideal world? Imho that is true linux on mobile. With painless, secure, efficient downloads from app stores. (This way the FOSS impact will skyrocket and the promise will be fulfilled) Work backward from that requirement and constraint. Solutions and designs that barely work for the linux desktop will never bring a revolution...
butz 3y ago
While Flatpak is not the future, today it helps keep $HOME directory clean.
deleted 3y ago
[deleted]
denton-scratch 3y ago
I have one AppImage installed on one system (of four, at the moment). Zero flatpaks and snaps. That one AppImage appears to be available only as a Windows install or an AppImage. I dread any future where everything is an AppImage (or whatever). Why not just ship everything with a complete OS? Hell, let's go the whole hog; hardware is also a dependency, it's not just libraries. So let's ship every app as a hardware appliance. This is not why I use Linux.
teddyh 3y ago
If Flatpaks (and similar) are such a great idea, why don’t software in Flakpaks install their own dependencies as Flatpaks?
xp84 3y ago
Article: > How many people on Earth will truly understand how this all works? I feel this. And I think the software industry in general seems to have decided the answer is “No one does or will, and meh, we don’t care.” This is why every mysterious issue with every OS seems unsolvable. Every app is spewing random exceptions to the logs 100 times a second because in fact it does not just work together, most things barely work and nobody cares. We don’t get to have good software that works reliably anymore. Like my phone that turns its ring volume to 100% every few days. It’s not a rogue Shortcut, cuz Shortcuts doesn’t even have that feature (only Media volume). No one will ever know why that occurs, because no one understands the whole stack from top to bottom. And in a way that’s the best case scenario with such a walled garden controlled by one “benevolent” dictator. Using all these packaging frameworks and libraries at once, no one will ever be able to make sense of some kinds of problems, because everyone is cargo-culting some large section of this stack of complexity, because a single person couldn’t hope to make sense of everything.

108 points by shrvtv 3y ago

Most of this is obsolete, especially the complaints about size. Worth reading: https://news.ycombinator.com/item?id=29316024 https://news.ycombinator.com/item?id=29316024 https://news.ycombinator.com/item?id=31406556 https://news.ycombinator.com/item?id=31406556

Tomte 3y ago

But it's the present. And a godsend. I'm using it for current Firefox, Zotero, Joplin and two or three more programs, none of which are packaged in Debian (except Firefox, but only the LTS version that doesn't work with all my extensions). Unless you can offer something better, I'll keep using it.

5- 3y ago
> Firefox should be able to just use the mozilla's official build which comes with an auto-updater (and it implements the sandbox itself, so no need for another one on top). > Zotero > Joplin both electron shells. also come with their sandbox already. most rolling release distributions would just package these with a system-provided electron build.
- pengaru 3y ago
  > (it implements the sandbox itself, so no need for another one on top). "An unexpected message in the WebGPU IPC framework could lead to a use-after-free and exploitable sandbox escape." [0] Defense in depth applies here, you definitely want to sandbox any network application as complex as a modern web browser. [0] https://nvd.nist.gov/vuln/detail/CVE-2022-26486 https://nvd.nist.gov/vuln/detail/CVE-2022-26486
- teruakohatu 3y ago
  > Zotero > both electron shells Zotero is a XUL application, not Electron. The soon to be released version 7 is a major rewrite and is based on Firefox. Zotero is one of those cruitual applications where Flatpak is nice. I want it to be self contained. I don't want anything messing it which could lose me weeks of research.
- smashed 3y ago
  > both electron shells. also come with their sandbox already. Not sure about the 2 specific apps posted, but web applications packaged as electron apps often do so in order to easily escape the normal browser sandbox without having to prompt for permissions? Or even call into native code which would be impossible from a web app. I would not think that because an app is electron based, it is sandboxed from your system. Ideally if you can run the same app under your normal web browser, you'd be fine. I see many people install the Slack app for example, but the web version works just as well within the full browser sandbox.
  - c-hendricks 3y ago
    You're correct. In fact, they can even let webpages break out of the sandbox. So, some random JS loaded from the web can now compromise your system. The person you're replying to is quite mistaken.
- Hamcha 3y ago
  I always assume Electron apps are going to be more vulnerable than your average app. They tend to have the same vulnerabilities as web browsers (who are a big target for exploits given the reach) but have 2 additional layers of "bureaucracy" (the App's own update schedule and Electron's) before the underlying vulnerable engine is patched.
tombert 3y ago
I always get a little annoyed at "X is not the future" post because we don't live in the future, we live now. Much as we like to personalize them, computers are tools that we use to get things done, and Flatpak is among the better things we have right now for dealing with the awfulness of Linux packages. If a better thing comes in the future I'll use that.
- phalf 3y ago
  But this is Hacker News where people who build things hang out. If you are fine with the state of the world and are not involved in advancing it, good for you, you can close this discussion. But many people around here are building the next things. And in that context it makes sense to think about what's the future and what's not.
  - delfinom 3y ago
    You sound like every other person responsible for the rampant NIHism in Linux and the reason why the "year of the Linux desktop" is in the year 6002 at this rate.
    - mid-kid 3y ago
      I swear the only people going on about the "year of the linux desktop" are its detractors.
    - phalf 3y ago
      Sorry, I don't see how my post relates to NIHism. Could you elaborate?
    - biasedestimate 3y ago
      If "the year of the linux desktop" requires turning linux into a windows/macos clone, I am happy to postpone it.
- regularjack 3y ago
  > Flatpak calls itself “the future of application distribution”. The post is making the author's case against this claim, so I think the title makes sense.
prmoustache 3y ago
Isn't that just because you aren't using a decent distro? I mean I am surprised that firefox or librewolf or whatever fork is not packaged by Debian in a current version.
- jdiff 3y ago
  That's kinda Debian's shtick. Its ethos is to be rock-solid stable no matter what. No changes but bug fixes, and it gets those in a very timely manner. It's an amazing distro for what it is, but in a desktop or workstation sometimes you just need up-to-date software and for that, Flatpak makes a whole lotta sense. Stable OS core with the latest applications shipped on top. It may not fit your own use case but it's one of the leading distros that exist, it far exceeds just "decent."
  - JohnFen 3y ago
    Yep. That "solid, not cutting edge" philosophy is one of the main reasons why Debian is my favorite distro.
Dwedit 3y ago
If you want a more recent Firefox, try backports?
banthar 3y ago
Zotero Flatpak comes with 4 year old Firefox binary and full access to your home directory. The compromise currently being made here is your security.
paddim8 3y ago
Or just use Arch and have almost everything in official repos (and the rest in the AUR). I have had less issues with arch than with debian, because Arch is so simple. If you want to install something, you install it, and the it's installed. One command. Always. I found that debian would break more easily because I had to mess around with unofficial repos and things like flatpak just to get basic programs. More complexity, more that can break, more reliance on 3rd parties. Arch has been rock solid.
- chronogram 3y ago
  I've been using Arch for over a decade and never liked using the AUR. Too much vetting and building. So I use flatpak for the non-DE graphical applications now.
kaba0 3y ago
Nix, NixOS. It has firefox LTS and nightly, and the other two packaged as well. You can in fact freely go back and install any combination of versions/configurations for each of these, even multiple times. Flatpak mixes up packaging and sandboxing, these two imo should not be that close coupled. Especially that it doesn’t even solve the former properly (not sure about the latter).

HeckFeck 3y ago

If the future is Snap I don't want to be around for it.

jasoneckert 3y ago

I wonder if the author of the article feels differently about Flatpak today (a great deal has changed in the past 2 years, and Flatpak seems to have a vibrant future today).

prmoustache 3y ago
There are a lot of points that are still valid. Like the fake security feeling people have using flatpak because of the advertised sandboxing, the size of the software being downloaded or the slower startup of applications.

JohnFen 3y ago

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.

cies 3y ago
Same for me. I had really weird stuff to debug. Could not save from FF to /tmp for instance (and I really like that for downloads I should use immediately and can be removed). 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.
ibejoeb 3y ago
Yeah. I can never seem to get the fonts to work with flatpak/snap Firefox. Seems kind of essential.
curt15 3y ago
What about transactional updates? Applications might have undefined behavior if their libraries or other assets are changed under their feet.
- JohnFen 3y ago
  If there's a security issue, I want to be able to update libraries and such independently of applications rather than waiting for the application devs to do it. I don't think it's caused a problem for me in the last 10 years or more. It may have and just forgotten about it, though. If it happens, it's not a huge problem to fix it.

emersion 3y ago

Related: https://blog.brixit.nl/developers-are-lazy-thus-flatpak/ https://blog.brixit.nl/developers-are-lazy-thus-flatpak/

teddyh 3y ago
This is a much better argument against Flatpak (and its ilk) than the linked article.

unixhero 3y ago

I for one dont care about disk space and think Flatpack is great

jcastro 3y ago
The disk space thing is a myth, once you start to install apps people actually use it ends up being about the same. If you test it with VMs you can check it out for yourself: https://www.ypsidanger.com/wasting-disk-space/ https://www.ypsidanger.com/wasting-disk-space/
- ekianjo 3y ago
  Tell me again when you dont end up with 20 different versions of Nvidia drivers
  - jcastro 3y ago
    Your system should be cleaning up unused runtimes. That's perhaps a distribution integration issue that should be filed and fixed?
    - ekianjo 3y ago
      it's not cleaning runtimes if you have 20 different flatpaks using different versions of the runtime. That's the whole weakness of this system.
- WesolyKubeczek 3y ago
  What is not a myth, though, is that if you think you have patched some bug or hole in a system library, think again, because flatpaks are a distro in your distro (old yo dawg meme slide follows), sometimes a few even. And their update cadence is not the same. Yes, it means that sometimes they will be ahead on patches, why not. So at the very least, two systems on your system. Given that there are hacks to share some of your fd.o stuff, let’s say one and a half.

pmarreck 3y ago

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 of course why it's considered "arcane"). As a use-case where its capabilities came in handy just today, I had some old files I encrypted with gpg1 which didn't cleanly decrypt with gpg2. Accessing the old version of gpg, just for this one console and this one time for this one task, was a one-liner: "nix-shell -p gnupg1orig". With that one command it installed everything that version required, and put its executables at the front of my PATH in my shell, so I was able to do the decryption. When I exit, that stuff will get collected on the next garbage collection.

sanderjd 3y ago
I really like Nix, but I think "is still considered too arcane for most people to use" is a contradiction of "has already definitively solved this problem". Being usable for most people is an important part of solving this problem, which I unfortunately don't think Nix has accomplished. Maybe there is some way to improve its UX while keeping the fundamental model intact, in order to solve this problem.
- pmarreck 3y ago
  The core idea of Nix that has basically "solved this problem" is simply trying to control for all possible inputs to a build-time and run-time environment, and lock them all down with hashes, which is in essence basically treating a build like a pure function. (In theory, this should result in deterministic builds and deterministic runs. And in practice, nearly 100% of the time, it does.) The point of a "derivation" is to provide that for code that does not. Nix, and derivations in general, are thus sort of a "scaffolding" over all the existing build tool and dependency managers out there that bring them "over the line" regarding this. If these build tools and dependency managers all embraced the Nix way of specifying dependencies, and they all agreed to store it in a Nix store (i.e. a Merkle tree), then hypothetically, Nix would not even be necessary (except perhaps as a group of small tools to manage the store). 1) This is probably too much to ask of people. 2) This still leaves behind decades of software that would still need to be built in the future and would thus still need something like the "scaffolding". But again, the fundamental idea is really just this: Treat builds and runs as pure functions. Every other advantage derives directly from that principle. If someone else can figure out how to do this as simple as possible, I'm all for it! In the meantime, I think every developer should read Eelco's thesis paper on this idea: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf Of course, the OTHER way to solve this problem is just to statically-compile everything, leading to an explosion of disk-space usage. And even then, you wouldn't get guaranteed rebuilds.

gclawes 3y ago

I'm curious how all of this compares to macOS's .app packages.

harrego 3y ago
.app packages are merely the binary with assets and a bunch of metadata for code signing, entitlements, icons and locales. If you "Show Package Contents" there's not much to them.
mike_hearn 3y ago
Apple bundles compared to Flatpaks: • Both use reverse DNS to globally identify themselves, neither actually verifies DNS ownership. • Almost everything is a bundle, except for CLI apps. FlatPaks on the other hand are being auto-converted from previous packaging systems. • Bundles don't have dependencies. In theory they can, but in practice they never do. You depend on macOS/iOS as a unitary platform and bundles expose what the min version they require is. • There is no update mechanism except the app store. If you want that you need to use something like Sparkle. A tool like Hydraulic Conveyor [1] can create a bundle with integrated Sparkle for your cross platform application without needing a Mac. Likewise no attempt to deduplicate redundant files. Interestingly, if you use the latest MSIX tech on Windows then the OS will deduplicate shared files (including libs) that are bundled with apps, in a transparent manner. • Sandboxing is optional on macOS. If you don't opt in, you are put inside a relatively weak sandbox that just blocks access to a few folders in your home directory and stops you tampering with other apps/the OS. If you do opt in, you get a PowerBox design that's like what FlatPak is trying with portals. There's no way in the UI to see if an app is sandboxed because it's intended as a vulnerability mitigation and not a way to run untrusted code. • Both bundles and the binaries within those bundles advertise which version of macOS/iOS they're expecting, and the OS frameworks can change behaviors depending on that for backwards compatibility reasons. It's a bit easier to maintain compatibility with Objective-C APIs than with C++, but still, Apple does it for all their APIs including the C++ ones. [1] https://hydraulic.dev/ https://hydraulic.dev/ (disclosure: my company)

AdmiralAsshat 3y ago

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 not jiving with flatpak's security model. It took some non-trivial editing (thanks, flatseal) to finally let the Steam flatpak be able to write outside of its own directory and install the games. I still get occasional weirdness, especially on older games. I wasn't hearing any sound effects on Team Fortress 2, which I eventually discovered was tied to an selinux alert. At last check in, I still can't launch CS:Go, because of some backend problem while trying to play the opening movie...

PurpleRamen 3y ago
I had similar problems with Lutris, but never came around to fully solve them. Now I'm using the native debian-package, and never had any problem again. Flatpaks overall are working fine, I use them for portable apps on my mobile SSD. But the security can be a hassle on a hacking friendly-system which is doing too much outside the expected. So one should be aware that Flatpaks might be a tad different from native packages.
post-it 3y ago
It's insane that flatseal isn't a native part of flatpak. Problems like you encountered mean that the packaging system is incomplete by default.
hedora 3y ago
Fine fine-grained permissions systems like selinux end up introducing bizarre error conditions that are outside of upstream's test suite. Those error conditions are often exploitable. 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: https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2

Octabrain 3y ago

Flatpak is good overall but it has one things I dislike: - Not being oriented to also CLI apps. Apart from that, I like it for its convenience and I think it will be the future (or a similar approach). The reason for my thinking that is that, putting myself in the shoes of a distro maintainer, I can see the appeal and benefit of "isolating" the system packages and libraries from the packages installed by the user. I find it similar to the great relief that Docker brought back in the day when reduced the system administration overhead as it reduces the amount of moving parts on the functioning of an app.

dale_glass 3y ago

I think it's an unfortunate necessity for some kinds of applications. Eg, we make this: https://overte.org/ 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 it. We also expect our users to keep reasonably up to date, not whenever it's convenient to the distribution. Code changes can change the networking protocol, and some of those can require everyone to upgrade. So at least to me it makes perfect sense to package some kinds of applications this way. Maybe not KDE's calculator, but definitely things like games and tools with specialized markets, where it may be difficult to find people wanting to do the work of packaging them for a distribution.

avhception 3y ago
While the problems you cited certainly need to be solved by the Linux ecosystem, I don't see why that solution should involve the heavy-handed sandboxing with a thousand overlayfs, containers and whatnot. I wish there was a more straightforward solution that didn't have so many complicated moving parts, more like the static binaries that I get from Go or Rust.
- dale_glass 3y ago
  I want sandboxing. One reason is that big applications can have many dependencies, and once in a while I find something dlopens something from the host filesystem, finds something incompatible and crashes. So I really want my stuff to run in a sandbox where I know exactly what it's loading and there are no surprises. The other is that we've got a complex system under development and there may well be security exploits. I like the idea of that if somebody breaks our code it's going to take some work to get to the user still.
pmontra 3y ago
I install only debs because I don't want too much redundant code around and having to update all of it, if it ever updates. I prefer Debian to care about updating shared libraries. I make few exceptions, none for snaps and flatpacks so far. I installed Firefox from the tar.bz2 on their site, as I did with Windows before my switch to Linux in 2009. It auto updates and so far it's OK. I'm on Debian 11, I'll upgrade to 12 to stay more current. Other exceptions: docker containers for redis and the PostgreSQL versions I have to run for compatibility with the production servers of my customers. I use asdf for that sometimes and also for languages, of course. We can't rely on the versions coming with distros. If I'd really have to use Overte I would do an exception for that too.

Timber-6539 3y ago

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.

deleted 3y ago
[deleted]
prmoustache 3y ago
The point is the proponent raise the security flag like it is a huge advantage and you could trust anything coming from flathub while it is mostly pixie dusk. Untrustable apps aren't more trustable because they are delivered as flatpaks.
- Timber-6539 3y ago
  You missed my point. > The point is the proponent raise the security flag like it is a huge advantage and you could trust anything coming from flathub while it is mostly pixie dusk. Okay then, as you criticize Flatpaks give us your alternative to a trusted application. > Untrustable apps aren't more trustable because they are delivered as flatpaks. Nobody made this claim.
  - prmoustache 3y ago
    > Okay then, as you criticize Flatpaks give us your alternative to a trusted application. I am not criticizing, I am saying it is mostly a moot point. The sandboxing allow a bit of isolation but this it ranks quite poorly in term of actual security benefits for the typical end users use cases. > Nobody made this claim. Well, not the authors of flatpak, but yes some did. On medias that many people watch such as youtube videos.
    - Timber-6539 3y ago
      > The sandboxing allow a bit of isolation but this it ranks quite poorly in term of actual security benefits for the typical end users use cases. Ranked poorly in what checklist? > Well, not the authors of flatpak, but yes some did. On medias that many people watch such as youtube videos. Let's try to stay on topic. The point I made was that, the author's example about Flatpak GIMP doing something unauthorized on your system applies to any package format. The differentiating factor here is that Flatpak/Flatseal allows you to sandbox the application easily and quite effectively if I may add.

osmsucks 3y ago

I had to stop using elementary OS when they doubled down on Flatpak because I ran out of disk space. Those runtimes add up. :-/

invokestatic 3y ago

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 better on recent versions of Windows 10/11.

JonChesterfield 3y ago
That lets Microsoft break ABI on every release if they see fit. I thought the model was to install the runtimes globally, so you only have one copy of each version, but you install whatever version a given program wants. So you end up with lots, all somewhat different to each other. It has different tradeoffs to the glibc model.

zamalek 3y ago

On my old NVIDIA (never again) laptop, Flatpak left around 30GB of NVIDIA runtimes lying around. Each version approaches 1GB in size, and Flatpak will install updates for all versions of the driver you have ever installed. Downloading a few GBs just to update Firefox is just bloody annoying, even with cheap disk space and fast internet. Fixing it was easy enough, but it took figuring out what's going on, and requires regular maintenance (two things the target user for this project probably wouldn't know how to do). The drivers also never work properly. I've attempted to use several official game flatpaks, and have run into various forms of crashes (including the entire system stalling).

gumballindie 3y ago

Neither are snaps. The future, for regular daily use, are appimages. Much like MacOS dmgs, these are a "single" file (from an end user perspective) that you download, double click, and run. That's it. Ideally we'd see more work in this area. I am slowly trying to figure out how to automate builds for GUI apps and I am considering somehow settings up an inexpensive server to pull, package, and submit appimages to appimagehub. A crowdsourced effort would be cool. Imagine a distro where by default if you place apps in ~/Applications you can just execute them. Comes with risks, but having them "signed" by appimage a lot of it would be mitigated. Linux, while excellent as a desktop, and I am referring to the many awesome distros available, is really user friendly. Let's make it even more user friendly.

jeroenhd 3y ago
AppImages waste even more disk space. At least with Flatpak I only need to install libraries once, with AppImages I'm getting a second copy of everything with every application I download. If AppImages were actually directories, like they are in macOS, I could at least run duperemove to fix the disk space issue on BTRFS, but with full images that become a lot harder.
- gumballindie 3y ago
  Technically speaking appimages are compressed files so maybe someone clever can come up with an idea on how to dedupe them. With mass adoption this issue i think may be solved by someone concerned about disk space. Personally, and probably many casual users, are not as worried about space as they are about convenience. But I think your point is valid, and I think this would make an interesting side project for someone out there. For me, I'd like to see more adoption. The nice to haves will follow.
  - tomrod 3y ago
    Something like docker's layers?
    - 3y ago

samcat116 3y ago

> Personally, I’m much more interested in how to get Excel and Photoshop on Linux rather than untrustworthy drive-by apps and games, so I don’t really care about sandboxing, permissions, portals, app stores, alternate runtimes or really any of the stuff Flatpak does. Guess what Excel and Photoshop will want if they were to ever port their software to Linux.

jasonthorsness 3y ago

vscode flatpack just didn't work for me - found a workaround for terminal not working, but CoPilot extension refused to authenticate. No issues with non-flatpack version :(.

spenrose 3y ago

The #1 story on Hacker News at 2023:08:21T15:41Z is a 2021 discussion of Linux desktop packaging tools. 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.

spenrose 3y ago
Five net downvotes (and counting?) for this anodyne observation.

CapsAdmin 3y ago

The fundamental problem to me has always been that people cannot agree on standards, so this a relatively good solution to that problem. I can't think of a better one that doesn't involve people needing to come together to agree on a standard. 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.

danShumway 3y ago

This debate will never die, but while people have been complaining about it, Flatpak has quietly just become a better way to package software for end users. My criteria is that I'm a user, I don't care about what's elegant to developers -- and I have fewer problems with Flatpak than I have with non-Flatpak software. The vast majority of Flatpak problems I do have as a user come down to sandboxing permissions that I actually quite appreciate. The (very) few architectural problems are problems I would have had with other bundling systems too. "Developers are lazy" -> No, no user ever wants to debug dependency issues, and developers can't get rid of dependency issues. This feels like a repeat of the Rust debates where C developers kept complaining that good developers just don't have memory errors. Okay whatever you're very talented, congratulations; but most software isn't written by people who can reliably support multiple distros and lowering the skill requirements to maintain software is good actually because I use hobby projects all the time. Even outside of hobby communities, GoG's Linux installer is so borked that half of the time it's easier to install the Windows versions of the games and run them through Wine (because then you can use Bottles which provides dependency isolation). And I am completely convinced that dependency management is the problem -- Flatpak apps don't have these issues, at least not nearly as many. I'm not saying everything should be a Flatpak, but certainly at the very least most Linux games should be, anything that's graphical that isn't being distributed through an official package manager is a good candidate to at least consider Flatpak. I'm always grateful when I can install a graphical app through Flatpak instead of AUR. Is it the future? Flatpak critics spend a lot of time bashing Flatpak and very little time proposing equivalent fixes or acknowledging why Flatpak exists in the first place. If those issues were solved and the solutions popularized on mainline distros, maybe Flatpak wouldn't be the future. But I'm not holding my breath. This article proposes GoG's system as an alternative and says the existing problems are minor and easy to solve. 2 years later, I have literally never gotten a GoG native Linux installer to run without problems on the Steam deck. I'm not even saying it has to Flatpak, but whatever system you want to propose (Snap, AppImage, whatever) very clearly dependency isolation is better for end users and results in fewer bugs. "It takes up too much space" just isn't a real critique when the alternative being proposed almost universally fails to run on my hardware.

prmoustache 3y ago

INTPenis 3y ago

I was kinda forced into flatpaks with Fedora silverblue and 10 months later I don't really mind them. They are good enough for a laptop with no special requirements. I have Dino, Steam, Gnome Tweaks, Fractal, Signal, Gimp (crashes a lot), Firefox (because it comes with codecs, unlike the Fedora flatpak), Transmission, Chromium (mostly to run Teams and Outlook for work).

rvz 3y ago

Just goes to show the amount of third-party fragmentation that goes on in the Linux Desktop ecosystem which tons competing alternatives of alternative system components and now installers all in conflict and fighting against the users system. Snaps are only available in the default install in Ubuntu and Flatpaks is not in the default install of other Ubuntu-based distros [0]. Even other distros have neither in their default installs. It is not the same thing with macOS with its first party installation methods provided by Apple that just works. [0] https://www.omgubuntu.co.uk/2023/02/ubuntu-flavors-no-flatpak https://www.omgubuntu.co.uk/2023/02/ubuntu-flavors-no-flatpa...

wudangmonk 3y ago

I only use linux for daily use but deploying software on it is the worst out of any OS that I know of with windows being the best. Every update can potentially break things because who knows what changed in that library you depend on, and its not like you can avoid that by shipping static libraries to prevent this since for whatever reasons everyone has conspired against static libraries, I'm guessing because they take up more space?. Instead of having some minimal set of conventions of where things are supposed to be stored, instead of allowing static libraries to actually work it seems that the solution is to now include the whole system instead. After all storage is cheap right?.

teddyh 3y ago
Maybe Guix is for you?

travisgriggs 3y ago

Random tangent. When I see articles linked from this time frame, my brain automatically thinks "Ah, but that was during Covid when a disproportionate amount of people were working from home and a lot of the normal feedback loops weren't running normally. Those were lonely/different times. I'll consider this article accordingly." It's not really rationale/logical/founded, but that's where my brain kind of initially goes. Do others experience this?

bobajeff 3y ago

Flatpaks break a number of apps that I use. So no, it's not the future. Come up with something that works before making it the solution to distribution packaging.

TOGoS 3y ago

One major headache with trying to run precompiled binaries on Linux is that if they were compiled using a newer version of glibc than the target machine, they won't be able to run. Back while working on Factorio, I was trying to get around this problem with endless Docker containers, but coworker Wheybags came up with a much simpler solution to this, which is simply to, at compile time, link to the oldest compatible version of glibc by including a header: https://github.com/wheybags/glibc_version_header https://github.com/wheybags/glibc_version_header It's too bad this hasn't been standard practice for the past 30 years!

ape4 3y ago

Flatpak is the best of all the other alternatives.

OJFord 3y ago

Is there anything that offers mobile-style sandboxing & permissions API like described? I'd love that, but I'm not even sure how it would work, I don't want it via walled-garden app store where you basically have to target it as an extra platform, because of dealing with those APIs... It would need to somehow just sort of slot into Unix, and if you didn't have it 'enabled' on the system it would just plough on uncontrolled as it does today. What's the story or usual recommended practice on NixOS? Seems like the overlap with security-minder types would be quite high, and if you did use something like Flatpak wouldn't that interfere with Nix's own management? (Or at least not use it.) (I didn't learn much from the Flatpak Nix wiki page.)

phkahler 3y ago

A related part of the problem is apps that have a large number of dependencies. We should all be careful about which dependencies we use, keep that to a minimum, and try to use things with a stable API. The other part is library developers need to aim for backward compatibility so apps don't need to care so much about what specific version they're using.

ceronman 3y ago

Flatpak seems to follow a similar path as many other Linux technologies like Wayland or Systemd, in the sense that they seem to arouse the anger of a small but very vocal crowd who really can't stand any challenge to the status quo. So this is the template of the story: There is a new tool or workflow trying to replace or complement an old one. This new tool tries to solve many different complex problems that the old tool, usually designed decades ago, doesn't solve well in this the current world. To do so, obviously, some sort of compromise is required, the new tool won't do certain things that the old tool used to do, but in exchange of that it will do a lot of new things that many users really want. However this small crowd is really pissed by this, without understanding that there is no holly grail solution and some sort of compromise is always required. Additionally, as it's natural with any new technology, the very first incarnations of the new technology are not very mature and there is a lot to polish, a lot of tooling missing, and a chicken and egg problem of not enough users to drive its take off. And the small crowd will use all this as much as they can to try to prevent the world from moving on. However, as time passes, the new tool starts becoming more mature, the obvious shortcomings get fixed, and all the new possibilities that the tool enables start to really shine. And while the initial compromise will always remain, the majority of users realize that the tradeoff was worth it. This has happened with Systemd, it's starting to happen with Wayland, and I believe it will happen with Flatpak was well. We'll see.

c-hendricks 3y ago
Great argument calling out similar histories with then-new technologies, posted 4 minutes ago, already turning grey on HN. Please change, HN.
JohnFen 3y ago
> without understanding that there is no holly grail solution and some sort of compromise is always required. Why do you assume that such people don't understand this? Sometimes those compromises mean that the tool can no longer accomplish something important to some users. I don't think that being upset that software has become less useful is terribly unreasonable or hard to understand. > Additionally, as it's natural with any new technology, the very first incarnations of the new technology are not very mature and there is a lot to polish, a lot of tooling missing And while the software is in that state, it shouldn't be forced on anyone. It's not unreasonable for people to want to use software that actually works well in the present.

dcow 3y ago

Not dissenting generally, just want to point out that the author is wrong about the file permissions dialog thing: > This is the most complicated and brittle way to implement this. It’s also not at all how other sandboxed platforms work. If I want file access permissions on Android, I don’t just try to open a file with the Java File API and expect it to magically prompt the user. I have to call Android-specific APIs to request permissions first. iOS is the same. So why shouldn’t I be able to just call flatpak_request_permission(PERMISSION) and get a callback when the user approves or declines? On macOS you try to open a file and it’s handled transparently. “iOS is the same” also could use a citation (I don't recall off hand if it is, and kinda doubt it based on the macOS behavior, so I feel a citation is appropriate). I’m slightly confused why the author is comparing Linux desktop with mobile rather than existing desktop implementations of sandboxing… feels a tad disingenuous.

Dan42 3y ago
Fully agree. When the user selects a file via the file selection dialog, that automatically implies s/he has given permission to read that file. So the Flatpak libportal approach has really good UX. Having a second popup to grant access to the file would be horrible UX. Which is why apps ask for coarse-grained permissions like "access to all files" in order to bother the user as little as possible with multiple permission dialogs. Which then kinda defeats the point of sandboxing. I'm reminded of how Android apps need to know your "location" in order to scan for wifi networks. In general I think all permission dialogs should be reframed as selection or confirmation dialogs. • Open file dialog -> grants permission to read that file. • Open file for edit dialog -> grants permission to read/write that file. • Save as -> grants permission to read/write that file. • Select which wifi network to connect to -> grants permission to use internet • Do you want to display events in your neighborhood? -> grants permission to location data • Select which camera & mic to use for this call -> grants permission to record video & audio -- I have to say though, apart from that permissions thing, the author makes a lot of good points I hadn't realized before.

nologic01 3y ago

What is the linux app endgame in an ideal world? Imho that is true linux on mobile. With painless, secure, efficient downloads from app stores. (This way the FOSS impact will skyrocket and the promise will be fulfilled) Work backward from that requirement and constraint. Solutions and designs that barely work for the linux desktop will never bring a revolution...

butz 3y ago

While Flatpak is not the future, today it helps keep $HOME directory clean.

deleted 3y ago

[deleted]

denton-scratch 3y ago

I have one AppImage installed on one system (of four, at the moment). Zero flatpaks and snaps. That one AppImage appears to be available only as a Windows install or an AppImage. I dread any future where everything is an AppImage (or whatever). Why not just ship everything with a complete OS? Hell, let's go the whole hog; hardware is also a dependency, it's not just libraries. So let's ship every app as a hardware appliance. This is not why I use Linux.

teddyh 3y ago

If Flatpaks (and similar) are such a great idea, why don’t software in Flakpaks install their own dependencies as Flatpaks?

xp84 3y ago

Article: > How many people on Earth will truly understand how this all works? I feel this. And I think the software industry in general seems to have decided the answer is “No one does or will, and meh, we don’t care.” This is why every mysterious issue with every OS seems unsolvable. Every app is spewing random exceptions to the logs 100 times a second because in fact it does not just work together, most things barely work and nobody cares. We don’t get to have good software that works reliably anymore. Like my phone that turns its ring volume to 100% every few days. It’s not a rogue Shortcut, cuz Shortcuts doesn’t even have that feature (only Media volume). No one will ever know why that occurs, because no one understands the whole stack from top to bottom. And in a way that’s the best case scenario with such a walled garden controlled by one “benevolent” dictator. Using all these packaging frameworks and libraries at once, no one will ever be able to make sense of some kinds of problems, because everyone is cargo-culting some large section of this stack of complexity, because a single person couldn’t hope to make sense of everything.