dls@cci632.UUCP (Darren Swartzendruber) (11/17/89)
I am looking for a copy of the "The White Paper", also know as
Apollo NCA and Sun ONC: A Comparison". _HP Design & Automation_
(Sept 1989) states that "Apollo had made the paper available to
the industry-at-large." Can someone email to me as well as posting
it.
Thanks.
Currently fighting the question:: What shall we buy: Sun or Apollo!?!
--
Darren Swartzendruber CCCCCCCCCCC CCCCCCCCCCC IIIIIIIIII
CC CC CC CC II II COMPUTER
dls@cci632 CC CCC CC CC CCC CC IIII IIII CONSOLES,
rochester!rit!cci632!dls CC CCCCCCC CC CCCCCCC IIII IIII INCORPORATED
uunet!ccicpg!cci632!dls CC CCC CC CC CCC CC IIII IIII
uunet!rlgvax!cci632!dls CC CC CC CC II II An STC Company
rayssd!cci632!dls CCCCCCCCCCC CCCCCCCCCCC IIIIIIIIIImishkin@apollo.HP.COM (Nathaniel Mishkin) (11/21/89)
In article <31904@cci632.UUCP>, dls@cci632.UUCP (Darren Swartzendruber) writes: > I am looking for a copy of the "The White Paper", also know as > Apollo NCA and Sun ONC: A Comparison". _HP Design & Automation_ > (Sept 1989) states that "Apollo had made the paper available to > the industry-at-large." Can someone email to me as well as posting > it. The paper is (for better or worse) in Interleaf format and is moderately long, which are a couple of the reasons I've not distributed it electronically. (I'm also not sure I wanted to be pummeled for distributing it -- but you asked...) So what I've done is to make Interleaf generate a Postscript file and then compress'd, uuencode'd, split, and shar'd it. (I'd be glad to hear from anyone who knows a better way to do this. Maybe having a man page for shar handy would have helped :-) The result is 3 pieces I will post following this message. If you get the 3 shar files and run them and then run "make", you should end up with a file called "comparison.ps", which should be plain old Postscript which you can print. Let me make a few things clear: First, it is based on my knowledge about current product offerings. Second, I take personal responsibility for the content. This is NOT some official pronouncement of HP. The documented started off its life as a writing down of my repeated verbal responses to the question "So what makes NCS different from Sun RPC?". If anyone has any complaints, comments, or corrections, please let me know and I will address them as soon as I possibly can.
joshua@athertn.Atherton.COM (Flame Bait) (11/26/89)
We are talking about Apollo/HP's white paper comparing Apollo's Networking system and Sun's Networking system. The version of the paper which I have is dated Jan. 1988. If a new version has come out since then, my comments would be out of date. mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: >Let me make a few things clear: First, it is based on my knowledge about >current product offerings. Had you actually written any Sun RPC programs at the time you wrote the paper? I got the impression that the author of the White Paper had not actually used Sun RPCs. >Second, I take personal responsibility for >the content. This is NOT some official pronouncement of HP. Too late for that. The copy I got about 10 months ago from Apollo has Apollo's name all over it, and does not have your name on it at all. It was an "official pronouncement" of Apollo then :-). >If anyone has any complaints, comments, or corrections, please let me >know and I will address them as soon as I possibly can. 0. The paper is out of date by two years at least. Many things have chagned since it was written. 1. The paper is marketing propaganda with a thin veneer of technical knowledge. 2. Never use the paper's arguments in a debate with someone who understands Sun's RPC: you'll be cut to shreads. The facts about Sun's RPC are often out of date or inaccurate, the facts about Apollo's RPC are often technically acurate, but totally misleading. There are two ways to compare Sun's and Apollo's networking systems, technically and intuitively. Technically would take many pages to handle in detail, but here is a quick inituitive comparison: Apollo's networking system is like VMS's file system; Sun's networking system is like UNIX's file system. VMS is a file system of features. It directly supports all kinds of special purpose files, it has record based files and stream based files, all kinds of files. UNIX only has one kind of file, but it is flexible and easy to use. VMS has features; UNIX has simplicity. If you make a feature by feature comparison, Apollo's networking system has more features than Sun's. But, if you want simplicity and ease of use, then Sun's is the winner. Apollo's RPC is like PASCAL; Sun's RPC is like C. Since it was designed as a teaching language, PASCAL forces you to write programs the way the designer wanted programs written. C is a language designed to to what the programmer wants, right or wrong. PASCAL says "this is the best way to do things", C says "here is a flexible language, do what you want". For example, Apollo's RPC forces you to use their beefed up UDP transport protocol. Sun's RPC allows you to use UDP or TCP as a transport protocols, your choise. Apollo makes it very difficult to use any interface language except NIDL. Sun provides RPCGEN, but also makes it easy to roll your own interface language, if you want to. Apollo makes it very difficult to use any data representation except their's (NDR). Sun makes it easy to replace their representation (XDR), if you want to. Finally, Sun's RPC system has always been an open system; Apollo's is just now opening up (and even now, is opening in a marketing/buzzword sense of the word). The know this is an emotional issue, but lets face it. Sun's RPC source code has been freely distributable for three or four years. Apollo's source is still not freely distributable. Apollo uses a proprietary, private communications protocol. Sun uses public protocols when possible, and publishes their protocols, when they are forced to create their own. disclaimer: I do not work for Sun or Apollo. I have never worked for Sun or Apollo. I have used both Sun's and Apollo's RPC systems, but not their complete networking sytems. I speak for me: no one else. Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822
achille@cernvax.UUCP (achille petrilli) (11/26/89)
In article <14983@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes: >We are talking about Apollo/HP's white paper comparing Apollo's Networking >system and Sun's Networking system. The version of the paper which I have >is dated Jan. 1988. If a new version has come out since then, my comments >would be out of date. > ....... >0. The paper is out of date by two years at least. Many things have chagned > since it was written. > >1. The paper is marketing propaganda with a thin veneer of technical knowledge. > >2. Never use the paper's arguments in a debate with someone who understands > Sun's RPC: you'll be cut to shreads. The facts about Sun's RPC are often > out of date or inaccurate, the facts about Apollo's RPC are often > technically acurate, but totally misleading. > >Joshua Levy joshua@atherton.com home:(415)968-3718 > {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822 Hi, I'm in no way an RPC expert, I just tried to use both Apollo's NCS and Sun's RPC just for a couple of examples and just to find out their applicability to our environment. I found NCS a much more finished product (but I'm no expert :-). May be is just matter of doc style or whatever else, I don't know. What strikes me, is that there is NO justified technical argument in Joshua's posting. Point 0) refers to a paper dated Jan. 1988, almost 2 years old, point 1) is irrelevant (Sun RPC doc could be taken exactly like this, as marketing propaganda, just like any vendor's doc and report), point 2) is just subjective. I would like to see technical comments, even if they are long, I'm interested and would really love to see them. Please post, I believe there is interest in these sort of things. I'm not working for Sun or Apollo nor I have any interest in them. Thank you, Achille Petrilli Cray & PWS operations
mishkin@apollo.HP.COM (Nathaniel Mishkin) (11/28/89)
In article <14983@joshua.athertn.Atherton.COM>, joshua@athertn.Atherton.COM (Flame Bait) writes: > Had you actually written any Sun RPC programs at the time you wrote the paper? > I got the impression that the author of the White Paper had not actually used > Sun RPCs. I've (a) read all the available documentation, (b) looked closely at several programs (including Sun's samples), (c) tried to write some simple programs, and (d) read the Sun RPC source code. Based on all of that, plus my native intelligence, I think I'm competent to comment. > >Second, I take personal responsibility for > >the content. This is NOT some official pronouncement of HP. > > Too late for that. The copy I got about 10 months ago from Apollo has > Apollo's name all over it, and does not have your name on it at all. > It was an "official pronouncement" of Apollo then :-). I'm afraid I don't have 100% control over what the marketing folks do. I accept your criticism though. > 0. The paper is out of date by two years at least. Many things have chagned > since it was written. Well, first of all, as you've said, *you're* comments might be out of date. In fact they are, since the paper I just distributed is different from the 1/88 version. Given the way the world works, it's just not possible to (a) always update these things as frequently as everyone would like, and (b) purge all existing old copies of documents to make sure no one gets the wrong impression. This is why I put dates on the paper (at least I started doing that some time ago). Give me a break. > 1. The paper is marketing propaganda with a thin veneer of technical knowledge. Remarkable. I wrote the paper. I consider myself to be solely technically oriented. I believe I have a pretty good understanding of all the technical issues. > 2. Never use the paper's arguments in a debate with someone who understands > Sun's RPC: you'll be cut to shreads. The facts about Sun's RPC are often > out of date or inaccurate, the facts about Apollo's RPC are often > technically acurate, but totally misleading. Let's have a list of the parts that are out of date or inaccurate. Based on my best recollections of the various versions of the paper and of Sun RPC, the areas of old versions of the paper that might be out of date relate to RPCGEN. I think at the time of the first version of the paper, there wasn't an RPCGEN at all. Later there was an RPCGEN, but it generated only server stubs, not client stubs. Last I looked, RPCGEN did both stubs, but still allowed only for procedures that take one input parameter and return outputs as function values. Recently, Sun/Novell/Netwise made an announcement that said that the Netwise RPC TOOL stub generator would generate stubs that talk to the Sun RPC runtime. As far as I know, this is not available to the general public, if it's even available at all. (Note that the Netwise interface language is significantly different from Sun's [RPCL]. So much for compatibility.) > If you make a feature by feature comparison, Apollo's networking system > has more features than Sun's. Glad to hear we agree on at least one thing :-) > But, if you want simplicity and ease of > use, then Sun's is the winner. Of course I disagree. I'll happily let the world decide whether in fact for a broad class of applications Sun RPC is either simpler or easier to use. I don't think it's simpler to have to understand when to use UDP and when to use TCP. I don't think it's simpler to have to know whether my input or output parameters are larger than 8K. I don't think it's easier to use when I can only pass one parameter as input thereby requiring me to manually write code to assign my "logical" input parameters into fields of a struct before making a remote call. I don't think it's easier to use when I have to remember when I do and when I don't have to explicitly free storage that the stubs have malloc'd for me under the covers. > For example, Apollo's RPC forces you to use their beefed up UDP transport > protocol. Sun's RPC allows you to use UDP or TCP as a transport protocols, > your choise. See above. > Apollo makes it very difficult to use any interface > language except NIDL. Sun provides RPCGEN, but also makes it easy to > roll your own interface language, if you want to. Apollo makes it very > difficult to use any data representation except their's (NDR). Sun makes > it easy to replace their representation (XDR), if you want to. Sure. And I don't like C, but since the 68000 instruction set is public, I can write a compiler for my own language. What's the point? Most people don't want to write compilers; they want to get their jobs done. They want to be supplied with a competent set of tools; they don't want to reinvent the world. In any case, both Sun RPC and NCS have runtime libraries that export routines used by the stubs. I don't see that either system has any particular advantage in making any happier the small percentage of people who want to design their own interface definition language and implement a compiler for it. > The know this is an emotional issue, but lets face it. Sun's RPC source > code has been freely distributable for three or four years. Apollo's > source is still not freely distributable. Apollo uses a proprietary, > private communications protocol. Sun uses public protocols when possible, > and publishes their protocols, when they are forced to create their own. Both Sun RPC and NCS run (can run) on top of UDP/IP. However, they're both "private communication protocols". The Sun RPC spec doesn't just say "use UDP/IP". It says "use UDP/IP in the following way". That's a protocol. NCS does the same thing. Admittedly, the NCS protocol is more complicated, but that's because it does more things. In any case, the specification for both protocols are public and published. (The book "Network Computing Architecture" just published by Prentice-Hall contains the complete specifications of the NCS RPC protocols.) As far as availability of source code, sure, Sun gives theirs away and we charge for ours. I'll let the market decide whether what we have to offer is worth the price. (Also, I'll be interested to see whether Sun gives away the source the the Netwise RPC TOOL compiler, which they claim is the future of Sun RPC.) -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com
news@calgary.UUCP (Network News Manager) (12/05/89)
From: sharp@cpsc.ucalgary.ca (Maurice Sharp)
Path: cpsc!sharp
I have also used both systems (NCS and Suns RPC), and thus have
my own comments on the following ...
In article <14983@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes:
>Too late for that. The copy I got about 10 months ago from Apollo has
>Apollo's name all over it, and does not have your name on it at all.
>It was an "official pronouncement" of Apollo then :-).
Not surprising. They have to do something about Suns blatant
rumour spreading techniques (Mr. Sun says Sure WE are UNIX now..., NFS
for file sharing, much better than Apollos)
>0. The paper is out of date by two years at least. Many things have chagned
> since it was written.
On both sides. Apollo for the better as well.
>1. The paper is marketing propaganda with a thin veneer of technical knowledge
Actually, Apollo NCS IS faster than the Suns. I have the source,
compiled NCS and NIDL on the Suns, and it WORKED first time. NO bugs
(unlike NFS for machine X). Not only that, it took 3 Sun 4 file
servers to equal the speed of 6 DN3000's for the Mandel demo.
>2. Never use the paper's arguments in a debate with someone who understands
> Sun's RPC: you'll be cut to shreads. The facts about Sun's RPC are often
> out of date or inaccurate, the facts about Apollo's RPC are often
> technically acurate, but totally misleading.
Totally agree with you there.
>There are two ways to compare Sun's and Apollo's networking systems,
>technically and intuitively. Technically would take many pages to handle in
>detail, but here is a quick inituitive comparison:
>
>Apollo's networking system is like VMS's file system; Sun's networking system
>is like UNIX's file system.
More accurate to say Apollo is like Multics.
> VMS is a file system of features. It directly supports all kinds of
> special purpose files, it has record based files and stream based files,
> all kinds of files. UNIX only has one kind of file, but it is flexible
> and easy to use. VMS has features; UNIX has simplicity.
Nonsense. The Apollo system is Object Oriented. I would agree
with a higher learning curve to master it. However, it is MUCH more
flexible and MUCH easier to use. (A file type to mount Vaxes at the
root level in abouth 2 weeks, including learning time)
> If you make a feature by feature comparison, Apollo's networking system
> has more features than Sun's. But, if you want simplicity and ease of
> use, then Sun's is the winner.
I disagree, see above...
>Apollo's RPC is like PASCAL; Sun's RPC is like C.
NIDL lets you do Pascal OR C. You are confusing the interface
with the implementation. Yes, the Apollo NCS is written in Pascal,
but then so is the OS. And not standard Pascal, but one with many C
like extensions. The Sun version is C to the core.
> Since it was designed as a teaching language, PASCAL forces you to write
> programs the way the designer wanted programs written. C is a language
> designed to to what the programmer wants, right or wrong. PASCAL says
> "this is the best way to do things", C says "here is a flexible language,
> do what you want".
NCS is a can be used with C including a C interface definition.
Are you sure you used it ?
> For example, Apollo's RPC forces you to use their beefed up UDP transport
> protocol. Sun's RPC allows you to use UDP or TCP as a transport protocols,
> your choise. Apollo makes it very difficult to use any interface
> language except NIDL. Sun provides RPCGEN, but also makes it easy to
> roll your own interface language, if you want to. Apollo makes it very
> difficult to use any data representation except their's (NDR). Sun makes
> it easy to replace their representation (XDR), if you want to.
NCS does that because the machines are TRANSPARENT. Try
interfacing with an IBM using Sun. Yech, write your own. For NCS, if
it exists on the machine, use NIDL and all is OK :-)
>Finally, Sun's RPC system has always been an open system; Apollo's is just
>now opening up (and even now, is opening in a marketing/buzzword sense of
>the word).
>
> The know this is an emotional issue, but lets face it. Sun's RPC source
> code has been freely distributable for three or four years. Apollo's
> source is still not freely distributable. Apollo uses a proprietary,
> private communications protocol. Sun uses public protocols when possible,
> and publishes their protocols, when they are forced to create their own.
Apollo now publishes all their stuff. And they currently use 2
protocols (TCP, and Domain) with others to follow. Sun ???
I do not work for Apollo, nor for Sun. I have used both. And
just as a final note, RPC is NOT a good way of distributed processing
anyway. If they were smart, they would offer Message passing, or even
Linda, or maybee all of them :-)
maurice
Maurice Sharp MSc. Student
University of Calgary Computer Science Department
2500 University Drive N.W. sharp@ksi.cpsc.UCalgary.CA
Calgary, Alberta, T2N 1N4 ...!alberta!calgary!sharpspeyer@joy.cad.mcc.com (Bruce Speyer) (12/05/89)
Bruce Speyer / MCC CAD Program WORK: [512] 338-3668 3500 W. Balcones Center Dr., Austin, TX. 78759 ARPA: speyer@mcc.com
speyer@joy.cad.mcc.com (Bruce Speyer) (12/05/89)
In article <2197@cs-spool.calgary.UUCP> sharp@ksi.cpsc.ucalgary.ca.UUCP (Maurice Sharp) writes: >>Apollo's RPC is like PASCAL; Sun's RPC is like C. > > NIDL lets you do Pascal OR C. You are confusing the interface >with the implementation. Yes, the Apollo NCS is written in Pascal, >but then so is the OS. And not standard Pascal, but one with many C >like extensions. The Sun version is C to the core. > > NCS is a can be used with C including a C interface definition. >Are you sure you used it ? > >Maurice Sharp MSc. Student NCS and the suite of associated tools that are produced by Apollo are totally implemented in C code. (How else would it be portable?) All coding at Apollo has been in C or C++ for the last three years except that which is tied to Pascal for historical reasons. Bruce Speyer / MCC CAD Program WORK: [512] 338-3668 3500 W. Balcones Center Dr., Austin, TX. 78759 ARPA: speyer@mcc.com
joshua@athertn.Atherton.COM (Flame Bait) (12/06/89)
% = Achille Petrilli # = Nat Mishkin > = Joshua Levy (me) % I would like to see technical comments, even if they are long, I'm % interested and would really love to see them. Please post, I believe there % is interest in these sort of things. The quickest summary is: there isn't that big a difference. Apollo, Netwise, and Sun all make good RPC systems which will solve almost all of the problems you need solved. This discussion is about which is "better", a hard to define idea when it comes to RPCs. The RPC systems are different, however, which provides lots of stuff to talk about. Unfortunately, I do not have the time to write a good technical comparison of RPC protocols (except speed and reliablity, which I already have written). I'm sorry. I know how valuable one would be. Instead, I'll reply to the technical parts of Nat's posting. % I found NCS a much more finished product (but I'm no expert :-). % May be is just matter of doc style or whatever else, I don't know. I can see how you felt that way, and I do not disagree. In a sense I see Apollo's RPC as one tool, while I see Sun's RPC as several cooperating tools. This gives Apollo the finish you talk about; Sun's architecture gives it greater flexiblity. > If you make a feature by feature comparison, Apollo's networking system > has more features than Sun's. Some of these features include: quit propagation, where if the server routine fails this is echoed back to the client; no time out operation, where you do not need to specifiy a maximum server time out; and a better name service. # I don't think it's simpler to have to understand when to use # UDP and when to use TCP. I don't think it's simpler to have to know # whether my input or output parameters are larger than 8K. In a sense, you're correct; whenever you force someone to do things one way, you save them the hassle of making a choice. I'd rather have choices and easy to use defaults, if I do not really care. # I don't think # it's easier to use when I can only pass one parameter as input thereby # requiring me to manually write code to assign my "logical" input parameters # into fields of a struct before making a remote call. This is a non-issue, at least in my mind. Both Sun and Apollo allow you to pass as many arguments as you want, they use slightly different syntax, but it is no big deal. We can argue about syntax forever, but why bother. # I don't think it's easier to use when I have to remember when I do and when # I don't have to explicitly free storage that the stubs have malloc'd for # me under the covers. Then you'll be happy to know that both Sun and Apollo will free storage automatically for you. (Look at the dealloc action for XDR. I must admit that I've never used this feature myself, but it looks like it does exactly what you want. > Apollo makes it very difficult to use any interface > language except NIDL. Sun provides RPCGEN, but also makes it easy to > roll your own interface language, if you want to. Apollo makes it very > difficult to use any data representation except their's (NDR). Sun makes > it easy to replace their representation (XDR), if you want to. # Sure. And I don't like C, but since the 68000 instruction set is public, # I can write a compiler for my own language. What's the point? Most # people don't want to write compilers; they want to get their jobs done. Using your compiler analogy: C is simple. I understand how to write a compiler for it. Even though I never will, the fact that I could is very important. It shows that the language is understandable. The fact that I could write an XDR compiler shows how easy and straight forward the language is. The fact that I can not for NDR shows the problem; that NDR is compilcated. # They [RPC users] want to be supplied with a competent set of tools; they # don't want to reinvent the world. This is very true, and why I like Sun RPC. It is a collection of useful tools which you can combine to solve many problems. Apollo's RPC is more like a single tool, which also solves many problems. But you can not tailor it to your particular problem (by choosing a transport layer, or a data encoding, or ...) like you can with Sun. # As far as availability of source code, sure, Sun gives theirs away and # we charge for ours. I'll let the market decide whether what we have to # offer is worth the price. # I'll happily let the world decide whether in fact # for a broad class of applications Sun RPC is either simpler or easier # to use. Besides source code availability, there is also "plain old" availablity. Take a company which makes a product for IBM RT, DEC ULTIRX, Suns, Apollos, and HPs, and wants to expand to VMS and IBM PCs. Sun RPC is available on all these platforms; Apollo's RPC is not. (The ringer is the IBM RT, which does not yet have Apollo RPC, as far as I can tell.) The bottom line is that every new UNIX machine coming out now has Sun RPC as part of its standard software bundle. Most of them have Apollo RPC also, but the difference between all and most is important. Since everyone must use NFS (like it or not) everyone has Sun's RPC. If you want to pay $25,000 you can get Apollo's RPC also. Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822
joshua@athertn.Atherton.COM (Flame Bait) (12/06/89)
> = Maurice Sharp from sharp@ksi.cpsc.ucalgary.ca >> = my eariler posting Maurice ended with this note, which I think is imporant and often overlooked, so I'm putting it in front: > And just as a final note, RPC is NOT a good way of distributed processing > anyway. If they were smart, they would offer Message passing, or even > Linda, or maybee all of them :-) I look at RPC as a sort of temporary kludge, which should go away in three to ten years. Right now programmers, compilers, designers, and everything else is set up for sequential execution on one machine. RPC alows us to have sequential execution on several machine, one at a time. Current programmers, designers, testers, compilers, etc. are all very comfortable with that, but it is a waste of hardware. As people and programs become more comfortable with distributed systems, things like Messages and Linda should replace RPC. > Actually, Apollo NCS IS faster than the Suns. I have the source, >compiled NCS and NIDL on the Suns, and it WORKED first time. NO bugs >(unlike NFS for machine X). Not only that, it took 3 Sun 4 file >servers to equal the speed of 6 DN3000's for the Mandel demo. I'm not comparing hardware or distributed file systems, just RPC protocols. I didn't now anyone used the file system part of NCS. I thought even Apollo used Sun's NFS. Your last sentence seems to say that Sun's are twice as fast as Apollos, so I'm sure you did not mean it :-) I assume that "faster" refers to installation time, not run time speed. The current Apollo RPC system is 4 TIMES slower than Sun RPC system for 8K packets, which happens to be the size my application uses. That is using Sun/TCP (for reliablity as good or better than Apollo). If I use Sun/UDP, it is 8 times faster than Apollo, but not as reliable. Note to Nat: I know that Apollo is coming out with version 1.5 "Real Soon Now", but it is still in beta test and you can not buy it, so I'm still giving out speeds for version 1.1. > Nonsense. The Apollo system is Object Oriented. I would agree > with a higher learning curve to master it. However, it is MUCH more > flexible and MUCH easier to use. I assume you are refering to Apollos distributed file system, not their RPC system. If you are refering to their RPC system you are wrong. Object Oriented means three things: data encapsulation, inheritence, and polymorphism. Many OO people seem to think you need all three, but I think that inheritence and one other qualifies a system as OO. Apollo RPC has only data encapsulation, not inheritence or polymorphism. By that definition Sun RPC is "Object Oriented" also. I refer to this as "buzzword object oriented", you give your routines object oriented names like (object$_method for example) and a consistent naming scheme, (UUIDs for example), and claim your system is "object oriented". I like Apollo's routine naming system. UUIDs (with their location broker) is one of Apollo's best features, much better Sun's counter part, but they do make make the system object oriented. >>Apollo's RPC is like PASCAL; Sun's RPC is like C. > > NIDL lets you do Pascal OR C. You are confusing the interface >with the implementation. I'm sorry; I must not have been clear. I meant that PASCAL and Apollo's RPC were paternalistic ("father knows best"), while C and Sun's RPC were not ("I'll do what I'm told, even if I do not like it"). I do not want to talk about interface langauge syntax (everyone has their own favorite), but I will say one sentence: I thought that both NIDL's PASCAL syntax and its C syntax looked like PASCAL, and were almost identical. This is personal taste, however, just look at example code from all three to see which one you like better, RPCGEN, NIDL(C), or NIDL(PASCAL). >> For example, Apollo's RPC forces you to use their beefed up UDP transport >> protocol. Sun's RPC allows you to use UDP or TCP as a transport protocols, >> your choise. > NCS does that because the machines are TRANSPARENT. Try >interfacing with an IBM using Sun. Yech, write your own. For NCS, if >it exists on the machine, use NIDL and all is OK :-) Which IBMs are you talking about? I use NFS on an IBM RT everyday, and I'm sure it is available for IBM PCs and mainframes as well. I think your facts are wrong or out of date, or maybe you are refering to on specific IBM machine which is not supported (AS/400?). Transparency is nice, but look at the price: It forces Apollo RPC to use the same transport protocol, even when the machine supports several. So on a UNIX machine I must use their protocol, even though my application could never run on an IBM mainframe, for example. But Apollo RPC will not support more protocols because the IBM mainframe can not. (By the way, I'm not convinced that Apollo forces one transport protocol for transparency. I think you could have several transport protocols, and still have transparency. The RPC system would use a default protocol if your requested protocol was not available to a given machine. Nat, what's the word on this?) Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822
mishkin@apollo.HP.COM (Nathaniel Mishkin) (12/06/89)
In article <2197@cs-spool.calgary.UUCP>, news@calgary.UUCP (Network News Manager) writes: > From: sharp@cpsc.ucalgary.ca (Maurice Sharp) > >Apollo's networking system is like VMS's file system; Sun's networking system > >is like UNIX's file system. > > More accurate to say Apollo is like Multics. Ah, the truth will out! > NIDL lets you do Pascal OR C. You are confusing the interface > with the implementation. Yes, the Apollo NCS is written in Pascal, > but then so is the OS. And not standard Pascal, but one with many C > like extensions. The Sun version is C to the core. THE NCS IMPLEMENTATION IS WRITTEN IN PORTABLE C AND HAS BEEN MADE TO RUN ON MACHINE FROM CRAYS TO PC'S. I put that in all caps because I just couldn't bear to have straightjacketed myself to the requirement of maximum portability and then have people think otherwise. Just want to make it clear. NIDL supports two input languages: one that looks like (ANSI) C and one that looks like Pascal. The non-Unix parts of DOMAIN/OS are written largely in Pascal. > Apollo now publishes all their stuff. And they currently use 2 > protocols (TCP, and Domain) with others to follow. Sun ??? Small correction: NCS runs on top of UDP, not TCP.
derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") (12/07/89)
> > Actually, Apollo NCS IS faster than the Suns. I have the source, > >compiled NCS and NIDL on the Suns, and it WORKED first time. NO bugs > >(unlike NFS for machine X). Not only that, it took 3 Sun 4 file > >servers to equal the speed of 6 DN3000's for the Mandel demo. > > I'm not comparing hardware or distributed file systems, just RPC protocols. > I didn't now anyone used the file system part of NCS. I thought even > Apollo used Sun's NFS. Your last sentence seems to say that Sun's are > twice as fast as Apollos, so I'm sure you did not mean it :-) I'm sure Joshua meant exactly what he said. The DN3000 is (was) an entry level machine. The equivalent can be purchased today for under $5000. The Sun 4 is a much bigger, more expensive machine. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com
mishkin@apollo.HP.COM (Nathaniel Mishkin) (12/08/89)
In article <15101@joshua.athertn.Atherton.COM>, joshua@athertn.Atherton.COM (Flame Bait) writes: > % = Achille Petrilli > # = Nat Mishkin > > = Joshua Levy (me) > > # I don't think > # it's easier to use when I can only pass one parameter as input thereby > # requiring me to manually write code to assign my "logical" input parameters > # into fields of a struct before making a remote call. > > This is a non-issue, at least in my mind. Both Sun and Apollo allow you to > pass as many arguments as you want, they use slightly different syntax, but > it is no big deal. We can argue about syntax forever, but why bother. OK, I'll grant you the right to like what you like, but I just want to make it clear to all our readers what we're talking about. Suppose I want to define and call some procedure (say "proc1") that takes 3 input params and returns 2 output params. With Sun RPC you have to do (something like): struct proc1s_ins { int in1; char in2; float in3; }; struct proc1s_outs { short out1; double out2; } proc1s_outs proc1(proc1s_ins); You have to make up a struct for each unique combination of input and output parameters used in your interface. In NCS you just do: void proc1( int [in] in1, char [in] in2, float [in] in3, short [out] *out1, double [out] *out2 ); Sure it's "just syntax", but I think it matters. > Using your compiler analogy: C is simple. I understand how to write > a compiler for it. Even though I never will, the fact that I could is > very important. It shows that the language is understandable. The fact > that I could write an XDR compiler shows how easy and straight forward > the language is. The fact that I can not for NDR shows the problem; that > NDR is compilcated. First, you write a compiler for NIDL, not NDR. Second, I guess I don't understand what you're trying to say. Simplicity is not the only metric of the utility of a language. The "language" (instruction set) of most RISC systems is simple, that doesn't mean I want to program in it. > Besides source code availability, there is also "plain old" availablity. > Take a company which makes a product for IBM RT, DEC ULTIRX, Suns, Apollos, > and HPs, and wants to expand to VMS and IBM PCs. Sun RPC is available on > all these platforms; Apollo's RPC is not. (The ringer is the IBM RT, which > does not yet have Apollo RPC, as far as I can tell.) The bottom line is > that every new UNIX machine coming out now has Sun RPC as part of its > standard software bundle. Most of them have Apollo RPC also, but the > difference between all and most is important. You can get NCS in binary form from Apollo for Ultrix, Sun, Apollos, VMS, and MS/DOS. IBM has licensed NCS from Apollo. We'll have to see what they ship. DEC and Apollo (HP) have announced that the two companies are doing joint work on NCS. I won't argue that Sun RPC is probably being shipped in binary form by more vendors today than NCS. But let's recall that this discussion started as one of technical merits. I can only hope that the technical merits will eventually change the availability situation. > Since everyone must use NFS (like it or not) everyone has Sun's RPC. > If you want to pay $25,000 you can get Apollo's RPC also. The $25K number is completely out of context. That's the price of the NIDL compiler source. The NCS runtime library source sells for something like $1000. (The source to both is available for essentially nothing to universities.) I think the binary forms of both the compiler and the runtime are around $500-1000 each. -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com
cricket@hp-ses.SDE.HP.COM (Jiminy Cricket) (12/08/89)
% = Achille Petrilli
# = Nat Mishkin
> = Joshua Levy
> Apollo makes it very difficult to use any data representation except
> their's (NDR). Sun makes it easy to replace their representation (XDR),
> if you want to.
# Sure. And I don't like C, but since the 68000 instruction set is public,
# I can write a compiler for my own language. What's the point? Most
# people don't want to write compilers; they want to get their jobs done.
Using your compiler analogy: C is simple. I understand how to write
a compiler for it. Even though I never will, the fact that I could is
very important. It shows that the language is understandable. The fact
that I could write an XDR compiler shows how easy and straight forward
the language is. The fact that I can not for NDR shows the problem; that
NDR is compilcated.
Whoa. What? I think you'd better take some time to qualify your terms. To
say that because it's easy to write a compiler for a language makes it "easy
and straightforward" (for a programmer, anyway) is ludicrous. To my mind,
more abstraction brings with it both an "easier and [more] straighforward"
programming paradigm, but often at the cost of greater compiler or interpreter
complexity - just the reverse of your claim. C is "simple"? I beg to differ. C, to many folks, is a nasty, grubby language. Smalltalk, on the other hand,
is based on a clear, consistent paradigm. But try writing a Smalltalk
compiler.
cricket
Hewlett-Packard Corporate cricket@winnie.corp.hp.com
Palo Alto, California
cricketjoshua@athertn.Atherton.COM (Flame Bait) (12/09/89)
I said: | C is simple. I understand how to write a compiler for it. Even though I | never will, the fact that I could is very important. It shows that the | language is understandable. cricket@hp-ses.SDE.HP.COM (Jiminy Cricket) replies: > Whoa. What? I think you'd better take some time to qualify your terms. To > say that because it's easy to write a compiler for a language makes it "easy > and straightforward" (for a programmer, anyway) is ludicrous. I was describing a rule of thumb, not causality. I'm sorry if it sounded that way. I was thinking of ALGOL type languages. Take these as examples: C, PASCAL, ADA, ALGOL-68, PL/I. Those languages that are easy to write a compiler for are easy to understand, and the reverse is also true. This rule tends to break down for non ALGOL type languages like LISP, PROLOG, SMALLTALK, and database languages. > To my mind, more abstraction brings with it both an "easier and [more] > straighforward" programming paradigm, but often at the cost of greater > compiler or interpreter complexity This is a good rule of thumb also, but it is not perfect either. > C, to many folks, is a nasty, grubby language. Surely we can find something more interesting to talk about then "my language is better than your language". Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822
cricket@hp-ses.SDE.HP.COM (Jiminy Cricket) (12/09/89)
> To my mind, more abstraction brings with it both an "easier and [more] > straighforward" programming paradigm, but often at the cost of greater > compiler or interpreter complexity This is a good rule of thumb also, but it is not perfect either. Granted. You could always write a Byzantine compiler for a simple programming language, or (better) find a powerful, straightforward paradigm which happened to map directly to your CPU's instruction set. > C, to many folks, is a nasty, grubby language. Surely we can find something more interesting to talk about then "my language is better than your language". Just meant to underscore the idea the C is not, by many standards, an "easy and straightforward" language. Besides, I'm not the right person to talk about "my language is better than your language" here (unless you wanna defend something else). I program mostly in C. cricket
perry@apollo.HP.COM (Jim Perry) (12/12/89)
>> C, to many folks, is a nasty, grubby language. > >Surely we can find something more interesting to talk about then "my >language is better than your language". This is the perfect capper for a nasty, grubby debate about "my RPC system is better than your RPC system" :-) - Jim Perry perry@apollo.hp.com HP/Apollo, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.