root@uwspan.UUCP (John Plocher) (10/22/87)
In June of this year I gathered votes for splitting up comp.unix into
comp.unix.sys5 and comp.sys.microport. About 75 people responded, all but 2
were in favor of the idea. (Since then, the lower limit was raised to 100
votes for a new group)
When the proposal was submitted to the backbone it managed to set off a
major discussion of how the comp.unix layout should really be done. It was
felt that breaking it up into BSD/SYS5 camps wan not really what was needed
at this time, but a Microport group was desirable.
We proceeded slowly, installing the needed software, making sure that
Microport and Bell Tech both got news up and running so that they could
participate, tested links and aliases, and even found a method to "do"
this group with THREE moderators. All this was in place and tested when it
was brought to my attention that using the name of a single distributer
(Microport) to describe a group devoted to the product of many other
distributers (Bell Tech, Intel, Interactive Systems...) was not a Good
Thing to do. Because of this, the name was changed to:
comp.unix.unix-at
This specifies that the OS is true Unix, and not Xenix (which has it's
own group) for any of the machines like the AT. Most of the 286 and
386 systems out there use the AT (I-BUS) for add on cards, so it was felt
that this name was fitting.
The point of this rather long winded note is that, sometime this week (or
early next) the backbone will do a newgroup for comp.unix.unix-at. What
follows is the charter we have developed for the group.
-John
PS. I hope that this group goes well - I will post again after the group gets
created.
--
comp.unix.unix-at: Unix on Intel processors Submissions to unix-at@uwspan.uucp
Please add ONE of these words to your Subject: line to describe your submission:
286, V/AT, 386, V.3, bug report, or source
To get an up to date buglist include the words "send buglist" in your Subject:
Charter for comp.unix.unix-at
Moderated Newsgroup Guidelines
Description:
* Discussion about Unix on 80286 and 80386 machines.
Newsgroup contents:
* Targeted for a technical audience of intermediate to advanced
users. The beginning user will not be ignored, though.
* Technical discussion concerning system installation, management,
and maintenance.
* Discussion of other vendor/PD software and hardware which can be
used with Unix.
* "Guest tutorials" on using System 5 & V/AT goodies. This
speaker might be someone at Microport, Bell Tech, ISI, a Unix
guru, or whoever, who would write an article on some interesting
topic. e.g., Installing TCP/IP, smail, elm, interfacing to an
EGA, ...
* Source code postings for *UNIX-AT Specific* programs.
(EGA device drivers, CGA graphics routines...)
* A forum for Microport, Bell Tech, and ISI support staff to
address users' questions.
* Bug reports and fixes, to be indexed and archived
This includes the latest "official buglist" from Microport
Systems, as well as known bugs reported by the readers.
Other proposed (future) benefits:
* Source code archives of programs ported to V/AT (V/386 too?)
At this time these will be avaliable through POSTAL MAIL only!
Send email to unix-at-request@uwspan.uucp for details.
* Access to Microport's proposed support BBS
Editorial policy:
* All submissions should go to:
unix-at@uwspan.uucp submissions
unix-at-request@uwspan.uucp administrivia
(<backbone>!uwvax!uwspan!unix-at for non-domain mailers)
This will be set up as a mail bounce point which will sort out
submissions for the moderators based on the Subject line.
There are three moderators who have expertise in these areas:
John Plocher - "Bug" reports & "source" code
Eric Raymond - "V.3", "386"
Robert White - "V/AT","286"
In order for your submission to get to the correct moderator,
you *must* include one of the quoted words above on your
Subject line. For example:
Subject: Bug report - V/AT uucico dies when -xnum flag is used
---
Subject: Benchmarks for V.3 (Bell Tech): Dhrystones
---
Subject: The V/AT 2.3 kernal is really better than 2.2.2
----
The words "Bug" and "source" are recognized before anything else,
so any Subject containing either of these words will be sent to
John Plocher.
"386" and "V.3" is recognized next, before "286"; these messages
will go to Eric Raymond.
If "286" or "V/AT" is found, or no other identifying words are
found the message will get sent to Robert White.
The special case of:
Subject: Please send the latest buglist
---- -------
will generate a reply containing the current list of known bugs.
If a submission is mis-labeled it will be bounced (by hand)
to the correct moderator. NOTE that this will take longer,
so *please* do it right the first time!
* The moderators are:
Robert White, MENTOR Software
Eric Raymond, Thyrsus Enterprises
John Plocher, University of Wisconsin Spanish Department
* NO FLAMES OR META-DISCUSSIONS WILL BE TOLERATED
* All postings should pertain to Unix on Intel CPUs.
* Messages may be edited to:
1) reduce ammount of quoted material and/or .signatures
2) eliminate flames and/or Meta-Discussions
3) reduce redundant info (if many ask the same question)
4) correct/re-arrange spelling errors and grammer to preserve
the tradition of King James.
Message CONTENT will hopefully not be distorted.
Personality conflicts with the moderators will not effect
editorial policy.
* The moderators reserve the right to reject or delay the posting
of any material.
* Technical/informational articles should be posted immediately
upon receipt.
* Questions will be either answered by mail or bundled in a digest
and posted as volume (and content) allows.
* Source code must:
- NOT be derived from propriatary (e.g, AT&T) source code.
- Be either Public Domain (no strings) OR validly Copyrighted.
Software which sports an invalid or overly restrictive
Copyright will be rejected. Note that since we are not
lawyers the fact we distribute an article with a Copyright
does not mean that it is really a valid one. We just want
to catch the obvious gaffes.
e.g., Copyright John Plocher
INVALID because it contains no date,
(C) 1987 John Plocher
INVALID because the symbol (C) has no legal standing,
This Public Domain code is Copyright 1987 John Plocher
INVALID because it contradicts itself.
Copyright 1987 John Plocher All rights reserved
Too Restrictive - We can not really distribute this
because you have explicitly NOT given us the right
to send it out over Usenet.
A correct Copyright is of the form:
Copyright 1987 John Plocher
Distribution through Usenet permitted
Explicit resale prohibited
An even better way would be:
This code is placed into the Public Domain
by its author, John Plocher, on Jan 11, 1987
Note that Bell, ISI, and Microport might find it impractical
to incorporate Copyright stuff into their products; PD stuff
stands a better chance.
- Please include a Makefile
Try to have entries for
make all compile & link everything
make install install everything in a system dir
make doc print out man pages and manuals
make uninstall restore sys dirs to original state
make clean erase *.o, core, unneeded libs..
make all ; make install ; make uninstall ; make clean
should be a no-op.
- Include a man page for use with nroff -man
- If possible, please "shar" your files before submission.
uuencode all binary data, and make sure no one file is
greater than 40,000 bytes.
* Source code will be evaluated (does it compile/run), shar'd,
posted, and archived IF it is Unix-AT specific. Generic
Unix code will be forwarded to comp.sources.unix or
comp.sources.misc; games will go to comp.sources.games.
* Binaries will usually be rejected. Exceptions would need to have
a Very Good Reason.
* Bug reports should include the following:
OS Vendor: (Microport, Bell Tech, ISI,...)
OS Version: (2.2.2, 2.3 + DosMerge...)
Hardware config: (CPU, Bios type, speed, mem size...)
Problem description: (what is broken, symptoms...)
Reproduce the problem: (a program, shell script...)
Proposed fix/workaround: ("Don't use it" isn't good enuf)
Urgency: (crashes system ... annoyance)
These reports will be checked against the list of known bugs,
if possible verified and reproduced, and forwarded to Microport,
Bell Tech, or ISI. Bug reports will be ack'd by email.
* The list of known bugs will be posted monthly.
This list is avaliable by email by sending a message:
To: unix-at@uwspan.uucp
Subject: Please send the latest buglist
The operative words in the Subject are "send" and "buglist".dyer@spdcc.COM (Steve Dyer) (10/22/87)
I think the name is horrible and will only lead to confusion, in the
light of the existing Xenix newsgroup. "comp.unix.microport", while
perhaps a bit restrictive in that it doesn't seem to include ISC's and
Bell Tech's offering, at least has the advantage of being clearly
distinct from comp.unix.xenix. Since Xenix IS UNIX, and it IS running
on the AT, I wager you'll gets as many cross postings there for Xenix
stuff as we see in comp.unix.xenix for Microport stuff right now. Anyway,
since none of the 386 UNIXes presently or will ever run on something known
as an "AT", I also think it's unnecessarily confusing. How about trying again
for a better name?
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyerrobertfe@microsoft.UUCP (Robert Ferguson 2/1073) (10/23/87)
I seem to recall that XENIX runs on an "AT". We just finished working on the 2.2.3 update release for that machine. "Comp.unix.unix-at" is a very, very bad way to set this up. The logical consequence of the division you propose is that the XENIX group should be moved to in part to "Comp.unix.unix-at.xenix", and that we should create "Comp.unix.unix-386.xenix", "Comp.unix.unix-ps/2.xenix", and so on, ad nauseum. Small-scale architectural differences are not the way to sort this out. May I suggest that you consider creating comp.unix.micro, comp.unix.micro.intel, and comp.unix.micro.xenix? Please pick another name. I fear that comp.unix.unix-at will confuse the issue and may not solve any of the problems that you set out to address. ---------- Rob Ferguson XENIX Development Staff microsoft!robertfe Microsoft Corp.
vix@ubvax.UB.Com (Paul Vixie) (10/25/87)
In article <152@uwspan.UUCP> plocher@uwspan.UUCP (John Plocher) writes: >[...] it >was brought to my attention that using the name of a single distributer >(Microport) to describe a group devoted to the product of many other >distributers (Bell Tech, Intel, Interactive Systems...) was not a Good >Thing to do. Because of this, the name was changed to: > > comp.unix.unix-at > >[...] Most of the 286 and >386 systems out there use the AT (I-BUS) for add on cards, so it was felt >that this name was fitting. John, I know you are trying to do a Good Thing, and I expect to benefit from this group. However, your assumption there at the end of what I've quoted from you article just Isn't Correct. There are several 386 machines I can think of that will run "UNIX System V/386" as ported by ISC for Intel and AT&T, that either use the "IBM PC/XT/AT" as an I-O bus only, or do not use it at all. Recent announcements from Compaq, AST Research, and even IBM will bear this out. The Texas Instruments 386 machine (trade name unknown, sorry TI!) also has its own bus. You've established that it ought not to be named after any single distributor; we've all more-or-less assumed that it there does need to be a group seperate from the comp.unix.sysv group for discussions about the V/386 version (which AT&T is very definitely treating specially and apart from its other offerings). I suggest that comp.unix.xenix can remain, for a while at least, until it is finally merged into the V/386 port (which I believe Microsoft/SCO/whomever are probably working on even as you read this). I'm not sure where to put the Microport/286 release, since it is actually a very seperate product from the V/386 product that is currently looming. However, the solution to this part of it may come from what I'm about to suggest for the V/386: comp.unix.sysv.386 (yeah, yeah, okay, it's ugly. However, it makes room for:) comp.unix.sysv.286 (which would be harder to mistake than anything else I've seen suggested.) So, how about: comp.unix.xenix leave it alone comp.unix.sysv.286 for uPort 286, Bell Tech 286, ??? comp.unix.sysv.386 for "UNIX System V/386" from all sources Disclaimer: I've used a lot of trademarks. They are all, hopefully, obvious. -- Paul Vixie Consultant Work: 408-562-7798 vix@ubvax.ub.com Ungermann-Bass Home: 415-647-7023 ames!pyramid!ubvax!vix Santa Clara, CA <<I do not speak for Ungermann-Bass>>
grr@cbmvax.UUCP (George Robbins) (10/27/87)
In article <152@uwspan.UUCP> plocher@uwspan.UUCP (John Plocher) writes: > > ... All this was in place and tested when it > was brought to my attention that using the name of a single distributer > (Microport) to describe a group devoted to the product of many other > distributers (Bell Tech, Intel, Interactive Systems...) was not a Good > Thing to do. Because of this, the name was changed to: > > comp.unix.unix-at > > This specifies that the OS is true Unix, and not Xenix (which has it's > own group) for any of the machines like the AT. Most of the 286 and > 386 systems out there use the AT (I-BUS) for add on cards, so it was felt > that this name was fitting. Aw, come on and get real. What is wanted is a group for the people who are using "microport" unix, and feel that the problems and issues are different enough from those of the xenix users. I see no need to get religious about it, people using microport under another name or something similar but different can share the group untill their problems start to differentiate. Please call this spade a spade. This is even sillier than the original "sys5" name. Just because a name is descriptive of a commercial product doesn't make it verboten. -- George Robbins - now working for, uucp: {ihnp4|rutgers|allegra}!cbmvax!grr but no way officially representing arpa: out to lunch... Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
root@uwspan.UUCP (John Plocher) (10/28/87)
+---- In article <2628@cbmvax.UUCP> George Robbins writes: | +---- In article <152@uwspan.UUCP> John Plocher writes: | | distributers (Bell Tech, Intel, Interactive Systems...) was not a Good | | Thing to do. Because of this, the name was changed to: | | | | comp.unix.unix-at | +---- | I see no need to get religious about | it, people using microport under another name or something similar but | different can share the group untill their problems start to differentiate. +---- [ Followups are being diverted to news.groups ONLY ] George, First some history: 286: AT&T hired Intel to port System5 to the 80286 line of CPUs Intel hired (for a while) DRI to help/do the port. Intel finished the port and it was validated by AT&T Some of the people from DRI/Intel formed their own company, which they called "Microport". Their aim was to sell the Unix which they had worked on to the AT market. Microport thus sells (retail) to Joe User. They also sell (non-retail) to Bell Tech who turn about and resell it. 386: AT&T hired Intel (again) to do the port to the 80386 Intel hired Interactive systems to do the port for them. Interactive finished the port, and gave it to Intel who in turn gave it to AT&T who validated it. Microport distributes a version of this code from ISC/Intel. Bell Tech distributes the generic code from ISC/Intel ISC sells a version of the code which they had sent to Intel/AT&T Then some conclusions: Thus it is *Intel*, and not Microport, that is the kingpin of these products. Since the group is to be for ALL of these different versions, calling it "microport" would not be calling "a spade a spade". By rights, it should really be called comp.unix.intel. How 'bout it? I'll be the first to admit that unix-at is a bit far fetched, but, as I see it, the name isn't really as important as you make it seem. We need a group where we can discuss Unix on "AT" class machines, no matter what it is called! -John
davidsen@steinmetz.UUCP (10/28/87)
In article <152@uwspan.UUCP> plocher@uwspan.UUCP (John Plocher) writes: +================ | When the proposal was submitted to the backbone it managed to set off a |major discussion of how the comp.unix layout should really be done. It was |felt that breaking it up into BSD/SYS5 camps wan not really what was needed |at this time, but a Microport group was desirable. |================ So far you show good common sense +================ | We proceeded slowly, installing the needed software, making sure that |Microport and Bell Tech both got news up and running so that they could |participate, tested links and aliases, and even found a method to "do" |this group with THREE moderators. All this was in place and tested when it |was brought to my attention that using the name of a single distributer |(Microport) to describe a group devoted to the product of many other |distributers (Bell Tech, Intel, Interactive Systems...) was not a Good |Thing to do. Because of this, the name was changed to: | | comp.unix.unix-at |================ You act on false assumptions here. The versions mentioned differ in device drivers and support software. Many of the problems discussed here have been related to either device drivers, the support group, or installation and customization. Since these are not common, there is no reason to group them. Also, most of the discussion to which there has been objection in the xenix group is microport based. Having created one vendor specific group for xenix, what is the reason for not having a group for microport. +================ | This specifies that the OS is true Unix, and not Xenix (which has it's |own group) for any of the machines like the AT. Most of the 286 and |386 systems out there use the AT (I-BUS) for add on cards, so it was felt |that this name was fitting. |================ I assume that since Xenix is developed from AT&T code it *is* "real unix." It has some modifications to the utilities, and uses its own compiler, but it is UNIX. I would suggest selection of one of the following solutions: 1) make the xenix group the "micro-unix" group, and devote it to all the flavors of UNIX which run on microcomputers. My definition: if the CPU is one chip it's a micro. Use keywords to identify areas of interest, rather than newsgroups. Include the unix-pc 3B1 portion of the att group here, too. 2) create a catch-all group as above and additional groups by vendor, such as xenix, uport, bell, inix. 3) create a catch-all group as above and additional groups by CPU type, as 80286, 80386, 68k, etc. I honestly believe that you are using groups to do the work of keywords. Many postings will be germane to several groups as you have structured them. Limiting the number of groups will limit the cross posting and overhead. Since you have gotten the vendors involved and otherwise done this very well, it would be a shame to see naming confuse the issue. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
tanner@ki4pv.uucp (Tanner Andrews) (11/01/87)
The "comp.unix.sys5.386" name looks an awful lot like an article number.
Sure, we know that most of the unbroken news software out there can skip
over the directory, but why tempt fate. Who knows how many buggy news
systems and home-brew "find"-based expire scripts there are out there?
--
{allegra clyde!codas decvax!ucf-cs ihnp4!codas killer}!ki4pv!tannerpeter@sugar.UUCP (Peter da Silva) (11/02/87)
The problem is that it's not people with Bell Tech or ISC or intel systems that form the majority of sys5/286 and sys5/386 volume. It's the people with Microport systems. Microport has had a lot of problems with bugs and apparent design flaws. The newsgroup is supposed to address these particular problems... so why shouldn't the name match the group (for once :->). -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.