From: Jim Choate <ravage@ssz.com>
Date: Sun, 20 Jul 1997 23:11:10 +0800
To: cypherpunks@ssz.com (Cypherpunks Distributed Remailer)
Subject: Re: Will Monolithic Apps Dominate? (fwd)
Message-ID: <199707201456.JAA08917@einstein.ssz.com>
MIME-Version: 1.0
Content-Type: text



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      |
   |____________________________________________________________________|