yarvin-norman@CS.YALE.EDU (norman yarvin) (02/14/90)
In article <1089@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: > Discussions about porting X-windows to the UNIX-pc can be > summarized in one sentence, "X windows can be ported to the > UNIX-pc, but we need someone to write it." Nobody at the BOF > volunteered to port X, but the MGR demonstration did spark > some additional enthusiasm about doing it. On a Sun, the X11R3 server takes 500K for the code segment and over a megabyte total. On the Unix PC, less storage would be required for window data (because of the smaller screen), but the server alone would still take up a substantial percentage of the memory. The X clients together generally take more memory than the server. X was too big for the Sun-2, another 68010 machine; a friend who tried running X on a Sun-2 says that the machine was very slow, and would crash under the high load. In summary, X is much too big and slow for the Unix PC, even if someone were to port it. The Unix PC is a slow machine with a small amount of memory. Some comments on Fixdisk 2.0: First, I unpacked it by hand (in case of any AT&T treachery...). In the process, I discovered a couple of things in the Install files that deserve comment. (Each fix has its own directory and Install file; a central Install file runs the Install file in all the directories.) 1) The Install file for the ATE fix creates the file /usr/lib/ua/ate_info with permissions 666 (as follows, starting from line 20): | # Create /usr/lib/ate_info and make 666 for permissions fix | > /usr/lib/ua/ate_info | chmod 666 /usr/lib/ua/ate_info I have no idea why a blank file called ate_info should be created, much less why everyone should be able to bash it. 2) The Install file for the kernel fix contains the following code (starting from line 26): | echo "Unpacking window driver --- please standby ...\c" | unpack wind.o 2>/dev/null | echo | mv /etc/lddrv/wind.o /etc/lddrv/wind.o.OLD | mv ./wind.o /etc/lddrv/wind.o | chown bin /etc/lddrv/wind.o | chgrp bin /etc/lddrv/wind.o | chmod 644 /etc/lddrv/wind.o | rm -f wind # Force a new one to be built The last line, "rm -f wind", does not work, because the routine has not changed directory to /etc/lddrv. Does anyone out there know the difference between "wind" and "wind.o", and how "wind" would be rebuilt? I decided not to remove "wind", seeing as the fix had probably worked fine on lots of other machines. The second comment on 3.51m is that a bug which has made me reboot quite a few times still exists. It is activated by the following sequence: (rm /usr/spool/uucp/LCK..ph0) (kermit; starts up on line /dev/ph0 at 1200 baud) (phtoggle, from another window) at which point the Phone Mangler switches its window to display "DATA 1:", followed by the screen blanking as the machine crashes, followed by a relay clicking five seconds later. (no, the relay bit isn't really that significant.) Configuration: Kermit (don't know version # off hand), Fixdisk 2.0 phone manager, Unix 3.51m kernel, phtoggle from Foundation Set 3.51, stock 67MB/2MB 3b1. Well, not quite stock; I put in a new clock battery. The problem only occurs on the first use of the phone after booting the machine. Workaround: running phtoggle twice before the above sequence. This sequence is the only way I have found to get kermit to work. Starting up kermit with the line already in DATA mode does not work, and not removing the lock does not work -- kermit detects the lock, and refuses to open the line. I don't remember what else doesn't work. Normally, after the steps mentioned above, I dial from within kermit. This produces the message "Can't release lock file" (or something similar), then "Dialing xxx-yyyy, /dev/ph0, 1200 baud" (or something similar). Sometimes the dialing does not start until I hit ^\, kermit's interrupt key, after which all is OK. After the phtoggle, the disk starts a repetitive pattern of accesses, which continue indefinitely until kermit starts dialing. My last comment on 3.51m is that loading device drivers seems to take longer. I have not verified this by a stopwatch (I will soon), but after each driver is loaded, the system seems to wait for maybe 5 seconds before loading the next. I would not notice this, except that I have modified /etc/.drvload to display to the screen rather than to /tmp/<whatever>. I load two drivers: lipc (SYSV IPC) and dup (Ford's /dev/fd/* device driver). After each there is the pause. The modified .drvload follows: (I do suggest installing it.) # # called from /etc/rc to load drivers at boot time: # /etc/.drvload # requires: # /etc/master (with entries for loadable devices) # /etc/lddrv (directory) # /etc/lddrv/lddrv (setuid root) # /etc/lddrv/mkifile # /etc/lddrv/drivers # .o files for loadable drivers in /etc/lddrv # if [ ! -f /etc/lddrv/drivers ] then exit fi cd /etc/lddrv exec < drivers find . -name unix.sym ! -newer /unix -exec rm {} \; if [ ! -r unix.sym ] then echo creating unix.sym ./mkifile /unix unix.sym fi # Addition by F. Dewey 5/86 to take care of drivers that cause a panic # during binding. The name of the current driver is kept in /etc/current.driver # so that if, on the reboot after a panic or hang, the file contains # the name of a driver, that driver is removed from the /etc/drivers # file for subsequent bootups. if [ -s /etc/current.driver ] then read driver </etc/current.driver rm -f /etc/current.driver echo "Removing problem driver $driver" grep -v $driver /etc/lddrv/drivers >/tmp/$$.drv mv /tmp/$$.drv /etc/lddrv/drivers exec < drivers fi while read driver do echo $driver >/etc/current.driver sync;sync;sync sleep 1 if [ -z "$driver" ] then continue fi ./lddrv -q $driver if [ "$?" != "0" ] then ./lddrv -av $driver retcode="$?" else retcode="0" fi if [ \( "$retcode" = "0" \) -a \( -x ./${driver}.rc \) ] then ./${driver}.rc retcode="$?" if [ "$retcode" != "0" ] then ./lddrv -dv $driver fi else if [ \( "$retcode" != "0" \) -a \( -x ./${driver}.brc \) ] then ./${driver}.brc fi fi if [ "$retcode" != "0" ] then echo "Error loading driver $driver" fi # if we got this far, the current driver didnt cause a panic or # system hang, so it is OK to remove it from the current driver.file. rm -f /etc/current.driver done exit 0 Norman Yarvin yarvin-norman@cs.yale.edu "The blastoff looked much like the Challenger, except it appeared to take place at night and there was no subsequent explosion"
lenny@icus.islp.ny.us (Lenny Tropiano) (02/15/90)
In article <15523@cs.yale.edu> yarvin-norman@CS.YALE.EDU (norman yarvin) writes: |>In article <1089@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: |>> Discussions about porting X-windows to the UNIX-pc can be |>> summarized in one sentence, "X windows can be ported to the |>> UNIX-pc, but we need someone to write it." Nobody at the BOF |>> volunteered to port X, but the MGR demonstration did spark |>> some additional enthusiasm about doing it. |> |>On a Sun, the X11R3 server takes 500K for the code segment and over a |>megabyte total. On the Unix PC, less storage would be required for window |>data (because of the smaller screen), but the server alone would still take |>up a substantial percentage of the memory. The X clients together generally |>take more memory than the server. |> [...] I probably not the correct person to comment on this, but doesn't X11 have quite a bit of networking code in it to handle X windows over a network medium. Since the UNIX pc doesn't have any "great" network, other than STARLAN, wouldn't it be wise to remove this from the X server? Could this be done to keep the X applications and server down in size? I still don't know if this will make it feasible for the UNIX pc. -Lenny -- | Lenny Tropiano ICUS Software Systems lenny@icus.islp.ny.us | | {ames,pacbell,decuac,hombre,sbcs,attctc}!icus!lenny attmail!icus!lenny | +------- ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752 -------+
alex@umbc3.UMBC.EDU (Alex S. Crain) (02/16/90)
In article <1093@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >I probably not the correct person to comment on this, but doesn't X11 have >quite a bit of networking code in it to handle X windows over a network >medium. Since the UNIX pc doesn't have any "great" network, other than >STARLAN, wouldn't it be wise to remove this from the X server? There isn't alot of networking code in the X server. X relies on a generic packet based protocol which would still have te be supported regardless of the transport mechinism. The X port shouldn't be difficult, especially as R4 claims to have dramatically reduced the amount of heap memory required by the server, but I still don't see it as a realistic option for this machine because of its size. Its incredably flexable, but the unix-pc just ain't big enough to run it. Even if the server runs ok, the really cool clients would be too big, so all you would get is X, uwm, xclock and xterm (maybe xlogo :-)). I've seen mgr. It's really cool, its small, it FAST, and it's based on pty's so theres no special libraries, etc. One could presumably port the I/O manager that the mgr guy was talking about at USENIX. It appears to offer everything that one could reasonable expect from X and its available now. I'm certainly going to put it up as soon as I get around to it. ################################# :alex. #Disclamer: Anyone who agrees # University of Maryland Baltimore County #with me deserves what they get.# alex@umbc3.umbc.edu #################################
yarvin-norman@CS.YALE.EDU (Norman Yarvin) (02/16/90)
In article <15523@cs.yale.edu> yarvin-norman@CS.YALE.EDU (Norman Yarvin) writes: >Configuration: Kermit (don't know version # off hand), Fixdisk 2.0 phone It identifies itself as: C-Kermit, 4C(058) 19 Mar 86, AT&T System III/System V >My last comment on 3.51m is that loading device drivers seems to take longer. >I have not verified this by a stopwatch (I will soon), but after each driver >is loaded, the system seems to wait for maybe 5 seconds before loading the >next. This didn't happen the second time I booted; the speed was normal. From this I am willing to make a conjecture about how device drivers are loaded. Loadable drivers are kept in the directory /etc/lddrv, and have the suffix ".o" (e.g. "wind.o" for the window driver). The first time they are loaded, the kernel does a certain amount of work resolving addresses (the 'ld' part of the program /etc/lddrv/lddrv), then saves the result in a file without the suffix (e.g. "wind"). This resolving-addresses took the extra time on the first boot. I noticed another effect of installing 3.51m: the new kernel took much more time to load from disk -- about 7 times as many seeks. Guess it's time to pull out that disk de-fragmenter... The new kernel also prints out "Disk Cntrlr = WD1010" on bootup. Lenny Tropiano writes: > I probably not the correct person to comment on this, but doesn't X11 have > quite a bit of networking code in it to handle X windows over a network > medium. Since the UNIX pc doesn't have any "great" network, other than > STARLAN, wouldn't it be wise to remove this from the X server? Could this > be done to keep the X applications and server down in size? I still don't > know if this will make it feasible for the UNIX pc. I don't know. But if anybody gets the total size of X (server + xterms) below 1 MB, I will be very surprised. Many people out there only have 1 MB, and few have more than 2. -- Norman Yarvin yarvin-norman@cs.yale.edu "Outside of a dog a book's a man's best friend. Inside a dog it's too dark to read." -- Groucho Marx