The problem is that games don’t run at all or require major effort to run without issues.

A major cause for that is the distro - when it comes to gaming, the distro makes a huge difference as I outlined previously. The second major cause is the flavor of Wine you chose (Proton-GE is the best, not sure what you used). The third major cause is checking whether or not the games are even compatible in the first place (via ProtonDB, Reddit etc) - you should do this BEFORE you recommend Linux to a gamer.

In saying all that, I’ve no idea about pirated stuff though, you’re on your own on that one - Valve and the Wine developers obviously don’t test against pirated copies, and you won’t get much support from the community either.

Unfortunately you chose the wrong distro for your friend - Linux Mint isn’t good for gaming - it uses an outdated kernel/drivers/other packages, which means you’ll be missing out on all the performance improvements (and fixes) found in more up-to-date distros. Gaming on Linux is a very fast moving target, the landscape is changing at a rapid pace thanks to the development efforts of Valve and the community. So for gaming, you’d generally want to be on the latest kernel+mesa+wine stack.

Also, as you’ve experienced, on Mint you’d have to manually install things like Waydroid and other gaming software, which can be a PITA for newbies.

So instead, I’d highly recommend a gaming-oriented distro such as Nobara or Bazzite. Personally, I’m a big fan of Bazzite - it has everything you’d need for gaming out-of-the-box, and you can even get a console/Steam Deck-like experience, if you install the -deck variant. Also, because it’s an immutable distro with atomic updates, it has a very low chance of breaking, and in the rare ocassion that an update has some issues - you can just select the previous image from the boot menu. So this would be pretty ideal for someone who’s new to Linux, likes to game, and just wants stuff to work.

In saying that, getting games to run in Linux can be tricky sometimes, depending on the game. The general rule of thumb is: try running the game using Proton-GE, and if that fails, check Proton DB for any fixes/tweaks needed for that game - with this, you would never again have to spend hours on troubleshooting, unless you’re playing some niche game that no one has tested before.

As an actual M1+Asahi user and a gamer: Asahi is not there yet. Right now, if you’re on macOS, Crossover (or Porting Kit) and/or Parallels is able to run more games and with better performance compared to Asahi (using krun + FEX). Also, Steam on macOS (non-native) is much more peformant compared to Asahi, where it’s currently slow and glitchy.

But that will all change in the future once the Vulkan driver and TSO patches are ready. FEX is also seeing a lot of improvements, so by the end of the year, there’s a good chance that gaming on Asahi would be much better than macOS.

The best option is to just support the developer/project by the method they prefer the most (ko-fi/patreon/crypto/beer/t-shirts etc).

If the project doesn’t accept any donations but accepts code contributions instead (or you want to develop something that doesn’t exist), you can directly hire a freelancer to work on what you want, from sites like freelancer.com.

That’s a shame. I hope someone continues a fork and calls it Shinyaku Toaru.

I am not a fan because they install all that WINE stuff on the system level which is a huge security degradation.

I disagree with this. Sure, it could be made more secure, but Wine, on it’s own isn’t, any greater security risk compared to any other scripting runtime such as say Python, which is also installed at the system level. Ultimately it’s up to the user to get their executables from trustworthy sources - and whether it’s a random bash script or an exe, doesn’t really make a difference.

As for Firefox, if you’re truly concerned about security then you wouldn’t be using it in the first place, you’d be using Librewolf, which you can install without any issues.

I am! I run it both on my gaming PC and laptop.

But it doesn’t seem like a “typical” distro for a daily driver? How does Bazzite for example differ from Nobara which is another gaming-oriented distro?

Well, for starters, if you get the Bazzite-deck edition, your PC boots straight into Steam’s game mode - in this mode, everything runs thru gamescope so you get all the awesome benefits like being able to use FSR even with games that don’t support it, HDR and more. You get a console-like experience on PC, and it’s awesome.

Another cool thing about this mode is that all your updates - including OS, Flatpak, firmware/BIOS, container, Nix, pip etc - all of it is presented as if it’s a Steam update like in SteamOS - and it’s automatic too, and it doesn’t interrupt your gaming experience. Basically a unified update backend and frontend, which is awesome.

Compared to Fedora/Nobara, one advantage this has is that the updates are image based and atomic, so when you reboot, the new update goes live instantly so there’s no wait-time. Another advantage is that your previous image is available in the GRUB menu, so in case the update broke something, you can always boot from the previous image - no need to even restore anything, no need to edit your fstab etc (unlike btrfs snapshot restores where the subvolid changes). And you can also pin “good” images to your GRUB menu (and I highly recommend doing that), so you can always fall back to a known good version. This came in handy on my laptop recently where after one of the Feb updates I was experiencing some weird graphics corruption in game mode, but thanks to image pinning I always had a working image to fall back to. Also, the rebase feature allows you to go back and forth between 90 days of images (stored on github), so it’s easy to switch between various versions for testing. The rebase is also interesting because with just a single command you can switch between any other Fedora Atomic distro, so if you’re bored of Bazzite or you want to try out a new DE, it’s just one command to switch. And with pinning, you can always switch back instantly.

Finally, there’s the whole immutability aspect. Personally I’m ambivalent on this, but the fact that it allows image/atomic updates (with easy rollbacks/rebases), I think of it more as a convenience - especially on a gaming-oriented machine, where I just wanna jump straight into my games without worrying about updates and broken systems.

So having used Fedora, Nobara, and finally Bazzite, I can highly recommend Bazzite as a daily driver - and it’s 100% worth switching. AMA.

This is my my phone running Debian with XFCE:

This looks nice, good job!

On a related note, does anyone have any good reasons as to why I should be using Restic instead of Borg? (my Borg backups are all local btw - generally they’re snapshots of various projects I’m working on, so I don’t need any cloud features).

