jik@athena.mit.edu (Jonathan I. Kamens) (10/31/90)
(Note the Followup-To.) In article <P5S6=T1@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: |> Even if it's at the other end of a 2400 baud SLIP link from the display |> server? If you're running over a SLIP line, then you put "*backingStore: true" and "*saveUnder: true" in your .Xresources file, and good clients will automatically request backing-store and save-under on all windows as a result of this, and good X servers will grant them. Note that X was not designed so that the X server *can't* store state. It was designed so that the X server *might* be able to serve state, and so that clients can tell it whether or not this is an important requirement for them. As far as I know, all of the sample servers that come from MIT for X11R4 can do backing-store and save-under, unless they're disabled explicitly when the X server starts up. Whether or not vendor X servers support backing-store and save-under is the problem of the vendors. |> It consumes just as much memory either way, Hogwash. If the server is storing the contents of a window, it has to store a pixmap of the entire window. For a monochrome display, that's 1bitXwidthXheight, for a color, might be up to 32bitsXwidthXheight. On the other hand, very few X clients do refreshing by storing a complete pixmap of the window. Xterm, for example, only needs to store the characters it needs to draw, i.e. 8bitsXcharacter-widthXcharacter-height. Most graphics programs only store the attributes of the shapes that have been drawn, so that they can be redrawn when a refresh events come in. Unless an application stores a full pixmap, the memory required for an application to store window state is far less than the memory required for the server to store window state. |> and it requires the client |> be able to respond in real-time... something that's just plain not |> possible in UNIX. It requires the clients to be able to respond in a reasonable amount of time. Funny, I never noticed any problem with X just because the clients can't "respond in real-time", and I work under it almost exclusively, without backing-store and save-under on my windows. |> It makes as much sense to have "xman" handle update |> events as it does to have "cat" do erase and kill processing. Fiddlesticks. It's more efficient memory-wise, and where other problems make it less efficient (e.g. the 2400 baud SLIP you mentioned above), it's possible to get the server to do it. So you win either way. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
tjo@its.bt.co.uk (Tim Oldham) (10/31/90)
CS 101: Network Window Systems 1) The X Window System and GUIs built on X are expensive in terms of CPU, memory and network resources. Discuss. You should compare the X philosophy with competing network windowing philosophies such as those based on PostScript. I'd be extremely interested in hearing peoples' views on this. I personally think that X is seen as far too much as a panacea for Unix HCI, and it worries me that X has been seized upon as a ``standard'' with little thought for the implications in terms of hardware and networking costs. The fact that I hear people from Sun tell me ``Our implementation of Open Look is great --- but you need 16 Meg in your SPARCstation'' alarms me. The fact that a 68030 isn't enough CPU for a single user of an X GUI under V.4 alarms me. The fact that X applications potentially generate significant numbers of packets and eat up CPU cycles even when there's no user interaction alarms me (ever watched a LANalyser when xeyes is running?). Applications controlling such dumb things as rubber-banding alarms me. I'm no Xpert, but has the industry got it wrong? Tim. -- Tim Oldham, BT Applied Systems. tjo@its.bt.co.uk or ...uunet!ukc!its!tjo Living in interesting times.
mouse@LIGHTNING.MCRCIM.MCGILL.EDU (10/31/90)
> (Note the Followup-To.) Eh? The headers on your message as I see it include only From Received: Date: From: Organization: Subject: Message-Id: References: Sender: To: Status: >> It consumes just as much memory either way, > Hogwash. If the server is storing the contents of a window, it has > to store a pixmap of the entire window. For a monochrome display, > that's 1bitXwidthXheight, for a color, might be up to > 32bitsXwidthXheight. No. It *may* store a pixmap of the entire window. It also may choose to compress it; for an xterm window, sufficiently smart compression schemes need store only a handful of bits per character cell (typically about 9 or 10 bits - there's more than just the character code to store). (Not that I necessarily expect X servers to include compression schemes that smart. But if we're being pedantic....) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
peter@ficc.ferranti.com (Peter da Silva) (11/01/90)
In article <1990Oct31.014133.14048@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > Funny, I never noticed any problem with X just because the clients > can't "respond in real-time", and I work under it almost exclusively, without > backing-store and save-under on my windows. What sort of hardware are you using? No fair throwing CPU power at the problem to hide it. If you need a 6.0 MIPS machine to get the sort of response I can get from a 0.6 MIPS machine say so. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (11/01/90)
> 1) The X Window System and GUIs built on X are expensive in terms of CPU, > memory and network resources. Discuss. You should compare the X philosophy > with competing network windowing philosophies such as those based on > PostScript. Taking NeWS as an example of a PostScript based window system: X11 is not significantly more expensive than NeWS as far a CPU is related. However the load may be distributed rather differently: some computations that are done on the client side (eg. user coordinate/screen coordinate transformations) may be done on the server side. Note that this implies that a NeWS terminal, should such a beast exist, would have to be more powerful than an equivalent X terminal. NeWS has a reputation as a memory hog. The X11/NeWS server that comes with OpenWindows 2.0 is much less piggy than the previous version when running NeWS clients but NeWS clients probably do not require markedly less memory (on either side of the client-server link) than X11 clients and may require more (I'm not sure how to measure this). The only area mentioned above where NeWS wins over X is in the interprocess communications overhead: since clients download PostScript code to the server no client-server transfers are necessary to repair windows after expose events. I also believe that NeWS is rather better at handling exceptions (eg. servers running out of memory) than X, but there is no fundamental reason why X should not improve in this regard in future releases. Working against NeWS (and presumably Display PostScript) is the fact that they impose the PostScript imaging model on their clients, which may not be appropriate for some applications. X11 uses a very low-level raster graphics model which may act as the foundation for any of a number of higher level models (including PostScript --- see GhostScript as an example). Furthermore, I suspect that many programmers are not comfortable with the though of writing PostScript code; certainly the idea of maintaining a few hundred lines of someone elses PostScript code would give *me* night- mares. > I'm no Xpert, but has the industry got it wrong? I don't think so. If it did it only got things slightly wrong. From what I've seen so far it is quite possible to merge X and PostScript based systems to get the best of both worlds. > The fact that I hear people from Sun tell me ``Our implementation of > Open Look is great --- but you need 16 Meg in your SPARCstation'' alarms > me. This just ain't so. I'm running OpenWindows 2.0 on a SPARCstation 1 with only 8 Mbytes of memory and, as long as I don't start doing silly things like grabbing hold of huge globs of shared memory, it hums along very nicely thank you (not that that stopped me from asking for more memory). Now OpenWindows 1.0.1 really dragged. That turns out to have been due to the window manager being written in PostScript and, consequently, being a real memory pig (I rest my case). Chris Flatters Postscript (not the trademarked kind): > The fact that X applications potentially generate significant numbers > of packets and eat up CPU cycles even when there's no user interaction > alarms me (ever watched a LANalyser when xeyes is running?). Xeyes is continually polling the server to find out where the pointer is. This sort of thing is not normally necessary in an X application. The only serious application I can think of that does anything like this is xclipboard which appears to continuously poll the server to get the current value of the CLIPBOARD selection.
keith@EXPO.LCS.MIT.EDU (Keith Packard) (11/01/90)
> The only serious application I can think of that does anything like this is > xclipboard which appears to continuously poll the server to get the current > value of the CLIPBOARD selection. If it does so, it is broken. The X protocol provides plenty of mechanism for eliminating almost all forms of polling; the selection mechanism which xclipboard uses is one such example.
cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (11/01/90)
>> The only serious application I can think of that does anything like this is >> xclipboard which appears to continuously poll the server to get the current >> value of the CLIPBOARD selection. > >If it does so, it is broken. The X protocol provides plenty of mechanism for >eliminating almost all forms of polling; the selection mechanism which >xclipboard uses is one such example. Sorry. I goofed. For some reason I had the (faulty) idea that xclipboard consumed any spare CPU time left lying around. Chris
don@zardoz.coral.COM (Don Dewar) (11/01/90)
) CS 101: Network Window Systems ) ) 1) The X Window System and GUIs built on X are expensive in terms of CPU, ) memory and network resources. Discuss. You should compare the X philosophy ) with competing network windowing philosophies such as those based on ) PostScript. ) ) I'd be extremely interested in hearing peoples' views on this. I personally ) think that X is seen as far too much as a panacea for Unix HCI, and it ) worries me that X has been seized upon as a ``standard'' with little ) thought for the implications in terms of hardware and networking costs. ) The fact that I hear people from Sun tell me ``Our implementation of ) Open Look is great --- but you need 16 Meg in your SPARCstation'' alarms ) me. The fact that a 68030 isn't enough CPU for a single user of an X GUI ) under V.4 alarms me. The fact that X applications potentially generate ) significant numbers of packets and eat up CPU cycles even when there's ) no user interaction alarms me (ever watched a LANalyser when xeyes is ) running?). Applications controlling such dumb things as rubber-banding ) alarms me. I'm no Xpert, but has the industry got it wrong? ) ) Tim. ) -- ) Tim Oldham, BT Applied Systems. tjo@its.bt.co.uk or ...uunet!ukc!its!tjo ) Living in interesting times. ) ) For starters, I agree with you that the means by which X has been made a standard is the most undesirable way to do it, but it is the only way that seems to work. X was made a standard because there came a need for some software that had capabilities much of which X satisfied, because many programmers started using it, and because industry momentum toward "open systems" pushed the "big players" into needing a platform on which to build the UNIX GUI's. In fact, the computing model that X was designed to fit is a somewhat outdated one. That does not mean to say that X is not a fantastic technical achievement. Moreover, I think X has proved itself to be a useful tool in leveraging UNIX as everybody's OS. About your concerns relating to X's performance... X is a relatively young beast considering its complexity. There is certainly time for X to make up for its shortcomings. I would hope that X will grow up as UNIX itself has (although UNIX still has some growing to do). Over time some of the memory issues will improve, the functionality will shift to meet user needs, and new innovations introduced as needed. As far as the CPU it takes to run it, so what. I agree that programmers that write innefficient code just because they are a running on a Cray are inept idiots, but I don't think the X implementers fall into that category. I hope X improves in that area, but the lower cost of hardware and more powerful cpu's makes it a non-issue as far as the current X implementation goes. Within the next decade, we all may be able to afford the power of a SPARC workstation or whatever at home with 16mb of memory and 600 mb of disk running a cheap but powerful version of UNIX (go GNU). Moreover, let's hope that FDDI solves the lan traffic problem over the medium term. Your concerns a very well founded, but we are in the Vietnam syndrome at this point -- there seems to be no turning back. Finally, I would like to take this opportunity to make a sales pitch. If X were written today, it would have been better to write it in C++. Complex systems, such as X, should find great savings in terms of code size, executable size, and memory usage with proper implementation in C++. In addition, X already attempts to present itself in the object oriented paradigm. Since NC-17 (please call it X15 to avoid confusion) has been scheduled so far away, please consider writing it in C++. It would be very easy to provide a C callable interface to it to maintain compatiblity with existing code. I don't know what the current status of X is, but if it is still under the auspices of MIT, it would be a great educational experience for the implementers, many of whom I expect are students, to learn how to program C++ on a large project. (This has been an unpaid announcement sponsored by committee to elect C++ as the next ruler of the programming languages.) +---------+ | Coral | |@@@@@*@**| |@@*@@**@@| Don Dewar |*@@**@@@@| Coral Network Corporation, Marlborough, MA |@***@@@@@| Internet: don@coral.com |@@**@@@@@| Phone: (508) 460-6010 |*********| Fax: (508) 481-6258 |Networks | +---------+
asente@adobe.com (Paul Asente) (11/02/90)
In article <9011010052.AA05115@zia.aoc.nrao.edu> cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) writes: >Working against NeWS (and presumably Display PostScript) is the fact that >they impose the PostScript imaging model on their clients, which may not >be appropriate for some applications. Not true for Display PostScript, at least as it exists on DEC and IBM boxes (i.e. as an X extension, as opposed to NeXT, where it's the whole window system). You can freely intermingle PostScript and X calls to achieve the results you want. For example, a useful programming technique is to use PostScript to image into a pixmap and use XCopyArea to blit portions or all of the pixmap into an X window -- this gives you smooth animation since it works as double buffering. Especially useful for dragging outlines of complicated shapes around. -paul asente asente@adobe.com ...decwrl!adobe!asente
gjc@mitech.com (11/02/90)
In article <V68%X7@uzi-9mm.fulcrum.bt.co.uk>, tjo@its.bt.co.uk (Tim Oldham) writes: > CS 101: Network Window Systems > > I'd be extremely interested in hearing peoples' views on this. I personally > think that X is seen as far too much as a panacea for Unix HCI, and it > worries me that X has been seized upon as a ``standard'' with little > thought for the implications in terms of hardware and networking costs. > The fact that I hear people from Sun tell me ``Our implementation of > Open Look is great --- but you need 16 Meg in your SPARCstation'' alarms > me. The fact that a 68030 isn't enough CPU for a single user of an X GUI > under V.4 alarms me. My humble observations: X applications can generally perform better and with less CPU load than comparable applications in other window systems I have used extensively: APOLLO, LISPMACHINE, VMS-UIS/VWS. Quite possibly X is not as drop-dead "efficient" as directly writing to the machine registers of a IBM-PC style VGA or EGA board. The 68030 CPU is plenty CPU for a single user of an X GUI application. Perhaps the application you have in mind is a memory hog or your machine has too little free memory? Even the lowly VAXSTATION-2000 does pretty well with VMS DECWINDOWS when the machine has sufficient memory. ***-------MEMORY--------*** That seems to be the real issue of late. Seriously. This is across the entire field of computer science and engineering. You even have things like the source to XTERM aproaching or exceding the size of significant modules of a program like Macsyma. (Irony: People still think of programs like Macsyma as "large" and "unwieldy". Of course one reason for this is the piss-poor state of the art of commercial lisp implementations currently, especially on the other great panacea of our time, RISC machines). But I digress... -gjc
mh@roger.imsd.contel.com (Mike Hoegeman) (11/04/90)
In article <7883@adobe.UUCP> asente@adobe.com (Paul Asente) writes: >In article <9011010052.AA05115@zia.aoc.nrao.edu> cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) writes: >>Working against NeWS (and presumably Display PostScript) is the fact that >>they impose the PostScript imaging model on their clients, which may not >>be appropriate for some applications. > >Not true for Display PostScript, at least as it exists on DEC and IBM boxes >(i.e. as an X extension, as opposed to NeXT, where it's the whole window >system). You can freely intermingle PostScript and X calls to achieve the >results you want. For example, a useful programming technique is to use >PostScript to image into a pixmap and use XCopyArea to blit portions or all >of the pixmap into an X window -- this gives you smooth animation since it >works as double buffering. Especially useful for dragging outlines of >complicated shapes around. > > -paul asente > asente@adobe.com ...decwrl!adobe!asente Just as a quick addition to this thread, X11/NeWS is capable of doing this too -mike hoegeman, mh@roger.imsd.contel.com
mouse@LARRY.MCRCIM.MCGILL.EDU (11/04/90)
> 1) The X Window System and GUIs built on X are expensive in terms of > CPU, memory and network resources. Discuss. Discuss what? How your first sentence resembles "Have you stopped beating your wife yet?"? Also, "expensive" is a fuzzy enough term that the same accusation could be leveled against well-nigh any windowing system of any sort. In fact, R4 contains a great deal of work designed specifically to lighten the CPU load the server places on its machine. (It's called speeding up the server, but it amounts to the same thing.) > You should compare the X philosophy with competing network > windowing philosophies such as those based on PostScript. Very well, let's compare X to a PostScript-based system. The X approach distributes the memory load: the server is smaller at the expense of making the clients larger. I have never done any tests, so I can't comment on the relative amounts of "smaller" and "larger". Similarly, X distributes the CPU load. X uses more network bandwidth, except in very atypical applications. This is a disadvantage for the X approach. (Again, I haven't done any tests, so I can't say how much more.) One difference which is not a philosophical difference, but is still significant, is that X is available entirely free. Another non-philosophical difference, which again is significant: X is far more widespread. (This is, I believe, due in large part to its being available free.) The first two are, IMO, advantages for X. There is only one server, but many clients, often on many machines. When the client machine is not the server machine, the client machine will typically be the "bigger" (more memory, faster cpu, etc) of the two. In the case where the client and server are known to be on the same machine, and portability is not a consideration, an all-singing-all-dancing server may indeed be a better way to go. (Network bandwidth does not worry me. Networks are fast and getting faster: 10Mbps is so common you find it in dorm rooms nowadays, with fiber (80Mbps? 100Mbps?) in regular use, and higher rates coming down the pike. In any case, at least to my mind, it's heavily outweighed by the advantages.) > I personally think that X is seen as far too much as a panacea for > Unix HCI, and it worries me that X has been seized upon as a > ``standard'' with little thought for the implications in terms of > hardware and networking costs. HCI? I'm not familiar with the acronym. Seizing upon anything with little thought for the implications is generally a bad idea. :-) > The fact that I hear people from Sun tell me ``Our implementation of > Open Look is great --- but you need 16 Meg in your SPARCstation'' > alarms me. And well it should - but it falls on the other side of the line :-) OpenWindows is one of the server-does-everything servers, and not only that, but it *also* supports the X model. Of *course* it's huge! > The fact that a 68030 isn't enough CPU for a single user of an X GUI > under V.4 alarms me. It's not? The 3/60 on my desk seems to do just fine, and it's only a 68020.... > The fact that X applications potentially generate significant numbers > of packets and eat up CPU cycles even when there's no user > interaction alarms me (ever watched a LANalyser when xeyes is > running?). That's a cause for bug reports, not for slamming the window system design philosophy. I'm sure it's not in the least difficult to code a NeWS application badly so that it eats up bandwidth like mad too.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
jimf@SABER.COM (11/05/90)
|HCI? I'm not familiar with the acronym.
Human-Computer Interface. More often CHI, as in SIGCHI.
As for X versus other windowing environments, the X distributed
approach is a good one so long as network bandwidth is high. Other
techniques, such as those used in NeWS, are better when bandwidth must
be preserved, such as over telephone lines. The X imaging model is
far inferior to most others available (such as Display PostScript,
NeWS, or SGI GL/DGL) but it suffices for many applications.
Extensions are already correcting many deficiencies.
I think of X as the IBM-PC of the windowing world. It's not that
great a technological feat -- but it's open enough that people can fix
the things that were done wrong. It's not elegant -- but it works
well enough to get your work done. When it comes right down to it
that's all most of us want anyway.
jim frost
saber software
jimf@saber.comjg@crl.dec.com (Jim Gettys) (11/05/90)
In article <9011040724.AA03335@Larry.McRCIM.McGill.EDU>, mouse@LARRY.MCRCIM.MCGILL.EDU writes: > X uses more network bandwidth, except in very atypical applications. > This is a disadvantage for the X approach. (Again, I haven't done any > tests, so I can't say how much more.) I've never seen any real data; until I do, I treat all claims that other systems send fewer bytes with scepticism. To date, all I've ever seen is marketing claims. Some real data for real applications would be very interesting. The X11 protocol is much more byte efficient than earlier versions of X were. In any case, remember that on a local net, if it takes longer to compute the byte than to send it, you've suffered a net performance loss. The X protocol was carefully designed to be very very easy to process, for maximum performance. Over low speed links, one should use an X protocol compressor; such things exist, and optimize link bandwidth at the expense of CPU time overhead, the correct choice for such situations. > > One difference which is not a philosophical difference, but is still > significant, is that X is available entirely free. > > Another non-philosophical difference, which again is significant: X is > far more widespread. (This is, I believe, due in large part to its > being available free.) > > The first two are, IMO, advantages for X. There is only one server, > but many clients, often on many machines. When the client machine is > not the server machine, the client machine will typically be the > "bigger" (more memory, faster cpu, etc) of the two. In the case where > the client and server are known to be on the same machine, and > portability is not a consideration, an all-singing-all-dancing server > may indeed be a better way to go. Huh? With shared libraries, and the fact that communications are typically faster on the same machine? I don't see that the conclusion follows. And the biggest argument for such servers is to make interaction with the user as close as possible to reduce latencies; on the same machine, this argument is specious. On the same machine, a cycle is a cycle is a cycle, unless overhead is increased by the choice of where to do the computation. > > (Network bandwidth does not worry me. Networks are fast and getting > faster: 10Mbps is so common you find it in dorm rooms nowadays, with > fiber (80Mbps? 100Mbps?) in regular use, and higher rates coming down > the pike. In any case, at least to my mind, it's heavily outweighed by > the advantages.) > Agreed. X's design center is campus area networking. We are in the middle of installing FDDI here to our workstation, for example. - Jim Gettys
ian@sq.sq.com (Ian F. Darwin) (11/06/90)
Paul Asente (asente@adobe.com) writes: > >... NeWS (and presumably Display PostScript) ... > >impose the PostScript imaging model on their clients, which may not > >be appropriate for some applications. > > Not true for Display PostScript, at least as it exists on DEC and IBM boxes > (i.e. as an X extension... Similar capability exists, of course, in Sun's Openwindows 2; you can create an XView window and render PostScript code into it, mixing XView/Xlib calls and PostScript calls. See ~openwin/share/xvps.ps for explanation and sample code.
fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) (11/06/90)
> > I think of X as the IBM-PC of the windowing world. It's not that > great a technological feat -- but it's open enough that people can fix > the things that were done wrong. It's not elegant -- but it works > well enough to get your work done. When it comes right down to it > that's all most of us want anyway. > Congrats. That was Well-Said. However if vendors (and academics) want that little extra zip, that little something that differentiates their software from the others, sometimes "well enough" is not "good enough". Thank goodness NeWS is an alternative. Frank G.
db@helium.East.Sun.COM (David Brownell) (11/06/90)
> As for X versus other windowing environments, the X distributed > approach is a good one so long as network bandwidth is high. Other > techniques, such as those used in NeWS, are better when bandwidth must > be preserved, such as over telephone lines. There's another area where alternate approaches (e.g. NeWS) can be better than X11: where LATENCY is an issue. NeWS lets you address bandwidth scarcity by changing the message encoding used for a session; it lets you address latency problems by eliminating some messages entirely. With NeWS, you can (for example) make the server handle rubber banding or menu selection without any roundtrip messages, and hence without extra network/os latency penalties -- latency is eliminated. Can't be done with the generic X11 protocol, though one might define extensions. Potentially, this approach can let one application process talk to more displays at once. On the other hand, UNIX doesn't have many applications today where that's an issue, and I agree that it'd be good to see some hard data. Is anyone gathering any? - Dave One of the Million monkeys ... see, here's my keyboard!
janssen@parc.xerox.com (Bill Janssen) (11/06/90)
> In the case where > the client and server are known to be on the same machine, and > portability is not a consideration, an all-singing-all-dancing server > may indeed be a better way to go. One of the big problems with local X (client and server on the same machine) is context-switching back and forth between the two programs. When I was working with X interfaces to large UNIX Common Lisp environments, we found it advisable to run the environment on one machine and the display on another, purely to avoid this effect. In fact, two people would "trade" machines: I'd run my Lisp image on Fred's machine, displaying on mine, and he'd run his image on my machine, displaying on his. Noticably crisper on input... Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
mouse@LIGHTNING.MCRCIM.MCGILL.EDU (11/06/90)
>> In the case where the client and server are known to be on the same >> machine, and portability is not a consideration, an >> all-singing-all-dancing server may indeed be a better way to go. > Huh? With shared libraries, and the fact that communications are > typically faster on the same machine? I don't see that the > conclusion follows. I said "may". This implies also "may not". > On the same machine, a cycle is a cycle is a cycle, unless overhead > is increased by the choice of where to do the computation. It is, to some extent - can you say "context switch"? While it's true that context switches don't really take all that long, they do take time. And on some machines (Sun-4s, for example), there's a fairly sharp performance knee when too many processes are competing for cpu. (What? I'm defending the non-X side? Somebody wake me up, quick! :-) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) (11/06/90)
> Paul Asente (asente@adobe.com) writes: > > >... NeWS (and presumably Display PostScript) ... > > >impose the PostScript imaging model on their clients, which may not > > >be appropriate for some applications. > > > > Not true for Display PostScript, at least as it exists on DEC and IBM boxes > > (i.e. as an X extension... > > Similar capability exists, of course, in Sun's Openwindows 2; you can create > an XView window and render PostScript code into it, mixing XView/Xlib calls > and PostScript calls. See ~openwin/share/xvps.ps for explanation and sample > code. > That because the "PostScript" is being rendered by NeWS. And, also the problem with X extensions is that, they are...extensions, and not guaranteed to be available on your server. With OpenWindows Postscript rendering (more properly, NeWS rendering) is guaranteed to be available. This is a *much* more desirable position for a developer, rather than hoping that an extension is available. Frank G.
fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) (11/07/90)
> > For starters, I agree with you that the means by which X has been made > a standard is the most undesirable way to do it, but it is the only > way that seems to work. The market has always decided *real* standards. Has and always will. The way that X (and OSF/Motif, and the X toolkit in general) was foisted upon the computing community by DEC/IBM/HP pounding their collective chests and declaring it a standard, insulting everyone's intelligence by stating that they've always been behind Unix and open systems, is certainly not a desirable way of selecting an technology that companies use to conduct business and universities use to help with their research. > X was made a standard because there came a > need for some software that had capabilities much of which X > satisfied, because many programmers started using it, and because > industry momentum toward "open systems" pushed the "big players" into > needing a platform on which to build the UNIX GUI's. Yes, back then the time was ripe for some decent standard GUI software for Unix. The Macintosh GUI had teased Unix developers with its growing commercial success, and Sunview (which predated the Mac's UI), was not portable or very "user friendly" (gees...I hate that term). However, I believe that X was *really* made a de facto standard primarily because DEC (and IBM to some degree) did not want NeWS to become another NFS. Despite the low licensing fee of NFS, both DEC and IBM had to swallow a lot of humble pie when they had to license Sun's technology; big corporations do not like to do this. Its bad PR when you license a competitors technology. Hence the funding to MIT by DEC. (Note that IBM just happens to be funding a spin-off to commercialize the Andrew File System, and another to commercialize Xerox OOP/Database/GUI technology with Metaphor...IBM doesn't really want Sun *or* DEC stuff!) What also helped X was the early "alpha" condition of NeWS. Sun couldn't help it; they were in a race. Their strategy was to rush NeWS development to compete. In retrospect, this was a lousy game plan. We all know what happens when you develop software in this environment. Many people got burned. > In fact, the > computing model that X was designed to fit is a somewhat outdated one. > That does not mean to say that X is not a fantastic technical > achievement. Moreover, I think X has proved itself to be a useful tool > in leveraging UNIX as everybody's OS. > Yes, I agree. X's view of the world is complex and somewhat outdated. However, Rob Scheifler, Jim Gettys, et al have done a marvelous job. They are to be complimented and commended for their tremendous efforts. > About your concerns relating to X's performance... X is a relatively > young beast considering its complexity. There is certainly time for X > to make up for its shortcomings. I certainly hope that its shortcomings are made up fairly quickly for the group that I heard that's building an air traffic control system in X....:-z > Your concerns a very well founded, but we are in the Vietnam syndrome > at this point -- there seems to be no turning back. That's the reason why you continue to use X Window technology ?!... I've been developing in X for some time now, its nice but just doesn't feel right for certain applications. Considering the recent moves made by Sun in regards to NeWS (and OW in general), I, for one *will be* turning back. Frank G. [insert usual caveat]
jg@crl.dec.com (Jim Gettys) (11/07/90)
In article <9011062334.AA16216@islanders.>, fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: > > > > For starters, I agree with you that the means by which X has been made > > a standard is the most undesirable way to do it, but it is the only > > way that seems to work. > > The market has always decided *real* standards. Has and always will. > > The way that X (and OSF/Motif, and the X toolkit in general) was > foisted upon the computing community by DEC/IBM/HP pounding their > collective chests and declaring it a standard, insulting > everyone's intelligence by stating that they've always been behind > Unix and open systems, is certainly not a desirable way of > selecting an technology that companies use to conduct business > and universities use to help with their research. Nothing like rewritten history, particularly from people who weren't involved.... Our arms got twisted (but not particularly by my own company in fact; at the time Unix was a backwater, and VMS didn't know or care about X); in fact, my shoulder is still sorest from a particular University professor whose initials are AvD and likes to sell books :-). X11 design started well BEFORE Digital decided to adopt it for VMS, for example (not to mention the history well before X11...). The design was published before implementation began, with feedback from all over, with alpha and beta test code being available to everyone simultaneously; this led to implementations for many machines (including Sun, Apollo, HP, DEC, and IBM) being available even at the first release of X11. Independent of Digital's history on "open systems" (ah yes, the year's, or maybe the decade's buzz words), which is probably better than most, and poorer than some, I dunno how to do things more openly than that. We were openly willing to fall flat on our faces, too, openly in public, if we failed to deliver. If you don't like X's design, where were you during the public design and alphaa and beta testing? Lots of things got changed/fixed/improved from comments we recieved. Is "open systems" defined to be only software designed, developed, licensed, and controlled by AT+T and/or Sun Microsystems? I somehow think not... > > > X was made a standard because there came a > > need for some software that had capabilities much of which X > > satisfied, because many programmers started using it, and because > > industry momentum toward "open systems" pushed the "big players" into > > needing a platform on which to build the UNIX GUI's. > > > However, I believe that X was *really* made a de facto standard primarily > because DEC (and IBM to some degree) did not want NeWS to become > another NFS. Despite the low licensing fee of NFS, both DEC and IBM > had to swallow a lot of humble pie when they had to license Sun's > technology; big corporations do not like to do this. Its bad PR > when you license a competitors technology. Hence the funding to > MIT by DEC. (Note that IBM just happens to be funding a spin-off > to commercialize the Andrew File System, and another to commercialize > Xerox OOP/Database/GUI technology with Metaphor...IBM doesn't > really want Sun *or* DEC stuff!) > As opposed to developing the technology in the open, freely available to all, with input from people all over? Please go read the acknowlegements in the X distribution; in particular in the X Window System book. Significant contributors to X include folk like Dave Rosenthal of Sun (also known as one of the NeWS folks), who we interacted with since the days when both he and James Gosling were still at CMU, and many many many others. You belittle the contributions of all of those people and their companies with such (incorrect) claims. X has been a community effort, from very early on. You also seem to take as a given that NeWS is "better" than X; well some of us certainly don't agree (just ask some ECAD folks, to mention one class of application writer), and have serious reservations about some fundamental aspects of NeWS design; it is different than X, with different beliefs about what is important. If that is your cup of tea, fine with me. The funding of MIT by DEC (and IBM) as part of Athena predates X's existance (or my working for Digital, and going to MIT on Athena) by a year to 1983. From day one, Athena used Unix; ownership of any developments belonged to MIT, with non-exclusive licenses to DEC and IBM. This arrangement is somewhat different that the ITC at CMU (where the Andrew file system comes from), where ownership resides in IBM, with a license to CMU (as I understand the situation). If you like, you can think of it of MIT getting a better deal. In any case, it was MIT's decision to make X freely available; you could argue, if you like conspiracy theory though, that X11 would never have been developed if DEC hadn't been willing to do much of the initial development of X11, which was given to MIT under the same terms as previous versions of X. Hard to tell whether X11 would have been done under other circumstances. I think we would have tried to find people to help us (X11 was too much work for us to do at MIT, and some companies were already trying to make X10 a standard, believe it or not; we did everything we could to prevent that! and that is where the urgency to get X11 out came from), but the issue did not come up since the right people were available at the right time. I won't claim total altruism for my company; there were (and are) good business reasons for establishing standards, but it wasn't specifically to "get Sun". I don't expect complete altruism out of Sun, either; I expect them to further their buisness interests. Boy, this is much longer than I ever intended. I guess I dislike amateur historians. Maybe I'll have to write another book sometime on the history of X; (Cliff Stoll was beating me up the other day) but the scars of the last book have not yet faded... But it would be a much more fun book to write; I could try to find out what happened at all the other companies who decided to use X; that would be facinating. Jim Gettys Digital Equipment Corporation (formerly of MIT Project Athena) Cambridge Research Laboratory Cambridge, Massachusetts
nazgul@alphalpha.com (Kee Hinckley) (11/08/90)
In article <9011051527.AA03775@armory> jimf@SABER.COM writes: >As for X versus other windowing environments, the X distributed >approach is a good one so long as network bandwidth is high. Other I might as well put my two cents in here. I think that X was adopted because people desperately needed a portable graphics substrate that was freely available. But I really wish it wasn't a networked window system. I see very little that can be gained from networking graphics that couldn't be done more efficiently using RPC and other protocols at higher levels of abstraction. And without the networking issues to get in the way the issues of efficiency would largely be moot. I realize it isn't that easy to discard. You would have to do a number of things very differently, but I think it would have significantly lessened the memory and CPU requirements that X imposes. -- 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.
fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) (11/08/90)
> >Working against NeWS (and presumably Display PostScript) is the fact that > >they impose the PostScript imaging model on their clients, which may not > >be appropriate for some applications. > > Not true for Display PostScript, at least as it exists on DEC and IBM boxes > (i.e. as an X extension, as opposed to NeXT, where it's the whole window > system). You can freely intermingle PostScript and X calls to achieve the > results you want. For example, a useful programming technique is to use > PostScript to image into a pixmap and use XCopyArea to blit portions or all > of the pixmap into an X window -- this gives you smooth animation since it > works as double buffering. Especially useful for dragging outlines of > complicated shapes around. > What Paul is describing is also true for rendering NeWS in an XView CANVAS under OpenWindows. And, no X extensions are involved; you're guaranteed to get PS rendering with OW. Frank G. X Extensions = Batteries not (always) included
david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (11/09/90)
fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: > >> Paul Asente (asente@adobe.com) writes: >> > >... NeWS (and presumably Display PostScript) ... >> > >impose the PostScript imaging model on their clients, which may not >> > >be appropriate for some applications. >> > >> > Not true for Display PostScript, at least as it exists on DEC and IBM boxes >> > (i.e. as an X extension... >> >> Similar capability exists, of course, in Sun's Openwindows 2; you can create >> an XView window and render PostScript code into it, mixing XView/Xlib calls >> and PostScript calls. See ~openwin/share/xvps.ps for explanation and sample >> code. > > And, also the problem with X extensions is that, they are...extensions, > and not guaranteed to be available on your server. With OpenWindows > Postscript rendering (more properly, NeWS rendering) is guaranteed > to be available. Only guaranteed if you are running OpenWindows [sic] and guaranteed NOT to be available if you are running any other X server. This is obviously a bad position to find oneself IF you are: 1. Writing code which is intended to be portable, OR 2. Writing code which will be around for a long time. If you are only writing code for Sun machines, AND if your code is throw away junk, then by all means, count on OpenWindows [sic] capabilities. Using OpenWindows [sic] specific capabilities is as questionable as using DEC FORTRAN specific capabilities 10 years ago: they are GREAT capabilities, but forget about porting. And the only reason for FORTRAN then was portability, and the best reason for X today is platform independence! Not that writing code for Suns only is a *bad* thing - it _is_ the biggest single market TODAY. Just like the VAX was the obvious platform 10 years ago. Sun makes really nice machines, and their software isn't too bad either. However, it you work for the government where we are directed by the OMB to avoid vendor-specific soulutions, then writing Sun specific code might be the last code you write... (written on a Sun via rn on a VAX, using X11R4 on everything) ------------------------------------------------------------------------- David Smyth david@jpl-devvax.jpl.nasa.gov Senior Software Engineer, seismo!cit-vax!jpl-devvax!david X and Object Guru. (818)393-0983 Jet Propulsion Lab, M/S 230-103, 4800 Oak Grove Drive, Pasadena, CA 91109 ------------------------------------------------------------------------- If British police don't give speeding tickets, what DO they do?!?! -------------------------------------------------------------------------
korp@atlantis.ees.anl.gov (Peter Korp) (11/09/90)
In article <10294@jpl-devvax.JPL.NASA.GOV> david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes: [ some talk about X extensions and OpenWindows ] > >Only guaranteed if you are running OpenWindows [sic] and guaranteed NOT >to be available if you are running any other X server. > This is true, but I think the point was that the lowest common denominator in OpenWindows includes many extensions in X. This allows application programmers to worry more about writing their app rather than how to work around missing extensions. OpenWindows(TM) is the correct name of the product. >This is obviously a bad position to find oneself IF you are: > 1. Writing code which is intended to be portable, OR > 2. Writing code which will be around for a long time. > >If you are only writing code for Sun machines, AND if your code is >throw away junk, then by all means, count on OpenWindows [sic] >capabilities. > I guess I have been writing throw away junk for the boys over in Desert Shield then. Honestly, the recent developments in the OpenWindows arena will provide an impetus to port OpenWindows to other platforms. Lots of the software that I have written is hardly viewed by the sponors as throw away junk, rather as a more time/cost effective solution to generating custom applications. Don't get me wrong, they use X stuff too, just that they feel they would rather have the best of both worlds. >Using OpenWindows [sic] specific capabilities is as questionable as >using DEC FORTRAN specific capabilities 10 years ago: they are GREAT >capabilities, but forget about porting. And the only reason for >FORTRAN then was portability, and the best reason for X today is >platform independence! > On the contrary, I ran most of my code on the Macintosh NeWS port first time. Portability of code is great, it just has to have NeWS. >Not that writing code for Suns only is a *bad* thing - it _is_ the >biggest single market TODAY. Just like the VAX was the obvious >platform 10 years ago. Sun makes really nice machines, and their >software isn't too bad either. However, it you work for the government >where we are directed by the OMB to avoid vendor-specific soulutions, >then writing Sun specific code might be the last code you write... > Apparently our sponsors have a different view of the future than yours. >(written on a Sun via rn on a VAX, using X11R4 on everything) > >------------------------------------------------------------------------- >David Smyth david@jpl-devvax.jpl.nasa.gov >Senior Software Engineer, seismo!cit-vax!jpl-devvax!david >X and Object Guru. (818)393-0983 >Jet Propulsion Lab, M/S 230-103, 4800 Oak Grove Drive, Pasadena, CA 91109 >------------------------------------------------------------------------- > If British police don't give speeding tickets, what DO they do?!?! >------------------------------------------------------------------------- Peter -------------------------------------------------------------------------- These opinions are all my own, though life would be simpler if they were yours too!
erik@westworld.esd.sgi.com (Erik Fortune) (11/09/90)
In article <9011062334.AA16216@islanders.>, fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: > The way that X (and OSF/Motif, and the X toolkit in general) was > foisted upon the computing community by DEC/IBM/HP pounding their > collective chests and declaring it a standard, insulting > everyone's intelligence by stating that they've always been behind > Unix and open systems, is certainly not a desirable way of > selecting an technology that companies use to conduct business > and universities use to help with their research. Comrades! He's on to us! Execute Plan 7 immediately! > However, I believe that X was *really* made a de facto standard primarily > because DEC (and IBM to some degree) did not want NeWS to become > another NFS. I was writing X servers for IBM at the time. This is nonsense. > Despite the low licensing fee of NFS, both DEC and IBM > had to swallow a lot of humble pie when they had to license Sun's > technology; big corporations do not like to do this. Its bad PR > when you license a competitors technology. Hence the funding to > MIT by DEC. Also nonsense. Project Athena is not some evil Digital plot to foist X on the unsuspecting universe. Nor is the ITC (at Carnegie-Mellon) an evil IBM plot to foist Andrew on the world. You should at least make an attempt to find out what really happened before you start flaming about this stuff. >(Note that IBM just happens to be funding a spin-off > to commercialize the Andrew File System, and another to commercialize > Xerox OOP/Database/GUI technology with Metaphor...IBM doesn't > really want Sun *or* DEC stuff!) Have you ever actually used the Andrew File System? I can't wait until we have AFS here and I can pitch NFS forever... -- Erik Disclaimer: all opinions my own. Smiley's where appropriate.
asente@adobe.com (Paul Asente) (11/10/90)
In article <9011072333.AA17805@islanders.> fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: > And, no X extensions are involved; you're guaranteed to get PS > rendering with OW. > > X Extensions = Batteries not (always) included How is writing an application assuming that the X server is actually an Open Windows server any different from writing an application assuming that the X server supports some particular extension? -paul asente asente@adobe.com ...decwrl!adobe!asente
asente@adobe.com (Paul Asente) (11/10/90)
In article <1990Nov7.170826.10967@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: >But I really wish it wasn't a networked >window system. I see very little that can be gained from networking >graphics that couldn't be done more efficiently using RPC and other >protocols at higher levels of abstraction. And without the networking >issues to get in the way the issues of efficiency would largely be >moot. At the time X was designed (and even to some degree today) there was no standard RPC mechanism, or anything else at that level. You may argue that if X had picked some RPC mechanism, that mechanism would be a standard today, and you might well be right. But you might also be wrong, and opposition to accepting RPC might have kept people from adopting X. -paul asente asente@adobe.com ...decwrl!adobe!asente
jg@crl.dec.com (Jim Gettys) (11/10/90)
Also, at least for a conventional implementation, RPC is no where fast enough. X is a streaming protocol, and runs maybe 10-30 times faster/request, since the overhead is much lower. - Jim
moraes@cs.toronto.edu (Mark Moraes) (11/12/90)
fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: > The market has always decided *real* standards. Has and always will. True. We heard a fascinating talk from a Sun person when OpenWindows1.0 came out about how they had finally acknowledged that the market did want X. :-) > The way that X (and OSF/Motif, and the X toolkit in general) was > foisted upon the computing community by DEC/IBM/HP pounding their Funny, we've been running it on Suns all along (back in the good old days of X10) So have lots of other people. Mark.
nazgul@alphalpha.com (Kee Hinckley) (11/14/90)
In article <1990Nov9.204140.25125@crl.dec.com> jg@crl.dec.com (Jim Gettys) writes: >Also, at least for a conventional implementation, RPC is no >where fast enough. X is a streaming protocol, and runs maybe >10-30 times faster/request, since the overhead is much lower. Don't get me wrong. I certainly wasn't proposing that X use RPC! I just would have preferred foregoing remoteness for efficiency. But, it's all moot anyway. -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.
fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) (11/15/90)
> > X11 is not significantly more expensive than NeWS as far a CPU is related. > However the load may be distributed rather differently: some computations > that are done on the client side (eg. user coordinate/screen coordinate > transformations) may be done on the server side. Note that this implies > that a NeWS terminal, should such a beast exist, would have to be more > powerful than an equivalent X terminal. > Well...if you said that an X/NeWS terminal (its only a matter of time...) had to be more "powerful" because it swaps more than the vanilla MIT X, I would tend to agree with you, because OW is larger. NeWS, unlike X, offers you the choice of a client *or* a server-side toolkit; X only gives you the client-side. In any event, using the X/NeWS server, you get both. > The only area mentioned above where NeWS wins over X is in the > interprocess communications overhead: since clients download PostScript > code to the server no client-server transfers are necessary to repair > windows after expose events. How about dedicating a lightweight task *in* the server to efficiently track the mouse? This greatly minimizes the net traffic...there isn't any. (To all those out there who say, "networks are getting faster so who cares?" should hang your software engineering heads in shame.). Reliable double clicks? Its a given. How about a dynamically extensible class mechanism *in* the NeWS server? How about running windowed applications over a 2400 modem? A proof of concept was demoed at a recent Usenix (during a WIP session) with an email application. > > I also believe that NeWS is rather better at handling exceptions (eg. servers > running out of memory) than X, but there is no fundamental reason why X > should not improve in this regard in future releases. Yes, I agree. Both X and NeWS are relatively young and evolving. So why are groups like AFIPS standardizing on Xt as *the* way to program for X? > > Working against NeWS (and presumably Display PostScript) is the fact that > they impose the PostScript imaging model on their clients, which may not > be appropriate for some applications. X11 uses a very low-level raster > graphics model which may act as the foundation for any of a number of > higher level models (including PostScript --- see GhostScript as an example). I don't understand. If you use X/NeWS, you get both. You choose the model that's best for the app. > Furthermore, I suspect that many programmers are not comfortable with the > though of writing PostScript code; certainly the idea of maintaining a > few hundred lines of someone elses PostScript code would give *me* night- > mares. > Gees, on the net we have some of the brightest programmers in the world, yet, most people on it say its a bear to learn something new to solve a problem. These are the same people that know C, C++, Smalltalk, the innards of the Unix kernal, the intricicies of awk/lex/yacc...yet, a simple, simple little language like Postscript scares everyone. The programmers that are typically afraid of Postscript are those people whose first exposure to Postscript was looking at the output of a mechanized, poorly-formatted XXX-to-PS filter. Heck, there is no need for formatting if you're just going to have another program, or printer, read it. I'm sure if your first exposure to C was looking at a multi-pager that didn't have too many newlines or tabs or comments, you'd be saying the same about C (...many have....). > > The fact that I hear people from Sun tell me ``Our implementation of > > Open Look is great --- but you need 16 Meg in your SPARCstation'' alarms > > me. > > This just ain't so. I'm running OpenWindows 2.0 on a SPARCstation 1 with > only 8 Mbytes of memory and, as long as I don't start doing silly things > like grabbing hold of huge globs of shared memory, it hums along very > nicely thank you (not that that stopped me from asking for more memory). Well...lets be fair. Unless you run most of your X/NeWS clients remotely (which is not a bad idea if you can), think about a minimum of 12 MB for doing development on a SS1 with OW. Of course, in this case the more the better. I'm like Chris, I only have 8 MB, but only my console runs locally. I borrow cycles from other SPARCS on the network (isn't that what networks are for?). > Now OpenWindows 1.0.1 really dragged. That turns out to have been due > to the window manager being written in PostScript and, consequently, being > a real memory pig (I rest my case). > In a computer languages class that I taught, I had a student who wrote a video game (so it was a *fun* assignment...so sue me) in interpreted BASIC that ran rings around another students' 80X86 assembler version of the same game. Its not the language. I rest *my* case. Frank G.
fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) (11/24/90)
> > > The market has always decided *real* standards. Has and always will. > > True. We heard a fascinating talk from a Sun person when > OpenWindows1.0 came out about how they had finally acknowledged that > the market did want X. :-) So did many other Sun reps. This was after X was artificially called a standard by DEC/IBM (and to a degree HP). And after many, many articles by DEC people saying "X is de facto standard" over and over again, when a small minority was actually even using X. It was a self-fulfilling prophecy. > > > The way that X (and OSF/Motif, and the X toolkit in general) was > > foisted upon the computing community by DEC/IBM/HP pounding their > > Funny, we've been running it on Suns all along (back in the good old > days of X10) So have lots of other people. > Back in the old days of X10, there was a Miniscule amount of people using X. That's understandable, X was in its formative years. That's my whole point. Why was it called a standard when only a tiny fraction of the computing community used it? You cannot dictate standards like this. It may be a de facto standard now, but back then, it wasn't. Should we be also declaring Postgres an industry standard? Should we declare VPL's DataGlove a standard user interface? How about calling Speculative Execution a de facto standard for handling superscalar opcode management? Can we demand fractal data compression as the industry standard for our Fax machines?.... you get the idea. Besides...sigh..., the key word here is "foisted". Foisted does NOT mean invented....(you know how much email I got explaining how X got "invented"!...sheesh!) I am not denigrating the efforts of the MIT people at all. I applaud their tremendous efforts, it's the marketing style of the big (formerly-Unix-hating-but-now-Unix-loving) companies that I didn't like. Frank G.
gary@proa.sv.dg.com (Gary Bridgewater) (11/24/90)
In article <9011232028.AA24515@islanders.> fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: >... This was after X was artificially called >a standard by DEC/IBM (and to a degree HP). And after many, many articles by >DEC people saying "X is de facto standard" over and over again, when a small >minority was actually even using X. It was a self-fulfilling prophecy. No. This is not an example of a self-fulfilling prophecy. Also, the number of people using a standard is neither here nor there. X Windows was adopted _as_ a standard by a number of vendors and computer user and manufacturing groups - meaning that they would abide by whatever the X Consortium chose to define X as. Some also chose to join so their input could be felt. >Back in the old days of X10, there was a Miniscule amount of people using X. >That's understandable, X was in its formative years. >That's my whole point. Why was it called a standard when only a tiny >fraction of the computing community used it? You cannot dictate >standards like this. It may be a de facto standard now, but back >then, it wasn't. Should we be also declaring Postgres an industry standard? >Should we declare VPL's DataGlove a standard user interface? >How about calling Speculative Execution a de facto standard for handling >superscalar opcode management? Can we demand fractal data compression as >the industry standard for our Fax machines?.... you get the idea. No, I don't get the idea. Again it was called a standard by those who chose to adopt it. You may not be one of them. You can manufacture and market a workstation running whatever windowing system you choose. You can also give it a name and call it a standard. If enough people vote for it (by purchasing it) you can then license it or give it away and rest asurred that it will be used. If very few people buy it it will disappear. This is true of most industries. >I am not denigrating the efforts of the MIT people at all. I applaud their >tremendous efforts, it's the marketing style of the big >(formerly-Unix-hating-but-now-Unix-loving) companies that I didn't like. I think your agenda is leaking a bit. If you are one of the "always been Unix and damn proud of it folks" then good for you. Now that the fUhbnUl companies have come to agree with you why are you unhappy? Can't you take "Yes" for an answer? But - would you prefer that each of these big, powerful companies enter the market with a separate windowing system to "compete" with X? What would be the point? Graphic workstations are the future of Unix - if that future is immediately clouded by a host of competing graphic interfaces running on a common platform what has been gained? Perhaps you feel that they should have, somehow, licensed a proprietary windowing system from a competitor? Perhaps you were hoping to do well at the ensuing mass Going Out of Business Sales? As far as I, personally, was concerned - when I was able to FTP the X10 sources across the net and bring them up on a workstation here the matter was settled. Marketting happened after that - not before. -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary C++ - it's the right thing to do.
marbru@attc.UUCP (Martin Brunecky) (11/26/90)
In article <9011232028.AA24515@islanders.> fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: > >Besides...sigh..., the key word here is "foisted". Foisted does >NOT mean invented....(you know how much email I got explaining >how X got "invented"!...sheesh!) > >I am not denigrating the efforts of the MIT people at all. I applaud their >tremendous efforts, it's the marketing style of the big >(formerly-Unix-hating-but-now-Unix-loving) companies that I didn't like. > Aparently, you DO like marketing styles of some other companies ... 'cause thay want to accomplish something *totally* different: sell more of their gear as oposed to those you don't like ... So should we talk now about how UNIX has been "foisted" upon the computer *users* by the *miniscule* of UNIX proponents by calling it a *de facto standard* at the time when nothing was further away from a "standard" than UNIX was ? Or does it belong into an entirely different News Group (as the entire previous discussion) ? (Suggest: comp.flame -). -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky [BORN TO BASH UIL] marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
erik@westworld.esd.sgi.com (Erik Fortune) (11/27/90)
In article <9011232028.AA24515@islanders.>, fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: >So did many other Sun reps. This was after X was artificially called >a standard by DEC/IBM (and to a degree HP). And after many, many articles by >DEC people saying "X is de facto standard" over and over again, when a small >minority was actually even using X. It was a self-fulfilling prophecy. Get your facts straight. (Most of) IBM was dragged kicking and screaming into X. The only people in IBM who were remotely enthusiastic about X were a bizarre little business unit in california who dealt with universities and technical customers. I was a part of that business unit, and I was the *only* person porting X11 servers at IBM in the early days of X11. I spent a lot of my time fighting off presentation manager and other assorted proprietary IBM stuff. What were you working on in 1986? I was writing window systems, and in the UNIX window systems world it looked like X10 was well on its way to becoming a standard. This terrified enough people (mostly universities and weirdos in assorted advanced development labs) that X11 got designed and written *quickly*. The biggest likely competitor for X was CMU's wm window manager. NeWS was this interesting research thing that Gosling was working on. Lots of people had concerns about problems in NeWS, and it was certainly too young to be considered as a standard. Also, it was proprietary and likely to remain so. One of the things that was cool about X in the early days was the fact that it wasn't proprietary. I worked alongside people from DEC, HP, Apollo and Sun. >Back in the old days of X10, there was a Miniscule amount of people using X. >That's understandable, X was in its formative years. >That's my whole point. Why was it called a standard when only a tiny >fraction of the computing community used it? You cannot dictate >standards like this. It may be a de facto standard now, but back >then, it wasn't. Should we be also declaring Postgres an industry standard? >Should we declare VPL's DataGlove a standard user interface? >How about calling Speculative Execution a de facto standard for handling >superscalar opcode management? Can we demand fractal data compression as >the industry standard for our Fax machines?.... you get the idea. This was exactly the reason that NeWS was considered an interesting research project but not ready for standardization. It was too way too young and untested. X had been through 9 releases (one number was reserved but never used) and the X community had learned a lot from those first 10 releases. Lots of the lessons learned from those early releases of X were applied to X11. That experience also pointed to some likely problems with the design of NeWS. Bob wrote a paper describing some of his concerns about NeWS in late 1986. I'll see if I can dig up a copy... In 1986 it was widely believed that what UNIX really, really needed yesterday was standard graphics. The only things that were not proprietary and were remotely close to being understood well enough to be standardized were X10 and wm, neither of which was acceptable. Hence X11. >Besides...sigh..., the key word here is "foisted". Foisted does >NOT mean invented....(you know how much email I got explaining >how X got "invented"!...sheesh!) > >I am not denigrating the efforts of the MIT people at all. I applaud their >tremendous efforts, it's the marketing style of the big >(formerly-Unix-hating-but-now-Unix-loving) companies that I didn't like. > > >Frank G. Your beliefs about the X community circa 1986 are really way off base (and potentially insulting to lots of people who've worked very hard). X did not come out of anybody's anti-UNIX corporate headquarters. X came out of the universities and assorted corporate advanced development labs. X was embraced by the *Unix* people in these companies to counter the "look at our spiffy proprietary stuff, Unix is so primitive" mentality. -- Erik
paquin@kahua.esd.sgi.com (Tom Paquin) (11/28/90)
In article <9011232028.AA24515@islanders.>, fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: |> So did many other Sun reps. This was after X was artificially called |> a standard by DEC/IBM (and to a degree HP). And after many, many articles by |> DEC people saying "X is de facto standard" over and over again, when a small |> minority was actually even using X. It was a self-fulfilling prophecy. |> Besides...sigh..., the key word here is "foisted". Foisted does |> NOT mean invented....(you know how much email I got explaining |> how X got "invented"!...sheesh!) |> it's the marketing style of the big |> (formerly-Unix-hating-but-now-Unix-loving) companies that I didn't like. Wow. You sure don't know what was going on inside IBM back then. From what I could see, you don't know what was going on at DEC either. I guess I never could know what it looked like from the outside, but any belief that IBM set out to force X on anything is just about as wrong as you can be. IBM's X11 effort was basically a terrified trust in a few very young not-blue-enough-yet unix people who were working on (shudder) BSD on RTs. Even inside that renegade shop, the X work got started because Erik Fortune disregarded instructions to tweak some boring printer code. He went home to Boston for Christmas in late 86 and came back with an X11 server running. Before management even knew what was going on, X was the 4.3 window system for RTs. Even after we got X up on all the displays, and on the PS2 stuff, most management still thought X was a window manager. The goal in that effort was to satisfy the universities, and IBM was involved in a rare example of really listening to their customers and ignoring those gut feels that they know better. What is clear to me is that the need or demand for ANY standard window/graphics system was so acute that almost any serious attempt to solve it would have been massaged till it worked. This demand came from the customers up, not from the companies down. Not only did I do a lot of the IBM server work, but I was also involved with many of the business deals with CMU, MIT, Brown, etc. which got this stuff rolling. I know. I was there. -Tom ***** Opinions are mine, etc.
geer@IRC.CBM.DEC.COM (11/28/90)
As if Erik needs corroboration, but he's telling the truth as I know it, too. I was Manager of Systems Development at MIT's Project Athena from 1985 to 1990. Daniel E. Geer, Jr., Sc.D. External Research Program Digital Equipment Corporation Innovation Technology Resource Center 1 Kendall Square - Bldg. 1400 Cambridge, Massachusetts 02141 Email: geer@crl.dec.com Telephone: 617-621-7443 FAX: 617-621-7423