Kevin Broekhoven <BROEKHVN@QUCDN.QueensU.CA> (06/13/91)
Using the Sun/Scott McNeally definition, OpenLook and X11 are "open" and "standard" in the sense that the specs are published, they are available from more that one vendor, and they're available in volume (have I covered all the bases?) Where does NeWS fit into all of this? In the May SunWorld, Scott McNeally gives an interview where he compares "NeWS to X11" as "Unix to Dos", with the implication that in some number of years, NeWS will be displacing X11. Is the technical spec for NeWS published, and freely implementable? Are there ports planned to other major platforms? Or is NeWS a Sun proprietary product which they expect to be "standard" because Sun will sell it in high volume? i.e. Will Sun be promoting NeWS as a competing open standard, or as a "value added" feature of Sun workstations? I understand that a PostScript extension to X11 is being considered, which may take a little thunder away from the display postscript abilities of NeWS. thanks in advance, Kevin Broekhoven Applications Programmer Computing Services Queens University K7L-3N6 (613)545-2235 Bitnet, NetNorth: BROEKHVN at QUCDN IP: kevin@ccs.QueensU.CA (130.15.48.9) X.400: Kevin.Broekhoven@QueensU.CA
hedrick@athos.rutgers.edu (Charles Hedrick) (06/15/91)
Yes, the NeWS spec is published and others can implement it. There is also code that Sun will let people license (though you'd have to pay Sun). Originally Sun intended NeWS to be the standard window system. They considered it better than X, and indeed there are some technical arguments for that opinion. The market had just adopted NFS, and they hoped the same would happen with NeWS. It didn't, partly because other vendors were becoming scared of Sun, and wanted nothing to do with anything else they initiated, and partly because software for X was available sooner. (It's pretty clear that the first plausible product in an area wins, except in areas where an official standards process can be used to impose a new standard.) Thus Sun was forced to support X, and ended up with OpenWindows, a server that implements both X and NeWS. For the moment most applications that are likely to be used with OpenWindows are based on X. However Sun says they will be coming out with new software in the future that uses NeWS, and takes advantages of its superior capabilities. Unless they are successful in getting other vendors to support both X and NeWS, particularly X terminals (and at least for us, software for 3/50's used as X terminals), some users may resist using applications based on NeWS.
spike@world.std.com (Joe Ilacqua) (06/16/91)
hedrick@athos.rutgers.edu (Charles Hedrick) writes: >The market had just adopted NFS, and they hoped the same would happen <with NeWS. It didn't, partly because other vendors were becoming >scared of Sun, and wanted nothing to do with anything else they <initiated, and partly because software for X was available sooner. >(It's pretty clear that the first plausible product in an area wins, <except in areas where an official standards process can be used to >impose a new standard.) Some how I think that the fact X was freely available had a lot to do with it. X was quickly ported to a large range of machines, mainly, in my opinion, because the source was there for people to play with. NeWS costs money and only ran (as far as I know) on SUNs and SGIs. ->Spike -- The World - Public Access Unix - +1 617-739-9753 24hrs {3,12,24,96,192}00bps
gjc@mitech.com (06/17/91)
In article <91164.101625BROEKHVN@QUCDN.QueensU.CA>, BROEKHVN@QUCDN.QueensU.CA (Kevin Broekhoven) writes: > > In the May SunWorld, Scott McNeally > gives an interview where he compares "NeWS to X11" as "Unix to Dos", with > the implication that in some number of years, NeWS will be displacing X11. Fantastic anology, perhaps. But an absurd prediction.
nazgul@alphalpha.com (Kee Hinckley) (06/18/91)
In article <91164.101625BROEKHVN@QUCDN.QueensU.CA>, BROEKHVN@QUCDN.QueensU.CA (Kevin Broekhoven) writes: > > In the May SunWorld, Scott McNeally > gives an interview where he compares "NeWS to X11" as "Unix to Dos", with Given the current growth rates of DOS and Unix actually this is probably pretty accurate :-). -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com 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.
stripes@eng.umd.edu (Joshua Osborne) (06/19/91)
In article <91164.101625BROEKHVN@QUCDN.QueensU.CA> BROEKHVN@QUCDN.QueensU.CA (Kevin Broekhoven) writes: [...] >Is the technical spec for NeWS published, and freely implementable? Yes, but there is no free "reference port". > Are there >ports planned to other major platforms? Not as far as I know. However it has run on a Macintosh ][ (but not very fast, Display-ish PostScript is a bit much for a Mac to handle), and an Atari ST. RAM was a big problem on both of thoes boxes. (it wouldn't be if you used it with a Mac running MacOS 7, and a big disk, and a PMMU). As far as I know these are not widely available (i.e. people did them to prove that NeWS was portable, but the ports were too slow to sell...). > Or is NeWS a Sun proprietary product >which they expect to be "standard" because Sun will sell it in high volume? I think Sun thought it would be a "standard" because it was "open", and they thought "better". I think it failed because there was no free refernce port, but who can tell? >i.e. Will Sun be promoting NeWS as a competing open standard, or as a >"value added" feature of Sun workstations? I don't think Sun has ever sold software for Workstations that don't run SunOS (well, except TOPS). However SunSoft's charter does not seem to prohibit this... >I understand that a PostScript extension to X11 is being considered, which >may take a little thunder away from the display postscript abilities of NeWS. As far as the drawing stuff it will take some of it away (of corse Sun has had longer to make NeWS fast, so mabie it would be a good thing for Sun... if people use the PostScript extension to X11, they will want it to be fast). However NeWS also has an input model, and object extentions, and intersting grarbage collection (you can use an object in such a way that your reference to it doesn't incrment the refernce counter, and you get some sort of destroy event when the object vanishes. Very handy for things like window managers, or subclassing...). -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)
djones@megatest.UUCP (Dave Jones) (06/20/91)
I wish I could find the article I read the other day. The author said that X is winning out over NeWS because certain big league players were still steamed over the acceptance of NFS as a standard, particularly those who had made large investments in what they considered to be better products. They just weren't going to let NeWS win, even if it was better -- expecially if it was better. (Me? I think it's because nobody wants to type "NeWS" with that stupid little e in it, or explain in conversation that they mean "NeWS" not "news".)
jg@crl.dec.com (Jim Gettys) (06/20/91)
I'll regret this message, as usual, I expect. Many people (myself included) dispute the claim NeWS is "better" than X. Value judgements are always difficult. For example, that I can't write (in the original NeWS, before the X11/NeWS stuff where I can use X facilities to get my job done) with reasonable performance imaging applications that I used to be paid to develop I considered fatal to any such claim; the ECAD folks have had similar problems with NeWS. I have other, more fundamental problems with the overall design of NeWS, but these problems are somewhat more philisophical in nature, rather than simple pragmatics to getting my job (and many other people's jobs) done. Of course, you can dismiss me as biased, if you like :-). As the market seems to have spoken, it generally does not help anyone to beat up on NeWS, so I generally avoid it. A better analogy in my opinion is that X and NeWS are different fruits; comparing apples and oranges is always a dangerous topic. My opinion has been that both the wide availability of X, and the fact that NeWS made life hard for a good chunk of the applications developers in the market, were two of the keys to X's sucess. But then, what do I know. :-) Jim Gettys Digital Equipment Corporation Cambridge Research Laboratory
eric@aquarius.sfu.ca (Eric Kolotyluk) (06/22/91)
I'm glad to see there's still some life in the X vs NeWS discussion, so here's my two bits worth: I've written code for X, NeWS, and Display PostScript (NeXTstep). I still find NeWS to be the most effective coding environment for a number of reasons. 1) The PostScript model is far "better" than X. For example, if I want my X application to display grey scale on a monochrome display I have to encode all the dither maps and then manage all the stipple switching myself. In PostScript I just set the grey level and draw. 2) Unlike an X window server, a PostScript window server is dynamically extensible. I can taylor the look and feel where it's most important, on screen rather than across the network. Unlike Display PostScript, NeWS does primary event handling in the server. This can dramatically reduce the number of events that have to be transfered across the networks. In general, modern computer netorks work best with large quantities of data (tranmitted less frequently) rather than zillions of tiny event packets. And over dial-up slip connections, X is barely usable whereas NeWS applications can perform remarkably well. 3) The architecure of X is very primative from a systems aspect. It's crazy the amount of low level issues you have to worry about writing X applications (like if you don't handle your events fast enough you make the server very upset). 4) The NeWS OOPS extenstions to PostScript offer a lot of potential. I really wish Adobe ahd consider such extensions in Display PostScript. OOPS also greatly simplifies PostScript programming. 5) If I were paying people to write code I would rather they not have to learn an manage too many differnt graphics systems. With X you have to learn X for screen work and somthing else (probably PostScript) for printer work. Using PostScript on screen and on printer reduces the load on the programmers. If X is so great, why is there now a Display Postscript extension? Unfortunately there isn't a NeWS extension to X. While there are many rumors and ideas why X is doing so much better than NeWS, here's a few more for the pot: - No company will ever admit they didn't want Sun to add another de facto industry standard to their resume (an so endorsed an inferior technology like X). Everyone knows companies don't really do things like that. More likely, DEC and IBM invested a lot in Project Athena, so they (and others) simply marketed X more agressively than Sun (who had less invested in NeWS). - NeWS was never as accessible as X (and still isn't). First you had to pay for it, which meant securing funding, typing purchase requisitions, waiting and waiting for the courier... X was easily available via ftp. - Sun must have done something to alienate Adobe, why else would Adobe work so closely with NeXT to develop Display Postscript. - While SGI initially embraced NeWS, and even had a better implementation than Sun, SGI seem to be abandoning NeWS. Rumor has it that Sun was not very cooperative with SGI, wouldn't even accept bug fixes from SGI. SGI spent a lot of time and money working on NeWS, but didn't receive adequate support from Sun. While NeWS is probably the "best" windowing system today, Sun's poor handling of the early marking and vendor/customer relations has much to do with the success of X. If Sun are still serious about NeWS (it still isn't clear that they are), they should do a better job of marketing it, and an even better job of playing nicely with other vendors in order to promote greater industry support for NeWS. They might start by making peace with Adobe (and apologising to SGI).
erik@westworld.esd.sgi.com (Erik Fortune) (06/25/91)
>1) The PostScript model is far "better" than X. For example, if I > want my X application to display grey scale on a monochrome > display I have to encode all the dither maps and then manage > all the stipple switching myself. In PostScript I just set the > grey level and draw. Better for some things, worse for others. Rasterops and colormaps are real useful things for a lot of applictions. Postscript imaging and X imaging are different. Each has its uses. >2) Unlike an X window server, a PostScript window server is > dynamically extensible. I can taylor the look and feel where > it's most important, on screen rather than across the network. > Unlike Display PostScript, NeWS does primary event handling in > the server. This can dramatically reduce the number of events > that have to be transfered across the networks. In general, > modern computer netorks work best with large quantities of data > (tranmitted less frequently) rather than zillions of tiny event > packets. Straw man (IMO). This argument ignores the added complexity of doing the event handling in the server (in terms of server size and performance) and the hassle of debugging a program that is split across multiple machines and languages. There are tradeoffs either way -- doing everything in the server not such a clear win. I still remember the arguments from (some) NeWS folks in the early days of X that it was absolutely impossible to get good interactive performance for things like rubber-banding and outline dragging without handling events in the server. On more than one occasion we'd go and demostrate perfectly acceptable tracking to these people only to hear them make the same claim in a different forum a week later. >And over dial-up slip connections, X is barely usable > whereas NeWS applications can perform remarkably well. No argument here. If your bandwidth is low you need to do more work in the server. >3) The architecure of X is very primative from a systems aspect. > It's crazy the amount of low level issues you have to worry > about writing X applications (like if you don't handle your > events fast enough you make the server very upset). I've never run into this problem. Are your clients runnning on a particularly slow host? Xlib is low level -- it's supposed to be. Try one of the many toolkits available for X (InterViews, Andrew, etc). >4) The NeWS OOPS extenstions to PostScript offer a lot of potential. > I really wish Adobe ahd consider such extensions in Display > PostScript. OOPS also greatly simplifies PostScript programming. I'll steal a line from your posting: "If PostScript is so great, why is there now an OOPS extension." PostScript is a great page description language. As a general purpose programming language, I'll pass. >5) If I were paying people to write code I would rather they not > have to learn an manage too many differnt graphics systems. With > X you have to learn X for screen work and somthing else (probably > PostScript) for printer work. Using PostScript on screen and on > printer reduces the load on the programmers. Postscript is great for some things (generally for things that overlap with printers). For those things, you have Display Postscript. I wouldn't want to write a flight simulator in postscript, though. >If X is so great, why is there now a Display Postscript extension? >Unfortunately there isn't a NeWS extension to X. Because PostScript is good for some things, while X rendering is good for others. I'm not sure what a NeWS extension to X would be. >- No company will ever admit they didn't want Sun to add another > de facto industry standard to their resume (an so endorsed an > inferior technology like X). Everyone knows companies don't really > do things like that. More likely, DEC and IBM invested a lot > in Project Athena, so they (and others) simply marketed X more > agressively than Sun (who had less invested in NeWS). This conspiracy theory nonsense has been around for a long, long time and it's pure garbage. I worked for IBM (doing X -- in fact, I was the only person writing servers at IBM for a number of months) at the time and IBM was dragged kicking and screaming into X. X was written and promoted by engineers in universities and at a number of companies. X gained support because it had a relatively large user community, was demonstrably portable, and was adequate for most of the applications people wanted to write. Also, people were getting tired of having 20 different ways to do graphics and wanted to settle on something (anything!) that was good enough to get the job done. X was a known quantity and was good enough. The amusing and annoying thing about this consipiracy crap is that it always seemed to me (back then) that NeWS was an attempt to derail X because Sun couldn't stand having a widespread standard they hadn't originated. It seemed to me that Sun was petulant about the existence of something they didn't control. At the time it seemed (to me) like we had engineers from a surprisingly broad collection of companies and universities cooperating to produce a window system and then you had Sun off on the sidelines jumping up and down and screaming. I've since gotten to know some of the people involved (from Sun) better, and tempered my opinions somewhat. Get a few things straight, though. X was *NOT* a reaction to NeWS. Project Athena was *NOT* commisioned to create X. IBM in particular did *NOT* even like X a whole lot. >- NeWS was never as accessible as X (and still isn't). First you > had to pay for it, which meant securing funding, typing purchase > requisitions, waiting and waiting for the courier... X was > easily available via ftp. Bingo. NeWS was never open or available. >- Sun must have done something to alienate Adobe, why else would > Adobe work so closely with NeXT to develop Display Postscript. Maybe, maybe not. Someone from Adobe should comment. The comments I heard from (friends at) Adobe was that they consider PostScript to be a page description language (i.e. fairly special puprpose) and that NeWS added a lot of warts to it to try to make it a general purpose programming language. For what it's worth, I heard some grumbles about some of the additions NeXT made to postscript as well. I have no idea what Adobe's official position (if it even has one). >While NeWS is probably the "best" windowing system today, Sun's >poor handling of the early marking and vendor/customer relations >has much to do with the success of X. I (and many people) disagree with the statement that NeWS is the "best" windowing system today. >If Sun are still serious about NeWS (it still isn't clear that >they are), they should do a better job of marketing it, and an >even better job of playing nicely with other vendors in order >to promote greater industry support for NeWS. They might start >by making peace with Adobe (and apologising to SGI). Uh. Best of Luck. -- Erik
bmacinty@mud.uwaterloo.ca (Blair MacIntyre) (06/26/91)
>>>>> On 24 Jun 91 21:48:36 GMT, >>>>> In message <1991Jun24.214836.27386@zola.esd.sgi.com>, >>>>> erik@westworld.esd.sgi.com (Erik Fortune) wrote: >1) The PostScript model is far "better" than X. For example, if I > want my X application to display grey scale on a monochrome > display I have to encode all the dither maps and then manage > all the stipple switching myself. In PostScript I just set the > grey level and draw. Erik> Better for some things, worse for others. Rasterops and Erik> colormaps are real useful things for a lot of applictions. I think many people are arguing about NeWS based on old versions of it. NeWS has colormaps and allows them to be used in the obvious ways (see createcolormap, createcolorsegment). NeWS allows you to specify rasterops for it's graphics operations (see setrasteropcode) ie. Yes, it is possible to do XOR drawing (in response to some mail I received pertaining to this discussion, but have since lost) Erik> This argument ignores the added complexity Erik> of doing the event handling in the server (in terms of server size Erik> and performance) Which, on todays workstations, is not a real issue. IMO. Erik> and the hassle of debugging a program that is split across Erik> multiple machines and languages. Hastle? Hmmmm ... when there is a clear split of functionality between the interface and the rest of the application, it should _help_ with debugging. Erik> I still remember the arguments from (some) NeWS folks in the early Erik> days of X that it was absolutely impossible to get good Erik> interactive performance for things like rubber-banding and outline Erik> dragging without handling events in the server. On more than one Erik> occasion we'd go and demostrate perfectly acceptable tracking to Erik> these people only to hear them make the same claim in a different Erik> forum a week later. Absolutely impossible would be a stupid thing to say. However, I would agree that you would get better performance, IN GENERAL, by having things like rubber-banding in the server. Of course, I usually get satisfactory performance from my X stations. Then again, we have fast hardware and a fairly unloaded network. >3) The architecure of X is very primative from a systems aspect. > It's crazy the amount of low level issues you have to worry > about writing X applications (like if you don't handle your > events fast enough you make the server very upset). Erik> I've never run into this problem. Are your clients runnning on Erik> a particularly slow host? Xlib is low level -- it's supposed Erik> to be. Try one of the many toolkits available for X (InterViews, Erik> Andrew, etc). The fact remains that there is an enormous amount of activity happening in the server, and as a user I am often forced to use the toolkit that the application writer used. For example, the interface for a program I am writing using tk and tcl is forever fixed using the widget set of tk. I don't have to worry about the low level stuff, but it is still tucked inside that program. Now, by writing the same thing in NeWS, I can easily switch the toolkit, assuming that they are "compatible" ... ie. I switched from TNT2.0 to Tabwindows without having to change my application at all. All of my applications now have that same look and feel. The interface is consistent. Not so with my X applications. Erik> I'll steal a line from your posting: "If PostScript is so great, Erik> why is there now an OOPS extension." ... you answered your own question ... Erik> PostScript is a great page description language. As a general Erik> purpose programming language, I'll pass. So, there is an OOPS extension. Erik> Postscript is great for some things (generally for things that Erik> overlap with printers). For those things, you have Display Erik> Postscript. I wouldn't want to write a flight simulator in Erik> postscript, though. Well, I wouldn't either. But, I would have no objection to implementing the actually drawing in postscript ... you know, the interface, the part of a NeWS program that should be written in postscript. The number crunching stuff would be in C ... what's the big deal? Ever played acm (the X flight simulator) over a network? It's not exactly zippy, and I don't see how having the drawing done in postscript would be any worse. In fact, I can even imagine in being faster. The number crunching would be done on my server, and the drawing would be done on the various workstations (for each user). Multiprocessing is a great thing, after all. Erik> Because PostScript is good for some things, while X rendering Erik> is good for others. I'm not sure what a NeWS extension to Erik> X would be. Hmmm ... I have yet to see anything that X can do that NeWS can't. -- Blair MacIntyre, Computer Graphics Lab Dept. of Computer Science, University of Waterloo, Waterloo, ON, Canada, N2L3G1 {bmacintyre@{watcgl|violet|watdragon}}.{waterloo.edu|uwaterloo.ca}
jg@crl.dec.com (Jim Gettys) (06/26/91)
I knew I'd regret any comments :-). Remember that the decisions that decided NeWS vs. X were being made some years ago. The point about colormaps/rasterops stuff was true when the industry was making up its mind... That it has been fixed since is irrelevant to the discussion about why people went the way they did. More of an issue (and to my knowledge, still unsolved in NeWS w.o. X) PostScript has very poor semantics at the boundary between filled areas; the easiest example where this hurts badly is ECAD, where parts of a drawing must be able to be updated without disturbing adjacent areas. You must have a tie-breaking rule, and not fill both edges of a filled area. This is irrelevant when painting on paper, as the issue never even surfaces. Moral is: pixels on screens aren't quite small enough to take the view that you can't notice each and every pixel touched; the fact is, you can. At 300 dpi, where PostScript was designed, you can (usually) get away with it. And I'm not going to get sucked into a more general discussion, particularly on general systems design philosophy; if you want more detail about our opinions, go read the special issue on X in Software Practice and Experience that just came out recently (I got my copy last week), though this doesn't go into specific criticisms of NeWS (afterall, it is papers about X, not critique of NeWS). You'll have lots of fun with it; it goes into all the things we really did wrong, given the general design point. Availability was the other major issue. - Jim Gettys
eric@tangerine (& Kolotyluk) (06/26/91)
>Straw man (IMO). This argument ignores the added complexity >of doing the event handling in the server (in terms of server size >and performance) and the hassle of debugging a program that is >split across multiple machines and languages. There are tradeoffs >either way -- doing everything in the server not such a clear win. If the complexity of NeWS is too much to handle in the window server, perhaps we should abandon X and go back to dumb ASCII terminals. I think technology is always going to get more complex in order to provide more function. As far as doing everything in the window server goes, not everything should go into the window server, but at least with NeWS you have a choice of what goes where. Yes, there can be challenges writing and debugging spit applications, but, like writing multithreaded applications, often the benefits in functionality are worth the challenges. >I still remember the arguments from (some) NeWS folks in the early >days of X that it was absolutely impossible to get good interactive >performance for things like rubber-banding and outline dragging >without handling events in the server. On more than one occasion >we'd go and demostrate perfectly acceptable tracking to these people >only to hear them make the same claim in a different forum a week >later. While I would never go so far as to say that anything was absolutely impossible, I think the issue of things like rubber-banding is not so straigtforward. Sure X can support rubber banding and other animation effects, but at what cost in terms of other resources like network bandwith and systems interrupt handling response time? I'm primarily a network person by background so I'm away of all sorts of network issues that most people (especially the X developers) may have taken for granted. My biggest concerns about X have been related to how well it can scale to larger and more diverse types of networks. X is extremely waistful of network bandwith by nature of its architecture. >I've never run into this problem. Are your clients runnning on >a particularly slow host? Xlib is low level -- it's supposed >to be. Try one of the many toolkits available for X (InterViews, >Andrew, etc). Is a Sun SPARCstation 1+ a slow client/server? One program I have, which performs a lot of stipple creation/changing seems to be able to overwhelm the server side and produce glitches. When delays are inserted into the code, the server side seems to keep ok. I'm running OpenWindow by the way. At Interop last year, one of tutorials on X programming stressed several of the systems issued to be aware of in overwhelming the server and not responding quick enough to the server. Is Xview considered a toolkit? Again the issue is an architectural one, programming in an X environment is like programming in an MS-DOS environment, sure you can hide the system with higher layer interaces, but that result in a more complex solution in the long run. >I'll steal a line from your posting: "If PostScript is so great, why is >there now an OOPS extension." PostScript is a great page description >language. As a general purpose programming language, I'll pass. I think the reason there's an OOPS extension to PostScript (in NeWS) is to make the PostScript programming environment an even better one. While I wouldn't want to implement a database in PostScript, I wouldn't want to write a window system in Cobol either. The point is language applicabilty. One of the features I especially like about NeWS is being able to try out new ideas interactively through psh or pageview. I find prototyping can go much faster in NeWS (via PostScript) than in X (via C). >Postscript is great for some things (generally for things that overlap >with printers). For those things, you have Display Postscript. I >wouldn't want to write a flight simulator in postscript, though. Right, I wouldn't want to write a fligh simulator in PostScript either, but you could (I think Sun's NeWS lunar lander is an example of this). >Because PostScript is good for some things, while X rendering >is good for others. I'm not sure what a NeWS extension to >X would be. Since Display PostScript doesn't support OOPS and server-side event handling, I'd want those sorts of things in in a NeWS extension to X. Actually, what I really want is for OpenWindows to support Display PostScript, then I can have a window server that supports all the important applications. >This conspiracy theory nonsense has been around for a long, >long time and it's pure garbage. I worked for IBM (doing X -- in fact, >I was the only person writing servers at IBM for a number of months) at >the time and IBM was dragged kicking and screaming into X. X was written >and promoted by engineers in universities and at a number of companies. I agree. I was trying to add some sarcasm to the conspiracy theory. Thanks for the insight into IBM. >X gained support because it had a relatively large user community, was >demonstrably portable, and was adequate for most of the applications >people wanted to write. Also, people were getting tired of having >20 different ways to do graphics and wanted to settle on something >(anything!) that was good enough to get the job done. X was a known >quantity and was good enough. The point I agree with most strongly is that X was good enough for most people. Most programmers just wanted to get on with programming. Most marketing types just wanted something to market. The problem with "good enough" arguments is that IBM PCs and MS-DOS are "good enough." >The amusing and annoying thing about this consipiracy crap is that >it always seemed to me (back then) that NeWS was an attempt to >derail X because Sun couldn't stand having a widespread standard >they hadn't originated. It seemed to me that Sun was petulant >about the existence of something they didn't control. I can't say whether Sun were petulant or not, but just because someone has an aggrevating personality doesn't mean they don't have some good ideas. >At the time it seemed (to me) like we had engineers from a surprisingly broad >collection of companies and universities cooperating to produce a window >system and >then you had Sun off on the sidelines jumping up and down and screaming. Good point. Sun certainly weren't much a team player in the window systems community. >I've since gotten to know some of the people involved (from Sun) better, >and tempered my opinions somewhat. Since I started using X windows, I've tempered my views somewhat too. >Get a few things straight, though. X was *NOT* a reaction to NeWS. >Project Athena was *NOT* commisioned to create X. IBM in >particular did *NOT* even like X a whole lot. I wasn't trying to promote those ideas, but thanks for the clarification for others who thought I might be. >Maybe, maybe not. Someone from Adobe should comment. The >comments I heard from (friends at) Adobe was that they consider >PostScript to be a page description language (i.e. fairly special puprpose) >and that NeWS added a lot of warts to it to try to make it a general >purpose programming language. For what it's worth, I heard some >grumbles about some of the additions NeXT made to postscript as well. >I have no idea what Adobe's official position (if it even has one). From what I've heard, Adobe never realized the importance of PostScript in display applications either. >I (and many people) disagree with the statement that NeWS is the >"best" windowing system today. That's what these discussions are for; for people to make their cases. Thanks for sharing yours.
cwpjr@cbnewse.cb.att.com (clyde.w.jr.phillips) (06/26/91)
In article <594@mitech.com>, gjc@mitech.com writes: > In article <91164.101625BROEKHVN@QUCDN.QueensU.CA>, BROEKHVN@QUCDN.QueensU.CA (Kevin Broekhoven) writes: > > > > In the May SunWorld, Scott McNeally > > gives an interview where he compares "NeWS to X11" as "Unix to Dos", with > > the implication that in some number of years, NeWS will be displacing X11. > > Fantastic anology, perhaps. But an absurd prediction. > The future means throwing more mips at existing, hidebound, nothing new under the sun software... Therefore the more the software can shine with more mips the more likely it will do better in the *future*... I think diplay postscript will DO BETTER with these mips than "X"... Clyde