3 ms·
talk about FUD! where to start > the people who brought you kernel mode printer drivers and the Blue Screen of Death the scenarios that result in errors are t
by munin 13y ago
talk about FUD! where to start
> the people who brought you kernel mode printer drivers and the Blue Screen of Death
the scenarios that result in errors are totally different from the error scenarios in linux. most of the crashes in windows systems are the results of non-MSFT developers who wanted to insert code into the kernel. these kinds of errors happen on linux too, if you use binary nvidia drivers and/or vmware.
> requires such gems as having to intentionally reproduce undocumented historical bugs because legacy applications rely on them.
the "compatibility layer" is actually far more nuanced than this, and only turns on the old and bad behavior if it recognizes that it's being used by an application that requires the old and bad behavior.
> Windows was designed by a committee in a hurry.
NT was designed by the team that did VMS in a 3-month retreat to Hawaii. the design they created has lasted with very minor modifications for the last twenty years. can linux say the same?
- luuse 13y ago> NT was designed by the team that did VMS in a 3-month retreat to Hawaii. the design they created has lasted with very minor modifications for the last twenty years. can linux say the same? It's not necessarily a good design just because it has lasted for 20 years. It might just be that it's too expensive to change any of it. Although I should probably say that I'm not informed enough to judge
- AnthonyMouse 13y ago>the scenarios that result in errors are totally different from the error scenarios in linux. Not really. It's more like the Windows problems are a superset of the Linux problems. Most kernel panics are a result of bugs in drivers which happens just the same on Windows. Then you have all the ones based on Microsoft laziness, like getting the INACCESSIBLE_BOOT_DEVICE BSOD instead of the OS trying to load some more drivers if your disk controller died and you replaced it with a different model. And then you have the fallout of Microsoft's attempts to fix legacy software rampaging through kernel memory, which means all the legacy code that used to do that (including the ones that did something useful instead of causing a BSOD) will now just crash the application and break the legacy software, because Microsoft couldn't be bothered to get it right the first time. > most of the crashes in windows systems are the results of non-MSFT developers who wanted to insert code into the kernel. The difference is that Unix-like operating systems have always discouraged that behavior so it happens a lot less often (and is a lot more suspicious), and if you have something that legitimately needs to go into the Linux kernel then it generally gets merged into the main tree. But not until you fix what problems the kernel maintainers identify, and then it gets maintained by the people who know what they're doing. > the "compatibility layer" is actually far more nuanced than this Sounds unnecessarily complicated and undesirable. > NT was designed by the team that did VMS in a 3-month retreat to Hawaii. NT was never the problem. That's like saying ReactOS will be good because it's designed by smart people. The "design" is already cribbed by what came before it and the box it now has to live in, which was set out by DOS and Windows 95. Microsoft now has to live with that legacy, why should the rest of us?
- mtdewcmu 13y ago> NT was designed by the team that did VMS in a 3-month retreat to Hawaii. the design they created has lasted with very minor modifications for the last twenty years. can linux say the same? How long does it take to design an OS, once you've already done one, and there are others to use as reference? I don't think there was ever a similar moment in the history of Linux, because Linus copped the design of UNIX, and he states this freely and matter-of-factly.