bytebug@dhw68k.cts.com (Roger L. Long) (04/06/88)
Before the backbone proceeds with creation of comp.binaries.hypercard (which should be comp.binaries.mac.hypercard, but that's another story), I'd like to urge you to look hard at whether another Macintosh binary newsgroup is really needed, whether the volume increase is needed, and whether binary groups in general are a good idea. From the latest Arbitron postings we find that in volume posted, we have: 1 19000 1468 95% 347 6868.0 18 2.30 7.9% comp.binaries.ibm.pc 10 13000 995 97% 74 1886.8 5 0.95 5.4% comp.binaries.mac 26 6800 522 95% 28 920.5 4 0.87 2.8% comp.binaries.amiga That's 9.7MB of binaries posted during the month of March. Now, some of the reasons why creation a HyperCard newsgroup was suggested were because of the backlog to be posted to comp.binaries.mac, which I moderate, and the size of HyperCard postings. It's true that there is a backlog, which is caused by the limitation of about 2MB per month that I put on postings to comp.binaries.mac. To limit volume, I feel, is the primary job of the moderator of a comp.binaries newsgroup, and the reason we see so much volume (and so much noise) in comp.binaries.ibm.pc, which desperately needs moderation. How much volume is needed in a comp.binaries group? I feel that the 2MB that I limit it to works well. I feel (and am probably biased since I moderate it) that comp.binaries.mac postings are extremely high quality and of good use to readers of the group. I feel that by limiting the volume, that most people don't post trivial programs on a whim. Especially useful are the postings of Apple Technical Notes, which aid programmers with the latest technical information directly from Apple. Could more be posted? Certainly. But I think the overall quality would go down, and the group would become useless to many people. Is a seperate HyperCard binary group needed? Given the votes, you would think that quite a few people think it is. But what were they voting for really? If they were voting to continue seeing HyperCard stacks posted, then they will be kept happy by those posted to comp.binaries.mac, without imposing a heavier load of traffic on the net. And the heavier load is what really worries me. For those of you unaware, HyperCard stacks can be quite large, especially if they are at all complex, which many of the recent ones that I've seen are. A small stack might be 150K in size, while others, even if compressed by one of the Macintosh compression utilities, might be 400K or larger. A recent stack published by Apple as a supplement to their 1987 Annual Report to stockholders nearly filled a double-sided 800K diskette. So, how many stacks might get posted in a month? Given a 2MB limit that works well for comp.binaries.mac, maybe 5 or 6. But where are these stacks going to come from? Since HyperCard was released by Apple last year, I've posted probably 5 or 6 stacks total! Create a HyperCard group, and you'll find people posting stacks that aren't as high quality, just because there is a perceived void that they wish to fill. Splitting off new newsgroups when existing volume is present is one of the criteria for newsgroup creation, and I just don't see that we have the existing volume. Last, are binary groups needed at all? I think so, but limited in volume by a moderator. It's true that binary postings for XYZ machine are useless to those people without an XYZ. But given the arbitron results, almost as many people read comp.binaries.mac as read talk.bizzare, which both have about the same volume. It's clear to me which group has more value, but once again, I'm probably a bit biased. I would urge the "backbone" to postpone creating comp.binaries.hypercard, and urge that HyperCard postings continue to be made to comp.binaries.mac. -- Roger L. Long dhw68k!bytebug
dtw@F.GP.CS.CMU.EDU (Duane Williams) (04/10/88)
In <6600@dhw68k.cts.com>, Roger L. Long writes: | For those of you unaware, HyperCard stacks can be quite large, especially if | they are at all complex, which many of the recent ones that I've seen are. | A small stack might be 150K in size, while others, even if compressed by one | of the Macintosh compression utilities, might be 400K or larger. The remark that a small stack might be 150K is extremely deceptive, at best, because it suggests that this is a typical size for "small" stacks, i.e., that they don't usually get much smaller. This is false. The smallest possible (empty) HyperCard stack is about 5K. Useful stacks can be created that are well under 50K. My Home stack is only 24K, my Address stack 10K, Phone 12K, Datebook 41K, and Area Codes 31K. Most of the useful stacks I have collected are under 100K. Duane Williams -- uucp: ...!seismo!cmucspt!me.ri.cmu.edu!dtw arpa: dtw@cs.cmu.edu
Ilan@cup.portal.com (04/14/88)
I totally disagree with the rationales presented:
1. The massive amounts of HyperCard stacks on BBS around demonstrate
the tremendous amount of interest in HyperCard. The fact that only
5 stacks get posted on the net is an indication that something is
wrong with the postings process. The HyperCard group is necessary
for those who are curious as to how others write and demonstrate
HyperCard stacks. It is a different way of expressing software
software development capabilities than the rest of the binaries
and definitely needs its own unmoderated group.
2. By suppressing HyperCard stacks that are "deemed" undesireable
some good products also get tossed away (human nature). Its
a shame to watch the baby getting tossed out with the bath water.
3. The HyperCard group vote has been tallied and the YESs have it.
The backbone must create this group or change its rules for all
groups retroactively, how many groups would survive that change ?
- Ilan Rabinowitz - with ILANET(tm)
Ilan@cup.portal.comfarren@gethen.UUCP (Michael J. Farren) (04/17/88)
In article <4472@cup.portal.com> Ilan@cup.portal.com writes: >I totally disagree with the rationales presented: > 1. The massive amounts of HyperCard stacks on BBS around demonstrate > the tremendous amount of interest in HyperCard. Yes, it also demonstrates the foolishness of sending all those binaries over the net when they are easily available from BBS systems everywhere. >The fact that only 5 stacks get posted on the net is an indication that >something is wrong with the postings process. No, it is an indication that many systems just plain don't want to waste (yes, waste) the resources necessary to handle multiple megabytes of binaries of interest only to a small percentage of the net. >The HyperCard group is necessary for those who are curious as to how >others write and demonstrate HyperCard stacks. Necessary? Bushwah. Are you seriously trying to claim that Usenet is the only way to learn this stuff, or even a *GOOD* way? >definitely needs its own unmoderated group. Like hell. If comp.binaries.mac.hypercard is unmoderated, I would predict that it will never get sent very far. Certainly won't on *MY* machine. >2. By suppressing HyperCard stacks that are "deemed" undesireable >some good products also get tossed away (human nature). Its >a shame to watch the baby getting tossed out with the bath water. Baby with the bathwater? More like the baby with the Atlantic Ocean. > 3. The HyperCard group vote has been tallied and the YESs have it. > The backbone must create this group or change its rules for all > groups retroactively, how many groups would survive that change ? As many as were performing a useful function without costing the entire net huge amounts of money, I would suspect. Get two things straight - the vote in NOT a binding contract, it does not REQUIRE the backbone to do anything. And the backbone is not required to change anything if it chooses not to. The historical precedent is pretty clear, and shows that the backbone cabal is generally quite reasonable. Too bad if they do something YOU don't like, though, then they're fascist war-mongering pigs, eh? -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame