That's the last thing in the list and the looping phase of catch-22. Without providing the other earlier items, it simply doesn't make sense to make Windows a Linux distro. NT is still the better solution. Unless Linux kernel becomes very friendly to closed source drivers and gets better isolation and stable APIs, no consumer company will ever invest in Linux.
Providing a closed-source friendly ecosystem for both the OS and the application layer is what Google did for early Android and that's why it caught on.
The advantages of Win32 and the filesystem structure on top of NT's technical advantages guarantees Microsoft's monopoly will go unchallenged for consumer devices. Linux has to become more like NT, not NT become Linux for success in consumer space. Linux will never become more like NT, so it will never get a stronghold.
The question for Linux (or any kernel / system layer) is very simple: If an OEM can hire developers who will independently play a mediator role under an NDA, creating stable kernel internal APIs that live more than 5 years, making sure the kernel is ready before launch without leaking any hardware specifics, Linux is a viable platform for mass-scale consumer hardware. If not, it isn't. Linux fails on all stages of that.
Processor's software becomes no different than a switch, a transfer medium in the network when you use the smartcard capabilities of the EU ID card. Digital signatures and cryptography happens purely inside the RFID/smartcard chip of the card.
This is how payments work for chip-and-pin system of EMV and login and signing systems of many businesses in the EU already. There is no need for third party attestation already.
Some architecture and some implementation details and sometimes purely economic reality:
1. NT is a hybrid kernel. Windows runs many drivers in userspace, if not in a limited kernel environment. This includes network drivers and GPU drivers. It can recover from crashes more gracefully than Linux and BSD kernels. Linux has similar drivers for specific use cases like FUSE, however, they are not as performant as NT.
2. NT has always been designed to drive a GUI-driven OS. So it has better default tunings than a vanilla Linux kernel to operate and stay reactive under memory pressure. When your system is under pressure you'd lose mouse movement on Linux, on NT this is rare. It is not impossible to do this under Linux, however, not many companies (except maybe Android manufacturers and Google/ChromeOS) actually invest in this.
3. NT provides a mostly stable API and ABI for drivers. It is not as strong as Win32 guarantees, however it retained mostly the same driver infrastructure since Vista. Many Win7 or Win8 drivers continue to work under Win11.
4. Bundled drivers for consumer systems in NT are often better quality. This could be the side effect of stable ABI. Unlike Linux, significant refactors changing big parts of the driver APIs are rare. I think this reflects in the quality of drivers like USB Host drivers. I deal with embedded Linux systems (x86, RPi), there is always some "rmmod and modprobe to fix USB" script somewhere in a deployed Linux embedded system. I have never seen anything similar in Windows Kiosk setups (TBH I have seen a lot of reinit of COM drivers but it is often manufacturer's faulty implementation).
5. There is simply more money invested to make consumer drivers work on NT. Linux is often an afterthought for many consumer device manufacturers. There is still not enough buy-in. Mainline Linux kernel team, being inferior marketshare-wise, requests more buy-in and more collaboration from device manufacturers. This works for servers since there is pressure from end customers who want to retain UNIX-like environments. Normal consumers cannot exert the same amount of pressure. Microsoft provides subsystems, APIs and ABIs to write the drivers to OEMs, often consulting the first manufacturers of a certain new device type and making compromises for them. Linux on the other hand, requires competitors to collaborate and create the subsystems and APIs. Competitor players themselves have to agree with the developers of their competitors to create a subsystem. On a capitalist economy competitors do not want to collaborate unless it significantly increases market size for everyone. Consumer electronics have very thin margins. They do not scale well with increased effort required by Linux. Only select few big tech or certain old-school consultancies send the significant system patches.
Macbook Neos are limited by whatever extra A-chips Apple has. They are okay for very simple office tasks. If you need something like Intel Core5 level performance though, PCs are still cheaper than equivalent M-series Apple chips. If they have both style users, it is cheaper to get a bulk discount from Lenovo/Dell/HP than splitting your users into camps. It is easier to administer too.
They do still force the volume licensors with their bullshit. However IT admins are used to dealing with Microsoft's bullshit and they can find ways to automate de-enshitification.
TBH many volume licensors do actually want to use Windows as a service and just pay a negotiated fee per license.
Forget about web development. All profession-specific software except web and app programming still runs best on Windows. Engineering, simulation, city planning, accounting, complex management, supply chain optimization, media production, statistics. If you're getting paid for some output where computers play an extra-boost tool role, simply being a means to the job, the software you'd use will be on Windows.
If a piece of software is specialized enough that people maintain it for decades, if it has nice detailed and complicated GUIs to handle complex tasks, it will be on Windows. It will rely on Windows' stable API. Those software goes back to 80s and 90s. They have organically grown. Linux kernel requires thousands of developers to keep alive. Linux kernel is much simpler than profession-specific software. Windows Stable ABI allows much fewer people (low 100s) to maintain much more complex software than the kernel.
Even without the stable ABI, Linux is hostile to the closed source software unless that software is served via a TCP socket.
Web can challenge this with Web Assembly and some combination of edge / datacenter computing now. Still quite the way out for demanding things like local simulation and CAD/CAM. There should also be strong economic reasons to throw actually trillions (unlike AI and other SV bullshit balloons) worth of software and entire systems out, not just to spite MS.
No such contempt has one against another in Western culture as much as politicians have against their constituents, and trendsetter companies against the cultural heritage they helped to create.
I am a daily user of S-Bahn. I know 2 alternative routes from every single station from home to work. I even started to memorize their departure times. DB prepares you for the worst.
Your target build environment often differs significantly from your server environment, so you end up needing a different toolchain and all of the problems that come with cross-compilation anyway. The toolchain and ABI settings that produce small, battery or instruction cache efficient are usually not you want on servers.
The problems building with Linux and GNU environments exist because they were terribly designed with assumptions like
- You're building on the same native system as GNU and Linux packages, you install them globally in the same places that servers and desktops use
- Your C, C++ compiler and entire toolchain and other binary utilities with the kernel is a one single unit that you can only change one part at a time
- You use the same up to date headers with glibc, gcc and Linux kernel
- You're building software in the same universe of all the other packages, especially gcc libraries (libgcc_s, libstdc++), glibc (especially bad since ld-linux.so is part of it)
- The build system only uses standard paths
The reason Yocto is so complicated is that developing in a Linux environment actually sucks when you're not writing web-oriented or server / VM software. Yocto fixes it. It introduces a good set of abstractions that work around terrible design decisions that were made in overall Linux ecosystem. There are a lot because the OS design is fundamentally broken, especially with C-based toolchains which is 99.999% of the ecosystem. Current C toolchains including MSVC strongly ties OS with the C's internal types and bad decisions of 70s.
As always all articles whose title asks a question are answered with NO, 99% time. By taking away the cross-compiling abilities and the workarounds doesn't fix the brokenness of Linux and overall FOSS ecosystem.
If you're looking for how a better embedded environment looks like, look at Rust toolchains. For Linux take a look at musl-libc based ones (you 100% need a systemd distro to get away from nss complexities that musl introduces). Or even better take a look at relibc. There are barely any assumptions about the target filesystem and tooling in Rust toolchains, unlike C/C++/Make toolchains. There is redox OS but it is still in slow development and they stuck with Make, which I think was a bad decision. Android uses its own build tooling but cannot run away from C/C++ tooling unless Google revives Fuschia.
Providing a closed-source friendly ecosystem for both the OS and the application layer is what Google did for early Android and that's why it caught on.
The advantages of Win32 and the filesystem structure on top of NT's technical advantages guarantees Microsoft's monopoly will go unchallenged for consumer devices. Linux has to become more like NT, not NT become Linux for success in consumer space. Linux will never become more like NT, so it will never get a stronghold.
The question for Linux (or any kernel / system layer) is very simple: If an OEM can hire developers who will independently play a mediator role under an NDA, creating stable kernel internal APIs that live more than 5 years, making sure the kernel is ready before launch without leaking any hardware specifics, Linux is a viable platform for mass-scale consumer hardware. If not, it isn't. Linux fails on all stages of that.