W8SDZ@SIMTEL20.ARPA (Keith Petersen) (11/18/87)
Binaries or source code should not be posted to Info-Cpm. Arpa/Milnet readers should instead send a message to Info-Cpm-Request@SIMTEL20.ARPA asking for instructions on how to use FTP to submit files to the SIMTEL20 archives. --Keith
kenw@noah.arc.CDN (Ken Wallewein) (11/19/87)
>>I have been asked to post the binary for interrupt driven terminal program fo r >>CP/M Kaypros. What is the policy concerning such postings in this newsgroup? >> >> Jeff Wieland >> abp@j.cc.purdue.edu >Binaries or source code should not be posted to Info-Cpm. Arpa/Milnet >readers should instead send a message to Info-Cpm-Request@SIMTEL20.ARPA >asking for instructions on how to use FTP to submit files to the >SIMTEL20 archives. > >--Keith ** FLAME ON!!! *** This is a most frustrating, Arpanet-chauvinistic attitude! Only a fraction of the people who recieve this newsgroup have the capability of performing FTP access to the massive SIMTEL20 archives. This summer, SIMTEL20 shut down their mail server, so that's out too... but I guess those on Arpanet don't care about that. If they want to use SIMTEL20, fine, but DON'T go telling the rest of the group not to post binaries! Come ON!!! ** FLAME OFF **. I'm sure Keith didn't think his answer through before replying, or perhaps it was a stock answer formulated back when things were different, or something. He's been too generous with us, myself included, in the past. However, the point needs making. I can neither submit not retrieve files from SIMTEL20. This is not an idle complaint - I would do both if I could. There _is_ a mail server on the network: listserv@rpicicge.bitnet (the contact appears to be "John S. Fisher" <FISHER@RPICICGE.bitnet>). It has taken over a large chunk of SIMTEL20's CPM mail service, for those who have access to BITNET. Of course, it's not quite current and has limited "bandwidth", but deserves a lot of support. I believe it's download-only at the moment. I suggest that binary postings to the net use either HEX or UUENCODE format. There are public domain programs available to work with both; HEX is easier to get the software for, but I understand that UUENCODE does some compression. /kenw Ken Wallewein A L B E R T A R E S E A R C H kenw@noah.arc.cdn C O U N C I L
bill@sigma.UUCP (William Swan) (11/20/87)
In article <KPETERSEN.12351593221.BABYL@SIMTEL20.ARPA> W8SDZ@SIMTEL20.ARPA (Keith Petersen) writes: >Binaries or source code should not be posted to Info-Cpm. Arpa/Milnet >readers should instead send a message to Info-Cpm-Request@SIMTEL20.ARPA >asking for instructions on how to use FTP to submit files to the >SIMTEL20 archives. Info-Cpm, fine... but what about posting to comp.os.cpm (or how about comp.{sources,binaries}.cpm)? Some of us out here in the net.boonies don't have FTP access to the SIMTEL20 archives... --
W8SDZ@SIMTEL20.ARPA (Keith Petersen) (11/20/87)
If the posting of binaries starts on Info-Cpm I will shut off the Usenet and CsNet gateways from this mailing list. There are other ways of distributing binaries other than a mailing list. I am the one who must wade through all the mailer rejections that are caused by mailing list recipients exceeding their alloted disk space and by angry system administrators who have deliberate message size limits because they have to PAY for every byte that they receive. The Info-Cpm mailing list handler presently has a limit of about 50k. If binary postings start I will ask the system administrator to reduce it to 10k. I don't have the time to read all the rejections. Instead of talking about posting binaries perhaps a discussion should be started about a file server for CsNet and Usenet. There are a number of hosts that are on both the Arpanet and one of those two nets. --Keith Petersen <Info-Cpm-Request@SIMTEL20.ARPA>
FISHER@CICGE.RPI.EDU.UUCP (11/20/87)
I think it is really unfair to flame at Simtel20 and/or the internet at large just because they have something and "you cannot get it". The fact is that just about everything in the Simtel20 archives (at least for CP/M) is available through alternate means. There are the public BBS's and the information network services and the marketeers of public domain software collections. Granted, those aren't quite free, but the cost is actually modest. Mail over the networks isn't quite free, either, by the way. You may not see any direct chargeback for mail sent and received, but some of us do. And we all pay in some sense for any unnecessary load placed on the networks. Please do not construe my comments as "dog-in-the-manger" (if that is the right analogy) just because I now have FTP access to Simtel20 and you don't. I joined this group before I had FTP and before Simtel20 started the mail-based archive service. I did not think that I had any "inherient right" to be able to access the Simtel20 archives then, nor when the mail service was cancelled, nor now. By the way, the file server at RPICICGE.Bitnet can also be addressed via CICGE.RPI.EDU on the internet. Eventhough targeted to service the Bitnet Info-CPM people, mail requests from other networks are supported as long as the server can figure out how to send back a reply. It won't work for everyone, but there are at least some requests it has processed for people in UUCP-land and on mail-only Arpanet sites.
abc@BRL.ARPA (Brint Cooper) (11/20/87)
Ken Wallewein writes: > This is a most frustrating, Arpanet-chauvinistic attitude! Only a fraction > of the people who recieve this newsgroup have the capability of performing FTP > access to the massive SIMTEL20 archives. This summer, SIMTEL20 shut down their > mail server, so that's out too... but I guess those on Arpanet don't care > about that. If they want to use SIMTEL20, fine, but DON'T go telling the rest > of the group not to post binaries! Come ON!!! > Keith Peterson responds: > I am the one who must wade through all the mailer rejections that are > caused by mailing list recipients exceeding their alloted disk space > and by angry system administrators who have deliberate message size > limits because they have to PAY for every byte that they receive. > > The Info-Cpm mailing list handler presently has a limit of about 50k. > If binary postings start I will ask the system administrator to reduce > it to 10k. I don't have the time to read all the rejections. It is ironic that this dialog arrived in my mailbox on "Graham-Rudman Day." SIMTEL20.arpa is funded by your tax dollars and mine. The official justification for even having CPM archives on this machine is that there are still a number of CPM workstations in government laboratories and offices which are made more useful and efficient (as are their human users) by having public domain CPM software readily available. In various times and places, we have all heard pleadings to keep down the volume of traffic flowing through UUCP links in order to keep down the long distance telephone bills of the individual users. Similarly, we are seeing problems in internetworking to Bitnet and to the UK community because host resources are overworked and funds are not forthcoming to upgrade gateways. Well, folks, the U.S. government is in the same boat as the rest of us. Keith Peterson and many other folks on Arpanet/MILNET machines are not paid to distribute public domain software to the world at large. Their kind extensions of their work time into their personal lives and time represents a "second mile" not always noticed or appreciated. I agree with Keith: Servers on Bitnet and "the UUCP net" are needed to complement SIMTEL's service. Such a server, APPLE2-L, runs under something called LISTSERV at BROWNVM. Also, a UseNet group, comp.binaries.cpm, might be useful. Conceivably, it could be gatewayed with a Bitnet server. But if the folks in the U.S. REALLY desire some governmental austerity, they're all going to have to allow their own oxen to be gored just a little. Cheers, _Brint DISCLAIMER: I usually don't issue these things. However, for the record the foregoing, and EVERYTHING ELSE I EXPRESS, are my own opinions and my own ideas.
bandy@well.UUCP (Andrew Scott Beals) (11/20/87)
Well, I don't know if they would let us poor old 8-bit people get away with a newsgroup. However, the cheapest method of distribution is still good old U.S. Mail. For example, I have a "centipede" program that I wrote one weekend years ago for my Osborne. I've been thinking about cleaning it up and giving it away to people, but how many folks could use it? It seems that we shall always get the short end of the stick, so I'd suggest that we rely on SIG/M and our local BBS sysops for the bulk of PD programs. I think that it should be okay to post source on the net, but binaries are a little unwieldly. Keith, I know that one can get UUCP for TOPS-20 systems, how about you set up a few dialin ports and let people who want access set up uucp accounts and turn on the server for them? That way they pay the shipping costs off-site and *everyone* gets access to the SIMTEL20 archives again. andy -- Andrew Scott Beals bandy@lll-crg.arpa or {lll-crg,hoptoad,hplabs,apple}!well!bandy
berger@clio.las.uiuc.edu (11/22/87)
That works both ways. If submission and acquisition of programs is strictly via FTP, then you'll lose a good part of the program sub- missions from the rest of the world. Mike Berger Center for Advanced Study University of Illinois berger@clio.las.uiuc.edu {ihnp4 | convex | pur-ee}!uiucuxc!clio!berger
W8SDZ@SIMTEL20.ARPA (Keith Petersen) (11/22/87)
Ken, please try the file server that John Fisher is running. [Note: In the following discussion, if you are not on BITNET substitute the address LISTSERV@CICGE.RPI.EDU for the address shown.] --Keith Petersen <Info-Cpm-Request@SIMTEL20.ARPA ---forwarded message--- Date: Friday, 23 October 1987 11:48-MDT From: John S. Fisher <FISHER@CICGE.RPI.EDU> To: INFO-CPM@SIMTEL20.ARPA Re: CP/M software file server on Bitnet I have made a few radical changes to the CP/M file server on Bitnet. I will describe the changes first, then, for many of the newer people on this list who never heard of the server, I'll review its use. (1) The server has been redesigned to use a disk "cache" for keeping only the most recently/frequently requested files online. Requests for files not in the cache are deferred for overnight processing. The offline-to-online procedure is automated, but subject to delays; if a request cannot be satisfied in 5 days, the request is abandoned. (2) The archive is now more current than the former collection (which was dated 17 July 1987). I will try to keep my server up to date with Simtel20, at least within a week or two. This means very new files on Simtel20 will not be immediately available on my server, and the reverse for recent deletions. Synchronizing my server with Simtel20 is a manual process I'll perform on a best-efforts basis. (3) THE SERVER IS STILL EXPERIMENTAL, AND INFORMATION ABOUT IT SHOULD STILL BE KEPT CONFIDENTIAL TO THIS GROUP. (4) The /PDDIR command is available for getting directory listings. (5) As before, if you have any comments, questions or problems with the server, direct them to FISHER@RPICICGE.BITNET (me), and not the Info-CPM mailing list. ***************************************************************** * Help information for the PDGET command. * ***************************************************************** Selected portions of the SIMTEL20 public domain software archives are available at RPICICGE.BITNET. At present the collections include the following directories: PD:<CPM.*> -- The Info-CPM archive (CP/M machines). PD:<SIGM.*> -- The SIG/M User Group archive (CP/M machines). Planned: PD:<CPMUG.*> -- The CP/M User Group archive. Any of the files in these collections are available from the file server LISTSERV@RPICICGE.BITNET. The server responds to two commands. /PDDIR requests a directory listing of files available in an archive, and /PDGET requests a file from an archive. The file server accepts commands in both interactive messages or RFC822-style mail. (On VM and MVS Bitnet hosts, TELL LISTSERV AT RPICICGE... can be used to send an interactive message. Other Bitnet systems may have similar facilities. People on non-Bitnet systems must use the mail interface, and must insure that the From: header represents a valid return path.) ****Note: The server actually responds to many, many other commands, but none of them have anything to do with the archives. The two commands have the following form: /PDGET <format> simtel.filename < ( encoding > /PDDIR simtel.pattern The <...> mark things that are optional. * "simtel.filename" specifies the name of a file to be delivered to the user. Names are usually of the form "PD:<dir.subdir>name.type" * "simtel.pattern" specifies a search pattern used in generating a directory listing. The form of the pattern is like the filename mentioned above, but asterisks (*) may be used freely in the subdir, name, and type parts as wild cards (but not in the dir field.) * "format" specifies the method of transmission to be used: NETDATA -- suitable for transfer to Bitnet hosts that can accept files in IBM Netdata format. PUNCH -- suitable for transfer to Bitnet hosts that can accept files but cannot decode the Netdata format. Files are sent as 80-byte card-images. MAIL -- suitable for transfer to hosts that can accept only mail or are accessible to Bitnet only through gateways. Large files sent via mail are split into several smaller files that the recipient must reassemble. If the format is omitted, NETDATA is assumed for Bitnet hosts and MAIL for all others. * "encoding" specifies any special encoding of the file data: ASIS -- suitable for hosts that can receive binary data. The file is sent exactly as it is stored on my system: CP/M sector images, binary mostly. ASIS may be used only with format NETDATA. UUENCODE -- suitable for hosts that cannot receive binary data. The file is sent uuencoded. TRANSLATE -- suitable for any host, but only when the file actually represents readable text. The file is translated into character data format. If the encoding is omitted, files are sent ASIS if the transmission format is NETDATA, and UUENCODEd otherwise. /PDDIR Examples: ================ (1) The user is looking for the LASM program. /PDDIR PD:<CPM.*>LASM.* (2) The user wants a listing of the full CPM collection. /PDDIR PD:<CPM> /PDGET Examples: ================ In each of the following examples the user wants the CPM.CRCLST file to examine on his host and the UNARC16.ARK file to download to his micro, both from the CPM collection. Note that none of the examples have a closing parenthesis! (1) The user is on an IBM host directly connected to Bitnet: /PDGET NETDATA PD:<CPM>CPM.CRCLST (TRANSLATE /PDGET NETDATA PD:<CPM.ARC-LBR>UNARC16.ARK (2) The user is on a non-IBM host directly connected to Bitnet and can receive Netdata files: /PDGET NETDATA PD:<CPM>CPM.CRCLST (TRANSLATE /PDGET NETDATA PD:<CPM.ARC-LBR>UNARC16.ARK (UUE (3) The user is on a non-IBM host directly connected to Bitnet and can receive punch files: /PDGET PUNCH PD:<CPM>CPM.CRCLST (TRANSLATE /PDGET PUNCH PD:<CPM.ARC-LBR>UNARC16.ARK (UUE (4) The user is on some host somewhere: /PDGET MAIL PD:<CPM>CPM.CRCLST (TRANSLATE /PDGET MAIL PD:<CPM.ARC-LBR>UNARC16.ARK (UUE