I don't care about the NT kernel, but I found that trend rather scary.
It looks like Linux might get extinguished in the next 10-20 years.
Sorry but no, if anything MS sees the writing on the wall, that Linux has become a true contender and it's too late now to extinguish it. Look at the commercial success of devices like the Steam Deck, or the fact that the android OS uses the Linux kernel.
With the excellent performance of hardware assisted virtualization, features like VFIO now supporting GPU pass-through, and vendors like Intel providing technologies like GVT-d, and AMD providing high core count CPUs with features like ECC as a standard, running Windows in a VM for desktop application workloads is becoming very common.
I have been a major part of this virtualization movement over the last 6 years (see
https://looking-glass.io) and watched it grow from a few dozen randoms messing with the interesting technology, to the commercial success it is today with countless people shoving windows into a VM so they can still play games or use legacy software that do not provide a Linux port.
Add to that the implementation of proton bringing excellent DirectX compatibility to Wine on a commercial level (again by Valve), we are seeing a very large migration to the Linux desktop as evidenced by the kind of people we are seeing in the support channels that I am a part of.
Theoretically, MS could fork Wine and rewrite the parts that are incomplete or based on stuff that wasn't 100% accurately reverse engineered, and call it the next generation of Windows.
Graphics support on Linux has been excellent for over a decade already assuming you are not being stubborn by wanting to use open source drivers ...
Hasn't been true for AMD Radeon cards for some time now, the mainline drivers for Radeon have active support from AMD.
Sorry but this is not entirely accurate either. While the AMD kernel sources are available, they still depend on and use binary blobs like the ATOM bios (amdgpu actually implements a small virtual machine to execute the ATOM bios's IL). And with the lack of any form of documentation on what the GPU registers are, and what the bits in the registers do, having access to the code is largely useless. I have spent countless hours debugging AMD GPU VFIO reset issues and getting any form of information on AMD on how things work to diagnose them is like pulling teeth.
I had access to an AMD Radeon Team engineer for a long time while working through these issues, and while he wanted to help me, we kept running into red tape on what he could tell me, which was almost nothing. I even had direct communication with Lisa Su on the matter (which was astounding, I didn't expect her to respond to my correspondence). The revelation that BACO (an amd specific acronym) was useful to us took about 8 months of trying to tease out information. For the record, it's "Bus Active Controller Off", used for power saving, but we found we could be used to semi-reset the GPU to a mostly working state again after VM shutdown.
Edit: and yes, while i'd love to give team green the flick, the fact that AMD years later, still today can't implement a proper working reset of the GPU via standard means (ie, bus reset) has me very hesitant to use AMD GPUs for any purpose. I consider the GPUs bugged until such a fundamental flaw is fixed (ever wondered why NVidia GPUs can crash recover so well vs AMD even on Windows? this is why)
Home
Help
Search
Login
Register
