Cemu
Cemu copied to clipboard
cemu-project
[A snap package request] for Cemu now that 2.0 is open source with Linux support!
Packagers often choose Snap because as a snap because one can be sure that the app is always sandboxed by default. The dev can ship ANYTHING from libraries, apps, server/CLI software, even a modified Linux kernel, and so on.
No need to make the package executable as a snap (which is the case in AppImage, and already too much for a new user coming from Windows). Snaps, while once installed are easily and automatically updated. Regular users will very commonly NOT update manually.
It would be just an easy install for new users (and as they so generally start off on Ubuntu). A one click snap install from the Software would not hurt other users either.
Snaps always have all dependencies. Flatpaks and appimages strangely always dont carry them. Snapd is installed by default on many a Linux distros (a misconception that its only a Ubuntu thing).
Also against common misconception; Snap is open source. The part that is closed source is the server that hosts them - if there was a backdoor (this type of FUD is spread also) in snap, it would be discovered because it’s open source. The proprietary snap server is no worse than using, say Reddit.
KDE, Microsoft, Google and Mozilla and so many more big players have official snap packages, in one place. Centralization is NOT always a bad thing. For example flatpaks, they can be here and there, just like in the dangerous old PPA-model. 'Nuff said.
Thanks alot for making Linux more easier for the beginners to start with!
Snapd is installed by default on many a Linux distros (a misconception that its only a Ubuntu thing).
If you take a look at the most relevant distros, only Ubuntu and Manjaro, which also has Flatpak, have Snap preinstalled. Even Ubuntu based Distros like Mint or popOS use Flatpak instead of Snap.
Snaps, while once installed are easily and automatically updated.
And you can't disable that, even if you are a advanced user. Snap does changes on your System without asking the User and you can't disable that. That should not be done by any Software.
Snaps always have all dependencies. Flatpaks and appimages strangely always dont carry them.
Snap does basicly the same as Flatpak, It's the Maintainers Job to include all dependencies.
For example flatpaks, they can be here and there, just like in the dangerous old PPA-model. 'Nuff said.
Today most Flatpaks are on Flathub.
If you want to choose between the two, you should take Flatpak. You can of course maintain both Snap and Flatpak if you have time.
According to the Steam hardware survey, Arch derivatives make up 32.87% of the top 8 most used distros and take spots 1 and 2 in the survey, when compared to 30.75 being Ubuntu or Debian based. Arch derivativesd are also pretty much the only distros gaining popularity the only Ubuntu/Debian distro which gained popularity was Pop!_OS. I'd also see performance as a concern. You listed Mozilla as somebody who uses snap for the Firefox browser, however that package of Firefox is infamously known for being extremely slow and buggy.
I feel like I'd rather have a CEMU Flatpak or Appimage compared to a snap, all things considered.
If you take a look at the most relevant distros, only Ubuntu and Manjaro, which also has Flatpak, have Snap preinstalled. Even Ubuntu based Distros like Mint or popOS use Flatpak instead of Snap.
I'd also like to note that, to me and many other users, a Flatpak would be better than a Snap as it provides support for installation on the Steam Deck. Even if Snap can be installed on the Steam Deck, due to the immutable nature of the root filesystems, it would get erased on the next SteamOS 3.0 update. Flatpak's benefit include that they are generally installed into the user's home directory
Snapd is installed by default on many a Linux distros (a misconception that its only a Ubuntu thing).
If you take a look at the most relevant distros, only Ubuntu and Manjaro, which also has Flatpak, have Snap preinstalled. Even Ubuntu based Distros like Mint or popOS use Flatpak instead of Snap.
Snaps, while once installed are easily and automatically updated.
And you can't disable that, even if you are a advanced user. Snap does changes on your System without asking the User and you can't disable that. That should not be done by any Software.
Snaps always have all dependencies. Flatpaks and appimages strangely always dont carry them.
Snap does basicly the same as Flatpak, It's the Maintainers Job to include all decencies.
For example flatpaks, they can be here and there, just like in the dangerous old PPA-model. 'Nuff said.
Today most Flatpaks are on Flathub.
If you want to choose between the two, you should take Flatpak. You can of course maintain both Snap and Flatpak if you have time.
No no, snaps and flatpaks are not replacements for each other. They are in fact entirely different. It would be great if there'd be both a flatpak and a snap. Most common users never update their system altogether. Automatic updates are important, as many have in the end of the day noticed in the area of a "normal user". An experienced user does not have to use snapd at all though if this scenario does not match ones ways. This is definitely about a common user and simplicity, where a snap package serves very well. Solus also has snapd by default and many more. Ubuntu is the most used one, and the entry point, so that is why a snap package would be important.
Generally most Ubuntu users are happy with snaps nowadays, the problems have been ironed out and more so all the time. More advanced users even self host snap packages.
With a Snap package, backwards and forwards compatibility is also easily achieved. With a Snap package you can use arbitrarily old Distro's to build software for arbitrarily old or new distros with no issue.
There are 3 types of confinement for snap packages, additionally for special needs.
Generally most Ubuntu users are happy with snaps nowadays
that's because everyone else ran sudo apt purge snapd or distro hopped to Pop, Mint, or something else entirely
Generally most Ubuntu users are happy with snaps nowadays, the problems have been ironed out and more so all the time. More advanced users even self host snap packages.
While that may be true for Ubuntu users, the user base is growing more in other distros/variations.
- Pop!_OS provides much better direct user support being that they are a Desktop/Laptop OEM whose primary focus is on that userbase (Canonical's primary focus as a business is on Server/Cloud) and they bundle Flatpak, not SnapD.
- SteamOS 3.x, which forms the basis of the Steam Deck, is probably the fastest growing distro right now and it doesn't even allow Snap unless you enable editing the root filesystem. Even then, on the next OS update, anything not in the user home is blown away as the OS uses an immutable root FS. Meaning, like Pop!_OS, Fedora, Mint, etc they support Flatpaks and not SnapD.
snaps are slow and half baked worth thing to add
Many do use them, and the slowness was in the beginning and that time is past. For example firefox is now -50% from what the initial startup time was. When was the last time you gave them a shot? I think both a snap and a flatpak should be there. I don't think it is only me who has never had issues with snaps nor flatpaks. It should be also seconded: snapd and flatpak are almost entirely different. Flatpaks are ONLY for desktop. Snaps are much more versatile.
Firefox on snap being "Not as bad as it used to be" doesn't take away from the fact that it is still bad.
I am in favor of a flatpak, as it has numerous advantages over alternative packaging methods (with less issues). I am willing to help with testing and making the manifest, if you need some help with it.
Even tho Snaps may seem good to you, it would make much more sense to support Flatpak as most mainstream Linux Distros already bundle Flatpak by default meaning it could reach much more users than Snaps. AppImage is also one way to go.
It might be best just to make an AppImage, and then repackage that into a Flatpak. That would work to support both platforms without too much work. It definitely isn't the preferred method for flatpaks, but it's one that can be used if it's dependency hell to flatpak an app. @Doomsdayrs this might prove useful to you.
That just seems like more trouble than it would be worth - I'd personally support going with a Flatpak first, AppImage second
It's fairly easy to repackage an AppImage into any other format, it's basically an archive (just launch with the --appimage-extract option). I can pull up some examples of apps that do just that, if you'd like.
Appimages are cumbersome to users and opens security risks because users might be given tainted appimages from foreign sites.
Flatpak is secure, it can be distributed via repos directly so users do not need to trouble themselves with tainted appimages.
Yes they can get it from the "official" website, but not when some other 20 sites have "download cemo linux easy".
Please, dear Linux community, don't be so toxic. While I too prefer Flatpak apps for various reasons, it is also true that Snaps have some technical advantages over Flatpak, and vice versa. Just like native distro packages have advantages (and disadvantages) over both.
And this is certainly not the place where we should discuss about this.
It is ultimately the developers of Cemu who should decide to support either Flatpak or Snap, or to support any of them at all. Saying that one is better than the other without exposing technical arguments is only a waste of time for the maintainers.
In my opinion, Flatpak support would be a better fit compared to Snap for Cemu, because it is the only format supported by the major Linux game console, i.e. the Steam Deck. It also has lower startup times, which may or may not be relevant. It performs less security checks than Snap, especially once the app has been installed, but I believe that security is not as relevant for Cemu as for apps like web browsers.
Not planned for now as the focus is still appimage and flatpak. If there is a high demand for this we can revisit this discussion in the future.
