Re: Will Monolithic Apps Dominate? (fwd)

Forwarded message:

> Date: Sun, 20 Jul 1997 08:03:09 -0400
> From: Robert Hettinga <rah@shipwright.com>
> Subject: Re: Will Monolithic Apps Dominate?

> I'm beginning to think that until it's possible for a given processor to
> autonomously buy the software it needs for cash in an auction market, and
> then download and install that software, all at run time, the
> superscalibility of an environment where software is dispersed through the
> network (again, "surfacted" is not a bad word to describe this), and run in
> the smallest possible bits at the processor level just won't happen.
> 
> Nonetheless, I do think that the linux gang is going in the right
> direction, especially since most most of the cash-settlement technology we
> on this list have all come to know and love is more likely to be used in
> linux than anywhere else.

You should look into Plan 9 with purchasing extensions to its job-processor
scheduling scheme. This would allow several interesting features:

 -   anonymous execution of jobs

     The person scheduling the job would have no idea exactly where the
     job was running, only that it was at the time the least expensive
     alternative available.

 -   anonymous processor selection

     The person owning the machine would not know where all the processes
     currently running come from since it would not be possible to turn
     the execution key into an actual machine address.

 -   automatic and anonymous software selection

     Jobs don't need to have the required software or even where it might
     be located. The job would need to understand the catalog scheme in
     place to locate the software (think of a library card system).

Since the OS already bids for processor space it would not require a
major architecture mod to include E$/crypto functions.

> Finally, there's the issue of Mhyrvold's software-as-a-gas idea. That is,
> that bloatware is a direct result of Moore's Law.

I have to disagree. Bloatware comes from the way we look at software
(ie generalize & modularize it) and the way we impliment it (ie libraries).
While it makes the programmers job easier it makes the amount of software
required for the job larger that required because the libraries have
functions and features that aren't used (in this product). Bloatware won't
be fixed unless we (ugh) go back to monolithic project design with most
code custom built with little re-use from previous versions. I suspect it is
easier to buy another 4M of RAM than to pay the programmers to re-create the
wheel each time a new version comes out.

    ____________________________________________________________________
   |                                                                    | 
   |            _____                             The Armadillo Group   |
   |         ,::////;::-.                           Austin, Tx. USA     |
   |        /:'///// ``::>/|/                     http:// www.ssz.com/  |
   |      .',  ||||    `/( e\                                           |
   |  -====~~mm-'`-```-mm --'-                         Jim Choate       |
   |                                                 ravage@ssz.com     |
   |                                                  512-451-7087      |
   |____________________________________________________________________|

At 10:56 am -0400 on 7/20/97, Jim Choate wrote:


> You should look into Plan 9

<snip>

> Since the OS already bids for processor space it would not require a
> major architecture mod to include E$/crypto functions.

Yeah. I've seen demos of what I think was plan 9, actually it's
successor(?). Both of them were Bell (now Lucent) efforts, right?

Certainly, it looks like it was a step in the right direction, if it works
as advertised.


>
> > Finally, there's the issue of Mhyrvold's software-as-a-gas idea. That is,
> > that bloatware is a direct result of Moore's Law.
>
> I have to disagree. Bloatware comes from the way we look at software
> (ie generalize & modularize it) and the way we impliment it (ie libraries).
> While it makes the programmers job easier it makes the amount of software
> required for the job larger that required because the libraries have
> functions and features that aren't used (in this product). Bloatware won't
> be fixed unless we (ugh) go back to monolithic project design with most
> code custom built with little re-use from previous versions. I suspect it is
> easier to buy another 4M of RAM than to pay the programmers to re-create the
> wheel each time a new version comes out.

No, but I bet that if there was a profit-loss feedback loop at the lowest
possible level of the, what?, solution (do we call a group of autonomous
cooperating bits of code an application?) then, at some point in the
development of a cash settlement mechanism, the benefits of efficiency
would far outweigh the extra cost of cash handling.

The idea of micromoney as processor food, I think, gets us a way to pay for
the adaptive evolution with the same, or better, results than we'd get by
top-down monolithic project design.

Cheers,
Bob Hettinga

