Finally - I think the biggest issue of Linux today is the inability to ship a binary and have it just work across distros.
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.
I wish you were joking, but one of the giant companies we work with as a supplier suggested we switch to the Windows version of their (desktop) software, running it under Wine.
In fact they told us they have plans to discountinue the true native Linux version, and going forward. they're going to package their Windows version with their version of Wine as the 'native' Linux solution.
This is a company that has both tremendous resources and deep Linux expertise.
I've been wondering if a linux GUI applucation can be made by compiling wine libraries into a linux ELF executable, skipping the EXE format. Do I still need the wine supporting extra processes or is this shippable?
I know I'm probably going to get some shit for this, but, this actually is one of the reasons I like using Rust. I know, I know, but, the fact that cargo can be used as a package manager universally across distros (and operating systems!) is a pretty huge boon to me as a developer.
Zero (Linux) package manager involvement and onerous rules.
I mean it's a general sign of the times across all of computing that problems keep getting solved wrong at all levels of the stack, and since the low level implementation can't be relied on for some reason, an implementation gets stacked on top.
More specifically to your case, Linux package management is an unmitigated disaster when it comes to development. Having to have root access just to install a few headers of whatever version your distro happens to ship with, have some scripts discover said versions (too bad if they are not the ones you wanted).
Every single professional (for profit model) piece of software tends to carry half the userland with it. Steam, Spotify etc..
Besides, Rust isn't big on the concept of dynamic libraries anyways, which once again, I don't think is a purely good thing, but there are a lot of arguments can be made pro or contra.
Let's just say it's a devil we know, which is more than can be said about a lot of other approaches.
I am actually interested in an explainer of the technical differences between AppImage and Flatpak and Snap and why one is better than the others, but I didn't find it here.
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.
I just start AppImages from the command line and put them in my /home/$username/bin that seems to take care of most of the annoying edge cases. Snaps are ridiculously hostile abusing the mount system and polluting all kinds of places where they have no business going, I've completely purged the whole snap subsystem from my machine. Flatpak I've managed to avoid so far.
I unpack them because the app runs faster, no container/fs problems, and I use apps where I want to access the files in the app. Kicad in particular has a load of component files that I always want to copy from /usr/lib into each project so that the project is fully self contained and in a nicer way than the way kicad does it itself.
freecad has a problem where it uses python, and python3 defaults to shitting turds (pycache directories) everywhere it's executed. There is a way to tell python not to do that, but that mechanism is not possible when the app is an appimage. But is possible if the appimage is unpacked.
It's a simple, but totally manual process to unpack and integrate into the desktop fully so that file types autolaunch the app and displays the icon in the file manager. I started to write a script to automate it but there is just enough variation in the way appimages are constructed that it's annoying to try to script even though it's pretty easy to do manually.
If you look at Apple / Google mobile platforms, these are the requirements for modern desktop apps:
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.
AppImages are just a portable packaging format while Flatpaks and Snaps also offer sandboxing, and Flatpak is more distro-independent than Snap which is developed by Canonical. Ubuntu used to be extremely pushy about Snap which turned me off and now Flatpak just seems a lot more popular.
Ubuntu is still pushing snap - they still kept the practice of silently replacing apt packages with snaps, I think the default Firefox is still a snap, and so is node.
The Ubuntu defaultism still puzzles me to this day... Canonical has been shown to subject users to its horrible science experiments pushing broken software on its users sometimes even persisting for half a decade or more (see pulseaudio, it was shipped in ubuntu for literal years, and it never worked...). Snap is their latest science experiment.
Though Im not sure what should be the default, as I can think of disadvantages to several alternatives.
I've generally preferred AppImages because they're just a single-file (in appearance) binary I can put in a ~/bin folder and run. Flatpaks require using an external tool to run them, and update them, and there's confusion whether you need the --user flag or not, and after every graphics driver update on the main OS you need to upgrade all the flatpaks again... It's so much of a hassle. The permissions isolation is nice in theory but firejail works for that too, arguably better in some ways.
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.
Generally speaking, between flatpaks and appimages, flatpaks are actually a lot easier to make and get out to people. The thing you're talking about here, not being able to easily run or get them, is kinda the core issue with appimages.
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.
What I got is that the author is the right kind of developer, talented, producing something, and serving the people, and some other people in the linux community are trying to dim the shine of his light. The key sentence from the piece is:
> 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.
This is definitely a rant, albeit a derserved one.
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
Probably (or at least usually) there is a sentence or phrase in the text which represents what the article is actually saying. I tried to find it so we could use it as the title per https://news.ycombinator.com/newsguidelines.html, but failed. Anybody?
While TFA is a bit of a disorganised stream of consciousness, I can definitely empathise with the author on the majority of their points. The desktop Linux community is full of people that are, frankly, completely insufferable.
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.
I understand the frustration. I have the uttermost reverence for distro maintainers and I love distro repos. I like that my OS is a consistent and well thought suite of aligned tools mindfully put together by a collective that knows what they are doing and test that it all fits and plays nice much better than I do. Please stop treating these awesome people like some kind of authoritarian ogres. I am grateful for flatpaks too. I understand that tools seldomly need to be tightly coupled to work together well, and that it does come at a cost, just as sandboxing does. I respect developers who do not package anything else. When I need a flatpak, I install it. Finally, it is also amazing that we have AppImages. Some tools just work perfectly well or well enough with limited integration capabilities in multiple diverse ecosystems. Why does everything have to be installable? So, if I want to use a tool I will get it however the developer decided to distribute it, trust that they have a good reason to do it the way they do it, and if I open my mouth it will be to say thanks, instead of being lame about someone's way of putting an effort for me to get a great product without asking for anything in return not being what I think most convenient. For me.
Wayland, Flatpak and Gnome are dead set on trying to turn my computer into a weird oversized smartphone. AppImage tries to recreate the "just download it and run" experience that Windows and macOS have, but hasn't quite gotten there yet (AppImages will sometimes just randomly link to system-wide libraries anyway, forgetting to bundle dependencies).
Meh. I guess I'll check back in some years, as it always goes.
63 comments
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.
In fact they told us they have plans to discountinue the true native Linux version, and going forward. they're going to package their Windows version with their version of Wine as the 'native' Linux solution.
This is a company that has both tremendous resources and deep Linux expertise.
Zero (Linux) package manager involvement and onerous rules.
More specifically to your case, Linux package management is an unmitigated disaster when it comes to development. Having to have root access just to install a few headers of whatever version your distro happens to ship with, have some scripts discover said versions (too bad if they are not the ones you wanted).
Every single professional (for profit model) piece of software tends to carry half the userland with it. Steam, Spotify etc..
Besides, Rust isn't big on the concept of dynamic libraries anyways, which once again, I don't think is a purely good thing, but there are a lot of arguments can be made pro or contra.
Let's just say it's a devil we know, which is more than can be said about a lot of other approaches.
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.
freecad has a problem where it uses python, and python3 defaults to shitting turds (pycache directories) everywhere it's executed. There is a way to tell python not to do that, but that mechanism is not possible when the app is an appimage. But is possible if the appimage is unpacked.
It's a simple, but totally manual process to unpack and integrate into the desktop fully so that file types autolaunch the app and displays the icon in the file manager. I started to write a script to automate it but there is just enough variation in the way appimages are constructed that it's annoying to try to script even though it's pretty easy to do manually.
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.
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...
[1]: https://docs.flatpak.org/en/latest/under-the-hood.html
Though Im not sure what should be the default, as I can think of disadvantages to several alternatives.
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.
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.
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.
> 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'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
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.
What is this even trying to say?
>As a software engineer, the most important thing in the universe is your ability to actually get people to experience your work.
lol