It's easier for Windows to do it because it only targets a small number of architectures (maybe only x86-64 and AArch64 these days?), and only Microsoft need to be able to build it. The Linux kernel has a huge number of targets and the build system needs to be solid for a huge number of people.
Windows does a lot of things in the kernel that Linux lets userspace handle. Part of that is the way UI is dealt with: for Windows UI is part of the core system, whereas on Linux it's a userspace tool you can install if you really fancy it.
There's also the advantage of being able to add Rust to the build pipeline without someone complaining that you broke the build for their TI-83+ calculator because there's no Rust compiler for that platform. Windows deals with amd64, x86, aarch64, and maybe some simple 32 bit ARM, but that's about it. Nobody is going to care about support for MIPS or Power9 or Motorola 6800 or SPARC or Xtensa.
I feel like there is a way more vibrant driver developer community for Windows anyway. It could be the architecture for kernel drivers Windows has or that many people use it for malware and game cheat development. I have a fond attachment to all the tools you have in your disposal once loaded into the kernel space on Windows. win32kbase.sys being at a certain memory location for all processes, KeUserModeCallback etc. all around really fun and interesting to hack with. Doing DKOM on PEB, TEB of kernel processes or user processes to do things you shouldn't be able to do like call win32 apis from kernel pretending to be a process to draw things using GDI etc.
Even though I primarily am a Linux user and I prefer using Linux on a daily basis, dabbling in Linux kernel development failed to create this feeling of awe and infinite possibilities (and exploitability) in my mind.
I guess my point is, Windows Kernel development in Rust excites me. Same with Linux would be very cool but it doesn't create the same feeling of wonder in me. Perhaps that's why this is happening first.
> Not surprising. Linux is one of the few monolithic kernels.
This is an amusing claim, given that Microsoft's first use of Rust in the NT kernel is in win32k.sys, which is the in-kernel code that used to live in userspace back when NT was actually a microkernel. So pre-NT4, which was released in 1996.
Windows still follows a microkernel like architecture with LPC across subsystems, and nowadays kernel runs on its own sandbox, while a select set from drivers are also sanboxed.
Then there are the whole set of userspace drivers, including graphics.
How are those X Windows driver crashes holding on?
Windows under the hood with the NT Kernel is actually regarded among some experts as technically superior to Linux with the driver model and personalities subsystem; it’s just that the stuff above the kernel isn’t so great…
That makes sense if your main target use case is desktops where a small number of CPU-intensive apps are running, right? And even in many server apps where you have one main app being the reason the server is booted, this makes broad sense.
Don’t get my wrong, but me and I bleed Unix-like systems and have done for decades, but what you’re saying actually makes sense for MS as a design decision…
How so? I believe I understand Windows' thread scheduler and this conclusion isn't obvious to me at all; from my understanding it seemed perfectly reasonable.
Put windows on a 4 core system. Open two terminals. Run cargo build in one terminal. Run ls in the other terminal.ls will hang for a good 10 seconds before printing output
The stuff above is actually pretty good, the problems come mostly from the obsession with supporting a flawed 30-year-old paradigm (the DOS world with its simpleton prompt), a failed system-management concept (the Registry), and the recent steer towards being adware.
It tries to be both a filesystem and a database and fails miserably at both. Entries layout is a total mess that not even Microsoft pays attention to anymore.
Agreed. Years and years of objectively bad UX and UI with the likes of GNOME, KDE, etc. I cannot understand why the organisations creating Linux distros have never at any point thought to hire a designer or two so their desktop apps don’t look like someone just slapped them onto a window with either far too much padding (even more than HN loves to complain about the web) or not enough so usability is harder.
GNOME is infamous for blindly copying things that appeal to them without underlying the originator's rationale and, in the process, making a mess of things... they just usually lean more toward copying Apple.
(eg. Changing their save icon to an "arrow pointing at hard drive" one that's harder to visually distinguish from their download icon because they don't understand that you shouldn't privilege affordances (which only give benefit while learning a new system of symbols) over consistency with existing established iconography like the "save icon" (diskette) used by every other system.)
...or GNOME 3 ruining the "Cancel/OK in the bottom-right corner of the dialog, in that order for LTR languages" they borrowed from Apple with their "action buttons in dialog header bars" idea. (TL;DR: Dialog boxes are laid out to read like paper forms, following the writing order of prose text in the user's native language. Action buttons go in the reading-order-terminal corner for a similar reason to why the signature field on a paper form is at the bottom and why business letters are supposed to end with what you want the reader to do.)
Likewise, for dialogs where they stretch OK and cancel to full width. Now you've required the user to move the cursor much further during normal operation.
