10 ms·

Linux desktop leaders unite behind Flathub app store. Here's why

82 points by CrankyBear 4y ago

gimix311 4y ago
[flagged]
superkuh 4y ago
Because they've given up on being able to maintain a desktop distro with a set of system libraries that allow you to run programs. Future shock from the too rapidly changing underlying libs and no thought of forwards compatibility longer than 3 years means no software lasts longer than 3 years, if that. And so, like a fever is a symptom of infection, we have containers as symptom of future shock. As for which container, it doesn't really matter, and there's been a lot of not-invented here going around creating new containers that muddied the waters. But the truth is they're all symptoms of something bad even if they mitigate a problem temporarily (while making debugging, networking, freedesktop standards, etc incomparably harder).
- smoldesu 4y ago
  I agree. You've got a bit of a fatalist tone, but you're not wrong either - if Microsoft or Apple announced that they were depreciating all of their prior packaging options in favor of a QEMU image of your application, people would lose it. It's not just about performance or integration or nativeness for most people, it's about the files living in the same spot and not needing extra apps to manage a sandbox. Flatpak feels like it took the wrong lessons from the past 30 years of software distribution and turned it into a platform. I get that it has to be simplified to be friendly to newer users, but it's also a complete turnoff when you want to fix an issue or edit a config file.
- quaintdev 4y ago
  What do you think about Nix
  - superkuh 4y ago
    Nix is the ultimate expression of this abandonment of the concept of a desktop distro. It doesn't even try to have system libraries. Nix gives up re: future shock. The entire OS is just containers. I'm sure it works fine if you only ever use popular software but as someone that's constantly compiling and adding little .c programs from the 'net to my bin/ having to manually create and specify the entire "system" libraries set bit by bit every time I want to compile (or run!) something is no go. Great for business use as server, bad for human persons as a desktop.
    - RGamma 4y ago
      Haven't tried it but you could probably pin an env with everything you would want and then use direnv for automation. And for quick experiments there's FHS/steam-run. But yeah.. setup.
    - gray_-_wolf 4y ago
      > manually create and specify the entire "system" libraries set bit by bit every time I want to compile (or run!) something is no go. I don't have first hand experience with nix, but if I would look at this statement from Guix point of view (and I assume nix will be same/very similar), this is not really true. Nothing prevents you from having a list of libraries (in a manifest). That list might be way to wide for any specific program and it can represent what you would normally have as "system libraries". You can then just invoke shell as guix shell --manifest=manifest.scm and you will be given working shell with all the libraries available. You can also just package your program using trivial copy&paste code with the same list. Sure, the dependencies will be too wide, but since you are not sending the package to upstream Guix for inclusion, no one really cares. So, is it as friction-less as "normal" distro? No (especially the "add to /bin" part). Is it as bad as "manually create and specify the entire "system" libraries set bit by bit every time"? Also no.
    - rgoulter 4y ago
      > Nix is the ultimate expression of this abandonment of the concept of a desktop distro. NixOS deliberately avoids having global/implicit 'system' libraries / configured state, and instead demands declarative expression of the system configuration. -- The libraries the system uses don't adhere to a global FHS structure. Nix similarly eschews use of global/implicit libraries. Building each package requires its dependencies be declared. However, it's incorrect to say this is "just containers". I don't see how you get "abandonment of concept of desktop distro" from "doesn't have implicit system libraries". -- NixOS allowing the whole system configuration starting from a single file is convenient, and something people might otherwise use a tool like Ansible for. That said, NixOS obviously has many use cases which have significantly higher friction compared to more typical systems. (And a steep learning curve to overcome that friction). -- e.g. on Arch or Ubuntu, the system configuration is global and malleable.
- mouse_ 4y ago
  Forgive me if it seems like this question comes from a place of ignorance and misunderstanding; it probably does. Why can't we just static link everything, and distribute binaries like we're on win32?
  - whoisthemachine 4y ago
    That exists - https://appimage.org/ https://appimage.org/.
    - oynqr 4y ago
      Appimages are not statically linked at all.
      - Infernal 4y ago
        While not statically linked necessarily, app images do attempt to bundle dependencies such that they “just work” as self-contained executables on most Linux distros - which is what the poster above seems to care about.
        rewgs 4y ago
        Which causes the aforementioned ballooning storage issue.
        Infernal 4y ago
        The ballooning storage issue was mentioned along with Flatpak, and is an issue as every single dependency is pulled in. AppImage excludes those dependencies which are "reasonably expected" to be on any Linux system. See the Application Sizes section here: https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others#1009061 https://askubuntu.com/questions/866511/what-are-the-differen... Example: LibreOffice download size (source) - AppImage ~248 MByte - Snap 463 MByte [July 2020 update] - Flatpak 543 MByte EDIT: formatting
        4y ago
