11 ms·

Why Flatpak apps use so much disk space on Linux

78 points by dxs 1y ago

account-5 1y ago
I can't really comment about snap since I don't use Ubuntu but I thought flatpaks would work similar to how portable apps on windows do. Clearly I'm wrong, but how is it that windows can have portable apps of a similar size to their installable versions and Linux cannot? I know I'm missing something fundamental here, like how people blame Linux for lack of hardware support without acknowledging that hardware vendors do the work for windows to work correctly. Either way disk space is cheap and abundant now. If I need thenlastest version of something I will use flatpaks.
- progval 1y ago
  Installable versions of Windows apps still bundle most of the libraries like portable apps do, because Windows does not have a package manager to install them.
  - maccard 1y ago
    Windows does have a package manager and has for the last 5 years.
    - mjevans 1y ago
      Windows 2020 - Welcome to Linux 1999 where the distro has a package manager that has just about everything most users will ever need as options to install from the web.
      - maccard 1y ago
        I can say the same thing about Linux - it’s 2025 and multi monitor, Bluetooth and WiFi support still doesn’t work.
        mjevans 1y ago
        FUD (Fear Uncertainty Doubt). Every OS has it's quirks, things you might not recall as friction points because they're expected. I haven't found any notable issues with quality hardware, possibly with some need to verify support in the case of radio transmitter devices. You'd probably have the same issue for E.G. Mac OS X. As consumers we'd have an easier time if: 1) The main chipset and 'device type ID' had to be printed on the box. 2) Model numbers had to change in a visible way for material changes to the Bill of Materials (any components with other specifications, including different primary chipset control methods). 3) Manufacturers at least tried one flavor of Linux, without non-GPL modules (common firmware blobs are OK) and gave a pass / fail on that.
        maccard 1y ago
        I don’t think I am spreading FUD. Hardware issues with Linux on non well trodden paths is a well known issue. X11 (still widely used on many distros) has a myriad of problems with multi monitor setups - particularly when resolutions and refresh rates don’t match. You’re right that the manufacturers could provide better support, but they don’t.
        account-5 1y ago
        The only thing you can say in the context of the few bleeding edge hardware that isn't supported by Linux is that: 1. The hardware vendors are still not providing support the way they do for windows. 2. The Linux Devs haven't managed to adapt to these new hardwares.
        yjftsjthsd-h 1y ago
        Er, yes they do? I guess things could be spotty if you don't have drivers (which... is true of any OS), but IME that's rare. But I have to ask because I keep hearing variations of this: What exactly is wrong with */Linux handling of multi-monitor? The worst I think I've ever had with it is having to go to the relevant settings screen and tell it how my monitors are laid out and hitting apply.
        maccard 1y ago
    - kbolino 1y ago
      Apart from the Microsoft Visual C++ Runtime, there's not much in the way of third-party dependencies that you as a developer would want to pull in from there. Winget is great for installing lots of self-contained software that you as an end user want to keep up to date. But it doesn't really provide a curated ecosystem of compatible dependencies in the way that the usual Linux distribution does.
      - maccard 1y ago
        Ok but that’s a different argument to “windows doesn’t have a package manager”
        kbolino 1y ago
        No, this is directly relevant to the comparison, especially since the original context of this discussion is about how Windows portable apps are no bigger than their locally installed counterparts. A typical Linux package manager provides applications and libraries. It is very common for a single package install with yum/dnf, apt, pacman, etc. to pull in dozens of dependencies, many of which are shared with other applications. Whereas, a single package install on Windows through winget almost never pulls in any other packages. This is because Windows applications are almost always distributed in self-contained format; the aforementioned MSVCRT is a notable exception, though it's typically bundled as part of the installer. So yes, Windows has a package manager, and it's great for what it does, but it's very different from a Linux package manager in practice. The distinction doesn't really matter to end users, but it does to developers, and it has a direct effect on package sizes. I don't think this situation is going to change much even as winget matures. Linux distributions carefully manage their packages, while Microsoft doesn't (and probably shouldn't).
        maccard 1y ago
        I never said that WinGet was a drop in replacement for yum - but the parents claim that windows doesn’t have a package manager isn’t true. There are plenty of padkages that require you to add extra sources to your package manager, that are not maintained by the distro. Docker [0] has official instructions to install via their package source. WinGet allows third party sources, so there’s no reason you can’t use it. It natively supports dependencies too. The fact that applications are packaged in a way that doesn’t utilise this for WinGet is true - but again, I was responding to the claim that windows doesn’t have a package manager. [0] https://docs.docker.com/engine/install/fedora/#install-using-the-repository https://docs.docker.com/engine/install/fedora/#install-using...
    - wmf 1y ago
      Unfortunately a lot of Windows devs are targeting 10 year old versions.
    - keyringlight 1y ago
      Assuming you're talking about winget, that seems to operate either as an alternative CLI interface to the MS store with a separate database developers would need to add their manifests to, or to download and run normal installers in silent mode. For example if you do winget show "adobe acrobat reader (64-bit) you can see what it will grab. It's a far cry from how most linux package managers operate
- blahaj 1y ago
  Just a guess, but Windows executables probably depend on a bunch of Windows APIs that are guaranteed to be there, while Linux systems are much more modular and do not have a common, let alone stable ABI interface in the userspace. You can probably get small graphically capable binaries if you depend on QT and just assume it to be present, but Flatpak precisely does not do that and bundles all the dependencies to be independent from shared dependencies of the OS outside of its control. The article also mentions that AppImages can be smaller probably because they assume some common dependencies to be present. And of course there are also tons of huge Windows software that come with all sorts of their own dependencies. Edit: I think I somewhat misread your comment and progval is more spot on. On Linux you usually install software with a package manager that resolves dependencies and only installs the unsatisfied dependencies resulting in small install size for many cases while on Windows that is not really a thing and installers just package all the dependencies they cannot expect to be present and the portable version just does the same.
- dismalaf 1y ago
  "Portable" apps on Windows just don't write into the registry or save state in a system directory. They can still assume every Windows DLL since the beginning of time will be there. Versus Linux where you have Gnome vs. KDE vs. Other and there's less emphasis on backwards compatibility and more on minimalism, so they need to package a lot more dependencies (potentially). If you only install Gnome Flatpaks they end up smaller since they can share a bunch of components.
- badsectoracula 1y ago
  The equivalent of "Windows portable apps" on Linux isn't flatpaks (these add a bunch of extra stuff and need some sort of support from the OS) but AppImages[0]. AppImages are still not 100% the same (and can never be as Windows applications can rely on A LOT more stuff to be there than Linux desktop apps) but functionally/UX-wise they're the closest: you download some program, chmod +x it and run it like any other binary you'd have on your PC. Personally i vastly prefer AppImages to flatpaks (in fact i do not use flatpaks at all, i'd rather build the program from source - or not use it if the build process is too convoluted - instead). [0] https://appimage.org/ https://appimage.org/
  - codedokode 1y ago
    Looking at their architecture they seem to be a pain to run safely (sandboxed). For example, you cannot take away access to mount syscall due to them mounting themselves using FUSE. Also are they easy to debug? Do they ship with debugging symbols? Googling around shows that it might be tricky.
