Comp.binaries.cbm FAQ

 

Archive-name: commodore/binaries-faq/part1
Version: 4.5
Last-modified: 1999/6/22
URL: http://stockholm.ptloma.edu/comp.binaries.cbm/
Copyright: (C)1999 Cameron Kaiser

 

COMP.BINARIES.CBM Official Frequently Asked Questions (FAQ)V4.5
---------------------------------------------------------------

written by Cameron Kaiser <ckaiser@stockholm.ptloma.edu>

based on a document by William Ward

 

** START OF FAQ **

 

0. Introduction

 

This is the Frequently Asked Questions guide for the newsgroup

comp.binaries.cbm (hereafter c.b.c). People are urged to consult this guide

before asking questions of the moderator(s) or posting them to the appropriate

discussion group, as doing so may answer your query much more quickly and in

such a manner that you do not collect mail along the lines of 'read the faq,

you blithering idiot' or significantly more unmentionable versions thereof.

 

This FAQ was written by Cameron Kaiser, who based it on an original draft

by William Ward, who based *that* on a draft by Michael Miller, and no one

knows where his came from.

 

| NEW CHANGES IN THE FAQ ARE DOCUMENTED with a | symbol in the first column.

| WATCH FOR THEM.

 

The humor in this FAQ is totally intentional. Posting to the group about

what a putz the author is will be ignored, mostly by the author.

 

0.1 Where to get the FAQ from

 

This FAQ is posted 'periodically' to c.b.c. You can also ask the author for

a copy. See 'Contacts' for addresses. You can also find it posted around the

same time to alt.c64 and comp.sys.cbm.

 

| A mini-FAQ appears frequently issuing and detailing the most common errors

| and announcements. Important extracts from these mini-FAQs will eventually

| appear here.

 

Jim Brain tells me that this FAQ is now available in ftp.jbrain.com under

/pub/cbm/faq/. The filename should be obvious. Make sure you get the latest

| version. I'm not sure if this is still the case given the recent demise of

| his jbrain.com domain, but if not now, it will be soon.

 

You can find the FAQ online at

http://stockholm.ptloma.edu/comp.binaries.cbm/

It is currently plaintext. I'm working on an HTML version.

 

1. General Notes about c.b.c

 

1.1 What c.b.c is

 

c.b.c is a newsgroup for the posting of Commodore related binary files.

By Commodore we refer to the 8-bit systems. Amiga binaries (excepting those

that have direct pertinence to the 8-bits) are NOT accepted and you should

send those to the analogous group.

 

c.b.c is MODERATED. If you post to this group, it will not automatically

appear. You should not send posts to the group along the lines of 'where the

#$%@!# is my post?' because we will ignore them. Plus, you'll look silly and

we will post you to our list of people to laugh at for not reading the FAQ.

If your post does not appear, we have not approved it. If your post never

appears, we never approved it. You should read under 'What we don't post'

for why.

 

If you don't know how to post, refer to the section on (ta-da!) 'How to

post'. Even if you do, it will save us some grief if you read it anyway.

 

As with all moderated groups, your posting is not actually sent through Usenet.

Instead, it goes via E-mail to the moderators, and you should send your post in

an appropriate manner. (If you want to E-mail directly, see 'Contact list'.)

You should also refer to 'c.b.c courtesy' for how to get your post approved

faster. If you help us, we'll expedite things for you. If things are difficult

for us to do, it will take us longer, or not at all.

 

1.1.1 The c.b.c charter

 

This is the abridged charter. The full version can be found at

 

ftp://ftp.uu.net/usenet/control/comp/comp.binaries.cbm

 

comp.binaries.cbm is a moderated newsgroup which passed its vote for

creation by 170:24 as reported in news.announce.newgroups on 22 Sep 1993.

 

>For your newsgroups file:

comp.binaries.cbm For the transfer of 8bit Commodore binaries.

(Moderated)

 

The newsgroup is for the purpose of swapping 8bit Comodore Binaries,

