jim@bauhaus.Stanford.EDU (James Helman) (02/13/90)
venkat@csun4.cs.uh.edu (Venkat Viswanathan) writes:
2) Xsgi keeps crashing on a regular basis and dumps core onto the root
partition. It regenerates itself automatically though.
Yes, it does crash a lot, doesn't it. But count yourself lucky that
the IRIX 3.2 version doesn't crash as often as previous versions did.
Another big plus: text is always printed right side up now.
Seriously, SGI's X is a lot faster and a lot more usable now than ever
before. But it is still too buggy for a real product.
I'm amazed that products like this could get throuch QC. Most of the
worst bugs in SGI's X server, in this and in previous releases, have
shown up within 5 minutes of use. Perhaps, their beta sites have to
sign an agreement to only use xterm and have no more than one window
open at a time. ;-)
The question that I would REALLY like the answer to (besides the
obvious, when can I get a better release) is whether the SGI stuff on
the X11R4 tape runs better or worse than the stuff shipped with IRIX
3.2. Any answers from SGI? Any experience from the real world?
BTW, don't bother trying to get anyplace with the hotline on this.
I've been going around with them for over a year about X. The best
they can do is put you on the "hot list" for the next release. The
support "engineer" who answered my latest X call, after making a
couple pointless digressions, focussed on THE REAL PROBLEM, asking
whether the final "b" in "exit status: 0x8b" was capitalized or not.
Jim Helman
Department of Applied Physics P.O. Box 10494
Stanford University Stanford, CA 94309
(jim@thrush.stanford.edu) (415) 723-4940 treed%tom.dallas@SGI.COM (Thomas E Reed) (02/13/90)
HI:
It sounds like you are doing more serious X development that the average
SGI user. If you would care to share your "SPECIFIC" problems with SGI's
X-server I'm sure the engineers responsible for the Quality of that product
would be greatful to here them. You can mail them to me and I'll forward them
on, or you could post them on this mailing list as I'm sure most if not all
of the engineers subscripe to it. Making blanket statements without supplying
DETAILS of fact does little to enlighten others or to help provide the Quality
of Product you and other deserve.
The same holds true for the hotline.
These statements are my own ..etc....
--
Tom Reed
SGI - Dallas
email: treed@sgidal.dallas.sgi.com
vmail: 8705
phone: 214-788-4122seth@miro.Berkeley.EDU (Seth Teller) (02/14/90)
In article <JIM.90Feb12192739@bauhaus.Stanford.EDU> jim@bauhaus.Stanford.EDU (James Helman) writes: > > ... non-specific X complaints deleted ... > then continues with this: > BTW, don't bother trying to get anyplace with the hotline on this. > I've been going around with them for over a year about X. The best > they can do is put you on the "hot list" for the next release. The > support "engineer" who answered my latest X call, after making a > couple pointless digressions, focussed on THE REAL PROBLEM, asking > whether the final "b" in "exit status: 0x8b" was capitalized or not. > > Jim Helman > Department of Applied Physics P.O. Box 10494 > Stanford University Stanford, CA 94309 > (jim@thrush.stanford.edu) (415) 723-4940 i'm sure there are those working at sgi who would like to respond to your posting in kind; however, good sense and discretion prevent them. since i am unfortunate enough to have the benefit of neither, you'll kindly allow me a few words. this sort of public castigation of hotline people is unwarranted, unfair, and in my (not entirely disinterested) opinion, borders on abusive. at best, the responses you'll get will be like mine (of protest), or frustrated silence (from those at sgi who are offended but unable to respond, unless they do so with enormous tact-- something which many may not be able to justify the time or patience for after reading your post). what effect did you expect it to have? frantic, subservient hotline people jamming your phone lines with offers of more help? netgroup readers stuffing your mailbox with detailed descriptions of work- arounds? you didn't detail any problems! look, at any company, there are going to be times when hotline people are left casting about in deep water by circumstances, whether they be development/release schedules, communication failures with engineers, or just the general finiteness of their resources, time, and energy. rather than direct criticism _at_ them, why not direct it _to_ those who allocate training, resources, and support to the hotline itself? and in a real letter, on paper (these seem still to be so much more effective than any ephemeral posting). i'm sure i've said more than my share. sincerely yours, seth teller <seth@miro.berkeley.edu>
ghelms@hellfire.csd.sgi.com (Gretchen Helms) (02/14/90)
Jim Helman writes: >The question that I would REALLY like the answer to (besides the >obvious, when can I get a better release) is whether the SGI stuff on >the X11R4 tape runs better or worse than the stuff shipped with IRIX >3.2. Any answers from SGI? Any experience from the real world? Clients and libraries and such should work fine. I have been informed by one of our X engineers that the server from the X11R4 tape will *not* build. >BTW, don't bother trying to get anyplace with the hotline on this. >I've been going around with them for over a year about X. The best >they can do is put you on the "hot list" for the next release. The >support "engineer" who answered my latest X call, after making a >couple pointless digressions, focussed on THE REAL PROBLEM, asking >whether the final "b" in "exit status: 0x8b" was capitalized or not. Many times when a call comes in that is not a request for information, the best policy for our customers is to have in hand a list that contains the sequence of events that caused the problem, the behaviour exhibited by the machine as it crashes or bombs, and the specific error codes produced at that time. This allows us to search through our database to locate the same error and cross-reference a previous call to see if it could impact the current one. Unfortunately, many of the error codes are somewhat obscure. Frequently a missing digit or the difference between uppercase and lowercase can be crucial in pinpointing the problem. For example, the difference between "aborted with" and "killed by" often lets us know whether a program caught an internal error or was terminated before it had a chance to progress past a given point. For this reason, we ask for your patience when we request more information on the error codes or symptoms that are described. G. "Murdock" Helms A host is a host & from coast to coast Silicon Graphics No one will talk to a host that's close Product Support Engineer Unless the host (that isn't close) ghelms@sgi.sgi.com Is busy, hung or dead. -D. Lesher
chuck@melmac.harris-atd.com (Chuck Musciano) (02/14/90)
In article <22066@pasteur.Berkeley.EDU> seth@miro.Berkeley.EDU (Seth Teller) writes: >this sort of public castigation of hotline people is unwarranted, >unfair, and in my (not entirely disinterested) opinion, borders >on abusive. Hear, hear! Every experience I have had with the hotline people has been exemplary. They were well versed in the technical details of the machine, knew exactly how to fix my problem, and didn't treat me like an idiot. They followed up with several phone calls until they were sure that everything was OK. I couldn't ask for more. Chuck Musciano ARPA : chuck@trantor.harris-atd.com Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck PO Box 37, MS 3A/1912 AT&T : (407) 727-6131 Melbourne, FL 32902 FAX : (407) 727-{5118,5227,4004} The answers to life's problems aren't at the bottom of a bottle, they're on TV! -- Homer Simpson
jim@baroque.Stanford.EDU (James Helman) (02/15/90)
Ahh luv the smell of napalm in the morning. Be forewarned, I even
start my barbie with a blow torch. Seriously. I find it is much more
effective than lighter fluid.
I won't go into the litany of the "non-specific" problems we've had in
several areas. But they were substantial and have a long history.
Now that I know where I can send them, I've submitted them to SGI.
Hopefully, resolution is just a short release away.
I would like to share one divine revelation though. The New Testament
says there is one sin which can never be forgiven, but never names it.
But, it has been revealed to me. The blackest depths of hell are
reserved for those who violate The First Law of Window Systems:
A window server shall never dump core except in case
of hardware failure or nuclear war.
I suppose, DOD might take exception with the latter exclusion. But
anyone who has used buggy window systems will agree, that when a
window server dies, it's a very bad thing. All that context, jobs in
progress, network connections, my very stateful 25MB of LISP and data
with two hours of processing time, all go down the toilet. If it
happens enough times, it can adversely affect your personality.
"Experimental" stuff like MIT's X10R3 server dumped core rather
frequently. As did MIT's X11R2 before all the patches made it out.
We completely skipped X11R1 because of its reputation. But, at least
on our Sun-3's, I don't think I ever got dumped on by MIT's X10R4,
X11R3 or X11R4 server. Not bad for code that isn't even commercially
supported. Similarly SunView (ok. so it's not a server.) never
bombed on me. The same can not be said of any of SGI's X releases to
date, although, as I said they are getting better: the MTBD is down by
at least factor of ten. Similarly, in all prior 4Sight releases (I
haven't seen it yet in 3.2), if you tickled GL the wrong way or even
did normal operations on a heavily paging system, grcond would choke,
and you would get bombed back to the login prompt. Miss Manners would
not approve.
As I said about SGI's X. It is now faster and more usable than ever
before. The OS is incomparably better than in the IRIS 1400 days, aka
the stone age. But if Silicon Graphics aspires to be a big guy, (in
the long term, there will only be big guys in the workstation market),
it needs not only to offer leading edge performance (which they do
better than anyone else) but also offer absolutely top notch software
and support.
Jim Helman
Department of Applied Physics P.O. Box 10494
Stanford University Stanford, CA 94309
(jim@thrush.stanford.edu) (415) 723-4940
Waiting for perfection, in the meantime:
"Man is not at all good. So hit him on the head. If you hit him on
the head enough, then perhaps he will become good" - Brecht, The
Threepenny Opera