leland@wri.UUCP (07/07/90)
Nowdays, there are as many Unix boxes out there as there are cars. I should know; I work with a reasonable number of them. The question of "Why would anyone buy an Apollo" is like asking "Why would anyone buy a Ford?" -- the answer is that people buy whatever they feel most confortable *using*. They buy the system that has an editor and debugger they are comfortable with and THAT -- not price, technology, or what have you -- seems to make the difference. The fact is, for those who use it the Apollo DM editor is very productive. In fact, the whole DM system is efficient and fast. Ok, so you don't have glitzy stuff, but the stuff you really need and use is there, and readily accessible -- fast. It is amazing that SunView on a Sparc is so sluggish. In my office, I have a Sun 3/50, an Apollo DN4500, and an SGI. All three get used, each for whatever tasks they are most appropriate, and all are great for at least some things. ------------------------------------------------------------------------------------------ Leland Ray Phone: (217) 398-0700 Systems Administration -- Unix Platforms Email: leland@wri.com WRI US mail: call and ask All disclaimers apply.
dan@cpsc.ucalgary.ca (Daniel Freedman) (07/10/90)
In article <9007070357.AA00259@zeus.WRI.com> leland@wri.UUCP writes: > >The question of "Why would anyone buy an Apollo" is like asking "Why would >anyone buy a Ford?" -- the answer is that people buy whatever they feel most >confortable *using*. They buy the system that has an editor and debugger they >are comfortable with and THAT -- not price, technology, or what have you -- >seems to make the difference. I agree with you entirely, and three years or so ago, there was enough difference between machines to make level-of-comfort a big part of the decision as to which machine to buy. But these days, as I said in my last posting, anything you can do on an Apollo, you can also do on a Sun, for less money. There may be some additional amount of hassle, but not much. I think that the important issues today are: price, performance, and standards. Suns have taken over from vaxes as the "standard" machine -- the machine (or at least the o/s) by which others are judged for compatability. They also perform well, and are cheap. I wish I could justify buying Apollos, since I truly believe that the o/s is superior, and that the hardware is more or less exemplary. Unfortunately, these issues are losing in terms of perceived importance to the 3 issues I mentioned above. Dan Freedman U. of Calgary Computer Science Dept., 403 220-7299 2500 University Dr. N.W., dan@cpsc.ucalgary.ca Calgary, Alberta, Canada. T2N 1N4
jwb@cepmax.ncsu.EDU (John W. Baugh Jr.) (07/10/90)
In article <1990Jul9.213212.5519@calgary.uucp>, dan@cpsc.ucalgary.ca (Daniel Freedman) writes: [stuff deleted] > compatability. They also perform well, and are cheap. I wish I could > justify buying Apollos, since I truly believe that the o/s is superior, and ^^^^^^^^^^^^^^^^^^^ Are you talking about Aegis, or the "3-in-1" SR 10? In what ways is it superior? John Baugh jwb@cepmax.ncsu.edu
jlol@ALTAR.EE.BYU.EDU (Jay Lawlor) (07/10/90)
In article <9007070357.AA00259@zeus.WRI.com> leland@wri.UUCP writes: > >The question of "Why would anyone buy an Apollo" is like asking "Why would >anyone buy a Ford?" -- the answer is that people buy whatever they feel most >confortable *using*. They buy the system that has an editor and debugger they >are comfortable with and THAT -- not price, technology, or what have you -- >seems to make the difference. I agree with you entirely, and three years or so ago, there was enough difference between machines to make level-of-comfort a big part of the decision as to which machine to buy. But these days, as I said in my last posting, anything you can do on an Apollo, you can also do on a Sun, for less money. There may be some additional amount of hassle, but not much. Yes, you can do it cheaper, as well as SLOWER on a Sun. Have you ever tried using a decent text editor on a sun (including sun4) color display? You might as well wait all day for it to scroll. On Apollos and HPs I have used, the display is very fast even for low end machines. I think that the important issues today are: price, performance, and standards. I'll admit, Sun wins on the standards. Most software ports to the Sun with almost no grief. I hate porting things to my HP (but I love the 50 MHz clock :-). ----------------------------------------------------------------------------- Jay Lawlor | Systems Manager, Supercomputer Center | I think there is a world market for 459 Clyde Building | about five computers -- Thomas J. Brigham Young University | Watson, CEO, IBM Corporation, 1947 Provo, UT 84602 | jlol@ee.byu.edu | ----------------------------------------------------------------------------- Opinions are, of course, my own. The fact that everyone else shares them is not my concern.
dan@cpsc.ucalgary.ca (Daniel Freedman) (07/10/90)
In article <1990Jul10.133441.8548@ncsuvx.ncsu.edu> jwb@cepmax.ncsu.edu writes: >In article <1990Jul9.213212.5519@calgary.uucp>, dan@cpsc.ucalgary.ca >(Daniel Freedman) writes: >[stuff deleted] >> since I truly believe that the o/s is superior, and > ^^^^^^^^^^^^^^^^^^^ >Are you talking about Aegis, or the "3-in-1" SR 10? In what ways is >it superior? > 1) File system: object oriented (can write your own handlers for interestingly structured files). Nicely networked, automagically allows access to any disk on the network, no setting up of daemons required for this. 2) Ability to run both sysv and bsd simultaneously, although there are many compromises here. 3) The new (as of SR10) NCS-based registry stuff. 4) ACLS 5) Protected Subsystems 6) The Display Manager (this is not only one of the best things about Apollos, it is also one of the worst -- yet another area where Apollo has a fantastic foundation providing basic features, but fails to make it sufficiently extensible, customizable, or up to date (ie: menus, scrollbars backgrounds, and so on) to keep people happy with it. 7) Dynamic swap partition 8) Ability to graphically debug processes running on remote nodes (not that it would be impossible to do this on suns, but they dont provide it). 9) Good compilers with good error messages and so on. Note however, that although these things are attractive, they don't seem to make enough of a difference to one's every-day use of the machine to warrant putting up with the slow performance, high price, and generally lousy telephone and sales support. BTW, there has been some comment on people not being able to get delivery of software that they had already paid for, let alone the elusive patch tapes. We (U. of Calgary) have had so much of this happen that we now refuse to pay for any software orders from Apollo until the entire order arrives. Unfortunately, it doesnt seem to help. Last November, we ordered a whole bunch of stuff for 10.1. Well, 10.2 is out, new versions of a lot of the stuff we ordered are out, and we have only received 2 out of the 10 or so packages we ordered. We have not yet (officially) received 10.2! Dan Freedman U. of Calgary Computer Science Dept., 403 220-7299 2500 University Dr. N.W., dan@cpsc.ucalgary.ca Calgary, Alberta, Canada. T2N 1N4
mike@tuvie (Inst.f.Techn.Informatik) (07/11/90)
In article <1990Jul10.155624.11131@calgary.uucp>, dan@cpsc.ucalgary.ca (Daniel Freedman) writes: > In article <1990Jul10.133441.8548@ncsuvx.ncsu.edu> jwb@cepmax.ncsu.edu writes: > >In article <1990Jul9.213212.5519@calgary.uucp>, dan@cpsc.ucalgary.ca > >(Daniel Freedman) writes: > >[stuff deleted] > >> since I truly believe that the o/s is superior, and > > ^^^^^^^^^^^^^^^^^^^ > >Are you talking about Aegis, or the "3-in-1" SR 10? In what ways is > >it superior? > > > > 1) File system: object oriented (can write your own handlers for interestingly > structured files). Nicely networked, automagically allows access to any > disk on the network, no setting up of daemons required for this. > This could be quite nice if it worked properly. The //netdirecory is great, maybe we can push HP/Apollo to get it included in OSF/2. It would be a shame if we had to use nfs instead. Nfs is great for sharing parts of a file system (like sharing /bin etc.). What I really want most of the time is being able to access all files on all hosts in an intuitive way. And I want to do so without having to mount the remote filesystems. I quite like the host:: syntax on CAXen running VMS, especially because it is not only used for file access but for just about any remote action. The //syntax comes as close to providing a UNIX equivalent that you can get. > > 2) Ability to run both sysv and bsd simultaneously, although there are many > compromises here. > Would be nice, if I COULD MAKE AEGIS SHUT UP FOR ONCE AND FOR ALL. > > 3) The new (as of SR10) NCS-based registry stuff. > If it works properly, and would not change with every release, I could learn to like it. Is probably better than YP. But the problem here is standards. While YP is vendor independent (well, nearly), registries run only on Apollos. But maybe that will change with the adoption of NCS as rpc protocol. > > 4) ACLS > You must be kidding! I wish I could just get rid of them and forget this four letter word! It might be nice if 1) it worked 2) did not break working code The reality is that often may not even access the files owned by *ME*, because somehow the ACLs got messed up! > > 5) Protected Subsystems > What is this ????? > > 6) The Display Manager (this is not only one of the best things about Apollos, > it is also one of the worst -- yet another area where Apollo has a > fantastic foundation providing basic features, but fails to make it > sufficiently extensible, customizable, or up to date (ie: menus, scrollbars > backgrounds, and so on) to keep people happy with it. > Same problem with Apollos as always: It was nice - 5 years ago. The fact is that they have not kept up with other vendors. And that it was proprietary - making it impossible for other companies to use it and thus from becoming a standard. I can do without the DM. I want a fast - and full - X11R3 implementation whose color-handling is compatible to that of SUNs, VAXen and DECstations. Let's face it: Apollo never was a standard setting company nor does HP seem to want to be one. And nowadays standards are more important than ever. > > 7) Dynamic swap partition > That is great! I wish HP would push to get it included into OSF/2. There are just two questions here: will swap partitions on multiple discs work properly with 10.3 as has been leaked aeons ago and how does a dynamic swap partition compare to a static one as far as access times are concerned. > > 8) Ability to graphically debug processes running on remote nodes (not that > it would be impossible to do this on suns, but they dont provide it). > If dde only ran under X11R3 as well!!! > > 9) Good compilers with good error messages > We are still running cc6.6 and it is a horror! You find bugs regularly - ever tried to compile GNU ghostscript? Or some other PD programs? Terrible compiler crashes are the result. Also, it's not ANSI nor is it K&R by default! A terrible nuisance, at least it could ignore 'volatile' and 'const' specifiers like Microsoft C does (BUT WITH A WARNING PLEASE!). The fact that some UNIX options are not supported (like -S) does not make me too happy either. Come to think of it - lint will crash on ANSI C. > > and so on. > > Note however, that although these things are attractive, they don't seem > to make enough of a difference to one's every-day use of the machine to > warrant putting up with the slow performance, high price, and generally > lousy telephone and sales support. What it boils down to: they had great ideas 10 years ago, implemented them lousy and have still not fixed the bugs. They often deny that bugs are bugs, trying to sell them as features. Also, Apollos are *NOT* an OPEN SYSTEM you can run easily in a multi-vendor environment. bye, mike ____ ____ / / / / / Michael K. Gschwind mike@vlsivie.at / / / / / Technical University, Vienna mike@vlsivie.uucp ---/ Voice: (++43).1.58801 8144 e182202@awituw01.bitnet / Fax: (++43).1.569697 ___/
burdick@hpspdra.HP.COM (Matt Burdick) (07/12/90)
>> 1) File system: object oriented (can write your own handlers for >> interestingly structured files). Nicely networked, >> automagically allows access to any disk on the network, no >> setting up of daemons required for this. > This could be quite nice if it worked properly. The //netdirecory is > great, maybe we can push HP/Apollo to get it included in OSF/2. AFS (the Andrew File System) has been accepted as the OSF/DCE base for a distributed file system. As I understand it, AFS (originally written by CMU, but now distributed by Transarc) will be re-written to use NCS, much like Apollo's // file system. Also like the Apollo setup, AFS will let you access directories such as /<hostname>/<path> (ie: /eddie.mit.edu/usr/tmp). Warning: I haven't been keeping up with the latest developments for this, so I may be slightly out-of-date. -matt -- Matt Burdick | Hewlett-Packard burdick@hpspd.spd.hp.com | Intelligent Networks Operation
krowitz@RICHTER.MIT.EDU (David Krowitz) (07/12/90)
It would be *much* cleaner if AFS did what Domain/OS does ... namely put the host entry directories in // rather than in /. This nice feature of Domain/OS makes much more sense for a closely networked group of machines. If you have any contact with the people working on OSF's implementation, please pass this on. I *HATE* having to use NFS where my current machine's rc.local file is /etc/rc.local, but every other machine's file is /othermachine/etc/rc.local. (this notation implies that I might have a machine named "etc" with a top-level file named "/rc.local"). -- 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)
krowitz@RICHTER.MIT.EDU (David Krowitz) (07/13/90)
Why not move them to "//" which the the logical parent directory of a "/" directory? I don't like the idea of having my top-level network directory be a subdirectory (not matter how many levels deep) of my root directory. It should be the parent of the root directory. Try typing "cd /; cd .." sometime, it will put you where you expect to be (in //). == Dave
rees@dabo.ifs.umich.edu (Jim Rees) (07/13/90)
In article <9007121442.AA01927@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes: It would be *much* cleaner if AFS did what Domain/OS does ... namely put the host entry directories in // rather than in /. Actually, you might be surprised at how many programs break because of the '//' notation. AFS currently puts all the machine names in /afs. But each machine is not an equal member of a large distributed file system. Instead, it's much more of a traditional client/server relationship. I don't particularly like this aspect of AFS. I've been running AFS for a couple of months on my Apollo and it's pretty nice. It uses large pages (64k) and caches them on a local disk. Once your cache is full it's plenty fast. But it's got some strangeness, like no hard links, no atime, and acls. It's also got deviant links, but they're not as flexible as Apollo's, since the only thing that can be substituted in is the machine type. The AFS selected by OSF as part of DCE will be considerably different from the AFS 3.0 currently in use around the country.
mike@tuvie (Inst.f.Techn.Informatik) (07/13/90)
In article <9007121442.AA01927@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes: > It would be *much* cleaner if AFS did what Domain/OS does ... > namely put the host entry directories in // rather than in /. > This nice feature of Domain/OS makes much more sense for > a closely networked group of machines. If you have any contact > with the people working on OSF's implementation, please pass > this on. [...] Add my name if you pass it on. By the way, don't we have any way of influencing the OSF decisions? After all, we are supposed to buy these machines, maintain them and work with them. And I'd rather work on an intuitive operating system! bye, mike ____ ____ / / / / / Michael K. Gschwind mike@vlsivie.at / / / / / Technical University, Vienna mike@vlsivie.uucp ---/ Voice: (++43).1.58801 8144 e182202@awituw01.bitnet / Fax: (++43).1.569697 ___/
mike@tuvie (Inst.f.Techn.Informatik) (07/13/90)
In article <1990Jul12.181524.1462@terminator.cc.umich.edu>, rees@dabo.ifs.umich.edu (Jim Rees) writes: > In article <9007121442.AA01927@richter.mit.edu>, krowitz@RICHTER.MIT.EDU > (David Krowitz) writes: > It would be *much* cleaner if AFS did what Domain/OS does ... > namely put the host entry directories in // rather than in /. > > Actually, you might be surprised at how many programs break because of the > '//' notation. AFS currently puts all the machine names in /afs. But each > machine is not an equal member of a large distributed file system. Instead, > it's much more of a traditional client/server relationship. I don't > particularly like this aspect of AFS. If it breaks programs, those programs are broken and should be fixed. This is difficult to do for Apollos alone, but if OSF breaks programs, they will be changed, not OSF. The problem is that mounting something in a directory implies that it is subordinated to this tructure. This is not the case with the network/computer relationship. Clearly, computers should be subordinated to networks, not vice versa. bye, mike ____ ____ / / / / / Michael K. Gschwind mike@vlsivie.at / / / / / Technical University, Vienna mike@vlsivie.uucp ---/ Voice: (++43).1.58801 8144 e182202@awituw01.bitnet / Fax: (++43).1.569697 ___/
thompson%pan@UMIX.CC.UMICH.EDU (John Thompson) (07/13/90)
> In article <9007121442.AA01927@richter.mit.edu>, krowitz@RICHTER.MIT.EDU > (David Krowitz) writes: > It would be *much* cleaner if AFS did what Domain/OS does ... > namely put the host entry directories in // rather than in /. > > Actually, you might be surprised at how many programs break because of the > '//' notation. AFS currently puts all the machine names in /afs. But each > machine is not an equal member of a large distributed file system. Instead, > it's much more of a traditional client/server relationship. I don't > particularly like this aspect of AFS. This is from Apollo's documentation, so it is not the word of GOD nor POSIX, but the implication is that POSIX supports (allows for?) the double-slash. From //node/install/doc/apollo/os.v.10.2__notes -- 1.3.5 POSIX We made the following changes to the operating system to be compatible with POSIX. They may result in incompatibilities with previous releases: More than two slashes at the beginning of a pathname will be compressed to a single slash. (One or two slashes at the beginning of a pathname will not be changed.) From //node/install/doc/apollo/os.v.10.2__posix -- 2.3* General Terms. pathname. A _pathname_ beginning with two slashes resolves to the network-wide root. The leafname following the two slashes is defined to be the name of a node in the network. Any POSIX experts out there? Regardless of standards or anything else, I personally _love_ the // notation. No NFS mounts, a consistent naming convention, and the concept of the entire network as a sort of super-directory are all appealing to me.
smv@apollo.HP.COM (Steve Valentine) (07/14/90)
Apollo (among others?) lobbied the 1003.1 committee to permit the leading double slash convention. From POSIX 1003.1 (the ugly green book): 2.3 General Terms pathname. ... Multiple successive slashes are considered the same as one slash. A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash. ... In POSIX-ese, 'may' means that the implementation is permitted, but not required, to treat a leading double slash specially. This means that in order to be POSIX 1003.1 compliant, an application program must not assume that two leading slashes will be collapsed into one, as is traditional in UNIX systems. This means that to be on the safe side you should start paths with three slashes when constructing a path from (possibly null) components, to wit: A shell command such as: pathname=/$TOPDIR/$MIDDLEDIR/$LEAF will result in a potentially troublesome path if $(TOPDIR) happens to be null. To POSIX-proof the script, add a two more slashes: pathname=///$TOPDIR/$MIDDLEDIR/$LEAF Note that adding one slash is insufficient because $(TOPDIR) might not be null. A POSIX 1003.1 compliant OS will always collapse the three slashes into one. The 'implementation-defined' keyword tells the POSIX-ese literate that, the implementation's compliance document must specify what the implementation does if a pathname with two leading slashes is encountered. //node/install/doc/apollo/os.v.10.2__posix is the compliance doc for sr10.2. Steve Valentine - smv@apollo.hp.com Hewlett-Packard Company, Apollo Systems Division, Chelmsford, MA Hermits have no peer pressure. -Steven Wright
paul@CAEN.ENGIN.UMICH.EDU (paul killey) (07/25/90)
The question of "Why would anyone buy an Apollo" is like asking "Why would anyone buy a Ford?" That, or "why would anyone buy a betamax?"
dan@cpsc.ucalgary.ca (Daniel Freedman) (07/26/90)
In article <4bcb9e82a.0017b5e@caen.engin.umich.edu> paul@CAEN.ENGIN.UMICH.EDU (paul killey) writes: > > > > The question of "Why would anyone buy an Apollo" is like asking >"Why would anyone > buy a Ford?" > >That, or "why would anyone buy a betamax?" I think you have hit the nail on the head. It *used* to be a case of real differences between Apollo's machines and others, in terms of networking options, performance, s/w reliability, o/s features, and so on. Now, since the functionality of o/s's is essentially the same, (in other words since the differences no longer affect what you can or can't do with the machines) its all a question of performance, price, and degree of standardness. The only exception to this is when the software that you want only runs on company xyz's machine, in which case your choice is more or less made for you. However, ask yourself where you see companies concentrating their s/w development efforts in terms of machines. Can you think of anyone who is saying "Nope, we are going to ignore Suns, and develop only on Apollos." I can think of some companies who are doing the same thing in reverse. If your company has done some in house s/w development on Apollos, particularly if you have used proprietary stuff like d3m, gmr, dsee, and so on, you are stuck. You either have to buy Apollos, or invest a whole lot of money porting the stuff to standard tools. Someone who has 1500 beta tapes would likely buy a betamax machine, to protect his investment. Supposedly, beta is better quality anyway. But, people buying new machines want vhs despite the lower quality, since the selection of tapes available is far far greater. Yes, I like your analogy. Dan Freedman U. of Calgary Computer Science Dept., 403 220-7299 2500 University Dr. N.W., dan@cpsc.ucalgary.ca Calgary, Alberta, Canada. T2N 1N4