bob@MorningStar.Com (Bob Sutterfield) (11/28/89)
In article <48698@bbn.COM> fisher@SIFVX3.SINET.SLB.COM writes: Can anyone tell me where I can get hold of a copy of GNU emacs sources. I can't use anonymous FTP so it will have to be an archive- or info-server. If there is no such server, could some kind soul mail them to me (or preferably let me know they would be willing to mail them to me. This will give me some warning so I can make enough space for them.) In article <48714@bbn.COM> bret@uop.UUCP writes: I can email it. It is HUGE!!! I'm not altogeth sure (I haven't tried to pack it up, but, compressed and tar'd, it's (i guess!) between 10 and 11 MEGS. In article <8970005@hpfcso.HP.COM> jka@hpfcso.HP.COM (Jay Adams) writes: Their is an archive server that will mail you the 18.53 sources. Send mail to archive-server@sun.soe.clarkson.edu with "help" and "index fsf" in the message body. The archive server should give you the details. If you want newer sources, 18.55, I could probably mail them to you. I don't know what the differences are between the two releases. (I sent the following last week to a mailing list where someone suggested setting up a mail-based archive server to distribute some large databases. The sentiments apply here as well. Please write to osu-cis!uucp for instructions on getting GNU software via anonymous UUCP, or find the instructions posted recently in comp.sources.d.) A mail-based archive server is an impolite and destructive way to distribute large amounts of information, and should be discouraged in such applications. When a mail-based archive server (MBAS) sends a requested chunk of stuff (CoS) to the requestor, it has no way to know what transport mechanisms will be used along the route. If the transport mechanisms are all on zero-incremental-cost-per-use networks, all is well. Very often, at least some of the trip will be along edges in a graph of an intermittent-connection, store-and-forward network, usually involving a nonzero incremental cost for transporting each CoS. Most such edges are maintained, and paid for, by the nodes on either end. They voluntarily allow other traffic to pass over their link, usually with the understanding that the volume will be small enough to be of negligible cost. However, if someone starts shipping megabytes of archives across those links, the distribution cost is borne by someone other than the requestor. This is impolite. Eventually, such hospitality abuse can cause the eventual removal of that connection from general "public service", and the two nodes will return to maintaining a private edge for their own use. Traffic will then shift to other edges, increasing their burden and encouraging them to retreat similarly. In the extreme case, the practice of general use and hospitable availability of connections will disappear. Everyone would need to maintain distinct links with every other site with which they wish to exchange traffic. Free, open, cooperative communication as we know it would wither, a nostalgic remnant of a bygone era. But take heart, there's another way! Instead, sites can pay for the connectivity they use for shipping large CoSs. If they're connected to a zero-incremental-cost-per-use network then they pay for the connectivity every month in their leased line bills. This is the case on the IP Internet, the BITnet, SPAN, and others. If a site is not so connected, then they can pay for the transient connectivity when they need it. For example, the Computer Science department at the Ohio State University has for several years maintained just such an archive. Its content is freely available to anyone who wants it and is willing to pay the cost to acquire it. No provision is made to assist requestors in freeloading on other sites' generous hospitality, other than in exchanging relatively small mail messages containing instructions and assistance in using the archive. Any number of schemes are possible, usually based around a reliable file transfer protocol. Pay-per-use archives run today using Kermit, UUCP and Fido request protocols, and probably innumerable others. Note that in saying "pay-per-use" I mean paying for connectivity (usually the phone company), not paying for the privilege of access nor for the archive contents themselves. The work involved in maintaining such access to an archive is negligible, compared to the work of maintaining the archive itself. In fact, compared to the work of untangling bounced mail replies from a MBAS, it should be quite attractive to the archivist. Once set up, the access mechanism pretty much runs itself. But MBASs are so popular, and so useful to so many people, I often feel like a voice crying out in the wilderness. Please, at least provide and encourage other, more polite distribution means. I wouldn't want such a good thing as your good intentions in redistributing software to be a contributing cause to the dismantling of open networks!
tower@bu-cs.BU.EDU (Leonard H. Tower Jr.) (11/28/89)
In article <BOB.89Nov27125422@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: ... |A mail-based archive server (MBAS) is an impolite and destructive way to |distribute large amounts of information, and should be discouraged in |such applications. ... |But MBASs are so popular, and so useful to so many people, I often |feel like a voice crying out in the wilderness. Please, at least |provide and encourage other, more polite distribution means. I |wouldn't want such a good thing as your good intentions in |redistributing software to be a contributing cause to the dismantling |of open networks! I support Bob in this cry for MBASs to not allow transport of large Chunks of Stuff (CoS). I do not plan to list any MBASs distributing GNU software in GNU help files, messages or Bulletins. MBASs are best used for small files containing pointers to large CoS and summary information. The CSnet and DDN NIC servers are excellent examples of focused limited MBASs on the Internet. Another way to help is for administrators of sites on zero-incremental-cost-per-use networks (ZicPuNets ?-) to give local people guest accounts to allow them to use ftp-like programs to access archives sites on those ZicPuNets and then download the files locally. This is a natural thing to do for any UUCP/USENET administrator a ZicPuNet site passes mail and news to. With the Internet being in local calling range of most of the US population (and increasingly the world) it also goes a long way towards solving the problem. BTW, in my experience, admins using such guest accounts are very polite and careful of all resources involved! thanx -len