Usenet 1994 October

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / misc / volume20 / intro20 < prev next >

Wrap

Text File | 1991-05-20 | 39.6 KB | 838 lines

Newsgroups: comp.sources.misc From: Kent Landfield <kent@sparky.imd.sterling.com> Subject: v20INF1: Introduction to comp.sources.misc Message-ID: <1991May20.162859.25205@sparky.IMD.Sterling.COM> X-Md4-Signature: ad760c3126823c9d0498e1fe1c30a3f8 Date: Mon, 20 May 1991 16:28:59 GMT Approved: kent@sparky.imd.sterling.com Submitted-by: Kent Landfield <kent@sparky.imd.sterling.com> Posting-number: Volume 20, Info 1 Archive-name: intro20 I am *still* requesting comments on a new auxiliary header, Environment:. It would be used to specify the runtime requirements needed by a submission. I have been shown that in a newsgroup that is not restricted to one type of operating system, one type of machine or one type of architecture that there is a need for this type of information in the header. I am not sure about its usage at this point. *Please* send me your opinions on its proposed usage, yea or nea.. Is there anyone in Asia that would like to provide comp.sources.misc archive access to the sites located in that part of the world ? If you would like to but don't know where to start, *please* send me some mail. I can get you setup with both the software to run it as well as a copy of the archives themselves. This is the first of five introductory messages about comp.sources.misc. It describes the newsgroup's history, how to submit sources to c.s.misc, where the archive sites are, and how to contact and access them. The second, third and fourth postings together comprise the index of previously posted software. The fifth article is a cross-index of patches that have been posted to this newsgroup. As always, I am looking for suggestions on how to improve the usefulness of the newsgroup. Do not hesitate to send suggestions to kent@uunet.uu.net or kent@sparky.imd.sterling.com. -Kent+ -------------------- Subject: Introduction Comp.sources.misc is sort of a "catch-all" sources group. The group is run in a generally informal manner. *Any* program source code will be accepted. Discussion and "sources wanted" requests will be discarded with a message back to the sender advising him/her to post to the correct newsgroup. Please do not send either to me, they don't belong here. The moderated comp.sources.misc replaced the unmoderated net.sources in May 1987. This was done by the Usenet backbone in response to the observed fact that net.sources was largely NON-sources by number of articles. The initial moderator of comp.sources.misc was Brandon Allbery. Mail Brandon received at the time indicated that the majority of people were willing to trade the small delays (mainly caused by network delays in mail) for having a source group that wasn't full of noise. As stated above, the only reason a submission will be rejected is if it is non-source. I am striving to get things out as quickly as possible. Testing of the source is not done. I will, however, assure that postings are in shar format and that shar'ed submissions can be unshar'ed correctly. If a patch is submitted, I assure that the patch can be applied to the sources it is to patch. If the submission is something that needs testing, it probably should be sent to comp.sources.unix instead. (Send submissions to comp-sources-unix@<backbone> in that case.) -------------------- Subject: Deciding where to post your software There are three choices for sources newsgroups, not counting local sources groups (fl.sources) or groups for specific systems (comp.sys.sun, et al.). Choosing between them can be somewhat difficult for the novice, and even for seasoned sources posters with unusual submissions. Here, then, is a discussion of the various "primary" sources groups, their advantages and disadvantages, and a crude attempt at quantifying when to use them. First off is comp.sources.unix, the major sources group. It is rather unfortunately named, but don't let that stop you from trying to submit something if it fits the group's guidelines otherwise. The benefits you'll get are testing of source on at least some machines before posting and guaranteed archiving at many Internet and UUCP sites. The problem is that smaller postings aren't usually accepted, especially if they don't come with a Makefile and README file -- and sometimes the moderator declares a moratorium on certain types of postings, like text editors. Trying doesn't hurt, however; if the moderator rejects something, he dumps it into the c.s.misc mailbox. I should also note that the current policy of comp.sources.unix is not to accept "shareware" programs, programs which request or require a fee to the author for continued use. For small sources and beta copies of programs (which probably should not be archived, in favor of the production release), one might choose alt.sources. It has one major advantage over the other possibilities: there is no moderation, meaning no delays and no rules for formatting. You're free to just pipe a source file to inews if the fit takes you (not that I recommend it). But it also has one major disadvantage: since the group isn't moderated, there is nothing preventing people from starting up discussions ranging from source code topics to why EUnet works the way it does. This, if you'll recall, is what caused comp.sources.misc to be created in the first place; although it seems that at least some people have benefited from the lesson and have started to work harder to prevent its happening to alt.sources. Another disadvantage is that, being an "alt" group, it doesn't get as wide a distribution as the "mainstream" Usenet. (For further information on the "alt" hierarchy, see the "Alternative Newsgroup Hierarchies" document posted once a month by Gene Spafford in news.lists.) And then there's this group, comp.sources.misc. The original charter called for moderation solely to reject non-source postings, nothing more; the intent was to provide net.sources without the noise. This changed rather quickly, as a policy was adopted of letting the group be controlled more by its users (submitters, readers, archivers) than by "moderative fiat". The advantages of posting here are that archiving is almost as widespread as that of comp.sources.unix, that anything that is source code can be posted, and that it's guaranteed not to be lost in non-source, discussion postings; the disadvantages are that there is a slight delay caused by having to filter stuff through the moderator. So which do you choose? While there are no hard rules, there does seem to be an evolving rationale for the use of the groups: if your software is in need of beta-testing and it is not quite ready for mainstream archiving, post it to alt.sources. After the beta period is over, submit it to the appropriate comp.sources.whichever group for worldwide distribution and archiving. In general, games usually are sent to comp.sources.games regardless of their size. Programs which are specific to a particular computer might be better off in an specialized sources group like comp.sources.sun or comp.sources.amiga, and X-Window based applications can be posted through comp.sources.x. Released, major programs usually go to comp.sources.unix, and comp.sources.misc is used for the rest. Remember though, it's up to you to decide to which newsgroup a your submission should be posted to. -------------------- Subject: The structure of comp.sources.misc articles Each posting in comp.sources.misc is called an "issue"; there are roughly 100 issues to a volume. The division is arbitrary, and has varied greatly in the past. There are two types of articles in comp.sources.misc; sources and "informational postings." They can be distinguished by the subject line. All source postings will be stored in a subdirectory within the volume so that patches have a place to be stored. Subject: v03INF1: Introduction to comp.sources.misc This first word in the title identifies this as the first info posting of volume three. Similarly, the subject line shown below: Subject: v014i082: lc - Categorize and List Files In Columns, Part01/02 identifies this as the 82nd source article in Volume 14. In the above example, the Part01/02 indicates that this is the first part of a two part posting. All sources are broken up into pieces. This is done so that there could be a proper storage directory when patches are issued. The first few lines of an article are auxiliary headers that look like this: Submitted-by: kent@sparky.IMD.Sterling.COM (Kent Landfield) Posting-number: Volume 14, Issue 82 Archive-name: lc/part01 The "Submitted-by" line in each issue is the author of the program. IF YOU HAVE COMMENTS ABOUT AN ISSUE PUBLISHED IN COMP.SOURCES.MISC, THIS IS THE PERSON TO CONTACT. When possible, this address is in domain form, otherwise it is a UUCP bang path relative to some major site such as "uunet." The second line repeats the volume/issue information for the aide of NOTES sites and automatic archiving programs such as rkive. The Archive-name is the "official" name of this source in the archive. All source postings will be treated as multi-part postings have been done in the past. The postings will have a subdirectory under the volume directory. This gives me a place to store patches as well as allows me to have more informative archive names without having to worry how many spaces the part numbering, patch indicator or compression suffix will take up. Postings will have names that look like this: Source posting Archive-name: lc/part01 Patch posting Archive-name: lc/patch01 Please try to use this name when requesting that sources be mailed to you. Note that the part number and patch number will be zero padded for convenience sake as was requested by several people. Also, note that the "part number" given in the title will be used to give the reader an indication of the total number of parts that make up the complete set of sources. The example below shows that this is part 21 of a 23 part submission. v17i102: calentool - day/week/month/year-at-a-glance SunView tool, Part21/23 Informational postings such as this posting will not be stored in a subdirectory as is the source postings. INF postings will have archive names such as indx20v1-7 and patchlog20. From an archiving perspective, archive names for all INFormational postings will be specified so as to store the INF postings directly in the volume's base directory. Archive names for source postings will be specified so as to store the sources in subdirectories within the volume's base directory. To support the tracking of patches the Patch-To: line is used in c.s.misc. The Patch-To: line exists for articles that are patches to previously posted software. The Patch-To: line only appears in articles that are posted, "Official", patches. The initial postings do not contain the Patch-To: auxiliary header line. Patch-To: syntax Patch-To: package-name: Volume X, Issue x[-y,z] Patch-To: examples. These are examples and do not reflect the accurate volume/issue numbering for rkive. In the first example, the article that contains the following line is a patch to a single part posting. Patch-To: rkive: Volume 22, Issue 122 This example shows that the 122-124 indicates the patch applies to a multi-part posting. The '-' is used to mean "article A through article B, inclusive.. Patch-To: rkive: Volume 22, Issue 122-124 If a patch applies to multiple part postings that are not consecutive, the ',' is used to separate the part issue numbers. It is possible to mix both ',' and '-' on a single Patch-To: line. Patch-To: rkive: Volume 22, Issue 122,125,126,127 or Patch-To: rkive: Volume 22, Issue 122,125-127 If a new release is posted instead of a large set of patches, the new posting will contain a Supersedes: header line with a format similar to the Patch-To: header. Supersedes: syntax Supersedes: package-name: Volume X, Issue x[-y,z] Supersedes: example Supersedes: rkive: Volume 22, Issue 122-127 The Supersedes: line is helpful for cleaning archives by providing a pointer to previous versions that the archive administrators can then remove from their archives. Prior to January 1, 1988, a different archive header system was used. At the time, it was not expected that comp.sources.misc would be welded into the then-evolving standard for sources archiving. There was only one special header line, and it resided in the main header. It looked like X-Archive: yymm/nn where "yymm" was the year and month of the submission date and "nn" was a sequence number. Please keep this in mind when dealing with archive submissions from 1987. ----------------- Subject: Patches Handling Patches will be handled as swiftly as possible. Authors of sources posted to c.s.misc should send all patches to me so that I can post them back through the newsgroup in order that the patches can be archived. This has not been done in the past in other sources groups and has lead to lost patches. If the patches must get out *real* fast, post them to comp.sources.bugs and send me a copy at the same time so that they will be available when they are needed in the future. Again, patches will receive priority processing so make sure I get them... I would prefer not to post patches that are not sent by the author of the original posting unless special arrangements have been made with the author. Please send your unofficial patches to the author so that the author can incorporate them into their postings baseline. Unofficial patches can be posted to comp.sources.bugs as a method of letting the community use the fix or enhancement during the interium. It is up to the author to determine if there have been major enough changes to warrant a complete reposting. This may be necessary if the size of the patches exceeds the size of the source but in most cases only patches are posted. Total repostings should be treated as an initial posting. What follows pertains to patches... 1. When patches are submitted, they should be in context diff format. Patches can be made with diff -c on 4.XBSD based machines and with diffc on others. Diffc can be found in volume 1 of comp.sources.unix archives. GNU diff can also be used to create context diffs. 2. A patch to patchlevel.h should be done to reflect that the patch has been applied if a patchlevel.h existed in the initial posting. If one was not included initially, maybe now is a good time to consider including one... :-) 3. Include information about which previously posted issues the patch pertains to if they were initially posted to c.s.misc. For more information on patch see patch.man in util/patch/patch.man in the X11 Release 4 distribution or in volume7 of the comp.sources.unix archives. -------------------- Subject: Guidelines for submitting source for publication Items intended for posting and problem notes should be sent to "sources-misc@uunet.uu.net" or to "sources-misc@sparky.imd.sterling.com". Newsgroup-related mail that is *not* a submission should be sent to me at sources-misc-request@uunet.uu.net or sources-misc-request@sparky.imd.sterling.com. If you want verification of arrival, say so in a cover note, or at the beginning of your submission, if it is small. I will try to do this by default but if you want it guaranteed, ask... To make life easier for both myself and the users of the comp.sources.misc newsgroup, I request that all submissions follow the following guidelines. Not following these guidelines may result in longer delays, since some things *must* be fixed for news to accept the submission, and others fixed so that I can spend time processing submissions rather than responding to flames. ;-) First, uuencoded postings are frowned upon. If at all possible, binary data files should be translated to an ASCII format that is usable by others. If it's not possible, consider sending the machine-dependent parts of the posting to another newsgroup. If all else fails, it will be accepted if it is not the only component of the submission; otherwise, it may be better to announce the availability of the item via anonymous FTP, UUCP, FTAM, etc A corollary of the above rule is that uuencoded (ABEd, btoa'd, BinHexed, ...) compressed (packed, ...) archives are not acceptable regardless of the compression and/or archiving method used. Not everyone has ARC, PKZIP, ZOO, StuffIt, or even cpio or tar and the "compress" program. The second rule is that "shell archives" as created by "shar", "cshar", "bundle", etc. be used to package files. Preferably, use cshar: it guards against mangling by older news programs, Bitnet mailers, etc. I must repack non-shar'ed submissions so that they have a better chance of surviving older mail/news systems and inter-network gateways. Third, *please* send me a Subject: to be used in posting your submission. Certain large postings in the past have arrived sans Subject:; not only does this force me to make one up for the archive list. Fourth, *please* send me an archive-name or package name that you want the submission archived by. If you do not send me one then I get to name your sources in the archives... Fifth, if your submission has limitations, such as it does not run on SYSV or limited to a specific version of SUNOS, or whatever the conditions, *PLEASE* inform me so that it can be included in the blurb that appears on the first part of the posting. This way people who are not able to run your submission will not take the time to ftp or unpack it. The following information should be supplied as appropriate: 1. If the submission is a patch to a previous posting, let me know the volume and issue(s) that it appeared in. 2. If the submission is a complete reposting of a previous posted package, let me know that the posting is superseding your previous submission. Each of the postings should contain a "blurb" that describes what the posting is/does/contains. This should only be a paragraph or two. When you submit your sources, please include the blurb on the first part. If you do not write it youself, I will have to grab it out of the submission somewhere. Please do not package executable programs and sources in the same submission. Executable binary programs are inherently system-dependent, and therefore should be posted to a system-specific "binaries" group. And, as a special case, Un*x executables should NEVER be posted to the Usenet. Please keep source filenames to 12 or fewer characters in length. Not everyone has long filenames... :-( Other nice things to consider/supply when submitting sources... 1. A Makefile. 2. A manual page is highly recommended for any substantial sized submissions. 3. A README file is also highly desirable. This should contain a brief description of what the posting is and any special considerations in building it. The README should also contain a list of authors and the distribution and copying policy. 4. A patchlevel.h -- This file can be used to keep track of how many official patches have been applied. 5. Any additional documentation (past the recommended man page) should be in PostScript format. ------------------------ Subject: Special services One way to solve the problem of an announcement not going out the same day as the posting it announces is to send the announcement to me -- under separate cover, please, it slows things down if I have to break a submission apart to get at the file -- with instructions as to where it should be posted, and I will insure that both go out the same day, if possible. (If one of the other newsgroups is also moderated, there's not a whole lot I can do about it.) The same goes for binaries and/or other material associated with a source; send it under separate cover and tell me what to do with it, and I will try to arrange for them to all go out at the same time. To help avoid the longer delays and possible network difficulties between the main comp.sources.misc receiving address and sites in Australia, john@basser.cs.su.oz.au acts as a sub-moderator for our friends "down under". It's not required to send sources to him, but the submission will be seen by your neighbors that much more quickly if it doesn't have to cross the ocean twice. It also saves on the bills incurred by all that trans-oceanic data transfer, which might not matter to you but *does* matter to your site admin and to the Australian gateway maintainers. -------------------- Subject: Reporting and tracking bugs. You should subscribe to comp.sources.bugs. Sometimes, when new versions of previously-published software is available, just patches are put out, usually in the form of shar files containing input for the "patch" program, new files, etc. Sometimes complete new versions are put out. Which method is used depends on the poster and the moderator. Minor updates must be in patch form and should update the patchlevel.h file. Major updates should follow the guidelines for initial postings. To report bugs, contact the person listed in the Submitted-by: header. Often there is a contact address in a README file, too. I *do not* maintain the sources I moderate, so don't send your bug reports to me. That just forces a delay in the right person getting them as I will forward them on to the author. Likewise, I normally do not post patches for a package from anyone except the author. If you have patches you would like to see included in the package, send them to the person listed in the Submitted-by: header. ------------------------ Subject: Newsgroup Status Information. You should subscribe to comp.sources.d. In some newsgroups, postings such as "I will be out of town..." and "What's in the queue to post..." have been posted as INF postings with an Archive-name: of /dev/null or .junk. I will not post these types of messages to c.s.misc due to the limited amount of time that information of this type is useful. I will post these kinds of messages to comp.sources.d as the need arises. In this manner, the informational c.s.d postings can expire as they should and will not be archived taking up disk space forever. -------------------- Subject: Accessing the archives The complete archives are fairly large; an average volume is 3.8 megabytes. There are several active archive sites around the net. I am currently trying to locate archive sites in Europe, Asia and Australia. If you are interested *please* contact me. Some sites below will send tapes through the mail. For those sites, send a 1/2" mag tape WITH RETURN POSTAGE and RETURN MAILER. Tapes without postage or mailer will not be returned. No other methods (COD, etc.) are available; please don't ask. There a couple sites that provide email access to their archives. Please use them when you need to locate a missing issue. Please don't ask me for missing issues, unless you are sure you are reporting a net-wide problem of propagation. At the end are detailed instructions on how to access the archives. More sites will be listed there in the future. I have access to archives here at Sterling. I do not have ftp or email archive access available at the present time. I have as complete a set of archives as I have found. I have all the issues listed in the indexes except for the first volume. If you have articles from volume 1 please send me a list of articles so I can see if there are some I do not have. If anyone has an article that was posted to the group that is not listed in the indexes, please send me the information and a copy of the article so that I can update the archive sites that I maintain. Nothing from April and May 1987 was ever archived to my knowledge. If I'm wrong, send them my way... I am willing to contribute a tape to a site on the internet that is willing to make the archives available. Submissions prior to July, 1987 have no auxiliary header information at all. At the time, the group's original charter was in full force, and archiving was not considered to be important. These articles may be assigned auxiliary headers in the future, but for now ... -------------------- Subject: Archive access via ftp If an archive site provides "anonymous FTP" access, sites directly on the Internet (that is, sites possessing an IP address, which looks like four small numbers separated with periods) can use the "ftp" program to get at sources. Sites which aren't on the Internet (more properly, the NSFnet) can not use ftp to retrieve this information. And no, having the ftp program does not mean that you can access NSFnet: there are many systems which use TCP/IP over local networks only, and at least one brand of system which has a program called "ftp" that has nothing to do with the Internet at all. You should check with a local system administrator to find out the details of using ftp. On most systems and to most archive sites, the following will work: type the command "ftp system.domain" (example: "ftp uunet.uu.net" -- case does not matter), enter "anonymous" when it asks for a user name, and enter *your* Internet address for the password. If "ftp" says that the system doesn't exist, check your spelling -- if the system name is spelled correctly, look for an IP address for the archive site and badger your system administrator to install a version of ftp which knows about nameservers. You should also be warned that some systems (like uunet) will not accept FTP connections from sites not registered with a nameserver. Once you are logged in to the archive system, you will get a prompt that looks like "ftp>". (It may not be identical, since it is possible to change the ftp prompt with a command in many versions of ftp.) At this point, you can use "cd" to change directories, "ls" or "dir" to list files, and "get" to retrieve them. For sources archives, it is not necessary to worry about file types unless the files are compressed; in that case, you must use the "binary" command for Unix or VMS hosts and "tenex" on Tenex (TOPS-10, TENEX, TOPS-20/TWENEX) hosts. *** Not switching the file type can result in a garbled file, especially on Tenex hosts, which do not store binary data the same way as Unix hosts. *** To disconnect from the archive site, enter the "bye" command. -------------------- Subject: Archive access via uucp UUCP archives aren't quite as standardized as FTP archives; check the archive list for the user name and password to use, and ask your system administrator to arrange to be able to poll the archive site. (If s/he/it refuses, you are stuck.) The "uucp" command is used to request files from a UUCP archive. Unlike FTP, UUCP does not (usually) do the transfer immediately; this is because most UUCP sites must be called over phone lines, so long-distance calls will usually be made in the early morning hours. Since you can't look around in the archives, you must know the pathname of the article to be retrieved. Most archives have an index file available via FTP; check the archive list in the next posting. It's a good idea to retrieve this file before getting anything from the archive, since things can move around without warning. The command to retrieve a submission looks like uucp -r archivesite!path/to/file "archivesite" is the name of the archive site, and "path/to/file" is the pathname listed in the archive index for that site. Please be warned that for security reasons, it is not usually possible to specify wildcards (?, *, [], or ~name) in the pathname. Also, while more recent versions of uucp allow a uucp command to traverse multiple systems (uucp -r systemA!systemB!file), for security reasons this is usually disabled. In both cases you won't find out until after the archive site has been called. -------------------- Subject: Archive access via email Some archive sites have mail servers that will accept mail from you and mail back files from the archive. There are no standards here; however, it's usually safe to mail a message containing the single word "help" to the mail server. Check the archive list for more information. IMPORTANT TO REMEMBER: Mail Based Archive Servers (MBAS) are there for the convenience of the community and are *easily* abused. Please do not request to have a MBAS send you GCC or X11R4. A good deal of this traffic goes through intermediate sites that have not advertised this service. You would be taking resources away that are not yours to take... -------------------- Subject: Extracting a retrieved archive member If the article came from an archive site, it may be compressed; if it was sent by a mail server, it may also be uuencoded. Compressed files have an extension of ".Z". Uuencoded files can be recognized by a line saying "begin 666 filename", followed by lines of what looks like random gobbledygook. (If a mail server splits a file into multiple parts, you may just have the gobbledygook. In this case, the server will include a message saying which part of the file it is, and will tell you how to combine them.) To extract a uuencoded file, give the command "uudecode filename". This will create a (binary, usually compressed) file in the current directory. To extract a compressed file, give the command "uncompress filename". The ".Z" extension will be removed from the file. The original, compressed file will be removed as part of this operation. After doing this, you should be left with a news article exactly as it is stored in the news spool directories. This file will contain a news header, a description (usually), and a "shell archive" ("shar"). Move to an empty directory (important!) and unpack the archive. Some systems have a command "unshar" to unpack these files; if yours does, use it. Otherwise, you can use an editor to remove the header, then just say "sh filename". I use a small (one line) shell script: sed '1,/^[#:]/d' $1 | sh which will handle anything (I hope!) in the comp.sources.misc archives. I do attempt to confirm that a shell archive contains nothing dangerous, but if you unpack as root and the archive removes your /etc directory or something equally unpleasant, I don't want to hear about it. Unpack shell archives as an unprivileged user. Once you've unpacked the archive, you're on your own. Keep the header from the submission handy, in case you can't figure out what's going on; the address in the "Submitted-by:" line can be used to contact the author of the program. ------------------------ Subject: Becoming an archive site If you collect comp.sources.misc postings and are willing and able to make your collection available to other people, please let me know. Benefits include the undying gratitude of your colleagues, and a promise from me to try to make sure you never lose an article whether you use rkive or not... :-) I am currently looking for archive sites outside the US. If you can provide access to your archives send me some email and I will get you some publicity... :-) If you need automated tools to build and maintain your archives, I have those too .. :-) If you need a tape of the archives to get you jump-started, let me know. PLEASE NOTE: Mail Based Archive Servers (MBAS) are there for the convenience of the community but are too easily abused. Because of this, I can not, in good conscience, list archive sites whose *sole* access is mail based. If you can't supply anonymous ftp as a secondary method for accessing your archives then consider uucp. It is easy enough to set up a uucp account for archive access with the appropriate security to protect your other system resources. -------------------- Subject: Listing of archive sites in no particular order Here is what each field means: Site: The name of the site nice enough to act as an archive site. Contact: The name of the person to contact and their mail address Location: The general area of the world the site is located in. Modems: For providing UUCP access, what types of modems are available. UUCP: Type of UUCP access is available. FTP: Type of FTP access is available. Mail Server: Account address of the automated mail server if available. Additional: Additional information pertaining to accessing the archive. NA - Not Available ************************ U S A - EASTERN ************************ Site: schizo.samsung.com Contact: Andy Rosen (rosen@samsung.com) Location: Andover, MA Modems: NA UUCP: NA FTP: Anonymous Mail Server: None Additional: Files are stored by volume number, archive name and are compressed. Volumes 1 through 6 and 11 through 15 are present. Examples: /pub/usenet-archives/comp.sources.misc/volume15/fb/part01.Z /pub/usenet-archives/comp.sources.misc/volume6/gone-2.0.Z Site: slug.pws.bull.com [128.35.10.203] Contact: Warren Lavallee <warren@pws.bull.com> Location: Billerica, MA. (NEARnet) Modems: T2500 UUCP: NA FTP: anonymous ftp 24 hours day. limit 6 users at a time Mail Server: NA Additional: Due to internal restructuring, this site may not be accessible some times over the next month. Carry FULL comp.sources.* archives (since the beginning). Usenet archives are currently taking 170M. Site: uunet.uu.net Contact: Kent Landfield (kent@uunet.uu.net) Location: Fairfax, VA Modems: Telebit UUCP: uunet uucp customers only FTP: anonymous ftp Mail server: netlib@uunet Additional: UUNET is keeping archives in ~ftp/comp.sources.misc, and I will be maintaining them. Volumes 1 and 2 are not available, and some earlier versions of programs have been removed due to space considerations. You can also use 1-900-GOT-SRCS to access this archive. ************************ U S A - CENTRAL ************************ Site: sparky Contact: Kent Landfield (kent@sparky.imd.sterling.com) Location: Omaha/Bellevue, NE Modems: Telebit UUCP: On request FTP: NA Mail server: NA Additional: Tapes made on request Site: sir-alan Contact: mikes@iuvax.cs.indiana.edu (812-855-3974 days 812-333-6564 eves) Location: Bloomington, IN Modems: Telebit (812-333-0450) UUCP: Anonymous uucp FTP: Coming.. Mail server: NA Additional: Archive site for comp.sources.[games,misc,sun,unix,x], some alt.sources, XENIX(68K/286/386) uucp-anon: ogin: nuucp password: anon-uucp uucp-anon directory: /u/pdsrc, /u/pubdir, /u/uunet, help in /u/pubdir/HELP Site: wuarchive.wustl.edu [128.252.135.4] Contact: Wuarchive Maintainers <archives@wugate.wustl.edu> Location: Saint Louis, Missouri. Connected to MIDnet Regional. UUCP: Subscription UUCP access available ($300.00/year flat fee) Modems: Telebit Trailblazer Plus and T2500. FTP: Anonymous FTP. T1 connectivity - 24 hours/day, 7 days/week. Mail Server: NA Additional: Access during all hours is encouraged. Plenty of available bandwidth. Wuarchive has everything! :-) :-) ************************ U S A - WESTERN ************************ Site: aeras Contact: Rob Simon (simon@aeras) Location: San Jose, CA Modems: 1200, 2400, Telebit UUCP: Anonymous FTP: NA Mail server: NA Additional: SnailMail tapes (Under duress) Systems/L.sys information: aeras Any 1200 4089439152 "" "" ogin:--ogin: uugarch word: freebee aeras Any 19200 4089439246 "" "" ogin:--ogin: uugarch word: freebee aeras Any 2400 4089439396 "" "" ogin:--ogin: uugarch word: freebee Suggested places to get additional information: /u3/archive/sources/LISTING LISTING contains the names of all the programs stored in the archives, and the sizes. Note: all archives have probably been stored in compressed form, with 12 bit compression (for machines that can't handle 16 bit). All multiple file programs have been stored in separate directories, then compressed. More information about the files stored in a particular volume are kept in files called LOGFILE. Such as: /u3/archive/sources/x/vol1/LOGFILE would be the one to get to examine the exact contents of volume 1 of the x section. Additional information from files: sample command to recover files: uucp aeras!/u3/archive/sources/games/vol1/LOGFILE /tmp/. Special note: wild cards have been proven to not be reliable, so to assure success they are not recommended tools. Site: lll-winken.llnl.gov (128.11514.1) Contact: Joe Carlson (carlson@lll-winken.llnl.gov) Location: San Francisco, CA Modems: NA UUCP: NA FTP: Anonymous FTP Mail Server: Account address of the automated mail server if available. Additional: Articles are stored by X-Archive: index in subdirectories of comp.sources.misc/volN. Note that these archives start from 9/87; anything from April to August isn't available. *NOTICE*: lll-winken is not permitting anonymous FTP for the time being. The archives are temporarily available on polaris.llnl.gov, 128.115.14.19. ************************ Australia ************************ Site: ftp.Adelaide.EDU.AU [129.127.40.3] Contact: Mark Prior <mrp@ITD.Adelaide.EDU.AU> Location: The University of Adelaide Adelaide, AUSTRALIA Modems: NA UUCP: NA FTP: Anonymous ftp, ftp.Adelaide.EDU.AU [129.127.40.3] Mail Server: NA Additional: Also available via ACSnet fetchfile (sirius.ua.oz) The comp.sources.misc archive is in the subdirectory pub/sources/misc and is archived in compressed form by issue number (subdirectories for each volume). The file INDEX in the pub/soures/misc directory lists the issues available. We will also make tapes (1600/6250bpi) or QIC-11/24 if you supply the tape AND a return mailer. No promises for speed for this though. ************************ Canada ************************ Site: array.UUCP Contact: Rob Marchand, rob@array.UUCP || ...uunet!attcan!lsuc!array!rob Location: Toronto, Ontario, Canada Modems: 2400 baud, perhaps TB in the future (hopefully :-) UUCP: On Request. FTP: NA Mail Server: NA Additional: I have most stuff for comp.sources.unix, comp.sources.misc, comp.sources.bugs and alt.sources. ************************ France ************************ Site: irisa.irisa.fr Contact: Didier Lamballais (lamballais@irisa.fr) Raymond Trepos (trepos@irisa.fr) Location: Institut de Recherche en Informatique et Systemes Aleatoires Campus universitaire de Beaulieu 35042 Rennes Cedex FRANCE UUCP: NA Modems: NA FTP: Anonymous FTP (login: ftp or anonymous, Password: your e-mail address) Mail Server: NA Additional: Additional information pertaining to accessing the archive. List of archived newsgroups : alt.sources, comp.binaries.atari.st, comp.binaries.ibm.pc, comp.binaries.mac, comp.sources.atari.st, comp.sources.games, comp.sources.mac, comp.sources.misc, comp.sources.sun, comp.sources.unix, comp.sources.x, comp.sys.sun under "News" directory. Some local stuff and RFCs are also available. -- Kent Landfield INTERNET: kent@sparky.IMD.Sterling.COM Sterling Software, IMD UUCP: uunet!sparky!kent Phone: (402) 291-8300 FAX: (402) 291-4362 Please send comp.sources.misc-related mail to kent@uunet.uu.net.