You use Steam for games on Linux primarily. Independent native games exist as well. Many Windows-only titles will be best run through Proton: Valve’s modified WINE bundle. Other store titles can be configured to run through WINE or Proton via apps like Lutris or Heroic (GOG, Itch.io, Epic Games, etc.).

I believe it’s mostly drawing tablet support in Qt and in turn porting to Qt6 that’s holding native Wayland builds back.

A good amount of distros actively have this functionality. To avoid breaking system packages, you can install the distro package for the given module or as the error recommends: use a venv for the given project.

As to why many guides don’t include it, I suspect as typical for many Linux-centric articles: they weren’t been written by knowledgeable individuals or just in general are writing with knowledge that is often 5+ years out of date.

My top picks currently for distros that support KDE are the following:

• ArchLinux
• Debian
• Fedora KDE
• OpenSUSE Leap
• OpenSUSE Tumbleweed

For your use case (Nvidia, Wayland preferential), the better choices among these will likely be the rolling releases (OpenSUSE Tumbleweed, ArchLinux) or 6 month point releases (Fedora KDE). Debian and OpenSUSE Leap are solid choices for LTS, but given the state of Nvidia and Wayland, it’s best to use the latest releases of KDE and the proprietary Nvidia drivers. If you switch GPUs to AMD or Intel in the future, you should have no issues using any of the distros listed.

To put points against some of the distros your contending list:

Many of the direct Ubuntu-based distros tend to have a certain level of lesser quality in packages (such as many releases never end up pushing bugfix patches that get patched in many other distros including Debian). Additionally, there is no guarantee that Ubuntu-derivative distros that don’t directly source from Ubuntu software repos may have breakages when using PPA repos or developer-distributed .deb packages.

I’m sure you’re aware of this bit as well, but the mainline Canonical-maintained distros (Ubuntu, Xubuntu, Kubuntu, etc.) rely heavily on Snap: a containerized application platform similar to flatpak, but with no freedom of choice of package sourcing. Every Snap package will be pulled from Canonical’s proprietary publishing platform. A lot of derivative distros (Linux Mint, Pop! OS, etc.) end up stripping out Snap from default installations and removing package redirects, recommends for Snap.

For Arch derivatives (Endeavour, Manjaro, etc.), don’t expect to be able to use AUR packages without issues unless your derivative directly sources from the ArchLinux repos. Many AUR packages explicitly expect the latest packages, which some derivatives defer updates to, causing breakages.

In particular, Manjaro has a track record of poor maintenance and questionable choices (recommending users to roll back system clocks after forgetting to renew TLS certs, shipping outright broken versions of Asahi Linux in order to tout support for Apple hardware, DDOS’ing the AUR, etc.)

Debian Sid (the unstable (rolling) variant Debian) is an option, but it’s really not recommended for end-use, and mostly only for testing.

To put points against some of the distros on my recommendation list:

Fedora explicitly only ships with FOSS software. This does mean that initial NVidia driver setup is more involved compared to most distros. The process shortlist is initial boot with nomodeset, install rpmfusion repos, and then install the NVidia drivers from RPMFusion-nonfree. Once that is done, the proprietary drivers should be installed and all configurations necessary should already be made. Simply rebooting should allow using the system accordingly.

Installing ArchLinux specifically expects some knowledge of the inner workings of a Linux system. Modern Arch live images do come with Archinstall: a utility that assists in getting an installation from configuration options. In general, an Arch install is a more involved process. ArchLinux also expects that you read from the news page before pushing updates to your system. While this kind of practice can also be true for many other rolling systems/point releases between feature upgrades, it is fairly imperative that due diligence and backups are taken on Arch systems when updating.

The best three brands with natively-supported hardware:

• HTC’s Vive series headsets
• Bigscreen’s Beyond
• Valve’s Index

Pretty much everything else requires a lot more tinkering than just launching SteamVR/OpenVR applications.

Some helpful links for diagnosing compatibility:

• https://help.steampowered.com/en/faqs/view/18A4-1E10-8A94-3DDA
• https://steamcommunity.com/sharedfiles/filedetails/?id=2984005943

For the most part, you won’t be able to escape Unix-like paradigms when using Unix-like systems. Notably, users have to exist in some form. You don’t necessarily need to give them passwords for the frontend signage, but they need to exist. The shortlist of setting up cage would be:

• install your favorite server distro of choice
• Have a rootless, sudoless user available to use
• install cage and your app(s) of choice
• Add autologin for the user and edit the user’s BASH profile to autolaunch cage
• Attend to any other backend setup (remote access, only allowing tty1 to exist, etc.)
• reboot

