TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Response to “Developers are lazy, thus Flatpak”

48 pointsby jcastroalmost 2 years ago

16 comments

seba_dos1almost 2 years ago
&gt; 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.<p>That&#x27;s <i>a lot</i>. Complete operating systems with similar amount of applications installed can take a fraction of that. That&#x27;s larger than &#x2F; partition on my PC used to be not that long ago (until I stopped splitting &#x2F;home out altogether).<p>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.
评论 #36192371 未加载
评论 #36191385 未加载
评论 #36191658 未加载
评论 #36191420 未加载
评论 #36191800 未加载
评论 #36191798 未加载
评论 #36191391 未加载
评论 #36191472 未加载
f33d5173almost 2 years ago
&gt;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<p>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.<p>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.
评论 #36191630 未加载
评论 #36191704 未加载
评论 #36191890 未加载
anon-3988almost 2 years ago
&gt; 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.<p>So why not just statically link at this point?
评论 #36194133 未加载
评论 #36191685 未加载
评论 #36191653 未加载
评论 #36191610 未加载
phkahleralmost 2 years ago
&gt;&gt; That’s completely fair, as you’re entitled to your own opinion. Likewise, I don’t trust the worryingly large amount of non-programmers&#x2F;developers that package dependencies in larger distributions, especially when they have no real world experience in developing apps.<p>Sadly I have to agree with this. How many &quot;package maintiners&quot; 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&#x27;t build an app and create the package in the first place.<p>Another problem is that library devs don&#x27;t always maintain compatibility. If you&#x27;re changing a minor version number you should not break any apps using you lib. Full stop, don&#x27;t tell me your sob story - you are someone&#x27;s infrastructure and need to act like it.<p>Fedora (my fave) should ship the latest gtk3 and gtk4 and no app should have to depend on a specific minor version - 3.12 <i>or later</i> is reasonable if the distro is tracking the latest for example.<p>There&#x27;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&#x27;m not sure what the solution is, but complex dependency management (npm) is not the answer.
评论 #36191747 未加载
评论 #36191868 未加载
评论 #36191769 未加载
评论 #36192561 未加载
curt15almost 2 years ago
&gt;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<p>One difference between the &quot;Flatpak distro&quot; and traditional distros is that the latter&#x27;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.<p>Since Flatpak runtimes are monoliths, every bug is a problem with the entire runtime. It&#x27;s not clear who is responsible for what part. Is there a centralized bugtracker for each runtime?<p>Also, compared to the &quot;Flatpak distro&quot; 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?
hamandcheesealmost 2 years 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.
评论 #36191430 未加载
评论 #36191479 未加载
评论 #36191860 未加载
评论 #36191488 未加载
jeroenhdalmost 2 years 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.<p>However, I only run Flatpak applications when there are no better ways to run software.<p>$ .&#x2F;flatpak-dedup-checker Directories: &#x2F;var&#x2F;lib&#x2F;flatpak&#x2F;{runtime,app} Size without deduplication: 13.82 GB Size with deduplication: 9.74 GB (70% of 13.82 GB)<p>$ flatpak list --app | wc -l 16<p>10GB for 16 applications is a lot. Electron applications seem to be the worst offenders here, I&#x27;m not seeing any runtime sharing between them and they&#x27;re all hundreds of megabytes in size.
candiddevmikealmost 2 years ago
If flatpak is acceptable, then distributing statically linked binaries should be acceptable, too.
ben0x539almost 2 years 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 &quot;we can&#x27;t ship it like that&quot;.
dangalmost 2 years ago
Recent and related:<p><i>Developers are lazy, thus Flatpak</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36185498" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36185498</a> - June 2023 (18 comments)
rcarmoalmost 2 years 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.
xtractoalmost 2 years ago
My main laptop uses Linux Mint. I&#x27;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&#x2F;function and the other LibreOffice for a similar reason.<p>I do software dev for a living. But as a desktop user, nowadays I couldn&#x27;t care less for the circus and crazy things my OS does in the background. I just want functionality and things to work. I&#x27;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.<p>Flatpak, AppImage or .deb, I dont really care as long as I can achieve what I need to do.<p>And yes, I&#x27;m a developer and am generally lazy. That&#x27;s why I love doing automation
bfrogalmost 2 years 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.<p>I still can never remember all the idiotic debhelper commands and the linter has strong ideas on how to do something.<p>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.<p>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.<p>Frankly I’d be surprised if flatpak or anything else is ever as easy as arch’s makepkg .
评论 #36191886 未加载
评论 #36191822 未加载
stjohnswartsalmost 2 years ago
I&#x27;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&#x27;s great to have options for users and authors, but users can&#x27;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.
taericalmost 2 years ago
Flatpak bit me with how support for canon raw files requires special tricks. I never really figured them out, either. :(
kelnosalmost 2 years ago
Frankly, I just don&#x27;t think Flatpak (and its ilk) is worth it for getting exact dependency versions. If you&#x27;re stuck using any dependencies that suck at following semver, and change API&#x2F;ABI&#x2F;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&#x27;ll probably want to use one of those glibc header tricks so you don&#x27;t require a brand-new glibc version).<p>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&#x27;t think I&#x27;d ever do that; I&#x27;d just wait for distros if they think it&#x27;s worthwhile, but I can understand why some developers could find it useful.<p>The thing is, after reading this article, as well as the article it&#x27;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&#x27;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&#x27;t have to worry about it.<p>I think Flatpak could provide two main (potential) benefits:<p>1. Sandboxing and isolation. I agree that even distro packagers mostly don&#x27;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.<p>2. Proprietary software distribution. Vendors won&#x27;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&#x27;t unintentionally depend on this month&#x27;s release of glibc. And then hopefully it doesn&#x27;t depend on libraries that are so old and obsolete that most distros don&#x27;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&#x27;s value there.<p>For my part, I keep Flatpak and Snap off my system; if an app is only available that way, I&#x27;ll find a different app.