mainly mainly for the 64 and 128 computers. The moderator will attempt

to filter out copyrighted software, and insure that the programs work,

although it is impossible to verify all software for all systems.

 

1.1.2 Why c.b.c is necessary

 

c.b.c is necessary because the comp.* hierarchy, with approximately two or

three exceptions, is discussion only. It is standard protocol to only post

binaries to comp.binaries.* groups, hence the motivation for creating this

group. This is not unique to the comp.* hierarchy; alt.binaries.* exists for

identical reasons.

 

Binary postings have started to appear in the comp.sys.cbm newsgroup in

spite of this fact, and they are subject to bincancel, not only by newsgroup

readers, but also by bincancel bots (such as Rich Depew's) and news admins.

Binaries in discussion-only groups also introduce serious breaches of

netiquette, discussion of which is beyond the scope of this FAQ. The reader

is invited to read any of the cancel and netiquette FAQs, routinely posted

to news.admin.net-abuse.usenet, news.admin.net-abuse.misc and easily found on

DejaNews and AltaVista.

 

1.1.3 Moderators

 

The list of moderators fluctuates wildly. Cameron Kaiser, the author of this

FAQ, is a moderator. There are also other moderators on c.b.c, but the

list of active moderators seems to get out of date quickly.

 

It is therefore best to mail the moderators collectively, versus

individually. See 'Contacts'.

 

1.1.4 c.b.c On-Line and via FTP

 

c.b.c now has an official webpage and the most current submissions are also

archived/kept at Videocam in Australia.

 

The c.b.c webpage is

 

http://stockholm.ptloma.edu/comp.binaries.cbm/

 

On the webpage, you can see what the most recent submissions were (for use

with threatening your newsadmin, see Troubleshooting), get a current copy of

this FAQ for bathroom reading, and also find out about submission policies,

moderators, etc. Also on the c.b.c page is a very trivial uudecoder which

will do in a pinch (it's BASIC 2.0, so don't expect too much) if you can't

get Fuzzy Fox's uuxfer (q.v.) to work.

 

If you prefer to get your files via FTP, Rod and Gaelyne Gasson at VideoCam

in the lend daun undaa have graciously offered their FTP server as a

repository for the most current c.b.c files (old postings are then archived

under the regular directory structure). Allow some time for the postings

to reach them first.

 

ftp://videocam.net.au/cbm/incoming

 

There's no /pub in that address. Common pitfall. Watch out.

 

1.2 What we post

 

c.b.c posts any and all binaries related to the 8-bit Commodore that do not

fall along the lines of what we *don't* post (q.v.).

 

Some examples: shareware games (unregistered); freeware; demos; public

domain games, utilities, etc. In other words, freely available software

with unrestricted distribution will be accepted.

 

In the past, emulator-related binaries were not accepted to this group. While

they are not encouraged, as a significant number of c.b.c's readers don't

have personal access to anything but 8-bits (which frequently cannot handle

emulator formats without external conversion), they are now accepted to the

group. However, if there is a straight binary version of a file as opposed to

a .d64 or .p00, we exceedingly prefer it.

 

Binaries intended for other target systems, such as PC executables, are

accepted only if they have relevance to Commodore systems. Examples would

include emulators and converters.

 

The head moderator (me) is a lazy bum, so most postings occur in large blocks

usually on Mondays or Tuesdays (Pacific time).

 

1.2.1 What we re-post (One From The Vault)

 

Periodically, we also re-post previous submissions that we deem of particular

interest, or ones that are requested frequently. The "One From The Vault"

postings occur at sporadic intervals, sort of a best-of-comp.binaries.cbm

selection mix. If you have suggestions about something you would like to

see reposted, notify the moderators.

 

1.2.2 How to download what we post

 

Most newsreaders are smart enough to uudecode the post automagically.

Chances are your PC or Mac newsreader already has downloaded and archived

the post before you even saw it. Check your newsreader's documentation.

 

Un*x shell newsreaders assume some intelligence on the part of the user.

Some will automatically decode the post; others won't. You'll need to check

your newsreader's documentation, but this method will always work:

 

* Save the post to a file on your shell account. (For nn, press 's'.) See

your newsreader's documentation.

 

* Get to a shell prompt (usually something like % or $). If you see #, the

first thing to do is type 'rm -rf /' to make sure you have plenty of

space. (Just kidding.) You may have to quit your newsreader or press

CTRL-Z to get to a shell prompt.

 

* Type 'grep ^begin <filename>' where filename is the name of the file you

saved the post to. Don't type the angle brackets and don't forget that

carat. You'll probably see something like this:

 

% grep ^begin really.cool.post << You typed this

begin 644 program.prg

 

There may be some other junk lines in the file; just look for one that

resembles this one.

 

As you can see from the above example, program.prg is the file that will

be created by the uudecoder. To create that file from the uucode, type

'uudecode <filename>', again substituting the post name without the angle

brackets (our example would be 'uudecode really.cool.post'). If you see

something like 'uudecode: short file', you didn't save the post properly.

Go back to the beginning and try again.

 

* Use the sx, sb or sz utilities (Xmodem, Ymodem and Zmodem respectively) to

download the created file to your terminal program. Usually the command is

'sx <filename>'; our example would be 'sx program.prg'.

 

* Resume your newsreader. If you used CTRL-Z to get a shell, you'll probably

type 'fg' to get back to it.

 

If you're all thumbs with this process, you can still get the most recent

postings via FTP. See section 1.1.4. Explaining FTP, however, is beyond the

scope of this FAQ; most ISPs offer assistance with FTP transfers, and most

web browsers support FTP, though.

 

1.3 What we don't post

 

We do not post:

 

* non-binary items. Spam is deleted. Discussion is deleted. People

writing us about why no one discusses anything in this group get deleted.

Et cetera.

The exception is the FAQ, naturally.

So where should you post if you want to talk about Commodore 8-bits?

A good question. Refer to:

 

comp.emulators.cbm

comp.sys.cbm

alt.c64

 

All of these, in particular the first two, have active discussion.

Talk on them. We'd love to hear from another 8-bit fanatic.

 

* binary items not relevant to the 64. UUencoded JPEGs of your pet

wonderdog Snotbrain whizzing on Mrs. Eagleson's petunias get deleted. And so

on.

 

* 'warez'. Cracks, hacks, etc. are NOT allowed. The old argument

that 'it's 10 years ago, the copyright doesn't matter' is hogwash. Someone

still has the copyright, even if they're not enforcing it, and we don't want

to be on their lawyer's target list if they decide to enforce it suddenly.

(Want an example? Okay. Three words: Activision fifteen pack. Case closed.)

Freeware and shareware versions of products are exempt because they are

explicitly freely distributable, in contrast to ...

 

* restricted distribution products. This is a fancy way of referring

to 'stuff that shouldn't be publicly distributed', and includes things such

as registered versions of shareware or beta tests that are not intended for

the public. Moreover, if there's a restriction on the software's distribution,

it's probably heavily copyright-protected too ... see 'warez'.

 

* programs not intended for all audiences. For example, posting a

nudie slide show for the 64 here would not be appropriate, and it would

never be approved, even if it *were* in the public domain and freely

distributable. This is not comp.binaries.erotica.cbm. You may think this is

a silly thing to say, but there are some of these demos around.

 

* things that don't work. Garbled submissions don't work. Make sure

your uuencoded file didn't get truncated. Make sure your mailer didn't eat

characters or add new ones, because on our end it looks like hell. IF YOU MUST

MAIL US YOUR POST, PLEASE see the section on 'How to post by mail' to get

around this problem.

Most importantly, however, if it don't work, it don't post. If we

can't get it to run, odds are most people who read this group won't either.

 

* anything we decide not to post, at our discretion. Some people have

claimed we're ignoring their posts because we don't like them. Tough orange

peels.

 

1.4 What happens if you post something we don't post

 

Nothing.

 

Yes, nothing. You will get no response from us, ever.

 

In the past, the response was to notify you that we did not accept your post,

and to send you some appropriate reason why. In this day and age of rampant

spammage and people who blindly post insulting things instead of reading FAQs,

that is an insurmountable task. Therefore, if you do not get a response to your

post WITHIN A SUFFICIENT INTERVAL and/or your post never appears on the group,

we did not approve it.

 

If you have trouble with your newsreader, and want to know if your post

came through, please state you want confirmation in the message body. We will

confirm only in cases where we have a serious posting. If you post 'why aren't

my messages posting somebody please respond' you will get a resounding fat

load of nothing returned to you. However, if there's a possible submission

attached to your polite and understanding request, we would be happy to tell

you that it got there in one piece. Do not, though, assume that a lack of

response indicates bad connection and therefore multiple reposting, because

this will not endear yourself to the moderators and collect you many four-

letter words. Ask first before you send that 2.5MB file again.

 

If you do get a message back from us, we probably just need a small extra

thing from you, like a description. Please read the note and comply; upon

your doing so, you will be the proud parent of a new post.

 

The phrase 'WITHIN A SUFFICIENT INTERVAL' has been cap'ed for a reason. It

takes time to check through a submission, first to receive it, then to test

it and then for the final post (if any) to percolate through the fibrous

wire mishmash of Usenet. Please respect the fact it may take as long as a week

to finish this process -- we have lives of our own, and we do this out of

our free time. Therefore, not seeing your post immediately does in no way

imply open and extremely prejudical rejection.

 

1.5 What happens if you post something we post

 

We post it.

 

If appropriate, we will notify you (usually 'thanks!'), but in most cases

you will know your post has been approved when you see it in the group. It is

good form to make sure your newsreader does in fact see this group.

 

If you want confirmation, say so. See above for conditions on that. Remember

that sending confirmation messages is not guaranteed.

 

1.6 c.b.c courtesy

 

Good things to do that make things easy for the moderators:

 

* Use .sda or .sfx, or any other self-dearcing format. It's easy

for us because we don't have to crank up the dearcer. Lynx is especially bad

on this point, since there's so many versions, a lesson I have learned the

hard way with many people asking me why Ultimate Lynx doesn't understand

CWI's Lynx archives. (Answer: We use Lynx IV, and they're mutually

incompatible.) Failing that:

 

