lol
I think it is practically impossible to fix Linux desktop without reinventing it under a single entity like AOSP or BSDs.
What is this even trying to say?
The topic's interesting and worth discussing, and like many HN posts, the gold seems to be in the comments, so I would be sad to see it removed.
Personally as a user I have found AppImages annoying as there's no install process to get a binary in your PATH and an app launcher icon automatically, and updating them is a manual process usually, and also I always get this FUSE error that I have to google how to fix. Snaps I have found annoying as the applications packaged that way seem to have limitations that the non-snap versions don't have. Flatpak I have no experience with.
All that said, I like the idea of an app being a single file, and if they just provided a standard way for AppImages to register with app launchers and your PATH on first launch, and made them update themselves automatically in a way as seamless as Chrome, and fixed that damn FUSE error, then I'd prefer them.
Though Im not sure what should be the default, as I can think of disadvantages to several alternatives.
It doesn't exactly compare it to the other formats, but still interesting on its own.
[0]: https://blogs.gnome.org/alexl/2017/10/02/on-application-size...
I've never actually worked with snaps before, but they're Canonical's format, somewhat? specific to Ubuntu. I can't say too much about them.
Out of Appimage, snap, and flatpak, flatpak has been the only one after years that seems sane.
It also works really well with atomic desktops tbf.
Fuck snap, fuck snap so hard.
In the space of retro gaming, the DuckStation devs recently had some drama (I think primarily with Arch users) and it resulted in purging the flatpak builds, now there's only an AppImage. I'm sure much righteous rage etc. like this post but against Flatpak or who knows.
Flatpaks are updated at the same time as the system with the GNOME and KDE update GUIs, or in one step from the command line with "flatpak update" (or "sudo dbus-launch flatpak update" when running outside a graphical environment), and I've never run into problems with graphics drivers, though I've admittedly only used them on systems with Intel and AMD GPUs supported by in-tree drivers (but what you're saying makes sense because Flatpak runtimes do bundle user-mode graphics driver components).
While you're not wrong that running Flatpaks requires an external tool, installing them creates both symlinks to wrapper scripts in a common directory that can be added to your PATH and launchable desktop application icons in GNOME and KDE that work no differently than those for applications installed through other means.
The wrapper scripts and symlinks have qualified names, e.g. "io.mpv.Mpv", but that's trivially fixed with an alias or additional symlink if desired.
The only problems I've run into with Flatpaks are limitations due to sandboxing, e.g., the Wireshark Flatpak can't capture packets, which makes it useless in common scenarios.
"--user" is for working with per-user Flatpaks, rather than system-wide Flatpaks, which I've personally never had any reason to use since all my Fedora systems are personal, but it doesn't seem any more confusing than similar switches in other package management systems.
1. providing a build environment for app developers to build something that can run on any distro
Both Flatpak and Snap solve this by providing a SDK; for Snap there is one SDK built out of Ubuntu packages, for Flatpak there is a choice of various options, most built on the Freedesktop.org SDK (Gnome/KDE), plus some independent ones. AppImage provides nothing to solve this problem.
2. providing a runtime environment that conveniently integrates the app on users' desktops
Flatpak and Snap solve this via integration into Gnome Software, KDE Discover and similar UIs; AppImage also solves it in a way by being just a single file that the user clicks on.
3. sandboxing to keep users safe
Flatpak provides sandboxing via Bubblewrap, which works on any Linux distro. Snap provides sandboxing mostly via AppArmor, which requires (last I checked) out-of-tree Linux patches, and only works fully on Ubuntu. AppImage does not provide sandboxing, but the expert user can manually run an AppImage with firejail to sandbox it.
4. a convenient way for users to find applications to install
Flatpak has Flathub as a vendor-independent central app store with volunteer reviewers, and also provides the option to self-host apps conveniently. Snap has Snap Store as a central app store that is run and monetized by Canonical, and it's not possible to set up an independent alternative. AppImages are typically hosted directly by the upstream project, but now there is also an AppImageHub.
5. automated updates
Flatpak and Snap provide this automatically from Flathub/Snap Store; AppImages may be auto-updatable in several different ways but it requires the application author to implement support for it.
This comment needs to be upvoted - the author supports their argument using as evidence a fact I cannot find anywhere on the net.
It's in their title, it's in their conclusion, but it seems to be hallucinated.
[1] https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...
…
> The guys out there with big Che Guevara energy are the real ones building and perpetuating a misery machine fueled by your ideology and nothing else
---
Ha, if the author hadn't mentioned that he was in South Beach on vacation, these lines would still make me think, "Here's a guy who sounds like he's in South Beach but is definitely not from Miami!
This isn't even isolated to the online world. I still remember when I presented my Honours project for University and the "demo" consisted of a few Debian VMs running on my laptop to serve as a facsimile of a compute cluster. An attendee (a respected industry representative) openly and publicly mocked me for not using RHEL or CentOS - despite the fact I'd already explained the implementation was distro-independent.
There's a degree of smug arrogance that's quite pervasive in tech fields, but the desktop Linux community seems to be an outlier even among that. I'm unsure how much of it is lack of social awareness, or neurodivergence, or what, but it's exhausting and it's a big reason why I (also a desktop Linux user) don't really engage in those communities.
> Freedom from the tyranny of package managers is the most exciting thing I've ever heard of as a developer.
The rest are a few shits and no init system beyond the title.
I'm not here to make value judgements lacking even a pony in the race, but the author could've been much more coherent without losing retorical strength. Also, maybe he should consider if his use case is the only use case, but that is going too far.
I'm maintainer to OpenMW and we have specific target audience with specific profile. We have technologies that serve our goals and that we are happy with. We received request for change that we consider undesirable because app image and packet managers have requirements that make them unfit for our purposes. Here is why we chose not to do it and why the alternative is actually perfect for us.
See, much less shits in title and text, no generic attacks against other people and actual information is transmitted.
While there was - an unfortunately failed - push for having ABI compatibility (remember Linux Standard Base?), this has been an issue since Linux has existed
And in customary Linux fashion we had 3 solutions for this in Linux-land, snap which was the ubuntu solution that was slow and buggy - and forced on users in a customary ubuntu fashion way before it was ready, AppImage, which was very rudimentary and involved shipping half the userland, and Flatpak, which seemed to be the best engineered (but far from flawless) of the 3.
And in customary Linux fashion, users decided to just wait this one out.
I think it's great that Valve has taken the time and money to get Flatpak across the finish line.
Btw another thing about Valve - it's really great that they could've went their own way and reimplemented huge chunks of the Linux stack rather than going with what's there, and the associated communities and politics (I'm mainly referring to Wayland, and now Flatpak), but they've decided to go for the popular move and actually bring the existing infrastructure up to a commercial standard.
Purpoting centralisation and hailing it as the resolution of a very legitimate fundamental need, that of freedom, is difficult to follow.
Freedom is not, has never been and will never be easy and comfortable.
I've never attempted to distribute software to Linux. The mere thought of all the distros and package managers always kill any intention I had to do so. That said, the future seems very bright
As far as actually shipping anything goes, it really is terrible for the user the most. Those are the people that end up getting hurt by not being able to navigate package management systems effectively, or break them, etc, and sometimes you might end up helping someone on a system with a package manager you've never used. let alone actually shipping something through one or any of them. But just because someone inside the Ubuntu or Fedora community might be willing to help by way of packaging one's application doesn't necessarily mean those roles existing is helpful in this era to begin with.
hyperionultra•5h ago
raphinou•5h ago
hsbauauvhabzb•5h ago