I'm already using the actual successor to Citra from here for my other 3DS emulation needs. I needed an old build of Citra from before the texture pack rewrite for the texture pack to work, using some meme fork based on the last Citra commit obviously wasn't going to be the solution.
leopold
joined 1 year ago
No reason to use it outside of a Steam Deck IMO. Compared to other immutable distros, SteamOS makes things pretty difficult if the thing you're trying to run isn't on Steam, Flathub or AppImage. Can't just layer. Have to set up stuff like Nix yourself. Distro doesn't come with gcc/make/cmake, so good luck building from source if you ever need to. It's fine for a handheld PC, but as a power user I would never want it on my desktop. Not to mention the whole Gaming Mode/Big Picture GUI is just very limited and you have to constantly work around its limitations if you want to use it for anything other than Steam games.
I had an instance of SteamOS making things unnecessarily difficult yesterday. I wanted to use a Pokemon Ultra Sun/Ultra Moon HD texture pack for Citra. However, about a year ago there was a major rewrite of Citra's texture pack code which broke a few older texture packs, including that one. The author recommended using Nightly 1880 at the latest for the texture pack to work correctly. However, last month, the Github repository for Citra was taken down and all of the old prebuilt binaries went down with it. Many mirrors of the repository exist, but they at best only offer the last nightly for download. On any normal Linux distro, this would be a trivial problem to solve. Clone one of the many mirrors of the Citra repository, rollback to whichever commit corresponds to Nightly 1880 and compile. Can easily be done in ten minutes. But on SteamOS, you can't do that. What I had to do instead was going to the old Citra Github repository through archive.org and somehow finding an archived download for the latest Linux build of Citra released before 1880. This took a while, but I was eventually able to find a download for Nightly 1816, which I deemed close enough. Great. Except it didn't launch. Because it was linking to some shared objects SteamOS did not have.
So I had to go to the Debian website and download deb files for Debian Buster that included the so files Citra wanted. I unpacked the debs into the Citra directory and created a shell script that simply launched Citra with LD_LIBRARY_PATH pointing to the libraries I'd downloaded. I had to to get at least a dozen libraries from Debian before Citra finally stopped complaining about missing so files and successfully launched. Then I had to reconfigure this second Citra build to match my preferences and transfer my Ultra Sun save file to it. I also had to change my Steam library entry for Ultra Sun to point to the shell script. Oh and I obviously also had to install the texture pack. And then I finally had the texture pack working. After hours of work. When it would've taken twenty minutes at worst on any other distro. Yeah, in retrospect, fuck SteamOS.
There is fragmentation in FOSS image editing. There's GIMP, Krita, Pinta, RawTherapee, DarkTable, Digikam and a few others. But it's good fragmentation. FOSS image editing is in fact in a much better place than FOSS video editing right now.
GIMP is focused on being a good general purpose image editor. Krita is focused on being a good digital art program. Pinta is focused on being a more basic, beginner-friendly image editor. RawTherapee/DarkTable/Digikam are focused on professional photography, with the latter in particular focused on library management. And they all do at least a decent job at accomplishing what they set out to do. If you as a photographer find that GIMP just isn't doing it, you can try DarkTable and will likely find what you were looking for. If you're an artist and GIMP isn't good enough, you can simply use Krita.
Where's this variety with video editing when everything is just trying to be a general purpose video editor? I'll acknowledge that the "simplified video editor" use case is covered by OpenShot and Pitivi. I'll also acknowledge that there are dedicated editors for animation (OpenToonz, Krita) and VFX (Natron). What about everything else? Instead of having different video editors for different use cases, you have at least six editors trying and failing at trying to do everything.
Say you aren't satisfied with Kdenlive, what should you use instead? Maybe Blender has the feature you want, but then maybe it's missing another feature you depended on in Kdenlive. Maybe Cinelerra has both features, but is missing a third one you also need. By the time you've tried all of the available options, you've wasted a lot of time and have found no editor suitable for your usecase. Do you just constantly switch back and forth between two or three editors which combined have all the features you want? Well, you can try. Switching between image editors is easy. There are many standard lossless formats you can export to and you can even directly import GIMP or Photoshop project files in other editors like Krita and Digikam. How do you open your Kdenlive project in Blender or vice versa? Should you encode every time you want to switch? Lossless video can easily take hundreds of gigabytes, lossy video means a loss in quality, both mean several hours spent waiting for encode to finish. Obviously not viable. So really you have to pick one editor and hope it does everything you want, because switching mid-project is impossible.
Or Blender? Or Cinelerra? Or ShotCut? Or OpenShot? Or Olive? Or Pitivi? The open source video editing landscape is frustrating. So many competent projects competing with each other, none of which have clear superiority. And nothing that comes close to the proprietary offerings. Feels like we might be closer if developers weren't split eight-ways.
Dunno. All I know is it's tied to supporting reclocking on newer Nvidia GPUs. This is something the Nouveau kernel driver already supports, so I guess this is just rewriting in Rust for the sake of rewriting in Rust.
WebKitGTK is only native for GTK desktops. On Qt desktops, you'd want QtWebEngine instead.
There is no HDR protocol for Wayland, so Wayland compositors cannot display HDR content. X11 also does not have HDR support, so window managers can't do it either. Games don't draw their own windows. If the compositor doesn't support HDR, the game isn't gonna be displayed in HDR. If the compositor doesn't support VRR, then VRR is also not going to work. Plasma 6 implements a custom Wayland HDR protocol which is also implemented by the Steam Deck. This allows it to display HDR content. It has also had VRR support for a few years. GNOME is waiting for the official HDR protocol for Wayland to be complete before implementing support, so it doesn't have it. It also didn't have VRR until relatively recently.
If you don't believe this, then can you explain why Plasma devs have been advertising HDR support as one of Plasma 6's killer features? Can you explain the purpose of this recently merged VRR merge request for Mutter? What is the purpose of this merge request for a color management/HDR Wayland protocol which has been in the works for years? If compositors have no involvement in HDR or VRR, then why are their developers working their asses off to make it work? And most importantly, can you show me HDR on Linux working in GNOME? Or Cinnamon? Or anything that's not Plasma or Gamescope?
I'm pretty sure the sandbox level is chosen by the developers of any given application. Flatseal only exists for users to change the sandbox settings the developers have chosen.
No. This is just a thing Discover does. Unless nearly every update I've done for every Flatpak I have installed on my Steam Deck have actually been downgrades.
try KvLibadwaita. otherwise, you can install gnome apps on plasma and use those instead of kde apps.
Tauri uses webkitgtk everywhere, including KDE.