Foxlet

Yes! ISA only remains on industrial motherboards at this point so it's not exactly supported, but PCI cards can be used on a PCIe system using a PCI-to-PCIe riser cable (can be found on sites like eBay or Aliexpress), and of course on special motherboards with PCIe + PCI slots. For example, here's an NVIDIA card passed through to 86box:

Hi, 86box contributor here! A few notes about the project that might've been missed in the video: Serial passthrough is WIP, but has been finally implemented and partially working, with some bugs to iron out 86box already supports mounting any folder as a Virtual ISO directly from the Media menu Support for Linux and macOS (plus native Apple M1/M2 support) is available, particularly handy for ARM64 systems There is a special build of 86box for Linux that supports VFIO, so you can pass through physical sound cards, network cards, hard disks, or classic GPUs over to the emulated PC

Even with the upcoming 5.15, the new ntfs3 driver will help substantially with accessing their existing game libraries off a secondary partition, so there's always a tangible benefit to being on the newer version of Kernel.

I'm surprised no one mentioned Void Linux, but it would make sense for having a more stable/tested package set due to its single repository layout (community packages are committed directly), while still being bleeding-edge enough to handle modern Linux gaming properly, all while not having the meme status of Arch. KDE Plasma is pretty much the easiest DE choice for someone coming solely from Windows.

Turns out dual-booting Windows 11 and Linux from a single partition is indeed possible.

The driver supports native Unix permissions and those are preserved properly in the filesystem. Windows itself sees root-owned files as held by TrustedInstaller, which handles all non-administrator files as well. Case sensitivity and file links are shared across both systems.

Background With the upcoming release of Linux Kernel 5.15, a new filesystem driver is included known as ntfs3. This driver was contributed by Paragon Software based on their commercial efforts, and includes full read/write support as well as NTFS and Unix permissions support. More details can be found in the following: https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html https://www.paragon-software.com/us/home/ntfs3-driver-faq/ So what's this about? Given that the new NTFS driver is now a native part of the kernel, I've decided to (as a proof of concept) add a preliminary kernel (with ntfs3) as well as boot support to a modified version of the Void Linux installer... and it works! Officially no distro supports installing Linux on an NTFS disk out of the box yet, but conceptually it should be possible for users to transition from Windows to Linux without formatting or moving any data by using this method. More information to come soon!

Summary After Valve's promises of anti-cheat support in SteamOS, individual vendors are beginning to publish Linux-compatible versions of their anti-cheat solutions, starting with Epic's Easy Anti-Cheat. The latest version of EAC is supported under native Linux as well as through the Proton and Wine compatibility layers, although the process for enabling it is opt-in for each game developer. Quotes My thoughts Anti-cheat has historically been one of the major pain points for many gamers trying to switch over to Linux; this essentially removes a blocker that prevented many popular multiplayer games from running on the platform. Given Valve's recent announcement of the Steam Deck being Linux-based, this also opens the path towards 100% game compatibility on their end. Sources https://www.windowscentral.com/epic-games-makes-easy-anti-cheat-available-linux-paving-way-steam-deck https://dev.epicgames.com/en-US/news/epic-online-services-launches-anti-cheat-support-for-linux-mac-and-steam-deck (original press release)

