cjdb@midway.uchicago.edu (Charles Blair) (07/15/90)
In article <1990Jul7.035507.23173@usenet.ins.cwru.edu> ernie@po.CWRU.Edu writes: >[...] >While on the subject of SU-PC/IP, I'll point out that it has a decent >implementation of MH using POP, which allows secure mail handling on >a PC. It also has FTP and the venerable PCIP Telnet, and BOOTP support. >We have added a Packet Driver interface, though this is not part of >the standard distribution. I'm not sure what the current distribution >policy is, but Stanford previously sold academic site licenses for $100. My experience with this product is that it inevitably hangs the machine if you use it long enough in a session (both its ftp and telnet implementations). Others at the University of Chicago have had this experience (disclaimer: I am not speaking as a representative of the University, but as an end-user only). Too bad, because mh is my regular mailer, and I would like to use it on the PC as well (an AST Premium 386). I should point out that Stanford's documentation says that one shouldn't run their product with any TSR's in memory -- in this day and age that's an unreasonable requirement. I've switched to FTP's product, and like it, with the following exceptions: I wish smtpsrv was implemented as a TSR, so I wouldn't have to run it at night to get all the day's mail, and I wish it didn't grab the keyboard interrupt so thoroughly that my CapsLock --> Ctrl redefinition was disabled (I use a well-behaved hook to do this). But so far it certainly seems to be a robust enough product. -- Bitnet: pmrcjdb@uchimvs1 Internet: cjdb@midway.uchicago.edu
ernie@cwlim.CWRU.EDU (Ernie L. Ellenberger) (07/17/90)
In article <1990Jul15.064627.17824@midway.uchicago.edu> cjdb@midway.uchicago.edu (Charles Blair) writes: >>[SU-PC/IP info...] >> >My experience with this product is that it inevitably hangs the >machine if you use it long enough in a session (both its ftp and >telnet implementations). Others at the University of Chicago have had >this experience (disclaimer: I am not speaking as a representative of >the University, but as an end-user only). SU-PC/IP's well-known lock up problem seems to have been cured by the replacement of Stanford's Ethernet driver with a packet driver interface. I used it all last week to program a UNIX box and had no hang ups. This morning I set up a PC with Telnet reading an infinite loop of cat jobs and sleeps; it's been running for eight hours so far. There were also some questionable operations in the SU-PC/IP code that we fixed, e.g. unlinking a file before closing it (ftp) and failing to set binary mode in a write to the configuration device driver (mh). > I should point out that Stanford's documentation says >that one shouldn't run their product with any TSR's in memory -- in >this day and age that's an unreasonable requirement. I would say that _no_ TSR's is either overprotective or a requirement of the original Ethernet driver. I'm able to run the TSR's I normally use -- ced, filec, ipx/net3, and of course packet drivers -- but there probably are many TSR's that don't coexist. Loading order is often important with TSR's; TCPIP loads and unloads fine when loaded _after_ Novell drivers, but hangs the system if it's given an unload command after being loaded _before_ Novell. (there's gotta be some way to turn that into a Feature...) This is rather obscure and doesn't happen in the midst of a Telnet or FTP session, however. -Ernie (ernie@cwlim.ins.cwru.edu) #include <std-long-legal-disclaimer.zzz>