gwyn@smoke.brl.mil (Doug Gwyn) (04/10/91)
In article <128236@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >Another thing I hate about X is the protocol. To my mind the worst problem with X is that to get anything at all done, two processes must communicate back and forth through the protocol bottleneck. This inherently limits the interactivity attainable using typical hardware (Sun workstations, for example) to levels below my personal standards for interactive graphics. To give a specific example, when I borrow the use of somebody's Sun running an X window manager, I often fail to "hit" pop-up menu items when I select them. That's because I'm used to the responsiveness of the Blit family of terminals, where the interaction is entirely under control of a single process with direct access to the terminal handware. What seems like a natural expectation for selection from menus becomes more difficult under X, where I have to give the protocols time to trickle back and forth while I'm making the menu seclection.
gamiddle@watmath.waterloo.edu (Guy Middleton) (04/11/91)
X does suck, but its popularity seems inevitable, since it doesn't cost any money. Other, better systems could have become the de facto standard, had they been as cheap. Of the set of free, reasonably portable, reasonably hardware-independent window systems that have been available since workstation hardware became affordable, X seems to be the best. Of course, that set has only one member. -Guy Middleton, University of Waterloo gamiddleton@watmath.waterloo.edu (+1 519 885 1211 x3472) gamiddleton@watmath.uwaterloo.ca
rbj@uunet.UU.NET (Root Boy Jim) (04/11/91)
In article <15785@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <128236@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >>Another thing I hate about X is the protocol. > >To my mind the worst problem with X is that to get anything at all done, >two processes must communicate back and forth through the protocol >bottleneck. Yeah. I already complained that the device independence is in the wrong place (in the client rather than in the server where it belongs). I forgot to add that device control is in the wrong place as well. With Blits and NeWS, you can download code to handle certain events locally. >This inherently limits the interactivity attainable using >typical hardware (Sun workstations, for example) to levels below my >personal standards for interactive graphics. To give a specific >example, when I borrow the use of somebody's Sun running an X window >manager, I often fail to "hit" pop-up menu items when I select them. But what's worse than sluggish response is the indeterminence of type-ahead and mouse-ahead operations. There is no guarantee that a client won't open a window right where you're typing or mousing and steal your input. With local device control, these operations can be synchronized. >That's because I'm used to the responsiveness of the Blit family of >terminals, where the interaction is entirely under control of a single >process with direct access to the terminal handware. What seems like >a natural expectation for selection from menus becomes more difficult >under X, where I have to give the protocols time to trickle back and >forth while I'm making the menu seclection. This was one of the motivations for Mark Weiser's pie menus. Even if the windowing system is slow, you can click a button, move in a certain direction (say, northwest) and release, even before the menu is drawn. -- [rbj@uunet 1] stty sane unknown mode: sane
fpb@ittc.wec.com (Frank P. Bresz) (04/12/91)
In article <1991Apr10.194243.12882@watmath.waterloo.edu> gamiddle@watmath.waterloo.edu (Guy Middleton) writes: >X does suck, but its popularity seems inevitable, since it doesn't cost any >money. Other, better systems could have become the de facto standard, had >they been as cheap. Of the set of free, reasonably portable, reasonably >hardware-independent window systems that have been available since >workstation hardware became affordable, X seems to be the best. Of course, >that set has only one member. Well I for one must disagree with the X sucks. I personally like X. I am much happier than I was with sunview. I use GNU-Emacs in X mode and I run Xterm all of the time. I am primarily a text man so I can't speek to well for the graphics. I think the fact about the only set of free software is true. This is the reason I run it. I can't see shelling out good $$$ for something like MOTIF when I get much faster response from the stuff from MIT. I won't even discuss OpenWindows from Sun sans to say it is slow and uncustomizable aside from that I don't know why I don't like it. Lord John Whorfin -- | () () () | Frank P. Bresz | Westinghouse Electric Corporation | \ /\ / | fpb@ittc.wec.com | ITTC Simulators Department | \/ \/ | uunet!ittc!fpb | Those who can, do. Those who can't, simulate. | ---------- | +1 412 733 6749 | My opinions are mine, WEC don't want 'em.
rbj@uunet.UU.NET (Root Boy Jim) (04/13/91)
In fpb@ittc.wec.com (Frank P. Bresz) writes: > > Well I for one must disagree with the X sucks. I personally like >X. I am much happier than I was with sunview. I use GNU-Emacs in X mode >and I run Xterm all of the time. I am primarily a text man so I can't >speek to well for the graphics. You just haven't learned enuf about X to hate it yet. If all you do is use xterms and other text oriented stuff, then X is somewhat better than SunView simply because it is more flexible. And it runs over the network, which is an advantage as long as the destination is close. For a slew of good reasons why X is bad, read the introduction to NeWS documents from Sun. To sum the up briefly: X uses the wrong imaging model and device control is in the wrong place. X does have some nifty features. Treating widgets as objects probably works better in an object oriented language. Device independence, while done wrong, is more or less accomplished in a portable way. And a networking windowing system is definitely a step in the right direction. > I think the fact about the only set of free software is true. This >is the reason I run it. I can't see shelling out good $$$ for something >like MOTIF when I get much faster response from the stuff from MIT. > > I won't even discuss OpenWindows from Sun sans to say it is slow >and uncustomizable aside from that I don't know why I don't like it. Both MOTIF and OpenWindows are basicly the same thing: icing on the cake, which is X. I really don't know the difference either, however, any program can just use X or any other toolkit directly. -- [rbj@uunet 1] stty sane unknown mode: sane
cgy@cs.brown.edu (Curtis Yarvin) (04/13/91)
In article <128451@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: > >Both MOTIF and OpenWindows are basicly the same thing: icing on >the cake, which is X. I really don't know the difference either, >however, any program can just use X or any other toolkit directly. A minor misconception; what you are thinking of is Open Look. OpenWindows is Sun's amalgamation of X and NeWS. curtis
root@NEXTSERVER.CS.STTHOMAS.EDU (Max Tardiveau) (04/13/91)
The problem with the imaging model of X is, in my opinion, the biggest flaw. Why on earth did someone have to create a totally new, and for all practical purposes, terribly inadequate, imaging model ? NeWS and NextStep did the right thing : they chose an existing, widely used model (PostScript). It does require more power to run, but is so much better, and machines are getting more powerful every day anyway. Having used both NeWS and NextStep, I can assure anyone that the power available is simply overwhelming compared to X. Now, because some moron decided he wanted to have his own imaging system, we're going to be stuck with X for years, until either it is so vastly enhanced that it is not X as we know (and hate) it, or until people get sick of it and move to a real system. It doesn't have to be PostScript, but PostScript works very nicely. Just my $0.02 worth(less ?). --------------------------------------------------------------- Max Tardiveau Department of Computer Science University of St.Thomas St.Paul, MN 55105 Internet : m9tardiv@cs.stthomas.edu --------------------------------------------------------------- "You can create your own opportunities this week. Blackmail a senior executive."
mjr@hussar.dco.dec.com (Marcus J. Ranum) (04/14/91)
root@NEXTSERVER.CS.STTHOMAS.EDU (Max Tardiveau) concisely states the problem: >[...] (PostScript). It does require more power to run, but is >so much better, and machines are getting more powerful every day >anyway. This is the issue. Window systems already hog to much power. "Machines are getting more powerful every day anyway" - and spending that power interpreting PostScript (best done by dedicated hardware rather than my expensive RISC workstation) instead of crunching the numbers I want crunched is not good. mjr.
bzs@world.std.com (Barry Shein) (04/14/91)
> > This is the issue. Window systems already hog to much power. > > "Machines are getting more powerful every day anyway" - and >spending that power interpreting PostScript (best done by dedicated >hardware rather than my expensive RISC workstation) instead of crunching >the numbers I want crunched is not good. > >mjr. Of course, and thereby we head onto what Sutherland described as the graphics "Wheel of Reincarnation". The next fad, no doubt, will be something X-terminal-like to use with your headless workstation so the workstation can do its work and the "monitor" can run most of the window system. Intelligent monitors. Then someone will add a little more processing power to this "smart monitor", a little more memory expansion, a SCSI port...and gee, we can dispense with the workstation! Until we want to offload the graphical interface from the "smart monitor"... I think Unix is already well into this cycle (think of sitting a Sun/SLC or X-terminal on top of your workstation and removing the monitor.) I assume it's just a matter of time before "smart monitors" running most of Windows show up for PC's. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
lm@slovax.Eng.Sun.COM (Larry McVoy) (04/14/91)
In article <9104131319.AA01023@.nextserver.cs.stthomas.edu.cs.stthomas.edu..> root@NEXTSERVER.CS.STTHOMAS.EDU (Max Tardiveau) writes: >The problem with the imaging model of X is, in my opinion, the biggest >flaw. > >system, we're going to be stuck with X for years, until either it is >so vastly enhanced that it is not X as we know (and hate) it, or until >people get sick of it and move to a real system. I think that people will tend to agree with you over time. Very few understand what it is you are saying - they see xterms and network windows and think X is great. When they see that they can work on a fast machine and display on their workstation, they are very happy. Especially when the server is a Cray and the workstation is a Sun or MIPS. The problem is that "technically right" != "business right". People are far less likely to write apps for NeWS or NextStep because X is the dominant player in the WS market (if Motif vs Openlook wars continue, that might kill X, though. Interesting thought even if unlikely.) I suspect that we are stuck with X. X will evolve. In 5 years, there will be this thing called X, big and ugly, that does X type imaging and has Postscript imaging glommed in as well. Sigh. Like Ritchie said: sometimes, when you fill a void it still sucks. --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com
root@NEXTSERVER.CS.STTHOMAS.EDU (Max Tardiveau) (04/14/91)
In article <1991Apr13.173834.14543@decuac.dec.com> mjr@hussar.dco.dec.com > root@NEXTSERVER.CS.STTHOMAS.EDU (Max Tardiveau) concisely states the problem > >[...] (PostScript). It does require more power to run, but is > >so much better, and machines are getting more powerful every day > >anyway. > > This is the issue. Window systems already hog to much power. > > "Machines are getting more powerful every day anyway" - and > spending that power interpreting PostScript (best done by dedicated > hardware rather than my expensive RISC workstation) instead of crunching > the numbers I want crunched is not good. This is obviously a matter of opinion. While I agree with you that windowing systems take a large amount of power, I would argue that it is not too much. I like having nice graphics on my workstation, and I like to have responsive windows. And, like most people, I use only a small portion of the processing power of my workstations (show me a Sparcstation that's 100% busy 100% of the time. There are probably a few, but not a whole lot). I think it's worth it. If you need all the power you can get, there are alternatives to X. On a Sun, you can run SunView, which takes relatively little power to run. --------------------------------------------------------------- Max Tardiveau Department of Computer Science University of St.Thomas St.Paul, MN 55105 Internet : m9tardiv@cs.stthomas.edu --------------------------------------------------------------- "Ban the bomb. Save the world for conventional warfare."
csu@alembic.acs.com (Dave Mack) (04/14/91)
In article <1991Apr10.194243.12882@watmath.waterloo.edu> gamiddle@watmath.waterloo.edu (Guy Middleton) writes: >X does suck, but its popularity seems inevitable, since it doesn't cost any >money. Other, better systems could have become the de facto standard, had >they been as cheap. Of the set of free, reasonably portable, reasonably >hardware-independent window systems that have been available since >workstation hardware became affordable, X seems to be the best. Of course, >that set has only one member. Not quite. Remember a very nice package that was posted to c.s.u a few years back called MGR? Steve Uhler at Bell Labs claimed that an updated version of that was going to come out eventually, but I've seen no sign of it. Pity. [Thinking back, though, I guess MGR only ran on Suns, so maybe that doesn't qualify as hardware independence.] -- Dave Mack
ken@dali.cc.gatech.edu (Ken Seefried iii) (04/15/91)
In article <1991Apr14.143159.3560@alembic.acs.com> csu@alembic.acs.com (Dave Mack) writes: > >[Thinking back, though, I guess MGR only ran on Suns, so maybe that >doesn't qualify as hardware independence.] > Actually...it has been ported to Xenix and, if I am not mistaken, the 3b1's funky little bitmapped display. The porting requirements, as I recall (it's been quite a while since I looked at it) seemed quite minimal. Personally, I think it's a fine piece of work. -- ken seefried iii ken@dali.cc.gatech.edu "If 'ya can't be with the one you love, honey, love the one you're with..."
flanagan@lisbon.stat.washington.edu (Jim Flanagan) (04/15/91)
In article <544@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM (Larry McVoy) writes: >In article <9104131319.AA01023@.nextserver.cs.stthomas.edu.cs.stthomas.edu..> root@NEXTSERVER.CS.STTHOMAS.EDU (Max Tardiveau) writes: >The problem is that "technically right" != "business right". People >are far less likely to write apps for NeWS or NextStep because X is the >dominant player in the WS market (if Motif vs Openlook wars continue, >that might kill X, though. Interesting thought even if unlikely.) > >I suspect that we are stuck with X. X will evolve. In 5 years, there >will be this thing called X, big and ugly, that does X type imaging and >has Postscript imaging glommed in as well. Sigh. Like Ritchie said: >sometimes, when you fill a void it still sucks. White man build big fire, stand far away. Jim Flanagan #ifdef OFFENSIVE flanagan@stat.washington.edu static char disclaimer[] = NULL; System Programmer #endif UofW Statistics main(){while(fork());} /* terminate account */
khera@cs.duke.edu (Vivek Khera) (04/16/91)
In article <1991Apr14.143159.3560@alembic.acs.com> csu@alembic.acs.com (Dave Mack) writes: In article <1991Apr10.194243.12882@watmath.waterloo.edu> gamiddle@watmath.waterloo.edu (Guy Middleton) writes: [stuff deleted] >workstation hardware became affordable, X seems to be the best. Of course, >that set has only one member. Not quite. Remember a very nice package that was posted to c.s.u a few years back called MGR? Steve Uhler at Bell Labs claimed that an updated version of that was going to come out eventually, but I've seen no sign of it. Pity. [Thinking back, though, I guess MGR only ran on Suns, so maybe that doesn't qualify as hardware independence.] actually, the libraries could be compiled on any machine, similar to the way the X library can. the hardware dependent routines numbered something like 6 functions. all in one file, if i recall correctly (even if it were more, it was still a small portion). i even got the MGR libraries to compile on a BBN GP-1000 parallel processor running a home-brewed version of their OS. worked like a charm drawing my graphics on my Sun 3. i'd like to see MGR updated... even though X is plenty fast on my SPARC. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vick Khera, Gradual Student/Systems Guy Department of Computer Science ARPA: khera@cs.duke.edu Duke University UUCP: ...!mcnc!duke!khera Durham, NC 27706 (919) 660-6528
dovich@cadence.com (Steven J. Dovich; x272) (04/16/91)
Let's not ignore our history here...
PostScript does not pre-date image processing technology. And the
imaging model used by X is the same one used by the bulk of image
processing and synthesis algorithms. Hence that code (and user base)
benefits most from the X imaging model and not the PostScript one.
PostScript provides an abstraction. That is usually a good thing. Not
every situation calls for the same abstractions. The real trick is
knowing the limitations of each of the relevant abstractions.
To paraphrase the old Mounds candy bar commercial...
Sometimes you feel like PostScript... and sometimes you
don't.
Should all applications pay because some might benefit? And to tie
this point back into the original discussion, how would using the
PostScript imaging model contribute to reducing the cost penalties of
software? Or would it encourage the proliferation of applications that
ignore the cost of computing resources they consume?
--
Steven J. Dovich <dovich@cadence.com>
Cadence Design Systems/ACAE Div.
2 Lowell Research Center Dr
Phone: (508) 934-0272 Lowell, MA 01852-4995allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/16/91)
As quoted from <FPB.91Apr12083527@ittc.ittc.wec.com> by fpb@ittc.wec.com (Frank P. Bresz):
+---------------
| I think the fact about the only set of free software is true. This
+---------------
Fact? So who's about to raid my pocketbook for the copy of MGR I'm porting to
SCO Unix?
++Brandon
--
Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200
Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed)
America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OHguy@auspex.auspex.com (Guy Harris) (04/16/91)
> I won't even discuss OpenWindows from Sun sans to say it is slow >and uncustomizable What can you customize in X that you can't customize in Open Windows? (I won't argue the "slow" part; I've found that, if I've been doing anything other than running rlogged-in terminal emulators on my machine - you know, stuff such as *compiles* - OW's even more sluggish at raising and lowering windows, switching focus, and the like than MIT X is - and that's using the *same* window manager, "twm", in both cases. I wonder how much of that can be blamed on the window manager? It's certainly customizable. Hoo boy, is it customizable. I could probably live with a *less*-customizable window manager if it had a smaller working set....)
thad@public.BTR.COM (Thaddeus P. Floryan) (04/16/91)
In article <1991Apr14.143159.3560@alembic.acs.com> csu@alembic.acs.com (Dave Mack) writes: >[...] >[Thinking back, though, I guess MGR only ran on Suns, so maybe that >doesn't qualify as hardware independence.] MGR also operates on 3B1 (aka 7300 aka UNIXPC) systems. Sources are available in the osu-cis archives and from other sites around the USA. MGR is quite popular among the members of the Silicon Valley AT&T UNIX Users' Group. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
gwyn@smoke.brl.mil (Doug Gwyn) (04/16/91)
In article <1991Apr13.173834.14543@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >spending that power interpreting PostScript (best done by dedicated >hardware rather than my expensive RISC workstation) instead of crunching >the numbers I want crunched is not good. There is no need to have your user interface crunching numbers. Indeed, the separation of such functions is much of what Plan 9 is all about.
klaus@cnix.uucp (klaus u schallhorn) (04/16/91)
In article <26333@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: >In article <1991Apr14.143159.3560@alembic.acs.com> csu@alembic.acs.com (Dave Mack) writes: >> >>[Thinking back, though, I guess MGR only ran on Suns, so maybe that >>doesn't qualify as hardware independence.] >> > >Actually...it has been ported to Xenix and, if I am not mistaken, the >3b1's funky little bitmapped display. The porting requirements, as I >recall (it's been quite a while since I looked at it) seemed quite >minimal. > Perhaps its time comes when sun drops sunview and attempts to take away unix by forcing me to use OpenBloat, a day I dread. So where is the latest version of MGR. Think it's time it get resurrected. klaus -- George Orwell was an Optimist
mjr@hussar.dco.dec.com (Marcus J. Ranum) (04/17/91)
rhealey@digibd.com (Rob Healey) writes: > [...] if it can run on as many different architectures and > platforms as X, can be run over any 8 bit clean data stream > and has all the functionality of X without all the bulk. The requirement of "all the functionality of X" is open to debate. All of X's wonderful functionality is one reason some of us think it's a mess. mjr.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/17/91)
As quoted from <1991Apr14.143159.3560@alembic.acs.com> by csu@alembic.acs.com (Dave Mack): +--------------- | Not quite. Remember a very nice package that was posted to c.s.u | a few years back called MGR? Steve Uhler at Bell Labs claimed that | an updated version of that was going to come out eventually, but I've | seen no sign of it. Pity. | | [Thinking back, though, I guess MGR only ran on Suns, so maybe that | doesn't qualify as hardware independence.] +--------------- The README mentioned a number of versions. Check mgr.bellcore.com for the official archive. And I'm tracing down the last bugs/buglets in a re-port to SCO Xenix and SCO Unix --- the official port exists but has problems (like a nasty race condition in a certain piece of code that causes it to dump core just at the time you need its capabilities most...). I have hopes that that port will move to other 386 Unixes fairly easily, although with SCO one can never count on portability. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
karish@mindcraft.com (Chuck Karish) (04/18/91)
In article <544@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM (Larry McVoy) writes: >The problem is that "technically right" != "business right". People >are far less likely to write apps for NeWS or NextStep because X is the >dominant player in the WS market (if Motif vs Openlook wars continue, >that might kill X, though. Interesting thought even if unlikely.) People don't write apps for NeWS or NeXTStep because there's not enough return for the effort; those systems aren't available on enough workstations. Writing to an X-based window interface gives developers a broader market. My perception is that Motif is winning the "war" and that OpenLook will persist as a third proprietary offering from Sun (note Bill Joy's comment that OpenLook is a "de facto standard" because of Sun'smarket share). Does this make any sense? Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
andys@ulysses.att.com (Andy Sherman) (04/19/91)
In article <671916336.14801@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >In article <544@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM (Larry McVoy) writes: >My perception is that Motif is winning the "war" and that OpenLook >will persist as a third proprietary offering from Sun (note Bill >Joy's comment that OpenLook is a "de facto standard" because of >Sun'smarket share). Does this make any sense? I'm not in the trenches, so I don't know who, (*IF ANYBODY*) is winning the GUI war. However, OpenLook(TM) is *not* a proprietary offering of Sun. OpenLook is an interface specification that was jointly published by AT&T and Sun. The trademark is an AT&T (now USL) property, not a Sun property. You can buy OpenLook toolkits from either AT&T/USL or Sun. OpenWindows, on the other hand, is a combined X11R4/NeWS server sold by Sun. I believe the licensing terms are less draconian than for NeWS. Yes, there are ISVs using OpenLook. For example, the spreadsheet we use in my lab (20/20) is OpenLook, and no, that wasn't the reason we bought it, although it was a plus. For ISVs who want to hedge their bets, there is an Object Interface library (developed by Solbourne, but I think the AT&T C++ people may have picked it up as well) that allows applications to determine their flavor at run time. Andy Sherman/AT&T Bell Laboratories/Murray Hill, NJ AUDIBLE: (201) 582-5928 READABLE: andys@ulysses.att.com or att!ulysses!andys What? Me speak for AT&T? You must be joking!
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (04/20/91)
root@NEXTSERVER.CS.STTHOMAS.EDU (Max Tardiveau) writes: | This is obviously a matter of opinion. While I agree with you that | windowing systems take a large amount of power, I would argue that | it is not too much. I like having nice graphics on my workstation, | and I like to have responsive windows. How many people prefer nice graphics to more responsiveness? Given X cpu horsepower, it must be divided between responsiveness and pretty pictures somehow. Personally, I'd happily trade some of the pretty pictures for faster performance (especially application startup). X11 insists that I take most of the overhead for potential pretty pictures even if I never use them, which is annoyingly obnoxious. | And, like most people, I use only a small portion of the processing | power of my workstations (show me a Sparcstation that's 100% busy 100% | of the time. There are probably a few, but not a whole lot). Peak available CPU is also important -- probably more important than sustained CPU in terms of user satisfaction (when my machine dies during a compile I really notice -- far more than I notice the constant overhead various daemons take). I suspect, although I have no numbers to back this up, that most workstations have low CPU demands most of the time, but with very high peaks (more or less 100% utilization) when things do peak. -- "This will be dynamically handled, possibly correctly, in 4.1." - Dan Davison on streams configuration in SunOS 4.0 cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
seb@ram.Sun.COM (Shannon Bushman - Sun SVN SE) (04/20/91)
I am sick of this discussion. If you don't like X, don't use it. If you have a complaint about X post it in the correct group!! Send your constructive criticism to someone who will do something! This is NOT the place for this discussion. Why do we insist on wasting the bandwidth with this drival? Spare me the flames >/dev/null S
gwyn@smoke.brl.mil (Doug Gwyn) (04/21/91)
In article <1625@west.West.Sun.COM> seb@ram.Sun.COM (Shannon Bushman - Sun SVN SE) writes: >Send your constructive criticism to someone who will do something! It's too late to fix X11's design. >This is NOT the place for this discussion. Sure it is -- we can learn from the mistakes that were made in other projects when we design a new one.
peter@ficc.ferranti.com (peter da silva) (04/26/91)
In article <14619@ulysses.att.com>, andys@ulysses.att.com (Andy Sherman) writes: > I'm not in the trenches, so I don't know who, (*IF ANYBODY*) is > winning the GUI war. What I want to know is why the "GUI war" is even considered worth discussing? I mean, who cares which marketing gimmick "wins"? It's about as important in the scheme of things as whether Bud Dry or Bud Light wins Bud Bowl 2. > For ISVs who want to hedge their > bets, there is an Object Interface library (developed by Solbourne, > but I think the AT&T C++ people may have picked it up as well) that > allows applications to determine their flavor at run time. So when does this get moved from the library to the server where it belongs? -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"