* Use a standardized arc format. I like .lnx best, but can tolerate

.arc. I find .lzh slightly exotic and .rar even more opaque. If you post using

Fritz Fluegelwagen's RLE-LZW-Huffman-Lynx encoder, something three people on

the planet use, the chances of my hitting delete in the mailreader increase

exponentially.

The one standard arc format you should avoid, if at all possible, is

ZipCode (the 1! .. 2! .. files.) These cause some irritation on my part, mostly

because I have to deal with four files instead of one. There are some

circumstances where ZipCode is needed, but most of them involve copy-

protection, which you find on (surprise!) copyrighted warez. See above.

If these are PC binaries, please please PLEASE use .zip. I HATE

unarj with a passion, and I don't like DOS tar or gunzip. I suspect the other

moderators have similar preferences.

But best of all:

 

* Don't arc. If you can avoid it, don't! That's best of all. Then

we can just run the stinking thing.

 

For clarity, preferred formats, from most preferred down, for Commodore:

 

.prg/.bin, .sfx/.sda/.spy/.sdl, .lnx, .d64/.t64/.p00, .arc/.lzh, .rar/.lbr

 

For PC/UNIX:

 

.zip/.infozip/.gz/.tgz, .Z, .arj

 

These are my preferences only and should not be construed as support for