-----------------
Robert Hettinga (rah@shipwright.com), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
The e$ Home Page: http://www.shipwright.com/

At 11:58 AM -0700 7/20/97, Robert Hettinga wrote:

>The idea of micromoney as processor food, I think, gets us a way to pay for
>the adaptive evolution with the same, or better, results than we'd get by
>top-down monolithic project design.
>

A husband-wife programming team just spent the last day or so at my place,
filling me in on their recent successes with their "agent-oriented
database" for financial trading. Unlike a lot of the hype about agents, in
books and in press releases, they've used their system for data mining of
financials, and have made a _lot_ of money with it. (They are not the folks
at The Prediction Company, in case anyone is wondering. Nor are they the
D.E. Shaw group. I can't say more right now, as the stakes and pool they
are running are up in the $10M range, and they hope/expect this to soon get
a lot larger. This could turn out to be one of the seminal applications of
this set of interrelated ideas.)

Bidding of agents is an important part of this approach. (Allocation of
resources, "putting their money where their mouth is," genetic programming,
evolutionary learning, data mining, neural nets, and all the other major
buzzwords. Their agents are somewhat "agnostic" about any particular
approach and they "use it if it works, otherwise kill it." The Koza-style
genetic programming top layer then makes use of the various buzzword
paradigms at lower levels, e.g., using time-series analysis for parts,
neural nets for other parts, forward-propagation for other parts, etc.)

The "agoric computation" work of Miller, Drexler, Tribble, Huberman and
others is relevant. (Huberman edited a book, circa 1987-8, "The Ecology of
Computation," which contains several of the important papers. The Miller
and Drexler papers are the ones to focus on.)

The "Digital Silk Road" work of our own Norm Hardy (and either Dean Tribble
or Mark Miller, I forget which right now) is highly relevant.

Some of this work is already being used to "market allocate" CPU cycles in
distributed systems. Sort of analogous to the "distributed crack" work
(except the distributed crack work is a winner take all approach, not
counting the confused situation with the DESCHALL crack recently). In
computational models where the prize is not so obvious, as in most routine
calculations in business, a market allocation model better uses
computational resources.

Selling spare CPU cycles is another related idea. Several Cypherpunks have
ideas along these lines.

Coincidentally, my last major project for Intel involved developing a
scheme for better automating and streamlining wafer production by having
wafer "runs" (manufacturing lots) bid for access to scarce resources. I
think I was strongly influenced by thinking about how wafer runs could be
seen as "objects" carring their own local state--the complicated time
history of the treatments they had received in the fabs, and test results,
etc.--and how traditional wafer lot tracking systems failed to
intelligently use any of this information. This "Frame-Based Manufacturing
System," using the work on frames with slots contained triggered methods
(daemons), would have essentially put an economic, agoric layer on what is
now mostly a human-run bureaucratic layer. (With various departments and
groups clamoring for access to equipment, rather than an auction approach.)

My environment at that time was a Symbolics 3670 LISP machine, with a user
interface/GUI of unparalleled elegance and power. And KEE, the Knowledge
Enngineering Environment, from Intellicorp.

I left Intel in '86, and the project limped along for another couple of
years. Miller and Drexler visited my group in '87, after I was gone, and
the work on using auction methods in wafer fabs entered into their
thinking, as they later told me.

(Intel did not deploy my vision. I can guess some of the reasons. Last I
heard, they're still struggling to adapt conventional relational data bases
for tracking wafer runs, but are not integrating in the vast amounts of
(expensive) knowledge in any meaningful way.)

These ideas are all part of a larger mosaic (TM, the Netscape Corporation)
of ideas involving collective computation, intelligent agents,
object-oriented data bases, "seas of objects" (a la Gelernter's "Linda"
system), auction markets, price discovery, and AI in general.

It's sad that so much of Cypherpunks coding has, perforce, been "stalled"
at the level of implementing mundane ciphers and showing weaknesses in
ciphers known 20 years ago to be weak.

The really neat stuff is taking a long time to percolate out.

--Tim May






There's something wrong when I'm a felon under an increasing number of laws.
Only one response to the key grabbers is warranted: "Death to Tyrants!"
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^1398269     | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."