🚀 go-pugleaf

In article <457@stech.UUCP> sysop@stech.UUCP (Jan Harrington) writes:
>Here's the current vote tally for the proposed comp.binaries.hypercard
>group:
>
>YES votes
	35 votes
>NO votes
	2 votes

I vote no.  But given the number of yes votes, I doubt that it will do much
good.

Here's my reasoning (as moderator of the already existing comp.binaries.mac):

There are a lot of folks out there that see the volume of comp.binaries.mac
as too high, which is why I limit the volume in the way that I do.  Apart
from checking out the postings that I receive, that's the major function of
the moderator: to limit the volume to what is perceived by a majority of the
net to be "an acceptable level".  Even so, comp.binaries.mac is usually in
the "Top 10" groups according to volume, and given that visibility, its 
easy to see why people who spend the bucks complain.

Yes, the Mac is a popular computer, but if you look at the arbitron stats
that are posted once a month, I sincerely doubt that increasing the volume
that is posted for the benefit of a fairly small number of readers is that
wise a move. (Actually, this months stats are likely to be way off since
the group took an unexpected break for two weeks.  Previous months stats
are likely to be more accurate.)  We really need to find an effective way
to deal with the volume of what is posted before we start adding new binary
groups.  And especially since there really isn't such thing as a "small"
hypercard stack.

What to do?  Some have suggested rejecting anything that is bigger than X,
but that would effectively eliminate most hypercard stacks.  Yes, the
Esperanto stack was hugh, but I felt that even though many people might 
not have an interest in Esperanto, it was a terrific example of just what
could be done with Hypercard.  Many complained about the commercialism of
posting the THINK upgrades; many people praised THINK about the level of
support they gave their product.  Many people have complained about the
commercialism of demos; many have commented that previewing demos are
invaluable.

Another point I'd like to raise is what can be done to increase the
reliability of the net in terms of probability of receiving a multi-part
posting intact.  The way things are, using the net as a distribution 
medium for binaries is fairly big gamble.  Witness the number of postings
here asking for replacement part 3 of this and parts 5 and 6 of that.  It
is far to likely that some site or sites is going to scramble a binary
posting.  I did what I could to distribute postings to a number of 
different sites, but as you can see from recent history, things still got
screwed up.

So, I would hope these things would be taken into account before we go
too much farther down the comp.binaries path.
-- 
	Roger L. Long
	dhw68k!bytebug