December 2003 - cypherpunks-legacy

Re: noiz-0.5: simple noise-emitting package
by Matt Blaze 17 Dec '03

17 Dec '03

This looks really cute, especially given the ability to "precompute" entropy before the process that needs it is running. An interface I'd rather see is one that allows a process to grab random bits that it can be sure are not correlated to bits that have been given to other processes. Since everything runs asynchronously with cron, you have no way of knowing how much time has elapsed since the last time the file was read or updated, and hence don't know how "fresh" the bits are. Also, /etc/noiz is an attractive target on multi-user machines.... So I'd rather see a /dev/noise, although a portable implementation of somthing like that is out of the question now that there are 10 gazillion unix vendors. Perhaps a more reasonable implementation would be a tcp or rpc service that processes can query to get random bits, where the server delays responding until it can guarantee that its state is sufficiently decorrelated from previous responses. Because you can "bank up" entropy during idle periods, most requests could probably be served without delay, making this technique a real advantage over just implementing the same functions in a library called directly. (Since good randomness is still rather expensive even when you can store it up, and useless when sent over a network, you'd probably want the noise server to refuse requests from outside the local machine.) Anyway, I'm looking forward to playing with it. It's a very nice idea. -matt

1 0

!NYC Cypherpunks meeting 2/11/95!
by Arsen Ray Arachelian 17 Dec '03

17 Dec '03

Incase you're in the NYC area, there is a meeting this Saturday. (If you're already on the list of NYC Cypherpunks, you'd have received the notice with the address.) If you're in NYC, but not on the NYC Cypherpunks list, and you need info, please send email to me, rarachel(a)photon.poly.edu, and I'll give you directions. See you there.. --Ray. =============================================================================== | + ^ + || ' . . . . . . . Ray (Arsen) Arachelian || | \|/ || . . . ' . ' . : . . rarachel(a)photon.poly.edu || |<--+-->||. . . |' '| .' . . ... ___ sunder(a)intercom.com || | /|\ || . . \___/ . . . : .... __[R] || | + v + || . oOOo /o.O\ oOOo :. : .. |A| "And bugs to kill before I sleep"|| =========/---vvvv-------VVVV------------|I|----------------------------------/ / . : . ' : ' |D| This signature pannel is / / The Next Bug to kill(tm) --- now open. / /___________________________________________________________________/ GCS d++(---)(-) H s+++/++ !g !p !au a- w-(+) (!v | v) C+++++ Coherent++++ L+ 3 C+ V+ P? E- N++ K- W W--- M++ V-- po- Y+++ t:[tos+, tng--, ds9+] 5 !j !R G? tv+ b+++ D+ B--- e+(- | *) u--- h+++ f+(++) r++ n+(---) x**(++)

1 0

Fwd: Seals and Sealing Waxes
by Alan Pugh 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Date: Tue Feb 07, 1995 10:15 PM EST To: cypherpunks(a)toad.com Subject: Fwd: Seals and Sealing Waxes Message-Id: TM> "All crypto is economics," and this is what made seals and sealing wax so TM> useful for so long. Saying "seals were duplicatable from the start" does TM> not mean this feat was easy, even if technically possible. TM> In fact, the fine details produced by a good seal are hard to exactly TM> emulate with a copy. Even on a two-dimensional surface. And with the advent TM> of three-dimensional surfaces, which sealing wax made possible, the fine TM> detail of a good seal was in fact very hard to forge. TM> Not impossible, but very costly with the technology of the day. Or even the TM> technology of _today_. After all, paper currency is largely based on seal TM> technology, with various embossing, printing, etc. methods used (on special TM> paper) that remain fairly hard to duplicate. true. thanks for the reminder of seals. i need to work this analogy into my current 'lecture' on the usefullness of encryption. _puzzle palace_ makes reference to british intellegence making use of people trained into the use of people trained to reproduce seals. this is something for us to look out for from the fine folx at nsa. if there is a way to spoof signatures (as mentioned in another thread recently), they will be perfecting and perhaps using these methods if they feel the need is great enough. i promote encryption using pgp with a lot of stress on the privacy and veracity of documents in business settings. how strong is the hash used by pgp? do you think it will eventually be hashed out in the courts in our favour?(pun semi-intended) i'd like digital signatures w/verifiable timestamps be recognised in a court of law. i don't know of any cases revolving around this issue. if anyone out there knows of one, i'd be interested in hearing of it so i can track it's progress. btw: though it is a pain sometimes to weed the noise off this list due to my (very) limited net access, it has proved to be an excellent resource. my thanks to the regulars. - --if i could code worth a damn i'd be a cypherpunk amp <0003701548(a)mcimail.com> February 7, 1995 22:17 -----BEGIN PGP SIGNATURE----- Version: 2.61 iQEVAwUBLzgN4CgP1O9KJoPBAQETZQf/WAY0I+fvEmevc7iwfVglqjIZ26zDnc33 p8Yjc+uQfagS0wavYLpN+OxMphpdUHHjycb98aYLDax8CUW3iDJ54tZKVnQT3pPx 9+v1gq38UbP8k7hvoGl5lIltmMJ/rMl2lZU87l2biYjmQq8n9S+mMoIOAatcmboG 6JQ4MEsNnZvsQVeaZm87qOGqfkeTbzwsBfz8LjLkgnv7TLUNn5wJgMgiC+apYC0V bJfAHWce3UGEPlaa4JHBbCRyfrC/hk1ggrYKthxHKE+Ceep1O2k7fRkX/tCC2BZC UaY8ZjogZKZJbfdDNmlG7fBN5EBWlj6Mj9Ti2SRYlx4q8lwSHad+gg== =HeNj -----END PGP SIGNATURE-----

