Re: [SC-L] Genotypes and Phenotypes
On Mon, Oct 12, 2009 at 9:55 AM, Gunnar Peterson wrote: > Its been awhile since there was a bugs vs flaws debate, so here is a snippet > from Jaron Lanier > A: No, no, they're not. What's the difference between a bug and a variation > or an imperfection? If you think about it, if you make a small change to a > program, it can result in an enormous change in what the program does. If > nature worked that way, the universe would crash all the time. Certainly > there wouldn't be any evolution or life. There's something about the way > complexity builds up in nature so that if you have a small change, it > results in sufficiently small results; it's possible to have incremental > evolution. Right now, we have a little bit -- not total -- but a little bit > of linearity in the connection between genotype and phenotype, if you want > to speak in those terms. But in software, there's a chaotic relationship > between the source code (the "genotype") and the observed effects of > programs -- what you might call the "phenotype" of a program. Is this really true though? A small change in libc doesn't change the whole look and feel of a word processing program. It looks exactly the same, but maybe behaves very slightly differently over a small range of inputs, etc. And, while not being an expert in biology, I'm quite certain that there are very minor mutations in certain key places that result in complete system failure or almost entirely fatal diseases, conditions, etc. Is the complexity and expression of it really the key piece here? Or is it general resilience against failure, complexity spread out so that the common enemies (transcription errors in one place) aren't fatal. The system is designed against different threat models. -- Andy Steingruebl stein...@gmail.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)
Chris Wysopal wrote: > In certain cases like aircraft where the economic pain of failure > is high you get DO-178B, Software Considerations in Airborne Systems and > Equipment Certification. For that type of software you might see the > purchase of highly reliable libraries that have also met that certification. Good point! That's like how my former employer (BAE Systems) relied for sales on those who NEEDED a data guard (or whatever) to be on a platform that passed high levels of common criteria evaluation. If it weren't for that, similar software would have run just fine under Linux (even without SE) or even Windows. -Dave -- Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII -+ Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net| Email<>Web ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)
This seems to boil down to an economics problem. Notice how quickly the bean counters showed up after the thread began with a discussion of bugs and complexity. It is just too inexpensive to create new code and there isn't enough economic pain when it fails for anything to change for most software. In certain cases like aircraft where the economic pain of failure is high you get DO-178B, Software Considerations in Airborne Systems and Equipment Certification. For that type of software you might see the purchase of highly reliable libraries that have also met that certification. -Chris From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Andreas Saurwein Franci Gonçalves Sent: Wednesday, October 14, 2009 9:49 AM To: Secure Coding List Subject: Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson) 2009/10/14 SC-L Reader Dave Aronson mailto:securecoding2d...@davearonson.com>> Andreas Saurwein Franci Gonçalves mailto:saurw...@gmail.com>> wrote (rearranged into correct order): > 2009/10/13 Bobby Miller mailto:b.g.mil...@gmail.com>> >> >> The obvious difference is "parts". In manufacturing, things are assembled >> from well-known, well-specified, tested parts. Hmmm > Thats the idea of libraries. Well known, well specified, well tested parts. > Well, whatever. Ideally, yes. However, programmers love to reinvent the wheel. It's MUCH easier, both to do and to get away with, in software than in hardware... and often necessary. Need a bolt of at least a given length and strength, less than a given diameter? There are standard thread sizes, and people make bolts of most common threadings and lengths, for purchase at reasonable prices, at places easily found, and you can be fairly certain that any given one of them will do the job quite well. Need a function for your program? If it's as common as a bolt, it's probably already built into the very language. If it's nearly as common, maybe there's a fairly standard library for it... and if you're very lucky, it's not too buggy or brittle. Otherwise, it's probably going to be much cheaper (which is all your management probably cares about) to just code the damn thing yourself, than to research who makes such a thing, which ones there are, who says which one is how reliable, which ones have licensing terms your company finds palatable, and justifying your choice to management. Lord help you if it requires money, because then you have to justify it to a higher degree, get the beancounters involved, budgetary authority from possibly multiple layers of manglement, and spend the rest of your days filling out purchase orders. If you do wind up coding it yourself, is the company then going to make that piece of functionality available to the world separately, whether for profit or open source? N times out of N+1, for very large values of N, no way! Will they at least make it available *internally*, so that *they* don't have to reinvent the wheel *next* time? Again, N times out of N+1, for almost as large values of N, no. -Dave Exactly thats the point. Going a bit further, for every piece of hardware engineering, there is almost always a legal, worldwide or at least national standard to follow. This is inexistent in software. As long as anybody with at least one healthy finger is allowed to write and sell software, the current situation will not change. Make software development an engineering discipline with all the rights and obligations of other engineering sciences. No more coding without a license. Point. This would change the landscape of bits and bytes in a dramatic way. But it requires the support of the governments worldwide. My 2 cents (me too would have to get back to college and study some more, although having 25+ years of software development experience) ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)
2009/10/14 SC-L Reader Dave Aronson > Andreas Saurwein Franci Gonçalves wrote > (rearranged into correct order): > > > 2009/10/13 Bobby Miller > >> > >> The obvious difference is "parts". In manufacturing, things are > assembled > >> from well-known, well-specified, tested parts. Hmmm > > > Thats the idea of libraries. Well known, well specified, well tested > parts. > > Well, whatever. > > Ideally, yes. However, programmers love to reinvent the wheel. It's > MUCH easier, both to do and to get away with, in software than in > hardware... and often necessary. > > Need a bolt of at least a given length and strength, less than a given > diameter? There are standard thread sizes, and people make bolts of > most common threadings and lengths, for purchase at reasonable prices, > at places easily found, and you can be fairly certain that any given > one of them will do the job quite well. > > Need a function for your program? If it's as common as a bolt, it's > probably already built into the very language. If it's nearly as > common, maybe there's a fairly standard library for it... and if > you're very lucky, it's not too buggy or brittle. Otherwise, it's > probably going to be much cheaper (which is all your management > probably cares about) to just code the damn thing yourself, than to > research who makes such a thing, which ones there are, who says which > one is how reliable, which ones have licensing terms your company > finds palatable, and justifying your choice to management. Lord help > you if it requires money, because then you have to justify it to a > higher degree, get the beancounters involved, budgetary authority from > possibly multiple layers of manglement, and spend the rest of your > days filling out purchase orders. > > If you do wind up coding it yourself, is the company then going to > make that piece of functionality available to the world separately, > whether for profit or open source? N times out of N+1, for very large > values of N, no way! > > Will they at least make it available *internally*, so that *they* > don't have to reinvent the wheel *next* time? Again, N times out of > N+1, for almost as large values of N, no. > > -Dave > Exactly thats the point. Going a bit further, for every piece of hardware engineering, there is almost always a legal, worldwide or at least national standard to follow. This is inexistent in software. As long as anybody with at least one healthy finger is allowed to write and sell software, the current situation will not change. Make software development an engineering discipline with all the rights and obligations of other engineering sciences. No more coding without a license. Point. This would change the landscape of bits and bytes in a dramatic way. But it requires the support of the governments worldwide. My 2 cents (me too would have to get back to college and study some more, although having 25+ years of software development experience) ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)
Andreas Saurwein Franci Gonçalves wrote (rearranged into correct order): > 2009/10/13 Bobby Miller >> >> The obvious difference is "parts". In manufacturing, things are assembled >> from well-known, well-specified, tested parts. Hmmm > Thats the idea of libraries. Well known, well specified, well tested parts. > Well, whatever. Ideally, yes. However, programmers love to reinvent the wheel. It's MUCH easier, both to do and to get away with, in software than in hardware... and often necessary. Need a bolt of at least a given length and strength, less than a given diameter? There are standard thread sizes, and people make bolts of most common threadings and lengths, for purchase at reasonable prices, at places easily found, and you can be fairly certain that any given one of them will do the job quite well. Need a function for your program? If it's as common as a bolt, it's probably already built into the very language. If it's nearly as common, maybe there's a fairly standard library for it... and if you're very lucky, it's not too buggy or brittle. Otherwise, it's probably going to be much cheaper (which is all your management probably cares about) to just code the damn thing yourself, than to research who makes such a thing, which ones there are, who says which one is how reliable, which ones have licensing terms your company finds palatable, and justifying your choice to management. Lord help you if it requires money, because then you have to justify it to a higher degree, get the beancounters involved, budgetary authority from possibly multiple layers of manglement, and spend the rest of your days filling out purchase orders. If you do wind up coding it yourself, is the company then going to make that piece of functionality available to the world separately, whether for profit or open source? N times out of N+1, for very large values of N, no way! Will they at least make it available *internally*, so that *they* don't have to reinvent the wheel *next* time? Again, N times out of N+1, for almost as large values of N, no. -Dave -- Dave Aronson, software engineer or trainer for hire. Looking for job (or contract) in Washington DC area. See http://davearonson.com/ for resume & other info. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)
Thats the idea of libraries. Well known, well specified, well tested parts. Well, whatever. 2009/10/13 Bobby Miller > The obvious difference is "parts". In manufacturing, things are assembled > from well-known, well-specified, tested parts. Hmmm > > >> ... If you look at other things >> that people build, like oil refineries, or commercial aircraft, we can >> deal with complexity much more effectively than we can with software. >> The problem with software is that we've never learned how to control >> the side effects of choices, which we call bugs. >> > ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)
The obvious difference is "parts". In manufacturing, things are assembled from well-known, well-specified, tested parts. Hmmm > ... If you look at other things > that people build, like oil refineries, or commercial aircraft, we can > deal with complexity much more effectively than we can with software. > The problem with software is that we've never learned how to control > the side effects of choices, which we call bugs. > ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] Genotypes and Phenotypes
Its been awhile since there was a bugs vs flaws debate, so here is a snippet from Jaron Lanier Q: What's wrong with the way we create software today? A: I think the whole way we write and think about software is wrong. If you look at how things work right now, it's strange -- nobody -- and I mean nobody -- can really create big programs in a reliable way. If we don't find a different way of thinking about and creating software, we will not be writing programs bigger than about 10 million lines of code, no matter how fast our processors become. [After publication of this interview, Jaron Lanier realized that his sentence should read: "bigger than about 20 to 30 million lines of code...".] This current lack of scalability is a universal burden. There are monopolies in our industry because it's so difficult for anyone to even enter the competition; it's so hard to write large software applications. And that's strange to me. If you look at other things that people build, like oil refineries, or commercial aircraft, we can deal with complexity much more effectively than we can with software. The problem with software is that we've never learned how to control the side effects of choices, which we call bugs. We shouldn't be complacent about that. I still believe that there are ideas waiting to be created, and that someday we will have new ways of writing software that will overcome these problems. And that's my principal professional interest. I want to make a contribution to making bugs go away. Q:Aren't bugs just a limitation of human minds? A: No, no, they're not. What's the difference between a bug and a variation or an imperfection? If you think about it, if you make a small change to a program, it can result in an enormous change in what the program does. If nature worked that way, the universe would crash all the time. Certainly there wouldn't be any evolution or life. There's something about the way complexity builds up in nature so that if you have a small change, it results in sufficiently small results; it's possible to have incremental evolution. Right now, we have a little bit -- not total -- but a little bit of linearity in the connection between genotype and phenotype, if you want to speak in those terms. But in software, there's a chaotic relationship between the source code (the "genotype") and the observed effects of programs -- what you might call the "phenotype" of a program. And that chaos is really what gets us. I don't know if I'll ever have a good idea about how to fix that. I'm working on some things, but you know, what most concerns me is what amounts to a lack of faith among programmers that the problem can even be addressed. There's been a sort of slumping into complacency over the last couple of decades. More and more, as new generations of programmers come up, there's an acceptance that this is the way things are and will always be. Perhaps that's true. Perhaps there's no avoiding it, but that's not a given. To me, this complacency about bugs is a dark cloud over all programming work. -gunnar ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