any format or having any rational basis in fact. :-)

 

* UUencode. Don't Base64. This means refrain from using attachments.

Most Unix newsreaders don't understand MIME, and most of us use a Unix

newsreader. If you don't, please be kind to the large majority that do.

The only exception to this is if you use a MIME-enabled mailer, and in that

case you should read the section on 'How to post' BEFORE YOU POST!!!

 

* Document! You don't need to tell us how to turn the computer on,

but please do tell us what we're looking at, and what we can expect when

we run it. We can probably guess the rest. Accuracy helps. :-)

 

A NOTE ON DOCUMENTATION: Some people believe that documentation

consists of a single sentence saying 'this is a program for the (64|128|+4)'.

We can see that already. Documentation is telling us what the program is

supposed to do and what it needs to run, and this information is vital!

Steve Judd writes particularly nice documentation. Look for some of this

previous posts, if your news spool goes back that far (!).

If you are sending an archive of programs, like a freeware

archive, please describe each program individually and completely as if

you had posted each one separately. A nice paragraph about the archive

itself will probably not suffice. :-)

 

* Post your post instead of mailing to us. The reason is not that

we care how the post arrives, but that most modern mailers fiddle around with

files and add metacharacters and 8-bit encoding and the like. Most news

programs don't. Therefore, a post arrives more cleanly in general than does

