FERGUSON@BKNLVMS.BITNET (06/09/87)
I got onto this mailing list under the impression that some constructive things would come out of it. So far, all I've seen is a lot of complaining about UNIX, AEGIS, and anything else that ever remotely bothered anyone. If you think your arrogant whining is going to help the situation, I think you're wrong. Maybe if you were a little more positive about you're working environment(AEGIS OR UNIX), you'd spend less time complaining on the mail network, and you're productivity would increase. That was the major goal of engineering workstations in the first place. If you really can't accept what people are offering, write your own operating system. That's how UNIX came about...
Giebelhaus@HI-MULTICS.ARPA (06/10/87)
I disagree. While there is some religion in this discussion, some useful comparisons are being made. Also, I'll be sure that the product manager for DOMAIN/IX gets a copy of this discussion. A third advantage is this is helping with ideas for the ADUS DOMAIN/IX SIG.
srt@CS.UCLA.EDU (Scott "Dr. Pain" Turner) (06/10/87)
Okay, here's a new topic, Apollo jokes...
Q: What does the sign on the Apollo Service Office say on Sunday?
A: Pad closed.
Yuk, yuk.
Scott R. Turner
UCLA Computer Science "Does school ever end?"
Domain: srt@ucla.cs.edu
UUCP: ...!{cepu,ihnp4,trwspp,ucbvax}!ucla-cs!srtmartin@medix.UUCP.UUCP (06/10/87)
I disagree. There are useful comments being made in this discussion,
though it has at times taken on an almost religious fervor. However,
I've learned a few things about the capabilities of AEGIS, and now I'm
willing to invest a little more time learning the Apollo-specific tools
(since I can do almost anything with UNIX tools, I've seen very little
reason to invest the time and energy it takes to learn a new/different
development environment). I certainly think that this discussion would
be of use to Apollo's marketing people, as it could give them a
different perspective on the engineering workstation market.
Keep the flames going.
Regards,
Brian K. Martin, M.D.
Martin Information Systems, Ltd.
3420-A Hinahina Street
Honolulu, Hawai'i 96816
PHONE: (808) 735-5661
ARPA: uhccux!medix!martin@nosc.mil
UUCP: { ihnp4,ucbvax,dcdwest,seismo }!sdcsvax!nosc!uhccux!medix!martinjoe@auspyr.UUCP (Joe Angelo) (06/10/87)
Speaking of which.... maybe you can take your own advice?
Without ''bickering'' or other forms to dispose complaints, nothing would
change, now would it?
--
"No matter Joe Angelo, Sr. Sys. Engineer @ Austec, Inc., San Jose, CA.
where you go, ARPA: aussjo!joe@lll-tis-b.arpa PHONE: [408] 279-5533
there you UUCP: {sdencore,cbosgd,amdahl,ptsfa,dana}!aussjo!joe
are ..." UUCP: {styx,imagen,necntc,dlb,jmr,sci,altnet}!auspyr!joerichard@gryphon.UUCP (06/11/87)
Yeah, bickering serves no point and decreases net.bandwidth, but
lets not let "computer wars" mentality get in the way of real
constructive comparisons of computer hardware and software.
Now, you wanna learn some usefull Apollo tips ? Here are some I
gleaned from the ADUS sys_admin sig meeting last week in Chicago.
1) (Documented, someplace, but still highly amusing) In
SR 9.5.1 the Fortran optimizer is a little sick. Use
opt -0 -cpu any
2) (Not documented) Under 9.5.1, on a freshly invol'd
drive, saying 'acl // -all' corrupts the disk with *NO*
hope of recovery. Use edacl instead. Also applies to
/, /sys, /sys/node_data.
3) We found this one, and havn't run into anybody else
that has: On 9.5, 9.5.1, on DN3000's, sometimes they
will miss/ignore an interrupt coming from the AT bus.
This causes the machine to fail with a bus time-out.
Fixed in 9.6.
"I'm sure 9.5.1 is going to introduce a lot of deadlocks"
-Apollo customer support
4) There is a new config.sys and ansi.sys for the PC
co-processor, that speeds up the mono display
a whole bunch. A lot of these DPCC's are in need
an upgrade that brings them up to the latest rev, there
should be a part on the lower right that says "9900_01".
5) The software that lets you use the DPCC across the net
is in Beta test. RSN.
6) You can pipe an AEGIS command to a UN*X command iff
the AEGIS command is the first command. This is not commutative.
7) Since SR.10 will be a hybrid UN*X/AEGIS kernel, who wins
in case of a dispute bewteen the two ? The official line from
Apollo seems to be "Without special dispensation, YOU CAN NOT
BREAK AEGIS".
8) When it asks you if you want to blast processes, sometimes
all it needs is a little time to finish up. This is especially
true of VT100 windows that have been made into icons. Deicon
them first, kill them, then quit.
Can we get back to bickering now please ?
--
Richard Sexton
INTERNET: richard@gryphon.CTS.COM
UUCP: {akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richardnazgul@apollo.uucp (Kee Hinckley) (06/13/87)
In article <679@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes: > Now, you wanna learn some usefull Apollo tips ? Here are some I > gleaned from the ADUS sys_admin sig meeting last week in Chicago. > > 6) You can pipe an AEGIS command to a UN*X command iff > the AEGIS command is the first command. This is not commutative. Ummm. Could someone kindly give me an example of this? This is the first I've heard of it and I have the (mis?)fortune of currently owning all of the shells. I certainly can't duplicate it. It *is* true that some Unix commands are sloppy with their return status and will occasionally exit with a bad exit value which will cause the Aegis shell to discontinue the pipe, but otherwise I can't imagine why this would be true. This discussion of Aegis vs. Unix treats things as though they are two completely different animals, which misses the point. One of the things that *I* like about the environment is that I can mix and match Aegis, System V, and BSD4.2 whenever I want to. -kee Incidentally, I think someone once complained that the Aegis shell didn't even have parallel pipes. I almost changed that at SR8, only to discover that a number of people were doing things like: "catf file | srf > file" (translation: "cat file | sort > file") and making any changes would break them quite badly. Sigh. -- UUCP: {mit-erl,yale,uw-beaver}!apollo!nazgul ARPA: apollo!nazgul@eddie.mit.edu 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.
ram-ashwin@YALE.ARPA (Ashwin Ram) (06/15/87)
> From: apollo!nazgul@beaver.cs.washington.edu (Kee Hinckley) > > Incidentally, I think someone once complained that the Aegis shell didn't even > have parallel pipes. I almost changed that at SR8, only to discover that a > number of people were doing things like: "catf file | srf > file" > (translation: "cat file | sort > file") and making any changes would break > them quite badly. Sigh. My feeling is that disallowing "catf file | srf > file" is no worse than disallowing "srf file > file" (which many naive users also tend to do), and the advantages of parallel pipes outweigh this minor disadvantage anyway (e.g., having partial results output on the screen so that you can work with them while the command runs to completion). For the same reason, it would be nice if LD .../?*.PAS, for example, printed your Pascal files as it listed them (similar to LS -R), rather than all together at the end. -- Ashwin Ram -- ARPA: Ram-Ashwin@yale UUCP: {decvax,linus,seismo}!yale!Ram-Ashwin BITNET: Ram@yalecs
nazgul@apollo.uucp (Kee Hinckley) (06/19/87)
In article <8706151717.AA02467@yale-eli.arpa> ram-ashwin@YALE.ARPA (Ashwin Ram) writes: > > Incidentally, I think someone once complained that the Aegis shell didn't even > > have parallel pipes. I almost changed that at SR8, only to discover that a > > number of people were doing things like: "catf file | srf > file" > > (translation: "cat file | sort > file") and making any changes would break > > them quite badly. Sigh. > > My feeling is that disallowing "catf file | srf > file" is no worse than > disallowing "srf file > file" (which many naive users also tend to do), and > the advantages of parallel pipes outweigh this minor disadvantage anyway Ah, but you don't have to answer the UCR from someone who didn't read the release notes and just trashed a weeks worth of work. :-) Seriously, as I've mentioned before, we tend to be very conservative when it comes to breaking things. In this case I didn't feel that the advantages were worth the risk. > (e.g., having partial results output on the screen so that you can work with > them while the command runs to completion). For the same reason, it would be > nice if LD .../?*.PAS, for example, printed your Pascal files as it listed > them (similar to LS -R), rather than all together at the end. I agree that would be nice, but the layering of wildcard expansion (via. the CL_$ calls) is such that I think it would be difficult to change. The underlying wildcard calls would have to save state, return a pathname and then be able to restart (further more they would have to be able to do this with multiple different wildcard requests interleaved). -- Incidentally, on the subject of UCRs, I have to agree, they are NOT simple to fill out, in fact I don't understand a number of the fields myself. Remember that software development is an ongoing process, and just because it's shipped that way now doesn't mean either that it won't change (hopefully for the better :-) or that we like it that way. I must say however that this feedback has been very good for giving us a feel on what people are thinking, and encouraging in that so far I haven't seen any major issues that we haven't already decided we should address in one way or another. However, if you do have specific changes/bugs to report it would be wise to use the UCR system, despite its foibles, since things posted here are too likely to get missed or forgotten amidst the volume. (All the usual disclaimers apply.) -kee -- UUCP: {mit-erl,yale,uw-beaver}!apollo!nazgul ARPA: apollo!nazgul@eddie.mit.edu 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.