- lenkite 4y ago
  Once the linux world moves completely to Flatpak, that would truly help languages like C++ - whose evolution and cleanliness has been tremendously crippled by being unable to have a clean ABI break.
  - badsectoracula 4y ago
    Let me repeat a message i wrote some time ago here because i really don't think Flatpak is a good solution (note that this isn't issues from some ancient distro, this is from openSUSE Tumbleweed, this is only a few months old): -- Flatpak is awful, i tried installing software from it a few times and not only it always installs a ton of unnecessary stuff (practically an entire distro!) but also the software doesn't integrate seamlessly with the rest of the system. GUI software looks wrong (themes do not apply, font rendering is wrong), command line software doesn't show up in PATH. Example in [0] for the GUI bits (Bless for theme, Notepadqq for font rendering) as well as the disk usage for two simple programs like a hex editor and a text editor. Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system. Nowadays i simply avoid anything related to flatpak. If something doesn't provide normal binaries and i really want it, i'd rather compile it from source (and if the source language is something exotic or the program needs a ton of dependencies i'd just skip it). [0] https://i.imgur.com/9tmo26J.png https://i.imgur.com/9tmo26J.png
    - IceWreck 4y ago
      For desktop integration, install flatseal and pass ~/.themes and other desktop directories to the flatpak app. It doesn't happen by default cause sandboxing. Command line software does show up in CLI, just not by its short name. You have to use the fully qualified app name - com.xyz.whatever. You can make an alias if you want. > Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system. Are you talking about flatpak install --user ? Yes youre right some apps might not work with it but how is that any worse than traditional packaging. Flatpak isn't perfect and I prefer distro packaging over everything else but it isn't feasable to have distro packaging for everything - not with the strict packaging rules most distros have atleast. But out of snap, appimage and flatpak I'd go with Flatpak.
- Ygg2 4y ago
  > forwards compatibility longer than 3 years Maintaining backwards and forwards compatibility will cripple you as a lib developer. If you do it, your solution will be slower to change, and probably slower overall than a solution that breaks compatibility occasionally. So you get less contribution and small bus factor means this library is more likely to die.
  - badsectoracula 4y ago
    On the other hand the developers who rely on your library wont need to waste time trying to play catch up with your breakage so that their programs keep doing the exact same stuff they were already doing and instead their most likely limited time (especially important for FLOSS developers, many of whom do that in their free time) will be instead put into improving what their applications actually does. In addition, even in the case the applications stop getting developed, they will keep working since their dependencies would not break and other developers can pick them up if needed, even years later. On the other hand having to pick up a project whose dependencies do not even work anymore is much harder.
    - Ygg2 4y ago
      > In addition, even in the case the applications stop getting developed, they will keep working since their dependencies would not break and other developers can pick them up if needed, even years later. In theory, yes. In practice due to Hyrum's law you'll have to reproduce bugged behavior because an application exploited a bug in your code. See for example SimCity Windows 95 compatibility story. https://arstechnica.com/gadgets/2022/10/windows-95-went-the-extra-mile-to-ensure-compatibility-of-simcity-other-games/ https://arstechnica.com/gadgets/2022/10/windows-95-went-the-... Now Microsoft could afford to buy and test a wide combination of hardware and applications to ensure future compatiblity.
smoldesu 4y ago
Part of my issue with Flatpak is that it takes these systems that really ought to be managed separately (process isolation, package management, runtime configuration, security, etc.) and makes them one monolith. It's an ok stopgap for people frustrated with software distribution, but it tangles itself up in so much mess that it's hard to promote over it's competitors (even Snap). It's not great. Sometimes it works well, but when the wiccan magic inside Flatpak breaks now you have to debug two runtimes for the price of one!
- wiseowise 4y ago
  > but when the wiccan magic inside Flatpak breaks now you have to debug two runtimes for the price of one! As a user I couldn’t care less.
  - pmontra 4y ago
    Well, if I understood the point correctly and if it happens too often, it could become too much of a burden (as in not enough sales to make it worthwhile.) Developer might end supporting only one runtime, deprecate and put out of support all the old ones. That's a problem for users and eventually for developers too: it they don't know how to create a release for everybody, they won't.
  - parineum 4y ago
    Exactly. A lot of Linux users grouse about people not wanting to use their favorite OS but they don't do it because a bunch of perfectly well built software may or may not run depending on some under-the-hood voodoo magic they don't understand and can't fix. Flatpaks fix that. If the pack is well built, it'll work. If it's from a reputable source, it's probably well built.
  - deleted 4y ago
    [deleted]
ar_lan 4y ago
What advantages does Flatpak offer over Nix? The only benefit(s) I see are: 1. Sandboxed applications (via containers?) - so applications you have don't technically have access to your home directories by default. That's sort of nice - but how many applications really warrant this overhead? 2. Possibly easier to write/package? That said, in Nix you pretty much just need to package once. I've not used Flatpak - can somebody who is maybe familiar with both technologies comment further? While I may be a big Nix evangelist, it's always confused me a bit why Flatpak exists and I'm curious if it is truly solving a problem I'm unaware of.
- AnIdiotOnTheNet 4y ago
  I don't have to learn a new language to use it and it is integrated with existing GNOME and KDE package install solutions.
- PurpleRamen 4y ago
  What advantages has Nix over Flatpak? Seems to be just yet another esoteric solution for installing software? Why should one prefer it over other solutions? How well does Nix integrate packages into the system? Flatpak is integrating apps into the desktop environments. Probably just following standards, but is Nix doing this too? Are Nix-Installations portable? I use Flatpak to have the same installation on different systems available, just move my SSD between them. How ell would this work with Nix?
  - smoldesu 4y ago
    Theoretically, you could create a Nix-Flatpak hybrid by sourcing your Bubblewrap packages/environment from the Nix store. It wouldn't be much different from how Nix handles it today, just with an additional layer of sandboxing for each environment. The problem Nix solves is the one Flatpak tries working around - how do I guarantee software builds and runs on my system? The answer turns out to be "very strictly", and Nix has done a good job of writing sane rules where it can. It's not perfect (and definitely not user-friendly today) but it has a larger package repo to work with and better support for stuff Flatpak is missing like system services. If people do want to switch to an immutable root system, I'd hope the goal is to be as modular as NixOS is someday.
colordrops 4y ago
Someone needs to slap a comprehensive GUI installer and configuration UI onto NixOS. It solves similar problems in a non-hacky way but is not easy enough for the average user.
- FengLengshun 4y ago
  This is being worked on by SnowflakeOS: https://discourse.nixos.org/t/snowflakeos-creating-a-gui-focused-nixos-based-distro/21856 https://discourse.nixos.org/t/snowflakeos-creating-a-gui-foc... https://github.com/vlinkz/nix-software-center https://github.com/vlinkz/nix-software-center
jmclnx 4y ago
Good for them :) These type of workarounds seems to point to people giving up in having secure applications, so much for the move to rust. So the path is to having applications in a walled garden. But who cares if all the plants in that garden is infested with aphids, at least they can say it won't spread. Well, time will tell on that. But, I hope application developers keep an eye on portability. There is more to the world than Linux. OpenBSD is avoiding all this complexity of Flatpack, snap, docker and all these attempts at contains. To me, pledge(2) and unveil(2) is far more secure and easier to use than what Linux is doing. And I think for containers, nothing still comes close to FreeBSD jails.
- Zurrrrr 4y ago
  It's funny you mention OpenBSD and pledge/unveil, because they don't really come close enough to being able to lock down the system, while linux has things like SELinux/RSBAC available.
criddell 4y ago
Does Flathub help with sandboxing? For example, if I download an app, can I know that it can’t access photos, or location, or microphone, etc… without asking first?
- oynqr 4y ago
  The flatpak CLI will tell you which permissions a program wants. GUI installers usually also show this information, just worse most of the time. If you want to revoke permissions, you can use Flatseal or the KDE settings module.
- deleted 4y ago
  [deleted]
jonfw 4y ago
I haven't daily driven linux on my desktop on a few years, so flatpak didn't have a ton of traction when I was a target user, but I do think it solves some of the problems I had running linux on my desktop I liked linux because I considered it to be a great development environment, but I always thought it was annoying as hell to run consumer software on. And I do have to run consumer software, whether it's web conferencing or chat or tools for some of my electronics, etc. Sandboxing consumer applications would have allowed me to focus my package management efforts entirely on my development environment
nvr219 4y ago
I still just use apt on debian because I'm a dinosaur apparently.
- nickstinemates 4y ago
  Using distro-provided package managers make sense to me
brucethemoose2 4y ago
Flatpak is great for self contained apps, but it seems problematic when it has to reach outside the sandbox. I ran into this in VSCode and with CUDA video processing filters, but I'm sure there are more examples. And thats what distro packages are for, I guess.
- sirius87 4y ago
  Try using Flatseal [1] which is a Flatpak app that helps manage permissions for other Flatpak apps. You can see exactly what permissions are enabled in each app's sandbox and expand/override everything from env vars to filesystem locations you want to enable access to. [1] https://github.com/tchx84/Flatseal https://github.com/tchx84/Flatseal
  - brucethemoose2 4y ago
    Yeah, but "install this thing to manually tweak that thing to get those things to work" is so linux, and is exactly what Flatpak is trying to avoid. On the other hand, its a security issue, so I supposed some opt in friction is prudent.
    - sirius87 4y ago
      Flatseal is only a convenience. I think you'll find that the flatpak CLI [1] has commands to do everything Flatseal does, albeit in an arguably unwieldy way. [1] https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-permission-set https://docs.flatpak.org/en/latest/flatpak-command-reference...
  - AnIdiotOnTheNet 4y ago
    There are still things Flatseal cannot make work though. For instance, the Wireshark FlatPak is incapable of actually capturing packets.
- FengLengshun 4y ago
  Yeah, which is why a lot of people in immutable distro uses distrobox. And now, it seems, Nix as well.
NayamAmarshe 4y ago
Flatpak is great! Flathub on the other hand... The app submission process is very convoluted and the documentation is super vague. Snap is much easier to publish and a joy to use with the dashboard and analytics. I hope Flathub improves their submission system and documentation because it's still a mystery to me.
FengLengshun 4y ago
Flatpak is the reason why people who only used Linux because of Steam Deck can just install the app from the app store, and it works well enough. And it's actually pretty cool that Flatpak keep improving, even in the past few years. It's not improving as fast as I'd like (I want VPN apps, Lutris controlling emulators, and Native Host Messaging to be working already) but a lot of issues are being worked on and these days they work well enough. I still prefer to use AUR if I could access it there, and some of the things I do are only available distro-agnostically through Nix or arch distrobox, but Flatpak is absolutely great when it's available and the sandbox isn't in the way.
blendergeek 4y ago
I owned a Librem 5 phone and used it as my daily driver for a few months. During this time I exclusively used Flatpaks for my apps that I installed. After installing about 15-20 apps, the 32 GB of internal storage were completely full and my phone stopped working. I had no clue how huge Flatpak apps are. Even worse, I could not find out which apps to delete. All the space was taken up by excess "runtimes" I don't know or care what a runtime is but I never intentionally installed them. Why are there five different Freedesktop and Gnome runtimes installed? Which app do I delete to get rid of them? I need to be able to easily answer the questions: "Which app(s) do I delete to free up space?" and "how much space will be freed by deleting app X?" On flatpak those questions required dark magic beyond my understanding to answer.
- timw4mail 4y ago
  This is especially relevant on devices with limited storage, like the Steam Deck. Keeping dependencies with applications does have a lot of advantages, especially for applications that need incompatible versions of the same libraries. But, having every application with its own full set of dependencies seems quite wasteful.
- deleted 4y ago
  [deleted]
- 2OEH8eoCRo0 4y ago
  Could this be solved by smarter layering? I've read that Flatpaks are just container images under the hood and I'm sure many of those share the same base layers.
  - Havoc 4y ago
    Docker does that, but I had understood flatpak to be closer to a VM. i.e. not layered in the same way
  - deleted 4y ago
    [deleted]
  - akvadrako 4y ago
deleted 4y ago
[deleted]
Kukumber 4y ago
there are no leaders, nobody own the "linux desktop" this is like systemd, bunch of people enforce poorly designed product on everyone linux is becoming a windows bis, and this piss me off
dathinab 4y ago
From a 2023 POV about desktop OS security running things sandboxed is a _strong must have_. Even for well curated applications, through less so. So I'm happy about the general direction here. But last time I looked at flathub (and related topics), I was quite disappointed to a point that I would say they majorly failed this. Now that was quite a while ago. But just the fact that in a non well curated app store you could download applications which where not effectively sandboxed (e.g. used it only for copatibility not sandboxing) in a context which made it look for users like it's sandboxed without any huge red warning label or similar was quite shocking and made me second guess the security competence of the involved developers. Now I hope things are much better by now and I guess I will spend some time to look into it again this weekend. But the reason I write this here isn't because I want to dump on flathub but because I often feel that huge parts of the Linux community seem to be very out of touch when it comes to desktop OS security to a point it makes me worry for the future of desktop Linux. (It's also not just security e.g. some design decisions and defaults of systemd make sense for many Linux use case, but not desktop systems. The Unix permission model doesn't match well to the desktop OS security concerns of today either etc. etc.)
- MayeulC 4y ago
  I strongly agree. Luckily, a lot of other people do, and the ecosystem is moving towards run-time permissios ("portals") that allow users to confirm access. It does take a while for toolkits to start using them, but AFAIK, as an example, both KDE and GNOME now transparently use portals for the file chooser dialog. It will take more time for everything to move to newer, safer APIs (Wayland, screensharing portal, etc). The situation is much better than it was a few years ago, though. And most frontends now display required permissions; KDE even recently integrated permission management in is system settings. Some portals still need to be devised though, especially for device access (gamepads, webcams, etc).
gnulinux 4y ago
What are people's opinions on Flatpak vs AppImage? I use both (AppImage a lot more so than Flatpak) and I'm not well educated in their differences. I shall research it, but I'm wondering if anyone has some insight to share. Some apps I use (MuseScore) publish their own official .AppImage linux executables which work flawlessly for me, so I cannot abandon AppImage completely. Is it worth it to use both? Is it better to switch to one for everything, along with distro package manager? Thoughts?
- badsectoracula 4y ago
  AppImage is a more localized approach to Flatpak's "bundle everything" in that instead of trying to have shared libraries across different applications (Flatpak tries to share runtimes), every set of dependencies is local to the application itself. In a way it is kinda like trying to static link everything, though of course it doesn't technically use static linking - and it is really up to the developer what "everything" means (it can still rely on stuff on the underlying OS). Also it only tries to solve the dependency problem, whereas Flatpak tries to do a bunch of other stuff. From a "how things should be" perspective, both are bad IMO (see my other messages here), but from a purely practical perspective based on my experience with trying to use applications using them, AppImage tends to work slightly better and since it is local only to the application, it doesn't pollute the rest of the system. If i had to choose, i'd choose none of them, but if i had to choose between the two then AppImage is by far the most preferable.
  - Infernal 4y ago
    I've looked at your other comments here but I can't find elaboration on the bad parts of AppImage. I tend to agree that AppImage is the best of the available options - do you mean that the best solution would be rich system libraries that never break backwards compatibility ala Windows? And since we don't have that, AppImage is the best we can do?
    - badsectoracula 4y ago
      Yes, i meant for the "how things should be", the comments i meant were those backwards compatibility which is the root of the problem and AppImage is just a workaround for it.
neilv 4y ago
Flatpak seems great for users who don't understand or care about open source software platforms, other than that they don't have to pay money for it. A contemporary app store is a spectacularly awesome middleperson business to be in -- both in revenue, and in anti-competitive power.
communism 4y ago
Let's use Red Star OS. It's the best OS in the world. It doesn't have flathub integrated though, unfortunately.
kitsunesoba 4y ago
Potentially stupid question, is there any reason a "simple" .app bundle like has been used on NeXTStep/macOS for decades wouldn't work on Linux? That doesn't take care of sandboxing, but that seems like it'd be better handled by the OS itself rather than the package management system, and it avoids the problems with overhead and integration that come with things like Flatpak and Snap.
- AnIdiotOnTheNet 4y ago
  > is there any reason a "simple" .app bundle like has been used on NeXTStep/macOS for decades wouldn't work on Linux? Conceptually no, and both GNUStep and RoxFiler/RoxOS did just that. The practical reality though was that Linux Desktop has never had a conception of which pieces are 'add-on' and which are 'base-system', and to the extent there was any collection of components that could be part of the latter they were frequently making breaking changes. Combined with no coherent standard for properly versioning libraries and every fiefdom package repo doing its own thing, and what you're left with is decidedly not a platform. The modern version of Rox AppDirs is AppImage, and it mostly kinda works on most distros. This is sad, but there's just no way out of it as long as the Linux Desktop community continues to reject the very concept of being a platform. Steam initially tried to solve this for games by just dragging along its own Runtime for developers to target, but there were still issues. They've since regrouped and basically just declared Win32 the one true stable runtime ABI for games on Linux. FlatPak just decided that yet-another-package-manager was the way to go and manages a collection of explicitly defined runtimes instead. It works well enough for most use cases.
stcroixx 4y ago
As a daily Linux desktop user for 20+ years I don’t want any kind of App Store at all. Forcing me to interact with one will drive me away for sure.
DeathArrow 4y ago
I'd rather use rpm or deb under Linux. Flatpack means potentially duplicating lots of files.
- tristan957 4y ago
  Not really. Runtimes have lots of software that is shared. If you are building a run of the mill GTK application, you probably use the GNOME runtime with no extra dependencies.
TheChaplain 4y ago
One thing I really dislike with snap/flatpak is how it breaks connectivity with other parts your system. Example, I run Ubuntu and wanted to use a smartcard for authentication in certain websites. That didn't work because Firefox is in a snap, and can not communicate with the pkcs11 libraries... To solve that I have to scrap Firefox as snap and install as debian package from PPA.
- tristan957 4y ago
  You could try Flatpak and override some of the defaults. I would probably open an issue with Mozilla since they maintain at least the Flatpak. Not sure about the Snap.