- kmeisthax 1y ago
  It's a matter of standardization and ABI stability. Linux itself promises an eternally stable syscall ABI, but everything else around it changes constantly. Windows is basically the opposite: no public syscall ABI, but you can always get a window on screen by linking USER.dll and poking it with the correct structures. As a result, Windows apps can assume more, while desktop Linux apps have to ship more.
  - codedokode 1y ago
    Linux is moving to Windows model, by shipping userspace libraries. For example, ALSA has a library, DRM has a library.
- account-5 1y ago
  I'm replying to myself in reply to everyone who replied to me. Thanks all for the explanations, much appreciated, I thought I was missing something. I really should have known though, Ive been using portable apps for over 20 years on windows and remember.net apps not being considered portable way back when, which are now considered portable since the run time is on all modern windows.
- johnny22 1y ago
  > Clearly I'm wrong, but how is it that windows can have portable apps of a similar size to their installable versions and Linux cann They can't depend on many apis existing or at the right version. Linux distros are made from a collection of various third party projects and distros just integrate those. Each of these third party projects has it's own development speed and ABI and API stability policies. Each distro also has it's own development speed and release policy, which means they might have things that could either be too new or to old. Most distros try to avoid packaging multiple versions of the same project when they can avoid it to ease maintenance as well. Heck, you can't even guarantee that you have the exact same libc. Most distros use glibc, but there are plenty of systems that use musl.
- int_19h 1y ago
  If you're targeting Windows, you can assume the following things to be present: - the entirety of Win32 API - all the Windows Runtime APIs - .NET Framework 4.7+ This is a lot of functionality. For example, the list above includes four different widget toolkits alone (Win32, WinForms, WPF, WinRT XAML), several libraries to handle networking (including HTTP), USB, 2D and 3D graphics including text rendering, HTML renderer etc. And all of this has a highly stable ABI, so long as you do everything by the book. COM/WinRT and .NET provide a stable ABI for high-level object-oriented APIs above and beyond what the basic C ABI can offer.
  - surajrmal 1y ago
    The real problem in Linux is the lack of a stable abi for anything other than the kernels UAPI. Perhaps one day we will standardize enough of the lower layers of Linux and provide real stability. There is definitely a line between packaging all of your dependencies and packaging none of them. We probably want something in the middle, or else perhaps more functionality which is currently provided via shared libraries should be moved behind stable IPC instead.
jasonpeacock 1y ago
The article mentions that Flatpack is not suitable for servers because it uses desktop features. Does anyone know what those features are or have more details? Linux generally draws a thin line between server and desktop, having “desktop only” dependencies is unusual less it’s something like needing the KDE or Gnome GUI libraries?
- LtWorf 1y ago
  AFAIK it cannot do CLI applications at all.
  - jeroenhd 1y ago
    It can, but because the Flatpak system depends on APIs like D-Bus getting those to work in headless environments (SSH, framebuffer console, raw TTY) is a pain. Flatpak will even helpfully link binaries you install to a directory you can add to your $PATH to make command line invocation easy.
- mananaysiempre 1y ago
  This may refer to xdg-desktop-portal[1], which is usable without Flatpak, but Flatpak forces you to go through it to access anything outside the app’s private sandbox. In particular, access to user files is mediated through a powerbox (trusted file dialog) [2] provided by the desktop environment. In a sense, Flatpak apps are normal Linux apps to about the same extent that WinRT/UWP apps are normal Windows apps—close, but more limited, and you’re going to need significant porting in either direction. (This has also made an otherwise nice music player[3] unusable to me other than by dragging and dropping individual files from the file manager, as all of my music lives in git-annex, and accesses through git-annex symlinks are indistinguishable from sandbox escape attempts. On one hand, understandable; on the other, again, the software is effectively useless because of this.) [1] https://wiki.archlinux.org/title/XDG_Desktop_Portal https://wiki.archlinux.org/title/XDG_Desktop_Portal [2] https://wiki.c2.com/?PowerBox https://wiki.c2.com/?PowerBox [3] https://apps.gnome.org/Amberol https://apps.gnome.org/Amberol
  - 1y ago
