PHOTOSYN as a Newsgroup
Kenton A. Hoover
shibumi at net.bio.net
Tue Dec 8 20:11:07 EST 1992
smith-una at yale.edu (Una Smith) writes:
>Since Jonathan Marder requested that this discussion be held in
>bionet.plants, I have set the followup for this article to that group.
>Well, the number of LISTSERV groups (~3000) seems to be growing faster
>than the number of Usenet groups. That's actually not true, because
>there are many, many more Usenet groups that are not "propagated" beyond
>the bounds of universities or geographical regions, while all LISTSERV
>groups are counted in the LIST GLOBAL kept at BITNIC.educom.edu.
There are about 2300 USENET groups, including those going over regional
boundries (checked at agate.berkeley.edu, which is the most 'complete'
machine I can readily check). A quick glance over the LIST LIST usually
points out that a large number of LISTSERV lists are 'regional' in nature
(such as EMSNY-L, which is for EMS workers in New York State), and that there
are also a large number of duplicate lists. I was looking into the
incorporation of a set of LISTSERV lists into the USENET hierarchy about
a year ago, and the nubmer of duplicate lists is very high. Further, most
of the lists are about IBM-related topics that are not of great interest
to Unix users, or biologists.
LISTSERV and BITNET are dying systems. Thats the long and short of it.
CSNET/BITNET have been slowly shrinking since the early 1980s, a victim of
the higher functionality and decreasing costs of Internet access for
>I agree completely that for the Bionet groups, BIOSCI's old system of
>Usenet newsgroup and by-hand mailing list and listserver did not work.
>However, the SAS-L/bit.listserv.sas-l and STAT-L/bit.listserv.stat-l
>have generally performed excellently, with no routine maintenance by
>anyone. Sure, there is occasional bounced mail, but nothing like what
>the Bionet groups used to see on a regular basis. Electronic mail has
>improved over all, all over the world. Recently, I got a submission
>rejected by the LISTSERV that runs WISENET, with the explanation at the
>top that my article duplicated a recent posting (I had forwarded an
>announcement seen elsewhere). That's a nifty feature!
Are you sure that you didn't get that notice of 'duplication' as the
result of a human action, rather than an automated message? Unless the
original message ID was preserved in the header (which would have been an
RFC-822 violation, except for a resend), the detection of a duplicate would
be beyond the capabilites of most automated systems.
>Not everyone will have access to Usenet. That is unquestionably true.
Not everyone will have access to any one thing that anyone chooses. One
great advantage of USENET over BITNET for small institutions is that it
does not require dedicated phone lines.
LISTSERV is not the answer to mailing list problems, it the CAUSE of most
mailing list problems. I fail to see what we are going to gain by adding
a problematic and unreliable component to an already working and reliable
mailing list system.
>There are now many LISTSERV mailing lists gated into Usenet, most
>at American University (write to net-admin at auvm.american.edu for info).
>Experience with them over 5 years now has been quite satisfactory: just
>ask the SAS-L and STAT-L groups how they like it. LISTSERVs do work,
>however much some people don't like them.
I don't know who you talk to, but most of the mailing list managers I
keep in touch with passionately hate LISTSERV. It is not RFC-822 compliant
and it depends on BITNET which is not RFC-822 compliant (except for sites which
gateway on-site, and then only if you modify it heavily).
>I have never heard of "majordomo". Is this something written at BIOSCI,
>or is it what other Internet mailing list owners are using? There are
>quite a few systems for running automatic list maintenance, most of which
>don't seem to work as well as LISTSERV, in my own experience.
Majordomo is being used by many other sites on many other lists. I
deliberately waited until it had been proven to work before putting it in
>I don't see how having LISTSERV groups gated into Usenet as part of the
>Bionet domain has anything to do with administrative efforts at BIOSCI
>for the non-LISTSERVed groups. BIOSCI and Bionet are not the same.
>If anything, I am suggesting that BIOSCI get out of the business of
>maintaining mailing lists as soon as possible. Most Usenet groups
>manage to sustain themselves solely by the interest of those who
>participate, and those that don't generate sufficient interest are
"Automatically removed"? Where did you get this idea? Have you ever
looked into the abyss that it the voting and discussions associated with
group creation and deletion?
BIOSCI/bionet. are the same entity. We've gone to alot of trouble to provide
a single, reliable and responsive service entity for biologists to obtain
information. And while to turn this environment entirely over to USENET
might be an idea for the future, it would at the moment create a huge barrier
to the information for biologists.
>I really must object here. Usenet is not a service that BIOSCI
>provides to anyone, except perhaps those who happen to read Usenet
>on computers owned or administered by BIOSCI. Bionet is a domain of
>Usenet which BIOSCI was responsible for creating, simply by asking
>for it. Someone else could as easily create new Usenet newsgroups
>in some other domain, or even create some other domain, and someone
>would have done it if BIOSCI hadn't. But now that Bionet is well
>established as a Usenet domain, it would be nice to expand the domain
>to include other groups. In no other Usenet domain does one person
>have the final say-so as to what groups may be created and what their
>names are to be, simply because they already take care of (all) other
>groups in the domain.
The domain is constantly expanded to add new groups. We've added quite a
few since I've been working on this project, and will add even more before I
finish. We would even add the group under discussion, given the appropriate
vote. What we will NOT do is add the group in such a way as to cause
problems to the users of the list, or of newsgroups.
>It is very nice that in the Bionet newsgroups there is someone who
>reliably explains how to subscribe to people who send subscription
>requests to mailing list, not biosci at net.bio.net. But this service
>is already duplicated by other people within the Bionet groups (I've
>asked) and handling such requests is not a problem, no matter who
>does it. BIOSCI does provide a true service by taking care of all
>subscription requests (that's a real chore, I'm sure!), and I am glad
>to hear that this service will be automated. But this service comes
>at a cost: the Bionet newsgroups can only expand as fast and as much
>as BIOSCI is able to find funding to employ individual people to do
>what in the rest of Usenet is done by newsgroup participants for free.
We are not totally automating the work -- that would perpetuate the
requirement that LISTSERV has of being highly computer literate to
add oneself to mailing lists. We are providing an automated mechanism
to assist literate users, and keeping the manual system for those who
are unable or unwilling to use the automated one.
>They do it for free because no one has to do it too long: there
>always seems to be someone who is willing to contribute some effort
>to these administrative chores. By spreading the work around in this
>way, no one ever has to do much. The biggest single administrative
>chore that exists within Usenet is the writing of FAQs. The biggest
>chore of all is that of the dedicated and truly noble computer system
>administrators around the world who have written the free software
>that we all use, and who keep it running smoothly for the rest of us.
Nice theory. Given this, almost no community non-profit group would need any
>Hey, be fair! It's entirely arguable that the LISTSERV software is
>still in use after at least a decade *because* it *works consistently*.
>And various Usenet reading programs have been around a long time to:
>should we throw them out because they're "old"?
No, its still in use because IBM mac
More information about the Plantbio