- belthesar 4y ago
  To some degree, I like this, but the experience for both to allow access is still pretty draconian. I'm not quite sure what the process is for Snap to adjust this (it might require a rebuild?), but I know for Flatpak it's common for folks to say "Use Flatseal to adjust the permissions of what the app has access to" to resolve problems like this. In an ideal world, the application would be Flatpak or Snapcraft aware (or there'd be a middleware to intercept these calls), and ask for access to parts of the system it needs.
class3shock 4y ago
As a non-technical linux user, seeing the ecosystem move towards some sort of standard on this front is wonderful and feels long overdue. Understanding how to install (or uninstall) software is one of greatest pain points for new / non-technical linux users.
tpoacher 4y ago
A benefit of all this crap is that Slackware will probably become cool again.
Brian_K_White 4y ago
Reinventing static binaries but 500x worse.
- nikau 4y ago
  At least static binaries slip under the radar of vulnerability management tools so you don't have to go through the tedious patching treadmill as often

82 points by CrankyBear 4y ago

[flagged]

Because they've given up on being able to maintain a desktop distro with a set of system libraries that allow you to run programs. Future shock from the too rapidly changing underlying libs and no thought of forwards compatibility longer than 3 years means no software lasts longer than 3 years, if that. And so, like a fever is a symptom of infection, we have containers as symptom of future shock. As for which container, it doesn't really matter, and there's been a lot of not-invented here going around creating new containers that muddied the waters. But the truth is they're all symptoms of something bad even if they mitigate a problem temporarily (while making debugging, networking, freedesktop standards, etc incomparably harder).

smoldesu 4y ago
I agree. You've got a bit of a fatalist tone, but you're not wrong either - if Microsoft or Apple announced that they were depreciating all of their prior packaging options in favor of a QEMU image of your application, people would lose it. It's not just about performance or integration or nativeness for most people, it's about the files living in the same spot and not needing extra apps to manage a sandbox. Flatpak feels like it took the wrong lessons from the past 30 years of software distribution and turned it into a platform. I get that it has to be simplified to be friendly to newer users, but it's also a complete turnoff when you want to fix an issue or edit a config file.
quaintdev 4y ago
What do you think about Nix
- superkuh 4y ago
  Nix is the ultimate expression of this abandonment of the concept of a desktop distro. It doesn't even try to have system libraries. Nix gives up re: future shock. The entire OS is just containers. I'm sure it works fine if you only ever use popular software but as someone that's constantly compiling and adding little .c programs from the 'net to my bin/ having to manually create and specify the entire "system" libraries set bit by bit every time I want to compile (or run!) something is no go. Great for business use as server, bad for human persons as a desktop.
  - RGamma 4y ago
    Haven't tried it but you could probably pin an env with everything you would want and then use direnv for automation. And for quick experiments there's FHS/steam-run. But yeah.. setup.
  - gray_-_wolf 4y ago
    > manually create and specify the entire "system" libraries set bit by bit every time I want to compile (or run!) something is no go. I don't have first hand experience with nix, but if I would look at this statement from Guix point of view (and I assume nix will be same/very similar), this is not really true. Nothing prevents you from having a list of libraries (in a manifest). That list might be way to wide for any specific program and it can represent what you would normally have as "system libraries". You can then just invoke shell as guix shell --manifest=manifest.scm and you will be given working shell with all the libraries available. You can also just package your program using trivial copy&paste code with the same list. Sure, the dependencies will be too wide, but since you are not sending the package to upstream Guix for inclusion, no one really cares. So, is it as friction-less as "normal" distro? No (especially the "add to /bin" part). Is it as bad as "manually create and specify the entire "system" libraries set bit by bit every time"? Also no.
  - rgoulter 4y ago
    > Nix is the ultimate expression of this abandonment of the concept of a desktop distro. NixOS deliberately avoids having global/implicit 'system' libraries / configured state, and instead demands declarative expression of the system configuration. -- The libraries the system uses don't adhere to a global FHS structure. Nix similarly eschews use of global/implicit libraries. Building each package requires its dependencies be declared. However, it's incorrect to say this is "just containers". I don't see how you get "abandonment of concept of desktop distro" from "doesn't have implicit system libraries". -- NixOS allowing the whole system configuration starting from a single file is convenient, and something people might otherwise use a tool like Ansible for. That said, NixOS obviously has many use cases which have significantly higher friction compared to more typical systems. (And a steep learning curve to overcome that friction). -- e.g. on Arch or Ubuntu, the system configuration is global and malleable.
mouse_ 4y ago
Forgive me if it seems like this question comes from a place of ignorance and misunderstanding; it probably does. Why can't we just static link everything, and distribute binaries like we're on win32?
- whoisthemachine 4y ago
  That exists - https://appimage.org/ https://appimage.org/.
  - oynqr 4y ago
    Appimages are not statically linked at all.
    - Infernal 4y ago
      While not statically linked necessarily, app images do attempt to bundle dependencies such that they “just work” as self-contained executables on most Linux distros - which is what the poster above seems to care about.
      - rewgs 4y ago
        Which causes the aforementioned ballooning storage issue.
        Infernal 4y ago
        The ballooning storage issue was mentioned along with Flatpak, and is an issue as every single dependency is pulled in. AppImage excludes those dependencies which are "reasonably expected" to be on any Linux system. See the Application Sizes section here: https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others#1009061 https://askubuntu.com/questions/866511/what-are-the-differen... Example: LibreOffice download size (source) - AppImage ~248 MByte - Snap 463 MByte [July 2020 update] - Flatpak 543 MByte EDIT: formatting
      - 4y ago
lenkite 4y ago
Once the linux world moves completely to Flatpak, that would truly help languages like C++ - whose evolution and cleanliness has been tremendously crippled by being unable to have a clean ABI break.
- badsectoracula 4y ago
  Let me repeat a message i wrote some time ago here because i really don't think Flatpak is a good solution (note that this isn't issues from some ancient distro, this is from openSUSE Tumbleweed, this is only a few months old): -- Flatpak is awful, i tried installing software from it a few times and not only it always installs a ton of unnecessary stuff (practically an entire distro!) but also the software doesn't integrate seamlessly with the rest of the system. GUI software looks wrong (themes do not apply, font rendering is wrong), command line software doesn't show up in PATH. Example in [0] for the GUI bits (Bless for theme, Notepadqq for font rendering) as well as the disk usage for two simple programs like a hex editor and a text editor. Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system. Nowadays i simply avoid anything related to flatpak. If something doesn't provide normal binaries and i really want it, i'd rather compile it from source (and if the source language is something exotic or the program needs a ton of dependencies i'd just skip it). [0] https://i.imgur.com/9tmo26J.png https://i.imgur.com/9tmo26J.png
  - IceWreck 4y ago
    For desktop integration, install flatseal and pass ~/.themes and other desktop directories to the flatpak app. It doesn't happen by default cause sandboxing. Command line software does show up in CLI, just not by its short name. You have to use the fully qualified app name - com.xyz.whatever. You can make an alias if you want. > Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system. Are you talking about flatpak install --user ? Yes youre right some apps might not work with it but how is that any worse than traditional packaging. Flatpak isn't perfect and I prefer distro packaging over everything else but it isn't feasable to have distro packaging for everything - not with the strict packaging rules most distros have atleast. But out of snap, appimage and flatpak I'd go with Flatpak.
Ygg2 4y ago
> forwards compatibility longer than 3 years Maintaining backwards and forwards compatibility will cripple you as a lib developer. If you do it, your solution will be slower to change, and probably slower overall than a solution that breaks compatibility occasionally. So you get less contribution and small bus factor means this library is more likely to die.
- badsectoracula 4y ago
  On the other hand the developers who rely on your library wont need to waste time trying to play catch up with your breakage so that their programs keep doing the exact same stuff they were already doing and instead their most likely limited time (especially important for FLOSS developers, many of whom do that in their free time) will be instead put into improving what their applications actually does. In addition, even in the case the applications stop getting developed, they will keep working since their dependencies would not break and other developers can pick them up if needed, even years later. On the other hand having to pick up a project whose dependencies do not even work anymore is much harder.
  - Ygg2 4y ago
    > In addition, even in the case the applications stop getting developed, they will keep working since their dependencies would not break and other developers can pick them up if needed, even years later. In theory, yes. In practice due to Hyrum's law you'll have to reproduce bugged behavior because an application exploited a bug in your code. See for example SimCity Windows 95 compatibility story. https://arstechnica.com/gadgets/2022/10/windows-95-went-the-extra-mile-to-ensure-compatibility-of-simcity-other-games/ https://arstechnica.com/gadgets/2022/10/windows-95-went-the-... Now Microsoft could afford to buy and test a wide combination of hardware and applications to ensure future compatiblity.

smoldesu 4y ago

Part of my issue with Flatpak is that it takes these systems that really ought to be managed separately (process isolation, package management, runtime configuration, security, etc.) and makes them one monolith. It's an ok stopgap for people frustrated with software distribution, but it tangles itself up in so much mess that it's hard to promote over it's competitors (even Snap). It's not great. Sometimes it works well, but when the wiccan magic inside Flatpak breaks now you have to debug two runtimes for the price of one!

wiseowise 4y ago
> but when the wiccan magic inside Flatpak breaks now you have to debug two runtimes for the price of one! As a user I couldn’t care less.
- pmontra 4y ago
  Well, if I understood the point correctly and if it happens too often, it could become too much of a burden (as in not enough sales to make it worthwhile.) Developer might end supporting only one runtime, deprecate and put out of support all the old ones. That's a problem for users and eventually for developers too: it they don't know how to create a release for everybody, they won't.
- parineum 4y ago
  Exactly. A lot of Linux users grouse about people not wanting to use their favorite OS but they don't do it because a bunch of perfectly well built software may or may not run depending on some under-the-hood voodoo magic they don't understand and can't fix. Flatpaks fix that. If the pack is well built, it'll work. If it's from a reputable source, it's probably well built.
- deleted 4y ago
  [deleted]

ar_lan 4y ago

What advantages does Flatpak offer over Nix? The only benefit(s) I see are: 1. Sandboxed applications (via containers?) - so applications you have don't technically have access to your home directories by default. That's sort of nice - but how many applications really warrant this overhead? 2. Possibly easier to write/package? That said, in Nix you pretty much just need to package once. I've not used Flatpak - can somebody who is maybe familiar with both technologies comment further? While I may be a big Nix evangelist, it's always confused me a bit why Flatpak exists and I'm curious if it is truly solving a problem I'm unaware of.

AnIdiotOnTheNet 4y ago
I don't have to learn a new language to use it and it is integrated with existing GNOME and KDE package install solutions.
PurpleRamen 4y ago
What advantages has Nix over Flatpak? Seems to be just yet another esoteric solution for installing software? Why should one prefer it over other solutions? How well does Nix integrate packages into the system? Flatpak is integrating apps into the desktop environments. Probably just following standards, but is Nix doing this too? Are Nix-Installations portable? I use Flatpak to have the same installation on different systems available, just move my SSD between them. How ell would this work with Nix?
- smoldesu 4y ago
  Theoretically, you could create a Nix-Flatpak hybrid by sourcing your Bubblewrap packages/environment from the Nix store. It wouldn't be much different from how Nix handles it today, just with an additional layer of sandboxing for each environment. The problem Nix solves is the one Flatpak tries working around - how do I guarantee software builds and runs on my system? The answer turns out to be "very strictly", and Nix has done a good job of writing sane rules where it can. It's not perfect (and definitely not user-friendly today) but it has a larger package repo to work with and better support for stuff Flatpak is missing like system services. If people do want to switch to an immutable root system, I'd hope the goal is to be as modular as NixOS is someday.

colordrops 4y ago

Someone needs to slap a comprehensive GUI installer and configuration UI onto NixOS. It solves similar problems in a non-hacky way but is not easy enough for the average user.

FengLengshun 4y ago
This is being worked on by SnowflakeOS: https://discourse.nixos.org/t/snowflakeos-creating-a-gui-focused-nixos-based-distro/21856 https://discourse.nixos.org/t/snowflakeos-creating-a-gui-foc... https://github.com/vlinkz/nix-software-center https://github.com/vlinkz/nix-software-center

jmclnx 4y ago

Good for them :) These type of workarounds seems to point to people giving up in having secure applications, so much for the move to rust. So the path is to having applications in a walled garden. But who cares if all the plants in that garden is infested with aphids, at least they can say it won't spread. Well, time will tell on that. But, I hope application developers keep an eye on portability. There is more to the world than Linux. OpenBSD is avoiding all this complexity of Flatpack, snap, docker and all these attempts at contains. To me, pledge(2) and unveil(2) is far more secure and easier to use than what Linux is doing. And I think for containers, nothing still comes close to FreeBSD jails.

