search

prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.76k stars 1.93k forks source link

Proper Flatpak support #9776

Open TheOPtimal opened 1 year ago

TheOPtimal commented 1 year ago

Not a duplicate

This issue is NOT a duplicate of #1124. That issue discusses simple inclusion in Flathub, this issue discusses official support from PrusaSlicer.

Issue: Proper Support for Flatpak in PrusaSlicer

Problem

PrusaSlicer currently distributes an AppImage for Linux users, which can cause issues on some distros and can lead to compatibility problems with some system libraries. While some distros package PrusaSlicer themselves, this can lead to fragmentation and inconsistencies in user experience.

On the other hand, there is an unofficial version of PrusaSlicer available on Flathub, but this is not an ideal solution since it may not receive timely updates and may not be supported by the PrusaSlicer development team. Moreover, the current version of PrusaSlicer on Flathub has been reported to have sandboxing holes, which can put user security at risk.

Sandboxing Holes

Solution

The solution to this problem is to properly support Flatpak, which is rapidly becoming the standard way of distributing applications on the Linux desktop. Flatpak provides a sandboxed environment for applications, which ensures that they can run on any Linux distribution without compatibility issues. Flatpak also provides a centralized repository, which makes it easy for users to install and update applications.

Advantages of Flatpak over AppImage

While AppImage is a useful tool for distributing applications on Linux, Flatpak offers several advantages:

Benefits of Supporting Flatpak

By properly supporting Flatpak, PrusaSlicer will:

Conclusion

Flatpak is the future of the Linux desktop, and it is essential that PrusaSlicer embraces this technology to provide the best possible user experience. I urge the PrusaSlicer development team to support Flatpak and make PrusaSlicer available on Flathub as an official application. This will help ensure user security and provide a more consistent and reliable user experience.

lukasmatena commented 1 year ago

Some thoughts on this one are already in written in https://github.com/prusa3d/PrusaSlicer/issues/7937. My (personal) opinion is that Linux people have already come up with so many ideas how someone else should distribute software for them, that it is becoming difficult to make them all happy.

PrusaSlicer currently distributes an AppImage for Linux users, which can cause issues on some distros and can lead to compatibility problems with some system libraries.

Are you talking about some actual issues that are appearing on your computer or someone else's that you know, or is more like that "it works, but it should still be done differently"?

While some distros package PrusaSlicer themselves, this can lead to fragmentation and inconsistencies in user experience.

Agreed. Such as PrusaSlicer packages not starting at all and their users bugging us for producing crappy software. For me it is pretty much proved to not be a good way.

Flatpak, which is rapidly becoming the standard way of distributing applications on the Linux desktop

I tend to be careful when hearing about "standard way on the Linux desktop". I don't follow the situation closely, but doesn't Canonical, the company behind the most widely used Linux distribution promote Snap over Flatpak?

Reduce the burden on the PrusaSlicer development team to support the application on different Linux distributions.

Actually, that is not that much of a burden. The real PITA is to support Linux in the first place.

All that being said, we may discuss this internally. If Flatpak really is "the future", the proposal may make sense. However, there are also voices that the real future of Linux desktop is its death - and the arguments also make sense.

TheOPtimal commented 1 year ago

Are you talking about some actual issues that are appearing on your computer or someone else's that you know, or is more like that "it works, but it should still be done differently"?

AppImage's claim of portability is a facade. If AppImages were truly self-contained, they would be gigabytes in size, and would have to include every core system library and graphics driver, and that's virtually impossible. AppImages still rely on system libraries, and different apps can vary on what system libraries and the versions that they depend on - so we're back to that problem.

Flatpak largely solves this - the apps are self-contained, but can also utilize shared runtimes. Runtimes can be anything for platform toolkits or SDKs for development (GNOME, KDE), graphics packages (VAAPI, Mesa), a large dependency like TeXLive or Wine, video codecs, and some more. Multiple different versions of a runtime can be installed concurrently, resolving the issue of compatiblity. It guarantees that if the app works on your system, it'll work elsewhere too.

