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]
Message-ID: <4155A183.2070106@easynix.net>
From: devis at easynix.net (devis)
Subject: Windoze almost managed to 200x repeat 9/11

Joe dude, how much u are getting from M$ a month to hang around this list ?
Zero ? Noway....send em a letter now dude.
And please don't serve me,  'just being objective crap', you HAVE to be 
interested
to defend it that well., if not, well,  you may be missing on something...

joe wrote:

>Definitely some interesting theories Ron.
>
>  
>
>>1> the code was better done under the original OS, unix
>>    
>>
>
>While possible, nothing actually points at this as being the case. Anyway, I
>would be curious as to the functionality of the system when it was first
>launched on UNIX versus the end-result. Put this on Windows and run it 10
>years and then port to UNIX or *nix and there will almost certainly be
>screwups there as well. In fact, I would be pretty confident. I have dealt
>with poor ports to and from Windows and *nix. I have even dealt with bad
>ports from Mainframes to UNIX where the whole time the Mainframe people were
>saying the same types of things about UNIX that you like to say about
>Windows. Being a good coder for one OS doesn't make you one for all Oses
>when dealing with system level components and interfaces. 
>
>
>  
>
>>2> considering "how often" you seems to run into this same 
>>issue with other coders in the windows realm, windows coders 
>>tend to be especially lazy/clueless as compared to coders in other OS'
>>    
>>
>
>I would expect the issue is the same as always. Sheer volume. There are good
>and bad coders period. Microsoft has surely drawn more poor coders than any
>other OS with its pushing of the RAD/simple coding environment such as VB.
>Additionally the Windows environment as a whole has more inexperienced users
>and admins and people likely to try and code. There are also many good ones
>as well, they are just well buried in the poor ones.
>
>
>  
>
>>3> tools to code with in the windows realm are not as 
>>3> developed/functional
>>as they are in other envs
>>    
>>
>
>I would say this opinion is uninformed.
>
>
>  
>
>>4> M$ does not properly provide developers with clued information with
>>which to do their jobs
>>    
>>
>
>This is another opinion which I would call rather uninformed. 
>
>Even if there was poor function documentation, if you have a function, any
>function returning a constantly increasing counter you know, as a skilled
>programmer, that eventually it has to do something other than increase. If
>the value is signed the sign bit will flip or if it is unsigned it will roll
>to 0. How can a good programmer think any other thing? The compiler could
>have inserted exception handling code but at best that is simply going to
>bounce the program out of a normal running state. That is a compiler thing
>though, not an OS thing. I do hope you aren't trying to tell me that UNIX
>can magically and infinitely maintain a counter on a variable with a fixed
>bit size. I try to consider you to be a bit more intelligent than that.
>
>
>
>To put it in anotehr way, if you have a set of tires on a car that are rated
>for 75 MPH (say off road truck tires) and some person goes 90 and the tires
>fly apart or the vehicle flips or both, is the issue the driver, the vehicle
>manufacturer, the tire manufacturer, or the tree that produced the rubber
>for the tire? This is the same sort of case. You have it in your mind ahead
>of time who you want to be at fault because you have a bug up your bum about
>it and work to prove that stance. 
>
>Poor coding is a result of poor coders. I have seen amazingly bad code on
>all OS/RTS platforms I have worked on from RSTS to BSD to Linux to Windows
>to DOS to VMS. I have also seen some amazingly good stuff on the same
>platforms. Someone who doesn't understand basic data types and how to handle
>their limits is going to do a shitty job on all of the platforms. 
>
>Is the ratio of good admins to bad admins better in UNIX versus Windows?
>Absolutely. Is the ratio of good programmers to bad programmers better in
>UNIX versus Windows? Most certainly. Does this mean all Windows admins are
>bad admins, obviously not. Does this mean all Windows programmers are bad
>programmers, obviously not. I specifically say UNIX versus *nix because I
>think *nix is one or more steps closer to Windows in this discussion and
>getting closer as its popularity grows with Windows users. Switching to *nix
>doesn't make the admins or coders switching (or just using in tandem) any
>better simply because they switched.
>
>
>
>
>
> 
>
>-----Original Message-----
>From: Ron DuFresne [mailto:dufresne@...ternet.com] 
>Sent: Friday, September 24, 2004 11:25 PM
>To: joe
>Cc: mcw@....se; full-disclosure@...ts.netsys.com
>Subject: RE: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
>
>On Fri, 24 Sep 2004, joe wrote:
>
>  
>
>>Again, there are valid uses of GetTickCount and there are safe ways of 
>>doing so. If there is concern, I do recommend testing functionality 
>>associated with each of the DLLs. You might find a bug you can report for
>>    
>>
>kudos.
>  
>
>>On the incident, I would guess the vendor never had a clue it would do
>>    
>>
>that.
>  
>
>>That function can't return more than 49.7 days without breaking every 
>>app that currently uses it. MS can not do that. That is why there is 
>>another function to get the info with a different datatype. See my other
>>    
>>
>posts.
>  
>
>
>What seems to read clearly from your replies to this thread is that either;
>
>1> the code was better done under the original OS, unix
>
>2> considering "how often" you seems to run into this same issue with
>other coders in the windows realm, windows coders tend to be especially
>lazy/clueless as compared to coders in other OS'
>
>3> tools to code with in the windows realm are not as 
>3> developed/functional
>as they are in other envs
>
>4> M$ does not properly provide developers with clued information with
>which to do their jobs
>
>
>>From which you can combine any or all of the above for a correct
>interpretation of the total of your replies.
>
>Thanks,
>
>Ron DuFresne
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>"Cutting the space budget really restores my faith in humanity.  It
>eliminates dreams, goals, and ideals and lets us get straight to the
>business of hate, debauchery, and self-annihilation." -- Johnny Hart
>	***testing, only testing, and damn good at it too!***
>
>OK, so you're a Ph.D.  Just don't touch anything.
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>  
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