Autonomic Computing
pvcpie writes: "The New York Times has a story today about Autonomic Computing, which is described as "a biological metaphor suggesting a systemic approach to attaining a higher level of automation in computing;" and they published a paper (pdf) on the topic. Apparently there are already some universities signed up on Autonomic Computing projects, more info was available on the website and in the nyt article. It also appeared in CNET."
A program/database is only only as good as the knowledge of the person who has input and wrote it. If a PC thinks that to wipe it's hard drive is the best way to fix itself, I'd blame the author who wrote the maintenance program. No expert would wipe a hard drive as a general fix for a PC, and would not write these instructions into the PC.
In my opinion, part of a autonomous PC is to be self-sufficient, not act like a lemming and follow other PC's just to follow.
Plus, just as human have a basic survial instinct to survive, I think you'd write this instinct into the PC as well and not have it destroy itself (unless it was doing major harm to its master, etc. Remember Asimov's rules for robots).
Finally, I agree humans will never be replaced as the final decision maker in fixing and running PC's, servers, networks, etc., but when I was a sys admin, I'd have killed for PC's to be smart enough to do some of the basic, mundane, man-hour, labourious tasks such as upgrading Service Packs if I told them all to do it, install programs, etc. Then I could have done more fun stuff. Plus when I had to fix a problem, people weren't glad to see me, because I was only there when something went wrong. Granted they were happy someone was there to fix the problem, but all would have preferred that there was no problem in the first place (PC fixed itself).
--- RFC 1149 Compliant.
"The only way to get efficiency gains in information technology is to take some of the people out."
They're called managers.
It tells your heart how fast to beat, checks your blood sugar and oxygen levels, and controls your pupils so the right amount of light reaches your
There's an OO principle called dimeter which advocates as few dependancies as possible between objects. This sounds like a lot of hooks all over the place which is not a model of simplicity. It would be better for "it" to step out of the way and let each object adjust itself based on its surroundings just as in natural systems. Nature has a tremendous advantage over computers. It is far more efficient because everything is happening literally in parallel. Computers can really only do a very limited number of things at a time although sometimes the user perceives concurrencey due to very rapid time-slicing.
As a result, programmers are forced to make tremendous compermises given the comparatively limited medium with which they have to work. It will take well established techniques and objective analysis to determine the be way to utilize bits on silica.
Over the years I have recognised one principle that transcends this issue -- the issue of dealing with complexity. Oversimply it is Recursive Composition. This "pattern" or OO construct as it is sometimes referred to does not have a Class or particular set of relationships between objects. It's completely arbitrary. The idea, is to recursively delegate the responsibilty of another part of the system to yet another module. At the leaves of this tree you have the primative operations and at the root you have one simple instruction for triggering a potentially very complex cascade of instructions. Thus you have reduced the complexity of the overall system. The key difference between this and just another group of functions calling one another (and thus target to reduceing complexity of programs and in real-life systems) is parameterization.
As a simple example, imagine trying to encode or decode a database file. The database file has a header, a record list, and data chunks. Like this one on PalmOS PDB files. If one were to apply the principle of Recursive Composition the API for this PDB codec would be, at the top level, PDB_decode(char *src). At the next level down you have operations like Hdr_decode(char *src) and Record_decode(char *src). At the leaves you have dec_uint32be(char *src) to decode an unsigned 32 bit integer in Big Endian byte order.
If you can parameterize cleaning exactly what is required to perfrom a task and delegate it to another module you have broken the problem into at least two smaller problems which reduces the order of complexity. Simple!