Referencing my comment in the other thread, Facepunch employees keep being disingenuous about this claim. Even if it is true, due to how unplayable Facepunch made the Linux build a short while before they axed it for “a rampant cheating problem”, this claim does not have enough evidence. The linked comment goes into some more detail, but it is insane how much the developers keep doubling down on their disinformation.

To note, even if the claim of ‘more cheaters than Linux players’ at the end of lifecycle is true, it is a blatant lie by omission. I played Rust from 2016 til shortly after the game went out of Early Access. I stopped playing because Facepunch had completely ruined the Linux builds of the game by removing the long-standing OpenGL output and forcing the new (at the time to Unity) and completely untested Vulkan output as the only option on Linux. For anyone unfortunate enough to experience playing Rust at the end of its Linux run, the game would regularly have major graphical glitches and various rendering errors, including graphical artifacting that would be seizure inducing. If you are prone to epilepsy or otherwise sensitive to bright or flashing lights, please do not click this link. To note, the attached video is a mild case of what commonly happened when playing. That is, if the crashes and many hardware just no longer being able to launch the game properly didn’t impede that.

Given all of that, I genuinely wouldn’t be surprised if the only “people” running the Linux client were actually cheat bots because there is no way many people were actually still playing the absolute rugpull of a game toward the end of its life.

Actually, you don’t have to via terminal! For OpenSUSE, you can use YaST to enable Packman and RPMFusion provides instructions to download the primary repo packages in a browser. Additionally, there is a more generic and slightly more technical way of providing repo URLs and managing additional repos from within PackageKit frontends like Discover. There is currently the point against RPMFusion that the Appstream data isn’t automatically configured upon update after adding the repos due to a bug in dnf5. Supposedly this is fixed now, but I haven’t verified the functionality again in a fresh setup. I’ll update this post later if it is indeed fixed.

Edit:

Tested Fedora 43 and Tumbleweed in VMs for quirk updates.

Tumbleweed’s third-party repos (NVidia, Packman at least) still don’t have Appstream data, meaning packages have to be installed through YaST, but can be updated through PackageKit frontends.

The particular DNF5 bug is fixed and functional, but PackageKit frontends don’t actually pull the appropriate packages in (perform group updates). This does mean that unfortunately there is at least one terminal command needed (dnf update @core) before jumping back to GUI and going from there.

So, mostly terminal-free on Fedora and still terminal-free on OpenSUSE, just with little freedom of installer choice.

If you happen to remember, what DE’s/WM’s did you use back when testing with your NVidia cards (particularly the 2080 and 3070)? I’ve been trying to gauge a lot of differences in DE usability, and driver versions. In my recent testing, one user on Fedora KDE 42 with the NVidia-open drivers with a 4070 have had a nearly-flawless experience that would be pretty much on par with AMD or Intel. Meanwhile a 1080ti user genuinely had major problems with both KDE and GNOME on the same distro with the standard proprietary drivers.

As for how much the average user needs to use the terminal on modern distros, especially with some of the graphical tools available, it genuinely is very little, if any at all. I think there is more of a problem with how many guides written go for the least common denominator approach of straight terminal commands for every tweak or fix somebody might look up. It is to a point where I might start attempting to write a series of guides and/or short-form videos for a lot of the more common ‘how-to’ and frequent problems that many users might encounter, both for GNOME and KDE at least.

I definitely forgot about it when writing but was definitely criteria for me when choosing my current desktop distro and the lineage of server distros was having some sort of MAC component (SELinux or AppArmor) with configured policies available in the distro repos. While it could be argued that a MAC component isn’t that necessary for desktop, I do believe for the rising marketshare of the Linux desktop that having the second stage of exploit protection will help mitigate some more severe malware attacks.

I do wonder about PikaOS and CachyOS as recommendations for specifically how the packaging and rollback availability is done on them. I’ll be taking a look at both later in VMs to see how they function to an end-user. CachyOS seems to rebuild the Arch packages for newer x86 architecture and other optimizations specifically among other tweaks such as the modified kernel. Then there is PikaOS which is based on Debian Sid but apparently has patches on top of. I am not currently sure to what extent the patching is and if the project is attempting to catch breakages and regressions that make it into Sid.

