p_ing

This ignores that Apple is unable to manufacture enough computers per year to be disruptive.

25m Macs in calendar year 2025. Lenovo manufactured 19m PCs in Q4 2025.

Apple simply lacks volume.

4K random read with a queue depth of 1 on an M1 Max is about 65MB/s.

Apple isn't capable of manufacturing the amount of volume necessary to displace x86/Windows.

Apple shipped 25.6 million Macs in 2025. Lenovo shipped 19.3 million PCs in the 4th quarter alone.

You don't want that dream.

It's a whole new set of unknown bugs, security issues, lack of essential features, and app compat issues.

And the internals of NT are quite good and still largely modern. There's not a lot worth replacing (my only thought would be to rip out the file system filter driver model though I don't know what would replace it).

On the desktop, I don't believe Microsoft has had significant competition for quite some time, likely back to Windows 95. In the server space, NT fought really hard against the UNIX giants of the time.

> giant XML blobs instead of using proper, efficient table schemas.

Prior to SharePoint 2013, Microsoft used sparse columns. It made for massive tables and was poor design.

Moving to XML blobs for user-defined schemas was the correct choice. The table schema became significantly smaller and user-defined schemas (for Lists/Libraries) could become much more complex.

.NET Framework needs its own runtime. Java needs its own runtime.

What's the issue?

And if it was the best choice, the critique isn't valid.

If you know why it was chosen and if it was a bad choice compared to other frameworks, please do tell.

I'm not sure that it uses React Native, but modern add-ins for Office are JS, so any injected modern add-in will be using JS rather than COM/C/C++. This gave add-ins portability between all supported Office platforms, increased security, and made administration much easier.

You have inside knowledge of why React Native was chosen?

So you're asking for a bug-filled, unstable, feature-less OS?

Because that's what you get when you start from scratch.

If you deem a couple of clicks "tons of effort", don't touch macOS!

Shouldn't devs be allowed to select what they feel is the "best" choice for a given component? While I wouldn't expect to see a SwiftUI in Windows from Microsoft, Microsoft hasn't been adverse to various NIH web frameworks for quite some time now.

If it fits and meets the goals of the project, why not?

Exactly this. And it is on a portion of the Start menu that can be fully disabled. Heck, my start menu looks like the Windows 10 start menu (yes, this is OOTB) as I wasn't fond of the "new" look of the Windows 11 start menu.

But we'll always hear "it's React!". Like most things, the masses must feed on the Internet outrage without critical thought.

As we've seen, across years no UI theme is permanent. It might stick around for a long time, but it won't stay forever.

I realized it was the gear icon that is rendering dark/black on a dark/black background of the app.

It's really difficult to see the right click menu.

There are no practical issues with a "cluttered" registry. It's a database. Databases deal just fine with extra rows in tables.

$1K for a toilet!

https://www.totousa.com/ultramax-ii-one-piece-toilet-elongat...

This isn't an NTFS thing. The I/O Manager implements NtLockFile. Applications can request exclusive byte-range write access to a file. And perhaps it is lazy programmers, or defaults, but they generally do.

I don't think Microsoft sees client machine reboots as an issue, and it used to be much worse when they used to be released weekly. On the server side, Microsoft expects that you'd implement some form of high availability.

NTFS on non-Windows follows the locking semantics of the underlying driver model/kernel, e.g. you can replace an in-use file on Linux. Likewise, using FAT on Windows you cannot replace an in-use file. This is just to demonstrate it isn't a file system-specific "issue" (if you feel it is one). It was a design decision by the original NT OS/2 development group.

Ultimately, the NT byte-range locking is a holdover from NT OS/2, where in OS/2 byte-range locking was mandatory.

> still be more robust

Why? The only stable ABI on Linux is Win32.

Displaying seconds on macOS also causes higher CPU usage for WindowServer.

Windows ships with a universal IPP driver that works for any printer which is Mopria certified; similar to AirPrint.

There's very little reason to install print drivers anymore on Windows.

Why bother making native releases when Valve/Proton will take care of it? Who wants the headache of supporting another build and directly supporting N flavors of Linux distributions?

When it comes to games, Linux has an OS/2 problem.

XWindows/Wayland being a userland application with no solid hooks into kernel space (that has both advantages and disadvantages), where as Windows operates the Window Manager/GDI within the Executive [for performance]. It makes it feel disjoint. Mouse acceleration differences, too (also impacts macOS), but that's something you get used to, though I find gaming awkward on macOS because of the weird default acceleration.

If you were old, you’d know KDE copied the UX from Windows.

> The Elder Scrolls IV: Oblivion Remastered

Interesting, given this game was shortly abandoned after release with major performance issues.

You can buy three socks for the price of one set of casters.

https://www.apple.com/shop/product/mx572zm/a/apple-mac-pro-w...

The kernel is technically inferior to NT, especially with memory management (see OOM on macOS while NT will keep going).

APFS is not designed for spinning rust, so that tracks.