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."
participants (3)
-
Jim Choate -
Robert Hettinga -
Tim May