1 0

Re: "encrypt tcp connections" hacks
by Chris Claborne 17 Dec '03

17 Dec '03

>> Thats because the providers never package things up cleanly. If they >> sent a client on a disk, a la AOL, and they set things up to >> autoconfigure, they'd never need to speak to the clients. > > You've obviously never attempted to get a Windows product working for >someone whose previous experience with a computer is limited to "Solitaire". > > I've done work with this ISP, and I can tell you it's nearly the most >frustrating experience I've had in my life -- Windows has bizzare >conflicts with software eating other software, ports getting set up >wrong, and just general nastiness. Even the slickest software needs >helpline time - for whatever reason. I hate jumping in when I may be completely off base but... NT and (possibly Winodws97) may solve some of this, mainly through better controll over devices and protected memory. I recently installed some NT services, HTTP server, and Time Service (to get time off a trusted host). The HTTP server was installed and working in 5 minutes. I'm a little more advanced than the typical "Solitare junky", but I was amazed at the ease of install and controll that some of this stuff gives you. I would probably spend atleast 30+ minutes trying to get them properly installed on my UNIX host. ... __o .. `\<, Chris.Claborne@SanDiegoCA.ATTGIS.COM...(_)/(_). CI$: 76340.2422 --------------------------------------------------------------------------- PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Available on any Pub Key server. PGP encrypted mail welcome.

1 0

a new way to do anonymity
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A week ago I made a suggestion for a new protocol for untracibility, but only got one response. I'll try again, this time more forcefully. I'm not trying to convince anyone to implement this (though of course you're welcome to!), but just to think about it and give me feedback. Why is another protocol needed? Right now we have only two, each of which has its own set of tradeoffs. To summarize: Mix-Net (i.e., remailer-net): high latency, moderate bandwidth costs, and low complexity DC-Net: moderate latency, high bandwidth costs, and high complexity While the DC-Net will probably never be widely used, the remailer-net has a fair chance of one day providing a way for many people to send e-mail that not even governments can trace. However, I don't think this is enough. Efficient social and business relationships require that people be able to converse to each other in real time. Cryptoanarchy will not come about if people cannot do this anonymously. How well can two pseudonymous agents negotiate a contract if each message they send must be delayed several hours? The protocol I sugguested would have low latency, moderate bandwidth costs, and moderate complexity. It would be well suited for people to interact anonymously in a textual environment. This is what I wrote: > Imagine a server that allows you to open a > low bandwidth (let's say around 100 cps, in order to reduce costs) > link-encrypted telnet session with it, and provides you with a number > of services, for example a link-encrypted talk session with another > user. You'll need to maintain the link 24 hours a day to defend > against statistical analysis, and of course you can chain a number of > these servers together in a way similiar to chaining remailers. Lance pointed out the chain cannot be built quickly. This is not a problem if servers connect to each other with relatively wide link-encrypted pipes and multiplex your connection into these pipes. In this system, latency would never be more than a few seconds, bandwidth cost is N*100 cps (point to point), N being the number of links in your chain. Implementation would probably be harder than remailers, but much easier than DC-Nets. The protocol would also provide both sender and receiver untracibility without any need for broadcasting. Wei Dai P.S. I never gave a name for the protocol... let's call it Pipe-net. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzgewDl0sXKgdnV5AQGzvAQAgFaOxOzFPgS031z4jZRYUJp/+3BS5Con Kza7WsvZPvxzaNLh9ecD3aCx5dtf4muaiUKjC2HIItaLKEdZZPdzUGFd4wg1cY8G k8mvYNzDImr3ZtQ0HiqQ59PWhznad0GuhjQajB7RtpI+K/Z4uBaUEZGVoZZT+LHN MSjOl/k/yfg= =jgq6 -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai(a)eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> singularity --> atoms --> macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> homo sapiens --> digital computers --> internetworking --> close-coupled automation --> broadband brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ?

2 1

Effects of S.314 (Communications Decency Act)
by skaplin＠mirage.skypoint.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I just had an interesting conversation with a person who works for an ISP. Basically their response if S.314 becomes law will be to preprocess all incoming mail. If it is uuencoded or encrypted, into the bit bucket it will go. They are still thinking about what to do with telnet and ftp. This is starting to get very scary. Sam - -- ============================================================================== skaplin(a)skypoint.com | Finger skaplin(a)infinity.c2.org for | a listing of crypto related files PGP encrypted mail is accepted and | available on my auto-responder. preferred. | (Yes...the faqs are there!) | Finger skaplin(a)mirage.skypoint.com for | "...vidi vici veni" - Overheard PGP public key. | outside a Roman brothel. | Fax Number +1 (612) 928-9771 | An UZI beats five aces every time... ============================================================================== Be careful when playing under the anvil tree. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLzgMJ8lnXxBRSgfNAQG3Egf9HewkJYboCW6RNABZiQd8K8JVyw3As0S7 Gwno4Flp3L1y/izbCSgVnrNY+oK7vwB5J0OPq4y1TX7gIb/NPasVKkcW9eET1a5X HJwjbfg7ZbUle5dcktuD1GLC1bZu5Mt39lV8eQKjqHiXYSxc3sWJT3xvtKQ45Pr+ FWsYNALI6Q9R7sBy0Zh0vg61fZHfnlSNi7SxEvE0GZ3e959L0y+AR44UE2HrI1KQ zfDgFtWiQsDztbVsbReYb4cwCs34Vxv/7v7GjY29SVZIKbeR1aEarR2TJbuT/jry dP+l4QIxOFv26OIGf5cHgPiWswf1KjosUkDso0Ps8fKf3Wafm5CH2g== =0WR8 -----END PGP SIGNATURE-----

10 16

Full text of S. 314
by Samuel Kaplin 17 Dec '03

17 Dec '03

2 2

noiz ... and more SKRONK
by strick＠techwood.org 17 Dec '03

17 Dec '03

MAB: > Also, /etc/noiz is an attractive target > on multi-user machines.... Right. But you notice I made it mode 660, owner root, group kmem, to parallel the /dev/*mem devices. You have the same vulnerabilities as always on a multi-user system, even if you put /dev/noise in the kernel or run a TCP daemon. Another parallel is the randseed.bin file in PGP. >From an information theory point of view, I don't know how to describe the kind of shared-entropy that this pool exhibits. Making the source of the entropy hidden to the users by crunching on the way out with MD5 adds something to the data -- it's not true entropy, but it's some kind of effective entropy, from the point of view of the users. Unless MD5 has weaknesses that I assume it doesn't, it's not really possible for users to know where their spaces of possible random values overlap, so they don't know how to exploit it. A final note -- I should have put /etc/noiz somewhere in the /var filesystem. Perhaps /var/adm/noiz. But one can edit the Makefile to do that, and no other software has to actually know where it is, since its access is totally encapsulated by noizinit, noizstir, and noizout. The location of these in /usr/local/bin/ is what needs to be standardized, so I hope that's good enough for most users. ------- Oh, I meant to thank everyone for the great discussion and constructive criticism of SKRONK and "encrypt tcp connections" hacks. Especially Perry -- your enumeration of projects was good. Based on that, and what I know of the others, the priority of protocols I'd like to support with skronk are 0. my own hack, to get it going 1. Matt's ESM 2. Kerberized connections (kerb4 or kerb5 or both?) 3. Perhaps the SSL from Netscape Thus SKRONK becomes what I wanted it to be: a way for sites to advertize the availability of enhanced services (via the skronk map UDP daemon) and a way to painlessly integrate crypto with existing code. (The last aspect always draws user interface problems -- if it's so transparent, how do you know if you're encrypted? Right now I have the client end scribble to stderr when it skronks.) strick

1 0

URGENT - What S.314 Would Do
by slowdog＠wookie.net 17 Dec '03

17 Dec '03

[ Article crossposted from comp.org.cpsr.talk,comp.org.cpsr.talk,misc.legal.comp ] [ Author was slowdog (slowdog(a)wookie.net) ] [ Posted on 7 Feb 1995 14:56:15 GMT ] The following is what Senator Exon's bill (S.314) would do to the Communicatons Act of 1934. The text in [brackets] is what is being deleted or changed. What exists as plain text outside those brackets is how the new law will look. Read carefully. There are indeed implications for Internet service providers in terms of their responsibility under the law for the content of their systems and services. ------------------------------------------------------------------- 47 USC Sec. 223 TITLE 47 CHAPTER 5 SUBCHAPTER II Sec. 223. [Obscene or harassing telephone calls in the District of Columbia or in interstate or foreign communications] Obscene or harassing utilization of telecommunications devices and facilities in the District of Columbia or in interstate or foreign communications (a) Prohibited acts generally Whoever - (1) in the District of Columbia or in interstate or foreign communication by means of [telephone] telecommunications device - (A) [makes any comment, request, suggestion or proposal] makes, transmits, or otherwise makes available any comment, request, suggestions, proposal, image, or other communication] which is obscene, lewd, lascivious, filthy, or indecent; (B) [makes a telephone call, whether or not conversation ensues, without disclosing his identity and with intent to annoy, abuse, threaten, or harass any person at the called number] makes a telephone call or utilizes a telecommunications device, whether or not conversation or communications ensues, without disclosing his identity with intent to annoy, abuse, threaten, or harass any person at the called number or who receives the communication; (C) makes or causes the telephone of another repeatedly or continuously to ring, with intent to harass any person at the called number; or (D) [makes repeated telephone calls, during which conversation ensues, solely to harass any person at the called number; or] makes repeated telephone calls or repeatedly initiates communication with a telecommunications device, during which comversation or communication ensues, solely to harass any person at the called number of who receives the communication; or (2) knowingly permits any [telephone] telecommunications facility under his control to be used for any purpose prohibited by this section, shall be fined not more than [$50,000] $100,000 or imprisoned not more than [six months] 2 years, or both. (b) Prohibited acts for commercial purposes; defense to prosecution (1) Whoever knowingly - (A) within the United States, by means of [telephone], telecommunications device makes (directly or by recording device) any obscene communication for commercial purposes to any person, regardless of whether the maker of such communication [placed the call] placed the call or initiated the conversation; or (B) permits any [telephone] telecommunications facility under such person's control to be used for an activity prohibited by subparagraph (A), shall be fined in accordance with title 18 or imprisoned not more than two years, or both. (2) Whoever knowingly - (A) within the United States, [by means of telephone, makes] by means of telecommunications device, makes, knowingly transmits, or knowingly makes available (directly or by recording device) any indecent communication for commercial purposes which is available to any person under 18 years of age or to any other person without that person's consent, regardless of whether the maker of such communication [placed the call] placed the call or initiated the communication; or (B) permits any [telephone] telecommunications facility under such person's control to be used for an activity prohibited by subparagraph (A), shall be fined not more than [$50,000] $100,000 or imprisoned not more than [six months] 2 years, or both. (3) It is a defense to prosecution under paragraph (2) of this subsection that the defendant restrict access to the prohibited communication to persons 18 years of age or older in accordance with subsection (c) of this section and with such procedures as the Commission may prescribe by regulation. (4) In addition to the penalties under paragraph (1), whoever, within the United States, intentionally violates paragraph (1) or (2) shall be subject to a fine of not more than [$50,000] $100,000 for each violation. For purposes of this paragraph, each day of violation shall constitute a separate violation. (5)(A) In addition to the penalties under paragraphs (1), (2), and (5), whoever, within the United States, violates paragraph (1) or (2) shall be subject to a civil fine of not more than [$50,000] $100,000 for each violation. For purposes of this paragraph, each day of violation shall constitute a separate violation. (B) A fine under this paragraph may be assessed either - (i) by a court, pursuant to civil action by the Commission or any attorney employed by the Commission who is designated by the Commission for such purposes, or (ii) by the Commission after appropriate administrative proceedings. (6) The Attorney General may bring a suit in the appropriate district court of the United States to enjoin any act or practice which violates paragraph (1) or (2). An injunction may be granted in accordance with the Federal Rules of Civil Procedure. (c) Restriction on access to subscribers by common carriers; judicial remedies respecting restrictions (1) A common carrier within the District of Columbia or within any State, or in interstate or foreign commerce, shall not, to the extent technically feasible, provide access to a communication specified in subsection (b) of this section from the [telephone] telecommunications device of any subscriber who has not previously requested in writing the carrier to provide access to such communication if the carrier collects from subscribers an identifiable charge for such communication that the carrier remits, in whole or in part, to the provider of such communication. (2) Except as provided in paragraph (3), no cause of action may be brought in any court or administrative agency against any common carrier, or any of its affiliates, including their officers, directors, employees, agents, or authorized representatives on account of - (A) any action which the carrier demonstrates was taken in good faith to restrict access pursuant to paragraph (1) of this subsection; or (B) any access permitted - (i) in good faith reliance upon the lack of any representation by a provider of communications that communications provided by that provider are communications specified in subsection (b) of this section, or (ii) because a specific representation by the provider did not allow the carrier, acting in good faith, a sufficient period to restrict access to restrict access to communications described in subsection (b) of this section. (3) Notwithstanding paragraph (2) of this subsection, a provider of communications services to which subscribers are denied access pursuant to paragraph (1) of this subsection may bring an action for a declaratory judgment or similar action in a court. Any such action shall be limited to the question of whether the communications which the provider seeks to provide fall within the category of communications to which the carrier will provide access only to subscribers who have previously requested such access.

3 2

The Rise of "Worse is Better"...
by stig＠hackvan.com 17 Dec '03

17 Dec '03

A while ago, I mentioned appendix C to the _Unix-Haters Handbook_ and someone (Jason?) was interested in it. I couldn't come up with the text of the chapter until now because I didn't have it until now. Look through the Lisp-specific jargon to see what RPG (the author) has to say about the differrent priorities in getting a job done... One school of engineering follows "The Right Thing" approach, while the other uses the "Worse is Better" (quick-and-dirty) approach. Stig I have the .tex file for the article, and it's available on the WWW as http://www.ai.mit.edu/articles/good-news/good-news.html ----------------------------------------------------------------------------- [Image] [Image] [Image] Previous: Lisp's Apparent Failures Up: Lisp's Apparent Failures Next: Good Lisp Programming is Hard The Rise of ``Worse is Better'' I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right: Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation. Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed. Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness. Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness. I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach.'' Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation. The worse-is-better philosophy is only slightly different: Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct. Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface. Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach. However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach. Let me start out by retelling a story that shows that the MIT/New-Jersey distinction is valid and that proponents of each philosophy actually believe their philosophy is better. Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called ``PC loser-ing'' because the PC is being coerced into ``loser mode,'' where ``loser'' is the affectionate name for ``user'' at MIT. The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing. The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix-namely, implementation simplicity was more important than interface simplicity. The MIT guy then muttered that sometimes it takes a tough man to make a tender chicken, but the New Jersey guy didn't understand (I'm not sure I do either). Now I want to argue that worse-is-better is better. C is a programming language designed for writing Unix, and it was designed using the New Jersey approach. C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%--80% of what you want from an operating system and programming language. Half the computers that exist at any point are worse than median (smaller or slower). Unix and C work fine on them. The worse-is-better philosophy means that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven't they? Unix and C are the ultimate computer viruses. A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus. It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better. The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++. There is a final benefit to worse-is-better. Because a New Jersey language and system are not really powerful enough to build complex monolithic software, large systems must be designed to reuse components. Therefore, a tradition of integration springs up. How does the right thing stack up? There are two basic scenarios: the ``big complex system scenario'' and the ``diamond-like jewel'' scenario. The ``big complex system'' scenario goes like this: First, the right thing needs to be designed. Then its implementation needs to be designed. Finally it is implemented. Because it is the right thing, it has nearly 100% of desired functionality, and implementation simplicity was never a concern so it takes a long time to implement. It is large and complex. It requires complex tools to use properly. The last 20% takes 80% of the effort, and so the right thing takes a long time to get out, and it only runs satisfactorily on the most sophisticated hardware. The ``diamond-like jewel'' scenario goes like this: The right thing takes forever to design, but it is quite small at every point along the way. To implement it to run fast is either impossible or beyond the capabilities of most implementors. The two scenarios correspond to Common Lisp and Scheme. The first scenario is also the scenario for classic artificial intelligence software. The right thing is frequently a monolithic piece of software, but for no reason other than that the right thing is often designed monolithically. That is, this characteristic is a happenstance. The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing. A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50% solution has to be basically right, and in this case it isn't. But, one can conclude only that the Lisp community needs to seriously rethink its position on Lisp design. I will say more about this later. rpg(a)lucid.com

3 3