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 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.
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.
My only experience with Flatpaks is on Fedora Kinoite and Silverblue, so YMMV.
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.
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.
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
There are a bunch of different ways it can be addressed. The biggest overarching problem is package managers, essentially. I think immutable distros will do us all a lot of good, but, really all that is needed is just for particular distributions to gain critical mass as has been happening with Arch over the last few years.
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.
IIRC they aren't based on Flatpak, they existed even before Flatpak gained any traction. I actually do think Steam changed a few things in pressure-vessel to be more similar to Flatpak, but they mostly evolved independently.
The main reason I think they are pouring money into Flatpak is because that is the main way to install applications on SteamOS (that aren't games shipped via Steam).
Well, it sounds pretty funny.
What can be said factually is that the Steam Deck is based on an immutable distro like Bazzite, which is a lot more important than flatpaks themselves. Flats are just a popular way to get apps on such a setup. I see a lot of resistance to them in general, not just in specific individuals or communities on the web, and they're actually pretty solid and do see lots of investment from other companies. SteamOS itself being an immutable distro, Gabe is indeed at least indirectly shitting his yacht money into them.
> 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!
That would require GNU/Linux distros to un-GNU themselves or even almost all Linux software un-everthing. The current Linux desktop architecture is built upon everybody compiling stuff per distro and per version. Everything is built on the assumption that "some people" will choose a subset of packages and versions and curate and do the work again and again to obtain binaries that can only work with that specific curation.
I think it is practically impossible to fix Linux desktop without reinventing it under a single entity like AOSP or BSDs.
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.
This happens at all kinds of scales throughout the community. The worst part ultimately is how many new users/devs get ran off because of this sort of thing in every nook and cranny of it.
> I implemented it in a real operating system. Your toy OS is best left to brain dead enterprise programmers who can't edit a config file to save their lives.
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.
I used that as an example, but, it really isn't the main point of the article. Basically, immutable distros are actually pretty good and worth using. I think that's largely where we'll end up due to all the various terrible user experiences I've seen throughout my years in the Linux community.
I'll keep using Gentoo, sorry not sorry. I agree that if my goal is to ship something like a game it needs to be easy to run or people won't play it, chucking an ebuild at them would not be helpful.
I used the title as an example for how confusingly the rest is written. Imagine alternative post:
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.
I guess I did a really bad job getting my point across because ultimately the OpenMW situation was just used as a convenient example of the kind of tribalism towards technology I see embodied across many subsections of the Linux community. It's not just a single individual or project.
I'd love to do a more technical and less frustrated breakdown of this later - I stand by everything said here, but, I feel like I really failed to get my ideas across.
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.
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.
It's easier to ship a Windows binary and have it run reliably everywhere on Linux then a Linux binary right now.
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 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.
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.
A few years ago I read this small post[0] that talks about Flatpak and it's use of OSTree[1].
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
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.
I'd love to see snap go the way of upstart...
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.
My only experience with Flatpaks is on Fedora Kinoite and Silverblue, so YMMV.
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.
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.
Flatpak gives me one package to install and a little bit of a minor security boundary around the application.
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.
An incredible amount of words used to touch on a very complex and deep problem in a very shallow way.
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.
This is a mass of words to say nothing useful. Why is it on the front page?
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
There are a bunch of different ways it can be addressed. The biggest overarching problem is package managers, essentially. I think immutable distros will do us all a lot of good, but, really all that is needed is just for particular distributions to gain critical mass as has been happening with Arch over the last few years.
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.
For some reason it was hard to read and comprehend.
Just like the title
12 minute read without a clear indication of what it’s about. No thanks.
I want to get background of gabe throwing money to flatpak, no any mention in this article
Steam offers an distro-independent runtime for native Linux games' distribution, which is based on Flatpak [1]
[1] https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...
IIRC they aren't based on Flatpak, they existed even before Flatpak gained any traction. I actually do think Steam changed a few things in pressure-vessel to be more similar to Flatpak, but they mostly evolved independently.
The main reason I think they are pouring money into Flatpak is because that is the main way to install applications on SteamOS (that aren't games shipped via Steam).
It’s not based on Flatpak, it’s based on the same technology of flatpak, which is linux containers/namespaces.
It’s clickbait at best, if not ragebait.
> I want to get background of gabe throwing money to flatpak, no any mention in this article
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.
Well, it sounds pretty funny. What can be said factually is that the Steam Deck is based on an immutable distro like Bazzite, which is a lot more important than flatpaks themselves. Flats are just a popular way to get apps on such a setup. I see a lot of resistance to them in general, not just in specific individuals or communities on the web, and they're actually pretty solid and do see lots of investment from other companies. SteamOS itself being an immutable distro, Gabe is indeed at least indirectly shitting his yacht money into them.
Yeah, but shitting and yachts, brah!
This is why I never go on vacation to South Beach Miami.
> I'd like for it to.
…
> 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!
With your romantic partner, I assume, as the author mentioned for no apparent reason.
This post is extremely verbose, unjustifiably angry and doesn't even talk about the title. I read half of it and I wish I hadn't bothered.
Anything to fight the fragmentation that is for developers on Linux would be great. Packaging and wayland...
That would require GNU/Linux distros to un-GNU themselves or even almost all Linux software un-everthing. The current Linux desktop architecture is built upon everybody compiling stuff per distro and per version. Everything is built on the assumption that "some people" will choose a subset of packages and versions and curate and do the work again and again to obtain binaries that can only work with that specific curation.
I think it is practically impossible to fix Linux desktop without reinventing it under a single entity like AOSP or BSDs.
We need to make a new, better, non-fragmented version of Linux. /s
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.
This happens at all kinds of scales throughout the community. The worst part ultimately is how many new users/devs get ran off because of this sort of thing in every nook and cranny of it.
> I implemented it in a real operating system. Your toy OS is best left to brain dead enterprise programmers who can't edit a config file to save their lives.
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.
I used that as an example, but, it really isn't the main point of the article. Basically, immutable distros are actually pretty good and worth using. I think that's largely where we'll end up due to all the various terrible user experiences I've seen throughout my years in the Linux community.
I'll keep using Gentoo, sorry not sorry. I agree that if my goal is to ship something like a game it needs to be easy to run or people won't play it, chucking an ebuild at them would not be helpful.
appimages are also immutable
I used the title as an example for how confusingly the rest is written. Imagine alternative post:
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.
I guess I did a really bad job getting my point across because ultimately the OpenMW situation was just used as a convenient example of the kind of tribalism towards technology I see embodied across many subsections of the Linux community. It's not just a single individual or project.
I'd love to do a more technical and less frustrated breakdown of this later - I stand by everything said here, but, I feel like I really failed to get my ideas across.
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.
learn to blog , worthlessly painful wall of text
Wow, what word salad.
What is this even trying to say?
I gave up after about a 1/4 It didnt seem to be going anywhere. Is it a shaggy dog story? I didn’t read the punchline.
Imo somebody decided to write a stream-of-consciousness blogpost, and then somebody else posted it here without context.
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.
tl;dr - package manager bad, immutable distro good
Tldr: some dude venting, hope he feels better now.
>As a software engineer, the most important thing in the universe is your ability to actually get people to experience your work.
lol
I think what you're quoting is one of the clearest and most relatable statements in this whole mess of a blog post!
While I don't relate, I am inclined to agree with you here. I stopped reading at: > Period.
The only part that actually makes sense.