Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/misc/volume10/v10welcome

Text File | 1990-01-06 | 24KB | 465 lines

Newsgroups: comp.sources.misc
From: [e-mail] (Brandon S. Allbery)
Subject: v10INF1: Welcome to comp.sources.misc! (Last changed: 11/4/89)
Organization: UUNET Communications Services, Arlington, VA
Expires: 6 weeks
Sender: [e-mail] (Brandon S. Allbery - comp.sources.misc)

Posting-number: Volume 10, Administrivia 1
Submitted-by: [e-mail] (Brandon S. Allbery)
Archive-name: v10welcome

[No changes.  ++bsa]

This is the first of three messages comprising the periodic Welcome! posting
for comp.sources.misc.  Hopefully, any questions you have will be answered
here; if they are not, send mail to me (comp-sources-misc-request@<backbone>),
the moderator.


                > Introduction <

Comp.sources.misc is sort of a "catch-all" sources group.  The intent is that
small sources, non-Un*x sources for which no newsgroup exists, and sources
which the moderators of comp.sources.unix and comp.sources.games will not
accept can be sent here.  This does not mean that large Un*x sources will not
be accepted, but they will probably gain a wider distribution if they are sent
to comp.sources.unix.  They also slow down the flow of sources through this
newsgroup to some extent.

As a result, the group will be run in an informal fashion.  In general, *any*
program source code will be accepted, but 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.)

This newsgroup isn't intended to be a high-volume one, since the "big" stuff
should be sent elsewhere.  Of course, if I'm sent a 50-part submission like
jetroff, the volume goes up a bit....  However, it is to be hoped that people
still have the desire to post their favorite prompt generators, integer square
root algorithms, etc.


                > Why moderated? <

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.  Mail I have
received indicates that the majority of people are willing to trade the small
delays (mainly caused by network delays in mail) for having a source group
that isn't full of noise.

As stated above, the only reason a submission will be rejected is if it is a
non-source.  I, as the moderator, am striving to get things out as quickly as
possible while not posting non-sources; testing is not done.  If it's
something that's worth testing, it probably belongs in comp.sources.unix
instead.  (Send submissions to comp-sources-unix@<backbone> in that case.)
Testing may be done in the future, but shuffling sources between machines to
test it can be difficult and trying, and in any case if it wants e.g. a Sun
console there's not a whole lot I can do about it.


            > Why comp.sources.misc? <

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 benefitted 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 I adopted a policy of letting the group be controlled more by its users
(submitters, readers, archivers) than by "moderative fiat", to coin a
phrase.  The policy worked quite well, but caused the newsgroup to drift
closer to the style of a regular moderated sources group.  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 "where are our Soviet friends?" postings;
the disadvantages are that there is a delay caused by having to filter stuff
through me, the moderator, and that submissions that aren't in the de-facto
"standard" format will get held up while I make them so.

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:  tiny programs and beta-test
copies of larger programs are often sent to alt.sources, small "released"
programs or beta-test copies of major programs often go to comp.sources.misc,
and released major programs usually go to comp.sources.unix.

There are, of course, other alternatives.  Games usually are sent to
comp.sources.games regardless of their size, and programs which are specific
to a particular computer might be better off in a specialized sources group
like comp.sources.sun.  However, it's up to the submitter to decide to which
newsgroup a submission should be sent.


          > Guidelines for fast processing of submissions <

The readers of this newsgroup would prefer that posters follow certain
guidelines.  Not following these guidelines may result in long 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, a Subject: header should *always* be included in a 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, but (more importantly)
inews, the driving program for the Usenet news system, will not accept
articles which lack a subject line.  (Yes, I know about C news.  Do *you*
know about RFC1050?)

Fourth:  The proper submission address for ANY moderated newsgroup is of the
form:

            newsgroup-name@backbone-site

