Return to BSD News archive
Xref: sserve comp.os.386bsd.apps:1095 comp.os.linux.misc:11740 Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!news.cs.su.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!csulb.edu!nic-nac.CSU.net!charnel.net.csuchico.edu!charnel!xmission!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.apps,comp.os.linux.misc Subject: Re: DOOM for X Date: 23 Mar 1994 00:51:45 GMT Organization: Weber State University, Ogden, UT Lines: 89 Distribution: inet Message-ID: <2mo3r1$aia@u.cc.utah.edu> References: <2m814r$bnp@news.mcs.kent.edu> <1994Mar17.132757.12534@taylor.wyvern.com> <2mgvon$ljb@usenet.mcs.kent.edu> NNTP-Posting-Host: cs.weber.edu In article <2mgvon$ljb@usenet.mcs.kent.edu> borsburn@mcs.kent.edu (Bret Orsburn) writes: ]In article <1994Mar17.132757.12534@taylor.wyvern.com> mark@taylor.wyvern.com (Mark A. Davis) writes: ]>Not really. Most Xterminals are not running Unix, which is far overkill... ] ]UNIX (at least a stripped-down run-time version) isn't overkill if the vendor ]has to port Xlib and Xt and and several other application libs. (Motif?) First of all, mwm doesnm't require linking with libXm, or didn't last time I licensed the sources. ]>Nope. But the mini OS in the Xterminal does have to support certain ]>functionality- most of which is necessary to run the Xserver software anyway. ] ]The X server has a very small OS porting layer (osx). ] ]The Client side does not. This depoends greatly on if you are stupid enough to try and port all clients or if you are simply trying to port *some* clients that make sense -- ie: those which take little room and *aso* have a very small OS porting layer. A window manager is one such client. ]You've got a heterogeneous network (that X allowed you to build, to your ]great advantage) including X terminals from three different vendors. You ]have among your user population people with strong preferences for four ]different window managers. ] ]So, as the site administrator, you have to make four different window managers ]work under 3 different, arbitrarily restricted, (perhaps proprietary) ]"mini OS"es. ] ]For those of you following along at home, that's 12 ports. Again, from the same perspective, window management services are something the X terminal vender should supply. Check out NCD and NCR. The only exceptions to this are bogus X terminals anyway, where the server runs on the UNIX and uses some dumb protocol for talking to the terminal and getting gross drawing capability out of it. ]Twelve ports using three different collections of low-volume, ad hoc cross ]development tools and three rag-tag processions of vendor-developed application ]support libraries. Obviously you'd be an idiot to do this. By the same token, you'd be an idiot anyway, since you have quadrupled your support problems anyway, even if the window managers did not run locally. Generally speaking, any large business that wishes to stay in business and spends on X will pick *one* user interface, and will probably pick *one* terminal vender. ]Are you absolutely sure that using a non-local window manager was such a ]big problem that you are willing to discard everything you know about ]software development and maintenance methodologies in order to "fix" this ]theoretical "problem"? This argument is an argument against X terminals instead of workstations and is an obvious straw-man, since the network bandwidth for engineering use on a single subnet is considerable. One 10Mb/s wire is only capable of supporting 260 full bandwidth 38.4 connections going on simultaneously. X bandwidth is considerably higher ieven though typical usage of text terminals would not consume the full 38.4 per terminal, and drops the number of supportable sessions considerably -- to well below the 254 addresses allowed on a typical 8 bit logical subnet. The problem then is to reduce wire traffic, and the simplest way to do this effectively is to divide by 2-3 the number of packets on the wire by moving the window manager into the terminal. Of course the swap traffic for an equivalent diskless (or even dataless) Sun systems makes them equally unacceptable, especially given their typical swap-from-image-instead-of-using-swap architecture makes them ridiculously NFS intensive (given Sun's religious avoidance of client caching at the cost of a few getattr's). The bandwidth for X is less than the bandwidth of an equivalent number of diskless/dataless machines. So in knocking down the X terminal configuration, you knock down at the same time the only other price competitive soloution, and you knock it down on exactly the same grounds. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.