Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!pyrdc!gmu90x!dolqci!vrdxhq!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.sources.d Subject: Re: Sun vs. 3B2 (was: Ksh availability?) Message-ID: <6640@brl-smoke.ARPA> Date: Sun, 1-Nov-87 20:24:44 EST Article-I.D.: brl-smok.6640 Posted: Sun Nov 1 20:24:44 1987 Date-Received: Thu, 5-Nov-87 22:50:44 EST References: <6615@brl-smoke.ARPA> <1957@killer.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 95 In article <1957@killer.UUCP> elg@killer.UUCP (Eric Green) writes: >"pg" is sorry compared to "less". "less" scrolls both forward and backward, >and you don't have to always be hitting return (the space bar is under my >thumb, fer cryin' out loud, why should I have to reach WAYYY over with my >little finger to hit the RETURN key?). I don't know where you got your information, but it's wrong. "pg -n" scrolls a page when either the newline or space key is pressed. "pg" scrolls backward as well as forward (and can do pattern searches), and has several other capabilities. "pg" can have some of its default behavior altered by setting configuration options (such as "-n") on the command line; you can build these options into a shell function (an "alias") if you prefer them. (Actually I usually use my own fast non-scrolling pager!) >I don't know if you've used "jove", but >I find it a nice compromise between "vi" (which is a bit simplistic), and >full-blown GNU Emacs (which is overkill a lot of the time). Yes, I use JOVE when I happen to not be using a DMD, or if I'm using a DMD and need just a quick edit, with the DMD "sam" interface not downloaded at the time. Sometimes under these circumstances I'll use "sam -d" (or even "ed") instead, depending on how much programmed editing I'll require. >I wouldn't know what Sam or Jim are, since I don't >happenn to have a $3,000 terminal hanging around, but while their user >interface might be prettier, I doubt they could hold their own against GNU >Emacs feature-wise. Let's face it, gmacs didn't get to be 1 megabyte of object >code fer nuttin'. $2200 for a 630 in small quantities, last I heard. That's considerably cheaper than a Sun. By the time one amortizes the cost of a 3B2 over the 630s it supports, the cost is similar to Suns, with no disk in your work area and files inherently sharable on a single host processor. Each 630 has a CPU comparable to a Sun's, so if you're exploiting it by interactive user interface code the speed is usually similar to Suns. As pointed out before, the system architectures for these two approaches are rather dissimilar, but the functionality is roughly comparable. You can probably find more commercial software packages for Suns than for 630/3B2s, and that may decide the issue.. >From what I've heard of RFS, it needs a bit more work before being useful for >the heterogenous networks where NFS is now chugging away. As of SVR3.1, RFS is in pretty good shape and is getting better. For heterogeneous processors, AT&T plans to use Sun's XDR, the same as is used by NFS. (I don't know if this is already in SVR3.1.) The main functional difference, apart from RFS supporting full UNIX file semantics, lies in the file protection mapping used by the two systems. AT&T's approach allows very flexible inter-system user ID mapping, while Sun's "yellow pages" sucks so badly that we refused to use it when we installed our first NFS support at BRL (we even found it preferable to impose a global UID space across all systems!). >But since job control, basic networking >etc. is pretty much public domain (since it was done at UCB), I've always >wondered why AT&T never adopted any such innovations. Turns out there was a >reason. AT&T was busy re-inventing them. Of course. And it took them ONLY 5 >years longer than UCB. I doubt that the Regents of the University of California would agree that the work done at UCB is in the public domain. The main reason (other than quality assurance) that such facilities have shown up later in AT&T UNIX System V than in 4BSD is that the AT&T developers sought the best long-term solutions, which have generally not been the same as the FIRST solutions found in 4BSD. For example, sockets act differently than other UNIX file objects and do not offer the technical advantages of streams. One has been able to obtain third-party socket implementations for UNIX System V, but AT&T waited until they had a superior networking technical base (STREAMS) before releasing it as part of their product. The System V approach is a better long-term solution; however, I have to agree that it was needed quite some time before it finally appeared. The head start that NFS has obtained may prevent RFS from ever displacing it; we'll have to wait and see. Another major factor affecting UNIX System V has been AT&T's desire to maintain object compatibility across releases. Although the Berkeley developers have paid some attention to this also, they haven't been nearly so concerned about it as AT&T. This certainly constrains the effects allowed when innovations are added to the product. I have nothing against Suns; we have some and plan to get lots more. However, AT&T's UNIX developers have not been sleeping either (at least not recently). If all goes approximately as planned, the merged SunOS/System V product line should be a real winner in a few years.