I tend to be careful when hearing about "standard way on the Linux desktop". I don't follow the situation closely, but doesn't Canonical, the company behind the most widely used Linux distribution promote Snap over Flatpak?

Canonical has largely stopped caring about the desktop space, ever since Ubuntu Touch and Unity got cancelled. Their primary focus is now on servers, which is what Snap is mostly used for. It's sort of a counterpart to Docker. These days, the recommended Linux distribution is Mint or Fedora.

Very popular distros, like Rocky Linux/CentOS, Fedora, elementaryOS, endlessOS, Linux Mint, ZorinOS and SteamOS now ship Flatpak by default as their preferred method of application distribution. Linux Mint has outright forbidden Snap on their distribution.

Actually, that is not that much of a burden. The real PITA is to support Linux in the first place.

The good thing about Flatpak is that you get control over application distribution, and are not at the whim of a distro maintainer. This was the initial appeal

All that being said, we may discuss this internally. If Flatpak really is "the future", the proposal may make sense. However, there are also voices that the real future of Linux desktop is its death - and the arguments also make sense.

I'd argue that the future of Linux looks bright. Linux has already infiltrated the server space, so it has a stable foothold and a good source of funding. With Valve's release of the Steam Deck and SteamOS 3, more and more developers are porting their apps to Linux, and moreover - via Flatpak. Not to mention, with ChromeOS's Crostini, apps on Linux have an even larger reach.

Bottles - A Case Study

Let's take a look at Bottles. Bottles is an app that manages your Wine prefixes, but that's not the important part here - the important part is, they distribute their app as a Flatpak, and do not support native distro packages. They only offer Flatpaks distributed via Flathub.

Now, say, they had taken the classic route, and supported each individual distro. Due to the fragile nature of Wine, and wineprefix, and everything related, they would be drowning in distro-related support issues. However, by getting rid of the distro middle-men, and distributing the app themselves over Flathub via Flatpak, they were able to mostly cut down on system-specific issues, and focus on the app itsself.

I love the work that you guys do, and frankly it has made my life so much easier. So it would be nice if you guys didn't have to do the heavy lifting of distro support, and could just focus on one way of distribution.

tamasmeszaros commented 1 year ago

I would like to mention the fact that we are closely cooperating with @xarbit who is in charge of making the Flatpak packages. Although not "official" in the sense that our Github releases section does not include any reference to a Flatpak package and we are primarily testing our AppImage packages, I think that @xarbit does as good of a job as we possibly could.

xarbit commented 1 year ago

@TheOPtimal i would also like to add, help is always welcome and to address some of your points, such as quicker releases and possibly frequent beta channels, feel free to join us. Help is always welcome.

To fix those misleading unsafe flags such as legacy window system, prusaslicer needs to update wxWidgets to support Wayland. I am not a big fan on how they decided to present that in Gnome Software.

Then again wxWidgets don't support portals out of the box like gtk or kde-qt to solve the Home folder warnings.

As soon as PrusaSlicer becomes beta, @eliadevito and I will start work on the next version for the flatpak'd PrusaSlicer on flathub.

TheOPtimal commented 1 year ago

@TheOPtimal i would also like to add, help is always welcome and to address some of your points, such as quicker releases and possibly frequent beta channels, feel free to join us. Help is always welcome.

I'd love to help, but I don't know where to begin.

To fix those misleading unsafe flags such as legacy window system, prusaslicer needs to update wxWidgets to support Wayland. I am not a big fan on how they decided to present that in Gnome Software.

To be fair to GNOME, X is horribly insecure. It allows an easy escape of the sandbox and full access to the keyboard. Any app can decide to record the screen or keylog, without any kind of restrictions.

Then again wxWidgets don't support portals out of the box like gtk or kde-qt to solve the Home folder warnings.

I believe this is case for an issue to file on wxWidgets - both Wayland and Portals. However, portals don't solve everything in this case - PrusaSlicer still needs access to /run/media for detecting when the SD Card is mounted and offering the appropriate options.

