woods@gpu.utcs.toronto.edu (Greg Woods) (08/16/88)
In article <728@wb3ffv.UUCP> howardl@wb3ffv.UUCP (Howard Leadmon ) writes: .... >comp.unix.i286 General 80286 UNIX discussions >comp.unix.i386 General 80386 UNIX discussions >comp.unix.i286.microport For System V/AT >comp.unix.i386.microport For System V/386 >comp.unix.i386.ix For IX from Interactive for the 80386 >comp.unix.i286.xenix For 80286 Xenix >comp.unix.1386.xenix For 80386 Xenix YES! PLEASE! Then I could rave at only the right people! :-) Seriously, we must do something about this, and this is the best I've seen. -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
dyer@spdcc.COM (Steve Dyer) (08/16/88)
In article <1988Aug16.011817.17102@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes: ]In article <728@wb3ffv.UUCP> howardl@wb3ffv.UUCP (Howard Leadmon ) writes: ].... ]>comp.unix.i286 General 80286 UNIX discussions ]>comp.unix.i386 General 80386 UNIX discussions ]>comp.unix.i286.microport For System V/AT ]>comp.unix.i386.microport For System V/386 ]>comp.unix.i386.ix For IX from Interactive for the 80386 ]>comp.unix.i286.xenix For 80286 Xenix ]>comp.unix.1386.xenix For 80386 Xenix ] ]YES! PLEASE! Then I could rave at only the right people! :-) ] ]Seriously, we must do something about this, and this is the best I've seen. This is known as news.groups.anal.retentive. Such a specialization would never work. You think the x-posting is bad between the xenix and microport groups now?? Comp.unix.intel, puleease. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer
rja@edison.GE.COM (rja) (08/17/88)
> In article <728@wb3ffv.UUCP> howardl@wb3ffv.UUCP (Howard Leadmon ) writes: > .... > >comp.unix.i286 General 80286 UNIX discussions > >comp.unix.i386 General 80386 UNIX discussions > >comp.unix.i286.microport For System V/AT > >comp.unix.i386.microport For System V/386 > >comp.unix.i386.ix For IX from Interactive for the 80386 > >comp.unix.i286.xenix For 80286 Xenix > >comp.unix.1386.xenix For 80386 Xenix This is excessive and still fails to address the point that Real Soon Now there won't be a hill of beans worth of difference between Xenix and the AT&T/Intel/interactive Systems/Microport/BellTech System V/386 port. Regular readers will recall that I do support the .i286 and .i386 groups in place of .microport and .xenix though not the bottom 5 groups. It does neatly separate the products based on cpu which is helpful for those of us who have to play with the memory adressing differences between the chips. I have used several different varieties of intel-cpu-based UNIX and find that Xenix 286 and System V/AT are a whole lot more in common in the bugs than the Sys V/AT and Sys V/386 versions are (or Xenix 286 and Xenix 386 for that matter.) Intel cpus aren't brain-damaged, they just act that way. ______________________________________________________________________________ rja@edison.GE.COM or ...uunet!virginia!edison!rja via Internet (preferable) via uucp (if you must) ______________________________________________________________________________ UNIX is a registered trademark of AT&T; Xenix is somebody else's tm.
wallace@cme-durer.ARPA (Evan Wallace) (08/18/88)
In article <1988Aug16.011817.17102@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > In article <728@wb3ffv.UUCP> howardl@wb3ffv.UUCP (Howard Leadmon ) writes: > .... > >comp.unix.i286 General 80286 UNIX discussions > >comp.unix.i386 General 80386 UNIX discussions > >comp.unix.i286.microport For System V/AT > >comp.unix.i386.microport For System V/386 > >comp.unix.i386.ix For IX from Interactive for the 80386 > >comp.unix.i286.xenix For 80286 Xenix > >comp.unix.1386.xenix For 80386 Xenix > > YES! PLEASE! Then I could rave at only the right people! :-) Let's get Bell Tech out of microport as well. I wouldn't mind merging the specialized groups to make room for this. Also in reference to comments by a previous poster about newsgroups named after products i286,i386 and unix are all product names as well!
jfh@rpp386.UUCP (The Beach Bum) (08/18/88)
there is precious little point in adding all those groups. someone will only think of a new way to add even more groups. what is needed is to take the uPort/Xenix flaming out of these groups for good. -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- apologizes to Dennis O'Connor
vixie@decwrl.dec.com (Paul Vixie) (08/19/88)
In <593@morticia.cme-durer.ARPA> wallace@cme-durer.ARPA (Evan Wallace) writes:
# Also in reference to comments by a previous poster about newsgroups
# named after products i286,i386 and unix are all product names as
# well!
T'was I. Very good point. I'll change the way I phrase that in the future.
My experience with various brands of UNIX(tm) for the 286 and 386 tells me
that there is basically Xenix and everybody else. All non-Xenix 286
products are basically similar, as are all non-Xenix 386 products. Yeah,
you can yell about details, but if someone wants to know how to directly
map CGA video memory in Bell Tech 386, chances are good that an answer
from an ISC expert will do the job.
UNIX System V release 4 is coming soon. This is due to include more stuff
from Berkeley, as well as new things from AT&T. I understand that Xenix/386
is already system-call compatible with UNIX V.3/386 (from ISC, Bell Tech,
and Microport); I am expecting UNIX V.4/386 to be more or less cause the
merge of Xenix and V/386 -- at least from a functional standpoint.
On this basis, I think that two newsgroups,
comp.unix.sysv.i286 and
comp.unix.sysv.i386
will divide the traffic according to the interests of the people who would
be reading it. There would be no cause for cross-posting. Both groups
should be moderated. The old groups,
comp.unix.xenix and
comp.unix.microport
should be destroyed in favor of these new groups.
I am still waiting for someone to give any reason -- even a flimsy reason --
why this separation is not a good idea.
--
Paul Vixie
Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP
Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul
Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013rick@pcrat.UUCP (Rick Richardson) (08/19/88)
In article <55@volition.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: >On this basis, I think that two newsgroups, > comp.unix.sysv.i286 and > comp.unix.sysv.i386 >be reading it. There would be no cause for cross-posting. Both groups >should be moderated. The old groups, > comp.unix.xenix and > comp.unix.microport >should be destroyed in favor of these new groups. >I am still waiting for someone to give any reason -- even a flimsy reason -- >why this separation is not a good idea. The separation is a good idea. The sysv is not needed since the merge is toward one base UNIX flavor. I doubt there will ever be an Intel BSD port, and who would want to refragment the world just as we finally get some peace? Moderation? Don't drag that up. Let's get the groups. If someone volunteers to moderate later, well, then we can start the to moderate or not wars again. -- Rick Richardson, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 389-8963 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
wnp@dcs.UUCP (Wolf N. Paul) (08/19/88)
In article <5562@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes: >there is precious little point in adding all those groups. someone will >only think of a new way to add even more groups. what is needed is to >take the uPort/Xenix flaming out of these groups for good. That's right. And if we were to create all these groups, the folks who want to flame and get maximum exposure for their flames (which is why they cross-post in the first place) would just cross-post to six groups instead of two. The signal-to-noise ratio cannot be lowered without the cooperation of those who chose to make noise, new groups won't do it. -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: killer!dcs!wnp ESL: 62832882 DOMAIN: wnp%dcs@killer.dallas.tx.us TLX: 910-380-0585 EES PLANO UD
beattie@visenix.UUCP (Brian Beattie) (08/19/88)
In article <1608@edison.GE.COM>, rja@edison.GE.COM (rja) writes: > > In article <728@wb3ffv.UUCP> howardl@wb3ffv.UUCP (Howard Leadmon ) writes: > > .... > > >comp.unix.i286 General 80286 UNIX discussions . . . > > >comp.unix.1386.xenix For 80386 Xenix > > This is excessive and still fails to address the point that Real Soon Now > there won't be a hill of beans worth of difference between Xenix and the > AT&T/Intel/interactive Systems/Microport/BellTech System V/386 port. when this is seen as true I will beleive it. The fact of the matter that what is being proposed is that Xenix will be made compatible. Microsoft will continue to try to give there product unique features. If they don't then what excuse do they have for existing. Please note that not everyone who buys System V/AT or System V/386 does so for price reasons, some of us do it because we want a system that conforms more closely AT&T (I'm still waiting for 4.4 BSD/386) -- Brian Beattie | (703)471-7552 MSDOS/OS2 | 11525 Hickory Cluster, Reston, VA. 22090 - just say no! | beattie@visenix.UU.NET | ...uunet!visenix!beattie
chip@ateng.uucp (Chip Salzenberg) (08/19/88)
According to vixie@decwrl.dec.com (Paul Vixie): >I am expecting UNIX V.4/386 to be more or less cause the >merge of Xenix and V/386 -- at least from a functional standpoint. Maybe, but it sure hasn't happened yet. And many problems and questions are related to OS _internals_, which I expect will always differ. I believe that these internal differences provide sufficient reason for a separate newsgroup for Xenix. >The old groups, > comp.unix.xenix and > comp.unix.microport >should be destroyed in favor of these new groups. Even if we pretend that SCO Xenix is System V, we shouldn't destroy comp.unix.xenix. Xenix is also available for the 68000, as many Tandy owners will affirm. Let's try this, instead: comp.unix.xenix Microsoft Xenix and its derivatives comp.unix.sysv.i286 AT&T Unix System V for the '286 comp.unix.sysv.i386 AT&T Unix System V for the '386 What say? -- Chip Salzenberg <chip@ateng.uu.net> or <uunet!ateng!chip> A T Engineering My employer may or may not agree with me. You make me wanna break the laws of time and space You make me wanna eat pork
davidbe@sco.COM (The Cat in the Hat) (08/19/88)
A long long time ago in an article far far away (<5562@rpp386.UUCP> to be exact) jfh@rpp386.UUCP (The Beach Bum) said:
-there is precious little point in adding all those groups. someone will
-only think of a new way to add even more groups. what is needed is to
-take the uPort/Xenix flaming out of these groups for good.
We probably won't do that until we either get a moderated
comp.unix.Xenix/uPort OR a comp.unix.flame group.
Comp.unix.flame has a certain appeal. Makes about as much sense as
splitting up into 286/386 groups.
Not that I'm suggesting it, mind you. Just pointing it out.
--
David Bedno (aka The Cat in the Hat) Now appearing at: davidbe@sco.COM -OR-
...!{uunet,decvax!microsoft,ucbvax!ucscc}!sco!davidbe -OR-
At home: 408-425-5266 At work: 408-425-7222 x5123 (I'm probably here...)
Disclaimer: Not SCO's opinions. At least not that they've told me.
"If you stand for nothing, you'll fall for anything."davidbe@sco.COM (The Cat in the Hat) (08/20/88)
A long long time ago in an article far far away (<55@volition.dec.com> to be exact) vixie@decwrl.dec.com (Paul Vixie) said:
-
-On this basis, I think that two newsgroups,
- comp.unix.sysv.i286 and
- comp.unix.sysv.i386
-will divide the traffic according to the interests of the people who would
-be reading it. There would be no cause for cross-posting. Both groups
-should be moderated. The old groups,
- comp.unix.xenix and
- comp.unix.microport
-should be destroyed in favor of these new groups.
-
-I am still waiting for someone to give any reason -- even a flimsy reason --
-why this separation is not a good idea.
Well...you want reasons, I've got some. I've been reading comp.unix.xenix
for a while, and haven't noticed a need for splitting up the group via
processor. The arguments talking about the merged product are fairly bogus
(in my opinion, of course) until such a product is actually released.
It's important to note that there tends to be little in the way of "How do
I do this for Y system on an N86?" Most of the questions I see are for
explanations of compiler errors (infinte spill), requests for diffs to
source code to allow Xenix compilation, and recommendations for hard/software.
None of these requests require a splitting of groups.
And also, I don't think there's enough volume to need splitting up the groups.
People can kill articles easily enough without a long delay.
The whole reason for creating comp.unix.microport was because of the flames
that were flying in c.u.x about Mport. While this may have been for the
better of the group (given human nature) I think it potentially hurt the
newsgroup. If I felt better about moderation in this type of group, I'd
suggest a moderated comp.unix.intel-arch for the discussion of Xenix and
other Unix and Unix-like OS's that run on intel machines. An unmoderated
version of this wouldn't be so bad if there were a comp.unix.flame...(.5 :-) )
After all, when the 486 comes out are we going to create a whole new newsgroup
just for that?
--
David Bedno (aka The Cat in the Hat) Now appearing at: davidbe@sco.COM -OR-
...!{uunet,decvax!microsoft,ucbvax!ucscc}!sco!davidbe -OR-
At home: 408-425-5266 At work: 408-425-7222 x5123 (I'm probably here...)
Disclaimer: Not SCO's opinions. At least not that they've told me.
"If you stand for nothing, you'll fall for anything."davidbe@sco.COM (The Cat in the Hat) (08/20/88)
In article <942@scovert.sco.COM> I (The Cat in the Hat) said (mistakenly):
-
-The whole reason for creating comp.unix.microport was because of the flames
-that were flying in c.u.x about Mport.
Before I get massive amounts of mail pointing it out, let me say that this
was not the ONLY reason this group was created. At the time of it's creation
there was about a 50/50 split in requests for info about SCO and Mport xenix,
so splitting it up seemed like a good idea.
There was quite a bit of Mport flaming also, and this WAS a factor. But not
the entire one. My apologies for not making this clearer in my previous
posting.
Also, my previous posting refers only to c.u.x, and not c.u.microport.
But I'm sure (by the inevitability of the net) that the same arguments
I used can apply.
--
David Bedno (aka The Cat in the Hat) Now appearing at: davidbe@sco.COM -OR-
...!{uunet,decvax!microsoft,ucbvax!ucscc}!sco!davidbe -OR-
At home: 408-425-5266 At work: 408-425-7222 x5123 (I'm probably here...)
Disclaimer: Not SCO's opinions. At least not that they've told me.
"If you stand for nothing, you'll fall for anything."plocher@uport.UUCP (John Plocher) (08/20/88)
>Let's get Bell Tech out of microport as well. I wouldn't mind
NO! This may sound strange, coming from someone who works for Microport,
but the ISC/Microport/BellTech/ATT productions of V.3 are so similar that
it doesn't warrent a different group for each of them. What *is* needed
is a combination of two things:
1) Better manners by all of us - this is a TECHNICAL newsgroup, not
a opinion poll; nor is it a flame test area. You all have my
phone and email addresses, use them instead of net.bandwidth
if you must gripe - email gets results, posted flames (may) simply
get ignored.
2) A change. Much as I like comp.unix.MICROPORT :-), the group
was founded as a technical discussion area for Unix on Intel CPUs.
This includes BT, ISC, AT&T, uport, and with V3.2, Xenix.
The recent spat of *suggestions* for new names ignores a few simple
facts:
The daily volume of the group is about 10 messages per day; .xenix
is similar. Does this volume require a split? NO.
Does the group discourage postings about/for BT, ISC, or AT&T? NO.
Does the name confuse people? YES.
What SINGLE name is there which covers all aspects of this group?
comp.unix.intel is the best compromise I can see. I'm not going to
worry too much if it doesn't get changed, though - I (and I'm sure
most other people) don't mind if others use this group too, if we
all keep in mind that this is supposed to be comp.unix, not talk.unix.
-John Plocherplocher@uport.UUCP (John Plocher) (08/20/88)
In article <55@volition.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: >I understand that Xenix/386 >is already system-call compatible with UNIX V.3/386 (from ISC, Bell Tech, >and Microport); Xenix 2.3 (announced as being avaliable on 8/15, shipping in "6 weeks") is Xenix with the ability to run COFF binaries (V/386 and V/286 stuff). AT&T Vr3.2 (shipping for the WGS series on 8/15) is Unix V with the ability to support Xenix: "This release supports the Microsoft Xenix application programming interface (with system call extentions supporting existing Xenix SystemV/386 and Xenix System V/286 applications) at both a source code and a binary executable level. The product inherits Xenix System V floating point emulation and provides extentions supporting Xenix semaphores, messages, shared data inode types, and mountable file systems. [Note: this does NOT specify object level compatibility. -John] "The system fully conforms to the SVID and is compatible with all previous releases of Unix System V on the Intel 80386 at a source, binary executable, and object code level. Unix System V/386 Release 3.2 also provides emulation routines supporting Unix System V/286 release 2 binary executables. The above quotes were taken from my copy of the AT&T Unix System V/386 Release 3.2 Product Overview manual which just came back from the print shop. ;-) > I am expecting UNIX V.4/386 to be more or less cause the >merge of Xenix and V/386 -- at least from a functional standpoint. Already done in 3.2. >On this basis, I think that two newsgroups, > comp.unix.sysv.i286 and > comp.unix.sysv.i386 why not just comp.unix.intel for all of the above - the volume does NOT demand a split. If you must split, why not comp.unix.intel, or comp.unix.Vr3/.Vr2 >Paul Vixie -John Plocher Microport Systems
samperi@marob.MASA.COM (Dominick Samperi) (08/20/88)
In article <177@dcs.UUCP> you write: >That's right. And if we were to create all these groups, the folks who want >to flame and get maximum exposure for their flames (which is why they >cross-post in the first place) would just cross-post to six groups >instead of two. The signal-to-noise ratio cannot be lowered without the >cooperation of those who chose to make noise, new groups won't do it. Most of the recent flames in this newsgroup were from people who desparately want to see the software that they paid for work correctly, or from people who want a reasonable amount of technical suppport in return for the support contract that they paid for. If these flames help to provide some incentive for the companies in question to deliver, then they have served a useful purpose, and are not noise. -- Dominick Samperi, NYC samperi@acf8.NYU.EDU samperi@marob.MASA.COM cmcl2!phri!marob uunet!hombre!samperi (^ ell)
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (08/20/88)
In article <1988Aug19.122042.19070@ateng.uucp> chip@ateng.UUCP (Chip Salzenberg) writes: > comp.unix.xenix Microsoft Xenix and its derivatives > comp.unix.sysv.i286 AT&T Unix System V for the '286 > comp.unix.sysv.i386 AT&T Unix System V for the '386 I agree, with one slight extension: comp.unix.sysv.i386 AT&T Unix System V for the '386 and Merged Xenix For the 286 systems, we need two groups, one for Xenix, and one for System V. For 386 we need (hopefully) only one group, for System V, and the merged Xenix system we are all waiting for with baited breath. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
vixie@decwrl.dec.com (Paul Vixie) (08/20/88)
In article <425@uport.UUCP> plocher@uport.UUCP (John Plocher) writes:
# Xenix 2.3 (announced as being avaliable on 8/15, shipping in "6 weeks")
# is Xenix with the ability to run COFF binaries (V/386 and V/286 stuff).
That's true -- Xenix and V/386 will be object compatible with eachother
and probably source-compatible to a degree. But since much of the traffic
on the net about a UNIX port is about system administration, installation,
internals, and other special witchery, I am convinced (recently) of a need
for a seperate comp.unix.xenix group. I'll even entertain a .i286/.i386/
.mc68k subdivision if volume warrants it. But let's not talk more about
that immediately.
# >On this basis, I think that two newsgroups,
# > comp.unix.sysv.i286 and
# > comp.unix.sysv.i386
#
# why not just comp.unix.intel for all of the above - the volume does NOT
# demand a split.
The volume on my info-386ix mailing list and the UNIX-related traffic on the
Davidsen's 386users mailing list might change your mind on that point. In
any case, we again have a situation where the sysadmin and installation for
286-based sysV is very different from sysadmin/install on 386-based sysV.
Since these are the sorts of things we often end up discussing, it makes
good sense to split the groups along those lines. Microport's V/AT product
has been reasonably popular and will probably continue to be. Nothing will
tick netnews readers off faster than having to skip half the articles in a
group, day after day, because they deal with a processor they don't have
and don't want to spend any time learning about.
This works in comp.unix.wizards because the number of different UNIX ports
being discussed is infinite :-). Here, we've got just a couple. I think
we can afford to split these.
# If you must split, why not comp.unix.intel, or comp.unix.Vr3/.Vr2 ?
Because some day, some ambitious idiot will make System V.4 run on a 286 :-),
and then where will we be?
--
Paul Vixie
Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP
Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul
Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013james@bigtex.uucp (James Van Artsdalen) (08/21/88)
In article <425@uport.UUCP>, plocher@uport.UUCP (John Plocher) wrote: > AT&T Vr3.2 (shipping for the WGS series on 8/15) is Unix V with the ability > to support Xenix: > "This release supports the Microsoft Xenix application programming interface > (with system call extentions supporting existing Xenix SystemV/386 and Xenix > System V/286 applications) at both a source code and a binary executable ^^^^^^ ^^^^^^^^^^ > level. [...] ^^^^^ > [Note: this does NOT specify object level compatibility. -John] Then what does "binary executable level" mean? > The above quotes were taken from my copy of the AT&T Unix System V/386 > Release 3.2 Product Overview manual which just came back from the print > shop. ;-) Interesting implications. Let us know when the boot disks come back from the duplication shop. > why not just comp.unix.intel for all of the above - the volume does NOT > demand a split. I agree here. I try to place "386" in the subject line of my GNU C postings, and figure a little more of this would eliminate the confusion. As for renaming the existing newsgroup to avoid being overly vendor-specific, I think it's a good idea, and I'm glad uPort volunteered, but I don't think it's worth the trouble. Inertia is a powerful thing on usenet. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
robert@pvab.UUCP (Robert Claeson) (08/21/88)
In article <55@volition.dec.com>, vixie@decwrl.dec.com (Paul Vixie) writes: > UNIX System V release 4 is coming soon. This is due to include more stuff > from Berkeley, as well as new things from AT&T. I understand that Xenix/386 > is already system-call compatible with UNIX V.3/386 (from ISC, Bell Tech, > and Microport); I am expecting UNIX V.4/386 to be more or less cause the > merge of Xenix and V/386 -- at least from a functional standpoint. System V Release 3.2 is the result of the Microsoft-AT&T agreement to merge UNIX and Xenix. Of course, AT&T added a bunch of their own inventions, such as a curses that supports color etc, a form and menu language interpreter (looks much like shell scripts) and kernel hooks for NFS. And a new 2K file system (I have the papers to the left of my terminal). This version of System V is shipping RSN (please correct me if I'm wrong) for both the 3b2's and (ta-dam!) 386 processors! I hope most UNIX vendors for 286 and 386 machines will use this as their base (I want this on my '286 at home). Similary, System V Release 4.0 will be the result of the Sun-AT&T agreement to merge UNIX and SunOS. Rumours has it that they will use Berkeley's file system... And it will have the ABI's for AT&T's own processors, the SPARC chip, the 386 chip and maybe a few others (ABI's for 68xxx, 88xxx and NS32xxx are under development). Release 4.0 will also have the Open Look user interface (Open Look is not a windowing system per se, but a user interface specification and guidelines implemented on top of various existing window systems, such as X and NeWS) and NFS. And, I guess, a lot of other new features (real-time extensions are promised). Just to clean up the confusion a bit.
plocher@uport.UUCP (John Plocher) (08/22/88)
+---- In article <6560@bigtex.uucp> James Van Artsdalen writes: | +---- In article <425@uport.UUCP>, John Plocher wrote: | | (with system call extentions supporting existing Xenix SystemV/386 and Xenix | | System V/286 applications) at both a source code and a binary executable | | level. [...] | | [Note: this does NOT specify object level compatibility. -John] | +---- | Then what does "binary executable level" mean? +---- I guess I can't talk with both feet in my mouth :-) I meant that it DOES NOT SEEM to imply that .o files are linkable together, or that .a (library) files would be either. If you would note that the second paragraph (talking about supporting existing Unix Vr2/286 and Unix Vr3/386 programs) specifically addresses this "object code" level then it seems significant. 1) source code \ Note that the overview mentions these 2) object code > three levels, of which only 1 and 3 are addressed 3) executable code / for Xenix/Unix compatibility! -John Plocher
det@hawkmoon.MN.ORG (Derek E. Terveer) (08/22/88)
In article <424@uport.UUCP>, plocher@uport.UUCP (John Plocher) writes: > What SINGLE name is there which covers all aspects of this group? > comp.unix.intel is the best compromise I can see. I have to agree. Since there seems to be a division between the 80x86 architecture and "other" (linear) architectures, regardless of merit, we could really come up with two types of Unix groups: comp.unix.segment (or comp.unix.seg) comp.unix.linear (or comp.unix.lin) Obviously, the 80x86 CPUs would inhabit the segmented unix groups and the 68000, National chips (N32???? something or other), etc., would live in the linear groups. This scheme would become more viable as the different flavours of unix converge more and more, until the only difference (in essence) would be the architecture of the CPU and the kludgey things one has to do to get code on one vs. the other. Choosing a name such as comp.unix.intel, is really the same thing as the names i've outlined above, except for substituting vendor names -- i guess "intel" has become synonomous with "segmented architechture". derek -- Derek Terveer det@hawkmoon.MN.ORG w(612)681-6986 "A proper king is crowned" -- Thomas B. Costain