There is the other point I have of more ‘niche’ distros like PikaOS, CachyOS, and Nobara, Bazzite to a lesser extent. I do wonder of the longevity of many of them. If not from developer burnout, financials, or the other standard culprits but from much of what makes the distros currently unique being absorbed by more mainstream distros. The work that projects like CachyOS, Nobara, and PikaOS are certainly important, but I feel that things like the higher x86 build targets, kernel patches, etc. will eventually make it into the upstream projects as well. PikaOS will probably have a longer lifespan than say CachyOS due to Debian likely will be among the last distros to drop support for older x86_64 processors, but I think the point does stand. Will the current ‘testbed’ distros still remain in say 5-10 years?

My big thing with recommending Arch and ‘direct’ derivatives (those that don’t repackage the Arch repositories with their own package versions). Is that Arch explicitly recommends for users to always read the latest release notes on the archwiki homepage before any upgrade, due to breakages sometimes being let in. This either means that every user will need to be their own system maintainer and input their judgement into each update or will need snapshots to restore to and the hope that breaking changes will eventually fix themselves out, if they don’t want to reconfigure parts of their OS themselves. If direct derivatives implement automatic btrfs system snapshots that can be selected from like OpenSUSE Tumbleweed does, I think such a derivative could be recommended to more experienced computers users in lieu of other distros like Fedora or Tumbleweed.

I definitely think COSMIC will be quite good, based on the progress I’ve seen. We’ll have to see how many of the relevant Wayland protocols are implemented in the stable releases, but it could be a good recommendation given that System76 seem to care about not breaking desktop applications for reasons. I just don’t recommend it now because it is still in beta.

I do believe I wasn’t specific enough in what I mean in some places. I did add the ‘(yet)’ portion for Pop! OS and Linux Mint because I am fairly aware of and tracking the efforts of COSMIC and Cinnamon (Wayland). While in the grand scheme it’s not going to be a major point, I do think System76 missed the mark on providing a 24.04 release in a timely manner. The current stable release target is still earlier than I would have expected, but will release much closer to upstream 26.04 than upstream 24.04, that some effort in porting Pop! Shell to 24.04’s GNOME version without any feature changes (essentially maintenance mode) would have been better than what will be ~1 year gap for LTS users to upgrade to the latest LTS release. Linux Mint by comparison still having regular releases while their Wayland version of the Cinnamon desktop is arguably a better route for their active userbase. By all means, when Pop! OS and Linux Mint get their Wayland releases out, I will be adding them possibly not as top recommendations depending on Wayland protocol inclusion, but decently high (and probably above straight GNOME).

Also, for my LTS recommendations I should probably clarify that I do intend to recommend LTS specifically for those that aren’t going to care about the latest features, will probably have the install done by myself anyways, and won’t want to be hassled by regular feature upgrades. A lot of my older family members that would have originally happily kept using Windows XP if I didn’t have them stop connecting those systems to the internet for security reasons are the target audience of ‘basic computing’ that an LTS distro. When recommending for gamers, creatives, developers, and other more involved users that need more out of their computers, and likely have newer hardware is where I swing heavily toward Fedora and OpenSUSE Tumbleweed, because their needs and desires will genuinely get hindered by the older packages of most LTS unless they can rely solely on Flatpaks, which means they could get away with using Aurora or Bazzite even.

Realistically, any LTS distro from a netinstaller or minimal image that can use a kiosk compositor like cage. So, the usual suspects of Debian, OpenSUSE, AlmaLinux, RockyLinux (or a derivative of one if the native distro doesn’t support Raspberry Pi). Then you just have cage open the browser of choice on startup (e.g. chromium --kiosk <url>) and you have a lightweight and relatively secure web kiosk.

Nvidia 9, 10-series support is quite poor. Your experience at best will still be worse than AMD, Intel, or more modern Nvidia cards running the nvidia-open kernel modules with the latest Nvidia drivers.

I recently dug through a sampled list of UE5 games released on Steam. It is shocking how many have such poor reviews (often for reasons not beholden to the engine). Sifting through stuff, I did find a handful of games that didn’t seem to have major performance, graphical flaws based on reviews and forum posts, though to note some of them also didn’t seem to leverage much of UE5 technologies to begin with (Lumen, Nanite, etc.). Some games did seem to leverage UE5 tech still and have minimal to no complaints.

Sadly, a large portion of the released games I pulled from this list had referenced performance issues or otherwise major issues that tanked the Steam review score. I unfortunately didn’t note down my findings for the handful that didn’t, but if you want to look for yourself the list I searched from is linked.

