bobr@zeus.TEK.COM (Robert Reed) (01/28/88)
I haven't played with an Apollo WS for nearly a year, but one of my lack of programmability frustrations with the DM was that there was no way to write to the title bar (to do things like indicate current directory, etc.). There were lots of other frustrations, but this is one I haven't seen mentioned yet. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
klee@daisy.UUCP (Ken Lee) (02/06/88)
This discussion so far has mainly discussed the differences between window manager user interfaces, not the window systems themselves. I'd be interested in hearing what people have to say about the deeper issues. Here are some things that concern me right now: 1. The NeWS server is completely and dynamically extensible. At any time, the client can download functions or programs for the server to execute. In X, these functions must all run on the client side (also possible in NeWS, but not necessary), thus requiring much more communication between the client and sever. Extensibility is especially important for fast mouse interaction and sophisticated graphics output (such as 3D). The NeWS language is object-oriented, with a lightweight process capability, to make the programming easy. Yes, I've heard about the limited compile-time extensibility of X, mainly that it doesn't really work. 2. The NeWS interface to C sucks. The X interface to C is much nicer, with a rich Xlib and Xtk. SunView 2.0 for NeWS has been mentioned on the net, but I haven't seen it yet. 3. I've heard people complain about X's limited usefulness with future, advanced hardware, while NeWS should be easily extended. I'm not really familiar with this issue, but would appreciate other people's comments. Thanks. Ken
mday@cgl.ucsf.edu (Mark Day) (02/09/88)
In article <828@daisy.UUCP> klee@daisy.UUCP (Ken Lee) writes: >2. The NeWS interface to C sucks. The X interface to C is much nicer, >with a rich Xlib and Xtk. SunView 2.0 for NeWS has been mentioned on >the net, but I haven't seen it yet. At the recent Sun User's Group meeting, Sun claimed that all Beta testing was done, and the new version of NeWs would ship in mid-January. Does anyone at Sun, or any of the beta test sites have a revised estimate for its ship date? ---------- Mark Day UUCP: ..ucbvax!ucsfcgl!mday ARPA: mday@cgl.ucsf.edu BITNET: mday@ucsfcgl.BITNET
montnaro@sprite.uucp (Skip Montanaro) (02/09/88)
In article <10683@cgl.ucsf.EDU> mday@socrates.ucsf.edu.UUCP (Mark Day) writes: >At the recent Sun User's Group meeting, Sun claimed that all Beta testing >was done, and the new version of NeWs would ship in mid-January. Does >anyone at Sun, or any of the beta test sites have a revised estimate for >its ship date? Funny, Sun never told us that the beta test was over. (We beta tested both 1.0 and 1.1.) Of course, they weren't very good about responding to bug reports either. I finally gave up sending them beta and bug reports. I will admit I could have been more diligient on the beta reports. To answer your original question: No we've received no indication of the NeWS 1.1 ship date, nor have we received a tape. Skip (montanaro@ge-crd.arpa, uunet!steinmetz!sprite!montanaro)
david@elroy.Jpl.Nasa.Gov (David Robinson) (02/10/88)
In article <9469@steinmetz.steinmetz.UUCP>, montnaro@sprite.uucp (Skip Montanaro) writes: > In article <10683@cgl.ucsf.EDU> mday@socrates.ucsf.edu.UUCP (Mark Day) writes: > >At the recent Sun User's Group meeting, Sun claimed that all Beta testing > >was done, and the new version of NeWs would ship in mid-January. Does > >anyone at Sun, or any of the beta test sites have a revised estimate for > >its ship date? > To answer your original question: No we've received no indication of > the NeWS 1.1 ship date, nor have we received a tape. From a press release I have just received by Sun about NeWS, put out at Uniforum: "NeWS release 1.1 is currently shipping and lists for $100 per copy for Sun workstations." -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway!
roy@phri.UUCP (Roy Smith) (02/18/88)
> Of course, it would be a lot easier for people to develop informed > opinions on NeWS if Sun were to freely release the source for the server I don't see why having or not having source should change your mind about how easy or hard it is to write NeWS applications, how well or poorly the documention is written, how buggy the system is, etc. I used to be a hard-core "must have source" person, but I've lately started to come off my high horse about that. Given a choice between buggy source and high quality binaries, I'll take the binaries any day. (And no, I'm not saying that X is buggy.) -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
wesommer@athena.mit.edu (William E. Sommerfeld) (02/18/88)
In article <3146@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >> Of course, it would be a lot easier for people to develop informed >> opinions on NeWS if Sun were to freely release the source for the server >Given a choice between buggy source and high >quality binaries, I'll take the binaries any day. (And no, I'm not saying >that X is buggy.) Given the choice between buggy binary distributions and doing without, I'll do without. In our environment at Athena[0], we'd rather have buggy source than "perfect" binaries because we can probably fix things we have source for if they become a problem. There's _no such thing_ as a nontrivial bug-free program. (TeX comes close, but very few companies are as good at quality control as Donald Knuth). If we have the source we can at least understand the real nature of the bug (rather than making guesses based on its erroneous behavior, which are typically completely wrong), have a better idea of how to make it reproducible, and also probably be able to fix it. [1] When you consider how hard it is to coordinate binary distributions to two completely different systems (MicroVAX and IBM RT), this is a real problem. We are under a large amount of pressure from our donors (DEC and IBM) to make the environment on both classes of workstations identical. Binary-only distributions and highly restrictive non-disclosure agreements on sources only get in the way of this. By the way, after reading parts of the NFS source, I feel real sorry for those of you out there who run binary-only Sun sites.. I was tempted to include a hex dump of a few "interesting" packets that will crash your average Sun RPC based service, but discretion prevailed. I used to think that binary-only distributions were sort of OK, but my work here has convinced me that it's not worth my time to have to fight with software that I don't have the source for. - Bill [0] ~700 workstations and growing: 1/2 DEC MicroVAXes running 4.3BSD+NFS, 1/2 IBM RT's running 4.3BSD+NFS, being managed by a crew of less than 100 people, of which at most 10-20 could really be considered "wizards". [1] If we at least have a symbol table, we can disassemble parts of the binary and at least have an idea as to what is going on (for example, when we discovered that the date conversion routine of a certain database system[2] goes into an infinite loop on the first of the year only _after_ we built our service management database using it..), but that's rather painful to do in the general case. [2] Well, since you asked, RTI Ingres version 5.