rls@onondaga.steinmetz.ge.com (Roderick Sprattling) (01/31/89)
In the second article referenced above, Paul Vojta writes: >As long as we are on the subject of wish lists for additions to the server, >why not allow the client to send a font to the server 'on the fly'? This >would at least help in the writing of dvi previewers. And this reflects my chief beef with the idea of X terminals. Because a terminal-based X server has no secondary storage, the manufacturer must place resource data in static memory. This ensures two things: 1. The limited memory in a terminal cannot contain all resource data. Some get EEPROM'd, some don't; 2. The terminal-based server has no provisions for incorporating new or revised resource data, save chip swaps. A useful X server should satisfy all reasonable resource requests of a client. Unless it's configured with disks (a high-density floppy and 20-meg drive should be plenty) and provides plenty of storage (disk or memory) for client data caching, then a terminal is not, in my mind, an approprite platform for X. Comments and rebuttals welcome. -- --------------------------------------------------------------------- Rod Sprattling rls@onondaga.steinmetz.ge.com uunet!steinmetz!onondaga!rls rls%onondaga.tcpip@ge-crd.arpa rls%onondaga@steinmetz.UUCP ---------------------------------------------------------------------
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (01/31/89)
I tend to agree. A local group is thinking of getting X server terminals. Unless they can swap resources (i.e. fonts) to backing store, it's not clear that they're very useful. e.g., when I use texx2, which uses X fonts instead of bitmaps, my server suddenly grows to 2.5 or 3.5Mb, depending on the number of fonts I'm using at once.
klee@daisy.UUCP (Ken Lee) (02/01/89)
Clearly, due to hardware limitations (memory, CPU, screen resolution, screen depth, etc.), X terminals are not going to be able to work (reasonably or at all) with some X applications. This is probably true, however, of almost all workstations that run X. There's always room for a bigger, faster machine. For the price, though, I see X terminals replacing alot of the PC's you currently find in large organizations. You can do fancy word processing, data base access, most software development, etc. from an X terminal. This gives you all the power of your UNIX hosts (including access to your UNIX network and file servers), through a low cost, multi-window, graphics terminal. They're not for everyone, but I think they are appropriate for many people. Ken Lee -- klee@daisy.uucp Daisy Systems Corp., Interactive Graphics Tools Dept.
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (02/01/89)
The X terminal business is still in its infancy. There's room for a fair amount of improvement and innovation. But, like any piece of hardware, X terminals will be appropriate only to some specific market. ASCII terminals don't do lots of things, but there are millions of them out there. I believe X terminals will be reasonable for lots of people. If you try to increase the capabilities of an X terminal too far too fast (e.g. putting a disk on it), there won't be a sufficient price difference between it and a workstation and people will buy a workstation instead. Most X terminals being built today are using some mechanism (ftp, tftp, NFS) for access to non-resident fonts, and punt fonts when no longer in use. Improving this in terms of caching (parts of) fonts needs to be done, as well as regularizing the access method. There is work underway in the X Consortium in this area. Some thinking about paging over the net has also gone on.
nobody@tekecs.TEK.COM (-for inetd server command) (02/02/89)
In article <RLS.89Jan30114845@onondaga.steinmetz.ge.com> rls@onondaga.steinmetz.ge.com (Roderick Sprattling) writes: ... quoted material deleted ... >And this reflects my chief beef with the idea of X terminals. > >Because a terminal-based X server has no secondary storage, the manufacturer >must place resource data in static memory. Why can't an X-terminal have secondary storage? Just because it doesn't run some form of Unix(c), doesn't preclude it from having secondary storage of some sort. Stank US Mail: Stan Kalinowski, Tektronix, Inc. Information Display Group, Interactive Technologies Division PO Box 1000, MS 61-028, Wilsonville OR 97070 Phone:(503)-685-2458 uucp: {ucbvax,decvax,allegra,uw-beaver}!tektronix!orca!stank
ed@lupine.UUCP (Ed Basart) (02/02/89)
1. Wish to have on the fly font service. 2. Wish to have more memory. The issue of on the fly font service is just beginning to be addressed by the consortium. There was a one day workshop last week just after the X technical conference. The idea is to build full-fledged font servers that can render and download any or all of a font (with all the appropriate license charges) to a server on the network. Now, this is a ways off in the future (probably beyond release 4), so for now, you'll have to settle for the available services. What server vendors are providing is downloading of a requested font using tftp or NFS. The fonts have to be lying about directories that xset can point to, and need to be in .snf format. This service appears to be usable. Regarding the wish for more memory, antiquated rotating devices and such, that's just what the client/server computer market (and the X model) calls for. The idea is to have a low cost, but high resolution "station" (not merely a terminal), that uses the network for services. If one wants access to Gbytes of files, bitmaps, icons and applications, that's what those monstrous "file server" machines churning away in the air-conditioned booths are for. It's then the job of the people in the station/server research labs to make this model become practical. We have the tools with NFS and its RPC mechanism to make this work.
ed@lupine.UUCP (Ed Basart) (02/02/89)
may be possible to make it work. The sample X server does provide a font caching mechanism that requires only the currently used font to be present. This won't help much if programs like texx2 actually use 3.5 MB of font information. What may help is the idea of caching only the glyphs (? I hope that's the right term), so if you're only using 5 characters out of a set of 5000, you can get all that you want for only 1% of the memory resource. This is one of the ideas kicking around for X font service, I can not claim credit for it.
lawrence@jarsun1.UUCP (mark lawrence) (02/07/89)
ed@lupine.UUCP (Ed Basart) wrote: } ... It's then } the job of the people in the station/server research labs to make this } [client/server] model become practical. We have the tools with NFS and } its RPC mechanism to make this work. And higher bandwidth networks to act as glue to make it practical for the interactive user are on the way...
jensen@gt-eedsp.UUCP (P. Allen Jensen) (02/07/89)
Many of the X Terminal systems I have looked at (NCD in particular) can down-
load the server from another system. This would seem to be reasonable,
most X Terminals will be in networks with other systems that have disk,
processors, and other perpherials but no Graphics devices for running
X Windows. I think that the problem will be that if you want enough memory
to have a lot of fonts, the cost starts going up pretty fast. Add to that
a 19" monitor and the cost starts to get very close to that of a diskless
Apollo or Sun workstation. X Terminals seem to be a good way to go for
situations where multiple windows and good quality text display
is needed. For more sophisticated graphics applications (3-D, motion, video,
...) what you really still need is a workstation as none of the currently
available X Servers are capable of this.
--
P. Allen Jensen
Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332-0250
USENET: ...!{allegra,hplabs,ulysses}!gatech!gt-eedsp!jensen
INTERNET: jensen@gt-eedsp.gatech.edubzs@Encore.COM (Barry Shein) (02/17/89)
From: jensen@gt-eedsp.UUCP (P. Allen Jensen) >Many of the X Terminal systems I have looked at (NCD in particular) can down- >load the server from another system. This would seem to be reasonable, >most X Terminals will be in networks with other systems that have disk, >processors, and other perpherials but no Graphics devices for running >X Windows. I think that the problem will be that if you want enough memory >to have a lot of fonts, the cost starts going up pretty fast. Add to that >a 19" monitor and the cost starts to get very close to that of a diskless >Apollo or Sun workstation. Yes, but you're falling into the standard "diskless workstation" fallacy, that the disk behind that diskless is not going to cost anything. In fact you usually need around 24MB of disk, at least, just to boot the thing (8MB root, 16MB swap), if you need to support even a dozen users you better throw in the price of a server also so suddenly you've easily eaten an additional $50K of hardware, or once again the price of the workstations. Of course, the workstation is more powerful and it all depends on what you're really trying to support, but let's not fall into these questionable comparisons to make a point. The X terminals require some disk space and a system to boot off of and store fonts on but the resources involved is just not comparable, perhaps 5 or 10MB of disk space could support 100 or more of these terminals since it's only accessed once at boot (ok, it might get a little hairy after a power failure, but on average, and there will be some font accessing.) (Unfortunately at many places you really do get that kind of thinking, someone will go out and buy a diskless workstation and then wander around banging on doors demanding that someone do whatever is necessary to make it work, and/or act betrayed that their $3500 purchase is worthless. I think the sysadmins out there know what I'm talking about.) -Barry Shein, ||Encore||
david@torsqnt.UUCP (David Haynes) (02/17/89)
In article <611@gt-eedsp.UUCP> jensen@gt-eedsp.UUCP (P. Allen Jensen) writes: > >Many of the X Terminal systems I have looked at (NCD in particular) can down- >load the server from another system. This would seem to be reasonable, >most X Terminals will be in networks with other systems that have disk, >processors, and other perpherials but no Graphics devices for running >X Windows. I have a problem with this. With vendors such as Oracle coming out with X-based tools (CASE in this example) X terminals will be much more common in a networked environment. I shudder to think what will happen if 8:30 rolls around and all the workers arrive to start the day, each boots his X terminal which then starts to download a server (and fonts???) to the workstation. Slowly the ethernet sinks into the ground... -david- Disclaimer: In no way could I possibly be a spokesperson for Sequent.
dce@stan.UUCP (David Elliott) (02/18/89)
In article <74@torsqnt.UUCP> david@torsqnt.UUCP (David Haynes) writes: >In article <611@gt-eedsp.UUCP> jensen@gt-eedsp.UUCP (P. Allen Jensen) writes: >> >>Many of the X Terminal systems I have looked at (NCD in particular) can down- >>load the server from another system. This would seem to be reasonable, > >I have a problem with this. With vendors such as Oracle coming out >with X-based tools (CASE in this example) X terminals will be Isn't the word "can" the operative one here? Maybe I've been given the wrong impression, but I thought that the NCD normally kept a copy of the server in memory, and that the only reason it had download capability was so that if you needed to download a new version of the server (or even another type of graphics subsystem!), you could do so instead of having to pop the case and change the PROMs. This is similar to EEPROMs found in some other types of products. -- David Elliott ...!pyramid!boulder!stan!dce "Splish splash, I was rakin' in the cash" -- Eno
twolf@homxb.ATT.COM (T.WOLF) (02/20/89)
With all this talk about X-Server Terminals, I thought I might as well ask my novice questions: What exactly happens when you power up a Visual (or NCD) terminal? Does it automatically try and get fonts via NFS? If so, what happens if the host doesn't support NFS? Any answers to these and other pressing questions would be appreciated. -- Tom Wolf Bell Labs, Holmdel, NJ E-mail: twolf@homxb.att.com (My employer doesn't know about these and other incriminating remarks)
klein@lupine.UUCP (Doug Klein ) (02/21/89)
In article <474@salgado.stan.UUCP>, dce@stan.UUCP (David Elliott) writes: > > Maybe I've been given the wrong impression, but I thought that the NCD > normally kept a copy of the server in memory, and that the only ... Just for clarification, the NCD16 can be either PROM based or booted over the net. If the unit is PROM based, it is an option to boot over the net to try newer software. We have seen arguments for both configurations, thus the option. Doug -- Doug Klein Network Computing Devices uunet!lupine!klein
ed@lupine.UUCP (Ed Basart) (02/21/89)
The NCD X station offers either a downloaded server or a server in PROM. Many people are happy that software updates can be handled in a civilized fashion, and choose to purchase the units as download units. The server is downloaded whenever the unit is powered on. There are other people who wish to have the server in PROM, just to avoid such problems as 1000 people powering on their station at 8:30 Monday morning. But this is not a new problem. Diskless workstations have the same problems (and more, due to paging and file access), and the networking community is slowly working this out. For the present, people partition their networks and keep the number of devices to a reasonable level (say 20 to 100) per partition. If you locate a boot machine on each segment (presumably one needs at least one host per 20 to 100 X stations!), then the traffic tie-up as everyone starts her/his station is minimized.
stpeters@dawn.steinmetz (02/22/89)
In article <4921@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >Yes, but you're falling into the standard "diskless workstation" >fallacy, that the disk behind that diskless is not going to cost >anything. In fact you usually need around 24MB of disk, at least, just >to boot the thing (8MB root, 16MB swap), if you need to support even a >dozen users you better throw in the price of a server also so suddenly >you've easily eaten an additional $50K of hardware, or once again the >price of the workstations. Barry, now you've fallen into a fallacy: pulling numbers from yesterday's technology to argue a point about tomorrow's. My diskless Sun has all of 2.9MB "in" it's root partition - "in" in quotes because its root "partition" is an NFS-mounted directory on the server. On the server, the "root directories" of all the clients are in a single partition. All the client vmunix's can be - on the server - hard links to the same file. Pull the same trick on most of the other root filesystem files, and an indefinite number of client roots take up only about 3MB on your server. Excluding client /tmp directories, of course. However, 1) they too can share common space on the server, and 2) if the diskless node is to be used as just a windowing terminal, it doesn't (or shouldn't) need a /tmp. SunOS 4.0 does require that the server have a fixed-size swap file for each client, but I'd bet that restriction doesn't last. Anyway, a diskless client used just as a windowing terminal doesn't need 16MB swap. In fact, it shouldn't need any swap at all. If a windowing terminal doesn't swap, why should a diskless client used as one swap? Suppose tomorrow's OS release supports a config option: option NOVIRTUAL_MEMORY Then we will have a machine that runs UNIX, has no disk, and needs server access only for boots or fonts. Hundreds of them could go on one server and use but a handful of MB. And, of course, you could always use them as real workstations if your needs change. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
mjb@xpiinc.UU.NET (Michael J. Braca) (02/23/89)
In article <474@salgado.stan.UUCP> dce@salgado.UUCP (David Elliott) writes: > >Maybe I've been given the wrong impression, but I thought that the NCD >normally kept a copy of the server in memory, and that the only >reason it had download capability was so that if you needed to >download a new version of the server (or even another type of graphics >subsystem!), you could do so instead of having to pop the case and >change the PROMs. This is similar to EEPROMs found in some other >types of products. Let me rephrase that. You believe the server is downloaded to non-volatile memory so the downloaded code would survive a power cycle. In fact, there are no X terminals I know of that include this feature today, but it's a great idea if you like downloadability but don't like to wait 30 seconds for the terminal to come up after a power-on. On the other hand, a representative of a Major Computer Company told me that users would tolerate a wait for up to one minute for a terminal to come up. So, as with most features, it all comes down to: how much is that 30 seconds worth to you (or your network administrator)? My gut feeling is: not what it would cost you. Mike Braca Visual Technology
raveling@vaxb.isi.edu (Paul Raveling) (02/23/89)
In article <13216@steinmetz.ge.com> dawn!stpeters@steinmetz.UUCP () writes: >In article <4921@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >>Yes, but you're falling into the standard "diskless workstation" >>fallacy, that the disk behind that diskless is not going to cost >>anything. In fact you usually need around 24MB of disk, at least, just >>to boot the thing (8MB root, 16MB swap), if you need to support even a >>dozen users you better throw in the price of a server also so suddenly >>you've easily eaten an additional $50K of hardware, or once again the >>price of the workstations. > >Barry, now you've fallen into a fallacy: pulling numbers from >yesterday's technology to argue a point about tomorrow's. My diskless >Sun has all of 2.9MB "in" it's root partition - "in" in quotes because >its root "partition" is an NFS-mounted directory on the server. For a different perspective, my workstation has about 3/4 gigabyte of local disk and mounts about the same from a file server, another workstation, and a VAX. >SunOS 4.0 does require that the server have a fixed-size swap file for >each client, but I'd bet that restriction doesn't last. Anyway, a >diskless client used just as a windowing terminal doesn't need 16MB >swap. Another aspect of our different perspective is that we need about 75 megabytes of swap space, with the biggest demand coming from running LISP under UNIX. The bottom line is there's a whole range of requirements for different users. The best solution for any given organization can easily be a mix of X terminals, diskless workstations, "diskful" workstations, and even mainframes. ---------------- Paul Raveling Raveling@isi.edu
schoeller@gvriel.dec.com (Dick Schoeller, MLO4-1/C32, DTN 223-1670) (02/23/89)
>In fact, it shouldn't need any swap at all. If a windowing terminal >doesn't swap, why should a diskless client used as one swap? Suppose >tomorrow's OS release supports a config option: >option NOVIRTUAL_MEMORY Dick St.Peters makes some interesting comments about where we can expect windowing terminals to end up. However, it is unlikely that we are going to see the above have a reasonable performance in the near future. The typical style of developing X applications would have to change drastically to allow a server to run in limited memory (<16meg) without paging resources. Especially if the user expects to run more than 10-12 large toolkit clients simultaneously. Disclaimer: The above statements blatantly plagerized fom comments made by Sgt. Rosenthal 8^{) at the X Technical Conference. Dick Schoeller | ARPA: schoeller%gvriel.dec@decwrl.dec.com Digital Equipment Corporation | UUCP: decwrl!gvriel.dec!schoeller 146 Main Street, MLO4-1/C32 | Voice: 508-493-1670 Maynard, MA 01754-2571 |
bzs@Encore.COM (Barry Shein) (02/24/89)
From: stpeters@dawn.steinmetz >Barry, now you've fallen into a fallacy: pulling numbers from >yesterday's technology to argue a point about tomorrow's. My diskless >Sun has all of 2.9MB "in" it's root partition - "in" in quotes because >its root "partition" is an NFS-mounted directory on the server. *WHAT* fallacy? So fine, you can squeeze diskless machines into a little less space, like 8 or 12MB (you never give the actual figure), so what? Aren't we just, then, arguing about the degree? You can cut it about 50%, it's still a heck of a lot more than a terminal that uses about 0MB. The point still stands. Postulating hypothetical non-swapping OS's isn't much of a refutation either, when one shows up, and is actually useful, perhaps it's worth talking about. It's nice that you have ideas, but posting them as refutations of someone else's point when they're actually just orthogonal ideas seems dishonest to me. Yes, I was aware of everything you mentioned when I summarized my thoughts, I just decided they weren't important. For example, how about some real cost analysis of the three approaches (terminal, diskless, squeezed diskless) on a per seat basis at 25, 50, 100 and 500 seats? -Barry Shein, ||Encore||
bzs@Encore.COM (Barry Shein) (02/24/89)
>Dick St.Peters makes some interesting comments about where we can expect >windowing terminals to end up. However, it is unlikely that we are going >to see the above have a reasonable performance in the near future. The >typical style of developing X applications would have to change drastically >to allow a server to run in limited memory (<16meg) without paging resources. >Especially if the user expects to run more than 10-12 large toolkit clients >simultaneously. > >Dick Schoeller | ARPA: schoeller%gvriel.dec@decwrl.dec.com In defense of Dick St Peters servers *obviously* can run on such systems, that's exactly what Visual, NCD and others are selling! I don't understand your objection. If what you mean is that one couldn't run their *clients* on a non-paging system, sure, who said they could? Essentially what Dick was proposing was building his own Visual/NCD etc out of a diskless Sun3/50 by turning off paging in the kernel, unless I seriously misunderstood his note. He expects the clients to be running elsewhere and only the server to run on the diskless machine. -Barry Shein, ||Encore||
stpeters@dawn.steinmetz (02/24/89)
In article <7610@venera.isi.edu> raveling@isi.edu (Paul Raveling) writes: > For a different perspective, my workstation has about > 3/4 gigabyte of local disk and mounts about the same > from a file server, another workstation, and a VAX. Apples vs. oranges here. I said my Sun has 2.9MB in its *root* partition. That's the (shared) space need just to make it function, which is all it would have to do if it were (note subjunctive) used just as a windowing terminal. I use it as a real workstation and have gigabyte upon gigabyte mounted from 15 servers from Sun, DEC, HP, and Encore. > Another aspect of our different perspective is that > we need about 75 megabytes of swap space, with the > biggest demand coming from running LISP under UNIX. But you can't run LISP on a windowing terminal either. There seems to be a disconnect in this newsgroup/mailing-list between those who want to use X as a network window system (server in front of me, application running somewhere else) and those who want to use X mainly as a local window system (server and application on the same machine). As you might guess by now, I have a fair bit of swap space too, but the issue was how easily/cheaply a diskless workstation could be used just as a terminal. > The bottom line is there's a whole range of requirements > for different users. The best solution for any given > organization can easily be a mix of X terminals, diskless > workstations, "diskful" workstations, and even mainframes. Agreed wholeheartedly, except I'd substitute "compute engines" for mainframes. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
dale@boing.UUCP (Dale Luck) (02/24/89)
In article <4965@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: > >The point still stands. Postulating hypothetical non-swapping OS's >isn't much of a refutation either, when one shows up, and is actually >useful, perhaps it's worth talking about. We have X running on a non-swapping real memory system. Seems to run just fine. Make sure you set the stack to the right amount (about 20k) seems to do fine for most X applications. Puzzle does grow to around 40k or so when recusively solving the thing. I have an X monochrome server that supports both tcp/ip-ethernet or decnet-serial plus uwm running locally and the local operating system still running in a 1M Amiga 500. All the code fits on one 880K floppy of which there is one built into the A500. I did strip the fonts down to a bare minimum. With the ethernet I only need about 2M of NFS for all the rest of the compressed fonts. Most of the other applications require about 100k-200k apiece, like xcalc, xclock, bitmap, etc. This is using non shared libraries which are one of the amiga's strong points. I expect the typical Amiga X system to be an A2000 loaded with an extra 2M of memory. So you really don't need 8M of real memory or more virtual, nor do you need 20mbytes of harddisk space for the binaries plus all the other operating system program to just get going. I'm sure we'll see more of this with os/2 (well maybe not ;-) ). Those 286/386 pc's running xenix or whatever and X are probably capable of stripping down to a bare minimum to only run X as well. > > -Barry Shein, ||Encore|| -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
geer@ATHENA.MIT.EDU (02/24/89)
It is our opinion that diskless nodes are a profligate use of network bandwidth and that any configuration involving same cannot scale. Further, the majority of diskless nodes have a protection model not directly compatible with open networks. Dan Geer Manager of Systems Development Project Athena - E40-342F Massachusetts Institute of Technology 1 Amherst Street Cambridge, Massachusetts 02139 NET: geer@athena.mit.edu TELCO: 617-253-0155
raveling@vaxb.isi.edu (Paul Raveling) (02/25/89)
In article <13242@steinmetz.ge.com> dawn!stpeters@steinmetz.UUCP () writes: >In article <7610@venera.isi.edu> raveling@isi.edu (Paul Raveling) writes: > >> Another aspect of our different perspective is that >> we need about 75 megabytes of swap space, with the >> biggest demand coming from running LISP under UNIX. >But you can't run LISP on a windowing terminal either. But users of a windowing terminal can use LISP running on a different host machine; given the same software on the host, each user would still need his own 75 MB of swap space on the host. That was the original poster's point about resource costs -- some represent a constant cost, no matter what part of the overall system they're in. BTW, the question of comparing apples and oranges about various aspects of resource usage is entirely germane; in fact, to describe the actual situation we'd better throw in some grapefruits and prunes. Maybe even some California Raisins. ---------------- Paul Raveling Raveling@isi.edu
stpeters@dawn.steinmetz (02/25/89)
In article <4965@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >*WHAT* fallacy? Well, broadly the fallacy that each new diskless node *inherently* requires additional space on a server. That was the central point of your posting, I believe. More specifically, the fallacy that each new diskless *currently* requires additional space on a server for its root. As I noted, under SunOS 4.0, all diskless clients can share a common root. The only space an additional client need use is that needed for more hard links on the server. >The point still stands. Postulating hypothetical non-swapping OS's >isn't much of a refutation either, when one shows up, and is actually >useful, perhaps it's worth talking about. Even today, the non-swapping OS isn't entirely hypothetical. One of the steps in installing SunOS 4.0 is loading MUNIX. From the manual: "MUNIX is a version of SunOS that ... and resides entirely in memory. It does not require a disk from which to load or swap ..." However, it probably can't run X (yet). -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
prc@maxim.ERBE.SE (Robert Claeson) (02/25/89)
In article <7627@venera.isi.edu>, raveling@vaxb.isi.edu (Paul Raveling) writes: > >In article <7610@venera.isi.edu> raveling@isi.edu (Paul Raveling) writes: > >> Another aspect of our different perspective is that > >> we need about 75 megabytes of swap space, with the > >> biggest demand coming from running LISP under UNIX. > > But users of a windowing terminal can use LISP running > on a different host machine; given the same software on > the host, each user would still need his own 75 MB of > swap space on the host. That was the original poster's point > about resource costs -- some represent a constant cost, > no matter what part of the overall system they're in. But 10x75 MB of SWAP on a large host is more cost-effective than 75MB of swap per workstation since the swap space is shared among all users. One user can run his multi-super LISP simulation that uses 250 MB of swap during off-hours, when there's few other memory-hungry applications running. . -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20 EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SE
aglew@XENURUS.GOULD.COM (Andy-Krazy-Glew) (02/26/89)
>Even today, the non-swapping OS isn't entirely hypothetical. One of >the steps in installing SunOS 4.0 is loading MUNIX. From the manual: >"MUNIX is a version of SunOS that ... and resides entirely in memory. >It does not require a disk from which to load or swap ..." However, >it probably can't run X (yet). Gould PN UTX also installed itself with a "no-swap" kernel, just a stripped down version of standard Gould UTX running out of a ramdisk. There was no reason it couldn't run X, if you had enough physical memory; we didn't include X in the ramdisk image, but there were tools so that the user could build his own noswap system. Motorola System V/68 also uses a ramdisk type installation.
dshr@SUN.COM (David Rosenthal) (02/27/89)
"Don't, don't believe, don't believe the hype." Public Enemy > >to see the above have a reasonable performance in the near future. The > >typical style of developing X applications would have to change drastically > >to allow a server to run in limited memory (<16meg) without paging resources. > >Especially if the user expects to run more than 10-12 large toolkit clients > >simultaneously. > > > >Dick Schoeller | ARPA: schoeller%gvriel.dec@decwrl.dec.com > > In defense of Dick St Peters servers *obviously* can run on such > systems, that's exactly what Visual, NCD and others are selling! I > don't understand your objection. > The point that Dick Schoeller was making was the one I have been making for about 18 months now. I can't understand why its so hard to get people to hear it. Here we go again, at somewhat more length than before. [I apologize if I'm getting repetitive on this point, but I believe that as one of the designers of X I have a professional responsibility to counter the misleading and irresponsible marketing of the X terminal companies]. Current X clients CRASH when they get a Alloc error. X terminals with no VM are likely to generate Alloc errors frequently. For example, the X server on the DEC PMAX in their suite at Usenix when I used it had been used to run a lot of sophisticated X clients simultaneously. It was 17meg big (resident set size was 7meg). Of course, this was pre-production software and it may have had leaks, but how many X terminals will have even half that much memory? Changing this involves a completely different style of client-writing, which no-one has designed yet. It would be basically transaction-oriented, to allow recovery from Alloc errors in a workable way. The fundamental problem here is a change in design philosophy between X10 and X11. In effect X10 was stateless, and clients couldn't allocate resources in the server (for example, off-screen pixmaps). X11 is statefull, and clients can allocate resources in the server. The reason for doing this is that much greater performance can be achieved in this way. When a client of a statefull service that is being shared with other clients gets an Alloc error, there may be nothing that IT can do to recover. The problem may be that some other client has just allocated too much resource, and that the only route to recovery involves the other client doing something. This problem is common to all statefull services, for example file systems, and can always lead to deadlock. OK, you say, we'll just tell the user what's going on, and let him or her get us out of the mess. Easy, except that to communicate with the user you have to use X11 protocol and the requests you send to do it may in themselves cause Alloc errors, and ....... Sounds familiar, doesn't it? This is basically the multi-access database problem, with additional problems caused by asynchronous error notification and the need to use the database itself to communicate with the user about the problems involved in using the database and how to recover from them. Ask the database people how easy it is to cope with the problem even without these extra complications. No current X applications are written like database access programs, with trqansactions that can be backed-out of to get back to a known state before the Alloc error. As I understand the Intrinsics, they cannot support such a mode of programming. Indeed, its my belief that to fix this problem we will have to build transaction support into Xlib. So, Alloc errors are likely to be fatal for a long time. Given that Alloc errors are fatal, there are two routes to living with the problem: - Give the X terminal an MMU, and page to an NFS server. Looks a lot like a diskless workstation, doesn't it? - Rewrite the X clients you are going to use never to do any X request that can cause memory to be allocated in the server, or do them all up-front. This is hard because: - Any X request can potentially cause the server to allocate memory. - Avoiding just the requests you KNOW allocate memory involves a severe performance hit (why was it statefull in the first place?) The bottom line is, X terminals are being marketed under two claims: - They are cheaper than workstations. - They run the same X clients as workstations. Neither of these claims is true in practice: - Using X terminals instead of workstations does not change the set of processes being run, nor the amount of disk/RAM/CPU needed to run them. It merely moves them from one place to another. It may be that you can buy the necessary total amount of disk/RAM/CPU cheaper as a set of workstations with a file server, or as a set of X terminals with a timesharing machine, but in neither case is the price tag on the thing on your desk the only thing to consider. - A non-VM X terminal will only run a small set of simple X clients safely. Overloading it with complex clients which use server resources to implement a high-performance graphical user interface is dangerous - clients will start to crash randomly (hardly user-friendly behaviour). If all you want from X is a way of running several terminal emulators at once, an X terminal is OK. But the whole idea of X was to get away from simple terminal-type interfaces and make a real operating system look more like the "computer you already know how to use". If I can't in practice run the clients that were the raison d'etre for X, I think I'm entitled to feel cheated. Caveat Emptor. David.
mujica@ra.cs.ucla.edu (S. Mujica) (02/27/89)
In article <8902262128.AA04910@devnull.sun.com>, dshr@SUN (David Rosenthal) writes: > > "Don't, don't believe, don't believe the hype." > Public Enemy > ... The argumentation in David Rosenthal's message is based on the fact that X servers may grow very large when complex applications are run. He also says that X terminals defeat the purpose of X because their limited memory size does not allow to run complex clients that demand large amounts of space in the server. I do not think that X terminals defeat the purpose of X because of memory size: do we believe that today's hardware limits will be valid one year from now?... How much space do highly-demanding clients require?... How many highly-demanding clients do we want (or are prepared) to use simultaneously?... It is true that the size of the server will depend on the clients being run and how they allocate resources. This is a limitation for X terminals, and it is also a limitation for workstations, diskless and with local disk. If a workstation is used instead of an X terminal the amount of swap space that can be used is also limited--just throw in a Lisp process, a few more usual-Unix-processes, and the X server won't be able to find a lot of space to grow. In an X terminal the limit may be a few Mbytes, in a workstation the limit may be larger (maybe much larger) than in a terminal. But in any case the limit WILL BE there. Isn't David Rosenthal pointing to a basic limitation in the design of X rather than in the X terminal concept? "... > safely. Overloading it with complex clients which use server > resources to implement a high-performance graphical user interface > is dangerous - clients will start to crash randomly (hardly > user-friendly behaviour). If all you want from X is a way of ..." Sergio Mujica, mujica@cs.ucla.edu Computer Science Department, UCLA
thp@westhawk.UUCP ("Timothy H Panton.") (02/27/89)
At the risk of repeating what other (more illustrious) posters have said, it is worth pointing out that we (software developers) are not the 'big' market for Xterminals, just as we are not the 'big' market for ascii terminals. As I understand it Visual et al are planning to sell mostly to system integrators, who may be selling an accounts package with built in graphics, or a medical database with graphical fields in the records. The thing about these applications is that their users 'live' in them so to estimate the amount of server resource one simply(?) has to get into the most complex part of the system and see how much that uses. The fly in the ointment is that these people will leave the system running for days or weeks, so any leaks will cripple (or even kill) the application. I'm about 3/4 of the way through an Xapplication of this sort and on a reasonably complex screen the server seems to peak at about 2Mb (X11R3 - sun 3/50) so I'd guess that a 2Mb Xterminal (code in rom) will probably be about right. ( It isn't clear to me that this is the way to go, it depends on where you want the client to be run) The place where X terminal vendors may trip up, is by saying > David Rosenthal <dshr@sun.com> writes: >- They are cheaper than workstations. >- They run the same X clients as workstations. particularly to Universities and research establisments, who are really developers and as such should only have one for testing purposes, not daily use. So in summary: I don't want one on my desk, but I can see where they might be useful. Tim Ps: Allowing the server to swap just postpones the problem. :-> +----------------------------------------------------------------------------+ |Tim Panton, Westhawk Ltd. (Bright the hawk's flight on the empty sky.)| |Paper: Westhawk Ltd. 26 Rydal Grove, Helsby, Cheshire, WA6 OET. UK. | |Phone: +44 92822574 uucp : ..!mcvax!ukc!cam-cl!westhawk!thp | +----------------------------------------------------------------------------+
dshr@SUN.COM (David Rosenthal) (02/27/89)
> Isn't David Rosenthal pointing to a basic limitation in the design of > X rather than in the X terminal concept? > > "... > > safely. Overloading it with complex clients which use server > > resources to implement a high-performance graphical user interface > > is dangerous - clients will start to crash randomly (hardly > > user-friendly behaviour). If all you want from X is a way of > ..." Right! Or at least, nearly right. What I am pointing out is a fact of the X protocol that makes the way that we currently write X clients unsafe, in the sense that they may randomly crash through no fault of their own. They are more likely to do so in an X terminal environment than in a workstation environment - this is a practical not a fundamental difference between the two environments, but it does have practical effects for customers. Developing a whole new way of writing X clients is hard for both technical and organizational reasons: - The current way has enormous momentum. - The technical difficulties of recovering from Alloc errors are enormous - no-one has even a theoretical structure for doing it. In the meantime, the only way of dealing with the problem is to avoid it by providing the server with plenty of room to grow. Plenty of room means enough room so that Alloc errors never happen given the set of clients that are normally run, and the set of operator actions normally taken (remember, selections also take space in the server - what is the biggest selection you think the user will make?). Given my observations of actual X servers running actual clients, I believe that "plenty of room" is at least 6-8meg. David.
dshr@SUN.COM (David Rosenthal) (02/28/89)
You are missing two points: - All I am trying to do is to point that the claims X terminals are cheaper than workstations X terminals run the same applications as workstations need to be taken with a large pinch of salt. I am not saying X terminals are a bad idea - in the right context they can be cost-effective - but that the right contexts to employ them in are somewhat restricted. - You have been taken in by the first of the claims. You keep contrasting $2K terminals with $10K workstations, ignoring the cost of the resources needed to run the clients. Does Encore give its machines away free with a box of X terminals? I have been saying the same thing for a long time. It is our responsibility to address the problems caused by the possibility of running out of memory. To stick our heads in the sand, cross our fingers, and hope that no-one ever actually runs out of memory in a situation where it actually matters reminds me strongly of the pre-worm situation on the Internet - everyone knew that worms were possible but people just hoped they wouldn't actually happen because solving the problem was hard and the Internet was so useful. When someone is killed because a critical X client crashes with an Alloc error, it won't do us a lot of good to say "yes, we knew about this, but we couldn't be bothered to deal with the problem" like we had to for the worm. The fact that the problem is hard isn't an excuse for not trying to solve it. And don't say "everyone knows that you shouldn't build critical things in X". I've already heard about air traffic control work in X. David.
twolf@homxb.ATT.COM (T.WOLF) (02/28/89)
In article <21032@shemp.CS.UCLA.EDU>, mujica@ra.cs.ucla.edu (S. Mujica) writes: > ...deleted stuff... > The argumentation in David Rosenthal's message is based on the fact > that X servers may grow very large when complex applications are run. > > He also says that X terminals defeat the purpose of X because their > limited memory size does not allow to run complex clients that demand > large amounts of space in the server. I guess I'm second-guessing the original author, but I don'tr recall the him being of that opinion at all. He simply asserted that companies providing X-terminals want the public to believe that these terminals can do everything a diskless workstation can. ...deleted stuff... > Isn't David Rosenthal pointing to a basic limitation in the design of > X rather than in the X terminal concept? I agree. But what design doesn't suffer limitations imposed by the environ- ment? Memory contraints on the server side were probably chosen as the lesser of two evils (the other being large network-transmission costs of these data structures.) -- Tom Wolf Bell Labs, Holmdel, NJ E-mail: twolf@homxb.att.com (My employer doesn't know about these and other incriminating remarks)
jg@jumbo.dec.com (Jim Gettys) (02/28/89)
In article <8902271538.AA07299@devnull.sun.com> dshr@SUN.COM (David Rosenthal) writes: >Or at least, nearly right. What I am pointing out is a fact of the >X protocol that makes the way that we currently write X clients unsafe, >in the sense that they may randomly crash through no fault of their own. >They are more likely to do so in an X terminal environment than in a >workstation environment - this is a practical not a fundamental difference >between the two environments, but it does have practical effects for >customers. >Developing a whole new way of writing X clients is hard for both technical >and organizational reasons: > >- The current way has enormous momentum. >- The technical difficulties of recovering from Alloc errors are > enormous - no-one has even a theoretical structure for doing it. > >In the meantime, the only way of dealing with the problem is to avoid it >by providing the server with plenty of room to grow. Plenty of room means >enough room so that Alloc errors never happen given the set of clients >that are normally run, and the set of operator actions normally taken >(remember, selections also take space in the server - what is the biggest >selection you think the user will make?). Given my observations of actual >X servers running actual clients, I believe that "plenty of room" is >at least 6-8meg. I guess I'd better comment on this topic, as one of the two people who started X, and in the position where I have less political hassle for commenting than Bob does, though I don't wish to imply any of the following is anyone's opinion but my own. I generally agree with Dave; the design center of X presumes virtual memory. Even on a terminal, this should not be very hard to provide today, given a high speed network connection. With some work, you can make the X server use around 50% of the resources it generally does to day for windows and GC's. The changes are not very hard, and may appear in a future release from MIT (no promises), but any terminal vendor who fails to implement these changes is is not being responsible to his customers, unless he is very careful to sell terminals only to people with fixed applications. To date, I have not seen a terminal which could truley replace a workstation, though it is certainly possible given the above work being done. In terms of absolute amount of memory used by an X server, I suspect Dave's estimate is high (at least for mono screens), but the problems are very real, and the unpredicatability of the problem is major. So I think X terminals may be useful, I can't say I'm happy with how they'be been implemented, and wonder how much they differ from diskless workstations. There may well be a market window while they make sense, since diskless workstation administration is currently much more hassle than it should be. A minor quibble on history; the problems even existed in V10, but the fact that you could not perform graphics on pixmaps in V10 meant that they were much less used. More importantly, X11 applications are now much more "real" and use the window system much more agressively. Jim Gettys Digital Equipment Corporation Cambridge Research Lab.
bzs@Encore.COM (Barry Shein) (02/28/89)
>Current X clients CRASH when they get a Alloc error. No one has claimed otherwise, even the vendors I've spoken to. No one has claimed X is mature and finished etc etc. Although the problems you detail later do indicate that it's not a trivial fix there are still ways to deal with it. And how much is your summary grounded in a very unfortunate window of technology where we're still stuck with $35 1Mb chips and a flat technology curve? What would 16Mb chips and/or the price dropping to $5/chip do to all these arguments (agreed, that's not where we are, but we're *both* doing some forecasting, no?) >X terminals with no VM are likely to generate Alloc errors frequently. Interesting claim, we've never had it happen here and I'm sure you'll hear that from others. I completely believe it can happen, I only dispute the word "frequently". Have you ever tried one of these terminals? I've seen some pretty fancy environments run on them, not terribly fast, but I've never seen this happen. >For example, the X server on the DEC PMAX in their suite at Usenix >when I used it had been used to run a lot of sophisticated X clients >simultaneously. It was 17meg big (resident set size was 7meg). Of course, >this was pre-production software and it may have had leaks, but how many >X terminals will have even half that much memory? And you don't mention they were color servers (I was in there also)...so far the X terminals I've seen are all mono and I'd certainly look carefully at a color station for just that reason. Besides, I'm running X11R3 on my (mono) 3/60 right now with a bunch of windows and the server is 832K, gee, quite a discrepancy, the X terminals I've seen had 1.5MB. I do believe you saw the server run up that high, but I don't believe it's representative of the type of person who would (or should) buy an X-terminal. Look, anyone who buys a $2000 X-terminal expecting a high performance workstation (or even medium, heck, a 3/50 or uVax-II is much more powerful) is a fool and doomed to serious disappointment. X-terminals, at this point, mainly buy you one thing: Software (and other, eg. training) compatability with real workstations so you can unify your environment while still keeping the cost per seat down. It's a good excuse to not keep people on dumb ascii terminals forever even tho you can't in your wildest dreams justify going ~$10K for a workstation for every desk. It's close enough to the price of a dumb ascii terminal to consider. And they do work, maybe not at the outer limits of windowtude, but for the typical day to day chores of many people (eg. mail, text editing, the sorts of things business people do with Macs or PCs or Unix.) The people selling these things aren't as stupid as you seem to believe (or do you think no one would notice if they don't work?) The same sort of problems (no virtual memory, just brain-death on running out of memory) exist on PC's and MacIntoshes. Would you argue that here it is, 1983, and they're doomed to failure? For straightforward applications with simple goals they're "good enough". If there's one thing I've learned in (well) over a decade of this business it's that "good enough" tends to be very successful, and "technically superior" but late/unavailable/expensive solutions tend to lose, despite all the screaming. In fact I think that sums up the whole battle between NeWS and X (for example), NeWS was technically superior in many ways (not all), but X was "good enough", and it was there, available, and cheap. Maybe someday if decent $3000 VM/Unix workstations become available with X they'll be superior and all that. But it's not shocking that a $2000 systems has limitations when compared to a $10K or $20K machine, who would say otherwise? Same thing with PC's and a lot of other "obviously inferior" solutions, they're *good enough* to get the work done for a lot of folks, aficianados be damned. I can certainly see some workstation vendors picking up this sort of FUD (Fear/Uncertainty/Doubt) party line (it might work now, but *someday soon* you'll be sorry...) for obvious reasons. But it's foolish, unnecessary and counter-productive. Within reasonable parameters [I am quite certain David Rosenthal exaggerates his case] the argument is true for many classes of users and *must* be told. Yes, people who *needed* workstations (and there are a lot of them) but decided to buy an X terminal merely because they're cheaper are in for a shock. People who bought X terminals because the other choice was dumb ascii terminals will be satisfied and even pleased. And when they stop feeling pleased there's nothing standing between them and nirvana but $$. From the point of view of the workstation vendors, even if they stand to lose a few bucks (short-range) on people buying X terminals, it's IN THE WORKSTATION VENDOR'S INTEREST for people to buy these terminals in the right instances. The reasoning is that it legitimizes the interface, it's no longer the more fortunate types in the back labs running windowing software, it's everyone. The software interface becomes unified and the organization is no longer required to either buy two software worlds (one windowed, another aimed at dumb ascii terminals) or, in my experience, to refuse to invest in window stuff more than the minimum necessary since "most of the users here have dumb terminals" (not at Encore, tho it's not that far from the truth when you count the business side, we also have lots of Suns here.) And as they outgrow these X terminals they'll move on to real workstations if need be, and (if the truth gets known) they'll probably realize that if they move to a unified window environment they'd still better buy quite a few real workstations, because for many folks the terminals won't cut it. But, only the truth will set us free, not hype. Look, we're not even a few percent of the market (the whole Unix market), let's not fight over the scraps, tell me how X is better than a 3278 (or a PC or a Mac)...now *that's* interesting, cuz there's a $100B market behind that argument...familiarity breeds contempt. -Barry Shein, ||Encore||
aad@stpstn.UUCP (Anthony A. Datri) (02/28/89)
In article <510@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes: >But 10x75 MB of SWAP on a large host is more cost-effective than 75MB >of swap per workstation since the swap space is shared among all users. Under whose OS? Certainly not SunOS. Swap space exists as one big file for each client: beaker# pwd /export/swap beaker# ls -l total 181874 drwxr-sr-x 3 root 512 Jan 31 14:34 ./ drwxr-sr-x 6 root 512 Jul 28 1988 ../ -rw------t 1 root 16000000 Jul 28 1988 barkley -rw------t 1 root 16000000 Nov 12 18:12 bert -rw------t 1 root 16000000 Jul 28 1988 cookie -rw------t 1 root 16000000 Jul 28 1988 doc -rw------t 1 root 16000000 Jul 28 1988 ernie -rw------t 1 root 16000000 Jul 28 1988 frazzle -rw------t 1 root 16000000 Feb 27 18:43 gonzo -rw------t 1 root 16000000 Feb 19 18:36 kermit drwxr-xr-x 2 root 8192 Jul 28 1988 lost+found/ -rw------t 1 root 16000000 Feb 27 17:23 marvin -rw------t 1 root 16000000 Jul 28 1988 scooter -rw------t 1 root 16000000 Jul 28 1988 snuffy -rw------t 1 root 16000000 Feb 19 18:37 zoot beaker# df . Filesystem kbytes used avail capacity Mounted on /dev/xy0e 181892 181873 0 111% /export/swap -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, my VT05, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
schoeller@gvriel.dec.com (Dick Schoeller, MLO4-1/C32, DTN 223-1670) (02/28/89)
>In defense of Dick St Peters servers *obviously* can run on such >systems, that's exactly what Visual, NCD and others are selling! I >don't understand your objection. > >If what you mean is that one couldn't run their *clients* on a >non-paging system, sure, who said they could? Essentially what Dick >was proposing was building his own Visual/NCD etc out of a diskless >Sun3/50 by turning off paging in the kernel, unless I seriously >misunderstood his note. He expects the clients to be running elsewhere >and only the server to run on the diskless machine. > > -Barry Shein, ||Encore|| Barry, I know that is what they are selling. I guess that I was a bit obtuse on what I was saying. At the X Technical Conference, Mike Braca of Visual Technology, Inc. informed us why we should all change the way we write X applications. Most X applications (especially Xt based applications) are so intensive of server resources. That they cause an X terminal without virtual memory to run out of resources. His opinion was that changing the way we program was the way to fix this problem. The rebuttal was that changing the way X terminal vendors implement their systems is a more appropriate way to fix this problem. This requires either X terminals with virtual memory or with massive physical memory. Virtual memory X terminals are or will be available shortly from most of the vendors. But it is very unlikely that a CHEAP X Terminal with very large physical memory and no virtual memory will be available soon. Am I being slightly clearer than mud now? Dick Schoeller | schoeller@gvriel.dec.com Digital Equipment Corporation | decwrl!gvriel.dec!schoeller 146 Main Street, MLO4-1/C32 | 508-493-1670 Maynard, MA 01754-2571 |
cmc@inf.rl.ac.uk (Chris Crampton) (02/28/89)
In article <74@torsqnt.UUCP> david@torsqnt.UUCP (David Haynes) writes: >In article <611@gt-eedsp.UUCP> jensen@gt-eedsp.UUCP (P. Allen Jensen) writes: >> >>Many of the X Terminal systems I have looked at (NCD in particular) can down- >>load the server from another system. > >I have a problem with this. You mean you "forsee" a problem with this? Or are you experiencing problems aleady (as this statement suggests)? >I shudder to think >what will happen if 8:30 rolls around and all the workers arrive >to start the day, each boots his X terminal which then starts to >download a server (and fonts???) to the workstation. Slowly the >ethernet sinks into the ground... Hmmm, but why is this going to be any different to the environment many people already have with dozens of diskless nodes all needing to boot over the network? I work is such an environment and have not experienced any problems of this kind at all. The important factor is that most users leave their machines running continuously and so don't need to reboot everyday. Even if users did login afresh every morning, in a workstation environment, then the amount of data needed to be paged in over the network is likely to be significantly more than the volume of a single X server! (X server plus xterm plus xedit plus xclock plus....) I would anticipate that users logged on via X terminals are not going to want to log in every morning - who is going to want to destroy their context of work at the end of the day only to have to rebuild it all the next morning? If X terminals are more environmentally acceptable, as you would expect, then it is going to be even more likely that terminals will be left switched on. Chris.
mujica@ra.cs.ucla.edu (S. Mujica) (03/01/89)
In article <3074@homxb.ATT.COM>, twolf@homxb (T.WOLF) writes: >In article <21032@shemp.CS.UCLA.EDU>, mujica@ra.cs.ucla.edu (S. Mujica) writes: ... >> >> He also says that X terminals defeat the purpose of X because their >> limited memory size does not allow to run complex clients that demand >> large amounts of space in the server. > >I guess I'm second-guessing the original author, but I don'tr recall the >him being of that opinion at all. He simply asserted that companies >providing X-terminals want the public to believe that these terminals can >do everything a diskless workstation can. >...deleted stuff... > Read the following piece of text extracted from Rosenthal's original article: "... But the whole idea of X was to get away from simple terminal-type interfaces and make a real operating system look more like the "computer you already know how to use". If I can't in practice run the clients that were the raison d'etre for X, I think I'm entitled to feel cheated. ..." >> Isn't David Rosenthal pointing to a basic limitation in the design of >> X rather than in the X terminal concept? > >I agree. But what design doesn't suffer limitations imposed by the environ- >ment? Memory contraints on the server side were probably chosen as the lesser >of two evils (the other being large network-transmission costs of these data >structures.) > Right! I essentially quoted Rosenthal's message. I just wanted to point out that the importat part of his article was the exposure of a problem in X, not the attack on X terminals and X terminal companies. Sergio Mujica mujica@cs.ucla.edu Computer Science Department, UCLA
meo@stiatl.UUCP (Miles O'Neal) (03/01/89)
In article <8902272209.AA07843@devnull.sun.com> dshr@SUN.COM (David Rosenthal) writes: >When someone is killed because a critical X client crashes with an >Alloc error, it won't do us a lot of good to say "yes, we knew about >this, but we couldn't be bothered to deal with the problem" like we >had to for the worm. The fact that the problem is hard isn't an excuse >for not trying to solve it. > >And don't say "everyone knows that you shouldn't build critical things >in X". I've already heard about air traffic control work in X. While the above, quoted statement is true, it is beside the point. We have to decide, "Is this just another neat toy I can play with while attempting to justify my salary to my employer, or is this a REAL PRODUCT?" If the former, that's fine, but make sure the toys stay in the toybox. Sort of like the movie, "Gremlins". That cute, fuzzy creature, when not properly hamdled and constrained, caused lots of damage. Who do you blame? The kid? His dad? The Chinese kid? The Chinese old man? The cops? IT IS TOTALLY IRRELEVANT TO THOSE WHO ARE DEAD! On the other hand, if it's real (which a lot of people have been saying it is), if it's available (oboy is it available), and we are selling products based on it, then both the platform and our products had better be prepared to perform in the real world. X is sort of the anti-Ada, in some respects. In some ways, I like that. In some ways, it scares me a lot more than the thought of Ada-powered missle computers. -Miles gatech!stiatl!meo meo@stiatl.gatech.edu
mujica@ra.cs.ucla.edu (S. Mujica) (03/01/89)
In article <8902271538.AA07299@devnull.sun.com>, dshr@SUN (David Rosenthal) writes: ... >selection you think the user will make?). Given my observations of actual >X servers running actual clients, I believe that "plenty of room" is >at least 6-8meg. > Doesn't seem so hard to have an X terminal with 8meg in it... Sergio Mujica mujica@cs.ucla.edu Computer Science Department, UCLA
bzs@Encore.COM (Barry Shein) (03/01/89)
>- All I am trying to do is to point that the claims > > X terminals are cheaper than workstations > X terminals run the same applications as workstations > > need to be taken with a large pinch of salt. I am not > saying X terminals are a bad idea - in the right context > they can be cost-effective - but that the right contexts > to employ them in are somewhat restricted. Fine, then we agree 100% on this. >- You have been taken in by the first of the claims. You > keep contrasting $2K terminals with $10K workstations, > ignoring the cost of the resources needed to run the clients. > Does Encore give its machines away free with a box of X > terminals? I don't understand, the clients run on the Encore (or whatever, Sequent, there, equal time :-) whether the display is an X terminal or a workstation or whatever. Are you saying it costs *more* to run the clients against X terminals than against a workstation? If not then explain, I'm missing your point. Otherwise it all seems equal to me and my comparison is valid, clients is clients, who cares what's being used for a display from the point of view of that machine? >When someone is killed because a critical X client crashes with an >Alloc error, it won't do us a lot of good to say "yes, we knew about >this, but we couldn't be bothered to deal with the problem" like we >had to for the worm. The fact that the problem is hard isn't an excuse >for not trying to solve it. This is getting ludicrous, yes, people have to evaluate the hardware and software they're specifying. No one is making the claims you're straw-man'ing against, there is no cover-up (or shouldn't be.) Do you know about a certain three-letter vendor who sold their token-ring against ethernet in hospitals by telling the hospital administrators that ethernet is unpredicatable by its very CSMA/CD nature? And when a packet is lost in a collision a patient !might die! in the delay, no joke, a guy on unix-wizards from a major research hospital was begging for people to supply him with counter-arguments. Sound familiar? Sound comfortable? >And don't say "everyone knows that you shouldn't build critical things >in X". I've already heard about air traffic control work in X. What happens when most any machine runs out of swap space? Or disk? Or process slots? Or...Why is this X terminal limitation so unique? Computers and their peripheral equipment have resource limits which should be carefully taken into account when designing critical applications environments. There, I said it, now everyone knows... -Barry Shein, ||Encore||
tore@SFD.UIT.NO (Tore Larsen) (03/02/89)
On Feb. 27 hsi!stpstn!aad@uunet.uu.net (Anthony A. Daatri) asks whose OS offers shared swap space. HP-UX 6.0 Hewlett-Packard HP-UX 6.0 (and later) does offer shared swap space. --Tore Larsen
prc@maxim.ERBE.SE (Robert Claeson) (03/04/89)
In article <2856@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: > In article <510@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes: > > >But 10x75 MB of SWAP on a large host is more cost-effective than 75MB > >of swap per workstation since the swap space is shared among all users. > > Under whose OS? Certainly not SunOS. Swap space exists as one big file > for each client: (ls -l listing of /export/swap deleted) A workstation's swap is local to it, even if it resides on a server. No, what I meant was, that 750MB of swap on a large, central machine (such as an Alliant, a VAX 8800 or an Encore Multimax) with X terminals connected to it via Ethernet or SLIP is more cost effective than having 75 MB of swap local for each workstation. That way, the a_p_p_l_i_c_a_t_i_o_n_ that's u_s_i_n_g_ the large host (and not X itself in the terminals) has more potential swap. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20 EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SE
dale@boing.UUCP (Dale Luck) (03/05/89)
In article tore@SFD.UIT.NO (Tore Larsen) writes: >On Feb. 27 hsi!stpstn!aad@uunet.uu.net (Anthony A. Daatri) asks whose OS > offers shared swap space. >HP-UX 6.0 Hewlett-Packard HP-UX 6.0 (and later) does offer shared swap space. >--Tore Larsen Swap space? What is that? ;-) No mention of it in my Amigados manual? Just kidding, I did not see any followups to a posting I made about X server and clients running on the amiga and the resources that I found were required, like 20k of stack space not really that much physical memory, maybe 100k-250k per client. This before we go to shared libraries. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
munir@hpfcmr.HP.COM (Munir Mallal) (03/06/89)
>/ hpfcmr:comp.windows.x / aad@stpstn.UUCP (Anthony A. Datri) / 4:47 pm Feb 27, 1989 / >In article <510@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes: > >>But 10x75 MB of SWAP on a large host is more cost-effective than 75MB >>of swap per workstation since the swap space is shared among all users. > >Under whose OS? Certainly not SunOS. Swap space exists as one big file > HP-UX from HP has a single shared swap space for diskless clients. Munir Mallal Disclaimer: I do work for HP but they didn't make me say this.
dac@f.gp.cs.cmu.edu (Daniel Christian) (03/07/89)
I agree with the Visual folks when they say that we need to look at how we write X applications. I do not beleive that virtual memory should be required for day-to-day applications (which in my book is almost everything except serious CAD type work). It is not unreasonable to have limits in the server and keep these limits in mind when designing applications. All personal computer applications have dealt with limits like these very effectively. Applications need to be efficient. Inefficiency unnecessarily strains the server and slows down the system. Toolkits were originally billed as being more efficient than simple Xlib code. Is this really true? What more can be done? From doing some server development, I noticed that toolkit applications imeadiately store one or more images to the server. As far as I can tell, these images are not use except maybe as border stipple. I haven't dug into the toolkit code enought to know what it is trying to do. There are a large number of people out there who would like to use their current PC/Mac/Amiga/etc as an (cheap) X server. The installed base of these machines absolutely dwarfs the workstation market: Do not ignore them. Many people will wonder why a machine that currenly runs a huge number of complete graphics applications is suddenly too small to handle just the graphics side of X applications. On a similar note, why are toolkit applications so @#$%&#!@# Large?! The baseline seems to be about 240K on a Sun3 (Xlogo). xfd is 100K smaller and does more. Do things get smaller with C++ tookits? -Dan Christian dac@ri.cmu.edu All disclaimers apply. --
barmar@think.COM (Barry Margolin) (03/08/89)
In article <4424@pt.cs.cmu.edu> dac@f.gp.cs.cmu.edu (Daniel Christian) writes: > Applications need to be efficient. Inefficiency unnecessarily >strains the server and slows down the system. Toolkits were >originally billed as being more efficient than simple Xlib code. Is >this really true? What more can be done? > From doing some server development, I noticed that toolkit >applications imeadiately store one or more images to the server. It depends on how you are measuring efficiency. In the case of distributed applications (all X-based programs are distributed applications), you must also consider communications efficiency. One way to improve communications effiency is to prevent redundant use of the communications medium, by storing data at the recipient. X provides mechanisms to support this, but it uses resources in the server. So, the application or toolkit developer must decide whether to trade off server resources for communication throughput. NeWS goes even further in supporting this, by allowing arbitrary Postscript programs to be stored in the server for later invocation; again, you're depending upon server power to reduce your network use. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
milburn@me1.lbl.gov (John Milburn) (03/11/89)
In article <2856@stpstn.UUCP> aad@stepstone.com writes: >In article <510@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes: > >>But 10x75 MB of SWAP on a large host is more cost-effective than 75MB >>of swap per workstation since the swap space is shared among all users. > >Under whose OS? Certainly not SunOS. Swap space exists as one big file >for each client: HP for one. Discless clients share swap space with the server. John Milburn Lawrence Berkeley Laboratory INTERNET: JEMilburn@lbl.gov DECNet: LBL::JEMilburn SnailMail: 1 Cyclotron Road 46-161 Ma Bell: (415) 486-6969 Berkeley, Ca. 94720