Flatpak is not the future (2021)(ludocode.com) |
Flatpak is not the future (2021)(ludocode.com) |
• Both use reverse DNS to globally identify themselves, neither actually verifies DNS ownership.
• Almost everything is a bundle, except for CLI apps. FlatPaks on the other hand are being auto-converted from previous packaging systems.
• Bundles don't have dependencies. In theory they can, but in practice they never do. You depend on macOS/iOS as a unitary platform and bundles expose what the min version they require is.
• There is no update mechanism except the app store. If you want that you need to use something like Sparkle. A tool like Hydraulic Conveyor [1] can create a bundle with integrated Sparkle for your cross platform application without needing a Mac. Likewise no attempt to deduplicate redundant files. Interestingly, if you use the latest MSIX tech on Windows then the OS will deduplicate shared files (including libs) that are bundled with apps, in a transparent manner.
• Sandboxing is optional on macOS. If you don't opt in, you are put inside a relatively weak sandbox that just blocks access to a few folders in your home directory and stops you tampering with other apps/the OS. If you do opt in, you get a PowerBox design that's like what FlatPak is trying with portals. There's no way in the UI to see if an app is sandboxed because it's intended as a vulnerability mitigation and not a way to run untrusted code.
• Both bundles and the binaries within those bundles advertise which version of macOS/iOS they're expecting, and the OS frameworks can change behaviors depending on that for backwards compatibility reasons. It's a bit easier to maintain compatibility with Objective-C APIs than with C++, but still, Apple does it for all their APIs including the C++ ones.
[1] https://hydraulic.dev/ (disclosure: my company)
If you test it with VMs you can check it out for yourself: https://www.ypsidanger.com/wasting-disk-space/
Yes, it means that sometimes they will be ahead on patches, why not.
So at the very least, two systems on your system. Given that there are hacks to share some of your fd.o stuff, let’s say one and a half.
Personally I prefer an environment where people are free to experiment and not be held back by backwards compatibility and opinions. Any utility that can automate backwards compatibility is good imo.
Work backward from that requirement and constraint. Solutions and designs that barely work for the linux desktop will never bring a revolution...
Why not just ship everything with a complete OS? Hell, let's go the whole hog; hardware is also a dependency, it's not just libraries. So let's ship every app as a hardware appliance.
This is not why I use Linux.
And the example given here for GIMP having r/w permission to your home doesn't hold water. The distro-packaged app probably has the same permissions in comparison. At least with Flatpak, to deny it this permission is a simple toggle with Flatseal.
Untrustable apps aren't more trustable because they are delivered as flatpaks.
> The point is the proponent raise the security flag like it is a huge advantage and you could trust anything coming from flathub while it is mostly pixie dusk.
Okay then, as you criticize Flatpaks give us your alternative to a trusted application.
> Untrustable apps aren't more trustable because they are delivered as flatpaks.
Nobody made this claim.
Number of distros? Number of applications?
Ubuntu seems to dwarf other Linux distrobutions in terms of numbers of users. Are you saying more users have Flatpak installed than have Snap installed?
> Ubuntu seems to dwarf other Linux distrobutions in terms of numbers of users.
I'd ask you the same thing. Based on what figures?
> Are you saying more users have Flatpak installed than have Snap installed?
Yes until Ubuntu's Snapcraft store provide download numbers. I can almost swear they used to provide this sometime back but can't see anything like that now.
"Ah, but that was during Covid when a disproportionate amount of people were working from home and a lot of the normal feedback loops weren't running normally. Those were lonely/different times. I'll consider this article accordingly."
It's not really rationale/logical/founded, but that's where my brain kind of initially goes. Do others experience this?
Hypothesis: HN story up-voters are heavily drawn from Free / Open Source Software folks interested in issues that were broadly discussed in "tech" two decades ago (Linux for the desktop!) and are much less broadly discussed today.
I am not criticizing, I am saying it is mostly a moot point. The sandboxing allow a bit of isolation but this it ranks quite poorly in term of actual security benefits for the typical end users use cases.
> Nobody made this claim.
Well, not the authors of flatpak, but yes some did. On medias that many people watch such as youtube videos.
Ranked poorly in what checklist?
> Well, not the authors of flatpak, but yes some did. On medias that many people watch such as youtube videos.
Let's try to stay on topic. The point I made was that, the author's example about Flatpak GIMP doing something unauthorized on your system applies to any package format. The differentiating factor here is that Flatpak/Flatseal allows you to sandbox the application easily and quite effectively if I may add.
Sandboxing can limit a bit the attack surface / scenarios, but that's it.
I'm using it for current Firefox, Zotero, Joplin and two or three more programs, none of which are packaged in Debian (except Firefox, but only the LTS version that doesn't work with all my extensions).
Unless you can offer something better, I'll keep using it.
should be able to just use the mozilla's official build which comes with an auto-updater (and it implements the sandbox itself, so no need for another one on top).
> Zotero
> Joplin
both electron shells. also come with their sandbox already. most rolling release distributions would just package these with a system-provided electron build.
Not sure about the 2 specific apps posted, but web applications packaged as electron apps often do so in order to easily escape the normal browser sandbox without having to prompt for permissions? Or even call into native code which would be impossible from a web app.
I would not think that because an app is electron based, it is sandboxed from your system.
Ideally if you can run the same app under your normal web browser, you'd be fine. I see many people install the Slack app for example, but the web version works just as well within the full browser sandbox.
> both electron shells
Zotero is a XUL application, not Electron. The soon to be released version 7 is a major rewrite and is based on Firefox.
Zotero is one of those cruitual applications where Flatpak is nice. I want it to be self contained. I don't want anything messing it which could lose me weeks of research.
"An unexpected message in the WebGPU IPC framework could lead to a use-after-free and exploitable sandbox escape." [0]
Defense in depth applies here, you definitely want to sandbox any network application as complex as a modern web browser.
Much as we like to personalize them, computers are tools that we use to get things done, and Flatpak is among the better things we have right now for dealing with the awfulness of Linux packages. If a better thing comes in the future I'll use that.
The post is making the author's case against this claim, so I think the title makes sense.
The compromise currently being made here is your security.
Flatpak mixes up packaging and sandboxing, these two imo should not be that close coupled. Especially that it doesn’t even solve the former properly (not sure about the latter).
The Steam Flatpak has been an adventure, to say the least. I added a second SSD just for games that gets automatically mounted on boot, and I gather that having the games installed somewhere outside of steam's /home/ directory was not jiving with flatpak's security model. It took some non-trivial editing (thanks, flatseal) to finally let the Steam flatpak be able to write outside of its own directory and install the games.
I still get occasional weirdness, especially on older games. I wasn't hearing any sound effects on Team Fortress 2, which I eventually discovered was tied to an selinux alert. At last check in, I still can't launch CS:Go, because of some backend problem while trying to play the opening movie...
Same with snaps, although I dislike snaps more.
I found Keepass to be a snap/flatpak once: so many extra layer of complexity for a passwrd manager? No way that's good for security.
I don't think it's caused a problem for me in the last 10 years or more. It may have and just forgotten about it, though. If it happens, it's not a huge problem to fix it.
It has different tradeoffs to the glibc model.
There is a new tool or workflow trying to replace or complement an old one. This new tool tries to solve many different complex problems that the old tool, usually designed decades ago, doesn't solve well in this the current world. To do so, obviously, some sort of compromise is required, the new tool won't do certain things that the old tool used to do, but in exchange of that it will do a lot of new things that many users really want. However this small crowd is really pissed by this, without understanding that there is no holly grail solution and some sort of compromise is always required. Additionally, as it's natural with any new technology, the very first incarnations of the new technology are not very mature and there is a lot to polish, a lot of tooling missing, and a chicken and egg problem of not enough users to drive its take off. And the small crowd will use all this as much as they can to try to prevent the world from moving on.
However, as time passes, the new tool starts becoming more mature, the obvious shortcomings get fixed, and all the new possibilities that the tool enables start to really shine. And while the initial compromise will always remain, the majority of users realize that the tradeoff was worth it.
This has happened with Systemd, it's starting to happen with Wayland, and I believe it will happen with Flatpak was well. We'll see.
Eg, we make this: https://overte.org/
We're currently using AppImage because that was the first thing that worked for us, but most of the reasons are the same either way: We want to spend time developing the software, and that means it's hard to justify packaging every release for a dozen distributions. And I'd say nobody particularly wants to do it.
We also expect our users to keep reasonably up to date, not whenever it's convenient to the distribution. Code changes can change the networking protocol, and some of those can require everyone to upgrade.
So at least to me it makes perfect sense to package some kinds of applications this way. Maybe not KDE's calculator, but definitely things like games and tools with specialized markets, where it may be difficult to find people wanting to do the work of packaging them for a distribution.
It's too bad this hasn't been standard practice for the past 30 years!
Like my phone that turns its ring volume to 100% every few days. It’s not a rogue Shortcut, cuz Shortcuts doesn’t even have that feature (only Media volume). No one will ever know why that occurs, because no one understands the whole stack from top to bottom. And in a way that’s the best case scenario with such a walled garden controlled by one “benevolent” dictator. Using all these packaging frameworks and libraries at once, no one will ever be able to make sense of some kinds of problems, because everyone is cargo-culting some large section of this stack of complexity, because a single person couldn’t hope to make sense of everything.
"Developers are lazy" -> No, no user ever wants to debug dependency issues, and developers can't get rid of dependency issues. This feels like a repeat of the Rust debates where C developers kept complaining that good developers just don't have memory errors. Okay whatever you're very talented, congratulations; but most software isn't written by people who can reliably support multiple distros and lowering the skill requirements to maintain software is good actually because I use hobby projects all the time. Even outside of hobby communities, GoG's Linux installer is so borked that half of the time it's easier to install the Windows versions of the games and run them through Wine (because then you can use Bottles which provides dependency isolation). And I am completely convinced that dependency management is the problem -- Flatpak apps don't have these issues, at least not nearly as many.
I'm not saying everything should be a Flatpak, but certainly at the very least most Linux games should be, anything that's graphical that isn't being distributed through an official package manager is a good candidate to at least consider Flatpak. I'm always grateful when I can install a graphical app through Flatpak instead of AUR.
Is it the future? Flatpak critics spend a lot of time bashing Flatpak and very little time proposing equivalent fixes or acknowledging why Flatpak exists in the first place. If those issues were solved and the solutions popularized on mainline distros, maybe Flatpak wouldn't be the future. But I'm not holding my breath. This article proposes GoG's system as an alternative and says the existing problems are minor and easy to solve. 2 years later, I have literally never gotten a GoG native Linux installer to run without problems on the Steam deck.
I'm not even saying it has to Flatpak, but whatever system you want to propose (Snap, AppImage, whatever) very clearly dependency isolation is better for end users and results in fewer bugs. "It takes up too much space" just isn't a real critique when the alternative being proposed almost universally fails to run on my hardware.
Like the fake security feeling people have using flatpak because of the advertised sandboxing, the size of the software being downloaded or the slower startup of applications.
Worth reading:
It only uses the disk space it must, AND every app only accesses the dependencies it needs. It's the best of all worlds (except for the learning curve, which is of course why it's considered "arcane").
As a use-case where its capabilities came in handy just today, I had some old files I encrypted with gpg1 which didn't cleanly decrypt with gpg2. Accessing the old version of gpg, just for this one console and this one time for this one task, was a one-liner: "nix-shell -p gnupg1orig". With that one command it installed everything that version required, and put its executables at the front of my PATH in my shell, so I was able to do the decryption. When I exit, that stuff will get collected on the next garbage collection.
> This is the most complicated and brittle way to implement this. It’s also not at all how other sandboxed platforms work. If I want file access permissions on Android, I don’t just try to open a file with the Java File API and expect it to magically prompt the user. I have to call Android-specific APIs to request permissions first. iOS is the same. So why shouldn’t I be able to just call flatpak_request_permission(PERMISSION) and get a callback when the user approves or declines?
On macOS you try to open a file and it’s handled transparently. “iOS is the same” also could use a citation (I don't recall off hand if it is, and kinda doubt it based on the macOS behavior, so I feel a citation is appropriate). I’m slightly confused why the author is comparing Linux desktop with mobile rather than existing desktop implementations of sandboxing… feels a tad disingenuous.
In general I think all permission dialogs should be reframed as selection or confirmation dialogs.
• Open file dialog -> grants permission to read that file.
• Open file for edit dialog -> grants permission to read/write that file.
• Save as -> grants permission to read/write that file.
• Select which wifi network to connect to -> grants permission to use internet
• Do you want to display events in your neighborhood? -> grants permission to location data
• Select which camera & mic to use for this call -> grants permission to record video & audio
--
I have to say though, apart from that permissions thing, the author makes a lot of good points I hadn't realized before.
Guess what Excel and Photoshop will want if they were to ever port their software to Linux.
The other part is library developers need to aim for backward compatibility so apps don't need to care so much about what specific version they're using.
I'd love that, but I'm not even sure how it would work, I don't want it via walled-garden app store where you basically have to target it as an extra platform, because of dealing with those APIs... It would need to somehow just sort of slot into Unix, and if you didn't have it 'enabled' on the system it would just plough on uncontrolled as it does today.
What's the story or usual recommended practice on NixOS? Seems like the overlap with security-minder types would be quite high, and if you did use something like Flatpak wouldn't that interfere with Nix's own management? (Or at least not use it.) (I didn't learn much from the Flatpak Nix wiki page.)
Snaps are only available in the default install in Ubuntu and Flatpaks is not in the default install of other Ubuntu-based distros [0]. Even other distros have neither in their default installs.
It is not the same thing with macOS with its first party installation methods provided by Apple that just works.
[0] https://www.omgubuntu.co.uk/2023/02/ubuntu-flavors-no-flatpa...
The drivers also never work properly. I've attempted to use several official game flatpaks, and have run into various forms of crashes (including the entire system stalling).
Instead of having some minimal set of conventions of where things are supposed to be stored, instead of allowing static libraries to actually work it seems that the solution is to now include the whole system instead. After all storage is cheap right?.
- Not being oriented to also CLI apps.
Apart from that, I like it for its convenience and I think it will be the future (or a similar approach). The reason for my thinking that is that, putting myself in the shoes of a distro maintainer, I can see the appeal and benefit of "isolating" the system packages and libraries from the packages installed by the user. I find it similar to the great relief that Docker brought back in the day when reduced the system administration overhead as it reduces the amount of moving parts on the functioning of an app.
To name an example: steam is a nightmare, even though they try their best to host and ship as many libraries from ubuntu as possible. The experience with botched steam installations shifted my perspective a bit, and I think for these desktop use cases, especially of proprietary software, AppImages are the way to go.
It's the easiest way to guarantee behavior and stability of software, while not putting the virtualization burden upon the end users.
- need to move the x.appimage somewhere in your $PATH
- need to create an alias like nvim.appimage -> nvim
- no way to automatically update
- the application isn't listed in your application list on ubuntu
On the other hand `sudo snap install nvim --classic` brings me all of the above without any work from me
Handles making it executable, automatic upgrades, no need to move it to your $PATH, and adds the application to your app list.
Only other thing you might want to do is symlink a friendly name for cli
If AppImages were actually directories, like they are in macOS, I could at least run duperemove to fix the disk space issue on BTRFS, but with full images that become a lot harder.
Ease of use, RAM usage, startup time and security should all rank higher than disk space.
It could also do with an update mechanism.
* i know they can technically be updated but i really have no idea how. would be cool to see a de-facto solution similar to sparkle[0] on mac
* i use appimagelauncher[1] to integrate with my menus etc but sometimes it works and sometimes it doesn't? i haven't really figured out the rhyme or reason
They also assume that having distributions and end users produce a multi-MB security policy written in an arcane, poorly-documented policy language will somehow lead to a correctly configured sandbox.
I greatly prefer the OpenBSD approach, where the upstream application developer builds calls to things like pledge(2) into their program, and then tests that it behaves correctly before releasing it:
I think flatpak could use a built in notification method of some sort to add exceptions to paths it's allowing access to, though I imagine it would still require effort on the application's part which maybe would never happen (especially with steam using its own custom file browser)
>At last check in, I still can't launch CS:Go, because of some backend problem while trying to play the opening movie
I've had no such issue (and it's worth noting the -novid launch option), but regardless valve still treats Linux as a second class platform despite the steam deck which is fairly disappointing.
The issue I do have is that the new overlay will crash cs:go in openGL mode and Vulkan mode has massive stutters.
I'm optimistic CS2 will be better, but to be determined.
Following this, it seems like there should be an XDG standard for sandboxing which distros are free to implement whichever way they feel is best. With that, Linux app packaging solutions need only worry about playing nice with that spec.
Why do you assume that such people don't understand this? Sometimes those compromises mean that the tool can no longer accomplish something important to some users.
I don't think that being upset that software has become less useful is terribly unreasonable or hard to understand.
> Additionally, as it's natural with any new technology, the very first incarnations of the new technology are not very mature and there is a lot to polish, a lot of tooling missing
And while the software is in that state, it shouldn't be forced on anyone. It's not unreasonable for people to want to use software that actually works well in the present.
This sort of narrative is common cope from developers who make substandard software. Ego blinds them to their own limitations so they blame the users. Just look at the difference between Pulseaudio and Pipewire. Pulseaudio is widely hated and the developers said it's because people just hate new things. But Pipewire is newer and people love it, the supposed reflexive hate for new things doesn't manifest for Pipewire. So what's the difference? Pipewire does what it's meant to and doesn't cause problems for people. Pulseaudio caused endless grief, that's why people hated it. SystemD earned ire by causing people problems; had it not done that most users never would have realized they were using it in the first place.
In case of Flatpak we have a so so much better solution in the linux space (nix) that I feel that it is blindly going in the wrong direction. Package management is hard, but it finally has a solution. One might disagree with the implementation of Nix, but the idea is sound, and this is the first thing ever that doesn’t just push it a layer down, but actually solves the problem. The linux world should definitely ride this moment similarly to git’s success back then.
Please change, HN.
I make few exceptions, none for snaps and flatpacks so far.
I installed Firefox from the tar.bz2 on their site, as I did with Windows before my switch to Linux in 2009. It auto updates and so far it's OK. I'm on Debian 11, I'll upgrade to 12 to stay more current.
Other exceptions: docker containers for redis and the PostgreSQL versions I have to run for compatibility with the production servers of my customers. I use asdf for that sometimes and also for languages, of course. We can't rely on the versions coming with distros.
If I'd really have to use Overte I would do an exception for that too.
It's less user friendly but on the good side you can use that to build pull requests or arbitrary commits.
One reason is that big applications can have many dependencies, and once in a while I find something dlopens something from the host filesystem, finds something incompatible and crashes. So I really want my stuff to run in a sandbox where I know exactly what it's loading and there are no surprises.
The other is that we've got a complex system under development and there may well be security exploits. I like the idea of that if somebody breaks our code it's going to take some work to get to the user still.
https://docs.flatpak.org/en/latest/debugging.html
An average user would just say that app is shit, linux is shit, I go back to windows!
- You can use `flatpak install --include-sdk --include-debug THE-APP` to install the SDK and debug info for an app - Then `flatpak-coredumpctl -m MATCH THE-APP` will use coredumpctl to open the matching coredump inside the corresponding SDK's gdb
The few times I've run into Flatpak crashes, they're architecture problems that would have been present in any version of the app, so I'd be doing that work regardless. They're harder to debug in Flatpak, but also heck debugging crashes every time I try to install a piece of software. I'll happily take the added complexity of needing to boot a shell into the sandbox if it means I get to debug 50% fewer problems (and in practice Flatpak tends to reduce my number of issues by way more than 50%).
The average user is never going to open a debugger, minimizing the number of crashes is more important for that user than making the crashes easier to debug.
That's actually interesting. For me, GoG's Linux installers have never given me a lick of trouble on Debian.
It's frustrating because Arch is generally more stable for me than Debian, but you can kind of see the niche status of the OS play out whenever you're working with a package that wasn't packaged by the Arch team. When developers have to maintain packages for multiple distros, my experience has been that usually the popular ones get serviced first and the niche ones get serviced last.
1) This is probably too much to ask of people. 2) This still leaves behind decades of software that would still need to be built in the future and would thus still need something like the "scaffolding".
But again, the fundamental idea is really just this: Treat builds and runs as pure functions. Every other advantage derives directly from that principle. If someone else can figure out how to do this as simple as possible, I'm all for it! In the meantime, I think every developer should read Eelco's thesis paper on this idea: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf
Of course, the OTHER way to solve this problem is just to statically-compile everything, leading to an explosion of disk-space usage. And even then, you wouldn't get guaranteed rebuilds.
Devs can keep arguing about what the "best" solution is, but Flatpak already won this debate by its ease of use.
If NIX had the same workflow as Flatpak, it would be a clear contender.
I see this argument all the time with Linux, what is the best vs what is usable. With gatekeeping nerds clinging to whatever is the hardest to use, so they can feel special, vs everyone else using what is easy.
Which is the most important one. "It's the best at everything except the thing that it needs to be good at, where it's one of the worst" is not a good marketing pitch.
Matrix algebra isn't easy either. Guess ML will never be a success! It's literally failing at the thing it needs to be good at!
The person you're replying to is quite mistaken.
I don't believe Snap natively offers any deduplication. Snap also uses compression (squashfs as far as I can tell) so deduplicating filesystems are equally powerless.
Flatpak has its own deduplication system (that will confuse df/du if you try to run it and often leads to confusion about download time). Through tools like https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker/ you can check how effective the dedup process on Flatpak is. On my machine, Flatpak is using 10.5GB of disk space, but reports 13.75GB of files. Running duperemove on /var/lib/flatpak found two identical extents (belonging to cached files) that didn't get deduplicated already.
As for why they couldn't be unpacked: I don't know. They'd take up more disk space, I suppose. Many standard Linux file systems don't have any form of deduplication mechanism built in, so I'm not sure what the balance would be. I would appreciate the ability to decompress AppImages/snaps without writing custom wrappers for them, but if you're on ext4 like many (most?) Linux users, you'll only see the downsides.
I'll rephrase: while software is in that state, it shouldn't be released.
https://discourse.nixos.org/t/2022-nix-survey-results/18983
Have you worked at a startup? Do you know what a “hockey stick” growth curve looks like? Because Nix may be on the cusp of one.
Its package repo (check out search.nixos.org) has more packages that are ready to download and run than any other Linux distro, while having fewer maintainers than most distros. If nothing else, this alone speaks to the power of deterministic builds and runs. When something doesn’t randomly break, turns out that it needs much lower maintenance and thus fewer people…
The funny thing about NixOS (and I heard about this before I experienced it, which I found intriguing at the time and which I can now say is very real) is that the second you "grok" it... you will want it on ALL of your machines
So when I dove in, I said "I'm going to figure out how this works and then simplify it." Unfortunately, the closest I've come to that so far (and this is partially due to... having a 2 year old and working at a startup) is this commandline wrapper that makes most of what I need Nix to do, easy: https://github.com/pmarreck/ixnay
I still don't understand the entirety of the Nix language, but this is an excellent, excellent interactive tour: https://nixcloud.io/tour/
None of my apps crashes except one. And that is a piece of shit of a proprietary app that is not packaged by the distro maintainers: Microsoft Edge.
Strong disagree, my experience is that app crashes are extremely common on Linux if you step outside of official repositories; I say this as someone who literally only runs Linux and nothing else. I'm not necessarily saying Windows is better but... it's not like nothing ever breaks. It's impressive how well developers are able to hold it all together, but my experience is that Linux systems are fragile the moment anyone stops actively managing the dependencies and putting in the work to compile everything to match.
> that is not packaged by the distro maintainers
It is not feasible or scalable for Linux for every single app (even every Open Source app) to be distributed and managed by the distro maintainers. And this is what I'm getting at with dependency isolation -- the vast majority of crashes and bugs I see on Linux (and I mean by a massive margin) are all due to dependency mismatches and shared dependencies. A lot of Linux software is generally stable if the system looks like what it's expecting the system to look like. But if you're not going through an official repository where a bunch of volunteers are putting in the work to make it consistent, then it very often doesn't look like what developers expect.
This is why people run games through Wine instead of using the Linux versions -- it's not because it's impossible to build good native versions, it's because if they don't use the Linux version they can use Bottles. That's the biggest reason; it's about the dependency isolation.
Most apps that I have been getting from third party repo were not included because most majors distros are us projects that can't ship patent encumbered libs/apps, not because distros mainteners couldn't package them.
> This is why people run games through Wine instead of using the Linux versions
No, the main reason is that the linux versions do not exist for the most part because devs don't want to bother supporting a non uniform software platform that represent a tiny fraction of their market.
They do? When I have a choice between the two, I'll take the Linux version every time.
This is not "Linux", it's users who mess around with (and ultimately break) dependencies in order to get the latest version of programs at any cost.
If one uses, say, an Ubuntu version and 3rd party repositories for that version only, they're not going to get any dependency issue, since all the programs will share the same library versions (dependency bugs do happen once in a long while, but they're rare, and they're exceptions).
At this point, I'm also tired of convincing others that linux package management is broken beyond repair. Until you experience my pain, you won't be convinced. I understand many people will never be able to sympathize with my pain but all I can truthfully and honestly say is that I'm a very experienced GNU/linux user, I used all kinds of distros from Ubuntu to Fedora to Arch to Gentoo and, no, it's all a complete and utter mess when it comes to dependency management. I end up spending hours every month fixing broken versions. The sweet spot is using pacman for very basic things, and AppImage for everything else. I don't care about memory efficiency, I want `MuseScore4.appimage` to contain everything about the app, I want it to behave exactly the same every single time I click on it. No, I don't tolerate even the slightest behavior difference, I do not want glibc to upgrade from x.y.z.t to x.y.z.t+1 because it causes insanity when t+1 causes a behavior change in some random software synthesizer I happen to use. I know that this probably doesn't make sense to 99% of users, but maybe I have a special case. Case in point, in the year 2023 while trying to ship a lot of work I'm producing, a single update broke tons of my workflows, and I finally decided that anything not frozen in AppImage is cursed. If it doesn't work you, I respect your patience and expertise, I just hope some people can understand the pain other users go through.
I have a degree in CS, I write code full time, I manage linux containers in my day job, and I still can't manage the mess I have at home in my local Ubuntu/Arch installs. I don't know how people who don't know how to code do, but all I know is that I'm done spending hours at a time on fixing glibc at this point. I just want to work on my hobbies, thank you very much.
EDIT: And before people come here, no, OSX and Windows are even worse. I won't consider using them either.
I use AppImage for the sort of software that won't get packaged (proprietary or obscure) and zypper for pretty much everything else (excepting a few programs I build myself due to reasons.)
The default Debian tools, apt and apt-get (and related tools, like gdebi/aptitude) won't put the system in an inconsistent state, unless the user forces them to do so. Dpkg will do, which I suspect is the tool you're using.
Even when one adds a repository with incompatible package versions (say, the system is Focal and the repository distribution is Mantic), the upgrade will stop before upgrading the packages.
What's happening is that you're forcing broken dependencies, likely to chase the "latest and greatest versions", then complaining that the package manager is broken.
I generally stick to the distro repos exactly because external software is a pain to run, with Flatpak as a fallback for applications not packaged in any repo. More and more third party applications are being compiled statically, though, which has solved a lot of issues for me when it comes to these externally managed programs (though it also causes annoying security issues).
We're talking about Linux users here, not your run-of-the-mill generic end user. If you download an AppImage, you're most likely an advanced computer user. Maybe you don't download media yourself, but you'll probably have huge node_modules/cargo/venv/maven directories slowly clogging up your drive.
AppImages aren't easy to use (you can't double click them like on Windows and they all have to provide a mechanisms of their own to register a shortcut in the system menu), their startup time is affected by the compression tying all the files together, the security is no better than any other application (worse, in fact, because when I update my system's openssl client I'll still need to wait for every AppImage program to publish a security update with the patches included, which usually takes months or longer). I don't know about RAM usage, but the duplicate libraries being loaded by the executables will cause at least a few megabytes of unnecessary RAM usage.
AppImage is mostly there to help the developer spread the software. The benefit for the user is "at least there's something I can run, I guess".
Uh, but that's exactly how they work. What file manager are you using them that doesn't recognize them? Also you can just chmod+x them and execute them.
As for their size, my XPS13 has a 250GB SSD too, not easily upgradable, but AppImages just aren't a significant burden to me. Once a month or so I move downloaded media to my NAS, but all of my AppImage applications together add up to maybe 15GB or so, the redundancy in them is really the least of my concerns.
Dolphin does seem to support AppImages natively and will execute the file (after clicking through two security prompts). I guess KDE users are AppImage's target audience, then?
There's a whole range of tiny/small computers that run Linux and that absolutely don't have hundreds of GBs of storage space.
I mean... citation needed :) I run Arch and I am not dismissing at all the frankly incredible work that the Arch maintainers do bundling software and making it available. It is a miracle that it works as well as it does, to the point where my Arch systems are often more stable than non-rolling-release distros I occasionally run. Fantastic work by the maintainers.
But it's not a solved problem and I can only imagine how much effort and work is getting burned to keep it running as smoothly as it does. Step outside of the official Arch repos into AUR or (heaven forbid) into completely separate ecosystems and all of those problems come back. And I don't want to ignore the software outside of the repos, I didn't start using Linux so that I would be beholden to some kind of "official" distro app store.
There are tons of Open Source applications with no legal barriers in place that are not getting packaged in official repositories for no other reason than that they're niche and there is a lot of software to package and not enough people to do package it all.
And of course any non-OS games are also going to run into these problems. That's a problem that distro maintainers can't solve, it doesn't matter how much work they put into it, they can't repackage source-available or closed source software. "People shouldn't ship that" -> but they do :) So ideally we'd be able to handle that without descending into dependency hell.
> No, the main reason is that the linux versions do not exist for the most part
I'm not talking about games where the Linux versions don't exist, I'm explaining why I'm currently running the Windows version of Inscryption on my Deck even though it has a native Linux port. Do I want to be doing that? No, of course not. But the Linux version doesn't boot, most likely because there's some dependency chain missing or an environment variable is wrong, or... I don't know, I don't want to crawl through forums and debug that myself, I want to play the game.
And I'm not alone in that, it is common advice on Linux to use Proton instead of Linux native versions. And that stinks, it's bad for the ecosystem and it's bad for users and it's bad for games. But the Linux versions have so many more problems because they make assumptions about the underlying system that turn out not to be true. Of course Windows builds also have those problems, but the difference is that they run in a containerized environment that gives them the system they expect.
Again, I truthfully experienced all of this and my day job is to handle things like this, so I personally know that it's neither of those things.
What's happening is a variety of issues (not one) and it can be anything from package maintainer not knowing whether a version is incompatible with their package, to dependency being noted wrong in package. For example, if I write package X and depend on numpy, but don't realize numpy 2.24 breaks it, Debian will happily accept the update breaking my package for users. It's the maintainer's fault but ultimately if the OS didn't upgrade dependencies for every program it would have worked. Which is why freezing dependencies is the way to go in terms of stability.
There are countlessly other scenarios, for example using a program compiled outside of Debian and dyn linking then Debian upgrading the dependency not knowing about the 3rd party program. It's all a trap for broken software.
Flibitijibibo has some good commentary on when to dynamically/statically link libraries, leaning towards statically linking dependencies when possible to avoid relying on the OS too much. Coincidentally, Flibitijibibo's Linux ports are some of the few where I can just download them and be confident that they're likely going to work out of the box with zero troubleshooting.
It is a general comment about Linux. Arch Linux is a major distro, if people using Arch can't run Linux software using existing packaging systems, the packaging systems are broken.
If the natural result of existing packaging systems is that software only works on distros like Ubuntu and Fedora, then that is very much a general Linux problem.