Zurrrrr 4y ago
It's funny you mention OpenBSD and pledge/unveil, because they don't really come close enough to being able to lock down the system, while linux has things like SELinux/RSBAC available.

criddell 4y ago

Does Flathub help with sandboxing? For example, if I download an app, can I know that it can’t access photos, or location, or microphone, etc… without asking first?

oynqr 4y ago
The flatpak CLI will tell you which permissions a program wants. GUI installers usually also show this information, just worse most of the time. If you want to revoke permissions, you can use Flatseal or the KDE settings module.
deleted 4y ago
[deleted]

jonfw 4y ago

I haven't daily driven linux on my desktop on a few years, so flatpak didn't have a ton of traction when I was a target user, but I do think it solves some of the problems I had running linux on my desktop I liked linux because I considered it to be a great development environment, but I always thought it was annoying as hell to run consumer software on. And I do have to run consumer software, whether it's web conferencing or chat or tools for some of my electronics, etc. Sandboxing consumer applications would have allowed me to focus my package management efforts entirely on my development environment

nvr219 4y ago

I still just use apt on debian because I'm a dinosaur apparently.

nickstinemates 4y ago
Using distro-provided package managers make sense to me

brucethemoose2 4y ago

Flatpak is great for self contained apps, but it seems problematic when it has to reach outside the sandbox. I ran into this in VSCode and with CUDA video processing filters, but I'm sure there are more examples. And thats what distro packages are for, I guess.

