AppImage for 2.9.0 and later

[probonopd]

The release notes for PrusaSlicer 2.8.1 state

PrusaSlicer now depends on WebKit library, which greatly complicates its distribution. (...) The AppImage made sense when it could be used in the "bundle what you need, distribute a single file" way, but having to distribute several different AppImages and maintaining the required build infrastructure (and still worrying about what needs to be updated when some Linux distribution update is released) means burning time that we would much rather invest into actual work on PrusaSlicer.

tl;dr: By using a static runtime and by bundling all dependencies inside the AppImage, the stated goals can be achieved at the cost of a larger download size (although not as extreme as Flatpak where all of GNOME gets downloaded even on non-GNOME systems). A version for testing is linked below.

According to the release notes for PrusaSlicer 2.9.0-alpha1, Prusa is considering to move away from the AppImage format for Linux, and is anticipating that this change might not be welcomed by all users. According to the release notes, Prusa would want a PrusaSlicer AppImage to:

• Bundle all necessary dependencies, including libraries such as glibc or webkit. - ✅ DONE by bundling all dependencies of the application rather than just the depencencies that cannot be reasonably assumed to be part of each target system
• Not require specific versions of system libraries, such as libfuse, to be present on the target system. - ✅ DONE by using a static AppImage runtime that does not use libfuse from the system, and bundling all dependencies of the application
• Be able to run on multiple Linux distributions without requiring extensive maintenance. - ✅ DONE by the above
• Allow for easy building and distribution of multiple architectures, such as x86_64 and aarch64. - ✅ DONE by using tooling that supports these architectures (e.g., Docker)
• Not require building on older distributions for compatibility reasons. - ✅ DONE by bundling all dependencies of the application
• Provide a seamless user experience, including desktop integration and application updates. - (☑️) Done by PrusaSlicer since 2.4. Alternatively, users can use an optional desktop integration tool (but not desirable in all cases, see below)
• Offer a sandboxing mechanism to control application permissions. - (☑️) OPTIONAL using a third party sandbox (but not desirable in all cases, see below)

Version for testing

https://github.com/probonopd/PrusaSlicer.AppImage/releases/latest

So far I have tested the AppImage on