As soon as PrusaSlicer becomes beta, @eliadevito and I will start work on the next version for the flatpak'd PrusaSlicer on flathub.

I believe the place for beta releases on Flathub is https://beta.flathub.org/

===

Either way, my issue was about replacing AppImages with Flatpaks. AppImages are in no way reliable and IMO should be phased out as a distribution format, as I've mentioned before:

AppImage's claim of portability is a facade. If AppImages were truly self-contained, they would be gigabytes in size, and would have to include every core system library and graphics driver, and that's virtually impossible. AppImages still rely on system libraries, and different apps can vary on what system libraries and the versions that they depend on - so we're back to that problem.

Not to mention, AppImages aren't sandboxed like Flatpaks aren't, so security is still an issue. AppImages kind of sit in this weird, narrow, unstable valley between containerized and sandboxed solutions like Flatpaks and native distro packaging. But they take the worst of both worlds.

tamasmeszaros commented 1 year ago

As to the wxWidgets upgrade with Wayland support, see issue https://github.com/wxWidgets/wxWidgets/issues/22580 which is a show-stopper for PrusaSlicer at the moment.

ivocavalcante commented 1 year ago

Not wanting to start a "Snap vs Flatpak" war, since we all had more than enough of this, but I'll make some points on this subject.

AppImage's claim of portability is a facade. If AppImages were truly self-contained, they would be gigabytes in size, and would have to include every core system library and graphics driver, and that's virtually impossible. AppImages still rely on system libraries, and different apps can vary on what system libraries and the versions that they depend on - so we're back to that problem.

True.

I tend to be careful when hearing about "standard way on the Linux desktop". I don't follow the situation closely, but doesn't Canonical, the company behind the most widely used Linux distribution promote Snap over Flatpak?

Canonical has largely stopped caring about the desktop space, ever since Ubuntu Touch and Unity got cancelled. Their primary focus is now on servers, which is what Snap is mostly used for. It's sort of a counterpart to Docker. These days, the recommended Linux distribution is Mint or Fedora.

Not sure where you got that from, but very unlikely (not to say, plain untrue). Many desktop applications are distributed through Snap, some even just there - as is the case with Flatpak, where some apps just exist on the format. Also, I can assure you that Snap and Docker (containers, in general) are very different beasts, sharing the same underlying technologies.

Not defending Canonical, since they have a good collection of mistakes and bad practices, but they're not this evil some people paint either. Even though they've somewhat severed their connection to community in the last few years, last I heard they were refocusing on getting in touch. Obviously, I might be wrong...

Very popular distros, like Rocky Linux/CentOS, Fedora, elementaryOS, endlessOS, Linux Mint, ZorinOS and SteamOS now ship Flatpak by default as their preferred method of application distribution. Linux Mint has outright forbidden Snap on their distribution.

True. Nonetheless, as @lukasmatena said, Ubuntu (and its variations) remains one of the most (if not the most) widely adopted distributions. Difficult to get real numbers though, as we all know.

Actually, that is not that much of a burden. The real PITA is to support Linux in the first place.

I can imagine that! :)

Bottom line for me is: AppImages are really suboptimal - hence I created the Snap package to start with (disclaimer) - and I'll gladly use whatever format Prusa (Snap/Flatpak) decides on (if you guys decide at all). I've both systems in use on my machine and, although generally prefer Snaps, won't have any problem at all using one or another. As I said, don't want to start another format war.

I might even try to help in maintaining the package, since learning how to do both - Snap and Flatpak - was on my initial roadmap, but had to stop with the one I learned (somewhat) first 'cause of time, that thing that we all lack often.

Cheers, Ivo

eliadevito commented 1 year ago

IMO current packaging status is no so bad as this thread seem to suggest.

There is a coverage for all major distro-indipendent distribution systems (AppImage, Flatpak and Snap) and they allow users to easy install and use PrusaSlicer without distro customizzations.

Yes, there is a small "issues" like missing wayland and portal support but this not affect significantly the user experience and will be resolved with the future versions of wxWidget.

