v20INF1: Introduction to comp.sources.misc
Kent Landfield
kent at sparky.imd.sterling.com
Tue May 21 02:28:59 AEST 1991
Submitted-by: Kent Landfield <kent at 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 at uunet.uu.net
or kent at 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 at 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 at uunet.uu.net" or to "sources-misc at sparky.imd.sterling.com".
Newsgroup-related mail that is *not* a submission should be sent to me at
sources-misc-request at uunet.uu.net
or
sources-misc-request at 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 at 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 at 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 at 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 at uunet.uu.net)
Location: Fairfax, VA
Modems: Telebit
UUCP: uunet uucp customers only
FTP: anonymous ftp
Mail server: netlib at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at irisa.fr)
Raymond Trepos (trepos at 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 at 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 at uunet.uu.net.
More information about the Comp.sources.misc
mailing list