• Windows 11 with WSL2 in a Debian environment ✅
• Ubuntu Studio 20.04.3 LTS (Focal Fossa) on hardware with Intel graphics ✅
• Fedora Linux 38 (KDE Plasma) on hardware with Intel graphics ✅
• Fedora Workstation 40 (GNOME) on VirtualBox ✅
• Manjaro Linux XFCE 24.1.2-241104 (like Arch Linux) on VirtualBox ✅
• Chimera Linux 20241027 (which uses musl libc instead of glibc and doesn't use many parts of GNU) on VirtualBox ✅
• NixOS 24.05.6668 (KDE Plasma) (which doesn't have /usr populated) on VirtualBox ✅
• Ubuntu 16.04.7 LTS (Xenial Xerus) (8 years old) on VirtualBox (☑️) with minor graphical glitches

Please let me know your experience with using this AppImage, mentioning your Linux distribution and version.

[probonopd]

Details

Prusa Research has been offering PrusaSlicer for Windows, Mac, and Linux from their own download page and from GiHub Actions for quite some while. For Linux, Prusa has been using the AppImage format for years, as it provides a way to have one convenient download for various Linux distributions. This has has been working well for many happy users over the years.

However, the release notes for PrusaSlicer 2.9.0-alpha1 state that Flatpak will be used as an official way to distribute PrusaSlicer for Linux in the future.
While I fully respect Prusa Research's freedom to distribute their software in every way they wish (after all, this is the main point of the AppImage project), the release notes make some claims about the AppImage format that require a closer look because they are not (or no longer) factually accurate:

• It is claimed that AppImage is not designed to bundle "everything" and requires assumptions about the target system. AppImage, first and foremost, is a self-mounting disk image that merely mounts itself and runs whatever the aplication author has put inside. In that regard, it is not unlike a .zip file. In deciding how much to bundle privately vs. how much to use from the target system, an application author is at liberty to make a tradeoff decision between size and robustness. Traditionally, most application developers wanted to bundle only those dependencies of an application that could not safely be assumed to come with all supported mainstream desktop Linux distributions. Since Linux distributions apparently are not reaching universal consensus on how to do even basic things (e.g., in which location to put certain files), it is not easy to find a "common ground" that can be assumed to be part of every supported target system. A common-sense approach that has worked reasonably well for many is to target the oldest still-supported Ubuntu LTS release. However, this is not the only one to do things, and the application developer might also decide to bundle all dependencies of an application, full stop.
• It is claimed that AppImage requires manual decision-making and testing on all targeted Linux distributions. While true, that decision can very well be to bundle everything the application needs to run. This will result in a larger download size (although not as extreme as with Flatpak, as explained below).
• It is claimed that that some libraries may be "almost or completely" impossible to bundle (e.g., glibc or webkit). Tools like go-appimage or sharun exist that entirely automate the handling of glibc. As for webkit2gtk, some manual steps are currently needed because that software is not built with relocatability in the filesystem in mind (in other words, it uses compiled-in hardcoded paths). However, this can be solved by some trivial patching (or submitting an upstream fix).
• It is claimed that AppImage requires a specific version of libfuse to be present on the target system. While this used to be the case with older versions of the AppImage runtime (a tiny piece of software that is part of evey AppImage - not to be confused with the large Flatpak runtimes), it is no longer the case when you use a static runtime that does not rely on any libraries from the target system, including libfuse. In fact, today there are several static runtiems from different authors, one even written in Rust. For systems with no FUSE support at all, an AppImage can be extracted (similar to a .zip file) using the --appimage-extract command line option. For this, no FUSE is needed at all.
• It is claimed that Using old glibc for compatibility reasons forces building on older distros. This is not an inherent limitation of AppImage. It is merely a consequence of application developers wanting to privately bundle only the dependencies that cannot reasonably assumed to be part of every mainstream Linux distribution. When you develop against an OS, then usually your users will need that OS version or a newer version in order to run your application. The only way around this is to bundle everything - which is what Flatpak does, and is what an application author can choose to do with AppImage as well.
• It is claimed that Flatpak solves the dependency hell problem by building against a defined runtime. While true, this means that on top of the user's Linux distribution, essentially the whole stack is installed a second time (e.g., in the case of PrusaSlicer, all of GNOME even if you are not using GNOME at all). And the runtime is definded by someone, not by the application author. There are some applications that require certain versions of (patched) dependencies. This is easy with AppImage but not with Flatpak.
• It is claimed that Flatpak provides better desktop integration and application updates. Depending on the use case, this may be an advantage or a disadvantage. For example, users wanting to try out the latest alpha version don't neessarily want that version to be integrated into the desktop, and certainly don't want the previous alpha to go away when a newer one is downloaded. With AppImage, users can have as many versions around as they like to. For example, having an AppImage would be especially be beneficial for each of the development branches in the PrusaSlicer project, as it would allow testers to test the branches easily.
• It is claimed that Flatpak offers sandboxing and permission control. This is possible for AppImages as well with third party sandboxes, but with unlike Flatpak, it is not mandatory and is not forced upon users.

The release notes for PrusaSlicer 2.9.0-alpha1 also state some downsides of using Flatpak:

First, make sure you have flatpak installed and Flathub correctly set up. You can follow the steps at https://flatpak.org/setup/.

This is not necessary with AppImage. The AppImage format is specifically designed so that users don't need to install anything else first, and do not need to have root permissions.

Please understand that publication of PrusaSlicer on Flathub has to be preceded by the publication on our GitHub. This means that there will always be certain delay (typically couple of hours) before the new release shows up on Flathub. This is the expected behaviour, the extra time is needed to build the Flathub binary.

With AppImage, builds can be published immediately as part of the regular build pipeline. The builds are available immediately.

Flatpak also provides better user experience regarding desktop integration and application updates, and it is able to control permissions that the applications have through its sandboxing mechanism. Although this may not be appealing to all Linux users, we believe that these points are valuable to most.

"Better" is subjective. Some users want one single file which can be downoaded and run, without the need to install anything, and without affecting any other versions that may already be on the system. Some users might be running a Linux Live ISO which is not even installed on the machine. Some users don't even have root permissions on the system they are using. AppImage delivers in these situations. AppImageUpdate allows for very efficient delta updates. And with AppImage, sandboxing is optional but possible for users who want it.

The biggest complain people have about Flatpak is that it downloads too much data to run a single application (although a runtime is only downloaded once for all applications that rely on it).

According to a scientific experiment, installing PrusaSlicer using Flatpak downloads 854 MB.

Flatpak download sizes are enormous, because whole runtimes (e.g., the entirety of GNOME) are downloaded even though only a tiny fraction of it might be required by the application. In contrast, with AppImage the developer can bundle only the few files the application actually needs to run and not rely on monolithic third-party runtimes.

An AppImage bundling PrusaSlicer with all dependencies it needs to run is 201 MB, so 1/4 the size of the same application installed by Flatpak and the dependencies it pulls in.

We understand that the decision may make some people angry and raise questions about why we are leaving something that "just works" (the AppImage).

Luckily, it's not either-or: AppImage and Flatpak serve different purposes for different target groups (portable single-file applications vs. installed applications). So why not have both?

References

• Linux AppImage -> FLATPAK notes in 2.8.1-rc1 #13376
• PrusaSlicer-2.8.1-rc1+linux-x64-newer-distros-GTK3-202409121246.AppImage on Ubuntu 24.04 looking for libwebkit2gtk-4.0.so.37 #13361 (no more need for two separate AppImages)
• 2.8 AppImage Missing libwebkit2gtk-4.0 #12984 (libwebkit2gtk-4.0 is now bundled)
• Missing libwebkit2gtk-4.0.so.37 #12835 (libwebkit2gtk-4.0 is now bundled)
• [SOLVED] New PrusaSlicer 2.8.0 does not start in Linux #12922 (all libraries are now bundled)

[Samueru-sama]

I want to add this to show how huge flatpak download sizes are:

Flatpak with deduplication and all of that ended up using 9.85 GiB, while the same apps as AppImage used 2.0 GiB. And I was not able to find all the apps that I have appimages of as flatpak, like lite-xl or deadbeef.

[buhman]

https://github.com/probonopd/PrusaSlicer/releases/tag/mk1 works for me on Gentoo (default/linux/amd64/23.0/desktop/gnome profile).

I do not have a system installation of webkitgtk, so this is a great improvement compared to:

./Downloads/PrusaSlicer-2.8.1+linux-x64-newer-distros-GTK3-202409181416.AppImage
/tmp/.mount_PrusaSxcsFCz/usr/bin/bin/prusa-slicer: error while loading shared libraries: libwebkit2gtk-4.1.so.0: cannot open shared object file: No such file or directory

./Downloads/PrusaSlicer-2.8.1+linux-x64-older-distros-GTK3-202409181354.AppImage
/tmp/.mount_PrusaS0TsyZQ/usr/bin/bin/prusa-slicer: error while loading shared libraries: libwebkit2gtk-4.0.so.37: cannot open shared object file: No such file or directory

from the previous 2.8.1 releases.

[Souliboi]

Honestly, the replacement of AppImage to Flatpak has been a long time coming,
imagine you are some individual, just wanting to download a slicer and being confronted with a table on what is, and what isn't capable of running the release binaries, and then hoping nothing goes wrong in the process.
Flatpak takes away any and all of the worries and makes it as simple as just clicking install, removing any of the prexisting efforts to explain the individual user what they should, and shouldn't download.

The following quotes are paraphrased in the way I understood them:

Choosing a Flatpak bloats up the size too much

First, it's not the early 2000s anymore, we can spare a couple gigs of space
Second, this assumes that modern day users don't already use some sort of Flatpak, which they are very likely to do so, which in turn means this "inflation" by downloading the GNOME Runtime doesn't really mean anything here, it would be present anyway.

Just include all dependencies

Then we would just end up inflating the package now would we, otherwise we would just end up requiring to test for any individual distro out there and pray they all play nice.

Flatpak forces sandboxing, AppImages don't

Security by default is a good option, yes, that includes sandboxing a slicer

And to finish this comment of mine off, anytime I had involvement with AppImages, it has always been dreadful to work with them if they didn't feel like coorperating with me and didn't "just work", this was even the case with PrusaSlicer, where thankfully, most of this for me could be avoided by
A: Installing the Flatpak
B: Installing the Distro's package, which also depends on the distro keeping it up to date.

It has always been a headache universally, pretty much regardless of what AppImage I came across, you could blame it on the packager or the user, but at this point I couldn't be bothered.
Signed, a Linux user frustrated with AppImages

[Samueru-sama]

Then we would just end up inflating the package now would we, otherwise we would just end up requiring to test for any individual distro out there and pray they all play nice.

Nope, you can see it in my comparison, some of the AppImages I have there (like the Steam appimage) already bundle everything and work on any distro.

I recently made this appimage of cromite that bundles everything and works on any distro, and the appimage is smaller than the tar.gz that cromite offers for linux which isn't really portable as it depends on glibc.

The difference here being that we bundle everything we need and no more. The flatpak runtimes are more like taking a AppImage and using distrobox to spin a container to run them that's compatible with it.

Anyways, none of this matters like you said, however if one option will use many times less storage than the other and gives me the same thing, I will pick the one that uses less storage.

Security by default is a good option, yes, that includes sandboxing a slicer

I do have a problem with not having a way to disable it, even snap provides a method to disable the sandbox, because not all apps play nicely with it. Also in the case of firefox browsers, the sandbox is bad for its security. The cromite the dev doesn't want to provide a flatpak of it because of these issues. (Edit: And the later is a chromium based browser where this issue isn't as bad).

With that said I'm not sure what the implications could with in the case of PrusaSlicer, no idea if webkitgtk even has the ability to use namespaces to create its own sandbox.

anytime I had involvement with AppImages, it has always been dreadful to work with them

Sad to hear, and I get it I also know some appimages that broken.

My story flatpak isn't great though, mine was short and a nightmare with yuzu being broken as flatpak because of the outdated mesa they shipped which was out of their control, then I found out how much storage I was wasting with all the flatpak runtimes I had and just stopped bothering with it.

It has always been a headache universally, pretty much regardless of what AppImage I came across, you could blame it on the packager or the user, but at this point I couldn't be bothered.
Signed, a Linux user frustrated with AppImages

In any case, please note that the AppImage that probono linked fixes these common issues for good.

[probonopd]

@Souliboi there is a huge difference between

• Bundling only the dependencies an application needs that cannot reasonably be expected to be part of every target system (the approach used by most "traditional" AppImages so far)
• Bundling all dependencies an application needs (the approach taken by this AppImage)
• Bundling entire frameworks that happen to include the dependencies an application needs (the approach taken by Flatpak)

downloading the GNOME Runtime doesn't really mean anything here, it would be present anyway

It won't be "present anyway" on many systems. Especially since you need a matching version for each PrusaSlicer version you want to keep around. (And some users want to keep around many versions, including historical ones. Not even sure whether Flatpak supports this at all.)

[probonopd]

@madpipeline I am trying to address the issue you mentioned there regarding PrusaSlicer-2.9.0-alpha1-x86_64.AppImage.
Which language is your system set to?

Can you please post the output of

env | grep -E 'LANG|LC_|CHARSET|LINGUAS'
cat /etc/os-release

Thanks.

[probonopd]

Thanks @Samueru-sama for bringing my attention to this.

Currently PrusaSlicer installs as part of make install

 /usr/resources/localization/ko
 /usr/resources/localization/ko/PrusaSlicer_ko_KR.po
 /usr/resources/localization/ko/PrusaSlicer.mo
 /usr/resources/localization/ja/PrusaSlicer_ja.po
 /usr/resources/localization/ja/PrusaSlicer.mo
 /usr/resources/localization/sl/PrusaSlicer.po
 /usr/resources/localization/sl/PrusaSlicer.mo
 /usr/resources/localization/ko_KR/PrusaSlicer_ko.po
 /usr/resources/localization/ko_KR/PrusaSlicer_ko_KR.po
 /usr/resources/localization/ko_KR/PrusaSlicer_ko_KR.mo
 /usr/resources/localization/ko_KR/PrusaSlicer.mo
 /usr/resources/localization/it/PrusaSlicer_it.po
 /usr/resources/localization/it/PrusaSlicer.mo
 /usr/resources/localization/fi/PrusaSlicer.mo
 /usr/resources/localization/fi/PrusaSlicer_fi.po
 /usr/resources/localization/pt_BR/PrusaSlicer_pt_BR.po
 /usr/resources/localization/pt_BR/PrusaSlicer.mo
 /usr/resources/localization/ca/PrusaSlicer.mo
 /usr/resources/localization/ca/PrusaSlicer_ca.po
 /usr/resources/localization/wx_locale/hr.po
 /usr/resources/localization/wx_locale/ko.po
 /usr/resources/localization/wx_locale/pt_BR.po
 /usr/resources/localization/wx_locale/ar.po
 /usr/resources/localization/wx_locale/es.po
 /usr/resources/localization/wx_localeru.po
 /usr/resources/localization/wx_locale/nb.po
 /usr/resources/localization/wx_locale/pt.po
 /usr/resources/localization/wx_locale/ko_KR.po
 /usr/resources/localization/wx_locale/uk.po
 /usr/resources/localization/wx_locale/fr.po
 /usr/resources/localization/wx_locale/zh_CN.po
 /usr/resources/localization/wx_localero.po
 /usr/resources/localization/wx_locale/en.mo
 /usr/resources/localization/wx_locale/gl_ES.po
 /usr/resources/localization/wx_locale/lt.po
 /usr/resources/localization/wx_locale/de.po
 /usr/resources/localization/wx_locale/hi.po
 /usr/resources/localization/wx_locale/af.po
 /usr/resources/localization/wx_locale/fi.po
 /usr/resources/localization/wx_locale/sv.po
 /usr/resources/localization/wx_locale/eu.po
 /usr/resources/localization/wx_locale/sl.po
 /usr/resources/localization/wx_locale/be.po
 /usr/resources/localization/wx_locale/ne.po
 /usr/resources/localization/wx_locale/sk.po
 /usr/resources/localization/wx_locale/id.po
 /usr/resources/localization/wx_locale/tr.po
 /usr/resources/localization/wx_locale/lv.po
 /usr/resources/localization/wx_locale/fa_IR.po
 /usr/resources/localization/wx_locale/ja.po
 /usr/resources/localization/wx_locale/hu.po
 /usr/resources/localization/wx_locale/an.po
 /usr/resources/localization/wx_locale/ca@valencia.po
 /usr/resources/localization/wx_locale/ms.po
 /usr/resources/localization/wx_locale/en.po
 /usr/resources/localization/wx_locale/zh_TW.po
 /usr/resources/localization/wx_locale/vi.po
 /usr/resources/localization/wx_locale/sq.po
 /usr/resources/localization/wx_locale/pl.po
 /usr/resources/localization/wx_locale/cs.po
 /usr/resources/localization/wx_locale/el.po
 /usr/resources/localization/wx_locale/ca.po
 /usr/resources/localization/wx_locale/ta.po
 /usr/resources/localization/wx_locale/it.po
 /usr/resources/localization/wx_locale/nl.po
 /usr/resources/localization/wx_locale/da.po
 /usr/resources/localization/zh_CN/PrusaSlicer_zh_CN.po
 /usr/resources/localization/zh_CN/PrusaSlicer.mo
 /usr/resources/localization/de/PrusaSlicer_de.po
 /usr/resources/localization/de/PrusaSlicer.mo
 /usr/resources/localization/es/PrusaSlicer_es.po
 /usr/resources/localization/es/PrusaSlicer.mo
 /usr/resources/localization/be/PrusaSlicer_be.po
 /usr/resources/localization/be/PrusaSlicer.mo
 /usr/resources/localization/en/PrusaSlicer_en.po
 /usr/resources/localization/en/PrusaSlicer.mo
 /usr/resources/localization/zh_TW/PrusaSlicer_zh_TW.po
 /usr/resources/localization/zh_TW/PrusaSlicer.mo
 /usr/resources/localization/nl/PrusaSlicer_nl.po
 /usr/resources/localization/nl/PrusaSlicer.mo
 /usr/resources/localization/tr/PrusaSlicer_tr.po
 /usr/resources/localization/tr/PrusaSlicer.mo
 /usr/resources/localization/uk/PrusaSlicer_uk.po
 /usr/resources/localization/uk/PrusaSlicer.mo
 /usr/resources/localization/ru/PrusaSlicer_ru.po
 /usr/resources/localization/ru/PrusaSlicer.mo
 /usr/resources/localization/fr/PrusaSlicer_fr.po
 /usr/resources/localization/fr/PrusaSlicer.mo
 /usr/resources/localization/cs/PrusaSlicer_cs.po
 /usr/resources/localization/cs/PrusaSlicer.mo
 /usr/resources/localization/pl/PrusaSlicer_pl.po
 /usr/resources/localization/pl/PrusaSlicer.mo
 /usr/resources/localization/hu/PrusaSlicer_hu.po
 /usr/resources/localization/hu/PrusaSlicer.mo

For reasons unbeknownst to me, Prusa are using /usr/resources rather than the more standard /usr/share.

The resources directory then gets copied into the AppDir. Maybe we need some environment variable to tell PrusaSlicer to load this from a relative (run-time) rather than an absolute (compile-time) path?

[Samueru-sama]

For reasons unbeknownst to me, Prusa are using /usr/resources rather than the more standard /usr/share.
The resources directory then gets copied into the AppDir. Maybe we need some environment variable to tell PrusaSlicer to load this from a relative (run-time) rather than an absolute (compile-time) path?

Looks like the perfect scenario for this library.

PATH_MAPPING="/usr/resources:${SHARUN_DIR}/resources"
LD_PRELOAD=${SHARUN_DIR}/path-mapping.so

[probonopd]

Let's see what @madpipeline responds regarding #13653 (comment). Then we can retest in an environment similar to his.

[novaplusplus]

Thanks for keeping this alive and showing that it's perfectly achieveable. Haven't used PS in a while but just grabbed your build to test while I try Nobara linux (light fork of Fedora 40) + KDE, seems to be working fine. Only just looked through basic functions though, did not go through and slice anything. Infamous web interface seems to work fine, as does the new printables integration

[madpipeline]

@madpipeline [...] Which language is your system set to?

env | grep -E 'LANG|LC_|CHARSET|LINGUAS'
LANG=ro_RO.UTF-8
LANGUAGE=

cat /etc/os-release
NAME="Fedora Linux"
VERSION="40 (KDE Plasma)"
ID=fedora
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Fedora Linux 40 (KDE Plasma)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:40"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=40
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=40
SUPPORT_END=2025-05-13
VARIANT="KDE Plasma"
VARIANT_ID=kde

[probonopd]

Thanks @madpipeline I can reproduce the issue and am working on an AppImage that fixes it.

[probonopd]

@madpipeline please retry with https://github.com/probonopd/PrusaSlicer/releases/tag/mk2.
The difference is that this also bundles the locales-all package. I have tested it on Fedora Linux 40 (KDE Plasma) with LANG=ro_RO.UTF-8.

[madpipeline]

It works ok. Thank you.

[prusaslicer-bot[bot]]

This issues has been labeled legacy. It means that it has been created before the release of PrusaSlicer 3.0.0 alpha version. In an attempt to clean up the GitHub issues tracker any legacy issue with no new user comments after this message will be automatically closed after 3 weeks. In two weeks from now, one more warning will be provided before finally closing the issue.

According to the PrusaSlicer GitHub policy, any issue that is not a reproducible bug, will be closed in GitHub issue tracker. See the GitHub issue tacker cleanup announcement for a detailed description of what this means for your issue.

[gneiss15]

OK, to keep ist open just this message

[timnolte]

I don't know yet. I had a lot of other projects so don't know if and when I will have time to adopt my repo to work with 3.xx upwards. But maybe my repo will work for 3.xx too.. We will see this only after prusa releases 3.00 (my repo does not act on alpha or beta releases

@gneiss15 I totally understand, which was why I was curious how you were feeling about the new 3.0 rewrite.

It's really a pain to see this move to a packaging system that is by far not the Linux standard, not that AppImage is either but it doesn't require the overhead of Flatpacks. I have no desire to burden my Ubuntu-based system with Flatpacks/Flathub garbage.

[lukasmatena]

I agree that this long thread deserves a different reaction that an automated bot.

We currently do not plan to move away from Flatpak, nor to provide an AppImage. While I am not going to say that Flatpak has no downsides, it serves the goal well - it takes care of distributing our application to pretty much any Linux distro, while providing the same environment that we tested the application in. And it gives us ARM builds for free.

It has been two years since the 2.8.1 which started all this, and nothing I wrote then has really changed. While I admire @probonopd who proved that the AppImage can be created, the hackish nature of it makes me worry about a possible maintenance trap. The fact that the proof required the author of the AppImage himself, is a strong flag. Yes, the same problem can happen with Flatpak, but based on my experience with both (and we used AppImage for quite a long time), I consider it less likely, at least at this time.

It's really a pain to see this move to a packaging system that is by far not the Linux standard, not that AppImage is either

This actually hits the nail on the head. There is no Linux standard. There are several vastly different options, and people who strongly love them or hate them. Unless we support deb/rpm/Snap/Flatpak and AppImage at the same time, someone will be unhappy.

Please understand that we have a complex application to maintain, and that less than 5 % of our users runs Linux in the first place. We really need to keep the pipeline simple. We may reconsider this decision in future if we find a strong technical reason to do so. We do not see it now.

All that being said, this is AGPLv3 application on Linux where freedom is paramount. THe community is completely free to maintaining any other distribution channel unofficially. Or to compile the application from source, which is what actually was the "Linux standard" once.

I am moving this to discussions, where it belongs.

[paulcobbaut]

and that less than 5 % of our users runs Linux in the first place.

Where does this number come from?
Linux is getting close to 10 % in statcounter etc. and since 3D printing and Linux are both appealing to tech nerds I would expect its market share for a slicer to be much higher than that.

[m00dawg]

We agree to disagree on that.

I've been building PS from source since the unfortunate AppImage pivot, and the thing brings in tons of its own dependencies to the point I think the complexity of managing AppImage (or DEB, RPM, etc. for that matter) feels overstated and stubborn. Plenty of other projects do this and largely because they setup an automated build pipeline that builds the packages as part of CI/CD.

Not to name drop forks; but OrcaSlicer, BambuSlicer, SuperSlicer and Slic3r all offer AppImage support as of the time that I am writing this. The information you need already exists in public space such that the arguments, to me, never held water and they still don't.

If Prusa doesn't want to maintain AppImage, I think that's fine! There is nothing wrong with focusing but the above reads like a veiled insult. It sounds like you're justifying the reasoning behind a supposed small userbase (even though I question that figure) and manufactured complexity. Talk about feeling minimized despite having purchased many Prusas over the years (they make up more than half my print farm).

These feel less like truths and more like, frankly, Bambu-like hand waiving. It's not a good look on Prusa. It sounds like I'm being scolded for running an operating system that seems to hit the points Prusa himself sells as part of your printers (offline capable, non-cloud, secure, etc.).

I take issue with the thin reasoning behind removing Appimage given all of the above, as it doesn't feel transparent and, I think, runs against the ethos that built this company in the first place. Digging the hole deeper isn't doing to make people change their minds or cease to point out the flaws in the logic either.

[MasterCATZ]

thankfully the AI bots have been kind enough to build into whatever format I have been asking them for
so that they are self contained programs without dependencies that would have only been a update away from being broken

AppImage is still my preferred as It works on any Linux distro and I can just have them sitting in my home

[nerdCopter]

share your vetted agent.md 😉

[MasterCATZ]

unfortunately my hermes agents quite unique most of its scattered inside an obsidian vault it consists of many micro skills its tuned for self learning and skill evolution with full revision history ie) arXiv:2608.27454 and contains a full lossless memory backend , I could possibly ask it to make a generic md to do the task

[m00dawg]

Those were...words? 🤣

For other folks, even a local model like Qwen 3.6 could probably manage an AppImage with enough prodding though I haven't tried. I'm personally AI-meh (particularly given us peons can't afford RAM for our phones let alone actual computers...) but I did use Qwen with OpenCode to help it debug a dependency issue with Tracy in the master branch so I could get PS3 built.

[lukasmatena]

@m00dawg

OrcaSlicer, BambuSlicer, SuperSlicer and Slic3r all offer AppImage support as of the time that I am writing this

Slic3r's last release was 8 years ago. SuperSlicer's 2 years ago. OrcaSlicer's AppImage does not run on Ubuntu 22.04 - a supported LTS. BambuStudio provides two different AppImages to ensure it does (that is my hack from 2.8.0-rc2, which I refused to keep doing). And OrcaSlicer's issue tracker has multiple AppImage-related open issues (OrcaSlicer/OrcaSlicer#10990 and others). That is what we wanted to avoid exactly. If it was as simple as "setup an automated pipeline", we would have done it.

Regarding your other points. You are absolutely not being minimized, and we are grateful if you are running our printers. You are also not being scolded for running Linux (it would be weird if I did that from my Linux workstation I run daily) or for anything else. You are more than welcome to use our slicer after you install it from Flathub (which we support officially, and I assume that so does your distro) or build it yourself if that is what you choose.

I take issue with the thin reasoning behind removing AppImage given all of the above, as it doesn't feel transparent and, I think, runs against the ethos that built this company in the first place.

I publicly stated my real opinion without lying or hiding anything. It is as transparent as it gets. My opinion may be wrong, but that does not count as "not transparent". As a maintainer, it is my responsibility to keep our pipelines stable and simple, and to ensure that things that work do not get fixed needlessly. I have actually pushed back against the suggestion to switch to Flatpak or the idea of taking over maintenance of distro packages for exactly those reasons in the past. We need to allocate resources to the slicer, not on maintaining dependency chains on 30 different platforms.

The short version is that Prusa has decided to not reintroduce AppImage and keep supporting Flatpak. And I am glad that you agree that focusing is fine, because that is exactly what we are doing with it.

I feel that I now explained our reasons as transparently as I could. I will be stepping back from this thread now, but I genuinely appreciate the feedback.

[m00dawg]

@lukasmatena thanks for the direct reply! We're still in agree to disagree territory but I still appreciate the extra insight. <3 I will add I think PS is a a wonderful slicer and appreciate the work you and all those folks do.

[SachCZ]

Hi @m00dawg, I would just like to comment further as I must admit I am a bit triggered right now and would like to rant for my own sake. It might be a bit unprofessional and I apologize for that.

I agree with your points about CI and you are not wrong, but I feel like we are talking past one another. It is not like we are unable to do what you are suggesting. The point is that we are unwilling to maintain and bugfix all the possible options forever, hence we converged on one approach that promises a sandbox with as minimal individual platform differences as possible. AFAIK flatpak does this really well at the expense of other things.

I must admit your points personally sadden me greatly for the following reasons:

• We are trying to be as transparent as possible from the start of this whole appimage vs flatpak discussion, we have posted multiple statements and tried to convey why we are doing what we are doing, yet in the end you say we are not transparent enough
• I use Linux, many of my colleagues use Linux, people around me use Linux, we care about Linux and we try (and fail as everyone else) to deliver the best possible experience for users while using our software. We do not want our software to be crashing for people based on the distro they are using, we do not want you encountering random bugs, just because you use a less popular Linux option, we want to support arm setups. We can ensure this to some degree with flatpak, because what we test is what you get. With the other options it is hard to promise that. I had spend so much time on just maintaining Linux distribution of PrusaSlicer. In comparison to the other two platforms, Linux has taken the majority of my time. In my opinion this is time well spent, but in the end you tell me you feel minimized as a Linux user.

Finally, I feel like it needs to be stated where developer time is actually allocated. We do not have infinite resources and if you commit to maintaining something, you commit to it "forever" (whatever "forever" might be - for an individual it might be until you burn out/until you retire/until you are not interested anymore, for a company it might be decades). Introducing features, technologies, distirubution methods is always comparatively cheap to maintaining them given enough time.

You can see an example of this right in this thread. @gneiss15 committed to maintaining appimage (without any promises), for which we are actually very grateful and think is an admirable thing to do. Yet, now he or she is not sure if he wants to continue as it takes his precious time. It is quite understandable and as a individual, he or she can very well afford to do that. We as a company, where our "forever" is decades to come do not have such a luxury.

[m00dawg]

The 5% comment in particular is what triggered me. I think it's under-reported (given the forks and ports) but I read that as being "be happy this is what you have" and I didn't care for that as a long time supporter of company (in buying printers and things and being personally a big promoter of all the good things Prusa does) and given the deliberate decision to use Slic3r as the PS roots.

To be clear, I hope the above was not considered any sort of personal attack on anyone. I treat it as the stance of the company not an individual. While I appreciate the insight from both you and Lukas, I'm not obligated to agree with it.

[SachCZ]

Yeah, I might have taken that bit too personally and now see it was not. I now understand your response better. In any case agreeing to disagree is fine with me ❤️

[gneiss15]

As my repo demonstrates, it is quite easy to build an AppImage from a PrusaSlicer release. There has been only one exception so far, where an additional library was required; once I added it, all Prusa releases were automatically generated as AppImages again. So, the effort involved is minimal. If—or since—Prusa can no longer (or chooses not to) provide support, things can simply continue via my repo.

[Samueru-sama]

@lukasmatena

#13653 (comment)

---

While I am not going to say that Flatpak has no downsides, it serves the goal well

• PrusaSlicer not usable on Fedora 43 with AMD GPU #15085
• Flatpak breaks post-processing scripts #13982
• Linux flatpak uses different DNS config than host and doesn't report effectively when broken  #13848

While I admire @probonopd who proved that the AppImage can be created, the hackish nature of it makes me worry about a possible maintenance trap

probono made that appimage because you lied horribly in the release notes saying absolute nonsense about appimage that to this day I still see people repeating and I have to correct.

That reality is that you people chose to force webkit2gtk4 despite complains about it #12968

webkit is totally broken, even tauri plans to offer cef due to its issues: tauri-apps/tauri#14963

And when faced with that nonsense you people decided to lie and hurt the image of appimage with those release notes.

it makes me worry about a possible maintenance trap

What maintenance trap is in here?

We even provide woulds of webkit2gtk4 with support for WEBKITT_EXEC_PATH which is the reason you had that many issues with appimage in the first place.

[probonopd]

Everyone, let's calm down a bit.

An AppImage is just a self mounting disk image that executes whatever is inside it.

There is nothing particular complex about AppImages. In fact, it is quite simple.

If anything, it is the software inside the AppImage that is complex, e.g., due to a high number of dependencies, which in turn can bring in even more dependencies, which... can get complex. The perceived complexity is in fact not about creating AppImages (putting whatever into a self-mounting disk image is easy), but is really about managing the complexities of deploying an application with many dependencies cleanly without relying on distribution package managers or runtimes (collections of libraries someone else manages). You would have the exact same complexity if you wanted to make a zip file containing an application that can run everywhere. For that, too, one would need to deploy into the zip file everything the application needs to run. It can be done by basic tools like ldd, cp, sed, patchelfalone (the hard way), or one can use tooling designed to automate much of it (like, e.g., quick-sharun).

Going forward, one can probably leave much of that work to LLMs. Just tell them to "turn this application into a self-standing application directory (AppDir) that can run on all Linux distributions by bundling everything".

If Prusa Research doesn't want to do it, anyone else can do it. That's the nature of the license. This, however, misses the important point: AppImages are meant for "upstream packaging", allowing application authors to be in full control over the entire software stack. Unlike with other distribution methods (including Flatpak) where an application author has little influence over which exact versions of each dependency get shipped (usually defined by the distribution or runtimes), the application author has full control over the whole stack with AppImages, and can ensure proper testing, integration, and certification. Some AppImages ship a finely tuned and patched stack of all of their dependencies. There are even projects like archlinux-pkgs-debloated that contain versions of libraries that minimize unwanted dependencies.

[buhman]

Or to compile the application from source, which is what actually was the "Linux standard" once.

During that time, it was also the standard that applications used fairly simple build processes, and had un-bloated and reasonable dependency lists.

AppImages are the crutch we use now that this is no longer the case.

[gtozzi]

+1 from another longtime Prusa and Linux user.

I want to add my voice to the Linux users for whom Flatpak is not a suitable replacement. I don't want a sandboxed runtime, I don't want to install a packaging system just to run a slicer, and I don't want hundreds of MB of runtime pulled in for a single application. For my workflow, the AppImage was the right solution: one file, no root, no daemons, works on any distro.

I understand Prusa's decision to focus resources, and I respect that the community can maintain an unofficial AppImage (thanks to @probonopd and @gneiss15 for keeping the AppImage alive). Please just don't make changes that would break the community AppImage effort.

[adelton]

Unless we support deb/rpm/Snap/Flatpak and AppImage at the same time, someone will be unhappy.

I wonder if this is really true and if you (assuming the "we" is Prusa Research) aren't assuming responsibility that ideally might not even be yours to bear.

People will be unhappy if they aren't able to use the slicer on their preferred Linux system their preferred way, that's the nature of Linux. It does not necessarily mean that all those preferred ways to install and use PrusaSlicer need to be supported by this repo and its authors. If it is easy for the community to provide and maintain those alternate distribution and installation formats, users might get what they want even if you don't provide and support it directly.

Could this be more about "how to make maintainers of Linux builds happy and maintain good relationship with them" than "how to make Linux users happy directly"? This might include at least acknowledging valid pull requests, even if your development model does not seem to allow for proper review and merge workflow, and some basic guidance about things that those maintainers might want to do, like using system dynamic libraries wherever possible. There seems to be a wealth of technical knowledge that can benefit PrusaSlicer there, and in my idealistic view, this should actually remove some of the maintenance burden from you because you will be able to point out that other ways to consume the software are also available.

Full disclosure: prusa-slicer Fedora package maintainer here. Feel free to comment that by maintaining the rpms in Fedora I actually negatively contribute to the fragmentation of the Linux world, rather than helping it.

[CRCinAU]

Thanks for mentioning that Fedora has its own packages... I didn't even realise this as a long time Fedora user.