sirius87 4y ago
Try using Flatseal [1] which is a Flatpak app that helps manage permissions for other Flatpak apps. You can see exactly what permissions are enabled in each app's sandbox and expand/override everything from env vars to filesystem locations you want to enable access to. [1] https://github.com/tchx84/Flatseal https://github.com/tchx84/Flatseal
- brucethemoose2 4y ago
  Yeah, but "install this thing to manually tweak that thing to get those things to work" is so linux, and is exactly what Flatpak is trying to avoid. On the other hand, its a security issue, so I supposed some opt in friction is prudent.
  - sirius87 4y ago
    Flatseal is only a convenience. I think you'll find that the flatpak CLI [1] has commands to do everything Flatseal does, albeit in an arguably unwieldy way. [1] https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-permission-set https://docs.flatpak.org/en/latest/flatpak-command-reference...
- AnIdiotOnTheNet 4y ago
  There are still things Flatseal cannot make work though. For instance, the Wireshark FlatPak is incapable of actually capturing packets.
FengLengshun 4y ago
Yeah, which is why a lot of people in immutable distro uses distrobox. And now, it seems, Nix as well.

NayamAmarshe 4y ago

Flatpak is great! Flathub on the other hand... The app submission process is very convoluted and the documentation is super vague. Snap is much easier to publish and a joy to use with the dashboard and analytics. I hope Flathub improves their submission system and documentation because it's still a mystery to me.

FengLengshun 4y ago

Flatpak is the reason why people who only used Linux because of Steam Deck can just install the app from the app store, and it works well enough. And it's actually pretty cool that Flatpak keep improving, even in the past few years. It's not improving as fast as I'd like (I want VPN apps, Lutris controlling emulators, and Native Host Messaging to be working already) but a lot of issues are being worked on and these days they work well enough. I still prefer to use AUR if I could access it there, and some of the things I do are only available distro-agnostically through Nix or arch distrobox, but Flatpak is absolutely great when it's available and the sandbox isn't in the way.

blendergeek 4y ago

I owned a Librem 5 phone and used it as my daily driver for a few months. During this time I exclusively used Flatpaks for my apps that I installed. After installing about 15-20 apps, the 32 GB of internal storage were completely full and my phone stopped working. I had no clue how huge Flatpak apps are. Even worse, I could not find out which apps to delete. All the space was taken up by excess "runtimes" I don't know or care what a runtime is but I never intentionally installed them. Why are there five different Freedesktop and Gnome runtimes installed? Which app do I delete to get rid of them? I need to be able to easily answer the questions: "Which app(s) do I delete to free up space?" and "how much space will be freed by deleting app X?" On flatpak those questions required dark magic beyond my understanding to answer.

timw4mail 4y ago
This is especially relevant on devices with limited storage, like the Steam Deck. Keeping dependencies with applications does have a lot of advantages, especially for applications that need incompatible versions of the same libraries. But, having every application with its own full set of dependencies seems quite wasteful.
deleted 4y ago
[deleted]
2OEH8eoCRo0 4y ago
Could this be solved by smarter layering? I've read that Flatpaks are just container images under the hood and I'm sure many of those share the same base layers.
- Havoc 4y ago
  Docker does that, but I had understood flatpak to be closer to a VM. i.e. not layered in the same way
- deleted 4y ago
  [deleted]
- akvadrako 4y ago

deleted 4y ago

[deleted]

Kukumber 4y ago

there are no leaders, nobody own the "linux desktop" this is like systemd, bunch of people enforce poorly designed product on everyone linux is becoming a windows bis, and this piss me off

dathinab 4y ago

From a 2023 POV about desktop OS security running things sandboxed is a _strong must have_. Even for well curated applications, through less so. So I'm happy about the general direction here. But last time I looked at flathub (and related topics), I was quite disappointed to a point that I would say they majorly failed this. Now that was quite a while ago. But just the fact that in a non well curated app store you could download applications which where not effectively sandboxed (e.g. used it only for copatibility not sandboxing) in a context which made it look for users like it's sandboxed without any huge red warning label or similar was quite shocking and made me second guess the security competence of the involved developers. Now I hope things are much better by now and I guess I will spend some time to look into it again this weekend. But the reason I write this here isn't because I want to dump on flathub but because I often feel that huge parts of the Linux community seem to be very out of touch when it comes to desktop OS security to a point it makes me worry for the future of desktop Linux. (It's also not just security e.g. some design decisions and defaults of systemd make sense for many Linux use case, but not desktop systems. The Unix permission model doesn't match well to the desktop OS security concerns of today either etc. etc.)

