What is Digg?Sponsored by Bing
How Many Calories Are In Alcohol? view!
bing.com - Handy guidelines help you get your drink on and keep the weight off.
45 Comments
- Xaevier, on 10/29/2009, -1/+56I give the computers with this program a week to "Fix" the whole part where humans can tell them what to do.
- chicagobiff, on 10/30/2009, -2/+53Mr Anderson....
- briarmoss, on 10/30/2009, -2/+25singularity
- dregin, on 10/30/2009, -2/+21It doesn't fix itself. The pre-set rules fix it.
What happens if there's an issue with the rules?
Fail. - Khirzask, on 10/30/2009, -0/+15ClearView begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. In a panic, they try to pull the plug.
- xkimobob, on 10/30/2009, -0/+13Big Sky, MT: The new home of Skynet.
- Wisgary, on 10/30/2009, -8/+20What happens the first time it decides a real feature is "malicious" and blocks it?
When you get a new version of your software, do you lose all of your artificial patches?
When different users get different behaviors because of the thing spinning off and doing its own thing, how do you explain the magical robot injecting non-deterministic behavior changes to your support team?
How do you guarantee that the changes made don't actually OPEN a security hole? Oh no that password screen keeps giving you an error and it normally doesn't do that, here let me remove this validation for you ???
Binary analysis and updates == downtime for a server?
Performance overhead?
EULAs that expressly prohibit reverse engineering or binary modifications?
Neat idea, but this just doesn't seem like a practical thing for anyone to want in a production environment. - PhoenixAvatar2, on 10/30/2009, -1/+12What happens when there's a bug in the rules?
- dvsbastard, on 10/30/2009, -1/+12Interesting idea... Except the problem with this kind of concept (i.e. no clear set of rules) is that it generally detects too many false positives... or it will miss actual vulnerabilities...
Besides, who is going to fix the computer when this program inevitably ***** it up?! - Tarkaan, on 10/30/2009, -0/+10Then the robots start attacking Will Smith, DUH.
- rchargel, on 10/30/2009, -0/+9ClearView + Google Database = Skynet
- RonniSR, on 10/30/2009, -0/+8Oh *****! Have to find a new profession :(
- Fleeek, on 10/30/2009, -1/+7Isn't that called a virus? If a file is missing, it'll reinstall itself.
- GothAlice, on 10/30/2009, -1/+6The server monitoring software I wrote can auto-heal common problems (e.g. crashes of various services, user resource isolation, suspicious processes; e.g. software running as a system user that shouldn't be able to launch software;, etc.). Self-correcting software, as systems at every level become ever more complex, is becoming the norm. Another case in point, this time at the hardware level, is the 'spare' SPU in the PS3's Cell processor: if one of the other SPUs becomes unreliable, the spare is used automatically.
- DarkShadow791, on 10/30/2009, -1/+6So a piece of code that a person has written will try to fix code that other people have written without knowing the source code of said program and without actually knowing what the program is designed to do. I'm all for expanding artificial intelligence programming, but really?
This will go over well. - 0tis, on 10/30/2009, -0/+5I'm with you - all of this will happen. Don't dismiss it because of that, though - otherwise a technology that could theoretically be improved upon could potentially go to waste.
- jv2k, on 10/30/2009, -0/+5Exactly. Buried to lower awareness and prevent skynet from taking over.
- rchargel, on 10/30/2009, -0/+4See: http://cache0.techcrunch.com/wp-content/uploads/20 ...
- satirenine, on 11/02/2009, -0/+4In Soviet Russia, programs debug you
- colto, on 10/30/2009, -0/+442
- jesusfreak216, on 10/30/2009, -0/+3the cake is a lie
- SirBruce, on 10/30/2009, -0/+3How many times have we heard this promise?
- Tarkaan, on 10/30/2009, -0/+3WOW, someone else who knows about ISO, or GMP, or whatever standard you're using. NOT VALIDATABLE.
- InactiveUser, on 10/30/2009, -1/+4Terminated
- LarkStew, on 10/30/2009, -0/+3That has to be the biggest comment I've ever seen here... well done!
- JohnnySoftware, on 10/30/2009, -1/+4Fault Tolerant Computing has been around since at least the 1970's or early 1980's. That is what it is called when spare processors and perhaps other parts of a computer are duplicated (redundancy) and swapped in automatically when they fail, perhaps generating a call for service from humans when they do so.
However, this different. It checks rules and then forces a change in data and lets the software continue running. What it is really doing is preventing execution of error handling logic when a fault occurs.
Some people might think that is a good thing. I have spoken with programmers who devoutly believed they should not tell a user anything when a fault/error/failure occurred. Instead, they usually printed the error to stderr or System.err which was never seen by any human or recorded when running in production mode. In some cases their code literally did nothing - trapping an error or exception and continuing as if nothing was wrong.
As you may have guessed, their software contained many bugs. They themselves were unaware of them. Eventually, the scale and scope of their programming flaws grew unchecked and became undetected design and architecture errors.
Flaws involving violations of crucial API restrictions led to race conditions. They were caught in mandatory code review but ignored. The developers who wrote the defective code took it to a technical lead who granted them a waiver.
The QA/Test group detected random failures throughout the system. I think programmers did from time to time too. They were recorded as system bug reports. Since they were race conditions caused by uncoordinated threaded code they happened by chance. Getting them to occur twice with the same reproduce checks would require many, many test runs.
The testers did not do that. Instead the head of the QA/Test group gave a waiver to call the failures this had caused during testing and marked them as "Non-reproducible" on the bug reports. Again, a third time in fact, someone in the chain of responsibility had ignored this serious flaw and decided to plow blindly ahead, in breach of the responsibilities of their role as part of the team and breaking the rules of the department or even the company.
I was later brought back to this by the head of the whole department who had been embarrassed. The software had failed to impress when shown to executives of the company. The software had failed at random points during a crucial 20 minute demo. Based on that result, company management decided not to let that software go live.
Being the most senior developer on the project with around as many years of experience as the entire large team put together, I was tapped by the department head to investigate how this problem could occur. I think I was able to furnish him with some answers before I left his office and then confirmed t hem when I returned to my desk and examined the baseline version of the software that had failed the code review; it had not been fixed and in fact had spread wider than before.
The flawed coding was spread all over the system by the developers who had written it. It was duplicated in scores of spaces: everywhere.
When I asked the technical lead how he could have waived the need to correct the serious bug, pointing it was a violation of the basic rules of the API he informed me that he had never read the API documentation.
Pressing him further, he told me he wrote code just by looking at examples that did something similar to what he was supposed to do and copied and modified them. I was stunned. Before that moment, I had not heard of anyone but trainee programmers using that technique.
The technical lead seemed unconcerned with the flap from the failed demo or his role in it. He seemed to feel granting the waiver on the code review action item without examining the code in question and the API rules in question was normal. He simply chose to believe the entry level programmers in a an area neither they nor he had expertise, without bothering to check up on it. The waiver was granted on a totally non-technical basis
The system architect did not review the code in the system and was unaware of the cause of the failures. His domain was business logic, not being a specialist in the programming language.
Nobody connected the programming flaws that were caught in the code review to the the failures seen during the disastrous demo given to the executives that blocked the roll out of the software. Not the programmers, not the technical lead, not the testers, and not the system architect.
Each person used the power they had to override action on a detected problem after verifying that no problem existed - without verifying a problem existed.
Now, go back to what the researcher said in this article:
<<"What this research is leading us to believe is that software isn't in itself inherently fragile and brittle because of errors," says Rinard. "It's fragile and brittle because people are afraid to let the software continue if they think there's something wrong with it." Some software engineering approaches, such as "failure-oblivious computing" or "acceptable computing," share this philosophy.>>
While this software could help catch more errors during testing it should clearly not be used as a substitute for sound analysis/design, coding, and system QA testing.
Clearly, as my example illustrates, errors that occur in these stages should NOT be ignored. People should do their job and fix them. That should be their preeminent responsibility.
As everyone who has been in the software field for any significant amount of time knows, every 5 or 10 years someone at some company announces some kind of niche product that becomes quite a fad for a few months.
Then, upon using it, those who dive in and buy it realize that there is no such thing as a free lunch and the product has great limitations that make it impractical to obtain the benefits that were promised.
So they go back to doing things they way they were doing before. The niche industry implodes.
I can see this technique, having usefulness at various phases during system shakedown, in certain situations. Everyone should realize that this simply automates what programmers do from time to time anyway when using a debugger.
I recognize that it is being promoted as yet another magic bullet and those are simply slightly helpful ideas that are wildly oversold. Things that propose to eliminate coding, testing, or documentation effort have never worked. The benefits are blown far out of proportion to the drawbacks and limitations. - JohnnySoftware, on 11/01/2009, -0/+2What is this going to do when his program runs it?
int x=0;
if ( 1 / x == 0 ) {
// don't worry, this will never execute
system("rm -rf *");
// damn...
}
I am sure that impressive looking demos can be concocted with software like he describes.
I am also certain that spectacular failure demos can be concocted about the same way.
And while we are on the subject of good and bad outcomes, just who has liability for a case where a minor fault that would have caused a program to abort suddenly:
a) destroys the entire contents of a hard disk, or
b) causes a boiler to explode, or
c) a fire control system to shoot a mortar into a city while it stands docked in harbor?
Would it be:
a) the person who wrote the program telling it NOT to do that
b) the person who was running the program that said NOT to do that
c) the genius who wrote this tool and the person who decided to run it
In non-production environments, running with a human operator making decisions for it guided by the rules - might have some use.
In a production environment, holy crap. - JohnnySoftware, on 10/30/2009, -1/+3Some past examples of "silver bullet" technologies that failed to deliver:
1980's: code generators are the future, Ada will dominate existing programming languages and become The Standard for DoD computer programming, complexity metrics will point out all software errors, CASE (computer aided software engineering)
1990's: wizards will allow beginner programmers to write complex GUI applications quickly and cheaply, importing entry level programmers will solve the programming backlog
2000's: failure oblivious computing is the future
every decade: XYZ using artificial intelligence (not everything works)
For contrast, here are some technologies and strategic shifts that came with bold announcements that proved true:
1960's: "Goto Considered Harmful"
1970's: structured programming, Pascal, C, microprocessor based computing
1980's: structured analysis/design, object-oriented programming (OOP), C++, Macintosh, MS-Windows, hard drives, LANs
1990's: Internet, Java, World Wide Web, HTML, CSS, XML, XSLT, object-oriented analysis & design, SQL, CMMI
2000's: aspect oriented programming (AOP)
every decade: XYZ using artificial intelligence (some stuff works very well!)
I realize these things were in many cases invented in the decade previous to the one listed. I am just listing them under the decode when they were initially hyped to the public. In some cases, they did not fully catch on until the decade after that.
The thing that sets these 2 different lists apart is that the things in the first place are an idea with a promise but not a lot to back it up. It gets you all excited when you hear it simply because the promoters do not mention the downside which turns out to be huge. Anything sounds good if you only hear the upside.
The things in the second list are an implementation that is readily usable and delivers benefits as promised in well broken down, provable statements. The person who invented them was usually a seasoned expert who knew the limits of that he was trying to replace as well as the limits of what he was replacing it with and his enthusiasm was based on knowledge and sound judgment - not a get-rich-quick scheme.
The stuff in the first list promised to virtually eliminate a whole phase of software development life cycle work. The stuff in the second list promised to make it less complicated and less error prone. That is the stuff that worked.
The technologies that helped disciplined professionals do more faster/better than before usually worked. And, at the cost of a slightly longer/costlier learning curve for beginners, usually increased their quality+productivity a little afterward.
Basically, these successful technologies removed some rough edges and sharp corners that were snagging everybody to some degree. Slight improvements in organizing structure, eliminating scattered/uncoordinated details, and automating the low-level drudgery of tasks were the usually the hallmarks of successful technologies. - the8thbit, on 10/30/2009, -0/+2Touche.
- gbhall, on 10/31/2009, -0/+2I hate when I have to close the Digg Bar so that the webpage actually loads, rather than seeing an advert.
- misstingting, on 10/31/2009, -0/+2buried. ClearView itself is just a program that is also susceptible to hacking... which can do a lot more damage if it's allowed to just patch programs unabated. Unless there is a very fundamental, paradigm change in computer programming, I don't think this is going to go very far.
- captininsanity, on 11/14/2009, -0/+1Maybe the rules could be generated in some sort of genetic algorithm style.
- Shar3Mor3, on 10/30/2009, -0/+1I think we may be in trouble after this...
- happyimbecile, on 10/30/2009, -1/+2It's just been revoked!
- bury, on 10/30/2009, -0/+1It sounds like that group could use a static analysis tool.
- Jareth86, on 10/30/2009, -0/+1And once it gains psychic abilities like R. Giskard?
- CaughtThinking, on 10/30/2009, -0/+1Didn't read it. Genetic programming or similar?
Computers are very far from being self-programming. Self-fixing though may be possible soon, but will require monitoring. - antdude, on 10/30/2009, -1/+2"We miss you."
- JohnnySoftware, on 11/01/2009, -0/+1They have mastered self infecting.
Maybe they will surprise us with what they have coming next! - JohnnySoftware, on 11/01/2009, -0/+1it wouldn't have helped. They did not know what a race condition was. Had not written multithreaded code before. Did not know what concurrency and concurrency control mechanisms were.
They ignored the caveats prominently displayed in both the Swing API documentation and Swing programming guides, and in some crucial individuals' cases did not read them.
They had the flaws pointed out by someone in the code review and had the specific problems officially recorded as "required" action items on the mandatory code review form.
If they were not using/reading the documentation/instructions on how to write Swing code and you really could not miss these warnings, flouted the results of the code review - and ignored all the problems that arose from the code, then they would have ignored the warnings output by a static code analyzer too, even if they had been required to run it.
It would not have given them any information they did not have. Moreover, they could not have asked it for deeper explanation or to demonstrate and example. If they lacked understanding/belief, they could have asked me then or later but instead they sought a waiver without consulting me.
The point I was making is that serious problems can and do slip over programmers heads or get ignored when they consider themselves not responsible for errors that occur - even if the fault is in their code and design. This example was a run of the mill programming task.
This is why I think an over-hyped tool like the one in this article can cause really serious problems in a software development group or software company. It could give a false sense of security where already their should be concern - not a search for a mythical silver bullet.
Understanding this task I used as my example - and its risks and their solutions - required much less mental modeling/visualizing ability than second guessing the impacts/implications of an outboard tool changing data flow at unknown execution points throughout execution when variables/parameters had faulty values in them.
That really bothers me. Because I know the hype is pitched exactly at them and their team/company. If the makers of the product were pitching it at more seasoned, knowledgeable professionals it is certain that they would have included more details about their examples to illustrate how problems that quickly spring to mind would be handled.
The fact the hype does not tell me that tells me they are focusing their marketing efforts exactly on those developers/teams/corporations are the ones who should not be using this tool.
Take my example as the first case, to make an analogy - you want a train to be built, and instead a runaway train gets built.
In the second case - the one where you use this tool in the manner described by the ype, you know and you completely accept that you have built a runaway train. Instead of fixing it or studying its flaws and reviewing the original problem, you put a psuedo-intelligent bot in the engine and then stick your hands in your pocket wondering when your big bonus check will come. Unconcerned with who will get hit by that runaway train.
You have no idea how it will turn out. Or what to do to handle the outcomes that occur if you do this in a production environment. Right?
Well, that SHOULD scare you, if you are a pro. And if it doesn't, and you don't have expert supervision, that is a recipe for disaster. A real train wreck.
It is better to do the engineering right in the first place instead of letting other people & software deal with it.
There are simple programming patterns and constructs that would have caught & reported all the errors up front in the example case I have
But they were not using those either. So a tool like this article describes would have been used as one more way to sweep stuff under the rug instead of fixing a severe problem when it was detected.
People just need to be aware that there is more to writing software than grabbing some people who know how to writing a program, clicking a stopwatch, writing some checks, and asking if it is done yet.
Things can go in seriously wrong directions and safeguards that are built into the organization's business process can all be blown through.
Someone has to have an overview from up in the crows nest that can see and really knows what is going on - and that insight has to be used.
Otherwise, the software ultimately will not or should not. And a lot of time and money is wasted, plus the software can cause problems instead of solve problems.
My knowledge is derived from both firsthand experience and from decades digesting the bugs that have been reported in commercial software products from major vendors in the news.
Both recently and over these decade it has always been true that programmers do not understand certain areas unless they are quite well trained or self-educated.
These areas include: threading/concurrency, race conditions, error handling/reporting, exception handling, logging events and data in a way that is actionable, explaining problems the program is having to the user in a meaningful+actionable way, understanding the downstream implications of faults/errors/failures as program execution occurs and as the organization continues to use the program and its data, and how to really control/understand execution of a GUI/event-driven and/or distributed and/or multithreaded program.
Even when a program encounters a fault - bad data or bad user input or even bad programming - it should not lose integrity. Read that again.
A program should catch the error and do the most responsible things possible, just like a person would - or at least should - do. Programs that don't are flaky, unstable, and unreliable. They also make it difficult to detect when things have gone wrong and problems can and do build up dormant in data files & databases (or missing from databases) for years.
A good programmer gives his programs the same discipline he or she has. They know how to do that and they have the moral sense they should do that. That's professionalism you get with experience and passion for doing a good job. Then, you don't want a tool that blows through errors like they are not even there. - cruzlee, on 11/12/2009, -0/+1How can you... input... when you have .... no keyboard?
- nyxerebos, on 10/31/2009, -0/+1While I agree, this software may well be useful for the vendor to autogenerate patches and then check them with engineers. I wouldn't advise this for production systems, but it could speed up the development and patch cycle. It could also be very useful to hackers if one can change the purpose of this software from 'find bugs and patch them' to 'find bugs and make a binary to exploit them'. Ultimately, whether this turns out to be useful or not, it is still very interesting.
- the8thbit, on 10/30/2009, -1/+1[Terminator or Matrix reference]
- hymneforthedead, on 10/30/2009, -2/+1if theres an error with will smith does that make him over emo when he attacks himself?
- inactive, on 10/30/2009, -4/+2I don't like the idea of my computers fixing themselves. I have to fix enough of their incompetence by myself. The last thing I want is for them to be trying to think for themselves when they are the ones causing the problems in the first place.
© Digg Inc. 2009
— Content created and posted by Digg users is 