The newsgroup name uses hyphens as separators, not periods (sendmail does not
appreciate the periods); "comp-sources-misc" is an example.  Backbone sites
are the major news feeds (excepting att.att.com, which does not pass mail)
which serve large areas.  (No, ncoast isn't one.  (Yet.)  UUNET is.)  Be
warned that some backbone sites may use "sources-misc" instead of
"comp-sources-misc"; there was some confusion about it at the inception of
comp.sources.misc.

Newsgroup-related mail that is *not* a submission should be sent to the same
address as above, with "-request" added to the newsgroup name; for example,
"[e-mail]".  Please do not send them to the
submission address.

Please do NOT send sources to *any* of my regular mailboxes.  This will cause
possibly long delays while I reroute the mail to the proper address (which
may well be on another machine) -- and since I use MH on most machines and
UUNET doesn't have MH, I have to do extra work to unpack the forwards on
UUNET.  Note that since ncoast's free disk space is never large, it is
possible for large submissions sent to my mailbox on ncoast to be lost along
with any other submissions or ordinary news and mail traffic.  (This is
changing, yes... for now.  However, every system administrator knows that
users expand to fill all available disk space; the present situation on
ncoast is temporary.)

In particular, please do not address submissions to ncoast!allbery or *any*
address on ncoast (NCoast.ORG):  comp.sources.misc no longer lives on ncoast,
so your submissions will have to be forwarded -- and the sources-misc aliases
have been removed from ncoast's mailer, so anything sent to those addresses
will be bounced by ncoast's mailer.  It's only been 8 months since the group
moved to UUNET; by now, I would hope that everyone knows about it.  Also,
sending to [e-mail] looks good now, but it could change overnight
if I become unable to moderate comp.sources.misc for some reason.  Use the
proper aliases on the backbone machines.

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.


               > Special services <

Now, after all the "thou shalt/thou shalt not"'s, here's some optional
services to compensate for some of the restrictions outlined above.

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,
[e-mail] 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.


               > Patches to sources <

There are now de-facto guidelines for the handling of "patches" (fixes) to
source postings in moderated newsgroups.  Unfortunately, I'm still working on
implementing them; at the moment, I'm a bit tied up with moving "ncoast" to a
new machine.  I hope to have them working soon.

Patches to source programs should be posted to comp.bugs.misc (no, the group
is *not* directly related to comp.sources.misc!); official patches should be
sent out only by the author of the original program (unless special
arrangements are made with the author) and should also be sent to
comp.sources.misc.  They should be posted as "context diffs", if at all
possible; Berkeley-based systems have the "-c" option to the "diff" command
to do this, and for AT&T-based systems there are commands available to
translate "diff" output to context diffs.  Check the Indexes to
comp.sources.misc and comp.sources.unix.  The use of context diffs allows
patches to be applied to sources which have had local modifications to aid
porting, etc.

Official patches will be posted as "archname/patchNN" for multi-part
submissions and as "archname.pNN" for single-part submissions.  This is a
temporary arrangement only; in the future, single-part submissions will be
posted as "archname/submission" and patches will be posted in the same way as
for multi-part submissions.  At present, there is no special header line for
patches, but a Patch-to: header will be implemented in the near future to aid
in locating the submission to which a given patch applies.

Patches are applied with the "patch" program.  It is also possible to apply
patches by hand, if the "patch" program is not available; it's adviseable to
look for "patch2" in the comp.sources.unix archives, however.

In the future, I will be adding automatic version tracking to the archive
mechanism as well.


                  > Archiving <

UUNET is now (at least, for the moment) an archive site, so the contents of
this newsgroup all the way back to July 1987 are available.  (Nothing earlier
was archived or was even assigned archiving information.)  I add archive
headers to posted submissions, suitable for manual or automatic archiving and
archive retrieval.  The archive Index is posted each month as part of the
Welcome! posting; it should follow this posting.

The format of the archive header is:

    Posting-number: Volume 2, Issue 45 Submitted-by: "user-full-name"
    <address> Archive-name: name

For administrative postings, the Posting-number: header looks like

    Comp.sources.misc: Volume 2, Administrivia 2    for administrivia.

These headers are often referred to as an "auxiliary" header, since it is
considered to be part of the message body by the news-posting software.

Each posting has an Archive-Name, which is a single word of (generally) 6-8
letters which tries to be somewhat descriptive.  You may want to use this
instead of the volume/issue number.  However, the local article number should
*not* be used; it is dependent on the order in which articles are received
and when your local system began receiving them, and is guaranteed not to
match the numbers on uunet, ncoast, or many other systems.

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.  (Read:  I was still trying to
cling to the last remnants of the group's original charter....)  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.  This must be used to retrieve submissions from 1987,
although work is being done to add standard archive headers to these
articles.

Submissions prior to July, 1987 have no archiving information at all.  At th
time, the group's original charter was in full force, and archiving was not
considered to be important.  These articles will also be assigned archive
headers in the future, but for now the only way to retrieve these postings is
to search each individual file.

A list of archive sites is included in the second part of this posting.  It
should be noted that this newsgroup is *not* gatewayed to WSMR-SIMTEL20; if
it is for some reason important to have a submission archived there, use
comp.sources.unix or a specialized sources group.


           > Okay, so how do I get at archived submissions? <

It varies.  Moreover, it is likely to be changing in many cases, as larger
UUCP sites gain direct Internet access and the Internet itself moves (slowly)
to OSI (GOSIP) compliance; and arrangements outside the U.S. are pretty much
outside my control and knowledge.


                   > Using "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
adminsitrator 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.


                > Using 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 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 travrse 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.


                 > Mail archives <

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.


                 > Other archives <

I know that there are equivalent commands for OSI-compatible networks (FTAM),
CSNet and Bitnet; I do not know how to use them.  Check with your system
adminsitrator first for local commands, then send mail to the archive
maintainer on the archive site.


           > Now that I have an article, how do I use it? <

If it 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.


               > Closing words <

Following this message should be a "shar" file containing the archive list
and an index for each volume of the archives.  More information on archives
is included within the posting, with specifics and contacts for known archive
sites.  If your site archives comp.sources.misc, please let me know -- it's
always nice to know who's keeping it, and I don't know of many archive sites
outside the U.S. as yet.

You now know enough (I hope) to be able to get some use out of this
newsgroup.  If you have any questions or suggestions, send them to the
request address mentioned earlier in this article; I also participate in
discussions about moderated sources newsgroups in comp.sources.d.

Have fun and happy hacking!

++Brandon, your friendly neighborhood comp.sources.misc moderator.