Maybe it never tried.

That and also more importantly: because nature's idea of "better" is almost never the same as our idea of "better." I think it's wonderful that the performance example that they used, happened to be binding to cancer cells. If cancer doesn't illustrate the vast gulf between us and it, I don't know what does!

Ensuring all developers in the industry are competent is a pipe dream. Take a look at the most exacting careers you can think of - and you'll find varying levels of competence.

People are imperfect (in the sense that they can have a bad day, and let typos slip by from time to time - even the very best of us). Additionally the real software lifecycle is not like frozen water. It is more like all the different states of water - solid, liquid, and gas, changing as its environment changes on a continuum from birth to death.

I agree we should do something. I think that 'something' should be more than just training and hoping they use what they've learned.

People are not perfect automatons - therefore you always run the risk, and probably will see new bugs and vulnerabilities. However, that is okay - in the sense that it will still reset the clock (assuming you caught the existing zero days in the process). Now the hackers will have to start over - and it will take them another 6 to 12 months to figure out an exploit to the bugs you introduced - assuming they are actually exploitable. Therefore it makes sense to review and refactor code on a recurring basis. The benefits outweigh the costs.

The real problem here is willingness to fund what is necessary - refactoring all code used in critical systems to ensure they are secure - and to maintain that approach over time in an iterative basis.

We should touch code (at least to review it) - every year - which research indicates is the sweet spot for zero-day exploits. We get more benefits if we refactor the code - effectively resetting the clock for exploit writers to find a new zero day, and develop applications to exploit it.

Working in IT today, I can tell you from experience no one is willing to spend money to constantly refactor code without delivering new functionality (read 'revenue generating functionality'). This approach also is counterintuitive to software engineers trained to value code reuse over rewriting or building new solutions.

Instead, they focus on cosmetic bandaids - such as firewalls, antivirus, patch updates, and policy management. All of these things are important - but in the scheme of things will not stop a zero day exploit - particularly given that most patches for zero days are not available until the zero day is discovered - and then the time it takes the developer/company in question to put out a fix - on average 6 months to a year after the zero day is discovered and reported. Meanwhile the network is wide open to anyone who has figured it out (which is roughly 6 months to a year after a new piece of software is deployed on the network). The problem is related more to how humans learn systems than any particular coding practice. Your code refactor efforts just need to fall inside of that curve - leading rather than following.

Finally - the proposed fixes, such as more regulations, will not fix the problem - and will only serve to drive people out of the business, at the precise time when we need more developers than ever to address the problem effectively.

Steps:

1. Pay for what is needed in IT instead of being cheap. If you get more specific regulation of this - you might not have a choice (e.g. Sarbanes-Oxley)

2. Let your developers as a whole spend some time on evaluating code - the more eyeballs you have the better.

3. Move away from expensive water-fall projects to more flexible agile methods, and adjust your funding protocols to match.

grep "terror" /var/log/mail.log

The article left out that terrorists will be required to send from a hostname that has the word "terror" in it. Failure to do so, is a violation and will be punished!

Well, i want to do something on Android, so Java is the way. :(

Yes, Java is still ugly, but at least it's consistently ugly.

rwa2++;

It sounds like the project you want [someone] to start, does this: reads a config file, looks at what modules ended up actually getting loaded, and then enables/disables config options, writes a new config file. Then your subsequent compiles can be faster and your /lib/modules can be smaller.

I suspect there are two problems for them in being too clear. First, I suspect they can't guarantee to reuse every cartridge - some of them will be damaged or contaminated, I imagine; second, they won't want to validate third party cartridge refills by admitting they actually do refills themselves! I recycle my Lexmark cartridges by mailing them back (with a prepaid shipping label they include with every new cartridge); my guess is they will refill and reset perfect-condition cartridges, recondition damaged or older ones, and recover the raw materials from unusable ones, but they won't want to be too open about the details. The "new" cartridges aren't exactly cheap, admitting they're sometimes actually refills would probably hurt sales.

make the entrants build a working prototype *first*, without any governmental money up front

Waitaminute, Congressman. Why would I fund your campaign, if you're not going to vote to give the public's money to me? I thought we had a deal: you scratch my back, I'll scratch yours.

I still buy CDs. They're (currently) the best way that I know of, to get music. Better ways are possible but aren't yet widespread.

Tell ya what: go to some live music bars tonight, and if you're lucky, you might find a band you never heard of that you really like. Tell me how you listen to their music the next day. Assuming you succeed (it's reasonably likely but far from guaranteed) I bet you will come up with an inferior approach to buying their CD from them. But maybe not: go on, teach me about a better approach.

Remember Comcast?

How i wish i had held on to that letter.