pdimitar 1y ago
[flagged]
- renewiltord 1y ago
  But I don’t want to solve actual problems. I want to write the 3689th lisp interpreter in the world.
  - pdimitar 1y ago
    Your right and prerogative, obviously. But out there, a stranger you care nothing about, will think less of you. Wish I had that free time and freedom though... The things I would do.
    - renewiltord 1y ago
      You can have that free time. Stop posting on HN and write some code. I can do both but if I couldn’t I’d pick the latter.
      - pdimitar 1y ago
        [flagged]
- bigyabai 1y ago
  Pay me
  - pdimitar 1y ago
    [flagged]
    - bigyabai 1y ago
      [flagged]
- deleted 1y ago
  [deleted]
loloquwowndueo 1y ago
“Storage is cheap” goes the saying. Other people’s storage has a cost of zero, so why not just fill it up with 100 copies of the same dependency. These package formats (I’m looking at you snap as well) are disrespectful of users’ computers to the point of creating a problem where due to size, things take so long and bog the computer down so much, that the resource being used is no longer storage, but time (system and human time). And THAT is not cheap at all. Don’t believe me, install a few dozen snaps, turn the computer off for a week, and watch in amazement as you turn it back on and see it brought to its knees as your computer and network are taxed to the max downloading and applying updates.
- m4rtink 1y ago
  Snaps do zero deduplication and bundle everything AFAIK - flatpak at least does some deduplication on file level and has shared runtimes.
  - brlin2021 1y ago
    This statement is false as snaps also have shared runtimes known as "content snaps". A common example is the ones with the gnome- prefix and the ones that end with -themes suffix.
    - loloquwowndueo 1y ago
      Wherein snaps found themselves reinventing shared libraries - at which point, what’s really the point.
      - Seattle3503 1y ago
        I think the point is that maintainers and developers now have a choice of whether they want to share libraries or not. Before the only choice was to share dependencies.
        hedora 1y ago
gjsman-1000 1y ago
It feels, to me, like the Linux desktop has become an overly complicated behemoth, never getting anywhere due to its weight. I still feel the pinnacle for modern OS design might be Horizon, by Nintendo of all people. A capability-based microkernel OS that updates in seconds, fits into under 400 MB (WebKit and NVIDIA drivers included), is fast enough for games, and hasn’t had an unsigned code exploit in half a decade. (The OS is extremely secure, but NVIDIA’s boot code wasn’t.) Why can’t we build something like that?
- anthk 1y ago
  Alpine Linux?
  - gjsman-1000 1y ago
    Close; but the security still isn’t anywhere close. On Alpine, if there’s a zero day in WebKit, you’d better check how your security is set up, and hope there’s not an escalation chain. On Horizon, dozens of bugs in WebKit, the Broadcom Bluetooth stack, and the games have been found; they are still found regularly. They are also boring and completely useless, because the sandboxing is so tight. You also can’t update Alpine in 5 seconds flat, even between a dozen major versions. That alone is amazing.
    - yjftsjthsd-h 1y ago
      > Close; but the security still isn’t anywhere close. [...] I think a lot of the security comes down to what compromises you're willing to make. Horizon doesn't have to support the same breadth of hardware or software as we expect out of normal OSs, so they can afford to reinvent the world on a secure microkernel. If we want to maintain backwards-compatibility (and we do, because otherwise it's dead on arrival) then we have to take smaller steps. Of course, we can take those steps; if you care about security then you should run your browser in a sandbox (firejail, bubblewrap, docker/podman) at which point a zero-day in the browser is lower impact (not zero risk, true, but again I don't see any way to fix that without throwing out performance or compatibility). > You also can’t update Alpine in 5 seconds flat, even between a dozen major versions. That alone is amazing. I rather assumed that the Switch doesn't actually install OS updates in 5s either? The obvious way to do what they're doing is A/B updates in the background, after which you "apply" by rebooting, which Linux can do in 5s.
ReptileMan 1y ago
Why does it seems that we try to both avoid and reinvent the static linker poorly with every new technology and generation. Windows has been fighting with dll hell for 30 years now. Linux seems to not be able to produce alternative to dll hell. Not sure how osx world is.
butz 1y ago
If you are space concious, you should try to select Flatpak apps that are using the same runtime (Freedesktop, GNOME or KDE), and make sure all of them are using exactly the same version of runtime. Correct me if I'm wrong, but only two versions of Flatpak runtimes are supported at a time - current and previous. So during times when transitioning happens to newer runtime, some application upgrades are not done at once, and user ends up using more than one (and sometimes more than two) runtimes. In addition to higher disk space usage, one must account for usual updates too. The more programs and runtimes you have, more updates to download. Good thing, at least updates are partial.
qbane 1y ago
I hope articles like this can at least provide some hints when the size of a flatpak store grows without bound. It is definitely more involved than "it bundles everything like a node_modules directory hence..." [Bug]: /var/lib/flatpak/repo/objects/ taking up 295GB of space: https://github.com/flatpak/flatpak/issues/5904 https://github.com/flatpak/flatpak/issues/5904 Why flatpak apps are so huge in size: https://forums.linuxmint.com/viewtopic.php?t=275123 https://forums.linuxmint.com/viewtopic.php?t=275123 Flatpak using much more storage space than installed packages: https://discussion.fedoraproject.org/t/flatpak-using-much-more-storage-space-than-installed-packages/67970 https://discussion.fedoraproject.org/t/flatpak-using-much-mo...
- catlikesshrimp 1y ago
  Your comment probably took more effort for this article than the prompter of the AI that produced said article. Conclusion: Thank you for the links
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
haunter 1y ago
What made Flatpaks more popular than Appimage? I thought the latter is "vastly" superior and really portable?
- kalaksi 1y ago
  I don't claim to know the answer but flatpaks have easier distribution (flathub), package management, sandboxing, can share runtimes and are also portable in the sense that they work across linux distros. AppImage is a simple and even more portable format but not much else so I guess it's superior if you only want to maximize portability.
