SCHAFER@RICEVM1.RICE.EDU (Richard A. Schafer) (01/31/90)
On Tue, 30 Jan 90 13:55:24 EST Michael Johnson said: >Software that might fall under the auspices of BITNIC would include such >things as Mail Transfer Agents, Mail User Agents, file servers, NEWS servers >and NEWS interfaces. When BITNET II hits the horizon, there will be other >things that need to be standardized across the net. Some of this software >would be required (such as the MTA) and some would be optional (the MUA). >As it is now, we have a horrible hodge-podge of (for example) up-to-date >MAILER servers, back-leveled MAILER servers, and no MAILER servers at all. >Sites that choose not to run MAILER can justify it on the basis that MAILER >support may not continue in the future. If support of the BITNET MTA was >assured for as long as there existed a BITNET, then that justification would >go away. Support of the MTA and other software could be a full-time job for >whoever is contracted/hired to do it, rather than being fit in among the other >duties of busy systems programmers. I'm glad to see someone raise this issue again. While I'm certainly personally committed to supporting the code I write and distribute *now*, there's no way I can possibly guarantee that I won't (heaven forbid) walk in front of a cement truck on my way out to the car tonight, in which case, who would take care of the RiceMail code? I have recently had at least one site say that they were leery of installing anything like the Mail command on precisely those grounds, and I encourage people with those kinds of valid concerns to bring them up before the board. As long as BITNET depends in a major way on programs written (and owned) by individuals without institutional support committments, then there is a major risk involved that at the very least needs to be recognized, if not dealt with. The only way that anything like BITNET-supported software is going to exist is for the membership to demand it and for the board to agree that this is a good idea. You'd need negotiations with current software owners should BITNET decide to try to obtain ownership of the existing widely used software. You'd need some network-wide funding committment, I would think, to provide for the software support structure you're talking about wanting. You'd need a *lot* of decisions about what software was needed, and we all *know* how hard that is to achieve. Am I pessimistic? Perhaps. But I think the only way to proceed is to start talking about the subject. Richard
WIL@BYUVM.BITNET (Wil) (02/03/90)
There were a number of messages regarding a major controversy respecting listserv, bulletin boards, news services, etc. in my last mail bag. I disposed of most of them but you may be able to rescue them if you have an interest. It involved more than just the ones a forwarded to you. Incidentally, when I type "mail" I get a "send to:" message which requires me to hit several keys to get rid of it. I also get this message periodically during the course of examining my mail. I didn't used to get this message. Ha s something happened to my software? or is it yours? Wil
LDW@USCMVSA.BITNET (Leonard D Woren) (02/03/90)
On Tue, 30 Jan 90 13:55:24 EST, Michael Johnson <michael@MAINE.MAINE.EDU> said: > I would like to see the BITNIC charged with developing, or contracting to > develop, software to implement BITNET RFC standards and with making that > software available to all the member institutions (VMS, Unix and VM). If this Why does everyone on Bitnet (except RAF) seem to forget that there are 169 MVS systems on the NJE network? And those 169 systems probably have as many users as 3 times that many VM or 20 times that many VMS systems. > means slightly increased dues for all member institutions, so be it. It is > certainly more fair than having a few places carry the bulk of the financial > load that comes from product development time. I disagree with basically everything quoted above. First of all, software developed by end users typically does what they want. Software developed by vendors (and in the above scenario, Bitnic would be a vendor) typically does not do what you want, the way you want it done, and it takes just short of forever to get the vendor to change it. (Well, ok, maybe Joiner is an exception -- I don't know since I don't deal with them or JNET, but people seem to be happy with them.) The software that was developed by ONE or maybe TWO people is almost always better than that developed by a large organization. (Remember that a camel is a horse built by committee. (No smiley here.)) UCLA/Mail was developed by ONE person. Wasn't MAILER also? And nearly everyone knows that LISTSERV was developed by one person. I think that the low cost and the P.D. tools that we have for mail on Bitnet are typically better than what vendors can sell us. And vendors don't like to make source available. One MAJOR reason why certain things like UCLA/Mail, LISTSERV, MAILER, MAILBOOK are successful is because the source is available, and sites can make modifications to suit themselves, and contribute those mods back to the maintainer. I certainly don't think that software that can't be used by *all* Bitnet sites should be funded out of general Bitnet membership fees. If some sites want to pay Bitnic to develop software that would be licensed to those sites paying for it, fine. But why should, say, an MVS-only site pay for development of VM tools, or a VM-only site pay for development of VMS tools, etc??? Leonard D. Woren Senior MVS Systems Programmer MVS Postmaster <LDW@USCMVSA.BITNET> <LDW@MVSA.USC.EDU> University of Southern California
LRL@PSUVM.PSU.EDU (Linda Littleton) (02/03/90)
A news package for VM is available that can help to offload some of the traffic caused by lots of people subscribing lots of Listserv lists. It is called NETNEWS and is available via LISTSERV. NETNEWS can gateway LISTSERV lists into bulletin board format, receive USENET feeds via either Bitnet or NNTP, set up local discussion groups, and control read and post access and expiration time on a per-group basis. The user interface has a "Filelist-like" feel to it, with three levels. First there is the Newsgroup Menu, listing all groups available. The user selects a group via cursor and PFkey and gets that group's Article Menu, which lists all current articles in the group. Finally, the user chooses an article (again with cursor and PFkey) to be displayed. The software can keep track of what groups the user wants to see and what articles have already been read. For info, issue TELL LISTSERV AT PSUVM GET NETNEWS PACKAGE This will send you an Administrator's Guide, a User's Guide and information on how to get the package. For information on the NNTP server (which is designed to work with this NETNEWS implementation), issue TELL LISTSERV AT QUCDN GET NNTP PACKAGE. The LISTSERV discussion list on this is NETNWS-L at NDSUVM1. -Linda
ACS00790@UDACSVM.BITNET (shaffer, bob) (02/03/90)
> Linda Littleton writes: ... >For information on the NNTP server (which is designed to work with this >NETNEWS implementation), issue TELL LISTSERV AT QUCDN GET NNTP PACKAGE. > >-Linda but when I tried this command I got an error message saying file not found.
LIPPKE@UTDALLAS.BITNET (David Lippke) (02/04/90)
In regard to the proposition that BITNIC should be charged with the production
and maintenance of software for BITNET sites, I have two comments.
First, I have faith that the production and maintenance of good software
by BITNET volunteers is something you can count on. I hope Richard is
never run over a truck and that he continues to be able to maintain his
MAIL package until he retires, but the fact is that if he for some reason
could not continue his work, someone else would rise from the ranks to
take his place. There'd likely be a stressful interim period, but things
would somehow or another work themselves out. This process has repeated
itself time and time again. As long as BITNET's volunteers aren't somehow
stifled (and if they were, I'm sure that the end of BITNET would be near),
I'm positive things will continue to work.
Second, judging from the negative reaction that BITNIC seems to get to their
every action, I doubt the network community ("pack of wolves" may be a better
description (hmmm.. maybe "jackals" even better yet)) would ever accept
software produced or maintained by BITNIC. I'm sure that we'd hunt down
every little weakness in it and then go for blood every time. It seems,
on this network, the only persons immune from real attack about their
software are volunteers. In fact, this may be the ONLY safe way to produce
software on BITNET. Volunteers are the only ones who can successfully
employ the critical fallback of "Don't like it? Then YOU fix it!"
I'm not blameless in this. Witness how I've attacked those who demand
commercial-class bucks for their BITNET-related software. To me, it's a
sortof sacrilege against an imaginary brotherhood based on trust and
mutual regard. I know I'm strange ;-), but BITNET just means certain
things to me and VOLUNTARISM is one of those things.
It could be that BITNET is entering a new phase of its life which demands
bureaucracy with all of its rules, regulations, and forms in triplicate.
In my book, such a phase should be labeled THE DECLINE. I sincerely
hope this is not what's actually happening.
Regards,
David LippkeLRL@PSUVM.PSU.EDU (Linda Littleton) (02/05/90)
Sorry for the misinformation on where to get NNTP. You need to GET NNTPXFER PACKAGE and GET NNTPRCVR PACKAGE from LISTSERV at QUCDN. -Linda
michael@MAINE.MAINE.EDU (Michael Johnson) (02/05/90)
>On Tue, 30 Jan 90 13:55:24 EST, > Michael Johnson <michael@MAINE.MAINE.EDU> said: >> I would like to see the BITNIC charged with developing, or contracting to >> develop, software to implement BITNET RFC standards and with making that >> software available to all the member institutions (VMS, Unix and VM). If this > >Why does everyone on Bitnet (except RAF) seem to forget that there are >169 MVS systems on the NJE network? And those 169 systems probably >have as many users as 3 times that many VM or 20 times that many VMS >systems. Probably because everyone would LIKE to forget that MVS even exists. :-) > >> means slightly increased dues for all member institutions, so be it. It is >> certainly more fair than having a few places carry the bulk of the financial >> load that comes from product development time. > >I disagree with basically everything quoted above. First of all, >software developed by end users typically does what they want. Software developed by end users at one particular site typically does what end users AT THAT SITE want done. >Software developed by vendors (and in the above scenario, Bitnic would >be a vendor) typically does not do what you want, the way you want it No, BITNIC would be a central programming site for the BITNET. BITNIC would not be selling or otherwise making a profit on the software. So BITNIC is not a vendor in the above scenario. BITNIC would have no vested interest in stifling development of such software in desirable directions. >done, and it takes just short of forever to get the vendor to change >it. >The software that was developed by ONE or maybe TWO people is almost >always better than that developed by a large organization. (Remember >that a camel is a horse built by committee. (No smiley here.)) If you think that BITNIC is a large organization, you should have another look. There are very few people working at the NIC. Camels work pretty well for what they were designed to do.. >UCLA/Mail was developed by ONE person. Wasn't MAILER also? And MAILER was developed by 3 different people over the course of time, but the reason why it is so good now is because MANY people all over the network have supplied ideas for it to one CENTRAL development site. >nearly everyone knows that LISTSERV was developed by one person. I And shows it too. LISTSERV may be the best thing that we have for its purpose, but it is NOT the best that could be done. It has lots of shortcomings. >think that the low cost and the P.D. tools that we have for mail on >Bitnet are typically better than what vendors can sell us. And >vendors don't like to make source available. One MAJOR reason why I would EXPECT the NIC to make source available for these tools. The NIC would have no economic interest in keeping the source secret or maintaining some kind or proprietary "look and feel". These are reasons why vendors typically do not make changes easily. You are assuming that the NIC would start acting like IBM or worse, like DEC. I see no reason to assume such a thing. >certain things like UCLA/Mail, LISTSERV, MAILER, MAILBOOK are >successful is because the source is available, and sites can make >modifications to suit themselves, and contribute those mods back to >the maintainer. There is no reason why this could not be done if the NIC were maintaining said software. >I certainly don't think that software that can't be used by *all* >Bitnet sites should be funded out of general Bitnet membership fees. >If some sites want to pay Bitnic to develop software that would be >licensed to those sites paying for it, fine. But why should, say, an >MVS-only site pay for development of VM tools, or a VM-only site pay >for development of VMS tools, etc??? The point is that all sites should be REQUIRED to run up-to-date copies of certain software so that we have some consistency on the network. Let's not get into operating system politics here. The same tools would be developed for all systems hooked into the net and would be run by all systems and should therefore be paid for by the net as a whole. The current system certainly is NOT fair. A very few sites are shouldering the development and maintenance burden for the entire net. And you would like them to continue doing so while you get free software. How convenient. >Leonard D. Woren Michael Johnson "We are the Priests of the Temples University of Maine System of Syrinx. Our great computers fill Computing and Data Processing Services the hallowed halls." - Neil Peart
mwh@IVORY.EDUCOM.EDU (Michael Hrybyk) (02/05/90)
From David Lippke's fine piece: >I know I'm strange ;-), but BITNET just means certain >things to me and VOLUNTARISM is one of those things. BITNET means the same to me - it exists upon the strength of the volunteers who support it. Voluntarism does not have to mean lack of organization. I believe if there was a venue for distribution of BITNET-related software (eg, the Iowa clearinghouse, uunet, the Free Software Foundation), voluntary software production would increase. BITNIC could (should??) perform the clearinghouse function. We get an incredible amount of mail and phone questions related to installation and maintenance of various volunteer-produced software packages across operating systems. I believe that it is important to provide support to local maintainers of these packages. Just how this should be done is an important question. Should we develop in-house support, or organize a set of volunteer consultants for each package? Which package(s) should we do this for? What scheme should be used to allow for rapid information flow from the person with the problem to the expert who can help? I see BITNIC deeply involved in these and other support questions in the future. Note that these issues are the same for your computing centers and their user support functions, except at a meta level. Finally, BITNIC will never be a software production house (although we *are* programmers, and can produce tools as necessary). The work of volunteer programmers is at the heart of this community network, and needs to be aided. Part of the reason that I came to work at the NIC was due to the emphasis on volunteerism. I like to reread Stallman's GNU Manifesto from time to time. >It could be that BITNET is entering a new phase of its life which demands >bureaucracy with all of its rules, regulations, and forms in triplicate. >In my book, such a phase should be labeled THE DECLINE. I sincerely >hope this is not what's actually happening. Let's hope that the need for organization never shuts out the impetus to create. Mike Hrybyk BITNIC
DBUECHNE@GTRI01.BITNET (Dave Buechner) (02/06/90)
> >The future? >Listservs running with no modifications but ANU-NEWS (and similar >packages) would be a great improvment. Listservs customized to help >NEWS-like packages would be a very great improvement. Bitnet >switching to Usenet-style news and getting rid of Listserv is very >do-able. I appreciate the work that went into Listserv, but I think >the trend towards a News-orientented system would be a bit improvment >for users. Management isn't all that more difficult. > >-Tom I can see Bitnet switching to Usenet-style list reading where one copy of a note is sent to/stored on a system no matter how many users are signed on. I do not think that Usenet-style distribution is a good idea. It seems like distributing all lists to all systems is going to increase network traffic significantly. Some rambling thoughts...... Dave Buechner Lead IBM Systems Programmer Georgia Institute of Technology, Atlanta, GA, USA
WYNCOTT@PURCCVM.BITNET (George F. Wyncott) (02/06/90)
Yes, Shari Martinez has been working on installing the Princeton version
of NETNEWS for some time now. We may also look at the Penn State
implementation before placing NETNEWS into production. I am the biggest
supporter of this type of product to reduce our spool file problems.
P.S. Rex promised to update the machine configuration diagrams when he
returns from vacation on Feb 12.MAINTCMS@PUCC.BITNET (John Wagner) (02/06/90)
On Mon, 5 Feb 90 09:18:06 EST Michael Johnson said: >>I certainly don't think that software that can't be used by *all* >>Bitnet sites should be funded out of general Bitnet membership fees. >>If some sites want to pay Bitnic to develop software that would be >>licensed to those sites paying for it, fine. But why should, say, an >>MVS-only site pay for development of VM tools, or a VM-only site pay >>for development of VMS tools, etc??? >The point is that all sites should be REQUIRED to run up-to-date copies of >certain software so that we have some consistency on the network. Let's not >get into operating system politics here. The same tools would be developed >for all systems hooked into the net and would be run by all systems and should >therefore be paid for by the net as a whole. The current system certainly is >NOT fair. A very few sites are shouldering the development and maintenance >burden for the entire net. And you would like them to continue doing so while >you get free software. How convenient. Michael, Let the sites who are doing the software make the claim that it is unfair. I don't think you will find them doing so. Princeton has received improvements to MAILER that I could not have produced as quickly but that benefitted Princeton (earlier than the rest of the MAILER sites). The debugging support (by other sites) has made MAILER a better piece of code. This has not been a one way street. Development of MAILER and MAIL/MAILBOOK (supported by Richard Schafer at Rice) have both been cooperative efforts of the users of the software with a site willing to provide a development center. My personnal feeling is that the whole topic of portable (system independent) code has been used as a smoke screen by some parts of the network to not create similar environments for their platforms. I believe that suggesting that software should be developed by BITNIC amounts to the same thing. Why didn't a similar environment develop for the UREP/JNET machines (to pick 1 group)? Where were the sites willing to develop software (at their own expense) to be compatible with the systems already on BITNET? Why did no support groups develop for those development projects that did occur? (If they existed, they sure were awful quiet.) What was different about the VM systems from the rest of the network? If you can answer these questions I think you will be a lot further along the route of being able to decide what would be a good approach for software development on BITNET. I know I don't have any answers to them. Does anyone?
mwh@IVORY.EDUCOM.EDU (Michael Hrybyk) (02/06/90)
>Development of MAILER and MAIL/MAILBOOK (supported by Richard Schafer >at Rice) have both been cooperative efforts of the users of the >software with a site willing to provide a development center. My >personnal feeling is that the whole topic of portable (system >independent) code has been used as a smoke screen by some parts of the >network to not create similar environments for their platforms. I >believe that suggesting that software should be developed by BITNIC >amounts to the same thing. Why didn't a similar environment develop >for the UREP/JNET machines (to pick 1 group)? Where were the sites >willing to develop software (at their own expense) to be compatible >with the systems already on BITNET? Why did no support groups develop >for those development projects that did occur? (If they existed, they >sure were awful quiet.) What was different about the VM systems from >the rest of the network? > I think mta/ua development is a bad example, as there exists mmdf/sendmail and pmdf, largely the result of volunteer development effort. It just so happens that these mta's service all types of protocols, not just nje/note/bsmtp, and therefore can't make the claim to be 'BITNET' software. pmdf/mmdf, eg, has bsmtp, phonenet, uucp, smtp, and x400 (I've left out a few) channels, and was largely done by folks at UDel, BRL, BBN, Harvey Mudd Coll. and Univ. Ky. (sorry if I've not given full credit to all due here). Sendmail likewise has multiple delivery modes, with PSU support for BSMTP. However, there is a lack of effort in getting LISTSERV, NETSERV, and EARN tools available on non-VM platforms. In part, it is hard to fit LISTSERV into a general facility on VMS or UNIX; it would have to be done from scratch. Since the bulk of LISTSERV is in assembler and REXX, the developer would have to start from the command language and engineer backwards to the system. It would have been nice to have the central routines written in a more portable manner, but this is no excuse for lack of development. For non-IBM systems, just getting the NJE emulation software off the ground and working took some real effort. On IBM systems, the transport layer is a given, no extra products or hacking required. The extra time spent in maintenance mode on non-IBM systems tends to sap energy fast. Portability is not a smoke screen; it makes life a lot easier. But arguing that BITNIC (or some central agency) take on the role of primary software developer in order to get similar services across hardware and OS's just may be blowing a few puffs. >If you can answer these questions I think you will be a lot further >along the route of being able to decide what would be a good approach >for software development on BITNET. I know I don't have any answers >to them. > >Does anyone? > John, you are on the mark here. The general questions are 1. what services should CREN/BITNET provide to its community of users? 2. how should software be developed, maintained, and distributed in order to fulfill the service requirements? My answers (and this does not reflect an official position) in short: 1. coordinated mail delivery systems; robust file and information servers; discussion list, news, and bboard facilities; network hook-up assistance. Sound familiar? It is what CSNET and BITNET provide to their users now. The focus is on the application layer, with the other 6 left to the OS and networking software/hardware providers to fight out. 2. CREN should provide leadership in specifying the services and the interfaces/protocols necessary. Who writes the code to implement the protocol or meet the interface spec could be anyone - commercial or volunteer. CREN should facilitate development and maintenance of such software, and provide the method of distribution to its members. These are admittedly incomplete thoughts. Mike Hrybyk BITNIC
GETTES@PUCC.BITNET (Michael R. Gettes) (02/06/90)
>1. what services should CREN/BITNET provide to its community of users? But but but but, we cannot decide this. Additionally, I believe we really can't think about this until we here from CREN what direction our network is going in... maybe the board minutes will state this??? I think most of us agree with these concepts. The problem is, there is nowhere to begin. We need a direction -- and we need methods of establishing standards, formalizing ideas, and enforcing policy/standards to move in that direction. >2. CREN should provide leadership in specifying the services and the > interfaces/protocols necessary. Who writes the code to implement > the protocol or meet the interface spec could be anyone - > commercial or volunteer. CREN should facilitate development and > maintenance of such software, and provide the method of > distribution to its members. BINGO! In my opinion, once the aforementioned concerns are dealt with, then this point 2 is right on the money. I do not believe this is a "chicken and egg" problem. I believe we must have the "political" mechanisms in place to properly address and implement the technical mechanisms of the network. /mrg
NOREILLY@HASEOC.BITNET (02/06/90)
At IRLEARN, an extension to Rice MAIL is in use which gives users access to a public disk area where postings to selected public lists, popular with local users, are placed in notebooks by a daemon. This avoids the need for individual subscriptions to the lists. This utility, called BBOARD, is home-grown. It is written in REXX, and requires Rice MAIL and a suitable archive-daemon, such as LISTSERV. Anyone requiring further information is welcome to contact me. Niall O'Reilly
IMHW400@INDYVAX.BITNET (Mark H. Wood) (02/06/90)
>From: Michael Johnson <michael@MAINE.MAINE.EDU> [...] >>Why does everyone on Bitnet (except RAF) seem to forget that there are >>169 MVS systems on the NJE network? And those 169 systems probably ^^^^^^^^ >>have as many users as 3 times that many VM or 20 times that many VMS >>systems. [...] >>Leonard D. Woren Before these supposed statistics find their way into our future plans, let me supply an *actual* statistic: the VMS system from which I am writing currently holds around 7,000 user accounts. Yesterday (quite early in a semester) we topped out at around 60 concurrent jobs, and last semester our overall peak was about 90-95 concurrent jobs. I don't know how many users a typical MVS site represents. Is there some better place to discuss this? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mark H. Wood (317)274-0749 III U U PPPP U U III Indiana University - Purdue University at Indianapolis I U U P P U U I IMHW400@INDYVAX.IUPUI.EDU I U U PPPP U U I IMHW400@INDYVAX.BITNET I U U P U U I [@disclaimer@] III UUU P UUU III
TLIMONCE@DREW.BITNET (Tom Limoncelli @ Drew Univ.) (02/07/90)
>From: "Mark H. Wood" <IMHW400@INDYVAX.BITNET> >Date: Tue, 6 Feb 90 09:56:00 EST >[ Mark has 7,000 user accounts & about 60-100 concurent jobs ] We find a similar thing here. 3000 accounts, 60-80 concurent jobs. By the way, in My Humble Opinion a VMS system running JNET and PMDF is pretty damn near the RFCs, and possibily closer that a LOT of the other systems on Bitnet (including VMS sites without PMDF). -Tom --- Tom Limoncelli The computer industry should spend more time in front of tlimonce@drew.edu (new) their computers. Remember when 'Look & Feel' tlimonce@drew.Bitnet was what you tried to do on a date? limonce@pilot.njin.net -Me