Path: utzoo!attcan!uunet!mcsun!tuvie!mike From: mike@tuvie (Inst.f.Techn.Informatik) Newsgroups: comp.sys.apollo Subject: Re: reason to buy Apollos Message-ID: <1670@tuvie> Date: 11 Jul 90 12:17:13 GMT References: <1990Jul9.213212.5519@calgary.uucp> <9007070357.AA00259@zeus.WRI.com> <1990Jul10.155624.11131@calgary.uucp> Organization: Technical University of Vienna, AUSTRIA Lines: 109 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 ___/