cosc4fp@jetson.uh.edu (09/06/90)
This is driving crazy..... how does one configure the "kernel" on an Apollo? I need to raise the max number of processes on a machine.
wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) (09/06/90)
In article <6881.26e59640@jetson.uh.edu> cosc4fp@jetson.uh.edu writes:
You > This is driving crazy..... how does one configure the "kernel" on an
You > Apollo? I need to raise the max number of processes on a machine.
Well you'r best guess is to get OS10.3 since the max number of process
is really hardwired deep down in Aegis. I know it a nuisance but 64 is
really the maximum, and then you have to give away at least 8 to the OS.
But Apollo/Hp promissed that a largen number was going to be implemented
is OS10.3 which was/is due this month.
I'm also banging my head against this limit: My(Our) gateway is really loaded
with all kinds of deamons and servers. The user on the display sometimes has to
wait for a free entry to execute a simple process.
So, to bad i guess,
Willem Jan
Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl
Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET
P.O. 513 Tel: +31-40-473401
5600 MB Eindhoven The Netherlandsnazgul@alphalpha.com (Kee Hinckley) (09/06/90)
In article <6881.26e59640@jetson.uh.edu> cosc4fp@jetson.uh.edu writes: >This is driving crazy..... how does one configure the "kernel" on an >Apollo? I need to raise the max number of processes on a machine. First the good news about Apollos. You hardly ever need to modify anything that on most systems would requiring modifying the kernel. Now the bad news. When you *do* need to, you can't. The only kernel mod you can get is called a new release of the OS. SR10.3 supposedly allows around 1024 or so, which ought to do the trick. You'll run out disk space before you run out of processes. The process limit on Apollos is so strangely low for a number of reasons. It was only meant as a single user machine, Aegis was not as daemon-crazy as Unix is, Aegis originally used multiple programs per process, so invoking a new program didn't invoke a new process, etc.. On the bright side, it used to be 32! -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.
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (09/07/90)
> <<forwarded message>> > This is driving crazy..... how does one configure the "kernel" on an > Apollo? I need to raise the max number of processes on a machine. As has been noted -- you don't. Instead, wait for sr10.3. This is from the beta3 release notes for sr10.3 -- | 1.8.1 Increased Number of User Processes | | We have enhanced the operating system to include an increased number | of user processes. The new maximum number depends on the type of node | and the available physical memory. Note, however, that older systems | with 68010-based processors are still limited to 64 processes. The | following table indicates the maximum number of processes for the | various node types: | | Software Release 10.3 | | Node Type Maximum Processes | | Next Generation Workstations 64 | DN300/320/330 64 | DN550/560/570/580 64 | DSP80/80A/90 64 | DN460/660 256 | DN570T/580T/590T 256 | DN3000 (with DMMU) 128 | DN3010 (with PMMU) 256 | DN2500/3500/4000/4500 1024 | DN10000 1024 | | On most node types, available resources (disk space and physical | memory) limit the number of processes that can be used effectively. | | .... | | Nodes that have 4 MB or less of physical memory are limited to 64 | processes. Motorola nodes that have more than 4 MB of memory (and sup- | port more than 64 processes) have a maximum number of processes | equivalent to 32 times the MB size. DN10000 nodes have a maximum | number of processes equivalent to 16 times the MB size. For example, | a DN4000 with 32 MB of memory can have 1024 processes (32 x 32). How- | ever, there are still limitations.... A small number of processes is | capable of saturating either the CPU or disk. The number of processes | is no longer the limiting resource on a node. I have been assured privately that the "Next Generation Workstations" (the 9000 series 400) limit is erroneous, and should be just like the DN2500 et. al. If that is not the case, we're going to take our machines and shove them in a very uncomfortable location. :-) note that the old clunker machines will still be limited to 64 processes, however. John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either)
huntting@boulder.Colorado.EDU (Brad Huntting) (09/07/90)
In article <6881.26e59640@jetson.uh.edu> cosc4fp@jetson.uh.edu writes: >This is driving crazy..... how does one configure the "kernel" on an >Apollo? I need to raise the max number of processes on a machine. I too would like to change some system paramaters on my gateway machine which runs several daemons, and cnews. Specifically the 'max open files' parameter. But like other non-standard aspects of HPollo's (swap partitions, acl's, /etc/{passwd,group}, dm, type-mgrs, device-drivers and many many more) I'm sure "it's a feature not a bug". A feature which, like so many others, makes these machines more quirky less usefull and more difficult to integrate into a heterogenous environment. When are companies (hp/apollo, dec, +many others) going to learn that nonstandard software environments are expensive, and *devalue* their systems? brad huntting@boulder.colorado.edu huntting@sel.bldrdoc.gov
root@VLSI-MENTOR.JPL.NASA.GOV (The vlsi-mentor SysAdmin) (09/07/90)
>When are companies (hp/apollo, dec, +many others) going to learn that >nonstandard software environments are expensive, and *devalue* their >systems? When the nonstandard software environments slow down the systems as much as the standard ones do. :) The DM is a real good thing. It is one of the only things I like about Hpollos. X windows is slow and quirky to me, because I use the DM. It's all in how you look at it. -Dave
krowitz@RICHTER.MIT.EDU (David Krowitz) (09/07/90)
You can't do that. Apollo doesn't allow you to muck with the kernal (that's because Apollo is Just Like Real Unix, only not really). Apollo periodically raises the max number of processes in later OS releases. The problem is that the later OS releases consume so much of the hardware resources on your current hardware that you frequently have to upgrade your machine (which is frequently as expensive as buying a new machine) in order to run the latest OS release. -- 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)
asherman@dino.ulowell.edu (Aaron Sherman) (09/07/90)
huntting@boulder.Colorado.EDU (Brad Huntting) writes: In article <6881.26e59640@jetson.uh.edu> cosc4fp@jetson.uh.edu writes: >This is driving crazy..... how does one configure the "kernel" on an >Apollo? I need to raise the max number of processes on a machine. I too would like to change some system paramaters on my gateway machine which runs several daemons, and cnews. Specifically the 'max open files' parameter. But like other non-standard aspects of HPollo's (swap partitions, acl's, /etc/{passwd,group}, dm, type-mgrs, device-drivers and many many more) I'm sure "it's a feature not a bug". A feature which, like so many others, makes these machines more quirky less usefull and more difficult to integrate into a heterogenous environment. When are companies (hp/apollo, dec, +many others) going to learn that nonstandard software environments are expensive, and *devalue* their systems? Sad. The Apollos are probably the most powerful distributed computing environment ever seen, and some people just won't be happy until they can have them act like a toy. I'm sorry if this sounds like a flame (I was going to send it personally, and be a bit harsher, but this is something that needs to be aired out). Your list of "bugs": Swap partitions - There is no swap partition on an Apollo, they have paging "files" which gives you the ability to use only the space you need. When Sun can do this I'll be impressed. ACL's - What unix machine can even come close to this kind of functionallity?! I've loved this since 9.5, and was MAD when they made it conform to Unix-like modes. /etc/{passwd,group} - I suppose you like yp? 'Nuf said. dm - The best development environment/windowing system that I've seen type-mgrs - Usefull. Not a feature that I have much use for, but it makes things more reasonable for some of the users. Certainly NOT a detriment. device-drivers - I remember the shock that one of our people had when he had to write a device driver for a SysV box. He couldn't belive it was so awkward! The problem here is that Domain/OS is NOT Unix, and the more HP/Apollo tries to make it Unix the more people will get frustrated. Remember that for YEARS Unix was not "standard". Standards. Bah! Standards brought us MSDOS. Standards brought us MOTIF. I much prefer the old Apollo attitude. You want BSD, have it. You want SystemV, have it. Heck, you can make Apollos act like a PC. You can have DDS, TCP/IP or DECNet. You can use X, the DM, even MS-Windows if you're sick. Since the HP-takeover though, people like this poster have been having more of a voice in the direction Apollo's taking, and I fear the day an Apollo is just as much a toy as the next machine. -AJS -- asherman@dino.ulowell.edu or asherman%cpe@swan.ulowell.edu Note that as of 7/18/90 that's asherman@dino.cpe.ulowell.edu "That that is is that that is not is not is that it it is."
pcc@apollo.HP.COM (Peter Craine) (09/07/90)
In article <9009061916.AA08595@pan.ssec.honeywell.com>, thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes: |> |> This is from the beta3 release notes for sr10.3 -- |> | 1.8.1 Increased Number of User Processes |> | |> | |> | Node Type Maximum Processes |> | |> | Next Generation Workstations 64 |> |> I have been assured privately that the "Next Generation Workstations" (the |> 9000 series 400) limit is erroneous, and should be just like the DN2500 et. al. Unfortunately, someone didn't tell you the complete truth. For reasons far too complex (and not for public disclosure) to go into here, SR10.3, as distributed for SAU12 machines (the series 400's) will only allow 64 processes. ** DON'T FLY OFF THE HANDLE YET ** When the 040 chips are available (for the 425s and 433s), there will be a PSK put out (I believe that it will be PSK8). That PSK will have all the new SR10.3 functionality for both SAU12 (the 030 400's) and for SAU11 (the 040 400's). So, until PSK8 is available, only 64 processes. Afterwards, it will be just like the other "modern" nodes. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + "Home is where you wear your hat." Hewlett-Packard + Chelmsford Response Center + *I* don't want my opinions. Why would HP?
rees@pisa.ifs.umich.edu (Jim Rees) (09/08/90)
In article <25786@boulder.Colorado.EDU>, huntting@boulder.Colorado.EDU (Brad Huntting) writes:
I too would like to change some system paramaters on my gateway machine
which runs several daemons, and cnews. Specifically the 'max open files'
parameter.
128 is too many and you want to reduce it to the standard 20?
When are companies (hp/apollo, dec, +many others) going to learn that
nonstandard software environments are expensive, and *devalue* their
systems?
If you don't like it, go buy a PDP-11 and run v7 on it.mike@tuvie (Inst.f.Techn.Informatik) (09/09/90)
In article <ASHERMAN.90Sep7114636@dino.ulowell.edu>, asherman@dino.ulowell.edu (Aaron Sherman) writes: > The problem here is that Domain/OS is NOT Unix, and the more HP/Apollo > tries to make it Unix the more people will get frustrated. Remember that > for YEARS Unix was not "standard". > > Standards. Bah! Standards brought us MSDOS. Standards brought us MOTIF. > I much prefer the old Apollo attitude. You want BSD, have it. You want > SystemV, have it. Heck, you can make Apollos act like a PC. You can have > DDS, TCP/IP or DECNet. You can use X, the DM, even MS-Windows if you're sick. > Since the HP-takeover though, people like this poster have been having > more of a voice in the direction Apollo's taking, and I fear the day > an Apollo is just as much a toy as the next machine. There are great things in DomainOS (you forgot to mention my favorite, the //netdirectory :-), BUT there are annoying things in DomainOS as well, like: * HPollo makes your life miserable, if you need rpc. Ok, NCS is better, but I never managed to get the pcnfsd to compile with NCS :-) * If you need to raise the number of process slots, you're out of luck! * If you complain about a bug in DM, you're told it's not worth fixing as the DM is going to die soon, anyway. * If you have problems with buggy include files, you are told "Wait for OSF/1" * The file-locking semantics of open can drive you mad. * Programs which work on any other computer break on Apollos. 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 ___/
asherman@dino.ulowell.edu (Aaron Sherman) (09/10/90)
mike@tuvie (Inst.f.Techn.Informatik) writes: asherman@dino.ulowell.edu (Aaron Sherman ) writes: me> The problem here is that Domain/OS is NOT Unix, and the more HP/Apollo me> tries to make it Unix the more people will get frustrated. Remember that me> for YEARS Unix was not "standard". me> me> Standards. Bah! Standards brought us MSDOS. Standards brought us MOTIF. me> I much prefer the old Apollo attitude. You want BSD, have it. You want me> SystemV, have it. Heck, you can make Apollos act like a PC. You can have me> DDS, TCP/IP or DECNet. You can use X, the DM, even MS-Windows if you're sick. me> Since the HP-takeover though, people like this poster have been having me> more of a voice in the direction Apollo's taking, and I fear the day me> an Apollo is just as much a toy as the next machine. There are great things in DomainOS (you forgot to mention my favorite, the //netdirectory :-), BUT there are annoying things in DomainOS as well, like: * If you need to raise the number of process slots, you're out of luck! * If you complain about a bug in DM, you're told it's not worth fixing as the DM is going to die soon, anyway. * If you have problems with buggy include files, you are told "Wait for OSF/1" All of these problems are directly related to the fact that HP/Apollo is trying to turn Domain/OS into Unix. This is their greatest mistake, as Domain/OS is 1000 times better than Unix. * The file-locking semantics of open can drive you mad. * Programs which work on any other computer break on Apollos. * HPollo makes your life miserable, if you need rpc. Ok, NCS is better, but I never managed to get the pcnfsd to compile with NCS :-) [BTW: I've been thinking of writing an interface that would allow Sun/RPC to use NCS internally, that would piss off Sun! Of course you could only talk to other NCS-based SunRPC's, but this would just mean re- compiling on both ends (not easy if you don't have source:)] These are the problems that should be worked on instead of tyring to make Domain/OS into Unix. Where I work we have ~20 Apollos, including a DN10000, and I find that most of the users' complaints center around Domain/OS not being like Unix, but so are ALL of the praise! If HP/Apollo takes away Domain/OS, they take away ALL of our reasons for liking the Apollo. Instead they could try to make the mock-BSD and mock-SYSV environments a bit more tollerant (even give out supported docs on the get-info-that-would-be-in-kmem-if-there-was-one calls). I think that what they should do is just add one more supported environment: OSF/1! This would keep the standards-hounds happy, while letting people still get real work done. Anyone from HP/Apollo out there want to comment on this??? -AJS -- asherman@dino.ulowell.edu or asherman%cpe@swan.ulowell.edu Note that as of 7/18/90 that's asherman@dino.cpe.ulowell.edu "That that is is that that is not is not is that it it is."
mike@tuvie (Inst.f.Techn.Informatik) (09/10/90)
In article <ASHERMAN.90Sep9170611@dino.ulowell.edu>, asherman@dino.ulowell.edu (Aaron Sherman) writes: > * If you need to raise the number of process slots, you're out of luck! > All of these problems are directly related to the fact that HP/Apollo is > trying to turn Domain/OS into Unix. This is their greatest mistake, as > Domain/OS is 1000 times better than Unix. Wait! Just a moment! DomainOS to you seems to be Aegis! This is (fortunately) not the case! DomainOS is to be "an enhanced UNIX"! I quite like _that_ idea. But if you have to write software which is portable, you want reasonable UNIX compatibility. Without forfeiting execution speed. I cheer any attempt to make DomainOS more UNIX compatible as long as the good features of DomainOS are retained which are basically networking and CASE support. I can live without DM, but demise of the DM (which is soon to come, from what I hear) is a warning what will soon happen to DomainOS at large. And I can and will not welcome this. If DomainOS is killed, I guess we'd rather go Sun. The implementation of DomainOS is lousy, but the ideas behind it are _great_. So I guess Hpollo should not kill DomainOS, but rather fix the broken parts. The number of process slots has nothing to do with DomainOS being like UNIX or not! Sure, UNIX is more daemon hungry, but daemons are a clean solution and I'd rather have 5 programs doing one thing properly each, rather than one program doing five things in a totally _awkward_ fashion to save daemons. Our gateway for example has 35 processes running _if_nobody_is_logged_on! > [BTW: I've been thinking of writing an interface that would allow Sun/RPC > to use NCS internally, that would piss off Sun! Of course you could > only talk to other NCS-based SunRPC's, but this would just mean re- > compiling on both ends (not easy if you don't have source:)] What does this help most users? You just dont get PC NFS with NCS. And if you've a heterogenous environment you might just as well commit suicide. > These are the problems that should be worked on instead of tyring to make > Domain/OS into Unix. Just my point. But this is exactly what annoys most users. User do not say "I want this workstaion with real UNIX", because they hate the DomainOS ideas, they say it because Sun workstations are perceived to work properly and without bugs (I know this is far from true, but this is the perception :) whereas in DomainOS all kinds of things do not work. > [...] are ALL of the praise! If HP/Apollo takes away Domain/OS, they take away > ALL of our reasons for liking the Apollo. Instead they could try to make > the mock-BSD and mock-SYSV environments a bit more tollerant (even give > out supported docs on the get-info-that-would-be-in-kmem-if-there-was-one > calls). Sure! E.g., things like the syscall() system call or related stuff. I know these things ain't clean and nice, but some times (e.g. if you want to compile SB prolog) they are necessary. > I think that what they should do is just add one more supported environment: > OSF/1! Would be nice, but eill not happen. I think there is a simple reason for this: HP currently has to support MS-DOS, DomainOS 68k, DomainOS Prism, HP PA, HP 68k machines. Also, I think, they have some proprietary OS as well. Now, I guess, HP would rather have two lines, MSDOS and _one_ UNIX line. They have already killed (or are doing it right now) DomainOS Prism and the next to fall will be DomainOS. It simply doesn't make economic sense to have 5 different kinds of OS. > This would keep the standards-hounds happy, while letting people still get > real work done. Standards are necessary if you want to live in a heterogenous environment. I guess you won't buy a VCR if it isn't able to play some other manufacturer's cassettes. Same thing for computers! I guess HPollo should think _twice_ about killing DomainOS. I know a lot of people who would rather have SunOS as their OS and not HP-UX. So if this is the future, I guess HP will lose _lots_ of customers. Worrisome is for exmple the demise of the DM, which makes many people unhappy. I guess we should try to find out what HP wants to do to DomainOS next. I guess that DomainOS will not survive the DM's death very long. For many users, DomainOS _is_ the DM, and if they can't have the DM, they will go somewhere else. I HP should pay attention to its customers feelings. Otherwise, the only return from the acquisition of Apollo will be disgruntled customers who will never ever buy HP again. (50% of all people I know say that without the DM they will go Sun, because if they have to learn a new editor, it will be emacs, so that they are insulated from all further changes. And up-to-date GNU software is not easy to get for DomainOS.) 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 ___/
asherman@dino.ulowell.edu (Aaron Sherman) (09/11/90)
mike@tuvie (Inst.f.Techn.Informatik) writes: asherman@dino.ulowell.edu (Aaron Sherman) writes: > * If you need to raise the number of process slots, you're out of luck! > All of these problems are directly related to the fact that HP/Apollo is > trying to turn Domain/OS into Unix. This is their greatest mistake, as > Domain/OS is 1000 times better than Unix. Wait! Just a moment! DomainOS to you seems to be Aegis! This is (fortunately) not the case! DomainOS is to be "an enhanced UNIX"! I quite Domain/OS is the culmination of the "Aegis-years". This IS the case. And, much of it worked better then. Actually the inetd concept works better as a multi- proccess. I cheer any attempt to make DomainOS more UNIX compatible as long as the good features of DomainOS are retained which are basically networking and What I was saying was that the Domains/OS ITSELF should not bother trying to be more Unix-like. Sure, you can do what you will to make the Mock- BSD and SysV environments as kind as possible, but why try to make Domain/OS more like Unix. Unix is about 10 years behind Domain/OS! CASE support. I can live without DM, but demise of the DM (which is soon to come, from what I hear) is a warning what will soon happen to DomainOS at large. And I can and will not welcome this. If DomainOS is killed, I guess we'd rather go Sun. The implementation of DomainOS is lousy, but the ideas behind it are _great_. So I guess Hpollo should not kill DomainOS, but rather fix the broken parts. No, the implimentations of the Unix-interfaces are lousy. But no one at Apollo notices this, because THEY DON'T USE THEM! daemons. Our gateway for example has 35 processes running _if_nobody_is_logged_on! This is good? [...] whereas in DomainOS all kinds of things do not work. Such as? Domain/OS, now, not the Unix-like environments. > I think that what they should do is just add one more supported > environment: > OSF/1! Would be nice, but eill not happen. I think there is a simple reason for this: HP currently has to support MS-DOS, DomainOS 68k, DomainOS Prism, HP PA, HP 68k machines. Also, I think, they have some proprietary OS as well. Now, I guess, HP would rather have two lines, MSDOS and _one_ UNIX line. They have already killed (or are doing it right now) DomainOS Prism and the next to fall will be DomainOS. It simply doesn't make economic sense to have 5 different kinds of OS. I was not talking about a new OS, but a new Domain/OS user/programmer environ- ment. I've used HP/UX. It's a lousy Unix port, and it should be tossed long before Domain/OS. > This would keep the standards-hounds happy, while letting people still get > real work done. Standards are necessary if you want to live in a heterogenous environment. I guess you won't buy a VCR if it isn't able to play some other manufacturer's cassettes. Same thing for computers! Sure, but I'd rather buy a VCR that played ALL manufacturer's cassettes. Besides, look at what standards have gotten us with VCRs. Beta is a LOT better than VHS. But, because VHS is THE STANDARD, Beta goes away (exept in a few areas out West where quality won out). I guess HPollo should think _twice_ about killing DomainOS. I know a lot of They sure should. the DM they will go Sun, because if they have to learn a new editor, it will be emacs, so that they are insulated from all further changes. And up-to-date GNU software is not easy to get for DomainOS.) I've got all the the latest for our machines. -AJS -- asherman@dino.ulowell.edu or asherman%cpe@swan.ulowell.edu Note that as of 7/18/90 that's asherman@dino.cpe.ulowell.edu "That that is is that that is not is not is that it it is."
mike@tuvie (Inst.f.Techn.Informatik) (09/11/90)
In article <ASHERMAN.90Sep10201322@dino.ulowell.edu>, asherman@dino.ulowell.edu (Aaron Sherman) writes: > Domain/OS is the culmination of the "Aegis-years". This IS the case. And, much > of it worked better then. Actually the inetd concept works better as a multi- > proccess. Not "real" UNIX programs! > What I was saying was that the Domains/OS ITSELF should not bother trying > to be more Unix-like. Sure, you can do what you will to make the Mock- > BSD and SysV environments as kind as possible, but why try to make Domain/OS > more like Unix. Unix is about 10 years behind Domain/OS! Yeah, AND improve the performance. But this will only work if you modify the kernel, I guess. > No, the implimentations of the Unix-interfaces are lousy. But no one at Apollo > notices this, because THEY DON'T USE THEM! Apollo's implementation of the Unix-interfaces are lousy! Ever tried to use lpr/lpd? It will drive you mad! Sure, I know prf is _much_ better, but we just happen to like the lpr/lpd, because it allows easy integration of other hosts. > daemons. Our gateway for example has 35 processes running > _if_nobody_is_logged_on! > > This is good? No, not really, but that's the way it is. We need nfs, nntp, nnmaster, sendmail, and all the other daemons. And you can't discuss this need away. > [...] whereas in DomainOS all kinds of things do not work. > > Such as? Domain/OS, now, not the Unix-like environments. I need the UNIX-like environments! I don't care for Aegis! If I have to write a program which works on _any_ UNIX host, I can't use Aegis. This really is Apollo-style. They will say "Just use Aegis, the problems are in the UNIX environments!" Well I need UNIX, and therefore I need a *working*UNIX* > [...] and the next to fall will be DomainOS. It simply doesn't make > economic sense to have 5 different kinds of OS. > > I was not talking about a new OS, but a new Domain/OS user/programmer environ- > ment. I've used HP/UX. It's a lousy Unix port, and it should be tossed long > before Domain/OS. No, but I'm afraid that they don't really want to spend any effort in DomainOS and rather kill it today than tomorrow. (I've use HP/UX also. It _is_ lousy!) > Sure, but I'd rather buy a VCR that played ALL manufacturer's cassettes. > Besides, look at what standards have gotten us with VCRs. Beta is a LOT better > than VHS. But, because VHS is THE STANDARD, Beta goes away (exept in a few > areas out West where quality won out). Actually, VIDEO 2000 was better still. But today everybody buys VHS, because you get software (videos) for it. Same thing with UNIX. Aegis may be better, but you don't get software. > I guess HPollo should think _twice_ about killing DomainOS. I know a lot of > > They sure should. If not, "Here comes the Sun,..." 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 ___/
agq@itd1.dsto.oz (Ashley Quick) (09/13/90)
I have seen all the discussion about "modifying the kernel", etc, and wish to comment: 1. As a new comer to Apollos about 8 months ago, I have found the environment (DM) nice! Killing it for the sake of standards would be silly. *** HP/APOLLO PLEASE TAKE NOTE! *** Allowing interoperability with things like X is desirable, but I have found X to be YUK to use!!!. 2. We run PCNFSD here. It compiles without any problems, IF YOU GET HOLD OF THE SUN RPC SOURCE CODE. Something to note about PC NFS: PC NFS is plain ordinary NFS for a PC. So you need to run NFSD on your host (whatever flavour, SUN, VAX/VMS, etc). As the PC is a crummy little beast and does not know about user ID's, you need a special piece of software called the AUTHENTICATION SERVER, known as PCNFSD to do this special function. This is the thing that is supplied in source form ON THE PC disks when you by PC NFS from SUN. If we can compile and run it, anybody can. Dont bring up silly issues like this if you dont try very hard. (BTW: there is a bug in the SUN Supplied source code for PCNFSD which I posted a fix for a week or so back). I have found in testing that an Apollo DN3000 running SR10.2 performs as well as a SUN 3/280 for PC NFS file transfer. (Someday I will post about 10 pages of benchmarks of various NFS implementations.) PC NFS is NOT a big deal! 3. The first coding job I did was to write a device driver interface on a brand new DN4500. This machine was to be a divisional server and I found one day that all the files had been shifted on! I expected this to be a problem as the machine would not be "stable". On the contrary, the PBU_$ system calls allow a device driver to be loaded and unloaded under user controll. You really have to try very hard to crash a machine using this approach. Further, you dont need to reboot the machine every time you make a change, and (by trying a bit harder) you can debug a device driver (call side). [The interrupt side can be done by placing trace info into shared storage]. I was therefore able to develop device handling software without killing the node and affecting others. From this point of view, DOMAIN/OS is GOOD!!!!!! Why the UNIX crowd have not taken this approach bemuses me. 4. System software using the DOMAIN calls is easy to write. The calls also stand out in the code, making debugging / understanding a program easy. You really need to be a UNIX guru to follow some C programs. Example: Domain Mailbox calls WORK WELL!!!! Try using UNIX sockets! YUK YUK YUK YUK YUK!!!! DOMAIN/OS supports several different types of interprocess communication, and they work and they are simple to understand. If you want a brain-dead approach, you can still uses SYSV or BSD IPC as well. (Or all at once if you are a real masochist!) The whole approach to DOMAIN/OS system calls, by breaking them up into "manager" function makes it easy to write software. The whole O/S has had a lot of thought put into it. Writing it off as a crummy implemenation is being far too simplistic. Yes there are faults. EVERYTHING has faults. At least they can be either worked around or get fixed (eventually: SR10.1 print servers look like a good idea without enough development time). 6. Type managers (and typed files) are a great idea! Once again, you can set up special handling without putting user-specific handling into the OS (how do you debug it it its in the OS? Must be pretty hard!) Type managers allow the user to develop and debug (LINE BY LINE with DDE) special file handling systems without disturbing other users on the node or the network. Pretty clever, Eh? 7. Dynamically loaded libraries allow programs to be written with a dependance on a "balck box" module. That module can be changed without requiring a recompilation of anything which depends upon it. (Unless the interface changes, obviously). The use written libraries can then be set up (WITHOUT MODIFICATION) to be loaded at boot time and become available to everybody. Effectively, it is possible to EXTEND the OS. 8. There are some things where UNIX inter-operation does not work. There are not really too many, and lots of limitations are documented in the manuals. Take an objective look at UNIX some time. It has grown over the years and reeks of lots of undergraduate computing projects! What I am getting at is that the system calls and the utilities and the directory structure are all a big mixed up mess! It all seems to have had more bits tacked on without much thought, and definitely without a total SYSTEM approach. It is a lazy persons O/S from the ground up. The best thing that could happen to UNIX is to scrap it and start again. Unfortunately that will not happen, as UNIX seems to have become trendy. It is JUST LIKE THE IBM PC. A case of mediocrity wins by MIGHT not RIGHT. Sigh! (Apologies to IBM if that upsets them!) I also get the feeling that OSF/1 will end up some kind of horrible monster. Reminds me of the joke about the Elephant: a mouse designed by a committee. To ME, the best HP/Apollo could do is to add another compatibility type: SYSV, BSD and OSF/1. I suspect it wont happen, though. If the problems with the UNIX environments could be fixed, that might cure some gripes. Why is UNIX the way it is? Because MOST people (especially in Universities) have NOT idea about writing GOOD STRUCTURED code. [If you are in a university and take exception, so be it - but look at your undergrads... how good are they? Most would be OK but NOT GOOD]. I really dont think people are taught to take a black box [information hiding] approach to writing software, and that has shown up in UNIX due to its evolution. DOMAIN/OS reeks of being written by a group to a set of standards, and being designed from the ground up. Writing code in C is also part of the problem - it is just TOO easy to get away with TOO much in C. Sorry C hackers (yes, I have become one too, but at least I can be objective and say I do not like it a lot!), but C programmers tend to get lazy and that leads to crypography. I heard a guy from a military software contracting company say that you do not write programs in C, you cipher in it! Finally: remember: every UNIX is NOT standard. How many BSD 4.2's have YOU used and found that the MORE command behaves differently!!!!! Not to mention SYS5!!!!! PLEASE PLEASE PLEASE dont trot out the tired old line about UNIX being some kind of standard! It IS NOT. (It may become one by default [ie pressure of users]. That does not make it NICE to USE or PROGRAM under!). 9. It was the story that Apollo would not have continued if they were not taken over by HP. If that is so, we should give thanks for small mercies! 10.What is so good about SUN machines anyway? They run BSD or SUNOS, they have umpteen incompatible hardware platforms, their networking is NFS (sort of client / server rather than peers). They win by selling lots at good prices, not by any kind of O/S superiority! Yours in anticipation of a balanced viewpoint, Ashleigh Quick AGQ@dstos3.dsto.oz.au Defence Science and Technology Organisation, Salisbury, South Australia 5108.
nazgul@alphalpha.com (Kee Hinckley) (09/13/90)
In article <1215@fang.dsto.oz> agq@itd1.dsto.oz (Ashley Quick) writes: > >I have seen all the discussion about "modifying the kernel", etc, >and wish to comment: > >1. As a new comer to Apollos about 8 months ago, I have found the > environment (DM) nice! Killing it for the sake of standards would > be silly. *** HP/APOLLO PLEASE TAKE NOTE! *** Allowing > interoperability with things like X is desirable, but I have found > X to be YUK to use!!!. Agreed. However the DM is dead in the long term, the market has decided. There is one and only one correct solution - take the best of the DM and migrate it to X/Motif. And furthermore, make those fixes available to OSF, the X Consortium, etc.. Any other path relegates Apollo to the dustbins of forgotten operating systems. >2. We run PCNFSD here. It compiles without any problems, IF YOU GET > HOLD OF THE SUN RPC SOURCE CODE. Something to note about PC NFS: J. Random User doesn't compile source code - they want working binaries, and they'll pay for them (if they have to). Any other solution won't fly. (Note that if you read this group you aren't J.R. User by definition.) >3. The first coding job I did was to write a device driver interface ... > From this point of view, DOMAIN/OS is GOOD!!!!!! > Why the UNIX crowd have not taken this approach bemuses me. Yep. So Apollo should move this technology to OSF/1, not just to their veresion, but to all versions. Port it and export it. That's the only way to win the system software game. >4. System software using the DOMAIN calls is easy to write. The calls > also stand out in the code, making debugging / understanding a program > easy. You really need to be a UNIX guru to follow some C programs. Debateable, but it doesn't really matter if it doesn't run on other machines. However if you really prefer "rws_$open" to "open" I would suggest using #define. :-) > Example: Domain Mailbox calls WORK WELL!!!! Try using UNIX sockets! > YUK YUK YUK YUK YUK!!!! DOMAIN/OS supports several different types > of interprocess communication, and they work and they are simple to > understand. If you want a brain-dead approach, you can still uses > SYSV or BSD IPC as well. (Or all at once if you are a real masochist!) Port it... >6. Type managers (and typed files) are a great idea! Once again, you ... >7. Dynamically loaded libraries allow programs to be written with > a dependance on a "balck box" module. That module can be changed > without requiring a recompilation of anything which depends upon it. This one the Unix people have actually learned. However they see it as a way of saving disk space and memory, they haven't learned yet that if you use procedural abstraction instead of data abstraction you don't have to recompile. That will come, but it'll take time. >8. There are some things where UNIX inter-operation does not work. There > are not really too many, and lots of limitations are documented in the > manuals. Documenting that things work doesn't really do anything to please the programmer who is trying to do something that ought to be simple (try hooking up a Telebit to an Apollo sometime. RTS/CTS?! 19.2?!). It's not that Apollo doesn't know about the problems, it's just that Apollo consistantly made the mistake of doing the advanced stuff without first covering the simple things. Now someone else's simple thing has one the war. If Apollo moves fast (and it encourages me to see the number of Apollo people working with OSF) they can get that advanced stuff onto OSF/1 and make it a standard there and then we won't see 10 years of work go down the tubes. > If the problems with the UNIX environments could be fixed, that > might cure some gripes. Apollo is the one company that really knows what those things are. Hopefully that expertise can be put to use. > Why is UNIX the way it is? Because MOST people (especially in > Universities) have NOT idea about writing GOOD STRUCTURED code. Debatable. I'd take BSD code over Bell Labs any day. >10.What is so good about SUN machines anyway? They run BSD or SUNOS, They sell. No one can beat them alone, but OSF offers a chance to beat them together. -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.