the mail.

IF YOU MUST MAIL, PLEASE see the section on 'How to post by Mail'.

 

* Above all, remember that your post must be readable by the lowest

common denominator. Usually, that's us.

 

| 1.7 Things you should *never* do

|

| * Crosspost. Never ever crosspost. Announcements about your web site,

| whether or not it will resurrect the 64 to millions of waiting fans

| worldwide and usher in a new computing paradigm renaissance, are not binary

| and therefore not germaine. Announcements about service offerings you may

| be providing, or the software opus you're writing, are not binary and

| therefore not germaine. (But if you have a demo, why not post that?)

| Why am I picking on announcements? Announcements are, bar none, the single

| most crossposted crud I can think of. STOP IT.

| Moreover, it s a waste of time for you, because if I don't approve

| the post, or any of the other moderators, it won't appear in any of the other

| groups you've crossposted to either. And we're not going to strip the c.b.c

| group and and repost it for you. It's not our job.

| The problem is now of such an extent that c.b.c no longer accepts

| crossposts, even if they *are* on-topic. Sorry.

|

| * Use a hopelessly munged address. We're a fairly astute bunch of

| guys, and most mail munges are creative enough to be bot-foolers but still

| humanly decipherable, and we have no problem with munging per se. (Heck, I

| munge mine on a regular basis.) However, we have received submissions from

| "G@RT" (actual from address) that we needed more information on. Guess what,

| bucko? Into the bit bucket. If we can't contact you about your post, we will

| reject it.

|

| * Bite your nails. Don't do it, it's a nasty habit and you look funny

| gnawing on them like that.

 

2. Talking to c.b.c

 

2.1 How to post

 

2.1.1 How to post by newsreader (MOST preferred)

 

Simply point your newsreader to comp.binaries.cbm and post your document.

You should refer to your newsreader for the appropriate documentation. Make

sure it is uuencoded -- raw binaries never make it.

 

What will happen is that your post will be sent by UUnet to the moderators,

who will then review it. This method is most preferred because mailreaders

screw around with mail they send, particularly MIME-enabled mailers. Most

newsreaders don't. See above for the rest of the process.

 

2.1.2 How to post by mail

 

While we don't really encourage this, people do have trouble posting through

Usenet, especially if your only access is through DejaNews or the like. If you

really can't post by news, send your document to:

 

cbm-binaries at bayview.com

 

which is a mail alias generously provided by William Ward. If you use a

MIME-enabled mailer, DO NOT UUENCODE IT BECAUSE THE MAILER EATS IT! In this

case, and this case only, SEND IT AS AN ATTACHMENT. If the mailer is not

MIME-enabled, like mailx or early Elm versions, send uuencoded files as

usual.

 