To clarify, the vendor reason is speculation based mainly based on Intel EOLing 7th gen CPUs and related chipsets at the end of 2020, leaving it in extended support, with 8th gen and higher remaining as the only active products in their existing product stack (matching Microsoft's compatibility list). https://www.anandtech.com/show/14968/intel-to-discontinue-nearly-all-desktop-kaby-lake-cpus Certain older motherboards also lack support for Kernel DMA Protection, which is a new requirement for Windows 11, and was introduced around the launch of 8th gen systems.

Probably a combination of vendors no longer supporting these older CPU products, and Windows's Device Attestation (for the TPM) and Kernel DMA Protection (for older chipsets). Microsoft goes more into detail about the TPM and Device Attestation in https://www.microsoft.com/security/blog/2021/06/25/windows-11-enables-security-by-design-from-the-chip-to-the-cloud

The reason that 7th gen/Zen 1 CPUs and under are considered incompatible is mainly because the upstream vendors (Intel and AMD) no longer support these older CPUs with firmware updates. Microsoft is just taking advantage of the opportunity to eliminate them from the roster by following the vendor's direction.

Microsoft explicitly mentioned that Insider Preview builds would be exempt from needing to meet all the system requirements (this also applies to hypervisors), and users will be required to return to Windows 10 once 11 hits General Availability. In effect this new hard floor is only for the RTM version.

You may want to update this post as the Compatibility webpage for Windows 11 has been updated today; the old hard floor (that mentioned TPM 1.2) has been removed. Microsoft explicitly says that TPM 2.0 will be required and CPUs outside of the compatibility lists are not supported, putting the new hard floor in line with the results of the PC Health Checker (which was also updated today to point out incompatible CPUs). https://docs.microsoft.com/en-us/windows/compatibility/windows-11/ CPU Compatibility Lists: https://docs.microsoft.com/en-us/windows-hardware/design/minimum/supported/windows-11-supported-amd-processors https://docs.microsoft.com/en-us/windows-hardware/design/minimum/supported/windows-11-supported-intel-processors

This might fit better on ChannelSuperFun, but acquiring a full-size water slide ($180,000) and other waterpark equipment off AliExpress... because economies of scale allow for that apparently. https://www.aliexpress.com/item/33022449706.html

Ironically, with an LGA115x cooler (like the Intel Stock cooler). The die guard should protect against chipping the APU.

Yep, I wonder if hardware accelerated encoding + XSHM wasn't enabled.

If we limit ourselves to just running the kernel (XNU) and a simple userland, that's already possible to a degree with qemu-system-arm64. A RasPi with KVM support could speed up performance reasonably enough to be usable, and this is more likely the route you might see come up once Big Sur is publicly available. Doing the same on bare metal is slightly more difficult, since it depends on Apple's policies going forward. If they continue to publish source code releases on https://opensource.apple.com/, and these include the ARM64 targets and Platform Experts that Big Sir will add, then with enough effort you could end up running it on a Pi, sans support for any included hardware until kernel extensions are written for them. The binaries themselves won't run on a Pi as-is though, the firmware stack between both platforms are very different, with Apple Silicon Macs using something more akin to LLB/iBoot as seen on iOS devices.

PCIe itself is pretty flexible, you could send messages over a serial line if one was up to the task. The problem is that Android itself doesn't really support mainline Mesa, it has its own version of the 3D libraries which may not necessarily support desktop GPUs. The best bet would be to run an ARM version of desktop Linux with mainline libraries, but that's going into custom ROM territory and probably outside LTT's scope. Also, the drivers your linked are for 32-bit legacy ARM devices, which won't work on 64-bit smartphones (most of them nowadays).

I'm mostly fond of XNU and the Unix heritage of the system. It delivers the capabilities of power-user-friendly BSD with the integration of Cocoa in the UI. It's also the only other system with mainstream support for graphics applications (something that Linux still lacks currently). The other side is the challenge of running the OS on exotic hardware. I have a mixture of real Macs and Hackintoshes on AMD architectures, being able to use the OS across systems is great in most situations.

MSRs haven't been an issue since XCPM debuted in the Mavericks kernel.

Compatibility with macOS isn't down to generic brands, but more so the particular on-board hardware that exists in a motherboard. Networking, sound, and on-board I/O are all under consideration when picking a model. Outside of that, UEFI compatibility also matters, badly written firmwares will break the boot process from Clover -> XNU either due to memory fragmentation (KASLR fail) or driver issues.

One could also build a custom ROM to allow any selection of applications on the system.

You don't need any of that reasoning. Codesigning is verified when boot.efi is loaded, and again when boot.efi passes control to XNU. The boot device is irrelevant as long as it can pass the two conditions. UEFI will still be able to access all the other block devices attached to the system.

It wouldn't be usable under Windows, as the feature needed for GPU acceleration (iommu passthrough) just doesn't work without KVM support. There's some experimental accelerator support for CPUs, so at best you'll have a slow experience.

I have a mid-2009 MacBook Pro (on a Core2Duo), XNU can still work on Penryn+ processors to a degree, but I didn't involve any of dosdude's patchers (for various safety reasons).