MayeulC 4y ago
I strongly agree. Luckily, a lot of other people do, and the ecosystem is moving towards run-time permissios ("portals") that allow users to confirm access. It does take a while for toolkits to start using them, but AFAIK, as an example, both KDE and GNOME now transparently use portals for the file chooser dialog. It will take more time for everything to move to newer, safer APIs (Wayland, screensharing portal, etc). The situation is much better than it was a few years ago, though. And most frontends now display required permissions; KDE even recently integrated permission management in is system settings. Some portals still need to be devised though, especially for device access (gamepads, webcams, etc).

gnulinux 4y ago

What are people's opinions on Flatpak vs AppImage? I use both (AppImage a lot more so than Flatpak) and I'm not well educated in their differences. I shall research it, but I'm wondering if anyone has some insight to share. Some apps I use (MuseScore) publish their own official .AppImage linux executables which work flawlessly for me, so I cannot abandon AppImage completely. Is it worth it to use both? Is it better to switch to one for everything, along with distro package manager? Thoughts?

badsectoracula 4y ago
AppImage is a more localized approach to Flatpak's "bundle everything" in that instead of trying to have shared libraries across different applications (Flatpak tries to share runtimes), every set of dependencies is local to the application itself. In a way it is kinda like trying to static link everything, though of course it doesn't technically use static linking - and it is really up to the developer what "everything" means (it can still rely on stuff on the underlying OS). Also it only tries to solve the dependency problem, whereas Flatpak tries to do a bunch of other stuff. From a "how things should be" perspective, both are bad IMO (see my other messages here), but from a purely practical perspective based on my experience with trying to use applications using them, AppImage tends to work slightly better and since it is local only to the application, it doesn't pollute the rest of the system. If i had to choose, i'd choose none of them, but if i had to choose between the two then AppImage is by far the most preferable.
- Infernal 4y ago
  I've looked at your other comments here but I can't find elaboration on the bad parts of AppImage. I tend to agree that AppImage is the best of the available options - do you mean that the best solution would be rich system libraries that never break backwards compatibility ala Windows? And since we don't have that, AppImage is the best we can do?
  - badsectoracula 4y ago
    Yes, i meant for the "how things should be", the comments i meant were those backwards compatibility which is the root of the problem and AppImage is just a workaround for it.

neilv 4y ago

Flatpak seems great for users who don't understand or care about open source software platforms, other than that they don't have to pay money for it. A contemporary app store is a spectacularly awesome middleperson business to be in -- both in revenue, and in anti-competitive power.

communism 4y ago

Let's use Red Star OS. It's the best OS in the world. It doesn't have flathub integrated though, unfortunately.

kitsunesoba 4y ago

Potentially stupid question, is there any reason a "simple" .app bundle like has been used on NeXTStep/macOS for decades wouldn't work on Linux? That doesn't take care of sandboxing, but that seems like it'd be better handled by the OS itself rather than the package management system, and it avoids the problems with overhead and integration that come with things like Flatpak and Snap.

AnIdiotOnTheNet 4y ago
> is there any reason a "simple" .app bundle like has been used on NeXTStep/macOS for decades wouldn't work on Linux? Conceptually no, and both GNUStep and RoxFiler/RoxOS did just that. The practical reality though was that Linux Desktop has never had a conception of which pieces are 'add-on' and which are 'base-system', and to the extent there was any collection of components that could be part of the latter they were frequently making breaking changes. Combined with no coherent standard for properly versioning libraries and every fiefdom package repo doing its own thing, and what you're left with is decidedly not a platform. The modern version of Rox AppDirs is AppImage, and it mostly kinda works on most distros. This is sad, but there's just no way out of it as long as the Linux Desktop community continues to reject the very concept of being a platform. Steam initially tried to solve this for games by just dragging along its own Runtime for developers to target, but there were still issues. They've since regrouped and basically just declared Win32 the one true stable runtime ABI for games on Linux. FlatPak just decided that yet-another-package-manager was the way to go and manages a collection of explicitly defined runtimes instead. It works well enough for most use cases.

stcroixx 4y ago

As a daily Linux desktop user for 20+ years I don’t want any kind of App Store at all. Forcing me to interact with one will drive me away for sure.

DeathArrow 4y ago

I'd rather use rpm or deb under Linux. Flatpack means potentially duplicating lots of files.

tristan957 4y ago
Not really. Runtimes have lots of software that is shared. If you are building a run of the mill GTK application, you probably use the GNOME runtime with no extra dependencies.

TheChaplain 4y ago

One thing I really dislike with snap/flatpak is how it breaks connectivity with other parts your system. Example, I run Ubuntu and wanted to use a smartcard for authentication in certain websites. That didn't work because Firefox is in a snap, and can not communicate with the pkcs11 libraries... To solve that I have to scrap Firefox as snap and install as debian package from PPA.

tristan957 4y ago
You could try Flatpak and override some of the defaults. I would probably open an issue with Mozilla since they maintain at least the Flatpak. Not sure about the Snap.
belthesar 4y ago
To some degree, I like this, but the experience for both to allow access is still pretty draconian. I'm not quite sure what the process is for Snap to adjust this (it might require a rebuild?), but I know for Flatpak it's common for folks to say "Use Flatseal to adjust the permissions of what the app has access to" to resolve problems like this. In an ideal world, the application would be Flatpak or Snapcraft aware (or there'd be a middleware to intercept these calls), and ask for access to parts of the system it needs.

class3shock 4y ago

As a non-technical linux user, seeing the ecosystem move towards some sort of standard on this front is wonderful and feels long overdue. Understanding how to install (or uninstall) software is one of greatest pain points for new / non-technical linux users.

tpoacher 4y ago

A benefit of all this crap is that Slackware will probably become cool again.

Brian_K_White 4y ago

Reinventing static binaries but 500x worse.

nikau 4y ago
At least static binaries slip under the radar of vulnerability management tools so you don't have to go through the tedious patching treadmill as often