>Kernel and low level stuff are actually very stable and good.
This. A while ago a build of Win 11 was shared/leaked that was tailored for the Chinese government called "Windows G" and it had all the ads, games, telemetry, anti-malware and other bullshit removed and it flew on 4GB RAM. So Microsoft CAN DO IT, if they actually want to, they just don't want to for users.
You can get something similar yourself at home running all the debloat tools out there but since they're not officially supported, either you'll break future windows updates, or the future windows updates will break your setup, so it's not worth it.
Talked about back in the Vista days publicly (I cannot find the articles now) - Microsoft has commitments to their hardware partners to help keep the hardware market from collapsing.
So they are not incentivized to keep Win32_Lean_N_Mean, but instead to put up artificial limits on how old of hardware can run W11.
I have no insider knowledge here, just this is a thing which get talked about around major Windows releases historically.
> Kernel and low level stuff are actually very stable and good.
In their intended applications, which might or might not be the ones you need.
The slowness of the filesystem that necessitated a whole custom caching layer in Git for Windows, or the slowness of process creation that necessitated adding “picoprocesses” to the kernel so that WSL1 would perform acceptably and still wasn’t enough for it to survive, those are entirely due to the kernel’s archtecture.
It’s not necessarily a huge deal that NT makes a bad substrate for Unix, even if POSIX support has been in the product requirements since before Win32 was conceived. I agree with the MSR paper[1] on fork(), for instance. But for a Unix-head, the “good” in your statement comes with important caveats. The filesystem is in particular so slow that Windows users will unironically claim that Ripgrep is slow and build their own NTFS parsers to sell as the fix[2].
But there's another issue which is what cripples windows for dev! NTFS has a terrible design flaw which is the fact that small files, under 640 bytes, are stored in the MFT. The MFT ends up having serious lock contention so lots of small file changes are slow. This screws up anything Unixy and git horribly.
WSL1 was built on top of that problem which was one of the many reasons it was slow as molasses.
This is not due to slowness of the file system. Native ntfs tools are much faster than Unix ones in some situations. The issue is that running Unix software on windows will naturally have a performance impact. You see the same thing in reverse using Wine on Linux. Windows uses a different design for IO so requires software to be written with that design in mind.
joe_mamba|23 days ago
This. A while ago a build of Win 11 was shared/leaked that was tailored for the Chinese government called "Windows G" and it had all the ads, games, telemetry, anti-malware and other bullshit removed and it flew on 4GB RAM. So Microsoft CAN DO IT, if they actually want to, they just don't want to for users.
You can get something similar yourself at home running all the debloat tools out there but since they're not officially supported, either you'll break future windows updates, or the future windows updates will break your setup, so it's not worth it.
bcraven|23 days ago
https://www.windowscentral.com/software-apps/windows-11/leak...
RajT88|23 days ago
So they are not incentivized to keep Win32_Lean_N_Mean, but instead to put up artificial limits on how old of hardware can run W11.
I have no insider knowledge here, just this is a thing which get talked about around major Windows releases historically.
TkTech|23 days ago
workfromspace|23 days ago
drnick1|23 days ago
hilti|23 days ago
mananaysiempre|23 days ago
In their intended applications, which might or might not be the ones you need.
The slowness of the filesystem that necessitated a whole custom caching layer in Git for Windows, or the slowness of process creation that necessitated adding “picoprocesses” to the kernel so that WSL1 would perform acceptably and still wasn’t enough for it to survive, those are entirely due to the kernel’s archtecture.
It’s not necessarily a huge deal that NT makes a bad substrate for Unix, even if POSIX support has been in the product requirements since before Win32 was conceived. I agree with the MSR paper[1] on fork(), for instance. But for a Unix-head, the “good” in your statement comes with important caveats. The filesystem is in particular so slow that Windows users will unironically claim that Ripgrep is slow and build their own NTFS parsers to sell as the fix[2].
[1] https://lwn.net/Articles/785430/
[2] https://nitter.net/CharlieMQV/status/1972647630653227054
dgxyz|23 days ago
But there's another issue which is what cripples windows for dev! NTFS has a terrible design flaw which is the fact that small files, under 640 bytes, are stored in the MFT. The MFT ends up having serious lock contention so lots of small file changes are slow. This screws up anything Unixy and git horribly.
WSL1 was built on top of that problem which was one of the many reasons it was slow as molasses.
Also why ReFS and "dev drive" exist...
jph00|23 days ago
p_ing|23 days ago
BrouteMinou|23 days ago
https://github.com/Microsoft/WSL/issues/873#issuecomment-425...
exceptione|23 days ago
p_ing|23 days ago