- Vilian 1y ago
  It's depends, flatpak is a lot more portable, it bundle everything, the libraries are shared, thing that appimage can't, it automatically updates, it's more secure, and have a stronger sandbox, and it integrate better with the system
  - akimbostrawman 1y ago
    >it's more secure, and have a stronger sandbox AppImages don't have a sandbox at all, they have full access to everything the user has.
wltr 1y ago
That was so useless and the style was so bad, I’m pretty sure it was written with (if not by) LLMs. Not even sure if I’m disappointed finding this low effort content here, or rather not surprised at all. I wish the content here would be more interesting, but maybe I’d want to find some other community for that. I mean, the comments are much more interesting than this piece of content, but the content itself is almost offending. At least the discussion is much more valuable than what I’ve just read by following that link.
INTPenis 1y ago
I use flatpaks daily but not many apps. Because I've been on Atomic Linux for a couple years now flatpak has become part of my daily life. On this work laptop I have three flatpaks, Signal, Chromium and Firefox. They all take 1.6GiB in total. On my gaming PC I have Signal, Flatseal, Firefox, PrismLauncher, Fedora MediaWriter and Steam, and obviously they take over 700G because of the games in Steam, but if I count just the other flatpaks they're 2.2GiB. So yeah, not great, but on the other hand I don't care because I love the packaging of cgroups based software and I don't need many of them. I mean my container images take up a lot more space than my flatpaks.
massysett 1y ago
“ The name "Flatpak" is even a nod to IKEA's flatpacking,” Which is hilarious: an IKEA flat pack takes up less space than the finished product. Linux flatpack is the exact opposite.
tomhowls 1y ago
[flagged]
_Soulou 1y ago
Something I have been wondering with Flatpak is about Ram usage. As sharing dynamic libraries allow loading it into RAM only once, while if I use Signal, Chromium and different others Flatpaks, all libs will be loaded multiple times (often with their own version). So maybe disk is cheap but RAM may be more limited, which looks kind of a limit in the generalization of this method of distribution. (You could tell me it's the same with containers) Am I right to think that? Has someone measured that difference on their workstation?
- codedokode 1y ago
  Web browser (Signal and Chromium) wastes so much memory that shared libraries size is not important. Also, shared libraries can always be dropped from memory.
- Vilian 1y ago
  The same libraries are shared between flatpak apps, and everything deduplicated, so I don't thinknso, but someone would have to test
mcv 1y ago
I don't know much about package managers, but instead of demanding every app uses the same version of every library, or including all libraries in every app, wouldn't it make more sense to allow different versions of libraries to exist next to each other, and every app simply picks the more up to date version that it supports? I think that's how npm does it. Not that npm doesn't have its own dependency hell, but that's because different dependencies within the same application can end up requiring different versions of the same sub-dependency. But that's a problem only for developers.
- Vilian 1y ago
  ...that's literally what flatpak does?, and it deduplicate everything too
  - mcv 1y ago
    Is it? But if its only duplication is different versions of the same dependency, and it never has real duplication, then what exactly is the problem? As I said, I don't know much about these things. I thought flatpak had the app and all its dependencies together in a single package.
Havoc 1y ago
They took the “works on my computer - then we’ll just ship my computer” meme literally
compsciphd 1y ago
I'll repeat myself, but this is because Docker (and all its descendents) didn't understand my work (or at least took the easy way out). https://www.usenix.org/conference/usenix-atc-10/apiary-easy-use-desktop-application-fault-containment-commodity-operating https://www.usenix.org/conference/usenix-atc-10/apiary-easy-... I argued (and built years prior to docker), a container oriented file system infrastructure that combined the best of linux style package management and union file systems. Where instead of "packages", you had "layers" (analogous to packages) and an "image" that was just a set of layers. I imagined, instead of a linux distribution having an archive of installable packages, it would provide a mirror of usable layers (and PoCd this by converting a large enough set of Debian packages into layers to cover the applications needed for my PoC). In such a world, you don't waste (directly at least) any additional space, as you are sharing the packages directly (and therefore the underlying files, which can also have memory benefits in terms of easier sharing of ro code pages, due to being the same page on disk). You do still have a concept of version sprawl, as different images can be using different versions of the same package, but its not very visible. Each image enumerates directly what "shared" components its using. One could argue that just like upgrading a regular deb/rpm environment is relatively straight forward, "upgrading" (or in reality, creating a new image version from an existing version) in such a world is also easy. Just upgrade the shared layer versions in the image manifest/definition. I was trying to create a world where you could upgrade the container easily (ex: move the running container's private RW layer to a new container on upgrade, or in a sense resolve the container's layers from version A to version B by swapping around the layers that have changed), but one might argue that today that isn't viewed as valuable, and I might agree. I was trying to demonstrate a system that supported what I called persistent and ephemeral containers, with persistent containers being what became called pets and ephemeral containers being what became called cattle and the world today wants everything to be cattle.

78 points by dxs 1y ago

I can't really comment about snap since I don't use Ubuntu but I thought flatpaks would work similar to how portable apps on windows do. Clearly I'm wrong, but how is it that windows can have portable apps of a similar size to their installable versions and Linux cannot? I know I'm missing something fundamental here, like how people blame Linux for lack of hardware support without acknowledging that hardware vendors do the work for windows to work correctly. Either way disk space is cheap and abundant now. If I need thenlastest version of something I will use flatpaks.

progval 1y ago
Installable versions of Windows apps still bundle most of the libraries like portable apps do, because Windows does not have a package manager to install them.
- maccard 1y ago
  Windows does have a package manager and has for the last 5 years.
  - mjevans 1y ago
    Windows 2020 - Welcome to Linux 1999 where the distro has a package manager that has just about everything most users will ever need as options to install from the web.
    - maccard 1y ago
      I can say the same thing about Linux - it’s 2025 and multi monitor, Bluetooth and WiFi support still doesn’t work.
      - mjevans 1y ago
        FUD (Fear Uncertainty Doubt). Every OS has it's quirks, things you might not recall as friction points because they're expected. I haven't found any notable issues with quality hardware, possibly with some need to verify support in the case of radio transmitter devices. You'd probably have the same issue for E.G. Mac OS X. As consumers we'd have an easier time if: 1) The main chipset and 'device type ID' had to be printed on the box. 2) Model numbers had to change in a visible way for material changes to the Bill of Materials (any components with other specifications, including different primary chipset control methods). 3) Manufacturers at least tried one flavor of Linux, without non-GPL modules (common firmware blobs are OK) and gave a pass / fail on that.
        maccard 1y ago
        I don’t think I am spreading FUD. Hardware issues with Linux on non well trodden paths is a well known issue. X11 (still widely used on many distros) has a myriad of problems with multi monitor setups - particularly when resolutions and refresh rates don’t match. You’re right that the manufacturers could provide better support, but they don’t.
      - account-5 1y ago
        The only thing you can say in the context of the few bleeding edge hardware that isn't supported by Linux is that: 1. The hardware vendors are still not providing support the way they do for windows. 2. The Linux Devs haven't managed to adapt to these new hardwares.
      - yjftsjthsd-h 1y ago
        Er, yes they do? I guess things could be spotty if you don't have drivers (which... is true of any OS), but IME that's rare. But I have to ask because I keep hearing variations of this: What exactly is wrong with */Linux handling of multi-monitor? The worst I think I've ever had with it is having to go to the relevant settings screen and tell it how my monitors are laid out and hitting apply.
        maccard 1y ago
  - kbolino 1y ago
    Apart from the Microsoft Visual C++ Runtime, there's not much in the way of third-party dependencies that you as a developer would want to pull in from there. Winget is great for installing lots of self-contained software that you as an end user want to keep up to date. But it doesn't really provide a curated ecosystem of compatible dependencies in the way that the usual Linux distribution does.
    - maccard 1y ago
      Ok but that’s a different argument to “windows doesn’t have a package manager”
      - kbolino 1y ago
        No, this is directly relevant to the comparison, especially since the original context of this discussion is about how Windows portable apps are no bigger than their locally installed counterparts. A typical Linux package manager provides applications and libraries. It is very common for a single package install with yum/dnf, apt, pacman, etc. to pull in dozens of dependencies, many of which are shared with other applications. Whereas, a single package install on Windows through winget almost never pulls in any other packages. This is because Windows applications are almost always distributed in self-contained format; the aforementioned MSVCRT is a notable exception, though it's typically bundled as part of the installer. So yes, Windows has a package manager, and it's great for what it does, but it's very different from a Linux package manager in practice. The distinction doesn't really matter to end users, but it does to developers, and it has a direct effect on package sizes. I don't think this situation is going to change much even as winget matures. Linux distributions carefully manage their packages, while Microsoft doesn't (and probably shouldn't).
        maccard 1y ago
        I never said that WinGet was a drop in replacement for yum - but the parents claim that windows doesn’t have a package manager isn’t true. There are plenty of padkages that require you to add extra sources to your package manager, that are not maintained by the distro. Docker [0] has official instructions to install via their package source. WinGet allows third party sources, so there’s no reason you can’t use it. It natively supports dependencies too. The fact that applications are packaged in a way that doesn’t utilise this for WinGet is true - but again, I was responding to the claim that windows doesn’t have a package manager. [0] https://docs.docker.com/engine/install/fedora/#install-using-the-repository https://docs.docker.com/engine/install/fedora/#install-using...
  - wmf 1y ago
    Unfortunately a lot of Windows devs are targeting 10 year old versions.
  - keyringlight 1y ago
    Assuming you're talking about winget, that seems to operate either as an alternative CLI interface to the MS store with a separate database developers would need to add their manifests to, or to download and run normal installers in silent mode. For example if you do winget show "adobe acrobat reader (64-bit) you can see what it will grab. It's a far cry from how most linux package managers operate
blahaj 1y ago
Just a guess, but Windows executables probably depend on a bunch of Windows APIs that are guaranteed to be there, while Linux systems are much more modular and do not have a common, let alone stable ABI interface in the userspace. You can probably get small graphically capable binaries if you depend on QT and just assume it to be present, but Flatpak precisely does not do that and bundles all the dependencies to be independent from shared dependencies of the OS outside of its control. The article also mentions that AppImages can be smaller probably because they assume some common dependencies to be present. And of course there are also tons of huge Windows software that come with all sorts of their own dependencies. Edit: I think I somewhat misread your comment and progval is more spot on. On Linux you usually install software with a package manager that resolves dependencies and only installs the unsatisfied dependencies resulting in small install size for many cases while on Windows that is not really a thing and installers just package all the dependencies they cannot expect to be present and the portable version just does the same.
dismalaf 1y ago
"Portable" apps on Windows just don't write into the registry or save state in a system directory. They can still assume every Windows DLL since the beginning of time will be there. Versus Linux where you have Gnome vs. KDE vs. Other and there's less emphasis on backwards compatibility and more on minimalism, so they need to package a lot more dependencies (potentially). If you only install Gnome Flatpaks they end up smaller since they can share a bunch of components.
badsectoracula 1y ago
The equivalent of "Windows portable apps" on Linux isn't flatpaks (these add a bunch of extra stuff and need some sort of support from the OS) but AppImages[0]. AppImages are still not 100% the same (and can never be as Windows applications can rely on A LOT more stuff to be there than Linux desktop apps) but functionally/UX-wise they're the closest: you download some program, chmod +x it and run it like any other binary you'd have on your PC. Personally i vastly prefer AppImages to flatpaks (in fact i do not use flatpaks at all, i'd rather build the program from source - or not use it if the build process is too convoluted - instead). [0] https://appimage.org/ https://appimage.org/
- codedokode 1y ago
  Looking at their architecture they seem to be a pain to run safely (sandboxed). For example, you cannot take away access to mount syscall due to them mounting themselves using FUSE. Also are they easy to debug? Do they ship with debugging symbols? Googling around shows that it might be tricky.
kmeisthax 1y ago
It's a matter of standardization and ABI stability. Linux itself promises an eternally stable syscall ABI, but everything else around it changes constantly. Windows is basically the opposite: no public syscall ABI, but you can always get a window on screen by linking USER.dll and poking it with the correct structures. As a result, Windows apps can assume more, while desktop Linux apps have to ship more.
- codedokode 1y ago
  Linux is moving to Windows model, by shipping userspace libraries. For example, ALSA has a library, DRM has a library.
account-5 1y ago
I'm replying to myself in reply to everyone who replied to me. Thanks all for the explanations, much appreciated, I thought I was missing something. I really should have known though, Ive been using portable apps for over 20 years on windows and remember.net apps not being considered portable way back when, which are now considered portable since the run time is on all modern windows.
johnny22 1y ago
> Clearly I'm wrong, but how is it that windows can have portable apps of a similar size to their installable versions and Linux cann They can't depend on many apis existing or at the right version. Linux distros are made from a collection of various third party projects and distros just integrate those. Each of these third party projects has it's own development speed and ABI and API stability policies. Each distro also has it's own development speed and release policy, which means they might have things that could either be too new or to old. Most distros try to avoid packaging multiple versions of the same project when they can avoid it to ease maintenance as well. Heck, you can't even guarantee that you have the exact same libc. Most distros use glibc, but there are plenty of systems that use musl.
int_19h 1y ago
If you're targeting Windows, you can assume the following things to be present: - the entirety of Win32 API - all the Windows Runtime APIs - .NET Framework 4.7+ This is a lot of functionality. For example, the list above includes four different widget toolkits alone (Win32, WinForms, WPF, WinRT XAML), several libraries to handle networking (including HTTP), USB, 2D and 3D graphics including text rendering, HTML renderer etc. And all of this has a highly stable ABI, so long as you do everything by the book. COM/WinRT and .NET provide a stable ABI for high-level object-oriented APIs above and beyond what the basic C ABI can offer.
- surajrmal 1y ago
  The real problem in Linux is the lack of a stable abi for anything other than the kernels UAPI. Perhaps one day we will standardize enough of the lower layers of Linux and provide real stability. There is definitely a line between packaging all of your dependencies and packaging none of them. We probably want something in the middle, or else perhaps more functionality which is currently provided via shared libraries should be moved behind stable IPC instead.

jasonpeacock 1y ago

The article mentions that Flatpack is not suitable for servers because it uses desktop features. Does anyone know what those features are or have more details? Linux generally draws a thin line between server and desktop, having “desktop only” dependencies is unusual less it’s something like needing the KDE or Gnome GUI libraries?

LtWorf 1y ago
AFAIK it cannot do CLI applications at all.
- jeroenhd 1y ago
  It can, but because the Flatpak system depends on APIs like D-Bus getting those to work in headless environments (SSH, framebuffer console, raw TTY) is a pain. Flatpak will even helpfully link binaries you install to a directory you can add to your $PATH to make command line invocation easy.
mananaysiempre 1y ago
This may refer to xdg-desktop-portal[1], which is usable without Flatpak, but Flatpak forces you to go through it to access anything outside the app’s private sandbox. In particular, access to user files is mediated through a powerbox (trusted file dialog) [2] provided by the desktop environment. In a sense, Flatpak apps are normal Linux apps to about the same extent that WinRT/UWP apps are normal Windows apps—close, but more limited, and you’re going to need significant porting in either direction. (This has also made an otherwise nice music player[3] unusable to me other than by dragging and dropping individual files from the file manager, as all of my music lives in git-annex, and accesses through git-annex symlinks are indistinguishable from sandbox escape attempts. On one hand, understandable; on the other, again, the software is effectively useless because of this.) [1] https://wiki.archlinux.org/title/XDG_Desktop_Portal https://wiki.archlinux.org/title/XDG_Desktop_Portal [2] https://wiki.c2.com/?PowerBox https://wiki.c2.com/?PowerBox [3] https://apps.gnome.org/Amberol https://apps.gnome.org/Amberol
- 1y ago

pdimitar 1y ago

[flagged]

renewiltord 1y ago
But I don’t want to solve actual problems. I want to write the 3689th lisp interpreter in the world.
- pdimitar 1y ago
  Your right and prerogative, obviously. But out there, a stranger you care nothing about, will think less of you. Wish I had that free time and freedom though... The things I would do.
  - renewiltord 1y ago
    You can have that free time. Stop posting on HN and write some code. I can do both but if I couldn’t I’d pick the latter.
    - pdimitar 1y ago
      [flagged]
bigyabai 1y ago
Pay me
- pdimitar 1y ago
  [flagged]
  - bigyabai 1y ago
    [flagged]
deleted 1y ago
[deleted]

loloquwowndueo 1y ago

“Storage is cheap” goes the saying. Other people’s storage has a cost of zero, so why not just fill it up with 100 copies of the same dependency. These package formats (I’m looking at you snap as well) are disrespectful of users’ computers to the point of creating a problem where due to size, things take so long and bog the computer down so much, that the resource being used is no longer storage, but time (system and human time). And THAT is not cheap at all. Don’t believe me, install a few dozen snaps, turn the computer off for a week, and watch in amazement as you turn it back on and see it brought to its knees as your computer and network are taxed to the max downloading and applying updates.

m4rtink 1y ago
Snaps do zero deduplication and bundle everything AFAIK - flatpak at least does some deduplication on file level and has shared runtimes.
- brlin2021 1y ago
  This statement is false as snaps also have shared runtimes known as "content snaps". A common example is the ones with the gnome- prefix and the ones that end with -themes suffix.
  - loloquwowndueo 1y ago
    Wherein snaps found themselves reinventing shared libraries - at which point, what’s really the point.
    - Seattle3503 1y ago
      I think the point is that maintainers and developers now have a choice of whether they want to share libraries or not. Before the only choice was to share dependencies.
      - hedora 1y ago

gjsman-1000 1y ago

It feels, to me, like the Linux desktop has become an overly complicated behemoth, never getting anywhere due to its weight. I still feel the pinnacle for modern OS design might be Horizon, by Nintendo of all people. A capability-based microkernel OS that updates in seconds, fits into under 400 MB (WebKit and NVIDIA drivers included), is fast enough for games, and hasn’t had an unsigned code exploit in half a decade. (The OS is extremely secure, but NVIDIA’s boot code wasn’t.) Why can’t we build something like that?

anthk 1y ago
Alpine Linux?
- gjsman-1000 1y ago
  Close; but the security still isn’t anywhere close. On Alpine, if there’s a zero day in WebKit, you’d better check how your security is set up, and hope there’s not an escalation chain. On Horizon, dozens of bugs in WebKit, the Broadcom Bluetooth stack, and the games have been found; they are still found regularly. They are also boring and completely useless, because the sandboxing is so tight. You also can’t update Alpine in 5 seconds flat, even between a dozen major versions. That alone is amazing.
  - yjftsjthsd-h 1y ago
    > Close; but the security still isn’t anywhere close. [...] I think a lot of the security comes down to what compromises you're willing to make. Horizon doesn't have to support the same breadth of hardware or software as we expect out of normal OSs, so they can afford to reinvent the world on a secure microkernel. If we want to maintain backwards-compatibility (and we do, because otherwise it's dead on arrival) then we have to take smaller steps. Of course, we can take those steps; if you care about security then you should run your browser in a sandbox (firejail, bubblewrap, docker/podman) at which point a zero-day in the browser is lower impact (not zero risk, true, but again I don't see any way to fix that without throwing out performance or compatibility). > You also can’t update Alpine in 5 seconds flat, even between a dozen major versions. That alone is amazing. I rather assumed that the Switch doesn't actually install OS updates in 5s either? The obvious way to do what they're doing is A/B updates in the background, after which you "apply" by rebooting, which Linux can do in 5s.

ReptileMan 1y ago

Why does it seems that we try to both avoid and reinvent the static linker poorly with every new technology and generation. Windows has been fighting with dll hell for 30 years now. Linux seems to not be able to produce alternative to dll hell. Not sure how osx world is.

butz 1y ago

If you are space concious, you should try to select Flatpak apps that are using the same runtime (Freedesktop, GNOME or KDE), and make sure all of them are using exactly the same version of runtime. Correct me if I'm wrong, but only two versions of Flatpak runtimes are supported at a time - current and previous. So during times when transitioning happens to newer runtime, some application upgrades are not done at once, and user ends up using more than one (and sometimes more than two) runtimes. In addition to higher disk space usage, one must account for usual updates too. The more programs and runtimes you have, more updates to download. Good thing, at least updates are partial.

qbane 1y ago

I hope articles like this can at least provide some hints when the size of a flatpak store grows without bound. It is definitely more involved than "it bundles everything like a node_modules directory hence..." [Bug]: /var/lib/flatpak/repo/objects/ taking up 295GB of space: https://github.com/flatpak/flatpak/issues/5904 https://github.com/flatpak/flatpak/issues/5904 Why flatpak apps are so huge in size: https://forums.linuxmint.com/viewtopic.php?t=275123 https://forums.linuxmint.com/viewtopic.php?t=275123 Flatpak using much more storage space than installed packages: https://discussion.fedoraproject.org/t/flatpak-using-much-more-storage-space-than-installed-packages/67970 https://discussion.fedoraproject.org/t/flatpak-using-much-mo...

catlikesshrimp 1y ago
Your comment probably took more effort for this article than the prompter of the AI that produced said article. Conclusion: Thank you for the links

deleted 1y ago

[deleted]

deleted 1y ago

[deleted]

haunter 1y ago

What made Flatpaks more popular than Appimage? I thought the latter is "vastly" superior and really portable?

kalaksi 1y ago
I don't claim to know the answer but flatpaks have easier distribution (flathub), package management, sandboxing, can share runtimes and are also portable in the sense that they work across linux distros. AppImage is a simple and even more portable format but not much else so I guess it's superior if you only want to maximize portability.
Vilian 1y ago
It's depends, flatpak is a lot more portable, it bundle everything, the libraries are shared, thing that appimage can't, it automatically updates, it's more secure, and have a stronger sandbox, and it integrate better with the system
- akimbostrawman 1y ago
  >it's more secure, and have a stronger sandbox AppImages don't have a sandbox at all, they have full access to everything the user has.

wltr 1y ago

That was so useless and the style was so bad, I’m pretty sure it was written with (if not by) LLMs. Not even sure if I’m disappointed finding this low effort content here, or rather not surprised at all. I wish the content here would be more interesting, but maybe I’d want to find some other community for that. I mean, the comments are much more interesting than this piece of content, but the content itself is almost offending. At least the discussion is much more valuable than what I’ve just read by following that link.

INTPenis 1y ago

I use flatpaks daily but not many apps. Because I've been on Atomic Linux for a couple years now flatpak has become part of my daily life. On this work laptop I have three flatpaks, Signal, Chromium and Firefox. They all take 1.6GiB in total. On my gaming PC I have Signal, Flatseal, Firefox, PrismLauncher, Fedora MediaWriter and Steam, and obviously they take over 700G because of the games in Steam, but if I count just the other flatpaks they're 2.2GiB. So yeah, not great, but on the other hand I don't care because I love the packaging of cgroups based software and I don't need many of them. I mean my container images take up a lot more space than my flatpaks.

massysett 1y ago

“ The name "Flatpak" is even a nod to IKEA's flatpacking,” Which is hilarious: an IKEA flat pack takes up less space than the finished product. Linux flatpack is the exact opposite.

tomhowls 1y ago

[flagged]

_Soulou 1y ago

Something I have been wondering with Flatpak is about Ram usage. As sharing dynamic libraries allow loading it into RAM only once, while if I use Signal, Chromium and different others Flatpaks, all libs will be loaded multiple times (often with their own version). So maybe disk is cheap but RAM may be more limited, which looks kind of a limit in the generalization of this method of distribution. (You could tell me it's the same with containers) Am I right to think that? Has someone measured that difference on their workstation?

codedokode 1y ago
Web browser (Signal and Chromium) wastes so much memory that shared libraries size is not important. Also, shared libraries can always be dropped from memory.
Vilian 1y ago
The same libraries are shared between flatpak apps, and everything deduplicated, so I don't thinknso, but someone would have to test

mcv 1y ago

I don't know much about package managers, but instead of demanding every app uses the same version of every library, or including all libraries in every app, wouldn't it make more sense to allow different versions of libraries to exist next to each other, and every app simply picks the more up to date version that it supports? I think that's how npm does it. Not that npm doesn't have its own dependency hell, but that's because different dependencies within the same application can end up requiring different versions of the same sub-dependency. But that's a problem only for developers.

Vilian 1y ago
...that's literally what flatpak does?, and it deduplicate everything too
- mcv 1y ago
  Is it? But if its only duplication is different versions of the same dependency, and it never has real duplication, then what exactly is the problem? As I said, I don't know much about these things. I thought flatpak had the app and all its dependencies together in a single package.

Havoc 1y ago

They took the “works on my computer - then we’ll just ship my computer” meme literally

compsciphd 1y ago

I'll repeat myself, but this is because Docker (and all its descendents) didn't understand my work (or at least took the easy way out). https://www.usenix.org/conference/usenix-atc-10/apiary-easy-use-desktop-application-fault-containment-commodity-operating https://www.usenix.org/conference/usenix-atc-10/apiary-easy-... I argued (and built years prior to docker), a container oriented file system infrastructure that combined the best of linux style package management and union file systems. Where instead of "packages", you had "layers" (analogous to packages) and an "image" that was just a set of layers. I imagined, instead of a linux distribution having an archive of installable packages, it would provide a mirror of usable layers (and PoCd this by converting a large enough set of Debian packages into layers to cover the applications needed for my PoC). In such a world, you don't waste (directly at least) any additional space, as you are sharing the packages directly (and therefore the underlying files, which can also have memory benefits in terms of easier sharing of ro code pages, due to being the same page on disk). You do still have a concept of version sprawl, as different images can be using different versions of the same package, but its not very visible. Each image enumerates directly what "shared" components its using. One could argue that just like upgrading a regular deb/rpm environment is relatively straight forward, "upgrading" (or in reality, creating a new image version from an existing version) in such a world is also easy. Just upgrade the shared layer versions in the image manifest/definition. I was trying to create a world where you could upgrade the container easily (ex: move the running container's private RW layer to a new container on upgrade, or in a sense resolve the container's layers from version A to version B by swapping around the layers that have changed), but one might argue that today that isn't viewed as valuable, and I might agree. I was trying to demonstrate a system that supported what I called persistent and ephemeral containers, with persistent containers being what became called pets and ephemeral containers being what became called cattle and the world today wants everything to be cattle.