As a point of clarity, if you intend to send your program as an attachment,

do NOT uuencode the program and send the *uucode* as the attachment. SEND

THE BINARY ITSELF! Also, try to give the attachment a semi-descriptive name.

We often strip out attachments in one big bunch, and a whole lot of similar

looking files makes it tough to match files with posts.

 

CompuServe seems to be problematic with uuencoded attachments. If you can

use 'NewMail', please do so. If you can't, please alert the moderators in

the message body that you're using CompuServe OldMail and we will try to

rescue the post. (Thanks to John Iannetta.)

 

2.2 Contacts

 

As mentioned, it is better to mail the moderators collectively. Posting

will have the same effect as mailing, but it's better to mail because we

can differentiate between the two.

 

The alias

 

cbm-binaries at bayview.com

 

will send to all members of the moderation team, including me.

 

If you wish to contact me personally regarding the FAQ or the large check

you'll send me or the attractive, unmarried sister you have, send mail to

 

ckaiser@stockholm.ptloma.edu

 

and I promise to ignore it for as long as I can, unless I really like your

sister or the check is good.

 

John Iannetta has promised me an attractive sister, but I think someone at

Federal Express routed the crate to the Sultan of Brunei.

 

2.3 Troubleshooting

 

2.3.1 'My post was approved, but it hasn't appeared yet'

 

If you know that we approved your post, there are several reasons why it

hasn't appeared yet. The only reason under our control is:

 

* We haven't injected it into the Usenet stream yet.

 

Normally, we post things as soon as we approve them, just to get them out of

our hair, so most of the time these reasons below apply. In such cases,

there's no one you can blame, unless you have contacts at WorldCom. Usenet

is a very haphazard mishmash, so patience is a true virtue.

 

* Your ISP's newsfeed is behind. If your ISP does not have a 24/7 NNTP

connection, it could take up to a few days for it to percolate your way.

 

* Bad Usenet routing. Some computer between us and you burped or did a nasty

thing. Either way, the post is the immediate victim. Have patience -- it

should start propagating with the computer's imminent resurrection.

 

* Our ISP stream is queuing up. I use Concentric, which is a pretty reliable

Usenet injection point. Some moderators might use smaller ISPs that don't

have a 24/7 NNTP feed, and so the actual injection step might be delayed.

 

2.3.1.1 'I post over and over, but you say my post never gets to you'

 

This is a problem to which I have only recently found a solution. Apparently,

certain news sites with semi-morons for news administrators do not properly

mark comp.binaries.cbm as a moderated newsgroup. When your news server is not

aware that c.b.c is moderated, it will post the message as if it were an

unmoderated group, and pass it to another server. When it gets to a server

that knows c.b.c is moderated and this server sees that your message doesn't

have the proper credentials, it will silently drop it. End result: the

moderators don't get your post, and your post goes to the great bitbucket in

the sky.

 

There are two (well, two and a half) ways to fix this:

 

* Mail your post all the time. Easier, but gets annoying.

 

* The better solution, though it will require some investment of time: tell

your news administrator to "update his/her active file with moderated NGs

properly marked." Mention c.b.c by name. Active files list all newsgroups

on a news server. If it's inaccurate, your newsreader will never know.

This will probably fix other moderated newsgroups on your server, and your

fellow users will greatly appreciate it, I'll wager. You may have to be

persistent about this, in the same way that Ken Starr is persistent about

White House interns.

 

* The half a solution: tell your ISP to jump in a lake.

 

2.3.2 'You keep saying my post is garbled'

 

If we said that, your post *is* garbled -- you probably mailed it and your

mailer ate it. We have a picture of Eudora Welty on our dartboard. I hit

a bullseye last week after someone sent their uucode as an attachment, and

Eudora promptly made "intelligent" [sic] formatting decisions that ruined it.

 

Do the following check list:

 

* If you have a MIME-enabled NEWSREADER, then you MUST MAIL YOUR POST.

If you don't, then post it UUencoded.

 

