Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn ) Newsgroups: net.micro.att,net.unix-wizards Subject: Re: instability in Berkeley versus AT&T releases Message-ID: <62@brl-tgr.ARPA> Date: Mon, 22-Jul-85 12:25:05 EDT Article-I.D.: brl-tgr.62 Posted: Mon Jul 22 12:25:05 1985 Date-Received: Wed, 24-Jul-85 06:33:37 EDT References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp> <964@daemon.UUCP>, <46@brl-tgr.ARPA> <514@bu-cs.UUCP> Organization: Ballistic Research Lab Lines: 80 Xref: linus net.micro.att:305 net.unix-wizards:11139 > >> There are also plenty of examples where AT&T adds a BSD feature, > >> but changes the command or system call name or syntax. Isn't that > >> referred to as the NIH (Not Invented Here) syndrome? When will AT&T > >> (and DEC for that matter) realize that UC Berkeley is NOT a competitor? > > > >There may be some "NIH" syndrome at work, but you should also appreciate > >that BSD software is not necessarily up to commercial standards, so it > >might need some adaptation before being supported by a commercial outfit. > > Ok Doug, it's fighting time. ... Hey, Barry, all I was saying is that it isn't a crime for AT&T to change some aspects of the code that they borrow from 4BSD when they integrate it into their product. I agree that there have been some very stupid decisions made in the UNIX System V packaging as well as some good ones. I am glad that they're making an effort to organize the UNIX package. I agree that there is no real networking (by Internet standards) in the AT&T product yet. TCP/IP is long overdue, but it is certainly not the ideal. AT&T has promised full ISO protocols implemented with streams, and have demonstrated a prototype full-semantics (unlike NFS) transparent remote filesystem which is expected to appear in their product "soon". I don't have 3Bs, so I don't know why you're having problems with the SGS. Our DMD SGS works fine. I thought flexnames were a standard feature now. Ptys should appear along with stream I/O, where they can be done right. The 4.2BSD "fast file system" is unnecessarily complex; AT&T is rumored to have a simple implementation of a fast file system. I don't know whether it fragments big blocks. It is funny that you take AT&T to task for providing "fsdb" and fault them for not providing other things.. 4.2BSD backup and restore is certainly an improvement over old tools. To their credit, AT&T has been improving many of the system administration procedures. Perhaps they will pick up on this one. The right way to implement file system quotas is subject to debate. I have been burned by the 4.2BSD scheme, which has some real lossages.. Unbundling is a sore point. Seems that what is really needed is a way for VARs/OEMs to sell packaged systems for minimal licensing fees, while end-users get a "rich" set of utilities in their basic package, in order to ensure that they have what is needed to support add-on software. I think the main problem is that AT&TIS sees themselves in the "iron" (computer hardware) business, not the information business. I hope they can see that UNIX is much more than just a 3B operating system. I note that they're dropping the VAX from future releases; is DEC going to fill in for them or are they going to keep Ultrix a 4BSD look-alike (or both)? The PWB/Graphics and Plot facilities are scheduled to be replaced by something else, probably based on GKS. Specs have not yet been published. I don't have any real stake in "playing apologist" for AT&T. I too have chastised them publicly for their mistakes. I do think, however, that there are better performance metrics than the degree to which they lift pieces of 4BSD unmodified. I hope the rumors of convergence between 4.nBSD and System V are true; otherwise, 4BSD's days are numbered. I've been doing my bit to help bring about such a merger, which does not necessarily mean that there would not continue to be two distinct systems for the different target user populations (research vs. commercial). The biggest roadblock to 4.nBSD migrating in a System V direction seems to have been the silly policy that AT&T now has of not permitting exchange of UNIX-derived software among source UNIX licensees who have different CPU types. I agree fully with AT&T's position that there should not be two flavors of standard shell. It looks like the Korn shell may filter into the AT&T product (other than as a ToolChest add-on); if so, there would be little reason to ask for a Cshell. Ksh is very nice, is Bourne shell compatible, and does everything the Cshell can do. An AT&T UNIX user's group that could exert pressure for wanted goodies might be a good idea. The existing UNIX groups do not seem to fulfill this role. > hi doug, you're the only one who got this far. Hi, Barry! Let's hope the AT&T UNIX policy makers are listening, too.