←back to thread

752 points dceddia | 3 comments | | HN request time: 0.666s | source
Show context
waboremo ◴[] No.36447387[source]
We just rely on layers and layers of cruft. We then demand improvements when things get too bad, but we're only operating on the very top layer where even dramatic improvements and magic are irrelevant.

Windows is especially bad at this due to so much legacy reliance, which is also kind of why people still bother with Windows. Not to claim that Linux or MacOS don't have similar problems (ahem, Catalyst) but it's not as overt.

A lot of the blame gets placed on easy to see things like an Electron app, but really the problem is so substantial that even native apps perform slower, use more resources, and aren't doing a whole lot more than they used to. Windows Terminal is a great example of this.

Combine this with the fact that most teams aren't given the space to actually maintain (because maintaining doesn't result in direct profits), and you've got a winning combination!

replies(7): >>36447692 #>>36447714 #>>36447761 #>>36448103 #>>36448804 #>>36449621 #>>36458475 #
1. wongarsu ◴[] No.36447761[source]
> Windows is especially bad at this due to so much legacy reliance

Part of the "problem" with Windows is also lack of legacy reliance. As in: MacOS and Linux are at heart Unix systems, with a kernel architecture meant for 1970s hardware. The Windows NT kernel family is a clean-sheet design from the 1990s, a time where compute resources were much more plentiful.

For example, on Linux file system access has (by default) very basic permissions, and uses a closely coupled file system driver and memory system in the kernel. On Windows there is a very rich permission system, and ever request goes through a whole stack of Filesystem Filter Drivers and other indirections that can log, verify or change them. This is great from a functionality standpoint: virus scanners get a chance to scan files as you open them and deny you access if they find something, logging or transparent encryption is trivial to implement, tools like DropBox have an easy time downloading a file as you access it without dealing with implementing a whole file system, the complex permission system suits enterprise needs, etc. But on the other hand all these steps make the system a lot slower than the lean Linux implementation. And similar resource-intensive things are happening all over the kernel-API in Windows, simply because those APIs were conceived at a time when these tradeoffs had become acceptable.

replies(2): >>36448957 #>>36453322 #
2. c00lio ◴[] No.36448957[source]
> On Windows there is a very rich permission system, and ever request goes through a whole stack of Filesystem Filter Drivers and other indirections that can log, verify or change them. This is great from a functionality standpoint: virus scanners get a chance to scan files as you open them and deny you access if they find something,

Yes, but still it seems to be useless to implementers, because practically every virus scanner implements braindead stuff like DLL injection for on-access-scanning.

3. sillywalk ◴[] No.36453322[source]
> The Windowsw NT kernel family is a clean-sheet design from the 1990s

I thought that the NT Kernel was heavily based on VMS. When Dave Cutler, their chief OS architect/guru left for Microsoft and took a bunch of engineers with him. FTA:

"Why the Fastest Chip Didn't Win" (Business Week, April 28, 1997) states that when Digital engineers noticed the similarities between VMS and NT, they brought their observations to senior management. Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars."

[0] https://www.itprotoday.com/windows-client/windows-nt-and-vms...