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.

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.

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.

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.