Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/15/88)
SUN-SPOTS DIGEST Friday, 12 August 1988 Volume 6 : Issue 180 Today's Topics: Re: Whither 68030 The "open systems" approach to disks and controllers? tracing opens 'stuck' pty's Got the CAPS key blues? manual binders for SunOS 4.0 "Unsharing" libraries under 4.0 Running All Your Clients with One root Problems with dbx under sys4-3.2 SMI SCSI in 3/50, 3/60, 4/110? multiple .ttyswrc ? Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Sun, 7 Aug 88 20:55:55 PDT From: ultra!shj@ames.arc.nasa.gov (Steve Jay) Subject: Re: Whither 68030 Reference: v6n167 In sun-spots v6n167, Don Speck (speck@vlsi.caltech.edu) wants to know what, if anything, Sun is doing with the 68030. Without having any information from Sun, I can think of two responses: 1) who cares? 2) do you really think Sun is going to continue to produce machines with three (680x0, 386, and SPARC) non-compatible architectures? Is there something that a 680x0 based system would do better or cheaper than a system based on one of the other two processors? Who cares what instruction set the processor is executing? I happen to believe that the 680x0 processors are much neater [and closer to the way God intended things to work :-)] than the rather baroque x86 processors, but when it comes right down to it, my workstation could be executing the 1401 instruction set, as long it greps when I tell it to grep. I suspect Sun would prefer to sell only their own designs, but there's a huge pile of PC/x86 software out there that people want to run, and the 386i gives Sun a way of selling a machine that can run it, and still be a Sun. There isn't much 680x0 specific software, except for Mac stuff. Unless it becomes possible to clone Mac's (over Apple's dead body, I suspect) I can't see what's in it for Sun to continue manufacturing 680x0 based machines. It's probably necessary for me to say that I have no association with any of the companies involved, and these opinions are strictly my own. Steve Jay domain: shj@ultra.com Ultra Network Technologies Internet: ultra!shj@ames.arc.nasa.gov 2140 Bering drive uucp: ...ames!ultra!shj San Jose, CA 95131 408-922-0100 ------------------------------ Date: 6 Aug 88 23:35:59 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) Subject: The "open systems" approach to disks and controllers? Recently we have been finding Sun's approach to disk controllers increasingly frustrating. We have been buying Ciprico Rimfire controllers recently. The Suns are fine machines. But the XY451 controller (despite all rumors of newer XY controllers, this is still all you can from Sun) are clearly at least one generation out of date. To put such a thing on a Sun 4 is particularly absurd, but even with Sun 3's, there are benefits to using the Ciprico controller. On the other hand, our Sun support is fairly good, and we'd like to get as much from them as possible. Anyway, recently I wanted to add a file server. I ordered a 3/140 (the cheapest system that will support an SMD controller), and attempted to buy the whole disk subsystem from Sun except for the controller. What I tried to order was one of the new Hitachi disks plus the mounting shelf. That's all there is to a subsystem except for the controller and cables. What I found is that it is impossible to order the shelf from Sun, even from the maintenance catalog. Our salesman went to fairly high levels in Sun about this. It appears that Sun is trying to avoid losing peripheral sales, and so they are selling only full disk subsystems. Well, the result is obvious: since they wouldn't sell us the shelf that we needed in order to mount the disk, we had no choice but to start looking around at outside disk vendors. Once we do that, it's silly not to buy the disk from them as well. So they lost the entire peripheral sale, when all we really wanted to do was to avoid getting yet another XY451. We're also upset about the new policy about boot ROM's. It is possible to get boot ROM's for Ciprico controllers for Sun 3's. Sun apparently won't sell the source needed to do this, but they would allow Ciprico to pay them to make the ROM, as a consulting project. Apparently they've decided not to do this for the Sun 4. Sun will only allow Sun-supported devices to be used as boot devices. This is another one of these silly policies that is just going to cause trouble. In this case it's going to cause trouble to Sun field service. We're not about to keep using XY451's because Sun is being stubborn about boot ROM's. Instead we're planning to boot our large multi-user Sun 4's over the Ethernet (which is a Sun supported device). The concept of a 2 disk multi-user machine on which you can't run standalone diagnostics can't make field service real happy. It also modifies the way to set things up, since previously these were the first machines we brought up after power failures, and they had things like the primary name servers. I guess we'll now have to depend upon Pyramids to be our primary servers. Kind of supports all the things Pyramid has been saying about Sun... Guys, is it really worth all this to keep your customers from buying Ciprico disk controllers? Particularly not when all you're selling are the blasted XY451's? I'm not interested in rumors about the wonderful controllers you're going to sell us Real Soon Now. Those rumors have been around for a year. I'll start buying your controllers when you're ready to deliver controllers that are as good as the Ciprico ones. But until then, you can't be obstinate about supporting customers who are using the best available technology. It makes your products look good. ------------------------------ Date: Sun, 7 Aug 88 11:36:14 EDT From: smb@research.att.com Subject: tracing opens SunOS 4.0 can be configured to run in ``C2 mode'' -- a mode that's supposed to be certifiable (but not actually certified) by the National Computer Security Center as meeting the C2 requirements in the Orange Book. And that mode in turn requires the ability to audit file operations, including opens. So -- when you upgrade to 4.0 you may not need to make that mod. ------------------------------ Date: Sun, 7 Aug 1988 12:53-EDT From: Ralph.Hyre@ius3.ius.cs.cmu.edu Subject: 'stuck' pty's I believe that the only real solution pty open code needs to be fixed, since many programs will change the mode of this file when they're running, which makes it difficult to support users running on the console vs. remote users. X10 xterm, in.rlogind, and in.telnetd are the most heavily used examples that come to mind. - Ralph ------------------------------ Date: Mon, 8 Aug 88 09:24:09 EDT From: sjs@ctt.bellcore.com (Stan Switzer) Subject: Got the CAPS key blues? Got those low-down, can't tell your CAPS mode's on, vi's actin' strange, and undo don't work blues? If you are using NeWS (yes, this is a plug), you can stick the following into your user.ps file to disable the obnoxious caps-lock key: % % Disable Caps-Lock Key % /CapsEnable { UI_private begin /compute_shift_states exch { { % enabled version (original) /letter_shift_state control_keys_down 0 gt 0 { caps_keys_down 0 gt shift_keys_down 0 gt or 1 2 ifelse } ifelse store /other_shift_state control_keys_down 0 gt 0 { shift_keys_down 0 gt 1 2 ifelse } ifelse store } } { { % disabled version /other_shift_state control_keys_down 0 gt 0 { shift_keys_down 0 gt 1 2 ifelse } ifelse store /letter_shift_state other_shift_state store } } ifelse store reset_shift_state end } def % you can turn CAPS back on with "true CapsEnable" false CapsEnable OK, it's not exactly obvious, but it works! Stan Switzer sjs@ctt.bellcore.com ------------------------------ Date: Sun, 7 Aug 88 12:52:04 CDT From: monty%tartarus@gargoyle.uchicago.edu (Monty BSD) Subject: manual binders for SunOS 4.0 our man packs for 4.0 fit into 16 3 inch D ring binders, although we mixed some sections of the documentation into the same binder occasionally (usually related material, such as the C, assembler and floating point manuals being in the same binder). you could probably manage a 'one section, one binder' approach (except for the reference manual, which takes 3 binders), but then you probably also would want to vary the size of binders too. also, you'll probably want additional binders for the hardware installation manuals. we haven't bothered using binders for the beginner manuals since they come in bound, glossy covers and since they move around to new users as we add them to our net. as for the idea of using a long rack for manuals (a la large ibm sites), we don't use that because we prefer to have to option to take the manuals to our desks when using them. ------------------------------ Date: 7 Aug 88 12:44 -0700 From: Dave Gagne <daveg@ee.ubc.ca> Subject: "Unsharing" libraries under 4.0 When I was trying to set up an anonymous ftp account on one of our Suns running SunOS 4.0, I ran across an interesting problem. The problem concerns the use of shared libraries in 4.0. I set up the ftp account as described in the manuals, creating an id "ftp" with a "bin", "etc", and "pub" directories in ~ftp. In etc there is a "passwd", and a "group" file. In bin I put "ls". Then, when I sign in as "anonymous" using ftp and use the command "ls" I get the error: crt0: no /usr/lib/ld.so This occurs because ftp (or ftpd?) does a "chroot" to ~ftp when someone signs into the anonymous ftp acct. Then, of course there is no /usr, and the linker can't find any of the shared object modules (and in fact, the linker itself can't be found). It is possible, of course, to put a copy of ld.so in ~ftp/usr/lib, but the shared object modules, etc, still cannot be found. What I did was to copy a version of ls from a machine running 3.2, and then things worked OK, but this seems to be a poor solution. My question, then, is: Is it possible to "unshare" libraries for an executable file compiled for use with shared libraries? That is, can I take the ls from 4.0 and link the various shared object modules permanently into it? And can I do it without source code? I believe I could compile a C program with options telling the lnker NOT to use shared libraries (is this true?) [[ yes: "cc -Bstatic", cc passes that on to ld --wnl ]], but I don't have the source code, so it is a moot point here. Dave. daveg@ee.ubc.ca daveg%ee.ubc.cdn%ean.ubc.ca@RELAY.CSNET ------------------------------ Date: Sun, 7 Aug 1988 12:55:56 PDT From: Eliot Lear <lear@net.bio.net> Subject: Running All Your Clients with One root Well. I just spent the weekend bringing up SunOS 4.0 and I must say that things went pretty well. (One quick note, if you install Chuck Hedrick's hack to the domain system, don't forget to put /xlb or an appropriate link on the clients). The canned setup does not vary too far from earlier releases. Unfortunately, previous releases have always been an administrative headache for big sites. These headaches occur anytime one changes something on the root directory of a client. For example, if I want to make a change in my name ordering for the resolver, I have to do this on N clients. If I want to make a change in rc.boot for some bizarre reason, I have to edit N of them. That was up until 3.X. In the environments I work in, it is a lot nicer to treat all the clients associated with a particular server as one system when possible. There are some exceptions, but this is the rule. The shrewd conventional answer to this problem has been symbolic links. When I saw SunOS 4.0, I said to myself, ``Why not have all the clients share one root directory?'' I will now proceed to describe this process in gory detail. The first question on everybody's mind must be, ``What about rc.boot?'' I ended up deriving the hostname by using a combination of dmesg, awk, and tail. The two latter programs gave me grief because they are both dynamically linked. Fine, I stole the 3.4 versions and they work just fine. These now lie in /sbin on my clients. Next, I needed a way to separate system dependent files like mtab, fstab, and utmp, and I also needed a separate /tmp. I created a new directory tree on the server called /export/links. This tree contains subtrees named after hostnames (in a similar vein to /export/root) and mostly contains a bunch of links that point back to various filenames such as /etc/utmp.HOSTNAME. Next, I mount this tree of links in the client's /local and I adjust the the system dependent files such as utmp to point to /local/etc/utmp, which, in turn, points back to /etc/utmp.HOSTNAME. Well.. There was a little slight of hand in the scheme to mount /local on the client. Given that you know the hostname, you can grep for your hostname in /etc/fstab (which is really a link to /local/etc/fstab) and you mount it. This means that I have a /local/etc/fstab that contains a bunch of mount points for /local. Of course all of them are ``noauto'', but this turns out not to matter. The estute person will have noticed that I am accessing /local before mounting it. In fact, this is true, but in the case of fstab and mtab, two copies exist - one under the mount point, and the one that is in /export/links that is mounted. So to summarize, here is a layout of A bunch of Suns all running of the root partition of UK.BIO.NET: 1] utmp is a link to /local/utmp which is local to individual suns. 2] Same with psdatabase. 3] Same with mtab. 4] Same with fstab (with some hackery as described above). 5] Same with messages. 6] Same with msgbuf. So far, I haven't noticed any performance gains or losses with this setup. ------------------------------ Date: Sun, 7 Aug 88 20:10:52 EDT From: mc@moc.jpl.nasa.gov (Mike A Caplinger) Subject: Problems with dbx under sys4-3.2 Has anyone else noticed some problems with dbx under sys4-3.2 on the Sun 4? It seems to lose breakpoints and single-stepping frequently; sometimes I'll try to single-step and end up with the program running all the way to termination before I get a dbx prompt back. I haven't been able to characterize when this happens, though, so a Sun bug report will need some corroboration. Mike Caplinger, mc@moc.jpl.nasa.gov ------------------------------ Date: Mon, 8 Aug 88 09:35:09 EDT From: dan@wind.bellcore.com (Daniel Strick) Subject: SMI SCSI in 3/50, 3/60, 4/110? I expect the the 3/50, 3/60, and probably the 4/110 use the older style of SCSI interface chip which requires external intelligent direction in order to negotiate most of the eight phases of a SCSI bus command. I presume the intelligent direction is provided by the SUN cpu. Can anyone verify this? Does the cpu get an interrupt after each interesting phase or does it poll the SCSI interface chip? Does anyone know if the SCSI interface for the 3/75, 3/100, 3/200, 4/200 (a standard vme card) has on board intelligence? (I recently replaced my sun-3/160 with a sun-3/60 and find that the new machine runs painfully slowly when it has to page. Only the cpu and scsi interface have changed. Everything else is the same, including the monitor and keyboard. Both machines have 4 MB main memory. The disk is one of those ~70 mb ST-506 drives with an Adaptec ACB 4000 SCSI converter card.) ------------------------------ Date: Thu, 04 Aug 88 15:18:03 SET From: Danielle Heinzer <ESC1298@ESOC.BITNET> Subject: multiple .ttyswrc ? I need to program different function keys for different windows running simultaneously. The .ttyswrc file programs the function keys for the whole screen. Can anybody tell me how to create such a file for each window ? The .ttyswrc file has to be changed as soon as the mouse points a new window. Danielle HEINZER ECD/CS European Space Operations Centre Robert-Bosch-Str. 5 6100 Darmstadt West-Germany (49)-6151-886540 ESC1298%ESOC.BITNET@cunyvm.cuny.edu ------------------------------ End of SUN-Spots Digest ***********************