I take issue with this article.
Denuvo DRM Issues
DRM is bad. The Free Software Foundation launched Defective By Design, a campaign against DRM, nearly 20 years ago. To support a robust implementation of DRM, the operating system would need to place restrictions on the user which violates their freedom. It is completely antithetical to the goal of creating a free operating system. It is GOOD that no single corporation holds the keys to sell out the end users and lock down critical parts of the operating system. Why are you trying to replace GNU+Linux with a locked down, half-proprietary OS which caters to advertisers and publishers? Why would I want to use this? What you're describing is Android, and nobody considers Android the future of gaming. They curse it, and only find mild relief in the fact that it's not as locked down as iOS.
Proton and Compatibility
No, it's not perfect, but it's pretty damn good. Better even, in some cases. Games are published for dozens of platforms. PC operating systems, video game consoles, phones and tablets, arcade consoles, web browsers. If you are serious about building a gaming platform, emulation and compatibility layers are an essential component, and this is an area where GNU+Linux is not lacking in the slightest.
Compatibility with Windows isn't perfect because Windows is a moving target, but Proton isn't the only thing impacted by this. Every Windows game published within the past 30 years suffers from this same exact problem. There are a lot of games which were published for Windows which no longer work on Windows, but many of them do work in WINE.
Performance
Windows games running in Proton are native. It is x86 machine code running directly on the CPU, linked with a native implementation of the Windows APIs. The GPU shaders, including HLSL shaders meant for DirectX are either distributed in source form, or Spir-V, which are compiled by the GPU driver for the specific graphics card and driver at runtime even under normal circumstances.
Messy Stack Hurdles
Not that it makes the work of maintaining distributions any easier, but you know you can statically link your applications right? You also can distribute them as AppImages or FlatPaks with all the specific versions of dependencies you want. Or you can target established runtimes like Steam. Shit's no different than it is on Windows, where every application wants to install a particular .NET runtime and every game wants to install a particular DirectX. It's also just as invisible, because most game distribution platforms make this kind of thing invisible to the end user. The problem of installing software has been solved for a solid three decades already. I don't think I have heard the term "dependency hell" since George Bush was in the Whitehouse.
A Unified Ecosystem
WE HAVE THAT! Okay, there might be several components with SOME redundancy. ALSA / PulseAudio / PipeWire for instance. But there will be ONE PulseAudio on your machine. If there is a problem with your audio, that problem exists in one place, not in dozens of places because EVERY SINGLE APPLICATION ships with gigabytes of redundant middleware and their own media codecs and graphics libraries and shit.
OpenHarmony leverages industry-standard graphic APIs like Vulkan and Mesa for graphic drivers. These technologies are known for their performance and compatibility
Okay? So you're cribbing the state-of-the-art graphics stack I'm already using?
The ArkGraphics 3D pipeline library is a game-changer for Oniro-OpenHarmony. It offers a robust and efficient framework for rendering high-quality 3D graphics.
But you're also going to do the Apple Metal thing. Why? Who is asking for this?
The use of POSIX compatible musl libc compatibility over glibc in OpenHarmony addresses some of the broken issues associated with glibc on GNU Linux systems
Come on now. No shade at Musl, but there is a reason why NONE of the mainstream Linux distributions choose it over glibc. You are creating compatibility headaches and throwing away ABI compatibility with pretty much any binary software which has ever been published for Linux (including pretty much ALL of the native Linux games which already exist). The only people I have ever encountered who are enthusiastic about musl are a particular kind of Gentoo user who finds enjoyment in finding out which packages break on obscure configurations, and people doing intense system hardening.