kato@etlcom.etl.JUNET (Toshikazu Kato) (04/06/88)
Hello! [1] NCS (Network Computing System) Does anyone know the current status of NCS implementation on several kinds of machines? I've heard that third parties have decided to do on Sun, Vax, Cray, etc., but I don't know the current status. From when will they be available? [2] NCS vs NFS+rpc What is the difference of NCS and the combination of NFS (Network File System) with rpc (remote procedure call)? Which is more powerful and easy to builtin to application programs? Thanks in advance... Toshikazu Kato PS. I've read this news group (comp.sys.apollo) after a long interval, and found it is becoming active. In Japan, we have an apollo users group mailing list (independent from Apollo Corp. and from ADUS). It's address is: apollo.users%etl.jp@relay.cs.net -- Toshikazu KATO Information Systems Section, Electrotechincal Laboratory, Japan JUNET(domestic): kato@etl.junet CSNET(over-sea): kato%etl.jp@relay.cs.net
mishkin@apollo.uucp (Nathaniel Mishkin) (04/09/88)
In article <7075@etlcom.etl.JUNET> kato%etl.jp@relay.cs.net writes: >[1] NCS (Network Computing System) > >Does anyone know the current status of NCS implementation on >several kinds of machines? >I've heard that third parties have decided to do on Sun, Vax, >Cray, etc., but I don't know the current status. >From when will they be available? NCS has run on a variety of 4.2 and 4.3 machines (including Sun, VAX, Alliant, Multiflow), System V (R2 and R3, with BSD sockets) (including Unicos) MS/DOS, and VMS. We expect that support for NCS binaries will come from both Apollo and 3rd parties. (Sorry, I really don't know what I'm "allowed" to say.) The source to NCS is available to universities under license for a nominal fee. >[2] NCS vs NFS+rpc > >What is the difference of NCS and the combination of NFS (Network >File System) with rpc (remote procedure call)? >Which is more powerful and easy to builtin to application programs? Obviously, I'm biased, but I think it's pretty clear that as a suite of tools for developing distributed applications (especially ones with demands more complicated than distributed file system applications tend to have), NCS is both more powerful and easy to use. The features of NCS were described in a paper in the Summer '87 Usenix. You can send me mail if you want more information. -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {decvax,mit-eddie,umix}!apollo!mishkin
wesommer@athena.mit.edu (William Sommerfeld) (04/09/88)
In article <3b57a3de.13422@apollo.uucp> mishkin@apollo.UUCP (Nathaniel Mishkin) writes: >>[2] NCS vs NFS+rpc >> >>What is the difference of NCS and the combination of NFS (Network >>File System) with rpc (remote procedure call)? >>Which is more powerful and easy to builtin to application programs? > >Obviously, I'm biased, but I think it's pretty clear that as a suite of >tools for developing distributed applications (especially ones with >demands more complicated than distributed file system applications >tend to have), NCS is both more powerful and easy to use. The features >of NCS were described in a paper in the Summer '87 Usenix. \begin{disclaimer} I may be marginally biased, as I will start working for Paul Leach (Nat's boss) in July (assuming I get my thesis done ;-)). I have not done any work on any Apollo systems (well, I did type a few commands on one of their machines at their recruiting open house..), but am starting to use NCS on BSD4.3 unix on a microVAX. I'm only reading this newsgroup to try to get a feel for what I just committed myself to.. \end{disclaimer} I have looked at both Sun RPC/NFS and Apollo NCS sources. I wish I had seen NCS about a year ago; it would have saved me the effort of writing my own pseudo-RPC system for a major project I worked on last summer. Sun RPC just did not have the functionality for what I was trying to do (like the ability to allow the server to call back to the client while the client is waiting for a response from the server). Given the choice between using raw UDP datagrams and using SunRPC, I'd rather use raw UDP, because I could do a better job; I would not say the same about NCS. I was not impressed by the quality of Sun NFS or RPC. Well, SunRPC works (sort of) if you don't push it too hard. It appears that Apollo's staff understands the ideas of _modular progamming_ and _clean interfaces_ a lot better than Sun's staff does---library routines should NOT call fprintf(stderr, ...) and then abort() (or panic() in the case of kernel routines) in the event of errors. NCS also gives you a much richer programming environment; in the UNIX distribution, you get a simple exception handling package of sorts layered on setjmp()/longjmp() which lets you unwind the stack cleanly in the presence of failures, a timer manager package, etc. I heard some talk of eventually providing a semi-portable version of the tasking code. On the down side for NCS (trying to be fair here): NCS isn't bug-free; the interface compiler (or at least the version I was playing with) does seem to need a bit of work in its error recovery, and has choked on a few of the twisted things I've tried to feed it (but I can name C compiler products which choke on much more mundane inputs). Source is reportedly quite expensive if you aren't an educational institution, although the charge to universities (a $50 tape-handling fee?) is about right. The identifier naming conventions are unusual for UNIX (but look real familiar to anyone who ever did any programming on Multics..). If you have a strong revulsion to the use of the `$' character in identifiers (possibly caused by a bad reaction to MIT's killer software engineering courses ;-) ), this may be an issue. This also causes problems with overly pedantic ANSI C compilers like MetaWare's Hawaiian Punch (um, High C) compiler: it seems to treat `$' as `begin comment'. The distribution does contain a hacked version of the DECUS cpp which strips out the `$'s. If you're familiar with UNIX, the documentation is a little confusing on the first pass until you build a mental translation table; they seem to use the term `system call' for things which (in the UNIX world) are implemented as library functions, and the documentation refers to C functions as `procedures'. Oh well, back to the thesis... - Bill Sommerfeld wesommer@athena.mit.edu
benoni@ssc-vax.UUCP (Charles L Ditzel) (04/10/88)
> In article <7075@etlcom.etl.JUNET> kato%etl.jp@relay.cs.net writes: > >[2] NCS vs NFS+rpc Actually this may be of interest to you and others but an article I finished reading recently (I am sorry...don't know what mag) mentioned that AT&T was adopting Sun's ONC (Open Network Computing) and not Apollo's NCS. (I will try to dig up the article and give you the reference) ONC has been around a bit longer than NCS and is based on RPC (Remote Procedure Call) specification. The ONC platform also includes exdended data representation (xdr). XDR provides an vendor-independent method of representing data. There are a number of elements to ONC (like NFS, REX (Remote Execution service).... Sun's ONC architecture has been around for awhile and has a number of adopting vendors...(Alliant,Apollo, Arete, DEC, Dana, Gould, Harris, HP, Honeywell, Masscomp, MIPS, NEC, Pyramid, Ridge, SGI, Sony, Stellar, etc) and universities.
mishkin@apollo.uucp (Nathaniel Mishkin) (04/12/88)
In article <1848@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >> In article <7075@etlcom.etl.JUNET> kato%etl.jp@relay.cs.net writes: >> >[2] NCS vs NFS+rpc >Actually this may be of interest to you and others but an article I >finished reading recently (I am sorry...don't know what mag) mentioned that >AT&T was adopting Sun's ONC (Open Network Computing) and not Apollo's >NCS. (I will try to dig up the article and give you the reference) >ONC has been around a bit longer than NCS and is based on RPC (Remote >Procedure Call) specification. The ONC platform also includes >exdended data representation (xdr). XDR provides an vendor-independent >method of representing data. There are a number of elements to ONC >(like NFS, REX (Remote Execution service).... Just in case it's not clear, NCS supports a data representation protocol as well (NDR, Network Data Representation), which we feel has certain advantages over XDR. In particular, with NDR, if the communicating machines have a common data representation (that is one of a set of popular data representations), no data conversion is done when those machines talk to each other. With XDR, supposing you have two 368-based Unix systems talking to each other, integers are swapped twice -- once by the sender and once by the receiver -- when those systems talk to each other. If you think that the byte-swapping is in the noise (it's not clear it is as network throughput gets better) consider two processes talking to each other on the same 386-based machine via RPC. In this case, the communications overhead is small and the byte-swapping would seem to be a bottleneck. Further, in the case of floating point numbers, *any* conversion -- no matter how efficient -- might be considered numerically unacceptable. >Sun's ONC architecture has been around for awhile and has a number >of adopting vendors...(Alliant,Apollo, Arete, DEC, Dana, Gould, Harris, >HP, Honeywell, Masscomp, MIPS, NEC, Pyramid, Ridge, SGI, Sony, Stellar, >etc) and universities. Excuse me if I claim that this list is a bit of hype. For example, Sun declared that Apollo has "adopted ONC" based on the fact that we support Sun NFS. That's a fairly outlandish extrapolation, from our point of view. No one asked us if we thought we had "adopted ONC". Thus, it's hard to know what to make of the other people on that list. In any case, I doubt that the number of sophisticated applications built on top of anyone's RPC system is very large, and in particular, I wouldn't be surprised if there are a comparable number of remote procedure definitions written in NCS and in ONC. (I'll admit that Apollo may be the source of many of the NCS definitions, but Sun is probably the author of most of the ONC definitions as well.) (Major bias alert: Further, I can't imagine writing sophisticated applications like our replicated location database service, user registry, or license server using the limited tools that ONC provides.) So the issue of how many people "adopted ONC" or how long ONC has been around doesn't seem very important. Certainly, it's still early enough to make judgements based on technical merit. -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {decvax,mit-eddie,umix}!apollo!mishkin
geoff@eagle_snax.UUCP ( R.H. coast near the top) (04/14/88)
In article <3b66e520.13422@apollo.uucp>, mishkin@apollo.uucp (Nathaniel Mishkin) writes: > In article <1848@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: > >Sun's ONC architecture has been around for awhile and has a number > >of adopting vendors...(Alliant,Apollo, Arete, DEC, Dana, Gould, Harris, > >HP, Honeywell, Masscomp, MIPS, NEC, Pyramid, Ridge, SGI, Sony, Stellar, > >etc) and universities. > > Excuse me if I claim that this list is a bit of hype. For example, Sun > declared that Apollo has "adopted ONC" based on the fact that we support > Sun NFS. That's a fairly outlandish extrapolation, from our point of > view. No one asked us if we thought we had "adopted ONC". Huh? Apollo has licensed the NFS trademark and is offering an NFS product. I presume (though I haven't checked) that you, like most of the other licensees, supply the programming libraries along with the NFS capability. "Adopted" has many interpretations, but this doesn't seem an unreasonable one. Certainly it doesn't imply exclusivity. And anyone who goes to Uniforum knows just how real NFS/ONC support is - almost all vendors (including IBM) offer it. No hype. I'm the PC-NFS architect, and a significant proportion of the questions that come my way relate to networks without Suns - just PCs and VAXen, HPs, Pyramids, etc. I'm not knocking NCS - I think there are some really important advances in distributed computing embodied in it - but dismissing the ONC phenomenon as "hype" is just plain unrealistic. -- Geoff Arnold, Sun Microsystems | "Universes are just one of those things SPD at ECD (home of PC-NFS) | that happen from time to time..." UUCP:{ihnp4,decwrl...}!sun!garnold | [Dunno who said it - if you know, pass it ARPA:garnold@sun.com | on. G.A.]
mishkin@apollo.uucp (Nathaniel Mishkin) (04/17/88)
In article <280@eagle_snax.UUCP> geoff@eagle_snax.UUCP ( R.H. coast near the top) writes: >In article <3b66e520.13422@apollo.uucp>, mishkin@apollo.uucp (Nathaniel Mishkin) writes: >> In article <1848@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >> >Sun's ONC architecture has been around for awhile and has a number >> >of adopting vendors...(Alliant,Apollo, Arete, DEC, Dana, Gould, Harris, >> >HP, Honeywell, Masscomp, MIPS, NEC, Pyramid, Ridge, SGI, Sony, Stellar, >> >etc) and universities. >> >> Excuse me if I claim that this list is a bit of hype. > >Huh? Apollo has licensed the NFS trademark and is offering an NFS >product. I presume (though I haven't checked) that you, like most of the other >licensees, supply the programming libraries along with the NFS capability. >"Adopted" has many interpretations, but this doesn't seem an unreasonable one. >Certainly it doesn't imply exclusivity. Come on. First of all, Sun's marketing brochures don't just say "adopted" or "adopted NFS". They say "adopted ONC". If one is to take the marketing brochures seriously, "ONC" refers to a grand, panoramic distributed architecture. The brochures say "adopt" instead of simply "incorporate pieces of" because they want to give the impression that people/companies have accepted the entire architectural approach. We haven't. We support NFS. We support Fortran too, but I think people would get a funny (and incorrect) impression of us if we (or others) said we had "adopted Fortran". Anyway, the point isn't really what you (or Sun in general) take "adopted ONC" to mean. The fact is that (in my humble personal opinion), Sun would have done well to ask the companies listed in their brochures whether they had "adopted ONC" before listing them. No one asked us. BTW, as far as I know, we don't ship Sun RPC runtime library binaries as part of our product. Why should we? We ship NCS. (People who for some reason want Sun RPC have plenty of alternative sources.) The point that's most relevant to this discussion is that, for sure, our customers (understandably) clamored for us to support NFS, so we now do; they haven't been clamoring for the Sun RPC runtime library. -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {decvax,mit-eddie,umix}!apollo!mishkin
wesommer@athena.mit.edu (William Sommerfeld) (04/17/88)
The cause of the recent dispute between Nat Mishkin and Geoff Arnold is reminiscent of another goof by Sun's marketing which occurred almost two years ago. At the time, I was working as a summer intern for Jim Gettys at MIT/Project Athena; he and Bob Scheifler (among others) were working on the preliminary design of X version 11, and were also in the process of attempting to make it as widespread as possible. NeWS was just beginning to rear its head out of Sun. Some Sun marketing person put out a press release claiming that MIT was dropping X in favor of NeWS. JG & RWS were understandibly very upset about this. Fortunately, they complained loudly enough that Sun sent out a retraction of the press release. I guess Sun does marketing by claimed peer pressure: "Everyone else is using our stuff, why aren't you?". As a side note: MIT/Athena uses NFS, mostly because it's a defacto industry standard. We'd rather be using an architecture more like CMU's Vice filesystem, but at the point in time when we had to commit to a particular filesystem type, Vice wasn't really in shape to be imported by us. We don't use Yellow Pages, because it's a crock (we have our own user registration database/name server which has much lower overhead, and which is easier to administer). If asked, I would certainly deny that we had "adopted ONC". - Bill
celerity@bucasb.bu.edu (Roger B.A. Klorese) (04/18/88)
In article <280@eagle_snax.UUCP> geoff@eagle_snax.UUCP ( R.H. coast near the top) writes: >> Excuse me if I claim that this list is a bit of hype. For example, Sun >> declared that Apollo has "adopted ONC" based on the fact that we support >> Sun NFS. That's a fairly outlandish extrapolation, from our point of >> view. No one asked us if we thought we had "adopted ONC". >Huh? Apollo has licensed the NFS trademark and is offering an NFS >product. "Adopted" has many interpretations, but this doesn't seem an >unreasonable one. Certainly it doesn't imply exclusivity. >And anyone who goes to Uniforum knows just how real NFS/ONC support >is - almost all vendors (including IBM) offer it. No hype. The objection is to the term "adopted ONC"; this sounds like these other vendors have committed corporate resources to the furtherance of the "ONC platform". In fact, most of these licensed NFS because they were driven to by market pressure, long before the ONC buzzword (for "Omnibus of Network Confusion"?) was a gleam in some Sun marketeer's eye. Many of these vendors, if asked, if they believed in UNIX, would say "yes". But if asked if they believe in ONC, they would hedge about a need to play in mixed networks, or to supply ad hoc standards. This is hardly "adopting" ONC, unless your idea of adoption involves grudgingly letting a child stay in your house because that's the only way you'll keep getting the foster care subsidy, and worrying about what the little bastard will spring on you next... ;-)
benoni@ssc-vax.UUCP (Charles L Ditzel) (04/18/88)
In article <4673@bloom-beacon.MIT.EDU>, wesommer@athena.mit.edu (William Sommerfeld) writes: > The cause of the recent dispute between Nat Mishkin and Geoff Arnold > is reminiscent of another goof by Sun's marketing which occurred Why do you think it is necessarily a "goof". Apollo licensed a Sun product. That's a simple fact. Whether Apollo chose to include Sun's RPC package is Apollo's business. > process of attempting to make it as widespread as possible. NeWS was > just beginning to rear its head out of Sun. Some Sun marketing person > put out a press release claiming that MIT was dropping X in favor of > NeWS. JG & RWS were understandibly very upset about this. Speaking of NeWS, (again) a number of companies are developing merged X11/NeWS ports - Sun, Silicon Graphics (it already done and is being shown), Santa Cruz Operations (the Xenix folks will offer one). Will Apollo offer NeWS/X11? Having looked at X11 and NeWS, X11 looks pretty weak. Gee...while i'm in an inquisitive mood...here are some more questions for you Apollo guys. Will Apollo be adopting the AT&T/Sun/Xerox Open Look user interface? (Given now that Lotus and Ashton-Tate will be writing for Unix System V Release 4.0) Will Apollo adopt System V Release 4.0? ------------------------- Naturally My Opinions Are My Own.