ajayshah@aludra.usc.edu (Ajay Shah) (09/04/90)
Bill Joy
Dennis Ritchie
Steven Jobs
some of the people I respect the best in the whole wide
world; all think X is brain-dead. Do you have any ideas on
why? Did the wide acceptance of X have a lot to do with
the urgent need to kill NeWS quickly on the part of
DEC/HP/IBM (basically, did X rise to prominence for
political rather than technical reasons)?
Who're the people who did X anyway? I never heard any names
apart from the keyword 'MIT'.
--
_______________________________________________________________________________
Ajay Shah, (213)747-9991, ajayshah@usc.edu
The more things change, the more they stay insane.
_______________________________________________________________________________mouse@LARRY.MCRCIM.MCGILL.EDU (09/04/90)
> Bill Joy > Dennis Ritchie > Steven Jobs > some of the people I respect the best in the whole wide world; all > think X is brain-dead. Do you have any ideas on why? Yes and no. I don't know why they think what they think, no. But I agree, X has problems. It's just that I've not seen anything better. To paraphrase who was it, Churchill I think, X is the worst window system in the world, except for all the others. > Did the wide acceptance of X have a lot to do with the urgent need to > kill NeWS quickly on the part of DEC/HP/IBM (basically, did X rise to > prominence for political rather than technical reasons)? I don't know. I like to think that in large part it was due to its being freely available to all; that's certainly a big reason we're using it here. > Who're the people who did X anyway? I never heard any names apart > from the keyword 'MIT'. From the LABEL file on the R4 tape, X Window System, Version 11 Release 4 contents copyrighted by Massachusetts Institute of Technology Adobe Systems, Inc. Apollo Computer Inc. Apple Computer, Inc. AT&T, Inc. Don Bennett Bigelow & Holmes Bitstream, Inc. Adam de Boor Cognition Corp. Digital Equipment Corporation Evans & Sutherland Computer Corporation Franz Inc Hewlett-Packard Company IBM Corporation Network Computing Devices, Inc. O'Reilly and Associates, Inc. Dale Schumacher Marvin Solomon Sony Corp. SRI Sun Microsystems, Inc. Tektronix, Inc. Texas Instruments Incorporated UniSoft Systems The Regents of the University of California University of Wisconsin Larry Wall Wyse Technology, Inc. The LABEL.CONTRIB file is much longer and I won't bother including the whole thing here, but it's as widely varied.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
jim@ncd.COM (Jim Fulton) (09/04/90)
Who're the people who did X anyway? I never heard any names apart from the keyword 'MIT'. The introduction to the DP book X Window System: C Library and Protocol Reference by Gettys, Scheifler, and Newman contains a good introduction to the history of and principles behind the design of X.
jimf@SABER.COM (09/04/90)
| some of the people I respect the best in the whole wide | world; all think X is brain-dead. Do you have any ideas on | why? `Brain-dead' wouldn't be my word but some areas of its rendering model are rather naive (although most are better than the Suntools/SunView model). It's worst failing is probably its dependency on the pixel as the base unit. This makes it very difficult to move between monitors of differing aspect ratios or densities (ie not everything is a Sun). Some other portions of its design make it very difficult to write graphics-intensive applications, particularly those applications which deal with shapes as objects with some attributes (the X polygon rendering model describes two different shapes if filled versus unfilled, for instance). Lastly, the window manager concept makes implementation and documentation of complex programs much more difficult than it needs to be. Before ICCCM it was nearly impossible. It is unfortunate that the X designers didn't look more closely at existing environments before implementing X, but even as-is X is a workable system which is improving. The extension mechanism will aid in this process. On the up side, X proved that a networked window system can work pretty well (NeWS failed in that respect although it is a better system), and helped establish an industry standard that was badly needed. When it comes right down to it I'd rather have a naive system that's consistent across most machines than a fantastic one that exists on only one, at least from a marketing point of view. Happy hacking, jim frost saber software jimf@saber.com
jim@ncd.COM (Jim Fulton) (09/04/90)
Jim Fulton says that X's worst failing is probably its dependency on the
pixel as the base unit.
Nope, that was someone else. I mentioned the introduction to Jim, Bob, and
Ron's book.gjc@mitech.com (09/05/90)
In article <11813@chaph.usc.edu>, ajayshah@aludra.usc.edu (Ajay Shah) writes: > some of the people I respect the best in the whole wide > world; all think X is brain-dead. Do you have any ideas on > why? > Bill Joy crashme 100 10 200 (see comp.lang.c in sun os 4.0.3 *or* 4.1) > Dennis Ritchie Quite possibly the 'MIT' keyword is the main problem here. X: Sun of Multics? > Steven Jobs Quite possibly a confusion of underlying system structure issues with issues of user interface and applications generation tools. Maybe somebody should ask him if he saw to it that the MAC O/S made the same 24-bit address fiasco that the IBM 360 did, in order that NeXT or others might have a fighting chance. -gjc
kent@gilroy.pa.dec.com (Christopher A. Kent) (09/05/90)
Don't overlook the fact that two of the three people mentioned (Jobs and Joy) have or had a commercial interest in seeing X fail. Jim Fulton says that X's worst failing is probably its dependency on the pixel as the base unit. I'd be tempted to agree, and this is one of the reasons we've worked so hard on the Display PostScript extension. Not only does it remove the need for client programs to worry about pixel densities, it also allows client programs not to worry about what strange variant of color hardware exists on the server. Chris Kent Western Software Laboratory Digital Equipment Corporation kent@decwrl.dec.com decwrl!kent (415) 853-6639
jg@crl.dec.com (Jim Gettys) (09/05/90)
And the third (Dennis Richie) watched AT+T take so long with the BLIT that the great advance over the state of the art elsewhere it represented was lost, and never went anywhere. Sigh... To give you an idea of where things were, the BLIT was roughly equivalent to an X terminal in many respects (but not in others, as it did not provide network transparent access to applications on other machines) and was working several years before we started working on X. Of course, some of us believe that at today's and tomorrow's screen resolutions every pixel is critical. PostScript does great at 300 DPI; unfortunately, most screens are between 75 DPI and 100 DPI. I'd love it had screens been high enough resolution to take that point of view, but reality is somewhat otherwise, unfortunately. And bandwidth (more or less directly related to cost) goes as the square of the resolution. PostScript by itself is insufficient for many imaging and CAD applications on even the fastest of today's hardware, something I (who used to get paid to write image processing software) am quite sensitive to. - Jim
frose@synoptics.COM (Flavio Rose) (09/05/90)
This message is empty.
raveling@unify.com (Paul Raveling) (09/05/90)
In article <1990Sep4.202433.19653@wrl.dec.com>, kent@gilroy.pa.dec.com (Christopher A. Kent) writes: > > Jim Fulton says that X's worst failing is probably its dependency on the > pixel as the base unit. I'd be tempted to agree, ... For a different perspective, my view of X's biggest problem is its complexity, most of which follows from the basic design goal of making it policy-free. I believe the ideal window system would use a fair bit more encapsulation of policy to keep the client interfaces clean, while still providing adequate handles to override important aspects of default policy. A particular stumbling block is implementing policy through a separate window manager process, which adds some heavy burdens in communication and synchronization among client processes, the display server, and the window manager. I think a better way to do this is to make policy arbitration a central module within the main display server process, more like a ddx component than a client program. ------------------ Paul Raveling Raveling@unify.com
gjc@mitech.com (09/05/90)
In article <1990Sep4.203701.18657@crl.dec.com>, jg@crl.dec.com (Jim Gettys) writes: > ... To give you an idea of where > things were, the BLIT was roughly equivalent to an X terminal in many respects > (but not in others, as it did not provide network transparent access to > applications on other machines) and was working several years before we > started working on X. Was that before or after the availability of the BBN BITGRAPH? I had a BBN bitgraph at the MIT AI LAB around 1982, and was working on a LISP interface (from VAX-NIL). At the time LISP people at MIT were generally convinced that a graphics/window environment HAD to be in a VIRTUAL-MEMORY-MAPPED graphics buffer (like the Lispmachine). Some other LCS VAX hold-outs were putting their money/time into the VS-100 unibus/fiber-optic thing, but I figured that at 19.2KB using clever encodings a serial-line graphics terminal could do quite well keeping up with anything a VAX-750 could possibly throw at it. Quite possibly the BBN BITGRAPH was more primitive than the BLIT in its base software. The thing did support downloadable C code (68xxx using the circa-1981 MIT Chris-Terman C compiler no doubt) but for some reason MIT could never get BBN to *license* them the development system. (Maybe because BBN was at the same time selling it to the US government for megabucks). Typical story. -gjc
guy@auspex.auspex.com (Guy Harris) (09/06/90)
>> Bill Joy >crashme 100 10 200 >(see comp.lang.c in sun os 4.0.3 *or* 4.1) What does that have to do with anything? There are a number of machines (both RISC and CISC) that said program crashes; its existence hardly serves as any sort of useful response to any of Bill Joy's anti-X statements. >> Dennis Ritchie >Quite possibly the 'MIT' keyword is the main problem here. >X: Sun of Multics? Excuse me? One might as well wonder whether Dennis Ritchie is opposed to putting cows on the roofs of buildings, as that was an MIT project as well. (Not an *official* project, but....)
kent@wsl.dec.com (Christopher A. Kent) (09/06/90)
The BBN Bitgraph and BLIT are approximate contemporaries. In fact, the folks at Bell Labs got their BLIT code running on the Bitgraph, even though they grumbled a lot because the "bits went the wong way". Bitgraphs were fun. BBN developed a little window system for them, (though I don't think it ever made it out of the company), and a few places went pretty nuts with them. I still remember fondly the Spacee Invaders and PacMan games we had that ran completely in the terminal, complete with accurate sound effects... -- Chris Kent Western Software Laboratory Digital Equipment Corporation kent@decwrl.dec.com decwrl!kent (415) 853-6639
wds@uarthur.UUCP (William D. Sheppard) (09/06/90)
I have a question for thos who dislike X: What have they developed thats better!!!!!!!!!!!!! I have to agree that X windows is not a perfect piece of software engineering, but its the best we currently have available that will work on almost any hardware. It is always much easier to be a critic than it is to produce something thats better. My hat is off to those at MIT that have produced a usable window environment! It may not be perfect, but can you claim that the code that you write is? Bill Sheppard Consultant World Bank, Washington DC
moraes@cs.toronto.edu (Mark Moraes) (09/07/90)
wds@uarthur.UUCP (William D. Sheppard) writes: >I have a question for thos who dislike X: > What have they developed thats better!!!!!!!!!!!!! Um, in this case, each of the three would claim their window system was "better". More specifically, 1. Do you have an alternative window system? 2. What do I have to do to get a working set of binaries for my system? 3. What hardware will I need to run it on? 3a. How easy would it be for me to port it to my nonstandard machine? 4. Does it support colour properly? 4a. Does it have a functional terminal emulator (emulating some popular or standard terminal) with cut and paste? 4b. Is it possible to write programs that are portable across different architectures, especially architectures with different byte/bit order? 5. What sort of support can I get and how much does it cost? The answers to these questions often determine the fate of a window system far more than its "pure technical" merits. Having it not crash you is probably a desirable feature. Mark. PS: People might observe that some of these questions could be asked about a lot of software, not just window systems.
jcb@frisbee.Sun.COM (Jim Becker) (09/07/90)
raveling@unify.com (Paul Raveling) writes: In article <1990Sep4.202433.19653@wrl.dec.com>, kent@gilroy.pa.dec.com (Christopher A. Kent) writes: > > Jim Fulton says that X's worst failing is probably its dependency on the ^^^^^^^^^^ Jim Frost of Saber. > pixel as the base unit. I'd be tempted to agree, ... For a different perspective, my view of X's biggest problem is its complexity, most of which follows from the basic design goal of making it policy-free. I believe the ideal window system would use a fair bit more encapsulation of policy to keep the client interfaces clean, while still providing adequate handles to override important aspects of default policy. I strongly agree. This is where the direction of X after the creation of the Xlib layer appears, IMHO, to have gone astray. Instead of encapsulation of functionality, and introduction of solutions from the top down to the bottom, the Xt based stream of additional complexity was intertwined with that defined by Xlib to further multiply the base knowledgeset necessary to utilize the X Window System. In simple english, instead of making it easier to approach from a high level viewpoint, we now have more dribbling lowlevel functionality in the Xt Intrinsics and toolkit land before getting a real interface put together. The complexity of Xlib itself isn't really difficult, although there could be simple improvements (IMHO). Where things broke down is not taking a higher view of the interface creation process and building systems which generate and manage the interface at a meta level. The addition of Xt seems like adding macros to assembly, metaphorically, rather than building high level structured languages and interface generators. Building from this base simply has created a really tough learning curve, compared to providing systems at the level of HyperTalk and 4GLs. There is simply too much the application programmer has to understand to get to first base. This level of detail should be handled by the `User Interface System' as a whole, with little application programmatic overhead. Considering we have some of the brightest minds out there making these strategic decisions, I'm really surprised this is the current situation. A particular stumbling block is implementing policy through a separate window manager process, which adds some heavy burdens in communication and synchronization among client processes, the display server, and the window manager. I think a better way to do this is to make policy arbitration a central module within the main display server process, more like a ddx component than a client program. I strongly agree. What is needed is a higher level User Interface System/Server than handles everything. The separate window manager, and the `each application uses it's version of a toolkit' strategy, makes things a lot tougher in terms of user environment consistency and interaction. With a central server mechanism, issues currently handled inconsistently by the toolkits and window manager would become moot points. Additionally Internationalization would be consistent and easier, as well as user defaults and color management. To me it isn't any surprise that the existing systems in use by large numbers of end users are the Mac and Windows 3.0. Although I don't program either, both systems seem to have higher level interactions between the user and the applications in manner of environment. X is dealing at granular levels, fighting upward. The solutions out there for the masses give the end user a top-down approach, and therefore a more warm fuzzy feeling of security. They are consistent in appearance, and plug/play correctly. And are easy to setup and modify. It would be nice if that was more the norm in the X world. There is no reason that X could have not gone on this path in the past. [In fact I have developed a system with this philosophy on X.] However, with the combination of the current standards process and legal concerns (LAF), there are ramifications on pure originality and creativity for other potential solutions. It seems there is little room to break from the current defined alternatives, and the community has to work within them. Hopefully there will be lessons learned from the premature introduction of standards in the creative process. And hopefully the end result of ongoing legal battles in the computer world will not function to extinguish the innovative flame that has been kept alight by bright ideas and hard work. Hopefully. (it didn't look like a soapbox when I got on!) ------------------ Paul Raveling Raveling@unify.com -Jim Becker [Obviously my own opinions, not those of Sun Microsystems.] -- Jim Becker / jcb%frisbee@sun.com / Sun Microsystems
seg@barney.mitre.org (Scott E. Gordon) (09/07/90)
As someone who is going to be moving to an 'X' environment for reasons of image processing, I am *really* worried about the imaging functions in X. I have heard very bad things about these functions. Well, actually, I just heard that they were really bad, but was not really told the reasons. Can anyone expound on their experiences? Also, there is a question (keeping in mind we know very little about X right now) about whether software written in X will work for any X peripheral. If we have 2 different display boards for example, do we have to have 2 different versions of the software, or do the boards deal with the imaging calls and (hopefully) are transparent to the user? Thanx for your support -- Scott E. Gordon INTERNET : seg@hoppi.mitre.org MITRE Image Processing Research Laboratory USENET : linus!hoppi!seg Burlington Rd. Bedford, Ma. 01730 (617) 271-7338
fgreco@govt.shearson.COM (Frank Greco) (09/08/90)
>I have a question for thos who dislike X: > > What have they developed thats better!!!!!!!!!!!!! > >I have to agree that X windows is not a perfect piece of software engineering, but its the >best we currently have available that will work on almost any hardware. It is always >much easier to be a critic than it is to produce something thats better. > >My hat is off to those at MIT that have produced a usable window environment! It may not >be perfect, but can you claim that the code that you write is? Bill, The guys at MIT are doing a fantastic, if not unbelievable, job with X. No one, I believe, is criticizing their efforts. I think people are criticizing the X design philosophy, which anyone is entitled to do. ...heck, criticism happens every microsecond in every newsgroup on the net! ;-> As far as "better" (he says with a sly objective look on his face), have you looked at NeWS? Its available on almost as many platforms as X and is much more programmable (the server, that is) than X, and can inherently handle Postscript (ie., its *not* an extension). I might also add that one of Dennis Ritchie's colleagues, Rob Pike, who also dislikes X Window, (I'm paraphrasing here, but Rob was quoted as saying X was baroque and overly complicated) has invented some fundamental graphics algorithms that are used in practically all modern window systems and has developed several interesting window systems within AT&T Bell Labs. Please...I'm not trying to start window flames, but aren't we science folk supposed to question and criticize and opinionize? That's the nature of research. Frank G.
razdan@phx.mcd.mot.com (anshuman razdan) (09/08/90)
In article <119376@linus.mitre.org> seg@barney.mitre.org (Scott E. Gordon) writes:
Also, there is a question (keeping in mind we know very little
about X right now) about whether software written in X will
work for any X peripheral. If we have 2 different display
boards for example, do we have to have 2 different versions
of the software, or do the boards deal with the imaging calls and
(hopefully) are transparent to the user?
Not qualified to answer your first question.
As for the second question. If the display boards( I think what
you mean as in two X display servers) are "true" i.e. confirm to the
X11RZ (Z= 3 or 4) protocol the software should not have any
problem displaying. I recommend X Protocol Reference
Manual for version 11 by Robert W. Scheifler (O'Reilly and Assoc)
to resolve doubts. I am not sure if I answered your question.
--
Anshuman Razdan
************************************************************
* razdan@toy Test and Methodology Group *
* *
* razdan@phx.mcd.mot.com Diablo Plant, Tempe Az *
************************************************************cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (09/08/90)
Scott Gordon writes: > As someone who is going to be moving to an 'X' environment > for reasons of image processing, I am *really* worried about > the imaging functions in X. I have heard very bad things about > these functions. Well, actually, I just heard that they were > really bad, but was not really told the reasons. Can anyone > expound on their experiences? When people talk about X lacking an "imaging model" they seem to be referring to the fact that the Xlib primitives are pixel based and not based on some display independent coordinate system. I would rate this as building mountains over molehills: if you want to draw in centimeters or inches you can add another layer on top of Xlib (the necessary information -- the pixel spacing in real coordinates -- is easily available). Of course, for an image processing application pixel access is probably exactly what you need. Xlib has a rich set of primitives for drawing and image display. Its main disadvantages for image processing are that you have to pan and zoom in software if this is required. > Also, there is a question (keeping in mind we know very little > about X right now) about whether software written in X will > work for any X peripheral. If we have 2 different display > boards for example, do we have to have 2 different versions > of the software, or do the boards deal with the imaging calls and > (hopefully) are transparent to the user? You only need a different version of the X server for each board. X applications talk to the server using the X protocol and the server translates their requests into the imaging calls suitable (and hopefully optimised) for the board in question. However, if you have a wide variety of displays you might have to have alternate code branches for different display types since devices with 24-bit "true colour" displays may need to be treated differently from 8-bit pseudocolour displays if you are displaying images (there are other distinctions between display types but this is the most painful). Take a look at Adrian Nye's "Xlib Programming Manual" (Vol. 1 in O'Reilly's X Window System series). Chris Flatters
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (09/09/90)
>> A particular stumbling block is implementing policy through a >> separate window manager process, which adds some heavy burdens in >> communication and synchronization among client processes, the >> display server, and the window manager. I think a better way to do >> this is to make policy arbitration a central module within the main >> display server process, more like a ddx component than a client >> program. > I strongly agree. What is needed is a higher level User Interface > System/Server than handles everything. The major problem with this is lack of configurability. I certainly wouldn't be using X right now if it mandated someone else's idea of a nice interface by building the window manager into the server, as you seem to be advocating. (I have never, ever, seen a UI policy ("window manager") I could stand to use for long, except for ones I've implemented myself. I daresay this extreme a reaction is rare, but there are doubtless plenty of people who are happy with none of the available UI styles but find them tolerable and merely grumble.) > To me it isn't any surprise that the existing systems in use by large > numbers of end users are the Mac and Windows 3.0. [...] The > solutions out there for the masses give the end user a top-down > approach, and therefore a more warm fuzzy feeling of security. What do you want X to be? Would you rather it be popular, or useful? (Okay, so that's a loaded question. :-) If you prefer, think of X as a framework for building window systems (with none currently built). It would not be infeasible to build an interface with a Macish L&F on X; certain setups of twm I've seen in use come close already. The real advantage of X is that *the user isn't locked in* to the Finder, or PM, or whatever style of interaction happened to be all the rage that week. > They are consistent in appearance, and plug/play correctly. This is not impossible under X. If you restrict yourself to Motif clients, they will all be consistent and will interoperate nicely; likewise if you stick to OL[%]. The problems start when you try to mix-and-match; the reason this isn't seen in the Mac world (for example) is that it's *impossible* to mix-and-match there. [%] I assume. I have used neither Motif nor OL enough to know whether this is actually true. But if it's not, they're certainly being overblown on the net. > And are easy to setup and modify. Ha hahaha! My first reaction when I saw a Mac screen was "how do I get it out of reverse video?". As far as I can tell, even that fundamental configuration is impossible. (Or rather, it is impossible with the Apple-supplied tools. Having seen Stepping Out, it is obvious it would be possible to do. But I have never even heard of its being done, and feel quite certain it is not supported, and likely even would require using undocumented interfaces.) My second request would be to get rid of the title bars. Right, that's not easy either. Run that by me again about how it's easy to set up and modify? (Windows 3.0, whatever that is, I have had no experience with, except perhaps seeing it in use once without knowing what I was looking at.) > It would be nice if that was more the norm in the X world. Under X, on the other hand, getting things out of reverse video verges on the trivial[$]. Getting rid of the title bars involved a few days' programming, with a set of tools[#] that's reasonably well documented. [$] mit/clients/bitmap is an exception; that's part of the reason I never use it. Fortunately such clients are almost universally considered defective. [#] I'd say `toolkit', but when discussing X, that's a technical term whose meaning does not apply here. > There is no reason that X could have not gone on this path in the > past. [In fact I have developed a system with this philosophy on X.] You said it yourself. As I said above, if "window system" implies a mandated consistent L&F, then X is a framework for building window systems. Tools not rules - and if you want to implement rules, be our guest. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
meissner@osf.org (Michael Meissner) (09/10/90)
In article <9009071813.AA04208@islanders.> fgreco@govt.shearson.COM (Frank Greco) writes: | Bill, | The guys at MIT are doing a fantastic, if not unbelievable, job with X. | No one, I believe, is criticizing their efforts. I think people are | criticizing the X design philosophy, which anyone is entitled to do. | ...heck, criticism happens every microsecond in every newsgroup on the net! ;-> | | As far as "better" (he says with a sly objective look on his face), | have you looked at NeWS? Its available on almost as many | platforms as X and is much more programmable (the server, that is) than X, | and can inherently handle Postscript (ie., its *not* an extension). As a user I looked at NeWS 1.1 (I think that was the revision), running on a sun3/50. Within a week I was no longer running it. The terminal emulators were the big reason why I dropped NeWS. I couldn't get adequate performance out of the terminal emulators, and they seemed buggy as all get out. Since I primarily do text type things (such as compiler support), it didn't matter one whit whether it was easier to do complex graphics with the system -- if it doesn't do the basic tasks, it is useless as a window system. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
meissner@osf.org (Michael Meissner) (09/10/90)
In article <9009071813.AA04208@islanderc.> fgreco@govt.shearson.COM (Frank Greco) writes: | Bill, | The guys at MIT are doing a fantastic, if not unbelievable, job with X. | No one, I believe, is cbiticizing their efforts. I think people are | criticizing the X design philosophy, which anyone is entitled to do. | ...heck, criticism happens every microsecond in every newsgroup on the net! ;-> | | As far as "better" (he says with a sly objective look on his face), | have you looked at NeWS? Its available on almost as many | platforms as X and is much more programmable (the server, that is) than X, | and can inherently handle Postscript (ie., its *not* an extension). As a user I looked at NeGS 1.1 (I think that was the revision), running on a sun3/50. Within a week I was no longer running it. The terminal emulators were the big reason why I dropped NeWS. I couldn't get adequate performance out of the terminal emulators, and they seemed buggy as all get out. Since I primarily do text type things (such as compiler support), it didn't matter one whit whether it was easier to do complex graphics with the system -- if it doesn't do the basic tasks, it is useless as a window system. -- Michael Meissner email: meissner@osf.org `hone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
fgreco@govt.shearson.COM (Frank Greco) (09/11/90)
>As a user I looked at NeWS 1.1 (I think that was the revision), >running on a sun3/50. Within a week I was no longer running it. The ^^^^^^^ >terminal emulators were the big reason why I dropped NeWS. I couldn't >get adequate performance out of the terminal emulators, and they >seemed buggy as all get out. Since I primarily do text type things >(such as compiler support), it didn't matter one whit whether it was >easier to do complex graphics with the system -- if it doesn't do the >basic tasks, it is useless as a window system. >-- >Michael Meissner email: meissner@osf.org phone: 617-621-8861 >Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Michael, I wouldn't expect much gas out of 3/50. Gees, its only a 2 MIP machine, going downhill with the wind at its back. The first few (alpha, beta and FCS) versions of NeWS did not include a very good terminal emulator. It was a long time problem getting Sun to produce a usable terminal emulator (psterm, the Postscript terminal emulator written by Steve Isaacs, was never intended to be production quality. I'm not making excuses for Sun, but either a decent terminal emulator should have been written, or Sun should have released psterm under a "UnderConstruction" directory). There are several decent ones in the public domain that you could scarf up on the net (or from the latest Sun User Group tape). OW 2.0 does include a new and improved psterm, but more importantly, you could use good 'ole xterm, since OW 2.0 uses a merged X and NeWS server. This is what I do. Frank G. fgreco@shearson.com ...my opinions are mine, of course...
chuck@trantor.harris-atd.com (Chuck Musciano) (09/11/90)
I know that many people are initially discouraged from using X by the massive learning curve hit you take trying to use it. I would love to see cleaner interfaces to low level functions to make X easier to understand for neophytes. I understand the creeping featurism that evolves in a system whose motto is X: Tools, not Rules Therefore, might I suggest a better one? To whit: X: Confusion, not Collusion -- 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) 729-2537 A good newspaper is never good enough, but a lousy newspaper is a joy forever. -- Garrison Keillor
mouse@LARRY.MCRCIM.MCGILL.EDU (09/11/90)
> As someone who is going to be moving to an 'X' environment for > reasons of image processing, I am *really* worried about the imaging > functions in X. I have heard very bad things about these functions. > Well, actually, I just heard that they were really bad, but was not > really told the reasons. Can anyone expound on their experiences? I find them reasonable. Whether you will or not depends on what you expect of them. The X support is primarily for displaying images; there is nothing, really, for image processing or anything of the sort. (Even the display functions are not terribly well documented, something I hope will be remedied...I'll drop a note to xbugs.) > Also, there is a question (keeping in mind we know very little about > X right now) about whether software written in X will work for any X > peripheral. If we have 2 different display boards for example, do we > have to have 2 different versions of the software, or do the boards > deal with the imaging calls and (hopefully) are transparent to the > user? Yes and no. There are three levels here: the client (application) program, the X server, and the hardware. The server usually needs to be different for different hardware, but the clients (except in very special and unusual circumstances) need no work when moving from one hardware-plus-server combination to another. (Given that the client was written with at least minimal attention given to portability. Assuming a 256-entry PseudoColor visual, to pick one plausible example, is the sort of thing that might be done by an author who's not being careful.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
tmb@ai.mit.edu (Thomas M. Breuel) (09/12/90)
In article <119376@linus.mitre.org>, seg@barney.mitre.org (Scott E. Gordon) writes: |> As someone who is going to be moving to an 'X' environment |> for reasons of image processing, I am *really* worried about |> the imaging functions in X. I have heard very bad things about |> these functions. Well, actually, I just heard that they were |> really bad, but was not really told the reasons. Can anyone |> expound on their experiences? I'm not sure what you mean by "imaging functions". X lets you put up arbitrary sets of pixels on your display, and gives you access to colormaps, etc. Unless you use the memory-map extensions, there is a non-negligible overhead associated with such operations, but even performance over an ethernet is good enough for most applications. Finally, X also has extensions for doing animation via multibuffering. |> Also, there is a question (keeping in mind we know very little |> about X right now) about whether software written in X will |> work for any X peripheral. If we have 2 different display |> boards for example, do we have to have 2 different versions |> of the software, or do the boards deal with the imaging calls and |> (hopefully) are transparent to the user? X windows classifies display types according to "visuals" (e.g., B/W, static color, pseudo color (CLUT)). Depending on your application, you may have to write code for different visual types, but this is inherent in the nature of the differences between the displays. X, in fact, probably does the best job among all windowing systems of letting you take advantage of most of the capabilities of your display hardware in a portable manner.
tmb@ai.mit.edu (Thomas M. Breuel) (09/12/90)
In article <!19376@linus.mitre.org>, seg@barney.mitre.org (Ccott E. Gordon) writes: |> As someone who is go)ng to be moving to an 'X' envib/nment |> for reasons of image `rocessing, I am *really* worried about |> the imaging functionc in X. I have heard very bad t(ings about |> these functions. Well, actually, I just heard dhat they were |> really bad, bet was not really told the reasons. Can anyone |> expound on th%ir experiences? I'm not sure what you mean by "imaging funcd)ons". X lets you put up arbitrary sets of pixels on your display, and gives you access to colob-aps, etc. Unlecs you use the memory-map extensions, there is a .on-negligible overhead associated with such operations, but even performance over an ethernet is good enough for most applications. Finally, X also has extensions for doing animation via muldibuffering. |> Also, there is a question (kee`ing in mind we know very little |> about X right now) about whether software written in X will |> work for ani X peripheral. If we have 2 dif&erent display |> boards for ehample, do we have to have 2 diff%rent versions |> of the software, or do the boards deal with dhe imaging calls and |> (hopefelly) are transparent to the useb/ X windows classifies displai types according to "visuals" (e.g., B/W, static color, pseudo color (CLUT)). Depending on your !pplication, you may have to write code for different visual types, but this is inherent in the nature of the differences between the displays. X, in fact, prob!bly does the best job among all windowing systems of letting yoe take advantage of most of the capabilities of your display habdware in a portable manner.