RE: Standards for developing secure software

From: Ogle Ron (Rennes) (ron.ogleat_private)
Date: Fri Jan 24 2003 - 01:47:20 PST

  • Next message: Stormwalker: "RE: Standards for developing secure software"

    I must also digress because there seems to be a lot of ignorance going
    around on speed/performance.  I have a recent point of experience on this
    subject that makes your comments really quite lacking an understanding of
    how the performance of a system in reality will not be affected by the
    language at all.
    
    I designed a system to solve a problem to protect data in a production
    environment.  The components were a client on the production line, a server,
    and a database holding the data.  The client and server components were
    written in Java.  The database was Oracle, and we used some C programs to
    tie the server to the database.
    
    Everything worked that is until we encounter really heavy loads.  Then
    everything fell apart.  Upon analysis of the system, the Java components
    didn't cause the problem.  The problem was that the C programs were written
    so badly that they contributed to 100% of the timing issues.  The term
    "badly" here refers to the understanding of the relationship of what
    database functions should have been called and the order in doing the work.
    
    The point is that a system's performance may have very little to do with the
    programming language.  The C programs that had the serious performance hits
    were programmed both securely and "correctly" from a syntax point of view.
    But since the programmer didn't have a clue on how calls to the database
    reacted and the proper order to do the calls, the C programs took huge time
    hits once the system was loaded.
    
    We have now corrected the problems, but speed/performance in this case had
    nothing to do with how fast or slow Java was in doing its work.  BTW, I'm
    sure glad that AT&T decided to pay a penalty to for C (assembly can be such
    a pain).  In the same light, I'm glad that Sun has decided to pay a penalty
    for Java (C can be such a pain).  Hopefully in the future, company X will
    develop the ACME supper duper programming language because Java can be such
    a pain.
    
    If speed/performance were always the most important contributing factors,
    the language of choice would still be assembly.  Most developers have
    learned better.  There still maybe some portions of a system that are
    developed in assembly, but most software components are developed in a hll
    now.
    
    Time to evolve
    Ron Ogle
    Rennes, France
    
    > -----Original Message-----
    > From: Witness [mailto:bmeyer67at_private]
    > Sent: Thursday, January 23, 2003 07:23 PM
    > To: securityat_private
    > Cc: secprogat_private; stefan.schildtat_private
    > Subject: RE: Standards for developing secure software
    > 
    > 
    ...
    > Here I must digress and cite the example of Java.  While it 
    > is certainly
    > the hll - and probably the one you are most thinking of - it 
    > is also the
    > language with the worst performance. While throwing more hardware
    > (memory/cpu) at it will speed it up and perhaps make the speed
    > differences between it and C or C++ less noticible, the 
    > difference will
    > still be there.  And I for one don't think we should pay such 
    > a penalty
    > for security. Instead, I think that programmers should do it right in
    > the best language - that is one that provides the best 
    > speed/performance
    > and functionality - for the scenerio and then do it right so 
    > as there is
    > no need to incur costs like that of using Java.
    > 
    > Just another $0.02,
    > 
    > BRM
    > 
    



    This archive was generated by hypermail 2b30 : Fri Jan 24 2003 - 11:25:05 PST