Sun-Spots-Request@RICE.EDU (Scott Alexander) (02/19/86)
SUN-SPOTS DIGEST Tuesday, 18 Feb 1986 Volume 4 : Issue 5 Today's Topics: On March 1, >1-user Suns cost $2K more Replacing VAXes with SUN/3s (2) vfont format. (3) CLU for the SUN Re: lock removal by tip Pixrect depth bugs UNIFORUM demos/announcements?? question to whomever... SUN 1Mb -> 4Mb conversion Speed of Sun 3/50 are ie boards needed on clients? SUN draw program wanted Need a good (fast, cheap) printer for bitmap images. Changing your cursor in a ttywindow.... ------------------------------------------------------------------------ Date: Mon, 17 Feb 86 21:46:32 PST From: hoptoad!gnu@lll-crg.ARPA (John Gilmore) Subject: On March 1, >1-user Suns cost $2K more I found a giant whammy in Sun's latest price list (effective January 22, 1986), on page 31. I'll just quote and then I'll comment. "Right to Use Licenses for Latest Revision of Sun-2 or Sun-3 System Software Note: 1. Prior to March 1, 1986, all workstations ordered (except the 3/52M) include a 16-user right to use. 2. Effective March 1, all workstation ordered (except the 3/52M) must include on the customer order one of the following licenses. 3. A license can only be purchased with a workstation on the same order. 4. Licenses may be upgraded later to add more users (see below). 5. NO MEDIA OR MANUALS ARE INCLUDED. See previous page. Maximum Number of Concurrent Users Allowed (See Sun Object Code License for Details) Single-user 16-user 32-user 64-user Unlimited SYSL1 SYSL16 SYSL32 SYSL64 SYSL64P No charge $2,000 / A $4,000 / A $10,000 / A $20,000 / A " unquote. I've talked to some of the people at Sun about this and indicated that, both as a customer and a stockholder, I think this is a bad idea. They seem disinclined to change it, so I thought I'd better warn you-all that you should either scream loudly enough to get it changed, or order your upcoming systems before March 1st. Legally, if you attach a terminal to a Sun Workstation on one of the serial ports, you are required to pay the extra $2000, effective March 1st. So it both raises the quotable price of each workstation by $2K *and* it encourages customers to order the single-user license and deliberately break their license agreement. PS: The "/ A" after the prices is the discount category. PPS: After you have ordered the workstation, you can upgrade to a higher-cost license for the difference in cost plus $200. Except when going from a 32-user license, when it's the difference + $1200. Either they want to discourage 32-user licenses or they can't subtract. ----------------------------- Date: Sun, 9 Feb 86 13:12:16 EST From: bzs%bostonu.csnet@CSNET-RELAY.ARPA Subject: Replacing VAXes with SUN/3s At Boston University Computer Science we have sold our VAX/780 and replaced it with two SUN/3 systems. Among other things we make extensive use of NFS to make logging into either system quite transparent to the user, we hope to extend this to more systems and of course to extend it to people's desks. So far it seems to be quite good although I would still like to hold off on specific experiences for a few weeks (we are still waiting delivery of a few pieces which aren't scheduled until early March.) If there is interest I could put together an overview of our experiences. Without going into specifics I would say yes, this is something worth looking into. We more or less managed to finance the cost of the upgrade out of the resale value of the VAX which I still am fairly amazed at. -Barry Shein, Boston University ----------------------------- From: John Lee <mcvax!edcaad.ed.ac.uk!john@seismo.css.gov> Date: Tue, 11 Feb 86 12:53:15 GMT Subject: Re: Sun 3 as VAX replacement. Sorry for misleading you, but what I should have typed was 3/160 or 3/180 rather than 3/75. If I can get any more info. from you as to whether these bigger machines will successfully fill the role of a VAX, I should be most grateful. Thanks, John Lee. ----------------------------- Date: Mon, 10 Feb 86 00:02:22 est From: mark@mimsy.umd.edu (Mark Weiser ) Subject: vfont format. It turns out there is a sun supplied tool, called /usr/lib/vswap, which converts vax vfont format to/from sun vfont format. See man vswap on your sun for more into. (Thanks to Bill Shannon of Sun for pointing this out). -mark [And thanks to all the others who responded to sun-spots with notes about vswap. I only included the most complete of these messages since there was much overlap of information. ---dsa] ----------------------------- Date: Mon, 10 Feb 86 11:25:27 pst From: swagman%swagman@SUN.ARPA (Patrick J. McEvoy) Subject: vfonts > 4.2bsd came with a huge directory called /usr/lib/vfont. When I > try to use the fonts in here on my sun (i.e. look at them with fonttool), > I get the message that they are not in vfont format. Is this a byte-order > problem, or did vfont format change? > > [By 4.2bsd, I assume you mean the VAX version. Talking to the people here > who have played with vfonts I found that to move the fonts you need to > byte swap the shorts in the header of the file and to pad the rows to word > rather than byte boundaries. ---dsa] Three things: First, take a look at vswap(1). This program takes care of the VAX/Sun byte ordering problems. vfontinfo(1) is also helpful. Second, Sun also ships all those fonts. They come off the distribution tape when you load the vtroff optional software. Third, beware. Fonttool does not work too well on variable pitch fonts. It assumes that all characters are as large as the max size. Also, the suntools and sunview terminal emulators do not work well with variable pitch fonts. ----------------------------- Date: Mon, 10 Feb 86 19:14:30 CST From: William LeFebvre <phil@dione> Subject: Re: vfont format > [By 4.2bsd, I assume you mean the VAX version. Talking to the people here > who have played with vfonts I found that to move the fonts you need to byte > swap the shorts in the header of the file and to pad the rows to word rather > than byte boundaries. ---dsa] Point of clarification: the bitmap rows should be padded to shortword boundaries (16 bits). The term "word" is, at the least, ambiguous. William LeFebvre ----------------------------- Date: Mon 10 Feb 86 12:41:23-EST From: Paul R. Johnson <PRJohnson@XX.LCS.MIT.EDU> Subject: CLU for the SUN With respect to the announcement of our release of an implementation of CLU for the SUN Workstation: Only send simple requests for the license form to Anne Rubin at the address given. If you have ANY other questions please send them to me: Paul R. Johnson M.I.T., L.C.S. 545 Technology Square, Room 531 Cambridge, Mass. 02139 (617) 253-1945 PRJohnson@XX.LCS.MIT.EDU Thank you. ----------------------------- Date: 11 Jan 86 (Sat) 12:26:47 EST From: Sam G. Fulcomer <sgf@brunix.uucp> Subject: Re: lock removal by tip something easier than changing code is chowning uucp the uucp directory, chowning uucp tip, and chmodding 4*** tip. ----------------------------- Date: Mon 10 Feb 86 09:48:23-PST From: Neil Hunt <Nhunt@SRI-KL> Subject: Pixrect depth bugs I first noticed problems when attempting to write text to a retained graphics subwindow on a colour sun; the pw_text fails to notice that the destination pixwin is depth 8, while the source is depth 1, and the text is written compressed into one eigth of its normal width, and looks almost as if the letters have been slotted into the page sideways ! The problem only occurs when the pixwin is retained, and the depth of the destination pixrect is greater than the depth of the source pixrect (1, in the case of pixfonts). I next tried simply creating a mem_pixrect of depth 8, and writing text to it with pf_text and pf_ttext, then pw_rop'ing it to a window. Same results ! I wasn't sure how pf_text used pf_rop or pf_replrop, so I decided to see if it was some problem at the interface level; I rewrote pf_text in terms of pf_rop's of the actual pixrects from the pixfont. This was slower (probably because I was very naive about locking) but worked fine with destination pixrects of depth 1; however, this time, *nothing* appeared in mem_pixrects of depth 8 ! Not having any source code for pixrect library stuff, I debugged the object code. I examined the program after it had allocated a mem_pixrect of depth 8, and discovered that the pf_rop macro calls a function called mem_rop for a memory pixrect. I examined this function, and discovered that it checks that the source and destination pixrects are the same depth, and if not, returns -1 without any further work ! I re-read my documentation, and checked that it really did say that pixrects of depth 1 can be used as sources in an operation on destination pixrects of *any* depth. Clearly I have found a "not implemented" bug. There are still some unexplained phenomena: Clearly pf_text and pw_text work to destination pixrects of depth 8 when the destination is not a memory pixrect; otherwise one couldn't have text on a colour sun ! This is reasonable, as the pf_text macro will call a different function for each different kind of destination pixrect. What I cannot understand is how text in a retained window comes out compressed. I would have expected that either (1) The text would be written to the retained memory pixrect and then copied to the screen with a pw_rop of the entire bounding rectangle, or (2) The text would be written to the retained pixrect with a pf_text, and then to the screen with a pw_text. In case 1, nothing would appear on the screen, as it is clearly impossible to write text directly into a memory pixrect when mem_rop (called also by mem_replrop) refuses to touch it. In case 2, the text should appear correctly on the screen at the time written, but should disappear completely from the first repair of damage. In neither case should the observed effect where the text is written as if the screen were 1 bit deep be observed. A- Has anyone else had problems, or has anyone got any further light to shed on the subject ? B- Has anyone written a fix yet ? I am thinking of writing an alternative mem_rop function which could be substituted for the existing mem_rop as each mem_create returned. PS: I checked the code on our brand new sun 3's, and although they run much faster, the results are identical, so clearly sun hasn't fixed the problem yet ! Neil/. Nhunt@sri-kl.arpa (415) 496 4708 ----------------------------- Date: Fri, 14 Feb 86 18:27:33 est From: Ken Mandelberg <km%emory@CSNET-RELAY.ARPA> Subject: UNIFORUM demos/announcements?? Can anyone summarize what Sun demonstrated and announced at Uniforum? For example, I have heard that Sun was showing a PC running NFS, but did not show a 3B2 running NFS (or a Sun running RFS) as earlier expected. This is all rumor, I wasn't at UNIFORUM. Hence the question. Ken Mandelberg Emory University Dept of Math and CS Atlanta, Ga 30322 {akgua,sb1,gatech,decvax}!emory!km USENET km@emory CSNET km.emory@csnet-relay ARPANET ----------------------------- From: lerner@isi-vaxa.ARPA (Mitchell Lerner) Date: 13 Feb 1986 1050-PST (Thursday) Subject: question to whomever... Will/does Sun Unix 3.0 incorporate (partially or fully) the performance (kernal) and/or functional mods found in 4.3BSD??? lerner@isi-nova.arpa ----------------------------- Date: Sun, 16 Feb 86 05:39:40 EST From: rpics!fujiirm@seismo.css.gov (Roger M. Fujii) Subject: SUN 1Mb -> 4Mb conversion I'm interested in retrofitting the SUN 1Mb board with 256K drams. Has anyone done this? It seems straight-forward, but I am uncomfortable in trying to do this without schematics (who knows, you might have to cut a trace on the 2nd layer on the board :-)) Roger Fujii ----------------------------- Date: Mon, 17 Feb 86 01:52:33 est From: Ken Mandelberg <km%emory@CSNET-RELAY.ARPA> Subject: Speed of Sun 3/50 I tried running the Dhrystone benchmark on a Sun 3/50 workstation. I was expecting it to run 10% slower than our Sun 3/160 because of the 10% slower clock. Instead I found that it actually ran 25% slower. There must be some additional architectural change beside the clock to explain this. Any ideas? ----------------------------- From: allegra!mp@seismo.CSS.GOV Date: Tue, 11 Feb 86 22:25:54 est Subject: are ie boards needed on clients? Because of the rumored demise of nd in release 3.2, we're going to start running NFS here when 3.0 comes. We're definitely going to get the Sun ethernet boards for our 6 file servers, but not everyone I've talked to at Sun thinks that these boards are necessary for clients (of which we have 40 with the 3com boards, so this would be a major expenditure). Has anyone done a comparison to see if they really help? Mark Plotnick allegra!mp ----------------------------- Date: Thu, 13 Feb 86 15:33:34 est From: dewitt@cca-unix.arpa (Mark DeWitt) Subject: SUN draw program wanted Does anyone out there have a reasonably reliable, not necessarily fancy draw program which will run under SUN BSD 4.2 Version 2.0 and for which s/he can send us the source? We would like to do a mock-up of the output of a graphical demo before we write the demo code itself, and for that we need a tool that will allow us to create, save, and restore pictures roughly the size of a standard terminal subwindow (or smaller). We will hack something out of icontool.c if we must, but we'd rather not bother if someone else already has. We are not interested in producing hard copy, only in getting pictures to and from the display. I should note that I tried using the 'draw' program supplied in the demo directory but couldn't get it to do much of anything. If you have source to such a program, please mail me a description of its functionality (needn't be a manual, but a page or two would be helpful) along with the program. Thank you in advance. ----------------------------- Date: Fri, 14 Feb 86 10:07:34 est From: rochester!srs!matt@seismo.css.gov (Matt Goheen) Subject: Need a good (fast, cheap) printer for bitmap images. We are in the market for a printer for our systems that can print bitmap images at a good clip (i.e. we are currently using an Epson and slow just doesn't describe the speed). We would like something that is a good trade off between high speed and price. Since serial transmission is so slow, something that hooks up to the Multibus (we have all Sun-2's - 50's, 170's and a 120) would seem to be a requirement. Even a VME based product would probably be ok. We have heard of the Versatec printer but the price was part of what we heard. Any recomendations? Matt Goheen S.R. Systems UUCP (only): {allegra,seismo}!rochester!srs!matt ----------------------------- Date: Wed, 12 Feb 86 10:49:35 PST From: gerolima@Ford-wdl1.ARPA (Mark Gerolimatos) Subject: Changing your cursor in a ttywindow.... Change the cursor (mouse) in a shelltool? NO! YOU DON'T HAVE TO MODIFY SHELLTOOL.C!!!!! Changing a cursor (as well as ALL WIN_xxxxx calls, I think) is an IOCTL call that takes the UNIX file descriptor for the window. It DOES NOT NEED THE TOOL INFORMATION. Therefore, as long as you know what window you're in (using the WINDOW_ME environment variable), you can take control over your cursor! There are both {ad,and dis}advantages to doing it this way... -> You MUST change the cursor on a window-by-window basis (IE: each time you call up a new ttytool, you have to run this program) Actually, this might be useful... -> You need not keep a HUGE binary in some /.../local/.../bin directory. But, hey! Who cares? All I know is that it shore is neato! The program: /* CHANGE CURSOR (Mark Gerolimatos, gerolima@ford-wdl1.arpa): ** change to an XOR'd cursor.... ** ** Of course, you can always add stuff in to look at the command ** line (or even the cursor!), and change other things like the ** different function (other than XOR), cursor shape, etc..... ** ** to make: cc -o <whatever> change_cursor.c -lsunwindow -lpixrect ** */ #include <stdio.h> #include <sys/file.h> #include <sunwindow/window_hs.h> unsigned char mr_pixrect_b [16] [16]; mpr_static(mr_pixrect,16,16,1,mr_pixrect_b); struct cursor mr_cursor = { 0,0,0,&mr_pixrect}; main() { int fd; /* Look in the environment for a window_me... */ char *mywin = (char *)getenv("WINDOW_ME"); /* I can't remember what getenv returns on failure... */ if((!(strcmp(mywin,""))) || mywin == NULL) { fprintf(stderr,"Could not find window\n"); exit(1); } /* get the UNIX file descriptor on the window */ if( (fd = open(mywin,O_RDWR)) < 0 ) { fprintf(stderr,"Could not open window\n"); exit(1); } win_getcursor(fd,&mr_cursor); mr_cursor.cur_function = PIX_SRC ^ PIX_DST; win_setcursor(fd,&mr_cursor); } "For almost a quarter of a century..." "Eeez next... Mark Gerolimatos SOFTVARE!.... ARPA: gerolima@ford-wdl1.arpa verrrry niiice..." UUCP: {sun,fortune}!wdl1!gerolima ----------------------------- End of SUN-Spots Digest ***********************