Want to get the Wii U emulator Cemu working on Linux? It's now a little easier, as they've providing an AppImage with the latest release.
Version Cemu 2.0-14 (Experimental) just went up and this is the first to offer the AppImage, which should work across various Linux distributions and perhaps make it easier on Steam Deck as well. Nice to see they keep improving it little by little, as they slowly move towards the full 2.0 release that's open source.
They're not yet providing a full changelog between the small releases of the 2.0 release, with these still being listed as the main changes since the last major release:
- Cemu is now open-source!
- Preliminary Linux builds are available on github, but be warned that they are still very rough around the edges
- Going forward, we simplified the versioning a bit by using shorter version numbers for stable releases (2.1, 2.2, 2.3..). This version (2.0) is an exception in the sense that it follows the pattern of a stable release but is very much experimental.
- Updated all dependencies. Most notably SDL (input & motion) and wxWidgets (UI)
- Fixed a crash in the H264 video decoder. Resolves crash on Smash title screen
- Made nsysnet a little less crash prone. Fixes crash in Call of Duty: Black Ops II
- Fixed a logging related crash that could occur under very specific circumstances. Seen in Wind Waker if letting the game idle on the title screen for 2 minutes
- Fixed a crash that could happen when the path to Cemu.exe contained unicode characters
- Fixed a crash that could happen when loading .elf homebrew
- The account list in the title manager save exporter is no longer empty
- Latency for wiimotes should be a bit better now
- Added symbol/function list to debugger + other small debugger/assembler improvements
- Implemented API: coreinit.FSOpenFileExAsync (used by some homebrew)
- Many more under-the-hood changes and fixes
- Some more work towards a Stop&Restart emulation feature. Not ready yet but we are getting there
Some you may have missed, popular articles from the last month:
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
I wish Appimage became more widespread. So many projects have a Linux port but don't provide a convenient way to use the thing. Meanwhile those same projects don't have a problem providing a Windows executable.
That just contribute to the bad look Linux have among Windows users "I don't use Linux because I don't want to compile a program to use it".
That just contribute to the bad look Linux have among Windows users "I don't use Linux because I don't want to compile a program to use it".
4 Likes, Who?
Between Snap, Flatpak and AppImage, I'll admit I think AppImage is my fav. Just because I love the simplicity of it.
"Here's an app, it's in a file, double click it to run it."
Beautiful simplicity. What I'd like to see is more distros improving their support for the format. Stuff like if you try to double click an AppImage file and it doesn't have executable permission, just asking the user, 'Do you want to give this AppImage file executable permission?' and stuff like a place to drag and drop AppImage files to add them to the application list.
"Here's an app, it's in a file, double click it to run it."
Beautiful simplicity. What I'd like to see is more distros improving their support for the format. Stuff like if you try to double click an AppImage file and it doesn't have executable permission, just asking the user, 'Do you want to give this AppImage file executable permission?' and stuff like a place to drag and drop AppImage files to add them to the application list.
5 Likes, Who?
Between Snap, Flatpak and AppImage, I'll admit I think AppImage is my fav. Just because I love the simplicity of it.I'm ok with the dev to decide between Flatpak and AppImage. Distros may also still decide to provide their own package, but I'm a big fan of flatpak and AppImage for any self-contained application running on top of my DE. SteamDeck only made it more necessary to have these.
"Here's an app, it's in a file, double click it to run it."
Beautiful simplicity. What I'd like to see is more distros improving their support for the format. Stuff like if you try to double click an AppImage file and it doesn't have executable permission, just asking the user, 'Do you want to give this AppImage file executable permission?' and stuff like a place to drag and drop AppImage files to add them to the application list.
Regarding integration with AppImage: For some reason, it works beautiful with my Arch-KDE System. I just double click the appimage and a GUI pops up, asking if I only want to run it once or have it integrated. This is how it should be.
Last edited by const on 7 November 2022 at 11:57 am UTC
0 Likes
I wish Appimage became more widespread. So many projects have a Linux port but don't provide a convenient way to use the thing. Meanwhile those same projects don't have a problem providing a Windows executable.
That just contribute to the bad look Linux have among Windows users "I don't use Linux because I don't want to compile a program to use it".
its not the developers fault if we dont have an standard on linux like windows have with .exe, we are just now making those techs that work across distros and even with then some distros chose to not support all of then or offer a crap support so we still have to solve "political problems" before we can solve "techinical" ones, not to mention is a bit hard to make those packages last time i checked.
but hey, if you think otherwise you can always package yourself once they relase the source code...
Last edited by elmapul on 7 November 2022 at 11:58 am UTC
0 Likes
I'm not a fan of AppImage, personally. They're arguably more portable than Flatpak, but they lack Flatpak's sandboxing. The only AppImage I use is for Balena Etcher, because there's not Flatpak available.
0 Likes
I wish Appimage became more widespread. So many projects have a Linux port but don't provide a convenient way to use the thing. Meanwhile those same projects don't have a problem providing a Windows executable.
That just contribute to the bad look Linux have among Windows users "I don't use Linux because I don't want to compile a program to use it".
its not the developers fault if we dont have an standard on linux like windows have with .exe, we are just now making those techs that work across distros and even with then some distros chose to not support all of then or offer a crap support so we still have to solve "political problems" before we can solve "techinical" ones, not to mention is a bit hard to make those packages last time i checked.
but hey, if you think otherwise you can always package yourself once they relase the source code...
Sorry, I don't agree. If you have a app and are releasing it out there for people to use, you can do your part to easy things for the end user, just like you do with the Windows executable. Appimage is not a new thing, and way before it, some devs just released a compressed file with precompiled stuff and their dependencies. Just drop it on a folder and off you go. Mozilla does it for ages with Firefox and Thunderbird.
Some devs, even the ones doing commercial stuff, just don't get it, or blatantly refuse, to accept that not all Linux users feel comfortable with the command line. It is a attitude problem. The old excuse for lack of standardization doesn't cut anymore.
4 Likes, Who?
I wish Appimage became more widespread. So many projects have a Linux port but don't provide a convenient way to use the thing. Meanwhile those same projects don't have a problem providing a Windows executable.
That just contribute to the bad look Linux have among Windows users "I don't use Linux because I don't want to compile a program to use it".
its not the developers fault if we dont have an standard on linux like windows have with .exe, we are just now making those techs that work across distros and even with then some distros chose to not support all of then or offer a crap support so we still have to solve "political problems" before we can solve "techinical" ones, not to mention is a bit hard to make those packages last time i checked.
but hey, if you think otherwise you can always package yourself once they relase the source code...
Sorry, I don't agree. If you have a app and are releasing it out there for people to use, you can do your part to easy things for the end user, just like you do with the Windows executable. Appimage is not a new thing, and way before it, some devs just released a compressed file with precompiled stuff and their dependencies. Just drop it on a folder and off you go. Mozilla does it for ages with Firefox and Thunderbird.
Some devs, even the ones doing commercial stuff, just don't get it, or blatantly refuse, to accept that not all Linux users feel comfortable with the command line. It is a attitude problem. The old excuse for lack of standardization doesn't cut anymore.
yeah i already download those tar.gz where you suppose to extract and run the stuff.
but often they dont work, there is a reason for that.
0 Likes
I'm not a fan of AppImage, personally. They're arguably more portable than Flatpak, but they lack Flatpak's sandboxing. The only AppImage I use is for Balena Etcher, because there's not Flatpak available.
I've been curious about it. I really wonder why anyone would be interested in sandboxing, as an end-user.
I mean, since Firefox is a snap on Ubuntu and "benefits" sandboxing, all HTML pages located in /usr/local/ are unopenable, several extensions I used (ex: VideoDownloadHelper and its companion app) no longer work (for "valid" reasons, still, it's a PITA)...
Aside from the added security for apps you don't trust (which by definition I tend to avoid installing in the first place), what's in it for the average Joe ?
2 Likes, Who?
They're not yet providing a full changelog between the small releases of the 2.0 release
You can compare tags
https://github.com/cemu-project/Cemu/compare/v2.0-13...v2.0-14
0 Likes
Thanks but I am aware of it, it's not very friendly for users to go over commit logs :)They're not yet providing a full changelog between the small releases of the 2.0 release
You can compare tags
https://github.com/cemu-project/Cemu/compare/v2.0-13...v2.0-14
2 Likes, Who?
i liek appimage and flatpack both for different reasons. appimage is nice for stuff like github or a random obscure app, and flatpack for 'app stores' experiences or things that should be sandboxed. both have a place
1 Likes, Who?
i liek appimage and flatpack both for different reasons. appimage is nice for stuff like github or a random obscure app, and flatpack for 'app stores' experiences or things that should be sandboxed. both have a placeI think the main reason I prefer flatpak is based on discoverability. Also it currently will usually integrate smoother. Appimage does... but then you need appimage launcher.
0 Likes
I agree with most sentiments here, I def prefer AppImage over snaps and flatpaks. I just wish they integrated better and had better ways to update -- sure, some of them can be updated with tools, but not all of them, and most of the time it's janky regardless.
Though as far as preference goes, I wish they were just packages. Thankfully Cemu can just be built directly.
Though as far as preference goes, I wish they were just packages. Thankfully Cemu can just be built directly.
0 Likes
I wish Appimage became more widespread. So many projects have a Linux port but don't provide a convenient way to use the thing. Meanwhile those same projects don't have a problem providing a Windows executable.While I think AppImages are good, the devs of it don't help adoption when in the past (idk how long it's been) they said some things about the OBS Project because they only had flatpak and I think tried to say because RedHat became a sponsor of OBS that they then added flatpak, some crazy stuff like that.
That just contribute to the bad look Linux have among Windows users "I don't use Linux because I don't want to compile a program to use it".
0 Likes
Between Snap, Flatpak and AppImage, I'll admit I think AppImage is my fav. Just because I love the simplicity of it.Yeah, I do like the java approach they employ as well, that's also why I like java, although admittedly java does have the extra step of needing the jre but I think recently they added a way to bundle the jre in the app (think it's jpackage)
"Here's an app, it's in a file, double click it to run it."
Beautiful simplicity. What I'd like to see is more distros improving their support for the format. Stuff like if you try to double click an AppImage file and it doesn't have executable permission, just asking the user, 'Do you want to give this AppImage file executable permission?' and stuff like a place to drag and drop AppImage files to add them to the application list.
1 Likes, Who?
Sounds like you have AppImageLauncher perhaps as I recognize the gui you are describingBetween Snap, Flatpak and AppImage, I'll admit I think AppImage is my fav. Just because I love the simplicity of it.I'm ok with the dev to decide between Flatpak and AppImage. Distros may also still decide to provide their own package, but I'm a big fan of flatpak and AppImage for any self-contained application running on top of my DE. SteamDeck only made it more necessary to have these.
"Here's an app, it's in a file, double click it to run it."
Beautiful simplicity. What I'd like to see is more distros improving their support for the format. Stuff like if you try to double click an AppImage file and it doesn't have executable permission, just asking the user, 'Do you want to give this AppImage file executable permission?' and stuff like a place to drag and drop AppImage files to add them to the application list.
Regarding integration with AppImage: For some reason, it works beautiful with my Arch-KDE System. I just double click the appimage and a GUI pops up, asking if I only want to run it once or have it integrated. This is how it should be.
1 Likes, Who?
I wish Appimage became more widespread. So many projects have a Linux port but don't provide a convenient way to use the thing. Meanwhile those same projects don't have a problem providing a Windows executable.
That just contribute to the bad look Linux have among Windows users "I don't use Linux because I don't want to compile a program to use it".
its not the developers fault if we dont have an standard on linux like windows have with .exe, we are just now making those techs that work across distros and even with then some distros chose to not support all of then or offer a crap support so we still have to solve "political problems" before we can solve "techinical" ones, not to mention is a bit hard to make those packages last time i checked.
but hey, if you think otherwise you can always package yourself once they relase the source code...
Sorry, I don't agree. If you have a app and are releasing it out there for people to use, you can do your part to easy things for the end user, just like you do with the Windows executable. Appimage is not a new thing, and way before it, some devs just released a compressed file with precompiled stuff and their dependencies. Just drop it on a folder and off you go. Mozilla does it for ages with Firefox and Thunderbird.
While it is nice, I don't think it is or should be an expectation (that's how the bolded text in the quote comes across to me, kind of like geez, the least you can do after making an app for free and releasing the source for anyone to do with as they please is to support my preferred packaging format, if I got the impression/way it came across wrong, please let me know), it is remarkable developers as they are put time and effort into open source projects with no guarantee of financial support (or possibly any support as some open source projects are largely or entirely a one man team). I think it is the job of the packaging formats to make it as easy as possible to integrate with any project to make it enticing and preferably low maintenance to implement for the developer.
0 Likes
I suppose, but the packaging formats are also open source, so if you're going down the "open source developers shouldn't have to make things easy for their users" road that would apply to the packaging format developers as well . . .I wish Appimage became more widespread. So many projects have a Linux port but don't provide a convenient way to use the thing. Meanwhile those same projects don't have a problem providing a Windows executable.
That just contribute to the bad look Linux have among Windows users "I don't use Linux because I don't want to compile a program to use it".
its not the developers fault if we dont have an standard on linux like windows have with .exe, we are just now making those techs that work across distros and even with then some distros chose to not support all of then or offer a crap support so we still have to solve "political problems" before we can solve "techinical" ones, not to mention is a bit hard to make those packages last time i checked.
but hey, if you think otherwise you can always package yourself once they relase the source code...
Sorry, I don't agree. If you have a app and are releasing it out there for people to use, you can do your part to easy things for the end user, just like you do with the Windows executable. Appimage is not a new thing, and way before it, some devs just released a compressed file with precompiled stuff and their dependencies. Just drop it on a folder and off you go. Mozilla does it for ages with Firefox and Thunderbird.
While it is nice, I don't think it is or should be an expectation (that's how the bolded text in the quote comes across to me, kind of like geez, the least you can do after making an app for free and releasing the source for anyone to do with as they please is to support my preferred packaging format, if I got the impression/way it came across wrong, please let me know), it is remarkable developers as they are put time and effort into open source projects with no guarantee of financial support (or possibly any support as some open source projects are largely or entirely a one man team). I think it is the job of the packaging formats to make it as easy as possible to integrate with any project to make it enticing and preferably low maintenance to implement for the developer.
Obviously open source developers don't have to do anything. But whether open source or otherwise, if they want to say they've written "good" software, part of that is making it easy to use, which includes packaged in a way that makes it easy to run in the first place, or for packagers includes making it easy to package things with their system.
2 Likes, Who?
I suppose, but the packaging formats are also open source, so if you're going down the "open source developers shouldn't have to make things easy for their users" road that would apply to the packaging format developers as well . . .I wish Appimage became more widespread. So many projects have a Linux port but don't provide a convenient way to use the thing. Meanwhile those same projects don't have a problem providing a Windows executable.
That just contribute to the bad look Linux have among Windows users "I don't use Linux because I don't want to compile a program to use it".
its not the developers fault if we dont have an standard on linux like windows have with .exe, we are just now making those techs that work across distros and even with then some distros chose to not support all of then or offer a crap support so we still have to solve "political problems" before we can solve "techinical" ones, not to mention is a bit hard to make those packages last time i checked.
but hey, if you think otherwise you can always package yourself once they relase the source code...
Sorry, I don't agree. If you have a app and are releasing it out there for people to use, you can do your part to easy things for the end user, just like you do with the Windows executable. Appimage is not a new thing, and way before it, some devs just released a compressed file with precompiled stuff and their dependencies. Just drop it on a folder and off you go. Mozilla does it for ages with Firefox and Thunderbird.
While it is nice, I don't think it is or should be an expectation (that's how the bolded text in the quote comes across to me, kind of like geez, the least you can do after making an app for free and releasing the source for anyone to do with as they please is to support my preferred packaging format, if I got the impression/way it came across wrong, please let me know), it is remarkable developers as they are put time and effort into open source projects with no guarantee of financial support (or possibly any support as some open source projects are largely or entirely a one man team). I think it is the job of the packaging formats to make it as easy as possible to integrate with any project to make it enticing and preferably low maintenance to implement for the developer.
Obviously open source developers don't have to do anything. But whether open source or otherwise, if they want to say they've written "good" software, part of that is making it easy to use, which includes packaged in a way that makes it easy to run in the first place, or for packagers includes making it easy to package things with their system.
I mean, I think the fact that most users don't need to learn how to program and make the programs themselves I'd definitely say makes it infinitely easier for the users, is it nice to have precompiled binaries for your platform and distro, yes, but I mean with all the work that goes into these programs, is it too hard to read the compilation docs or look online how to compile x program (if compilation file isn't supplied), it's difficult as for some apps (normally C in my experience), you definitely need compiled binaries (as even when following instructions, you will still get errors sometimes and you are relying on the documentation being up to date), but most other languages have a.... simpler build system, as java is my best language, I will talk about that, with Java, you have default java compiler or you can use build systems like Maven or Gradle and for maven, it's just `mvn package` and for gradle it's `gradle build`. I definitely am not against compiled binaries or some crazy, compile everything from source guy (no offense to gentoo users and such) but I just don't know if we should have too big of standards for developers, although I suppose no one is holding an developer to any standard but the standard the dev puts on themself but I think you get what I mean, putting extra pressure on devs when they already do a lot.
0 Likes
Sounds like you have AppImageLauncher perhaps as I recognize the gui you are describingBetween Snap, Flatpak and AppImage, I'll admit I think AppImage is my fav. Just because I love the simplicity of it.I'm ok with the dev to decide between Flatpak and AppImage. Distros may also still decide to provide their own package, but I'm a big fan of flatpak and AppImage for any self-contained application running on top of my DE. SteamDeck only made it more necessary to have these.
"Here's an app, it's in a file, double click it to run it."
Beautiful simplicity. What I'd like to see is more distros improving their support for the format. Stuff like if you try to double click an AppImage file and it doesn't have executable permission, just asking the user, 'Do you want to give this AppImage file executable permission?' and stuff like a place to drag and drop AppImage files to add them to the application list.
Regarding integration with AppImage: For some reason, it works beautiful with my Arch-KDE System. I just double click the appimage and a GUI pops up, asking if I only want to run it once or have it integrated. This is how it should be.
Yep, seems like that. This should come with every distro, really convenient.
1 Likes, Who?
See more from me