orand@kuhub.cc.ukans.edu (05/10/90)
Does anyone out there have any of the OMTI winchester/floppy controllers for
a DN 4000?
Brady...
===========================================================================
Brady Orand - University of Kansas Computer Center Lawrence, Ks. 66045
ORAND@kuhub.cc.ukans.edu
Work: (913) 864-0490
Home: (913) 749-1341
===========================================================================gerry@swift.cs.tcd.ie (07/25/90)
: Does anybody know about Sun RPC run-time libraries available for 10.2? Gerry O'Brien, Dept. Of Computer Science, Trinity College Dublin, Dublin 2, Ireland. gerry@cs.tcd.ie
pcc@apollo.HP.COM (Peter Craine) (07/26/90)
In article <7054.26adcc1e@swift.cs.tcd.ie>, gerry@swift.cs.tcd.ie writes: |> : |> Does anybody know about Sun RPC run-time libraries |> available for 10.2? |> They certainly aren't available from Apollo. Of course, why would anybody want to work with some obtuse, inelegant RPC when you've got NCS. (And if THAT doesn't start another flame ware, I dunno what will). +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + "Home is where you wear your hat." Hewlett-Packard + Chelmsford Response Center + *I* don't want my opinions. Why would HP?
achille@cernvax.UUCP (achille petrilli) (07/29/90)
In article <4bd2e824.20b6d@apollo.HP.COM> pcc@1.HP.COM writes: >In article <7054.26adcc1e@swift.cs.tcd.ie>, gerry@swift.cs.tcd.ie writes: >|> : >|> Does anybody know about Sun RPC run-time libraries >|> available for 10.2? >|> > >They certainly aren't available from Apollo. Of course, why would anybody >want to work with some obtuse, inelegant RPC when you've got NCS. (And if >THAT doesn't start another flame ware, I dunno what will). > >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Peter Craine + "Home is where you wear your hat." > Hewlett-Packard + > Chelmsford Response Center + *I* don't want my opinions. Why would HP? Just to throw in my 2 cents. Apollo has ported SUN RPC to Domain/OS. Otherwise there could be no NFS product from Apollo. So the library does exist in Apollo but, I guess, is not distributed. (For a proof of that, do an 'nm' or 'dump -t' on /etc/nfsd, you'll find all routine names that you'd expect, for instance, xdr*). Now, while I'd tend to agree with Peter about NCS quality, features, etc, I feel frustrated because Apollo has done the work and is not allowing other people to benefit from it. This sort of 'beat the user' attitude will end up killing Apollo. Achille Petrilli Management Information Systems
nazgul@alphalpha.com (Kee Hinckley) (08/01/90)
In article <2121@cernvax.UUCP> achille@cernvax.UUCP (achille petrilli) writes: >Apollo has ported SUN RPC to Domain/OS. Otherwise there could be no NFS >product from Apollo. So the library does exist in Apollo but, I guess, >is not distributed. Yes and no. The Apollo implementation of NFS is a complete rewrite from scratch. Only the name is licensed from Sun. This may or may not be true of the RPC library as well, I'm not sure. >I feel frustrated because Apollo has done the work and is not allowing >other people to benefit from it. >This sort of 'beat the user' attitude will end up killing Apollo. You've got the tense wrong. :-/ Carlton pointed out the problem, it's been there from the beginning. Apollo does not have the resources to support every piece of code they would like, even if it's used internally (frankly I have no idea how most people survive on an Apollo using only the stuff that is shipped). However Apollo's policy is not to ship unsupported software (yes I know, much of what's shipped is unsupported in fact, but they don't want to add to that). Persuade them to ship unsupported software and you'll might get a flood of stuff. Maybe. Unfortunately it takes a fair amount of time to even ship unsupported tools (installation, compiling with new compilers, making sure it at least runs....), so there's no guarantee. In the six years I was there the only "unsupported" thing I managed to get out the door were the keydef files in /domain_examples. -kee -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
krowitz@RICHTER.MIT.EDU (David Krowitz) (08/01/90)
They would want to use Sun RPC in order to run the gobs of software which uses Sun RPC calls (like, say, PC-NFS, something which Apollo *still* does not support to my knowledge). Why is it that Apollo, and now HP, can't seem to get it through their heads that customers want, *need*, and *MUST* be able to use software packages that don't necessarily come from the vendor who provided their hardware? Many times we have NO choice as to the software we must run -- a collegue sends us their program which they developed on their Sparcstation and we can either a) spend 6 weeks of our valuable time to re-create the program on the Apollos rather than writing our papers/PhD thesis. b) buy a Sun workstation to run the software. Our research grants don't pay us to port software. They also don't pay us to publish papers 6 weeks after the same results have been reported by someone else. Which option do you think we would take? (I'll give you a hint: Since 1988, roughly 6 new professors in our department have bought workstations. None of them bought Apollos. In the past 12 months, 5 of the 8 professors who own Apollos have bought brand new color Sparcstations -- 6 machines at roughly $18,000 each after discount -- and only 2 of 8 professors who own Apollos have bought Apollos -- 5 new DN2500's at roughly $3500 each after discount -- that's roughly a 6 to 1 ratio in dollars spent). -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
petersn@physics.utoronto.ca (Mike Peterson) (08/02/90)
In article <9008011411.AA10103@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >They would want to use Sun RPC in order to run the gobs of software which >uses Sun RPC calls (like, say, PC-NFS, something which Apollo *still* does >not support to my knowledge). Why is it that Apollo, and now HP, can't seem >to get it through their heads that customers want, *need*, and *MUST* be able >to use software packages that don't necessarily come from the vendor who >provided their hardware? Many times we have NO choice as to the software we >must run -- a collegue sends us their program which they developed on their >Sparcstation and we can either >a) spend 6 weeks of our valuable time to re-create the program on the > Apollos rather than writing our papers/PhD thesis. >b) buy a Sun workstation to run the software. > >Our research grants don't pay us to port software. They also don't pay us >to publish papers 6 weeks after the same results have been reported by >someone else. Which option do you think we would take? (I'll give you >a hint: Since 1988, roughly 6 new professors in our department have >bought workstations. None of them bought Apollos. In the past 12 months, >5 of the 8 professors who own Apollos have bought brand new color >Sparcstations -- 6 machines at roughly $18,000 each after discount -- and >only 2 of 8 professors who own Apollos have bought Apollos -- 5 new DN2500's >at roughly $3500 each after discount -- that's roughly a 6 to 1 ratio in >dollars spent). I agree with these comments completely -- I have spent (and continue to spend) ridiculous amounts of time porting BSD programs that should run on any BSD system without change (e.g. sendmail, named, ckermit, batchd (still not working), C-News/rn/nntp, NCAR library). We have also had no end of problems with TCP/IP and Ethernet, especially on our DSP10020 - more on that later, but it still doesn't work for more than 1 week average (we are running SR10.2.0.5.p).. No one else at our University even thinks of HP/Apollo after our problems - who needs the headaches? We are going to buy SGI or IBM RS/6000. Mike Peterson, U/Toronto Chemistry, system@alchemy.chem.utoronto.ca (416) 978-7094
gmkumar@uxh.cso.uiuc.edu (G Maninthakumar) (12/19/90)
In article <71915@unix.cis.pitt.edu> jnlst1@unix.cis.pitt.edu (John N. Lutz) writes: >Howdy, > I got the imake utility from the Adus Archives >(adus.ecn.uiowa.edu) and de-tarred it. What I got was two files: >imake and makedepend. Both are coffs for m68k's. I dumped both files >in /usr/local/bin. When I run imake on a set of files (xdir off of >the x archives to be specific) it tells me: >*** >lutz@hepburn-//monroe/downloads/xdir-24-> imake >4: Can't find include file Imake.template >imake: Exit code 1. Stop. >*** >Here is the Imakefile: >*** > INCLUDES = -I$(TOP) -I$(AWIDGETSRC) -I$(TOOLKITSRC) > DEPLIBS = XawClientDepLibs >LOCAL_LIBRARIES = XawClientLibs > CDEBUGFLAGS = -g -DLIBDIR=\"$(LIBDIR)/xdir\" > > SRCS = xdir.c dir.c util.c display.c error.c \ > resources.c help.c menus.c filemenu.c configure.c > OBJS = xdir.o dir.o util.o display.o error.o \ > resources.o help.o menus.o filemenu.o configure.o > EXTRAS = README xdir.man Xdir.ad xdir-general.help xdir.about >\ > xdir-view.help Imakefile Makefile COPYRIGHT > >ComplexProgramTarget(xdir) >InstallNonExec(xdir.help,$(LIBDIR)) >InstallNonExec(xdir.about,$(LIBDIR)) >InstallNonExec(xdir-view.help,$(LIBDIR)) >InstallAppDefaults(Xdir) > >archive: > tar cf xdir.tar ${EXTRAS} ${SRCS} > compress xdir.tar > >shar: > shar ${EXTRAS} ${SRCS} > xdir.shar > >ci: > ci -u ${EXTRAS} ${SRCS} >***** > >Any ideas?? > >E-mail me, and I'll post a summary. > > >Thanks, >-- >John Lutz University Anesthesiology >jnlst1@unix.cis.pitt.edu 3471 5th Ave. Suite 910 >(412)622-1018 Pittsburgh, PA 15213-3221 >"Look, it's trying to think." - Albert Rosenfield , "Twin Peaks" From ss007720284@node_2f2f3.node_2f2f3 Wed Dec 12 21:04:58 1990 Received: from node-2f2f3.ce.uiuc.edu by uxh.cso.uiuc.edu with SMTP id AA09012 (5.65+/IDA-1.4.1 for gmkumar); Wed, 12 Dec 90 21:04:46 -0600 Received: by node_2f2f3.ARPA ( 5.52 (84)/5.17) id AA07936; Wed, 12 Dec 90 21:04:41 CST Date: Wed, 12 Dec 90 21:04:41 CST From: ss007720284@node_2f2f3.node_2f2f3 (Odencrantz) Message-Id: <9012130304.AA07936@node_2f2f3.ARPA> To: gmkumar@uxh.cso.uiuc.edu Subject: Interleaf/Apollo in LA, CA Status: R Dear Apollo Friends: Can you assist me in finding a University in the LA area where I can find an Apollo so I can use Interleaf to finish my dissertation? I am getting frustrated trying to do this myself mainly because I haven't had much luck. I now live near Cal State Long Beach and work near UCIrvine. I am currently forced to fly back to UIUrbana to use Interleaf on the Apollo at the Civil Engineering Department there to make changes on my dissertation. If you have any ideas as to where I may find the solution to my problem, they'd be greatly appreciated. I'd be willing to travel most anywhere in the LA area to be able to use Interleaf. Please respond to jodencrantz@civilgate.ce.uiuc.edu or ss007720284@civilgate.ce.uiuc.edu Thanks for any ideas, Joe Odencrantz