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  linux-hardening  linux-cve-announce  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: Thu Oct  6 16:05:07 2005
From: bkfsec at sdf.lonestar.org (bkfsec)
Subject: Bigger burger roll needed

Micheal Espinola Jr wrote:

>Bruce, I don't think you are going to find hard "evidence" for either
>conclusion.  But Bruce's conclusion is consistent with my own
>experiences, and that of many other Administrators that I discuss
>issues like this with.
>
>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.
>
>  
>
I agree, in general, that the vast majority of the BSODs I've seen on 
the NT line have been caused by bad drivers.  On occassion, though, I 
have seen poorly written software that has BSOD'ed NT 4.0 before.

However, the original topic was about users and their exposure to 
Microsoft products.  User exposure to the NT line really began with 
Windows XP (aside from a smattering of Win2k installed desktops)... so 
the real initial exposure that users have had to Microsoft products is 
actually the DOS/Win9x line and those most certainly crashed frequently 
in situations where a driver wasn't necessarily the culprit.

Not to mention the fact that a Windows XP or 2000 system can still crash 
without getting a BSOD, and that crashes of either the OS or 
applications can and do regularly occur.  Further, the argument that 
third party drivers are always the cause and that merging code bases is 
not Microsoft's problem completely and totally ignores the fact that 
other OS' don't have the frequency of crashes experienced while using 
third party code that MS does.

So, whether it be the shoddy coding that causes BSOD's in the 
DOS-dependant line of MS apps, or the shoddy coding that causes IE to 
freeze on Windows XP... or the shoddy coding that third parties carry 
out and that Microsoft allows to affect the system in such a way... 
nonetheless the net result is the same... the user's expectation has 
been lowered.

                   -bkfsec


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