UI of Windows is buggy and inconsistent. Kernel and low level stuff are actually very stable and good.

joe_mamba 2 hours ago | parent | next [-]

>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.

▲

RajT88 an hour ago | parent | next [-]

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.

	▲	joe_mamba 26 minutes ago \| parent [-]
		>Microsoft has commitments to their hardware partners to help keep the hardware market from collapsing. Citation needed since that makes no logical sense. You want to sell your SW product to the most common denominator to increase your sales, not to a market of HW that people don't yet have. Sounds like FUD. >but instead to put up artificial limits on how old of hardware can run W11 They're not artificial. POPCNT / SSE4.2 became a hard requirement starting with Windows 11 24H2 (2024) (but that's for older CPUs), and only intel 8th gen and up have well functioning support for Virtualization-Based Security (VBS), HVCI (Hypervisor-protected Code Integrity), and MBEC (Mode-Based Execution Control). That's besides the TPM 2.0 which isn't actually a hard requirement, the other ones are way more important. So at which point do we consider HW-based security a necessity instead of an artificial limit? With the ever increase in vulnerabilities and attack vectors, you gotta rip the bandaid at some point.

▲

TkTech 2 hours ago | parent | prev | next [-]

Is this not just Windows LTSB/LTSC? Which has been a thing forever.

	▲	joe_mamba 2 hours ago \| parent [-]
		Maybe, could also be that for a 9 figure government contract they'll provide a custom LTSC branch just for you with only the features you want.

▲

hilti an hour ago | parent | prev [-]

Never heard of Windows G .. that sounds exactly what I want for my older Thinkpads :-)

▲

mananaysiempre an hour ago | parent | prev | next [-]

> 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].

[1] https://lwn.net/Articles/785430/

[2] https://nitter.net/CharlieMQV/status/1972647630653227054

▲

jph00 an hour ago | parent | next [-]

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.

	▲	noumenon1111 37 minutes ago \| parent [-]
		Microsoft fanboy spotted... Why aren't you on the hate wagon with the rest of us, boy? You think yer BETTER? HUH?

▲

p_ing 40 minutes ago | parent | prev | next [-]

The file system isn't slow. The slowness will be present in any file system due to the file system filters that all file system calls pass though.

▲

dgxyz an hour ago | parent | prev [-]

This is on the mark.

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...

▲

exceptione an hour ago | parent | prev [-]

NTFS, not so great.

▲

p_ing an hour ago | parent [-]

NTFS is just fine. Stable, reliable, fast, plenty of features for a general purpose file system.

▲

repelsteeltje an hour ago | parent [-]

...But no way can you wrap it into something that looks posix-y from the inside

▲

p_ing 42 minutes ago | parent [-]

Why would you want to?

	▲	repelsteeltje 27 minutes ago \| parent [-]
		From the article, first use case: > Example use cases include: > * Running unmodified Linux programs on Windows > * ... That won't work if the unplugged Linux program assumes that mv replaces a file atomically; ntfs can't offer that.