dyer@spdcc.COM (Steve Dyer) (01/01/88)
I see no overwhelming reason to keep comp.unix.microport as "moderated"
other than to keep the Microport prez and veeprez from posting commercials
too often (heh heh, just a joke...) Moderation is really suitable for
only a few groups, mainly source and binary archives, and those which
are striving for some control over the discussion (e.g., sci.med.aids.)
Even so, the schemes for delivering articles to moderators are often
unreliable or simply flaky. Just as an example, I have posted to several
moderated groups only to find that the destination path was expanded to
something unrecognizable at a backbone site, only to be bounced back to me
undelivered. Since I am also a moderator of sci.med.aids, we also suffer
from the opposite problem--when certain sites post articles, we often end up
getting many tens of copies of the same article!
People simply aren't going to put a lot of effort into composing a message
if they can't be sure that it's going to reach the moderator and then get
out to the greatest number of people. Since comp.unix.microport has a lot
of "pent up" demand, and the audience is at least as well-behaved as
comp.unix.xenix, why not change it to an unmoderated group? I simply don't
see what benefit is gained through moderation other than to add delay and
unreliability. The net effect is to keep all UNIX 386/V.3 discussions in
comp.unix.xenix (which isn't necessarily bad, but is obviously not the intent
of having this other group.) This is not a dig at the present moderator;
this is really intrinsic to the state of affairs.
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,husc6,linus,ima,bbn,m2c}!spdcc!dyerjohn@wa3wbu.UUCP (John Gayman) (01/01/88)
In article <513@spdcc.COM>, dyer@spdcc.COM (Steve Dyer) writes: > I see no overwhelming reason to keep comp.unix.microport as "moderated" I couldn't agree more. I was looking forward to the informative discussions and information exchange in comp.unix.microport that we know and enjoy in the other comp.* groups. Microport UNIX has been growing drastically and has a line of discussion all it's own of late. If I'm having a particular problem with a utility, it is hardly worth my time to post it to comp.unix.microport and have it dissappear into the woodwork or be responded to 3 weeks later. I think most of the private folks running Microport on their personal systems need to communicate with each other on a fairly timely basis for all the benefiet. I personally do not think having comp.unix.microport moderated is serving the best interests of *US* the Microport users or the Net resources. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: wa3wbu!john@uunet.UU.NET Marysville, PA 17053 | Packet: WA3WBU @ AK3P
webber@brandx.rutgers.edu (Webber) (01/03/88)
In article <444@wa3wbu.UUCP>, john@wa3wbu.UUCP (John Gayman) writes: > In article <513@spdcc.COM>, dyer@spdcc.COM (Steve Dyer) writes: > > I see no overwhelming reason to keep comp.unix.microport as "moderated" > > I couldn't agree more. I was looking forward to the informative > discussions and information exchange in comp.unix.microport that we know > and enjoy in the other comp.* groups. ... What you say is perfectly reasonable and could be said about most of the moderated groups. Do you expect moderators to just give up because a few reasonable people think they are not needed or are you ready to collect votes for an unmoderated microport group? --------- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)
dirk@altger.UUCP (dirk) (02/27/89)
Has anbody figured out how to use variable block sized tapes on the 386/ix rel. 2.0 generic tape driver. When I use my SCSI tape the kernel just responds: PANIC: Variable blocks size on dump DMA tape ... and crashes. I could solve this by setting the tape into fixed block, but I do not know how to setup a generic SCSI command with the 386/ix driver. How does the XENIX 2.3.1 aha1540 driver solve the problem. Can you setup generic SCSI commands ? cu, dirk :-)