12 ms·

Response to “Developers are lazy, thus Flatpak”

48 points by jcastro 3y ago

seba_dos1 3y ago
> Even with an unusual amount of runtimes and apps, Flatpak somehow manages to use 37.73 GB, even with most browsers installed as a flatpak. That's a lot. Complete operating systems with similar amount of applications installed can take a fraction of that. That's larger than / partition on my PC used to be not that long ago (until I stopped splitting /home out altogether). My phone has a 32 GB eMMC. I have just a handful of small Flatpak apps installed on it and Flatpak already takes more disk space than the whole fresh OS did there. The thing is that it mostly scales not with number of apps, but with number of runtimes installed - and you only need a single app to still be on an outdated runtime to make it keep excessive space.
- PrimeMcFly 3y ago
  That's unacceptable, it's Windows levels of bloat. Of course, Windows does something similar to maintain backwards compatibility with apps going all the way back to Windows 3.1, and does so pretty efficiently all things considered. Flatpack seems anything but efficient.
  - nulbyte 3y ago
    To be fair, the author of the article states that 173 graphical applications take up that much space, not just a handful of browsers. I think gp misses the point the author is trying to make, that over 100 apps takes up less space than expected.
    - seba_dos1 3y ago
      That's not a huge number of applications at all, unless we're talking about asset-heavy things like games. It would usually take about 10 GB or so complete with the whole operating system.
      - selcuka 3y ago
        > It would usually take about 10 GB or so complete with the whole operating system. So it takes around 3.7x the size it should? That's not unusual given that it isolates all dependencies.
        eviks 3y ago
        It's not unusual, but it's still bad
    - deleted 3y ago
      [deleted]
- charcircuit 3y ago
  >My phone has a 32 GB eMMC And each app has its own copy of any dependency it uses and apps are isolated from each other.
  - seba_dos1 3y ago
    No, most apps come from apt repository and therefore use shared dependencies. I wouldn't mention using Flatpak on my phone if I used Android there.
- 29athrowaway 3y ago
  I have plenty of stuff installed via Flatpak, size is not as nearly as much. flatpak list --columns=ref,size
- ramshanker 3y ago
  Games these days are easily 100GB alone. So 37GB is still well within current hardware capabilities.
- ben0x539 3y ago
  It's a lot, but I think we've lost that battle and society has collectively decided it's okay to sacrifice untold amounts of storage space in service of things like more stable installations, extra features, etc. It's aesthetically displeasing to install a 10 GB text editor or whatever but I don't think it's generally ideal in application development to optimize for very limited storage on phones either, especially with phone storage presumably just growing bigger over time too.
  - eviks 3y ago
    But this is not the general battlefield, but a Linux niche one, where the sub-society hasn't collectively made a decision yet
    - ben0x539 3y ago
      That's fair. I figure a lot of the same design pressures apply though, and of course there's a cost to diverging from what the rest of the world is doing.
- stjohnswarts 3y ago
  It really isn't a lot. Why would you bring up a phone when I don't know of any phones that use flatpaks (or snaps) except very edge case ubuntu experimental phone distros?
  - seba_dos1 3y ago
    Because I use it on my phone? These days it's often being used on phone distros that have nothing to do with Ubuntu (PureOS, Mobian, postmarketOS, Fedora, Arch...). I have like six or seven apps installed via Flatpak, and about a hundred via regular repos. I'm glad Flatpak exists as it enables some use cases that wouldn't be possible otherwise, but let's not pretend that its disk usage is not a PITA (the way it handles updates is super annoying too, you never know how much free space you actually need to have available for it to succeed).
- marcthe12 3y ago
  I have 64 apps installed which takes 11GB. And I have Steam with proton and app that uses texlive which combined are more than a GB in size and to my knowledge same on distros. Since OP is a dev for front end for wine which is shipped as flatpak, likely a lot big apps.
- kstenerud 3y ago
  My relatively fresh macbook pro is sitting at a little over 100GB with just a few apps installed (I'm not even using it fulltime yet because not everything is installed). That includes 25GB in the Library directory in my homedir. On my primary work macbook (which ONLY contains work apps and software dev, nothing else), I'm hitting against the 1TB SSD and have to delete caches to get space back from time to time. The Library directory is currently a whopping 220GB (just checked with du) and I have no idea why. Windows was a similar experience before I replaced it with a Debian + Steam install. 37GB for an extreme case of 173 large GUI apps built to 97 different runtimes on a system where I can get the latest and greatest version (or older version) of the app without being hobbled by dependency hell seems like a steal by comparison.
  - kaba0 3y ago
    For what it’s worth, Macs can reboot to previous versions and has many features linux desktops don’t out of the box. Though I would be interested in a deduplicated nix store of the same number of apps — which is still the best solution imo.
    - kstenerud 3y ago
      Not sure what you mean by "reboot to previous versions". My macbook can only boot Ventura after upgrading. If I wanted to boot Monterey, I'd have to wipe the drive and reinstall from scratch (or restore from backup). Also, every system has features that other systems don't have out of the box. The extreme 37gb example is already deduplicated and compressed (from over 100gb of data). Plus it doesn't require learning the user-unfriendly nix (which is absolutely necessary for debugging when things break).
  - frizlab 3y ago
    I don’t know how you work but in our company (~ 100 people) everybody has a Mac and literally no one has a 1TB drive and no one has issues with hard drive space either (including devs). Furthermore the Library folder contains application’s data, not applications…
    - 3y ago
dang 3y ago
Recent and related: Developers are lazy, thus Flatpak - https://news.ycombinator.com/item?id=36185498 https://news.ycombinator.com/item?id=36185498 - June 2023 (18 comments)
hamandcheese 3y ago
Meanwhile, you can have the best of both worlds using Nix. Tons of things are packaged already, and for the most part dependences are shared across many different packages. But if a package needs a special version of a dependency, thats no big deal.
- Gigachad 3y ago
  Does nix have any version of XDG portals for allowing programs to open file pickers without seeing the contents? This seems like the killer feature of flatpak.
  - mixedCase 3y ago
    XDG portals are just APIs that applications can implement and use. Regardless, do you not trust the applications that you run natively?
    - kaba0 3y ago
      A “good” pdf reader only needs a bug and a bad pdf file.
    - carbotaniuman 3y ago
      I mean I trust Firefox to not steal my data, or maybe $APP_NAME, but do I trust the C++ code? Or maybe it's an app that's been pwned a lot. Sandboxing has uses other than running actively hostile apps (for which I'd argue this kind of sandboxing isn't enough).
    - ben0x539 3y ago
      I generally trust the applications that I run natively to not be malicious, but I don't always trust them to not step on each other's toes, or make a well-intentioned mess of things.
    - mjg59 3y ago
      I don't assume that applications are inherently hostile, but I do not trust that the developer of every application I use to open untrusted input is sufficiently security conscious to prevent those applications from being subverted.
f33d5173 3y ago
>I imagine that most users have a small selection of apps installed, which only come with a few runtimes and a version apart, which also means that my setup is possibly one of the worst case scenarios This seems backwards. The more apps you install, the more likely it is that it will reuse a runtime or otherwise that you already have installed, and hence the less space it is likely to take up. The traditional approach forces all packages to make do with one version of a library, whereas the flatpak approach encourages them to ignore what other apps in the ecosystem use. The flatpak approach will definitely cause severe bloat in the amount of space used on the system.
- ben0x539 3y ago
  > The traditional approach forces all packages to make do with one version of a library, Yeah, and that means a bunch of them don't work properly. It's unrealistic to expect app developers to support that one version that each particular distro ships.
  - slondr 3y ago
    Nobody expects app developers to do that, because app developers aren’t distro maintainers. This is addressed in the post that TFA is responding to.
    - saidinesh5 3y ago
      At one point we have had to maintain support for 3 different versions of libpng in an application we were working on - just to make it work on 3 different popular distros. (Ubuntu via PPA, Arch via AUR, OpenSuse iirc). For the popular applications, it maybe that distro maintainers send you the pull request. But for small time applications, all you get are bug reports that the application is crashing on X distro, fix it. We ended up moving to AppImages to not deal with all these headaches anymore. Distros themselves run on very few volunteers. So it's usually a painful process to even get your application packaged into distros like Debian etc .. when dealing with public domain libraries that aren't available in their repositories but you aren't allowed to statically link to them.
candiddevmike 3y ago
If flatpak is acceptable, then distributing statically linked binaries should be acceptable, too.
ben0x539 3y ago
As ever, I wish I lived in the world the distro packagers are packaging software for, but in practice, I frequently do want to use the apps that make the distro packagers throw up their hands and go "we can't ship it like that".
anon-3988 3y ago
> Separating every dependency would be really inconvenient, just like managing graphical apps in a Linux distribution. If, for example, a flatpak named XYZ needs 10 dependencies, whereby one of the dependencies changes the version that the developers of the XYZ flatpak have not tested, then it could lead to bugs or even breakages that would make it really difficult for developers to trace back, as they would need to frequently contact each packager and figure out together. So, as mentioned by the author, the solution is to let the developers bundle everything, as they test their apps against an environment that is easier to understand. So why not just statically link at this point?
- ben0x539 3y ago
  There's still some reuse between flatpak apps, and not everything one might depend on necessarily is of the shape of a statically linkable library.
- saidinesh5 3y ago
  One main reason is licensing. Lots of good, basic libraries are lgpl. Like Qt etc... Also you'd want the basic libraries like glibc, ssl to be provided as shared libraries by the distros for various reasons - including security. That being said i do appreciate how newer languages like rust, go default to static linking.
  - kelnos 3y ago
    > One main reason is licensing. Lots of good, basic libraries are lgpl. While this might be a little more annoying, you can absolutely statically link a proprietary application with an LGPL library. You do need to provide object files for the proprietary bits so someone could relink it with a different/modified version of the LGPL library, though. Which, yes, is annoying to the point that if I were distributing a proprietary application, I probably would use dynamic linking with the LGPL bits.
- echelon 3y ago
  It'd be neat if we could build binaries capable of both static and dynamic linking. Everything would be baked in statically, but you'd have the ability to override static links with system dynamic links at application launch. I'd like to be able to patch SSL bugs without downloading a whole new binary for everything that depends on it. But at the same time, I probably couldn't care less about other dependencies, and I don't want to sort out version mismatches and deal with system libraries in most cases. Ideally the operating system itself could help manage this. Know what deps I care to handle myself or override.
phkahler 3y ago
>> That’s completely fair, as you’re entitled to your own opinion. Likewise, I don’t trust the worryingly large amount of non-programmers/developers that package dependencies in larger distributions, especially when they have no real world experience in developing apps. Sadly I have to agree with this. How many "package maintiners" are just wannabe developers that are just doing a bullshit job. Sure they can edit a .deb or .rpm when someone tells them what needs to be fixed, but they couldn't build an app and create the package in the first place. Another problem is that library devs don't always maintain compatibility. If you're changing a minor version number you should not break any apps using you lib. Full stop, don't tell me your sob story - you are someone's infrastructure and need to act like it. Fedora (my fave) should ship the latest gtk3 and gtk4 and no app should have to depend on a specific minor version - 3.12 or later is reasonable if the distro is tracking the latest for example. There's plenty of responsibility here for app developers, library developers, and packagers. If they would all do their job there would be no problem. The real issue is that nobody is perfect, nor has infinite time, so we keep trying to delegate. Modern software development and deployment is at the edge of human capability. I'm not sure what the solution is, but complex dependency management (npm) is not the answer.
- eschaton 3y ago
  Really, the lack of a stable base platform is what ultimately kills Linux as a commercial deployment platform. You can’t install a “Fedora 38 SDK” or an “Ubuntu 2023.04 SDK” and reliably build software that will be binary-compatible from that point forward—much less use a mechanism like Deployment Target on Apple’s platforms or whatever Android calls the same concept (API version?) to build binaries that can run across a range of distro releases and use features from newer distros when running on them but gracefully handle the case where they’re not available. Hence commercial software will target something like RHEL or an LTS release and many users will ultimately wind up running that software in a VM anyway as time goes on and binary compatibility isn’t maintained. Flatpak and snap are both just admissions of failure when it comes to this stuff. It’s been straightforward to build platforms this way for multiple decades now, just do it already.
- taeric 3y ago
  I take issue with calling them wannabe developers. Especially as the number one way to tank a project at a job is to make yet another way to distribute it. Many companies would do well to have a package maintainer position.
taeric 3y ago
Flatpak bit me with how support for canon raw files requires special tricks. I never really figured them out, either. :(
bfrog 3y ago
Packaging for rpm or deb based distributions is a hassle. Arch’s makepkg especially and to some degree nix in comparison are incredibly easy most of the time. I still can never remember all the idiotic debhelper commands and the linter has strong ideas on how to do something. I can’t by any means point at a url or git repo, specify a hash, and add some minimal steps and dependencies followed by a single command. That just doesn’t exist for rpm or deb, or if it does it’s very difficult to find good information on it. Nix goes even a step further and ensures the packaging works in a nice clean environment ensuring you didn’t mistakenly use something else installed but unlisted. Frankly I’d be surprised if flatpak or anything else is ever as easy as arch’s makepkg .
- jeena 3y ago
  That is the main reason why I only package my app for Arch and nothing else. I tried for ever to create deb packages until I just gave up and package for Arch + do a AppImage (which I also dislike a lot).
- seba_dos1 3y ago
  makepkg is simple, but at a cost of not being nearly comparable to rpms or debs which handle a lot of stuff makepkg simply does not. With a proper deb you can do partial updates and won't end up in a state where you can't run an application because it's trying to use older ABI-incompatible versions of libraries than the ones you have presently installed. On Arch, it's very common - you're always expected to update the whole system in sync, and if you install a thing without updating the whole system first things will often go wrong. debs are complex because they're solving complex issues which makepkg does not even try to solve, otherwise it wouldn't be as easy.
jeroenhd 3y ago
If your entire system uses Flatpak it can probably reuse a lot of stuff. Flatpak-as-a-distro is bound to work well, just like any normal distro does. However, I only run Flatpak applications when there are no better ways to run software. $ ./flatpak-dedup-checker Directories: /var/lib/flatpak/{runtime,app} Size without deduplication: 13.82 GB Size with deduplication: 9.74 GB (70% of 13.82 GB) $ flatpak list --app | wc -l 16 10GB for 16 applications is a lot. Electron applications seem to be the worst offenders here, I'm not seeing any runtime sharing between them and they're all hundreds of megabytes in size.
stjohnswarts 3y ago
I'll be the first to say I prefer distribution packages to flatpaks in most cases but I understand why an author would choose to pick that as the distribution method (or docker or snap). I think it's great to have options for users and authors, but users can't expect authors to bow down every time they have a request. Let your voice be heard but be respectful rather than being toddler angry like so many blogs these days seem to be.
kelnos 3y ago
Frankly, I just don't think Flatpak (and its ilk) is worth it for getting exact dependency versions. If you're stuck using any dependencies that suck at following semver, and change API/ABI/behavior in breaking ways, you should probably just vendor it with your app and link statically. This can be a part of your normal build process, so users building from source can get a working build, and you can also reasonably easily distribute binaries if you want to (though you'll probably want to use one of those glibc header tricks so you don't require a brand-new glibc version). I could see some app developers liking Flatpak as a way to self-publish a new app (in order to gain some users) before distro packagers pick it up. I don't think I'd ever do that; I'd just wait for distros if they think it's worthwhile, but I can understand why some developers could find it useful. The thing is, after reading this article, as well as the article it's responding to, I find that I largely agree with both of them. Software distribution and packaging on Linux is a huge mess, especially if you want to distribute binaries that make it easy for users to simply download your app from your website and run it. Flatpak does seem to do a decent job of solving that problem, though it creates other problems, and tries to do other things (like sandboxing) that it doesn't do particularly well. But at the same time, if you end up with a reasonably successful open source project (ignoring the chicken-and-egg problem there), you can rely on popular distros to package your app for you, and you just don't have to worry about it. I think Flatpak could provide two main (potential) benefits: 1. Sandboxing and isolation. I agree that even distro packagers mostly don't do any kind of security auditing. They get an app building, running, and maybe do a few basic things with it to ensure that it at least vaguely works. Of course, as the author points out, many Flatpak apps are intentionally allowed to break out of the sandbox, and this fact is very poorly communicated to users. 2. Proprietary software distribution. Vendors won't package for 20 different distros; on average you get an RPM, a DEB, and maybe a tarball with an install script that does who knows what to your system. And hopefully they built it on an old-enough distro so it doesn't unintentionally depend on this month's release of glibc. And then hopefully it doesn't depend on libraries that are so old and obsolete that most distros don't ship them anymore. Flatpak gives vendors one thing to target that will run anywhere, and while I avoid proprietary software as much as possible, there's value there. For my part, I keep Flatpak and Snap off my system; if an app is only available that way, I'll find a different app.
curt15 3y ago
>I’m not really sure who denies that Flatpak is a distribution, but I’m certainly not one of them. If anything, this seems to be a really good thing to me, because we’re bundling a distribution and deploying it to users’ systems One difference between the "Flatpak distro" and traditional distros is that the latter's modularity improves accountability. For instance, if I encounter a bug with a Fedora or Red Hat RPM, I can file an issue in Red Hat Bugzilla for that component, each package has an owner whose job includes handle those bug reports just for that package and forward them upstream if necessary. If I wish, I can even install the corresponding debuginfo packages and step through a debugger myself. Since Flatpak runtimes are monoliths, every bug is a problem with the entire runtime. It's not clear who is responsible for what part. Is there a centralized bugtracker for each runtime? Also, compared to the "Flatpak distro" traditional distros have more clearly articulated maintenance policies. I know for how long a Fedora RPM or Ubuntu deb will get updates, and I trust the Ubuntu and Fedora maintainers to keep on top of the latest security patches. What level of maintenance does a Flatpak runtime receive?
xtracto 3y ago
My main laptop uses Linux Mint. I've had to install flatpaks instead of the shipped .deb versions twice: once for imagemagick because the distros version is older and doesnt support some specific flag/function and the other LibreOffice for a similar reason. I do software dev for a living. But as a desktop user, nowadays I couldn't care less for the circus and crazy things my OS does in the background. I just want functionality and things to work. I've also got terabytes of disk, MBps of bandwidth and 32GB of ram, so I dont really care if a library is repeated 50 times in my OS. I just want shit to work. Flatpak, AppImage or .deb, I dont really care as long as I can achieve what I need to do. And yes, I'm a developer and am generally lazy. That's why I love doing automation
rcarmo 3y ago
Flatpak is OK until you realize that you’re installing multiple copies of pretty fat dependencies with each app. That is a huge problem (never mind that storage is cheap, it’s not _that_ cheap) when your apps take up twice as much as your OS, and the reason why I still prefer RPMs or .debs for most installs.

48 points by jcastro 3y ago

> Even with an unusual amount of runtimes and apps, Flatpak somehow manages to use 37.73 GB, even with most browsers installed as a flatpak. That's a lot. Complete operating systems with similar amount of applications installed can take a fraction of that. That's larger than / partition on my PC used to be not that long ago (until I stopped splitting /home out altogether). My phone has a 32 GB eMMC. I have just a handful of small Flatpak apps installed on it and Flatpak already takes more disk space than the whole fresh OS did there. The thing is that it mostly scales not with number of apps, but with number of runtimes installed - and you only need a single app to still be on an outdated runtime to make it keep excessive space.

PrimeMcFly 3y ago
That's unacceptable, it's Windows levels of bloat. Of course, Windows does something similar to maintain backwards compatibility with apps going all the way back to Windows 3.1, and does so pretty efficiently all things considered. Flatpack seems anything but efficient.
- nulbyte 3y ago
  To be fair, the author of the article states that 173 graphical applications take up that much space, not just a handful of browsers. I think gp misses the point the author is trying to make, that over 100 apps takes up less space than expected.
  - seba_dos1 3y ago
    That's not a huge number of applications at all, unless we're talking about asset-heavy things like games. It would usually take about 10 GB or so complete with the whole operating system.
    - selcuka 3y ago
      > It would usually take about 10 GB or so complete with the whole operating system. So it takes around 3.7x the size it should? That's not unusual given that it isolates all dependencies.
      - eviks 3y ago
        It's not unusual, but it's still bad
  - deleted 3y ago
    [deleted]
charcircuit 3y ago
>My phone has a 32 GB eMMC And each app has its own copy of any dependency it uses and apps are isolated from each other.
- seba_dos1 3y ago
  No, most apps come from apt repository and therefore use shared dependencies. I wouldn't mention using Flatpak on my phone if I used Android there.
29athrowaway 3y ago
I have plenty of stuff installed via Flatpak, size is not as nearly as much. flatpak list --columns=ref,size
ramshanker 3y ago
Games these days are easily 100GB alone. So 37GB is still well within current hardware capabilities.
ben0x539 3y ago
It's a lot, but I think we've lost that battle and society has collectively decided it's okay to sacrifice untold amounts of storage space in service of things like more stable installations, extra features, etc. It's aesthetically displeasing to install a 10 GB text editor or whatever but I don't think it's generally ideal in application development to optimize for very limited storage on phones either, especially with phone storage presumably just growing bigger over time too.
- eviks 3y ago
  But this is not the general battlefield, but a Linux niche one, where the sub-society hasn't collectively made a decision yet
  - ben0x539 3y ago
    That's fair. I figure a lot of the same design pressures apply though, and of course there's a cost to diverging from what the rest of the world is doing.
stjohnswarts 3y ago
It really isn't a lot. Why would you bring up a phone when I don't know of any phones that use flatpaks (or snaps) except very edge case ubuntu experimental phone distros?
- seba_dos1 3y ago
  Because I use it on my phone? These days it's often being used on phone distros that have nothing to do with Ubuntu (PureOS, Mobian, postmarketOS, Fedora, Arch...). I have like six or seven apps installed via Flatpak, and about a hundred via regular repos. I'm glad Flatpak exists as it enables some use cases that wouldn't be possible otherwise, but let's not pretend that its disk usage is not a PITA (the way it handles updates is super annoying too, you never know how much free space you actually need to have available for it to succeed).
marcthe12 3y ago
I have 64 apps installed which takes 11GB. And I have Steam with proton and app that uses texlive which combined are more than a GB in size and to my knowledge same on distros. Since OP is a dev for front end for wine which is shipped as flatpak, likely a lot big apps.
kstenerud 3y ago
My relatively fresh macbook pro is sitting at a little over 100GB with just a few apps installed (I'm not even using it fulltime yet because not everything is installed). That includes 25GB in the Library directory in my homedir. On my primary work macbook (which ONLY contains work apps and software dev, nothing else), I'm hitting against the 1TB SSD and have to delete caches to get space back from time to time. The Library directory is currently a whopping 220GB (just checked with du) and I have no idea why. Windows was a similar experience before I replaced it with a Debian + Steam install. 37GB for an extreme case of 173 large GUI apps built to 97 different runtimes on a system where I can get the latest and greatest version (or older version) of the app without being hobbled by dependency hell seems like a steal by comparison.
- kaba0 3y ago
  For what it’s worth, Macs can reboot to previous versions and has many features linux desktops don’t out of the box. Though I would be interested in a deduplicated nix store of the same number of apps — which is still the best solution imo.
  - kstenerud 3y ago
    Not sure what you mean by "reboot to previous versions". My macbook can only boot Ventura after upgrading. If I wanted to boot Monterey, I'd have to wipe the drive and reinstall from scratch (or restore from backup). Also, every system has features that other systems don't have out of the box. The extreme 37gb example is already deduplicated and compressed (from over 100gb of data). Plus it doesn't require learning the user-unfriendly nix (which is absolutely necessary for debugging when things break).
- frizlab 3y ago
  I don’t know how you work but in our company (~ 100 people) everybody has a Mac and literally no one has a 1TB drive and no one has issues with hard drive space either (including devs). Furthermore the Library folder contains application’s data, not applications…
  - 3y ago

dang 3y ago

Recent and related: Developers are lazy, thus Flatpak - https://news.ycombinator.com/item?id=36185498 https://news.ycombinator.com/item?id=36185498 - June 2023 (18 comments)

hamandcheese 3y ago

Meanwhile, you can have the best of both worlds using Nix. Tons of things are packaged already, and for the most part dependences are shared across many different packages. But if a package needs a special version of a dependency, thats no big deal.

Gigachad 3y ago
Does nix have any version of XDG portals for allowing programs to open file pickers without seeing the contents? This seems like the killer feature of flatpak.
- mixedCase 3y ago
  XDG portals are just APIs that applications can implement and use. Regardless, do you not trust the applications that you run natively?
  - kaba0 3y ago
    A “good” pdf reader only needs a bug and a bad pdf file.
  - carbotaniuman 3y ago
    I mean I trust Firefox to not steal my data, or maybe $APP_NAME, but do I trust the C++ code? Or maybe it's an app that's been pwned a lot. Sandboxing has uses other than running actively hostile apps (for which I'd argue this kind of sandboxing isn't enough).
  - ben0x539 3y ago
    I generally trust the applications that I run natively to not be malicious, but I don't always trust them to not step on each other's toes, or make a well-intentioned mess of things.
  - mjg59 3y ago
    I don't assume that applications are inherently hostile, but I do not trust that the developer of every application I use to open untrusted input is sufficiently security conscious to prevent those applications from being subverted.

f33d5173 3y ago

>I imagine that most users have a small selection of apps installed, which only come with a few runtimes and a version apart, which also means that my setup is possibly one of the worst case scenarios This seems backwards. The more apps you install, the more likely it is that it will reuse a runtime or otherwise that you already have installed, and hence the less space it is likely to take up. The traditional approach forces all packages to make do with one version of a library, whereas the flatpak approach encourages them to ignore what other apps in the ecosystem use. The flatpak approach will definitely cause severe bloat in the amount of space used on the system.

ben0x539 3y ago
> The traditional approach forces all packages to make do with one version of a library, Yeah, and that means a bunch of them don't work properly. It's unrealistic to expect app developers to support that one version that each particular distro ships.
- slondr 3y ago
  Nobody expects app developers to do that, because app developers aren’t distro maintainers. This is addressed in the post that TFA is responding to.
  - saidinesh5 3y ago
    At one point we have had to maintain support for 3 different versions of libpng in an application we were working on - just to make it work on 3 different popular distros. (Ubuntu via PPA, Arch via AUR, OpenSuse iirc). For the popular applications, it maybe that distro maintainers send you the pull request. But for small time applications, all you get are bug reports that the application is crashing on X distro, fix it. We ended up moving to AppImages to not deal with all these headaches anymore. Distros themselves run on very few volunteers. So it's usually a painful process to even get your application packaged into distros like Debian etc .. when dealing with public domain libraries that aren't available in their repositories but you aren't allowed to statically link to them.

candiddevmike 3y ago

If flatpak is acceptable, then distributing statically linked binaries should be acceptable, too.

ben0x539 3y ago

As ever, I wish I lived in the world the distro packagers are packaging software for, but in practice, I frequently do want to use the apps that make the distro packagers throw up their hands and go "we can't ship it like that".

anon-3988 3y ago

> Separating every dependency would be really inconvenient, just like managing graphical apps in a Linux distribution. If, for example, a flatpak named XYZ needs 10 dependencies, whereby one of the dependencies changes the version that the developers of the XYZ flatpak have not tested, then it could lead to bugs or even breakages that would make it really difficult for developers to trace back, as they would need to frequently contact each packager and figure out together. So, as mentioned by the author, the solution is to let the developers bundle everything, as they test their apps against an environment that is easier to understand. So why not just statically link at this point?

ben0x539 3y ago
There's still some reuse between flatpak apps, and not everything one might depend on necessarily is of the shape of a statically linkable library.
saidinesh5 3y ago
One main reason is licensing. Lots of good, basic libraries are lgpl. Like Qt etc... Also you'd want the basic libraries like glibc, ssl to be provided as shared libraries by the distros for various reasons - including security. That being said i do appreciate how newer languages like rust, go default to static linking.
- kelnos 3y ago
  > One main reason is licensing. Lots of good, basic libraries are lgpl. While this might be a little more annoying, you can absolutely statically link a proprietary application with an LGPL library. You do need to provide object files for the proprietary bits so someone could relink it with a different/modified version of the LGPL library, though. Which, yes, is annoying to the point that if I were distributing a proprietary application, I probably would use dynamic linking with the LGPL bits.
echelon 3y ago
It'd be neat if we could build binaries capable of both static and dynamic linking. Everything would be baked in statically, but you'd have the ability to override static links with system dynamic links at application launch. I'd like to be able to patch SSL bugs without downloading a whole new binary for everything that depends on it. But at the same time, I probably couldn't care less about other dependencies, and I don't want to sort out version mismatches and deal with system libraries in most cases. Ideally the operating system itself could help manage this. Know what deps I care to handle myself or override.

phkahler 3y ago

>> That’s completely fair, as you’re entitled to your own opinion. Likewise, I don’t trust the worryingly large amount of non-programmers/developers that package dependencies in larger distributions, especially when they have no real world experience in developing apps. Sadly I have to agree with this. How many "package maintiners" are just wannabe developers that are just doing a bullshit job. Sure they can edit a .deb or .rpm when someone tells them what needs to be fixed, but they couldn't build an app and create the package in the first place. Another problem is that library devs don't always maintain compatibility. If you're changing a minor version number you should not break any apps using you lib. Full stop, don't tell me your sob story - you are someone's infrastructure and need to act like it. Fedora (my fave) should ship the latest gtk3 and gtk4 and no app should have to depend on a specific minor version - 3.12 or later is reasonable if the distro is tracking the latest for example. There's plenty of responsibility here for app developers, library developers, and packagers. If they would all do their job there would be no problem. The real issue is that nobody is perfect, nor has infinite time, so we keep trying to delegate. Modern software development and deployment is at the edge of human capability. I'm not sure what the solution is, but complex dependency management (npm) is not the answer.

eschaton 3y ago
Really, the lack of a stable base platform is what ultimately kills Linux as a commercial deployment platform. You can’t install a “Fedora 38 SDK” or an “Ubuntu 2023.04 SDK” and reliably build software that will be binary-compatible from that point forward—much less use a mechanism like Deployment Target on Apple’s platforms or whatever Android calls the same concept (API version?) to build binaries that can run across a range of distro releases and use features from newer distros when running on them but gracefully handle the case where they’re not available. Hence commercial software will target something like RHEL or an LTS release and many users will ultimately wind up running that software in a VM anyway as time goes on and binary compatibility isn’t maintained. Flatpak and snap are both just admissions of failure when it comes to this stuff. It’s been straightforward to build platforms this way for multiple decades now, just do it already.
taeric 3y ago
I take issue with calling them wannabe developers. Especially as the number one way to tank a project at a job is to make yet another way to distribute it. Many companies would do well to have a package maintainer position.

taeric 3y ago

Flatpak bit me with how support for canon raw files requires special tricks. I never really figured them out, either. :(

bfrog 3y ago

Packaging for rpm or deb based distributions is a hassle. Arch’s makepkg especially and to some degree nix in comparison are incredibly easy most of the time. I still can never remember all the idiotic debhelper commands and the linter has strong ideas on how to do something. I can’t by any means point at a url or git repo, specify a hash, and add some minimal steps and dependencies followed by a single command. That just doesn’t exist for rpm or deb, or if it does it’s very difficult to find good information on it. Nix goes even a step further and ensures the packaging works in a nice clean environment ensuring you didn’t mistakenly use something else installed but unlisted. Frankly I’d be surprised if flatpak or anything else is ever as easy as arch’s makepkg .

jeena 3y ago
That is the main reason why I only package my app for Arch and nothing else. I tried for ever to create deb packages until I just gave up and package for Arch + do a AppImage (which I also dislike a lot).
seba_dos1 3y ago
makepkg is simple, but at a cost of not being nearly comparable to rpms or debs which handle a lot of stuff makepkg simply does not. With a proper deb you can do partial updates and won't end up in a state where you can't run an application because it's trying to use older ABI-incompatible versions of libraries than the ones you have presently installed. On Arch, it's very common - you're always expected to update the whole system in sync, and if you install a thing without updating the whole system first things will often go wrong. debs are complex because they're solving complex issues which makepkg does not even try to solve, otherwise it wouldn't be as easy.

jeroenhd 3y ago

If your entire system uses Flatpak it can probably reuse a lot of stuff. Flatpak-as-a-distro is bound to work well, just like any normal distro does. However, I only run Flatpak applications when there are no better ways to run software. $ ./flatpak-dedup-checker Directories: /var/lib/flatpak/{runtime,app} Size without deduplication: 13.82 GB Size with deduplication: 9.74 GB (70% of 13.82 GB) $ flatpak list --app | wc -l 16 10GB for 16 applications is a lot. Electron applications seem to be the worst offenders here, I'm not seeing any runtime sharing between them and they're all hundreds of megabytes in size.

stjohnswarts 3y ago

I'll be the first to say I prefer distribution packages to flatpaks in most cases but I understand why an author would choose to pick that as the distribution method (or docker or snap). I think it's great to have options for users and authors, but users can't expect authors to bow down every time they have a request. Let your voice be heard but be respectful rather than being toddler angry like so many blogs these days seem to be.

kelnos 3y ago

Frankly, I just don't think Flatpak (and its ilk) is worth it for getting exact dependency versions. If you're stuck using any dependencies that suck at following semver, and change API/ABI/behavior in breaking ways, you should probably just vendor it with your app and link statically. This can be a part of your normal build process, so users building from source can get a working build, and you can also reasonably easily distribute binaries if you want to (though you'll probably want to use one of those glibc header tricks so you don't require a brand-new glibc version). I could see some app developers liking Flatpak as a way to self-publish a new app (in order to gain some users) before distro packagers pick it up. I don't think I'd ever do that; I'd just wait for distros if they think it's worthwhile, but I can understand why some developers could find it useful. The thing is, after reading this article, as well as the article it's responding to, I find that I largely agree with both of them. Software distribution and packaging on Linux is a huge mess, especially if you want to distribute binaries that make it easy for users to simply download your app from your website and run it. Flatpak does seem to do a decent job of solving that problem, though it creates other problems, and tries to do other things (like sandboxing) that it doesn't do particularly well. But at the same time, if you end up with a reasonably successful open source project (ignoring the chicken-and-egg problem there), you can rely on popular distros to package your app for you, and you just don't have to worry about it. I think Flatpak could provide two main (potential) benefits: 1. Sandboxing and isolation. I agree that even distro packagers mostly don't do any kind of security auditing. They get an app building, running, and maybe do a few basic things with it to ensure that it at least vaguely works. Of course, as the author points out, many Flatpak apps are intentionally allowed to break out of the sandbox, and this fact is very poorly communicated to users. 2. Proprietary software distribution. Vendors won't package for 20 different distros; on average you get an RPM, a DEB, and maybe a tarball with an install script that does who knows what to your system. And hopefully they built it on an old-enough distro so it doesn't unintentionally depend on this month's release of glibc. And then hopefully it doesn't depend on libraries that are so old and obsolete that most distros don't ship them anymore. Flatpak gives vendors one thing to target that will run anywhere, and while I avoid proprietary software as much as possible, there's value there. For my part, I keep Flatpak and Snap off my system; if an app is only available that way, I'll find a different app.

curt15 3y ago

>I’m not really sure who denies that Flatpak is a distribution, but I’m certainly not one of them. If anything, this seems to be a really good thing to me, because we’re bundling a distribution and deploying it to users’ systems One difference between the "Flatpak distro" and traditional distros is that the latter's modularity improves accountability. For instance, if I encounter a bug with a Fedora or Red Hat RPM, I can file an issue in Red Hat Bugzilla for that component, each package has an owner whose job includes handle those bug reports just for that package and forward them upstream if necessary. If I wish, I can even install the corresponding debuginfo packages and step through a debugger myself. Since Flatpak runtimes are monoliths, every bug is a problem with the entire runtime. It's not clear who is responsible for what part. Is there a centralized bugtracker for each runtime? Also, compared to the "Flatpak distro" traditional distros have more clearly articulated maintenance policies. I know for how long a Fedora RPM or Ubuntu deb will get updates, and I trust the Ubuntu and Fedora maintainers to keep on top of the latest security patches. What level of maintenance does a Flatpak runtime receive?

xtracto 3y ago

My main laptop uses Linux Mint. I've had to install flatpaks instead of the shipped .deb versions twice: once for imagemagick because the distros version is older and doesnt support some specific flag/function and the other LibreOffice for a similar reason. I do software dev for a living. But as a desktop user, nowadays I couldn't care less for the circus and crazy things my OS does in the background. I just want functionality and things to work. I've also got terabytes of disk, MBps of bandwidth and 32GB of ram, so I dont really care if a library is repeated 50 times in my OS. I just want shit to work. Flatpak, AppImage or .deb, I dont really care as long as I can achieve what I need to do. And yes, I'm a developer and am generally lazy. That's why I love doing automation

rcarmo 3y ago

Flatpak is OK until you realize that you’re installing multiple copies of pretty fat dependencies with each app. That is a huge problem (never mind that storage is cheap, it’s not _that_ cheap) when your apps take up twice as much as your OS, and the reason why I still prefer RPMs or .debs for most installs.