Legion495 commented 11 months ago

Now I agree Appimages are in such a weird state. I remember there is a confusion around "libfuse" Appimage needs to run. I think this specifically leads to a breaking Appimage execution on Ubuntu. My last information on that was it is still in some support limbo.

The Flatpak I currently use also only refers to this Github. So it looks very official if I may say so. Screenshot from 2023-11-25 16-58-15

Both beta and normal package are available. Screenshot from 2023-11-25 16-59-17

I may have missed it but there is no indicator it is unofficial. Just found that strange. Obviously I hope there will be official support for Flatpak. I am almost certain anyone on Ubuntu will also enable a Flatpak repository if needed (Like PPAs). But obviously I cannot validate it. Maybe the Flathub people have some numbers.

BTW anyone having issues with the Flatpak and other drives access. Download Flatseal to add more folder or drive locations. Something nice to know as many new people will not. I imagine some will find this here if they look up the Flatpak. Example (giving create access to "/mnt/media/" location): Screenshot from 2023-11-25 17-12-09

Best Regards

xarbit commented 11 months ago

@Legion495 the Flatpak on Flathub is not directly from Prusa, that is correct. But Id say it is kinda semi official, @eliadevito and I maintain it and we worked with the pursa folks together.

As to the mount location, it does not look in /mnt/media .. what distribution are you using? Ubuntu, Fedora and Co usually mount to /media ...

We do give access to /media and /run/media:

  - --filesystem=home
  - --filesystem=xdg-run/gvfs # make GnomeVFS accessible
  - --filesystem=/run/media
  - --filesystem=/media
Legion495 commented 11 months ago

I am on Fedora to be specific. /mnt/ are where I have internal drives. So no worries! External media is all good and so is the home directory. I use one drive and mirror that to the cloud as well as a document repository I am able to use anywhere.

So this just adds the internal drive so Prusa Slicer is allowed to access it. This is most likely a edge case. I find it good practice to separate home, documents and system. So I thought this might be more common. Screenshot from 2023-11-25 17-31-44 Screenshot from 2023-11-25 17-33-11

This /mnt/media/ is just my specific mount spot for the internal drives next to home and system. I just think people who are used to running multiple drives certainly will like to know that you can easily add locations via Flatseal.

Offtopic: Come to think of it Nautilus does not even show home is a different disk than root. I am waiting on that Cosmic DE c:

AlbertoFabbri93 commented 11 months ago

I use OpenSuse Aeon, it supports Flatpaks (FlatHub) out of the box and have problems with AppImages. If I remember correctly AppImages use an old version of fuse that on my OS is no longer installed by default. This makes it undesirable to use AppImages because Aeon is immutable and installing libraries directly on the host system means losing support in case of problems.

Legion495 commented 11 months ago

I use OpenSuse Aeon, it supports Flatpaks (FlatHub) out of the box and have problems with AppImages. If I remember correctly AppImages use an old version of fuse that on my OS is no longer installed by default. This makes it undesirable to use AppImages because Aeon is immutable and installing libraries directly on the host system means losing support in case of problems.

Yeah as far as I remember "libfuse 2" to be specific as mentioned previously. There is a issue around that. Also very recently I ran into a issue where appimages try expect something in gnome and fail: "org.gnome.settings-daemon.plugins.xsettings' does not contain a key named 'antialiasing'"

The workaround is to remove this entry from that xml where this option is. But this might be gnome specific. After all I do use the flatpak of the slicer.

https://github.com/juanfresia/libfuse2

It certainly confuses because libfuse is newer? https://github.com/libfuse/libfuse

Have not touched it in Fedora and stuff runs for the most part. As far as the Github says only pull requests are sorted and there is no active maintainener.

Lyude commented 4 months ago

I wanted to bump this thread again following the the 2.8.0 release. Specifically, it seems like you guys are already running into the reason why flatpak was introduced in the first place:

