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.