* If you have a MIME-enabled MAILER PROGRAM, then you MUST SEND THE BINARY

AS AN ATTACHMENT. If you don't, send the UUcode in your message body.

 

Most of the time, someone forgets to UUencode the program, or they sent

the UUcode accidentally as an attachment, and this is easy to reconcile.

If we complain about your post, we want it again. Please, resend it!

 

2.3.2.1 'But that didn't work!'

 

Failing that, you might have a peculiar program that just decides to chomp

your messages to death. We don't archive all the mailing programs in the

world to test your message with. I use Elm, and Elm exclusively, because

Eudora is Moloch and Microsoft Exchange is Satan. You might have different

opinions about the demonic potential of these mailer programs, but the

fact of the matter is any good mailer will have options to turn off its

special formatting and to do sane attachments. If it doesn't, get a new

mailer.

 

We are aware that CompuServe OldMail destroys postings en-route, and have

a semi-reliable way of rescuing them. Just mention you're using OldMail in

your message body, and we can probably save it.

 

2.3.3 'I can't read old postings in the group'

 

This is something you should take up with your ISP. Old news articles are

kept on your ISP's news spool for only a limited time, and most local ISPs

only keep posts less than a week old. I'm spoiled by Concentric, which keeps

posts up to a month. Odds are if you can't see prior postings, or get

'Cancelled or expired' messages, your ISP does not archive postings very long

and you should have a nice friendly chat with them involving physical harm.

 

There is no archive for c.b.c postings. Maybe there should be.

 

2.3.4 'I can't read this group at all!'

 

Your news administrator may have decided, for whatever reason, not to allow

binaries groups on his/her server. Usually this is a space consideration;

just think of how much space alt.binaries.erotica.extremely.big.jpgs takes

up on a news spool.

 

In such a case, you're pretty much left with two options: dropping by their

office with a cannon (illegal except in Libya), or telling them to allow

comp.binaries.cbm on their server or you'll find a new ISP. Vote with your

dollars -- it's your money.

 

2.3.4.1 'I can see some posts, but not all'

 

You have a flaky news spool, and your news administrator needs to get their

caboose in gear. Drop by this URL:

 

http://stockholm.ptloma.edu/comp.binaries.cbm/

 

and select What's playing on c.b.c this week. Confront them with this list.

Threaten pets or allege unspeakable acts with their next-door neighbor. Most

news administrators are guilty of that. You may also consider checking out

a new provider because if their news link is flaky, other things are probably

subpar in their service offerings as well.

 

3. Seriously

 

3.1 Disclaimer

 

Because of the sue-crazy nature of these United States, Bill Ward felt

compelled to write a legal disclaimer into the previous FAQ. So do I.

 

The use of programs posted on c.b.c is at your own risk. c.b.c moderators

cannot be held legally liable if a program published on this group, or the

(im)proper use of such a program, causes damage of a monetary, property or

personal nature. You agree to indemnify and hold blameless the moderators

in such an event. c.b.c cannot be held liable in the unlikely event that a

copyrighted work is distributed to the detriment of the copyright owner, nor

can the moderators carry personal responsibility for the content or nature

of postings. c.b.c takes no legal liability, and neither can you assign

liability to the group or its moderators, either collectively or individually.

 

If you do not agree with these terms, you must not use programs posted here.

Your use of programs on c.b.c and your subscription to this newsgroup

constitute your complete and binding acceptance of these policies without

restriction. This FAQ, and the policies and legal disclaimers therein, is

subject to change without notice. The terms of this FAQ and the legal

disclaimers therein shall be interpreted in accordance with the laws of the

State of California, United States of America.

 

3.2 Computer Workshops' relationship to c.b.c

 

Even though I run CWI, and I also do a lot of operations on c.b.c, CWI has

no relationship to c.b.c, and vice versa. This is the official word.

Computer Workshops has nothing to do with this group.

 

cbmsx.gif (1543 byte)