Haven’t played it myself, but based on watching gameplay and seeing community sentiment on the Steam forums and reviews, as well as from friends, it doesn’t seem that the performance is quite perfect. Definitely better than most UE5 games currently released, but still has some problems. From the footage I have watched of the game, it definitely still looks like there is some moderate TAA ghosting as well. Does this hold true from gameplay?

Probably either wait for some other provider to build helm charts, roll your own k8s YAML for Redis based on the helm chart and with standard Redis OCI images, or migrate to a different, but compatible service like DragonflyDB if you don’t need modern Redis features (not suggesting Valkey because they are also entrenched in Bitnami and offer it as the official chart source).

More or less yes, minus the copying files back if the operation was successful. You must be careful shrinking partitions as it is very easy to destroy them, and I’d have to guess the partition layout looks vaguely (EFI System Partition (/boot/efi), Boot (/boot), Root (/), …), which would require shrink and move of the partition before or after /boot. If you’re unfamiliar with shrinking a partition, a bit of reading into how it is done for your filesystem will be required. Different setups, ext4, btrfs, lvm, LUKS, etc. will have different requirements.

Checking the /boot size on my Fedora install, I partitioned out a gibibyte for the 3 kernel plus recovery kernel setup, which takes up about 338 MiB in total. Depending on out-of-tree kernel modules and bootloader modifications installed, your initramfs images could be larger. A few things to look for:

• the size of your current initramfs and vmlinuz image(s)
• any kernel modules you needed to install alongside your system (v4l2-loopback, nvidia, realtek, etc.)
• If there are other large files present in the boot partition

If everything there looks fine and/or is necessary, you might need to expand your /boot partition (either reinstall if new system or offline partition shrinking, moving after a data backup if you have personal files you care about).

You’re likely looking for this docs section for Caddy. The failure is the automated request to populate Caddy’s root CA cert to the host system, but obviously failed as it doesn’t have root permissions. As the docs state, if you intend to use the local HTTPS functionality of Caddy, you can manually run caddy trust privileged in order to populate the Caddy root CA cert manually. If you intend to disable the local HTTPS functionality (such as if you’re running Caddy behind a http reverse proxy), you can ignore the mail message.

The main idea on a device running something like Graphene OS is that you are already in a state of using minimal, if not at all using Google Cloud services, including data backups. It’s intended in tandem with modifications like GMS, GPS (if optionally installed into a given user, work profile) running as an unprivileged, permission-based application. If someone is taking their data privacy and security seriously enough to consider using a duress PIN and flashed their phone with something along the lines of Graphene OS, would they be likely to have heavy reliance to Google’s Cloud offerings?

Certainly glad I had my suspicions of Bitnami rugpulling when constructing my Kubernetes cluster and preemptively stripped out as much as possible from helm charts that relied on anything Bitnami. This is going to suck for a lot of people and organizations given that images like rabbitmq, postgres, oauth2-proxy, minio among many others are affected.

It’s not a full rugpull yet, but not being able to pin versions for the newer security-hardened images is already a huge issue for many pieces of software. Especially for things like not being able to pin to a major version of postgres will cause major problems over time for cluster admins and helm chart developers alike if they don’t migrate to other solutions.

Who knows if (when) Bitnami decides to go further in restricting their images, charts from being free and open. I do wish in the future that more helm chart developers would know the caution that should be taken when trusting anything touched by Broadcom of all companies. Maybe this is the necessary warning sign for many.

The Nullobsi fork of Cantata or many other mpd-backed music players are something I can recommend seems to fit what you’re looking for. It supports being able to edit the play queue whilst running a single-track on repeat within it. It does also support fade out and crossfade. The easiest way to obtain it is via its flatpak on Flathub. Cantata can either run an integrated or connect to a system-level mpd server for its backend.

Some modern laptops have completely removed support for S3 sleep, as well as some still include it but clearly never tested it. I have seen multiple OEMs that have S3 sleep “available” but with the Windows installation utilizing S0 by default. If such OEMs are lazy (which a lot of them are), they just won’t bother to properly test the functionality as long as the default OS configuration they ship works. Same kind of deal now with how many OEMs (mostly used to) ship non-standard ACPI implementations that required extra drivers in Windows to function (or would just not work correctly under Linux).