ballentine_m@apollo.uucp (Mike Ballentine) (02/19/88)
Apollo Computer Inc. introduced its new Domain/OS operating system,
which integrates Network Computing System (tm) (NCS) architecture to
deliver the industry's only true distributed UNIX operating system.
Domain/OS is a single operating system offering three complete
operating environments -- the latest versions of the two industry
standards, AT&T's UNIX System V Release 3 and Berkeley 4.3 UNIX, and
Apollo's own Aegis (tm) operating environment.
Domain/OS adheres to AT&T's System V Interface Definition (SVID) --
making Apollo the first workstation vendor to announce SVID compliance
with UNIX System V -- and provides a clear migration path to POSIX.
For more information, contact your local Apollo representative.
Jim Barbagallo
Apollo Computer Public Relations
(617) 256-6600, x4453
UUCP: ...{mit-erl,mit-eddie,yale,uw-beaver,decvax}!apollo!barbagallo
USPS: Apollo Computer, 330 Billerica Rd., Chelmsford MAroberts@edsews.EDS.COM (Ted Roberts) (03/05/88)
In article <3a60e1e6.8cd8@apollo.uucp>, ballentine_m@apollo.uucp (Mike Ballentine) writes: > Apollo Computer Inc. introduced its new Domain/OS operating system... > > For more information, contact your local Apollo representative. Forgive me for being critical, but isn't this a bit out of place in comp.sys.apollo. I can see it in comp.newprod, but this is basically out and out advertising. Flame on you apollo. -- Ted Roberts | My opinions are not necessarily those EDS Technical Services Division | of my employer. Does that mean I'm UUCP: roberts@edsews.EDS.COM | wrong?
rees@apollo.uucp (Jim Rees) (03/08/88)
> Apollo Computer Inc. introduced its new Domain/OS operating system... > > For more information, contact your local Apollo representative. Forgive me for being critical, but isn't this a bit out of place in comp.sys.apollo. I can see it in comp.newprod, but this is basically out and out advertising. (Speaking here as a reader of this list, not as a rep of Apollo) As I recall, the guy who posts these asked the list if they wanted to see these, and the answer was 'yes'. I'm sure that if we want to change this policy and ban these notices, that we can do so. I know that at least some of the readers on the list like seeing these announcements, as long as they don't stray too far towards marketing hype (which I hate just as much as you do).
ken@usceast.UUCP (Ken Sallenger) (03/08/88)
In article <460@edsews.EDS.COM> roberts@edsews.EDS.COM (Ted Roberts) writes: >In article <3a60e1e6.8cd8@apollo.uucp>, ballentine_m@apollo.uucp (Mike Ballentine) writes: >> Apollo Computer Inc. introduced its new Domain/OS operating system... > >Forgive me for being critical, but isn't this a bit out of place in >comp.sys.apollo. I can see it in comp.newprod, but this is basically >out and out advertising. > >Flame on you apollo. Well, _THIS_ reader of comp.sys.apollo is interested, especially in software updates (;-( ...we're Unix jocks here, you see... and it does get closer and closer). In addition, Apollo's presence on the net, along with the community of knowledgeable users here, has saved me and my co-workers much grief, hair loss, etc. We've found out the answers to our problems before the problems occurred (no kidding), and sometimes before the regional sales people knew about them. And knowing what to ask for when you call in for support (both sales and technical) can save time and frustration on both ends. -- Ken Sallenger # Dept. of Computer Science +1 803 777-4611 ken@usceast.UUCP # Univ. of South Carolina, Columbia, SC 29208 ken@cs.scarolina.edu (CSNET)
grr@cbmvax.UUCP (George Robbins) (03/09/88)
In article <460@edsews.EDS.COM> roberts@edsews.EDS.COM (Ted Roberts) writes: > In article <3a60e1e6.8cd8@apollo.uucp>, ballentine_m@apollo.uucp (Mike Ballentine) writes: > > Apollo Computer Inc. introduced its new Domain/OS operating system... > > > > For more information, contact your local Apollo representative. > > Forgive me for being critical, but isn't this a bit out of place in > comp.sys.apollo. I can see it in comp.newprod, but this is basically > out and out advertising. I don't have any problem with press releases, as long as they are actually announcing something and not simple self-praise or hype. Please continue to post significant press releases... -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
bobr@zeus.TEK.COM (Robert Reed) (03/09/88)
In article <460@edsews.EDS.COM> roberts@edsews.EDS.COM (Ted Roberts) writes:
Forgive me for being critical, but isn't this a bit out of place in
comp.sys.apollo. I can see it in comp.newprod, but this is basically
out and out advertising.
In the past, I have been a major critic of Apollo in this newsgroup, but on
this occasion I must rise to their defense.
Before any of these marketing sales releases were posted to this net, the
folks at Apollo asked if it was appropriate to dump them here. The
consensus of silence implied acceptance. Commericial advertising is only a
problem on ARPANET--elsewhere it is merely an esthetic matter. Apollo has the
tacit approval of the net to deliver these announcements to this USENET
newsgroup.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKkrowitz@mit-richter.UUCP (David Krowitz) (03/10/88)
Actually, if I remember correctly, it was not the 'consensus of silence' which approved the posting of product announcements. I seem to remember seeing a tally of the "yea's vs. nay's" on the net, and it was definitely in favor of having the announcements posted here. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu mit-erl!mit-richter!krowitz@eddie.mit.edu mit-erl!mit-richter!krowitz@mit-eddie.arpa krowitz@mit-mc.arpa (in order of decreasing preference)
bcs212@vader.UUCP (Vince Skahan) (03/10/88)
In article <460@edsews.EDS.COM>, roberts@edsews.EDS.COM (Ted Roberts) writes: > In article <3a60e1e6.8cd8@apollo.uucp>, ballentine_m@apollo.uucp (Mike Ballentine) writes: > > Apollo Computer Inc. introduced its new Domain/OS operating system... > > > > For more information, contact your local Apollo representative. > > Forgive me for being critical, but isn't this a bit out of place in > comp.sys.apollo. I can see it in comp.newprod, but this is basically > out and out advertising. > > Flame on you apollo. > -- > Ted Roberts | My opinions are not necessarily those > EDS Technical Services Division | of my employer. Does that mean I'm > UUCP: roberts@edsews.EDS.COM | wrong? ===> anything that Apollo contributes that adds to what I know about what's on the way is a big help to me. I've got no problem with reading "advertising" and the resulting discussion of Apollo press releases - it's a whole lot better than buying something now when I can wait a bit and get what I really want. Speaking for myself, I think most people can interpret what is advertising and what is not (in their view) and handle it accordingly. I also welcome the input of the folks in Chelmsford on the net - it's also helpful to hear what they can provide to the at-large Apollo user community. (the above is NOT any criticism of the above writer so no flames, OK? I just thought another voice was needed.) ) -- Vince Skahan Boeing Computer Services - Phila. (215) 591-4116 INTERNET: bcs212%psev@boeing.com UUCP: {...rutgers!bpa | uw-beaver!uw-june!bcsaic}!vader!bcs212
neighorn@qiclab.UUCP (Steve Neighorn) (03/17/88)
The March 7, 1988 issue of Digital News carried an article entitled, "Apollo
PRISM Series Yields 'Personal Super.' The article was written by one Evan
Schwartz. Now for the reason this message is being posted:
On page 3 of the magazine, Mr. Schwartz writes:
"The Domain 10000's are object code-compatible with Apollo's existing
workstation family. However, source code running on current Apollo
machines must be recompiled to run on the new faster systems, a job
that Apollo officials said requires some work.
As a result, Apollo cannot claim that it offers a line of fully
software-compatible systems, such as Digital Equipment Corp. can
claim with its VAX family, a drawback that industry analysts say
is significant but it offset by the new workstation's speed."
I will publicly apologize if I am missing the "big picture" here, but
how can the 10000 be object code compatible with current machines at the
same time source code running (?) on current machines requires 'some
work' to be recompiled? Is this a glitch in the Digital News article, or
did I forget to oil the semantic brain cells this morning?
I would appreciate some kind soul clearing this up, as I and I suspect
several of my co-workers are in a sort of suspended tele-electronic lust
with the 10K at the moment. Thanks much.
--
Steven C. Neighorn !tektronix!{psu-cs,reed,ogcvax}!qiclab!neighorn
Portland Public Schools "Where we train young Star Fighters to defend the
(503) 249-2000 ext 337 frontier against Xur and the Ko-dan Armada"crgabb@sdrc.UUCP (Rob Gabbard) (03/17/88)
In article <1060@qiclab.UUCP>, neighorn@qiclab.UUCP (Steve Neighorn) writes: > "The Domain 10000's are object code-compatible with Apollo's existing > workstation family. However, source code running on current Apollo > machines must be recompiled to run on the new faster systems, a job > that Apollo officials said requires some work. > > I will publicly apologize if I am missing the "big picture" here, but > how can the 10000 be object code compatible with current machines at the > same time source code running (?) on current machines requires 'some > work' to be recompiled? Is this a glitch in the Digital News article, or > did I forget to oil the semantic brain cells this morning? > This kind of statement has been made elsewhere, and it is confusing. I may need to be corrected here, but I believe that the copatibility resides in data file compatibility. In other words, a DN10000 can reside on the same DOMAIN as a Motorola based DNXXXX. The DN10000 is source code copatible with recompiling necessary. This is to be expected - look at the SUN4 and HP825 series. You can't expect a RISC based machine to be object code compatible with a Motorola based CPU - unless you'd like to write a Motorola emulator. Come to think of it, considering the speed of these new super workstations, an Intel or Motorola emulator may be able to acheive the speed of the original instead of drudging along slower than a 4.77Mhz PC (ala. Amiga transformer). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rob Gabbard | UUNET: uunet!sdrc!crgabb Workstation Systems Programmer | PHONE: (513)576-2600 Structural Dynamics Research Corporation | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
slocum@hi-csc.UUCP (Brett Slocum) (03/18/88)
In article <1060@qiclab.UUCP> neighorn@qiclab.UUCP (Steve Neighorn) writes: >I will publicly apologize if I am missing the "big picture" here, but >how can the 10000 be object code compatible with current machines at the >same time source code running (?) on current machines requires 'some >work' to be recompiled? My sales update from Apollo says: "...the Series 10000 is source-code and binary data compatible with Apollo's entire product family..." This means that use need to recompile programs, but that you don't need to recreate data files, repopulate databases, and other data-oriented operations. I hope this clears things up. -- Brett Slocum UUCP: ...{uunet,ihnp4!umn-cs}!hi-csc!slocum Arpa: hi-csc!slocum@umn-cs.arpa "My name is Inigo Montoya. You killed my father. Prepare to die."
chan@hpfcmr.HP.COM (Chan Benson) (03/18/88)
> "The Domain 10000's are object code-compatible with Apollo's existing > workstation family. However, source code running on current Apollo > machines must be recompiled to run on the new faster systems, a job > that Apollo officials said requires some work. I attribute this to brain-damaged journalism. Typical for trade rags. > I would appreciate some kind soul clearing this up, as I and I suspect > several of my co-workers are in a sort of suspended tele-electronic lust > with the 10K at the moment. Thanks much. Don't get too excited. The report in EE Times said that they don't even have any prototypes running yet. -- Chan Benson
mishkin@apollo.uucp (Nathaniel Mishkin) (03/18/88)
In article <1060@qiclab.UUCP> neighorn@qiclab.UUCP (Steve Neighorn) writes: >On page 3 of the magazine, Mr. Schwartz writes: > >"The Domain 10000's are object code-compatible with Apollo's existing > workstation family. However, source code running on current Apollo > machines must be recompiled to run on the new faster systems, a job > that Apollo officials said requires some work. > >I will publicly apologize if I am missing the "big picture" here, but >how can the 10000 be object code compatible with current machines at the >same time source code running (?) on current machines requires 'some >work' to be recompiled? Someone pretty clearly lost a "not" here. The DN10000 (quick: did I get the number of zeros right?) is NOT object-code compatible with Apollo's 680x0 machines. We did try hard to remain DATA compatible the 680x0 machines. Not surprisingly, the 10000 is a big-endian machine and uses IEEE floating point. (Oh yeah, we decided to stick with ASCII too :-) A more insidious issue in the RISC arena is data alignment. RISC machines really want data to be naturally aligned; i.e. that N byte quantities start on memory locations that are 0 MOD N. Consider a program that writes out a file of structs of the form: struct s { short foo; /* 16 bits */ long bar; /* 32 bits */ } (I mean "write(fd, v, sizeof v)" where "s" is a "struct s".) Fortran programmers do the equivalent sort of thing ALL the time. Believe me. It seems like it'd be nice in these days of distributed file systems if you could read back that data on another machine made by the same vendor using a program compiled from the exact same source. Most (I think) 680x0 compilers lay out this struct as 6 bytes. Many RISC compilers would be tempted to lay it out as 8 bytes (with a two-byte hole between "foo" and "bar") to get the long to be naturally aligned. We chose to make the DN10000 compilers by default use the 680x0 data alignment rules to make sure that a binary file written on a DN4000 could be read on a DN10000. Of course, there's a price (the 10000 will access the data slower than it otherwise would have) but no one said compatibility came cheap. Of course, the 10000 compilers will tell you (if you don't tell them not to) about all the cases where they're unhappy about how the alignment is working out, and you can tell them to override the default alignment rules and use natural alignment if you're not worried about these data compatibility issues. A variant of this case is where you pass a pointer to procedure that's expecting a (say) "long *" but you passed "&v.bar" as the parameter. In this case, the compiler can't know that you might have done this. It assumes that the argument is a pointer to a naturally aligned long and compiles the code accordingly. However, at runtime, a hardware trap will occur (the equivalent of "odd address error" on a 680x0) and software will automatically figure out what happened and cough up the right data. The cost of this feature is even higher than cost of the feature described above. But it works (and you can fix your code if you want to). -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {decvax,mit-eddie,umix}!apollo!mishkin