React Native doesn't render using a browser instance, it's native code (as the name implies), it's actually a layer over WinUI 3 (Previous versions used WPF/UWP)
So it's in the same boat as MAUI, which is also a layer over WinUI 3.
(and why isn’t spell check core Windows functionality?)
It actually is, introduced in Windows 8, it's just taken devs ages to actually start using it (Notepad only got it last year, 12 years after it was introduced)
It's an easy license to reason about, allows for basically any project to use it, and you don't need to worry about trying to enforce it (Because the GPL is only as good as your lawyers are)
Plan 9 is inspired by UNIX (Helps that it had the same devs), but it's not a direct continuation.
UnixWare is I think the only direct continuation of the original AT&T UNIX. The various BSDs are close enough but were re-written entirely in the late 80s/early 90s so there's nothing original remaining.
Should be possible, as it's a normal VM you can already install flatpak apps in said VM as normal, you'd just need a Windows side bit to invoke the install within WSL when you opened the flatpak bundle, and then something to add a start menu shortcut from the app inside the VM (Which I actually assume already exists, I never actually ran WSL2 when I was on Windows)
Why have a laptop or a dual boot with Linux when you can now more easily stay on the proprietary OS ?
This is called market retention.
Preventing migration to another OS, another software ecosystem.
The ‘Embrace’ and ‘Extend’ parts of EEE.
That's stretching the definition to the point it's nearly unrecognisable.
What the term meant was for things like Internet Explorer, where MS adopted an existing standard (Embrace), started changing it in incompatible ways (Extend), while using their market power to lock out competitors (Extinguish)
e.g. IE used an incompatible method for sizing and laying out elements than any other browser, so a site that laid out properly in NN4 looked broken in IE6, and vise versa. So most devs targeted IE6 as it was more popular, and NN4 users got more and more broken sites.
ACPI was similar, Windows had an extremely lax implementation of it, so motherboards often shipped with bugs that Windows would ignore but would stop anything else from booting. Intentional? Doesn't really matter, since it sure was helpful in slowing the adoption of things like Linux, that had to come up with workarounds for all the broken hardware.
Not like you can fork it to run on a different OS.
For WSL1? yep that's effectively impossible.
WSL2 is effectively just a wrapper around the kernel virtualization support and a bundling format, as long as whatever image you run talks to the host properly (like any other virtualised OS would) it'd run.
e.g. Mastodon has been around for years, is actually really federated, not owned by a corporation, and a lot more features than BlueSky… but bluesky already has more users and i think largely because: marketing… how are people going to talk about “Mastodon” when they’ve probably never even heard the word before? (also named after a cool band, but not suitable for the masses).
Also fewer syllables, which apparently has a noticeable impact.
Yeah, I was prescribed them when I was younger (The wonders of living in a state that still doesn't fluoridate the water supply). They were small little red pills that you had to chew on and then rub the "paste" on your teeth with your tongue.
Imagine basically dehydrated toothpaste, had a chalky texture, not the greatest.
It is all generic layers, the base USB stuff is called a "Human Interface Device", controllers/keyboards/mice/etc. all show up as a HID to the OS. But you need some way to standardise the input and map the device side events to the host side, so the OS will have a mapping layer above the base USB layer that turns a generic HID into a "controller device" that an app can use.
As you can see from the patch, that's all they're doing. They're adding the USB IDs of these controllers to the mapping layer so instead of being shown as a "Generic HID", they're shown as "Generic Xbox Controller". Doing so also means the controller layer can drive the devices specifically, e.g. xbox controllers need a special handshake to enable the xbox button, the base generic input layer doesn't need to know that stuff.
From a quick search it seems that the mobo uses a Realtek audio chip, which is probably the actual problem. My current system build uses one and it barely worked under Windows, it'd randomly remap the channels, sometimes it just wouldn't come up properly (Showed as only a microphone, etc.), had lots of static noise, would constantly think I was unplugging and replugging headphones in, etc. Just a terrible experience compared to the Intel audio system the build before this used.
As much as "just buy another bit of hardware" is an awful bit of advice, I'd recommend getting a USB DAC/soundcard, I bought a cheap soundblaster one and it fixed all my problems. USB audio is a well-defined standardised protocol that's supported by just about everything, does away with any driver issues or incompatibilities, can be moved between devices, etc. Mine's a "gaming" model so it's just a USB port on one side and a headset jack on the other, but you can also get ones with proper inbuilt amplifiers to run full speaker kits, etc.
React Native doesn't render using a browser instance, it's native code (as the name implies), it's actually a layer over WinUI 3 (Previous versions used WPF/UWP)
So it's in the same boat as MAUI, which is also a layer over WinUI 3.