The problem with data security on an open network is not the lack of adequate technology or know-how because current methods of securing computers do work. Otherwise, our electronic commerce systems would have collapsed years ago. The problem is that hackers look for and often find ways of getting around the security barriers by exploiting defects in the underlying software. A network's security is thus intimately tied to the reliability and robustness of the network's software. Security companies have no way of guaranteeing that the various software modules used in their systems are defect-free. This uncertainty is the Achilles' heel of the security industry. The solution is to move away from algorithmic software and adopt a non-algorithmic, signal-based, synchronous software model.
Could be that Diebold is hiding some illegal stuff (probably stealing other people's ideas or code) and don't want to be found out. Just a thought. It's obvious that North Carolina is only asking for the source to the stuff that Diebold itself developed, not third parties like Microsoft. The Windows defence is just a lame strawman, IMO.
Mod me down if you wish but I think the CBE architecture is bound to fail. The reason is that you don't design your software model around a new processor. It should be the other way around. You first come up with a software model and then design a processor optimized for the new model. This way you are guaranteed to have a perfect fit. Otherwise, you're asking for trouble.
The primary reason that anybody would want to devise a new software model is to address the single most pressing problem in the computer industry: unreliability. The reason that software is unreliable is that it is based on the algorithm. Switch to a non-algorithmic, signal-based, synchronous model and the problem will disappear. Unfortunately current processor architectures, including the CBE, are optimized for the algorithm. Click on the link below for details on a new software model designed to solve the reliability problem.
Suggestion of Great Britian, possibly. They tend to have their heads screwed on straight. Canada, our 51st state? What would be the difference?
Ah, Great Britain. The country that spies on its people more than almost any other. Just a couple days ago, we learned that the British are going to monitor the movement of every vehicle on the road. Big Brother, if you ask me. Or is it a sign of the beast?
Gates seems to have forgotten the audience in this case
You underestimate the intelligence of the people at Microsoft. They want to create a new market targeted toward a different kind of people, those who would not normally use a supercomputer because of the technical difficulties. It's kind of like the way the GUI opened up computing to a lot of people who found a command line interface daunting, to say the least.
During this 40-minute antenna change, information about the spacecraft's vertical motion was unavailable to ground controllers.
For a country which prides itself as being at the forefront of robotics technology, this is rather surprising. The latency inherent in space communication over great distances is the primary reason for using intelligent robots in space. If the probe was sufficiently intelligent, it would perform its tasks without supervision from ground control. I hope they (including NASA and the ESA) put a lot more effort into automating their space probes in the future.
Global temperatures are extremely tied in to CO2 levels
This could also be written to imply the opposite of what you intended: CO2 levels are extremely tied to global temperatures. How do you tell which caused which?
or, at the very least, the worst case of vaporware ever. Personally, I think it's an unmitigated con game and the principal con artist is none other than David Deutsch of Oxford. One man's opinion.
One more thing: I just put on my flame-retardant suit. So flame away! ahahaha... And don't forget to mod me down too. ahahaha...
Consider how much software is written by people with five years or less of professional experience, on short schedules, with no time allocated for continuing education. If software projects weren't always rush jobs, and on relative shoestring budgets, the quality would be better.
The software reliability crisis has very little to do with greed, engineering incompetence or the lack of big budgets, in my opinion. There is something fundamentally wrong with the way we program our computers, something that no amount of quality control measures can ever cure.
The reason that software is bad has to do with a custom that is as old as the computer: the practice of using the algorithm as the basis for software construction. Switch to a synchronous, signal-based approach and the problem will disappear. Complex algorithmic software is essentially unreliable, something that Fred Brooks has shown in his now famous "No Silver Bullet" paper back in 1987. For an alternative approach to software construction see this article in The Silver Bullet News.
Regardless of what has been said in the past, the problem can be solved. Otherwise, we are in big trouble, very big trouble.
On the maps which show storms' predicted paths, it's much easier if you can write "K" to mark a storm's position rather than "Katrina".
Ah, thanks. Makes sense. Although I think it would probably be just as practical to use numbering scheme. But, not being a cartographer nor a meteorologist, I will defer to the wisdom of the profession. I am sure they are all very smart people who know what they're doing.
Why not put 10,000 names in a hat (or a computer) and just pick one at random? Why does it have to be based on the alphabet? And why do they have to go to the next letter after each storm? I mean, is there an adevantage to this weird naming scheme? Do the storms care?
I'm sick and tired of hearing talk about holding vendors or developers legally responsible for writing insecure code. It's impossible to write any complex application and not have security problems.
Software is unreliable because we have been doing it essentially the same way for 150 years without stopping to think that there might be a better way. We've been writing algorithms ever since Lady Ada Lovelace penned down the first table of intructions for a digital computer. It's time we reevaluate the algorithmic model. Switch to a non-algorithmic, signal-based, synchronous software model and the problem will disappear. Until then, we can't hold either vendors or programmers liable. Didn't Fred Brooks show that algorithmic code is essentially unreliable? See link below for more info on non-algorithmic programming.
Then the music industry joined in with some punches of its own, saying it too will hunt those who share songs online.
It's time that the powers that be recognized that the current IP laws are not only stupid but have become obsolete in the internet age. Certainly, artists and inventors must be compensated for their work and creativity but the IP laws are not the way to do it. The IP laws are being unfairly used by a few to oppress the many, all in the name of greed. The nations of the world should form a fact-finding commission to come up with a different way of compensating IP creators. I think all information should be released freely on the internet (unless the inventor has a way to keep it a secret). A fully funded international body should then determine what sum of money should be allotted to whom based on utility to the public, download data or some other poll mechanism. All nations that use the internet should participate. Inventors and artists would simply publish their stuff on the net, file a claim application with the IP Authority and wait for their checks in the mail. If necessary, as we get more confident in the use of the system, allotments should be made retroactive. Otherwise, I see nations going to war over IP or worse. One man's opinion.
If one really want to cut costs, one should replace employees (especially astronauts) with robots. Oh wait, they got rid of the engineers who were going to make the robots. Never mind.
This is not a well-thought-out feature at all. How is the database supposed to know what data an application *might* access? The database provides all the necessary isolation and notification systems. That's all it can do.
Well, maybe it's not the database's job. Maybe it should be part of the data access layer that connects the database to the applications.
Also, how is the database supposed to notify the application? Would it throw an exception/error/warning/notice the next time you executed some SQL? Would it be a separate API call (in which case, why not just use LISTEN/NOTIFY)? Would it signal your process (thereby killing it if you don't have a handler)?
It makes no difference what the actual mechanism is. In the system that I envision, every dependent app should provide a handler for automatic notification.
And the idea of "resolving" these dependencies would require a huge amount of knowledge that the database has no way of knowing.
I don't think so. It's just a matter of associating write accessors to read accessors of the same record.
Say Application X writes to Tables A, B, and C. Application Y writes to Tables A and D. Under what circumstances would App X need to know that data in Table A had been put there by App Y, or vice versa? How do existing database systems fall short of satisfying such a need?
No. There has to be read access to a shared table in order for a dependency to exist. The reading application is the dependent component.
While true in a general sense, I'm not sure the correct solution to the problem is to add ADDITIONAL complexity the the system.
Complexity is not the cause of failure, IMO. The problem is a lack of timely communication between parts of the system. This is true both at the system or network and the program level. Oftentimes, a variable is modified by one part of the program unbeknownst to some other part which may crucially depend on the state of the variable. Only a non-algorithmic, signal-based approach to software construction can solve this problem.
Don't be silly. PostgreSQL has had this feature for ages (atleast since 7.x days) implemented via NOTIFY, which interested listeners can register to be notified of.
Thank you. But that is not what I meant. There should be a software mechanism that automatically identifies dependencies and resolves them. Leaving it to the programmer does not solve the problem because programmers come and go and may not be aware of old dependencies. The problem is especially annoying in legacy systems. Modifications made to a complex system can have unforeseen consequences if programmers are not aware of the dependencies.
MySQL has finally caught up to the state of the enterprise relational database industry
One of the things that is missing in most if not all databases (AFAIK) is an effective mechanism to deal with data dependencies. A data dependency exists whenever two or more applications of components share read/write access to the same records in a database. We need a simple to use mechanism that will notify relevant applications of changes in a shared record. Resolving dependencies in a timely manner is extremely important to system or network reliability. Data dependency problems also exist within applications but that's a slightly different issue, one which is made all the more hard to deal with by the algorithmic nature of software.
The problem of software failures has very little to do with the competence of developers, IMO. Sure we can make software very reliable given enough time and resources. But we don't have that. In our modern society where everything depends on software, we cannot wait forever for the software to be bugless. Avionics and other safety-critical applications are extremely expensive precisely because of this. The problem has to do with our current software construction methodology. No amount of software metrics can guarantee the full reliability of complex algorithmic software.
The problem is not complexity but the algorithmic nature of software. Switch to a signal-based synchronous model and the problem will disappear (see link below). We can hold developers legally liable only if a method is found to guarantee reliability. We hold other engineering disciplines liable only because they have known ways to ensure safety. When it comes to mission-critical applications, very high reliability is not good enough. Only 100% reliability will do. The proper role of quality control is to ensure complete reliability. This is impossible with our current software construction model. There is a solution, however. If only we could wake up and realize that the algorithmic model is hopelessly flawed. We must reinvent computing at the fundamental level. EEventually, even processor architecture will have to be overhauled. Afterwards, software developers will have no excuse.
He doesn't seem to think that writing poor code is entirely the fault of coders though: he blames the education system.
To hold programmers responsible for software failures is downright irresponsible. Programs are not bridges. Whereas bridge engineers can use known procedures and practices to ensure bridge safety, the same is not true of software engineers. It is impossible to guarantee the reliability of complex algorithmic software. This much has been shown by Frederic Brooks. But, regardless of what Brooks claimed in his famous No Silver Bullet paper, the reason has nothing to do with complexity (there are many good examples of reliable yet highly complex systems in nature), but with the algorithmic nature of our software. Switch to a non-algorithmic, signal-based synchronous model and the problem will disappear. See the link below for more on this important subject.
The problem is as old as Lady Ada Lovelace who wrote the first algorithmic code more than 150 years ago. We've been writing algorithmic programs ever since and the ensuing unreliability problem has turned to a major crisis. The problem is not software. The problem is algorithmic software. Switch to a non-algorithmic, signal-based, synchronous model and the problem will disappear.
Bug free software is possible, so long as it is done right and people are prepared to pay for it.
It is impossible to guarantee the reliability of complex algorithmic software. This is something that Frederick P. Brooks has shown in his famous "No Silver Bullet" paper. However, Brooks' arguments fall apart in one important area. Although Brooks' conclusion is correct as far as the unreliability of complex algorithmic software is concerned, it is correct for the wrong reason. Software programs are unreliable not because they are complex (Brooks' conclusion), but because they are algorithmic in nature.
Last week, an article in the Wall Street Journal's OnLine Edition gave a vivid description of the costly software reliability problems that Microsoft has had to endure in its effort to develop the next version of its Windows operating system. It drove home a point that I have repeatedly made in the past. The biggest problem with software is communication. I am not talking about the lack of communication between programmers (nothing can really be done about that since programmers come and go) but about communication between various parts of the software. Microsoft is suffering from a classic case of the "right hand not knowing what the left hand is doing" syndrome.
The problem has to do with what I call blind code and it is not just Microsoft's problem. It is an old problem that has plagued the entire software development industry from the beginning. It is proportional to complexity but it does not have to be. In fact, it can be completely eliminated. The solution requires a rethinking of software construction, not only at the single program level but also at the operating system level. It calls for the reinvention of computing at the fundamental level. We must abandon the algorithmic model of software construction and embrace a signal-based, synchronous model. Eventually, even basic microprocessor architecture will have to be overhauled. For more on this important subject, see the link below.
The reason is that dataflow is really a non-algorithmic, signal-based approach to computing whereas most programming languages and applications are strictly algorithmic. We need to change our way of programming in a radical way before the non-algorithmic model can take off. It's not easy to translate algorithmic code into a dataflow application.
In my opinion, even though TRIPS has 'reliability' in its acronym, unless the execution of parallel code in a given object is synchronous, there is no way it can enforce reliability. To get an idea as to how a signal-based synchronous architecture can enforce software reliability, see the link below.
I'm not sure if we'll be able to pinpoint when a Singularity occured, if one ever does.
I got news for you. The singularity already happened, eons ago, and the universe is the result. If and when our puny mini-singularity happens, it will be crushed like like a toy. You've been warned.
Unless you want to modify the embedded OS, there is no need to hack AIBO anymore. Sony provides an excellent and free software development package that you can use to program AIBO to do anything, including controlling it from another computer (Windows and Unix) via WLAN (802.11b). Here's the URL:
Slashdot Mirror
The problem with data security on an open network is not the lack of adequate technology or know-how because current methods of securing computers do work. Otherwise, our electronic commerce systems would have collapsed years ago. The problem is that hackers look for and often find ways of getting around the security barriers by exploiting defects in the underlying software. A network's security is thus intimately tied to the reliability and robustness of the network's software. Security companies have no way of guaranteeing that the various software modules used in their systems are defect-free. This uncertainty is the Achilles' heel of the security industry. The solution is to move away from algorithmic software and adopt a non-algorithmic, signal-based, synchronous software model.
Hmm... Good point.
Could be that Diebold is hiding some illegal stuff (probably stealing other people's ideas or code) and don't want to be found out. Just a thought. It's obvious that North Carolina is only asking for the source to the stuff that Diebold itself developed, not third parties like Microsoft. The Windows defence is just a lame strawman, IMO.
Mod me down if you wish but I think the CBE architecture is bound to fail. The reason is that you don't design your software model around a new processor. It should be the other way around. You first come up with a software model and then design a processor optimized for the new model. This way you are guaranteed to have a perfect fit. Otherwise, you're asking for trouble.
The primary reason that anybody would want to devise a new software model is to address the single most pressing problem in the computer industry: unreliability. The reason that software is unreliable is that it is based on the algorithm. Switch to a non-algorithmic, signal-based, synchronous model and the problem will disappear. Unfortunately current processor architectures, including the CBE, are optimized for the algorithm. Click on the link below for details on a new software model designed to solve the reliability problem.
Suggestion of Great Britian, possibly. They tend to have their heads screwed on straight. Canada, our 51st state? What would be the difference?
Ah, Great Britain. The country that spies on its people more than almost any other. Just a couple days ago, we learned that the British are going to monitor the movement of every vehicle on the road. Big Brother, if you ask me. Or is it a sign of the beast?
Gates seems to have forgotten the audience in this case
You underestimate the intelligence of the people at Microsoft. They want to create a new market targeted toward a different kind of people, those who would not normally use a supercomputer because of the technical difficulties. It's kind of like the way the GUI opened up computing to a lot of people who found a command line interface daunting, to say the least.
During this 40-minute antenna change, information about the spacecraft's vertical motion was unavailable to ground controllers.
For a country which prides itself as being at the forefront of robotics technology, this is rather surprising. The latency inherent in space communication over great distances is the primary reason for using intelligent robots in space. If the probe was sufficiently intelligent, it would perform its tasks without supervision from ground control. I hope they (including NASA and the ESA) put a lot more effort into automating their space probes in the future.
Global temperatures are extremely tied in to CO2 levels
This could also be written to imply the opposite of what you intended: CO2 levels are extremely tied to global temperatures. How do you tell which caused which?
or, at the very least, the worst case of vaporware ever. Personally, I think it's an unmitigated con game and the principal con artist is none other than David Deutsch of Oxford. One man's opinion.
One more thing: I just put on my flame-retardant suit. So flame away! ahahaha... And don't forget to mod me down too. ahahaha...
Consider how much software is written by people with five years or less of professional experience, on short schedules, with no time allocated for continuing education. If software projects weren't always rush jobs, and on relative shoestring budgets, the quality would be better.
The software reliability crisis has very little to do with greed, engineering incompetence or the lack of big budgets, in my opinion. There is something fundamentally wrong with the way we program our computers, something that no amount of quality control measures can ever cure.
The reason that software is bad has to do with a custom that is as old as the computer: the practice of using the algorithm as the basis for software construction. Switch to a synchronous, signal-based approach and the problem will disappear. Complex algorithmic software is essentially unreliable, something that Fred Brooks has shown in his now famous "No Silver Bullet" paper back in 1987. For an alternative approach to software construction see this article in The Silver Bullet News.
Regardless of what has been said in the past, the problem can be solved. Otherwise, we are in big trouble, very big trouble.
On the maps which show storms' predicted paths, it's much easier if you can write "K" to mark a storm's position rather than "Katrina".
Ah, thanks. Makes sense. Although I think it would probably be just as practical to use numbering scheme. But, not being a cartographer nor a meteorologist, I will defer to the wisdom of the profession. I am sure they are all very smart people who know what they're doing.
Why not put 10,000 names in a hat (or a computer) and just pick one at random? Why does it have to be based on the alphabet? And why do they have to go to the next letter after each storm? I mean, is there an adevantage to this weird naming scheme? Do the storms care?
I'm sick and tired of hearing talk about holding vendors or developers legally responsible for writing insecure code. It's impossible to write any complex application and not have security problems.
Software is unreliable because we have been doing it essentially the same way for 150 years without stopping to think that there might be a better way. We've been writing algorithms ever since Lady Ada Lovelace penned down the first table of intructions for a digital computer. It's time we reevaluate the algorithmic model. Switch to a non-algorithmic, signal-based, synchronous software model and the problem will disappear. Until then, we can't hold either vendors or programmers liable. Didn't Fred Brooks show that algorithmic code is essentially unreliable? See link below for more info on non-algorithmic programming.
Then the music industry joined in with some punches of its own, saying it too will hunt those who share songs online.
It's time that the powers that be recognized that the current IP laws are not only stupid but have become obsolete in the internet age. Certainly, artists and inventors must be compensated for their work and creativity but the IP laws are not the way to do it. The IP laws are being unfairly used by a few to oppress the many, all in the name of greed. The nations of the world should form a fact-finding commission to come up with a different way of compensating IP creators. I think all information should be released freely on the internet (unless the inventor has a way to keep it a secret). A fully funded international body should then determine what sum of money should be allotted to whom based on utility to the public, download data or some other poll mechanism. All nations that use the internet should participate. Inventors and artists would simply publish their stuff on the net, file a claim application with the IP Authority and wait for their checks in the mail. If necessary, as we get more confident in the use of the system, allotments should be made retroactive. Otherwise, I see nations going to war over IP or worse. One man's opinion.
If one really want to cut costs, one should replace employees (especially astronauts) with robots. Oh wait, they got rid of the engineers who were going to make the robots. Never mind.
This is not a well-thought-out feature at all. How is the database supposed to know what data an application *might* access? The database provides all the necessary isolation and notification systems. That's all it can do.
Well, maybe it's not the database's job. Maybe it should be part of the data access layer that connects the database to the applications.
Also, how is the database supposed to notify the application? Would it throw an exception/error/warning/notice the next time you executed some SQL? Would it be a separate API call (in which case, why not just use LISTEN/NOTIFY)? Would it signal your process (thereby killing it if you don't have a handler)?
It makes no difference what the actual mechanism is. In the system that I envision, every dependent app should provide a handler for automatic notification.
And the idea of "resolving" these dependencies would require a huge amount of knowledge that the database has no way of knowing.
I don't think so. It's just a matter of associating write accessors to read accessors of the same record.
Say Application X writes to Tables A, B, and C. Application Y writes to Tables A and D. Under what circumstances would App X need to know that data in Table A had been put there by App Y, or vice versa? How do existing database systems fall short of satisfying such a need?
No. There has to be read access to a shared table in order for a dependency to exist. The reading application is the dependent component.
While true in a general sense, I'm not sure the correct solution to the problem is to add ADDITIONAL complexity the the system.
Complexity is not the cause of failure, IMO. The problem is a lack of timely communication between parts of the system. This is true both at the system or network and the program level. Oftentimes, a variable is modified by one part of the program unbeknownst to some other part which may crucially depend on the state of the variable. Only a non-algorithmic, signal-based approach to software construction can solve this problem.
Don't be silly. PostgreSQL has had this feature for ages (atleast since 7.x days) implemented via NOTIFY, which interested listeners can register to be notified of.
Thank you. But that is not what I meant. There should be a software mechanism that automatically identifies dependencies and resolves them. Leaving it to the programmer does not solve the problem because programmers come and go and may not be aware of old dependencies. The problem is especially annoying in legacy systems. Modifications made to a complex system can have unforeseen consequences if programmers are not aware of the dependencies.
MySQL has finally caught up to the state of the enterprise relational database industry
One of the things that is missing in most if not all databases (AFAIK) is an effective mechanism to deal with data dependencies. A data dependency exists whenever two or more applications of components share read/write access to the same records in a database. We need a simple to use mechanism that will notify relevant applications of changes in a shared record. Resolving dependencies in a timely manner is extremely important to system or network reliability. Data dependency problems also exist within applications but that's a slightly different issue, one which is made all the more hard to deal with by the algorithmic nature of software.
The problem of software failures has very little to do with the competence of developers, IMO. Sure we can make software very reliable given enough time and resources. But we don't have that. In our modern society where everything depends on software, we cannot wait forever for the software to be bugless. Avionics and other safety-critical applications are extremely expensive precisely because of this. The problem has to do with our current software construction methodology. No amount of software metrics can guarantee the full reliability of complex algorithmic software.
The problem is not complexity but the algorithmic nature of software. Switch to a signal-based synchronous model and the problem will disappear (see link below). We can hold developers legally liable only if a method is found to guarantee reliability. We hold other engineering disciplines liable only because they have known ways to ensure safety. When it comes to mission-critical applications, very high reliability is not good enough. Only 100% reliability will do. The proper role of quality control is to ensure complete reliability. This is impossible with our current software construction model. There is a solution, however. If only we could wake up and realize that the algorithmic model is hopelessly flawed. We must reinvent computing at the fundamental level. EEventually, even processor architecture will have to be overhauled. Afterwards, software developers will have no excuse.
He doesn't seem to think that writing poor code is entirely the fault of coders though: he blames the education system.
To hold programmers responsible for software failures is downright irresponsible. Programs are not bridges. Whereas bridge engineers can use known procedures and practices to ensure bridge safety, the same is not true of software engineers. It is impossible to guarantee the reliability of complex algorithmic software. This much has been shown by Frederic Brooks. But, regardless of what Brooks claimed in his famous No Silver Bullet paper, the reason has nothing to do with complexity (there are many good examples of reliable yet highly complex systems in nature), but with the algorithmic nature of our software. Switch to a non-algorithmic, signal-based synchronous model and the problem will disappear. See the link below for more on this important subject.
The problem is as old as Lady Ada Lovelace who wrote the first algorithmic code more than 150 years ago. We've been writing algorithmic programs ever since and the ensuing unreliability problem has turned to a major crisis. The problem is not software. The problem is algorithmic software. Switch to a non-algorithmic, signal-based, synchronous model and the problem will disappear.
Bug free software is possible, so long as it is done right and people are prepared to pay for it.
It is impossible to guarantee the reliability of complex algorithmic software. This is something that Frederick P. Brooks has shown in his famous "No Silver Bullet" paper. However, Brooks' arguments fall apart in one important area. Although Brooks' conclusion is correct as far as the unreliability of complex algorithmic software is concerned, it is correct for the wrong reason. Software programs are unreliable not because they are complex (Brooks' conclusion), but because they are algorithmic in nature.
Last week, an article in the Wall Street Journal's OnLine Edition gave a vivid description of the costly software reliability problems that Microsoft has had to endure in its effort to develop the next version of its Windows operating system. It drove home a point that I have repeatedly made in the past. The biggest problem with software is communication. I am not talking about the lack of communication between programmers (nothing can really be done about that since programmers come and go) but about communication between various parts of the software. Microsoft is suffering from a classic case of the "right hand not knowing what the left hand is doing" syndrome.
The problem has to do with what I call blind code and it is not just Microsoft's problem. It is an old problem that has plagued the entire software development industry from the beginning. It is proportional to complexity but it does not have to be. In fact, it can be completely eliminated. The solution requires a rethinking of software construction, not only at the single program level but also at the operating system level. It calls for the reinvention of computing at the fundamental level. We must abandon the algorithmic model of software construction and embrace a signal-based, synchronous model. Eventually, even basic microprocessor architecture will have to be overhauled. For more on this important subject, see the link below.
So why aren't dataflow machines mainstream?
The reason is that dataflow is really a non-algorithmic, signal-based approach to computing whereas most programming languages and applications are strictly algorithmic. We need to change our way of programming in a radical way before the non-algorithmic model can take off. It's not easy to translate algorithmic code into a dataflow application.
In my opinion, even though TRIPS has 'reliability' in its acronym, unless the execution of parallel code in a given object is synchronous, there is no way it can enforce reliability. To get an idea as to how a signal-based synchronous architecture can enforce software reliability, see the link below.
I'm not sure if we'll be able to pinpoint when a Singularity occured, if one ever does.
I got news for you. The singularity already happened, eons ago, and the universe is the result. If and when our puny mini-singularity happens, it will be crushed like like a toy. You've been warned.
Unless you want to modify the embedded OS, there is no need to hack AIBO anymore. Sony provides an excellent and free software development package that you can use to program AIBO to do anything, including controlling it from another computer (Windows and Unix) via WLAN (802.11b). Here's the URL:
http://openr.aibo.com/openr/eng/index.php4/