lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue Oct  4 12:49:39 2005
From: jericho at attrition.org (security curmudgeon)
Subject: Bigger burger roll needed


: Since its inception, supporting NT 3.0 beta and onward, I have been 
: dealing with BSOD's.  In total, there have been comparatively very few 
: times were it was a direct fault of MS code.  It has very commonly been 
: in relation to 3rd party drivers that needed reworking or updating by 
: the 3rd-party manufacturer.
: 
: This is not PR spin (of which I don't think you could find any published 
: PR spin for either side of this argument either).  This is real world 
: experience with the NT+ products across i386 and Alpha hardware 
: platforms using peripheral devices from many different major 
: manufactures.  There are admins on both sides of the anti-MS fence that 
: I communicate with that would agree with this conclusion.

Fine, it isn't PR spin. But, compare this to Unix. How many times do you 
run user-land, 3rd party applications, that cause a kernel panic?

Why does Windows *let* third party applications BSOD the core operating 
system? Fine, Microsoft didn't code the application causing it, but they 
sure coded the operating system that doesn't know how to handle malformed 
input.

And the first few years of Windows 95 saw many, *many* BSODs that were due 
to Microsoft code. That lead to the general impression and sentiment you 
see today.

Powered by blists - more mailing lists