hedrick@athos.rutgers.edu (Charles Hedrick) (02/17/88)
I'm surprised not to have seen more responses to your question about PC Unix ports. (Actually, I'm no longer surprised. My first attempt to respond bombed because your list of newsgroups included one non-existent one.) I'm not as qualified to comment as some, as I've had my system only for about a month, and the Microport Unix for only a couple of weeks, but I've been fairly active at porting software, and so have at least some basis for commenting on it. As should be clear from these comments, I'm really using the system as a single-user machine. I could do what I want to do on MS-DOS, but I already know Unix, I'm disgusted at having a dozen different C compilers each of which almost but not quite implements the Unix libraries -- incompatibility with each other, I'm fed up with all the software being shareware, and I like being able to do something else while I'm tranferring files with kermit or compiling something. o Which unix and why? How much? I am using Microport's System V/AT. I chose it because it was half the price of Xenix, seemed to have at least as good a reputation, and was likely to be a somewhat more "pure" Unix. (The last point may not be true for the 386, by the way, and I think that even on the 286, Xenix has been getting closer to System V over time. You should depend upon responses from people with Xenix for your evaluation of that system, not my rumors.) From any of the standard discount places, it is something like $169 for the system, and another $209 for the C and Fortran compilers. Considering that the MKS toolkit for MS-DOS is nearly $169, and the high-end compilers are generally several hundred dollars, this price is no problem. (Note that the document preparation software is not included. It is another $150 or so. All three are bundled together some something like $450. The document preparation package is nroff, troff, ditroff, eqn, tbl, pic, and some macro packages.) o How do these systems differ from 'real' unix (if there is such a thing) As far as I can tell, this is a very straightforward port of System V release 2. It is not Berkeley Unix, which in my view means that it is not "real" Unix. But as System V goes, it is "real". Now and then you'll find a minor utility that wasn't ported, but it is remarkably complete, including system administration tools that probably don't make sense on a PC. In addition to generic system V, some minimal attempt has been made to support specific features of the PC. I particularly like the virtual consoles. By hitting ALT-F1 through ALT-F4 (and I think you can raise the number if you need more) the screen switches among 4 virtual screens. It's very much like switching among 4 windows on a Sun, except of course that only one is visible at a time. It almost compensates for the fact that System V's csh doesn't have job control. It is possible to access video memory directly using the System V shared memory facilities. (The man page for shmcreate says how to do it.) I've used it for writing text directly on a monochrome screen. I haven't tried it for graphics. Another message in this group suggests that there may be some difficulties there. Note that they do not have any other real support for graphics. They also don't supply much support for common micro printers. The troff they support will print nicely-formatted output on an Imagen printer, a CAT typesetter, or a Xerox 9700 printer, but they don't give you much help with an Epson printer. Of course this is just what you'd see with "real" Unix on a VAX. In terms of reliability, I'd compare the system with the first year or so of our Pyramid. (We were one of Pyramid's early customers.) In porting four moderate-size programs (microEmacs, Kermit [just so I run from a version I have source to -- they supply kermit], xlisp and sc), I ran into one or two files where the optimizer blew up. They work OK unoptimized. I ran into one odd problem where microEmacs didn't restore the terminal modes. I was able to fix it by initializing some fields in the terminfo struct. I'm still not sure whether this was a bug in uEmacs or some oddity with uport. I ran into a problelm with sc where the screen display looked odd, and the console was left in an unusable state after exit. It turned out to be a couple of bugs in the terminfo description of the console (type ansi). They were easily fixed. (I've told uport about the problem and fix.) This is probably a bit more trouble than I'd expect to see on a VAX or a Sun, but isn't bad. I've had a couple of cases where a job hangs, and only reloading the system would free it. (It seemed to be when it ran out of memory or swap space. The problem went away when I switched to a decent malloc.) Other jobs were usable though. And I haven't seen any system crashes yet. Again, this is a higher level of odd system behavior than I'd expect to see on a Sun, but there are many systems in the world that are far worse, and it's well within my expectations. Almost all, if not all, of the problems I have seen are listed in the known bugs list that comes with the release notes. o Where do you get info on unix system care and feeding? Read the manuals? The manuals seem to be an amalgamation of the ATT System V manuals, with some additional introductory material. ATT has put in some work on documentation, so Unix manuals are in general better than they were back in the good old days of 7th Edition. If you are an experienced computer programmer, you can learn Unix from the manuals. However it's not clear that you'd want to. If you're using it as a single user system, there really isn't a lot of administration to do. As it comes out of the box, the startup files are appropriate for that purpose. About all you have to do is create yourself an account, set up the printer spooler for your printer, and modify the appropriate startup file so that lpsched gets run at startup. They tell you how to set up an account. (You just edit /etc/passwd, create a directory for yourself, and change its ownership to yourself.) There is a chapter on setting up printers, which gives good instructions, though you do have to look around in a directory and figure out which "model file" is appropriate for your printer. That's pretty much it. There is a spiffy menu-driven sysadmin tool that will do all of that automatically, if you like such things. (I'm a Unix hacker though. Real programmers don't use menu systems.) Of course if you want to run UUCP, things get more interesting. Again, there is documentation on what to do, but it can get a bit complex. (I think the sysadmin tool may even set up UUCP for you. But even with automated help there are going to be choice you have to make that will require some background.) If you're using the thing as a single-user machine, you might prefer just to use kermit (which they supply). While this is all straightforward, and they supply instructions, if this was your first exposure to computers, you might find it a bit much. Whether it would be any worse than trying to install and set up MS-DOS on a hard disk is a bit unclear. The process is probably no more complex. Of course if you really want to run it as a multi-user system, with news and regular cron jobs, and all that good stuff, then you're talking a different ball game. Probably the thing to do is to set it up as a simple single-user system, get a feel for it, and then start adding complexities one by one. o What is a 'news feed', and how do you get one. Do I want one? This is a sort of odd question. Obviously you know what news is, since you posted your question. A news feed is a relationship between your computer and some other computer that feeds you news. If you want to have Usenet news on your PC and read it there, rather than logging into a machine at your university and reading it there, then you need a news feed. If you have easy access to a university computer, I'd read the news there. Setting up UUCP and news, and administering it, is somewhat complex. Also, if you get a full set of news, it takes lots of disk space and will use lots of machine resources. Finally, Microport's weak point appears to be handling serial lines. (This is probably not entirely their fault, but stems from built-in weaknesses of the hardware. The PC wasn't really designed as a multi-user system.) You can apparently do UUCP at 9600 baud, but not while doing anything else with serial lines at the same time. It used to be that exceeding the capabilities of the system caused crashes. Microport claims that a lot of these are fixed in release 2.3. I don't think the evidence is yet in on whether all of the crashes have gone away or not, but it is clear that some performance problems remain. Of course if you have a single-user system, you don't have anything else to do with your serial lines, and this probably won't be an issue for you. But the administrative and resource burden is still not something to take on lightly. o What are basic system requirements? Microport says you need at least a 17MB disk partition and 512K of memory. I think the 512K of memory is intended as a joke. Presumably you can boot the system in it, but I wouldn't try to execute any commands. (Note that Microport doesn't seriously advise anybody to use it on a 512K system. I asked them over the phone whether their system would work on a 640K machine. The answer was "well, yes, but it will be beastly slow.") I ran for a week with 1M of memory. It swapped a bit more than you'd like, but as a single-user system was livable. My main problem was reading big files into microEmacs, but I later found out that this was because the supplied malloc is substandard. I'm now using a tuned malloc, and I think Emacs would probably work OK in a 1M system now. Compilations would still be slow though. I'm now using 1.5M. It seems to work fine as long as you don't try to do lots of memory or disk-intensive things at once. Most of the swapping caused by compilations seems to have gone away with the step up from 1 to 1.5M, though I get the feeling that another .5M might make some marginal difference. (Probably relinking the compiler with a decent malloc would be a better solution, but of course I can't do that.) That is, while I'm doing a compile I could be editing a file or maybe looking around with ls, but I wouldn't want to be doing much else. I've heard recommendations as high as 2MB for the system and 1MB for each user, and 4MB machines are common among people who like to run Xenix or Unix. But for my purposes, I don't plan to go above 1.5M. Probably 17MB is enough for somebody who isn't going to have many large files. I use a 25MB partition, and it looks like it's going to keep around the sources to a number of public-domain Unix programs and the smallish things that I'm working on. Of course if I were using it for database work, or keeping records of a company, I'd need more space, but that's obvious.
bkm%wintermute@Sun.COM (Bruce Martin Jr.) (02/18/88)
In article <863@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: [...stuff deleted...] >attempt has been made to support specific features of the PC. I >particularly like the virtual consoles. By hitting ALT-F1 through >ALT-F4 (and I think you can raise the number if you need more) the >screen switches among 4 virtual screens. Has anyone figured out how to increase the number of virtual consoles? I'd like to up the number (four can sometimes be limiting), but haven't found it in the manual. >Microport says you need at least a 17MB disk partition and 512K of >memory. I think the 512K of memory is intended as a joke. Presumably >you can boot the system in it, but I wouldn't try to execute any >commands. (Note that Microport doesn't seriously advise anybody to >use it on a 512K system. I asked them over the phone whether their >system would work on a 640K machine. The answer was "well, yes, but >it will be beastly slow.") I ran for a week with 1M of memory. I'll second the need for memory. I ran for a couple of months with 1Mb and it was not very usable for compilation (make, cc, etc running together). I've upgraded to 4Mb and the machine runs like a top... Also, uPort supplies two version of the kernel (one is smaller, and missing certain builtin functions; semaphores come to mind). If you only have 1Mb, run the small kernel unless you absolutely need the functionality. Of course, a fast disk make a lot of difference also. You don't want to try running with a 'PC-speed' disk (in the 80ms avg. access range). ...bruce Bruce Martin Jr. ARPA: bkm@sun.com Window Systems Group UUCP: ucbvax!sun!bkm Sun Microsystems, Inc. 415/691-2992
bae@ati.tis.llnl.gov (Hwa Jin Bae) (02/18/88)
There is no way to increase the number of virtual consoles (more than
four at a time). However, if you have DOSmerge running, you can run
up to seven DOS sessions in the background, each of which can be
accessed via additional virtual consoles by doing CTL-ALT-SYSRQ.
This is true for the System V/386 only.
Some problems I am currently having are:
1) When using Exelan 205T and its TCP/IP software ("r" utilities,
telnet, ftp, socket lib., assortment of net. daemons,etc.),
the newly built kernel conflicts with (or somehow no longer
understands the DOSmerge calls) DOSmerge; DOS simply is not
available any more as soon as you go to init state 3 to do
the networking.
2) It happens that the virtual consoles become disabled as well,
except one - the real virtual console (does this make sense?).
Is anyone experienced in the above problems?
Hwa Jin Bae
Control Data Corp. bae@{ati,aftac}.tis.llnl.gov (Internet)
4234 Hacienda Drive {ames,ihnp4,lll-crg}!lll-tis!bae (UUCP)
Pleasanton, CA 94566 hbae@plseca (smail)vandys@hpindda.HP.COM (Andy Valencia) (02/20/88)
2.3 ups the limit to 15. You just create more entries in /dev, add the entries to inittab, and go! Andy Valencia vandys%hpindda.UUCP@hplabs.hp.com
markz@ssc.UUCP (Markz Zenier) (02/22/88)
In article <42219@sun.uucp>, bkm%wintermute@Sun.COM (Bruce Martin Jr.) writes: > > Has anyone figured out how to increase the number of virtual consoles? > I'd like to up the number (four can sometimes be limiting), but haven't > found it in the manual. For version 2.3 , it is in the release notes on page 4 to add more consoles /etc/mknod /dev/cons5 c 0 5 and add or enable the getty line for that port in /etc/inittab Note if you boot the 2.2 kernal, it will set up two gettys on the same virtual console and really screw up. If you don't set up the getty, it is just a display device , useful for debugging output. Only those console devices that have output will be accessable with SysReq, so the number of consoles is variable. My problem is that my clone keyboard locks up when the LEDs are changed, and a keypress occurs around the same time. This is a documented Xenix problem, with a patch. Is there a patch for version 2.3?
fyl@ssc.UUCP (Phil Hughes) (02/23/88)
In article <141@bdt.UUCP>, david@bdt.UUCP (David Beckemeyer) writes: > I have 2MB of memory on a 286 AT system running Microport; Sometimes it > runs out of swap space and the system crashes (I have 3 MB of swap space). > This occurs most often when the system is receiving incoming news, > when UUCP fires up several rnews/compress jobs, each chewing on large > news batch files. > > It usually only happen when there > are four or more rnews/compress jobs running all at the same time. I see a simple solution to your problem: don't run so many unbatches. On a 286 system, you are not going to do anything more than thrash if you have more that one running. The system slows down, you eat up all your swap space and nothing good happens. I was having this problem on a 286 XENIX system. Even with 4MB of RAM the news throughput was less than one unbatch. The problem with XENIX (and maybe the reason you are running more than one unbatch also) is that the uuxqt lock times out after about 1 hour. The solution is to add a touch -c /usr/spool/uucp/LCK.XQT that is run every half hour by cron. All is well here. -- Phil uunet!pilchuck!ssc!fyl
rcw@qetzal.UUCP (Robert C. White) (02/25/88)
In article <1038@ssc.UUCP> fyl@ssc.UUCP writes: > >I was having this problem on a 286 XENIX system. Even with 4MB of >RAM the news throughput was less than one unbatch. The problem with >XENIX (and maybe the reason you are running more than one unbatch also) >is that the uuxqt lock times out after about 1 hour. The solution >is to add a > touch -c /usr/spool/uucp/LCK.XQT >that is run every half hour by cron. All is well here. >-- >Phil uunet!pilchuck!ssc!fyl Or, even better, get the Honey Danber version of UUCP from Microport. This implementation has a file called /usr/lib/uucp/Maxuuxqts that contains the number of simultaneous uuxqts that are allowed to run. Also the '-x' flag to uucico works with Honey Danber. I have been running this version of uucp for several months now with little problem. On the down side, HDB does not make use of the ordinary uucp's /usr/lib/uucp/dialinfo capability. Another thing you want to do if you are running news is to increase the number of in-core inodes in the kernel configuration files to 200 or so. 125 just doesn't cut the mustard. I have been running news on a similar setup for more than a year now, and unbatching still seems to clip along at a reasonable rate. I never have run out of swap space. Hope this helps -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ US SNAIL: 11534 Steele St, Thornton, CO. } Robert White { MA BELL : (303) 252-9090 } ihnp4!upba!qetzal!rcw { HORSE : Jct Platte River & Cherry Creek ~~~~~~~~~~~~~~~~~~~~~~~~~~~
root@elric.UUCP (root) (03/04/88)
In article <141@bdt.UUCP>, david@bdt.UUCP (David Beckemeyer) writes: > In article <863@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: > >[..] later found out that this was because the supplied malloc is > >substandard. I'm now using a tuned malloc, and I think Emacs would [..] > > What is the "tuned malloc" that Charles is talking about? Is it something > from Microport? Does it exist for the 286 version too? Perhaps the "tuned malloc" that Charles is talking about is the malloc library that can be loaded with a -lmalloc on the cc command line. I have done most of my development work on a vax 11/780 running "real" att sysVr2.0 and have occasionally run into mysterious (and dreaded) core dump problems using the "standard" malloc but find that they go away when i use -lmalloc; without changing any code -- simply recompiling! So, what I do is, unless i have a special reason to use the other features of the -lmalloc (a faster malloc, according to the man page) i just use the standard malloc until i get dumb core dumps, then i try the -lmalloc to see if the problem goes away. Most of the time, it does.... -- Derek Terveer root@elric.UUCP ..!clyde!lily!elric!root
david@bdt.UUCP (David Beckemeyer) (03/04/88)
In article <1393@qetzal.UUCP> rcw@qetzal.UUCP (0000-Robert C. White) writes: >Also the '-x' flag to uucico works with Honey Danber. I have >been running this version of uucp for several months now with >little problem. On the down side, HDB does not make use of the >ordinary uucp's /usr/lib/uucp/dialinfo capability. I am not running HDB yet, but it sounds better. I need the dialinfo becuase I use a strange modem. Does HDB have a similar mechanism for setting up the dial sequence? Now that I know "standard" UUCP, how hard is it to learn, and setup HDB UUCP? -- David Beckemeyer | "To understand ranch lingo all yuh Beckemeyer Development Tools | have to do is to know in advance what 478 Santa Clara Ave, Oakland, CA 94610 | the other feller means an' then pay UUCP: ...!ihnp4!hoptoad!bdt!david | no attention to what he says"
det@hawkmoon.MN.ORG (Derek E. Terveer) (03/07/88)
In article <165@bdt.UUCP>, david@bdt.UUCP (David Beckemeyer) writes: > Now that I know "standard" UUCP, how hard is it to learn, and setup HDB UUCP? I would say that h+d uucp is just as easy ("hard"?) to set up as stock uucp. In fact, its somewhat less frustrating. I don't know about the rest of the world, but after administrating experience with 6 machines, i have had day-time nightmares concerning the "evil USERFILE". Quite a few of my networking problems went away after upgrading to h+d. Principally, i don't have to spend a lot of my time baby-sitting the connections, lest my disk runneth over (like a babbling brook) from all the files sitting around waiting for the brain damaged stock uucp to send them. (it gets into wedged wait states fairly easily, you see) Anyway -- to summarize (and to cut myself off, mercifully) i think the change over to h+d is well worth the time. -- Derek Terveer det@hawkmoon.MN.ORG uunet!rosevax!elric!hawkmoon!det
jhs@actnyc.UUCP (John Spicer) (03/08/88)
In article <412@elric.UUCP>, root@elric.UUCP (root) writes: > my development work on a vax 11/780 running "real" att sysVr2.0 and have > occasionally run into mysterious (and dreaded) core dump problems using the > "standard" malloc but find that they go away when i use -lmalloc; without > changing any code -- simply recompiling! > > So, what I do is, unless i have a special reason to use the other features of > the -lmalloc (a faster malloc, according to the man page) i just use the > standard malloc until i get dumb core dumps, then i try the -lmalloc to see if > the problem goes away. Most of the time, it does.... When I have tried the -lmalloc version on Microport SYSV/AT 286 it dumps core. I tried using the standard version and it is SLOW. I finally ended rewriting malloc so I could get a version that works, and works quickly. I hope Microport provides a decent version of malloc some day. John Spicer InterACT Corporation uunet!actnyc!jhs
dave@micropen (David F. Carlson) (03/10/88)
In article <717@actnyc.UUCP>, jhs@actnyc.UUCP (John Spicer) writes: > In article <412@elric.UUCP>, root@elric.UUCP (root) writes: > > the -lmalloc (a faster malloc, according to the man page) i just use the > When I have tried the -lmalloc version on Microport SYSV/AT 286 it dumps core. > I tried using the standard version and it is SLOW. I finally ended rewriting > malloc so I could get a version that works, and works quickly. > > I hope Microport provides a decent version of malloc some day. > > John Spicer > InterACT Corporation > uunet!actnyc!jhs Microport has real problems with malloc on the 286 because the way AT&T malloc works is not applicable to 286 processor. The absurd segmentation scheme forces Microport to do very bad things with respect to allocation. Read sbk(2) man page. The jist of it is that although real malloc will look at all previously allocated space for new malloc calls, Microport's malloc only looks at the space in the current sbk segment! Thus, processes grow without bound because once a new segment is allocated, all the previously allocated memory in the other segments (and potentially free'ed) is not available to be reallocated. This is why the 386 product is 1000% more usable for real computing that the 286 product. Microport's malloc(3X) DOES NOT WORK on the 286. It just don't. I thought briefly about writing a good 286 malloc, but then the nightmare ended and I bought a 386. I have had 0.0 bad experiences with malloc(3) with Microport 386 and I heartily recommend it. -- David F. Carlson, Micropen, Inc. ...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave "The faster I go, the behinder I get." --Lewis Carroll
steve@nuchat.UUCP (Steve Nuchia) (03/12/88)
Re: flamage about the 286 malloc.
It really is a crock. I looked into it and wrote the following
allocator in support of pathalias, and it works with good
efficiency (both space and time).
If someone wants to layer the free() logic, say from K&R,
on top of this it would make a very usable replacement.
This only applies to large model, since sbrk isn't broken
in small model (small consolation).
--
/*
* a primitive malloc replacement that works efficiently
* in spite of the braindamage in uPort's brk/sbrk.
*
* This routine does not support a free() call. Recommend
* someone layer a reasonable alloc/free package on top
* of this system interface routine and repost it.
*
* Steve Nuchia
* released to the public domain
* 12 March 1988
* steve@nuchat (713) 334 6720
*/
char *malloc(n)
unsigned n;
{
static struct
{
char *p;
unsigned s;
} seg[64];
static int ns;
register int i;
if ( n & 1 ) n++;
for ( i = 0; i < ns; i++ ) if ( seg[i].s >= n ) break;
if ( i == ns )
{
if ( ++ns > 64 ) abort();
seg[i].p = sbrk(0);
seg[i].s = 0x0F000;
if ( n > seg[i].s ) seg[i].s = n;
while ( seg[i].s && brk(seg[i].p + seg[i].s) == -1 ) seg[i].s -= 512;
seg[i].p[0] = seg[i].p[seg[i].s - 1] = 0;
}
seg[i].s -= n;
seg[i].p += n;
return ( seg[i].p - n );
}
--
Steve Nuchia | [...] but the machine would probably be allowed no mercy.
uunet!nuchat!steve | In other words then, if a machine is expected to be
(713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947dave@micropen (David F. Carlson) (03/15/88)
In article <777@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes: > Re: flamage about the 286 malloc. > > It really is a crock. I looked into it and wrote the following > allocator in support of pathalias, and it works with good > efficiency (both space and time). > > If someone wants to layer the free() logic, say from K&R, > on top of this it would make a very usable replacement. > Malloc itself is easy as the code Steve has written illustrates. Note this implementation is fixed in the maximum allocated space. Also free is not so easy as he would have us believe: free must allow future mallocs to look at all the freed space for allocation of potentially large spaces. If this infomation is stored in the local segment, how many objects can be allocated in toto? If this information is stored globally, then a very hard limit of total objects storable is made. I have never had any trouble with Microports malloc, but rather malloc-free-malloc combinations which cause unbounded process growth. This problem is not without solution but any varients I've thought of imply expensive tradeoffs in time/space for the generic malloc I've come to know and love on linear addressing machines. -- David F. Carlson, Micropen, Inc. ...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave "The faster I go, the behinder I get." --Lewis Carroll
steve@nuchat.UUCP (Steve Nuchia) (03/17/88)
From article <428@micropen>, by dave@micropen (David F. Carlson): > In article <777@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes: >> If someone wants to layer the free() logic, say from K&R, >> on top of this it would make a very usable replacement. > Malloc itself is easy as the code Steve has written illustrates. > Note this implementation is fixed in the maximum allocated space. > Also free is not so easy as he would have us believe: free must > allow future mallocs to look at all the freed space for allocation > of potentially large spaces. If this infomation is stored in the > local segment, how many objects can be allocated in toto? If this > information is stored globally, then a very hard limit of total objects > storable is made. I have never had any trouble with Microports malloc, > but rather malloc-free-malloc combinations which cause unbounded process > growth. This problem is not without solution but any varients I've > thought of imply expensive tradeoffs in time/space for the generic > malloc I've come to know and love on linear addressing machines. Did you read my note? K&R provides a very simple alloc/free algorithm, based on allocating a chain pointer/free flag word with each piece of memory allocated. Adding this would be trivial and architecture independent. Stock malloc works but is very very slow when allocating many small pieces of memory - at least a brk() per kilobyte or whatever the figure is. My code is a great deal faster, where it is applicable. There are published algorithms for storage allocation that beat the "malloc [we've] come to know and love" to death in both time and space. Microbug's -lmalloc is based on one of them. To implement any one of them someone would have to duplicate my effort or steal my code - figuring out how sbrk() and brk() interract in large model was not at all fun, and I think it was worth posting a limited routine to make that knowledge available. And as far as being "fixed in the maximum allocated space", you show me a uPort 286 system that will let you allocate 65 60Kb segments and I'll eat my hat. Well, perhaps it is possible, since that is only four meg... but the extension mechanism is obvious. -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947