by yew21 » Jul 9th, '21, 07:02
Here are latest from Dr. Joe on ROBACUS aka ROBOCOM :-
We have already created a pilot software automation platform named ROBACUS, short for robotic abacus. You see, abacus is used solely for computing, unlike today’s hand phone and PC that have managed not to do any serious computing.
Such a platform requires an environment whose infrastructure consisted of a centralized supercomputing center, surrounded by the massive remote users, supported by a team of software automation developers and user support consultants, working out of the center’s supercomputer.
The following three major tasks are needed to achieve a full-blown software automation project:
1. Porting ROBACUS to the supercomputer center.
2. Training a team of software automation developers.
3. Educating students to become users of ROBACUS.
To responsibly close this presentation, we need to answer the one big question that should concern most readers. That is: “How is that this software is made public?”
The answer lies in the phenomenon observed in the preliminary testing of a pilot project, conducted jointly by University of California, Berkeley (UCB) and the Boeing Computer Services from 1980 to 1990, mostly in the licensing process of the damaged Three Mile Island Nuclear Plant’s reactor and the design of the space reactors for STAR WAR at General Electric Company and the Jupitor exploration for Lockheed Martin.
Boeing provided the centralized supercomputer CRAY. University of California had trained a team of software automation engineers for the support of nuclear engineers burdened with the licensing analyses required to recover the Three Mile Island plant to normal operation.
These two components of the project have their respective roles well defined. But the third component, involving the support of remote user group surprised us all in how they contributed to the development of automated, that is, public, software.
Basically, all the tasks were initially defined by the surrounding client users. And the kind of application software that were needed to solve the problems are obtained from code centers from national labs.
However, nuclear industry is a high-cash flow business. Thus, the demand for early response become a thing of highest priority, which so happen to fit like a glove to our talented team of software automation engineers from Berkeley.
But never did we realized that our remote users could turn out to be such a chaotic bunch that could only to be reconciled with ever drastic measures. They essentially compelled us to automate everything, reinforced by software robots that could backup our honest work, and to keep in line of their digressions and mischiefs.
But when the dust finally settled, we found out this hectic high-tech brawl turned out to be the most effective way for software development.
On realizing that, the support group decided to write automated interactive software for users’ own self-service. The surrounding users’ knowledge now can be spontaneously and systematically transformed into automated software. At the end, the users got their jobs done, but were never aware that they were also the nameless authors in a large compilation of software.
The resultant owner-less software have no place to go but into the public domain. And, in our formal launching of this automation project, a scaled up of the same phenomenon will be replicated. This time, the mass public will be made to participate in the transformation of all their knowledge, as well as all the existing non-automated software, to such automated public software.
Please comment and suggest on my proposal.