It’s not quite a few clicks, but this can in contrast also be fully automated trivially if it’s something you need to setup more than once.

In what way does Windows fulfill a ‘kiosk’ display mode better than Linux for you? Are you looking for permanent installations or just temporary lockdown to a single application. One of the more modern and straightforward methods currently is using cage.

Cage lets you spawn a Wayland compositor from command-line (or via system service, obviously) that launches either a singular or multiple exclusively-fullscreen applications.

What hardware, audio interface, and sound server is in use for your 5.1 Surround setup?

I am under the presumption that the current state of the Intel Arc Alchemist GPUs will likely remain about the same under Mesa even if support is dropped today by Intel. Am I mistaken in the amount of continued driver effort Intel has been putting in for the Mesa GPU drivers?

Obviously if this is true, one should probably remain wary of upcoming Battlemage GPUs.

A key list of compatible/incompatible components to look for:

• GPU
• Network Interfaces (Ethernet and Wi-Fi)
• Audio Interfaces (not that much of an issue anymore)
• Disks
• Motherboards
• CPU (excluding x86 ecosystem)
• Peripherals

The explanations for this are pretty long, but are meant to be fairly exhaustive in order to catch most if any pitfalls one could possibly encounter.

GPU:

A big one is the choice between AMD, Intel, and NVidia. I am going to leave out Intel for compute as I know little about the state it is in. For desktop and gaming usage, go with AMD or Intel. NVidia is better than it used to be, but still lags behind in proper Wayland support and the lack of in-tree kernel drivers still makes it more cumbersome to install and update on many distros whereas using an AMD or Intel GPU is fairly effortless.

For compute, NVidia is still the optimal choice for Blender, Resolve, and LLM. Though that isn’t to say that modern AMD cards don’t work with these tasks. For Blender and Davinci Resolve, you can get them to use RDNA+ AMD cards through ROCm + HIP, without requiring the proprietary AMD drivers. For resolve especially, there is some serious setup involved, but is made easier through this flatpak for resolve and this flatpak for rocm runtime. ML tasks depend on the software used. For instance, Pytorch has alternate versions that can make use of ROCm instead of CUDA. Tools depending on Pytorch will often have you change the Pytorch source or you may have to manually patch in the ROCm Pytorch for the tool to work correctly on an AMD card.

Additionally, I don’t have performance benchmarks, but I would have to guess all of these tasks aren’t as performant if compared to closely equivalent NVidia hardware currently.

Network Interfaces:

One section of hardware I don’t see brought up much is NICs (including the ones on the motherboard). Not all NICs play as nicely as others. Typically I will recommend getting Ethernet and Wireless network interfaces from Intel and Qualcomm over others like Realtek, Broadcom, Ralink/Mediatek. Many Realtek and Mediatek NICs are hit-or-miss and a majority of Broadcom NICs I have seen are just garbage. I have not tested AMD+Mediatek’s collaboration Wi-Fi cards so I can’t say how well they work.

Bluetooth also generally sits into this category as well. Bluetooth provided by a reputable PCIe/M.2 wireless card is often much more reliable than most of the Realtek, Broadcom, Mediatek USB dongles.

Audio Interfaces:

This one isn’t as much of a problem as it used to be. For a lot of cards that worked but had many quirks using PulseAudio (a wide variety of Realtek on-board chipsets mainly), they tend to work just fine with Pipewire. For external audio interfaces: if it is compliant to spec, it likely works just fine. Avoid those that require proprietary drivers to function.

Disks:

Hard drives and SSDs are mostly fine. I would personally avoid general cheap-quality SSDs and those manufactured by Samsung. A lot of various SATA drives have various issues, though I haven’t seen many new products from reputable companies actually releasing with broken behavior as documented by the kernel. If you wish to take a detailed look of devices the kernel has restricted broken functionality on, here is the list.

Additionally, drives may be one component beside the motherboard where you might actually see firmware updates for the product. Many vendors only release EXE files for Windows to update device firmware, but many nicer vendors actually publish to the LVFS. You can search if a vendor/device is supplied firmware here.

Motherboards:

In particular, motherboards are included mainly because they have audio chipsets and network interfaces soldered and/or socketed to them. Like disks, motherboards may or may not have firmware updates available in LVFS. However, most motherboard manufacturers allow for updating the BIOS via USB stick. Some laptops I have seen only publish EXE files to do so. For most desktop boards however, one should be able to always update the motherboard BIOS fine from a Linux PC.

Some motherboards have quirky Secure Boot behavior that denies them being able to work on a Linux machine. Additionally some boards (mostly on laptops again) have either broken or adjustable power state modes. Those with adjustable allow for switching between Windows and standard-compliant modes.