I’m a Flatpak user myself, but a lot of those arguments against AppImage are outdated or invalid. Here are my counterpoints:

Usability issues

GearLever solves all the problems mentioned.

Updates

There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don’t want to use GearLever, there are other updaters like AppImageUpdate.

The lack of repositories
Appimages don’t even have a central place where you can find them, not to mention download them.

This is blatantly wrong - AppImageHub exists for this very reason. There are also GUI frontends like AppImagePool which makes it easy to discover/download/install them.

Lack of Sandboxing

That is a fair point, however, AppImage never claimed to be a sandboxing solution, and for some use-cases this can even be seen as an advantage (any Flatpak user would’ve at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes). But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you’re actually running an untrusted app.

Random location
[…] A necessary step would be mounting the entire /home non-executable. This is no problem for system apps, or Flatpaks, but where do you put Appimages now?

There would need to be a standard directory to put such files in, which is normally the PATH. But this is also the easiest attack goal for malware, so PATH would be non-executable as well.

I completely disagree with making the entirety of /home as non-executable, when $HOME/.local/bin is recommended by the XDG standard as a place to store executables. As long as $HOME/.local/bin is in the XDG spec, I’ll continue storing my executables there. If you disagree, go argue with the XDG guys.

Duplicated libraries

This is a fair point but “they include all the libraries they need” is the entire point of AppImage - so mentioning this is pointless.

If users would really install every Software as Appimages, they would waste insane amounts of storage space.

Then it’s a good thing that they don’t right? What’s the point of making hypothetical arguments? Also, this is 2024, storage is cheap and dedicating space for your applications isn’t really a big deal for most folks. And if storage space is really a that much of a concern, then you wouldn’t be using Flatpak either - so this argument is moot and only really valid for a hypothetical / rare use-cases where storage is a premium. And again, in such a use case, that user wouldn’t be using Flatpaks either.

Finally, some distros like Bazzite already have the above integrations built-in (GearLever/AppImagePool), so you don’t even need to do anything special to get AppImages integrated nicely in your system, and there’s nothing stopping other distros adding these packages as optional dependencies - but it’s kinda moot at this point I guess since Flatpak has already won the war.

Personally, I’m pro-choice. If AppImage doesn’t work for you, then don’t use it, as simple as that. Stop dictating user choice. If AppImage is really as bad as you claim, then it’ll die a natural death and you don’t have to worry about it. What you really need to worry about is Snap, which has the backing of Canonical, and some dev houses new to the Linux ecosystem seem to think packing stuff as Snap is an acceptable solution…

https://stats.fm/d3xt3r_nz

Yep it’s a BSD thing (and deviations down the line), but you can amend your $PATH so that the homebrew GNU variants take precedence. Obviously you’d only set this for your user/shell, otherwise it’d cause issues with system-wide tools that expect the macOS variants.

Even in an IT job I prefer using my own gear (laptop+keyboard+mouse). Corporate laptops (+ peripherals) almost always universally suck. Therfore I won’t accept a job unless they have a decent BYOD scheme. At my current workplace for instance, most of our core apps are cloud-based already, and for the few legacy apps, we can access via Citrix; plus they also reimburse me (to an extent) for using my own laptop, which is nice. With my own gear, I can spec it however I want and use my own favorite apps, without needing to go thru approvals and red tape, and more importantly - I can use my own distro/DE of choice. Like, imagine if a company offered Linux laptops, but you were forced to use Ubuntu or something worse like Oracle Linux… So yea, BYOD FTW.

@[email protected] if I were you, I’d ask if BYOD is an option, and if so what their BYOD scheme is like. As a Linux person, it’s always better to use your own gear, than whatever el cheapo locked-down system the company offers.

Have you ever been in a… in a Turkish prison?

Pizza, followed by dessert.

These are work files and shared between teams, so I’d rather maintain 100% MSO compatibility. :) Also, most of the time these files are on Sharepoint or OneDrive, so it makes it convenient to edit with M365 - don’t need to save files locally and re-upload/sync them.

It’s based on Ubuntu LTS, so it’s not for me. Doesn’t make sense that you’d want a bleeding-edge DE on an old kernel and system stack. I mean, I can understand if you’re a KDE dev and you want a stable base to dev and test on, but if you’re just a power user who wants to play with the latest and greatest, then using Ububtu makes no sense at all.

I ain’t no hardcore Excel user so can’t speak for others, but I’ve been able to completely switch to Excel Online and use Office Scripts and Power Automate for tasks for which I used VBA previously. In fact, Power Automate has been great for doing stuff like updating workbooks through scheduled or event-driven flows, without even having to open Excel. I can see VBA going away soon with these technologies.

With the state of O365 these days, there’s zero need for me to have a native MSO install, and this no need for a Windows VM either (for day-to-day/personal stuff). The only reason I still keep Windows VMs though is for occasionally testing random things for work.

I don’t know about car stereos, but at least for 8bitdo controllers, you can update the firmware via fwupd. And if the firmware isn’t available on LVFS, you can download the blob install it manually using fwupd: https://ladis.cloud/blog/posts/firmware-update-8bitdo.html

I did this for my 8bitdo Ultimate Bluetooth controller, and it worked great.

8MB?! That is abysmally low for KDE. Depending on the apps you’re using, I’d recommend allocating at least 256MB, if you’re going to use it for actual productivity tasks.

Edit: Here’s a screenshot from nvtop showing my VRAM usage on KDE 5.27:

As you can see, Plasma alone is using 209MB, and Kwin 175MB, and this is with nothing but just Plasma and Konsole running on a very basic desktop (no fancy widgets, just one panel). Now this is at 2880x1800, so if your VM is running at a lower resolution you’d need lesser VRAM, but you can use that as a reference to see how much VRAM KDE really needs.