"PrusaSlicer now depends on WebKit library, which greatly complicates its distribution. Latest Linux distributions (such as Ubuntu 24.04, Fedora 40) ship with newer version of WebKit than older (but still supported) distros. Bundling WebKit into the AppImage is difficult because it leads to various issues with its dependencies. So far we did not manage to create an AppImage that would reliably run on all relevant distros."

This is a really seriously strong reason you guys should just give yourselves a break and use flatpak. Every single distribution supports it, it has a fairly good reputation among users, and you can literally ship any version of any library you ever want and it would never be a problem regardless of the distribution people are using.

Please reconsider this! Appimage is really kind of the worst choice for everyone.

lukasmatena commented 4 months ago

@Lyude Thanks. Yes, this may be a reason to move from AppImage to Flatpak and make the Flatpak packaging official (either by taking it over completely, or by supporting the packagers more than we do now). Providing that using webkit runtime will really be just about stating the dependency (as the documentation says) to make it work on all systems. AppImage bundling should also have been easy, so... @xarbit and @eliadevito are the ones maintaining the Flatpak package of PrusaSlicer, their opinion is most welcome. I am personally very interested to see how updating the Flatpak to 2.8.0 will go.

I like the simplicity of the AppImage from user's point of view, you download one file, run it and it works (or it should). You don't have to learn about flatpak, install it or anything. Our current AppImages should no longer suffer from the libfuse issue and it should run with either libfuse2 or libfuse3. But bundling webkit is a challenge, and from the research I did online, we are not the only ones who did not manage it. We actually got quite far, but there is still at least one last problem with some webkit dependency. And it is very difficult to estimate how long it would take to fix, if it is even possible.

xarbit commented 4 months ago

@Lyude Thanks. @xarbit and @eliadevito are the ones maintaining the Flatpak package of PrusaSlicer, their opinion is most welcome. I am personally very interested to see how updating the Flatpak to 2.8.0 will go.

@lukasmatena

I initially created the Flatpak build for PrusaSlicer on Flathub based on an open issue from users a few years ago, attached with a official “help wanted” label.

The intention was always for it to become official, and that hasn’t changed. Honestly, I never intended to maintain it for this long, but it has a large user base now, and @eliadevito has been invaluable in keeping it alive; it wouldn’t be possible without him.

So, I’d more than welcome and encourage Prusa to take over the repository on Flathub. We’re here to help with the handover if needed and to initiate the steps. Let’s get in touch and discuss this.

Let's help each other to make the flathub/flatpak package even better.

eliadevito commented 4 months ago

IMO move official releases on flatpak is the right choice also from user point of view, today flatpak is configured by default in a lot distributions (and easy to enable on others), users have only to open distro software center look for PrusaSlicer, click install and are ready to use software.

In addition when there is an update this can be installed with a click or even automatically.

Flatpak experience is very similar to that of smartphones and for non technical users this is fantastic.

From developers point of view, maintain it is pretty linear, usually at each release we change the release tag, update the deps and software build successfully, sometimes happens that there are some missing include or the need of a small patch.

Currently on flatpak version we have 3 patches and 2 of them are upstremmable.

Version 2.8.0 will be released today, it has not released yet because I was absent for the last 2 days, in the flatpak beta branch are already present beta releases that work correctly

I would be happy to see Prusa take over the flathub repo and maintain flatpak version as official linux release and are available to help with handover.

xarbit commented 4 months ago

@lukasmatena

Also, we should get the application verified :-) :

image
eliadevito commented 4 months ago

@lukasmatena

Also, we should get the application verified :-) :

image 
* https://docs.flathub.org/docs/for-users/verification

* https://docs.flathub.org/docs/for-app-authors/verification/

* https://docs.flathub.org/docs/for-app-authors/submission#someone-else-has-put-my-app-on-flathubwhat-do-i-do

yes, this is imporant to mantain current visibility on distro's software centers. Linux Mint for example has recently changed default policy to hide unverified apps (https://www.phoronix.com/news/Linux-Mint-Unverified-Flatpaks) and probably other distros will do the same in the future