Besides getting a Framework laptop ‘Chromebook edition’, I don’t think there is much you will find for modern boards supporting coreboot or libreboot.

CPUs:

For your use case, this doesn’t really matter. Pretty much every modern x86 CPU will work fine on Linux. One only has to hunt for device support if you are running on ARM or RiscV. Not every kernel supports every ARM or RiscV CPU or SoC.

Peripherals:

Obviously one of the biggest factors for many new users switching to Linux is their existing peripherals that require proprietary software on Windows missing functionality or not working on Linux. Some peripherals have been reverse engineered to work on Linux (see Piper, ckb-next, OpenRazer, StreamController, OpenRGB).

Some peripherals like printers may just not work on Linux or may even work better than they ever did on Windows. For problematic printers, there is a helpful megalist on ArchWiki.

For any other peripherals, it’s best to just do a quick search to see if anyone else has used it and if problems have occurred.

A couple things to check using a quick bash script:

#!/usr/bin/env bash

cd /sys/class/power_supply/BAT*/
echo "Charge cycles: $(cat cycle_count)"
printf '%s\0' 'Health: ' &
bc <<< "scale=3; ($(cat charge_full) / $(cat charge_full_design)) * 100"

That should print out the wear cycles the battery has endured and its reported capacity over design capacity. If your battery has less than 1000 cycles and the health reported from the battery is less than 80%, it might be best to contact Framework for warranty replacement as the battery is likely defective.

Just note that with Bambu printers about past data collection practices and their in general mid to atrocious after-sales support. If this doesn’t deter you, then go ahead and get one.

I do a lot of my functional parts in ABS, ASA though printing such material may be difficult on an open-air machine. The two obvious choices will generally be PLA or PETG. PLA is one of the most common printed materials, and is fairly balanced in material strength. PETG parts are more likely to permanently deform heavily before fully snapping, as well as they have a but more temperature resistance than PLA. Additionally most PETG plastics hold up decently well to UV, often making them more suitable for parts that need to be outdoors.

PLA takes not much consideration on surface to print, as most printers come with a smooth PEI build sheet by default. It will however need more cooling than printing with PETG at equivalent speeds. If you use a PEI sheet for PETG, make sure it is textured. You will destroy a smooth sheet if it doesn’t have some kind of release coating to lower its adhesive properties to PETG.

There is no guarantee for spools of filament to actually arrive dry, so a filament dryer isn’t a bad idea. I don’t have any particular recommendations for a good filament dryer. I have a Filadryer S2 from Sunlu, but am not impressed by it.

For multi-monitor: use Wayland. For 2.5Gbps Ethernet NICs, they never work properly on any system in regard to performance, but I presume you are referencing the subpar Realtek NICs not connecting? Depending on the distro, you likely won’t have the driver and/or firmware package preinstalled to make it work.

As I understand it, this driver isn’t ready for personal use unless you don’t care about the contents of your btrfs partitions mounted on Windows.

I know ArchLinuxArm (a fork of the ArchLinux project) supports the Hisense C11. It does seem to be a fairly involved procesd, and (potentially?) requires using external media rather than the onboard eMMC storage to boot a Linux system.

Your particular Chromebook contains the same SoC (Rockchip RK3288) as an Asus C201, which Debian has an install guide for. Once again, a fairly involved process and this one may not be guaranteed to work if the C11 has some quirks not present in the C201.

Just took a couple minutes to install and setup the fork to try it out. Turns out there is a flatpak on Flathub under the id dog.unix.cantata.Cantata that looks to be maintained directly by nullobsi. I’ll have to see where rough edges show up, but this fork looks good thus far. A full port from Qt5 -> Qt6 isn’t a trivial amount of effort, so mad respect to everyone working on this ported version.

The easiest ways to run custom executables for Proton titles is either going to be SteamTinkerLaunch or my shim script.

The question that I have to ask: what category of CLI apps (or even some examples) exist that are too complex to maintain a few versions simultaneously as native packages but are not complex enough to just use an OCI container for them instead?

Both not possible and unnecessary on Wayland.

The flatpak documentation has a semi-relevant page on setting up a flatpak repo utilizing gitlab pages and gitlab’s CI runners on a pipeline. Obviously, you’d need to substitute Gitlab Pages for a webserver of your choice and to port the CI logic over to Gitea Actions (ensuring your Gitea instance is setup for it).

A flatpak repo itself is little more than a web server with a related GPG key for checking the signatures of assembled packages. The docs recommend setting up the CI pipeline to run less on-commit to the package repos and more on the lines of checking for available updates on interval, though I imagine other scenarios in a fully-controlled environment such as a selfhosted one might offer some flexibility.