a couple of historical papers on the future of BSD unix (;

8 files changed, 1090 insertions, 0 deletions

diff --git a/share/doc/papers/future/0.t b/share/doc/papers/future/0.t
new file mode 100644
index 00000000000..9950276fd0b
--- /dev/null
+++ b/share/doc/papers/future/0.t
@@ -0,0 +1,62 @@
+.\" Copyright (c) 1986 The Regents of the University of California.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"	@(#)0.t	5.1 (Berkeley) 4/16/91
+.\"
+.rm CM
+.TL
+Directions of UNIX at Berkeley
+.AU
+Marshall Kirk McKusick
+.AU
+Michael J. Karels
+.AI
+Computer Systems Research Group
+Computer Science Division
+Department of Electrical Engineering and Computer Science
+University of California, Berkeley
+Berkeley, California  94720
+.AB
+This paper gives a brief overview of the contributions to UNIX\(dg
+.FS
+\(dgUNIX is a registered trademark of AT&T in the US and other countries.
+.FE
+made by the research community and describes the needs that
+prompted the distributions from Berkeley.
+The next Berkeley system will attempt to adapt to the
+current state of technology in the areas of virtual memory 
+and file system interfaces.
+The paper makes a brief survey of this available technological base
+and then speculates on the ways in which future
+Berkeley systems will use this technology.
+.AE
+.LP
+.sp 2
diff --git a/share/doc/papers/future/1.t b/share/doc/papers/future/1.t
new file mode 100644
index 00000000000..9ae6b2ec7b0
--- /dev/null
+++ b/share/doc/papers/future/1.t
@@ -0,0 +1,158 @@
+.\" Copyright (c) 1986 The Regents of the University of California.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"	@(#)1.t	5.1 (Berkeley) 4/16/91
+.\"
+.NH
+The Role of Research in Maintaining System Vitality
+.PP
+Since the divestiture of AT&T, UNIX has become the focus of
+a massive marketing effort.
+To succeed, this effort must convince
+potential customers that the product is supported,
+that future versions will continue to be developed,
+and that these versions will be upwardly
+compatible with all past applications.
+.PP
+AT&T's size alone ensures that it will be around in years to come.
+Because the company has allocated increasing research, development,
+and support resources to UNIX over the past 10 years
+it provides an assurance of its commitment.
+Its massive advertising campaign for System V, 
+its presence on the /usr/group UNIX standards committee,
+and the publication of the \fISystem V Interface Definition\fR
+testify to the company's intention
+to remain compatible with past systems.
+.PP
+Although repeal of the law of entropy is a necessary step
+along the road to a
+viable commercial product, this runs counter to
+orderly system evolution.
+Be that as it may, AT&T's major UNIX
+commercialization effort has succeeded in making the system
+available to a much broader audience than was previously possible.
+.PP
+The freezing of what previously had been
+an ever-changing UNIX interface
+represented a major departure from the pattern that the
+small but highly skilled UNIX community had come to expect.
+Most early users had accounts
+at sites that had the source to the programs they ran.
+Thus, as the system interface evolved to reflect more current technology,
+software could be changed to keep pace.
+Users simply updated their programs
+to account for the new interface, 
+recompiled them, and continued to use them as before.
+Although this required a large effort,
+it allowed the system --
+and the tools that ran on it -- to reflect
+changes in software technology.
+.PP
+At the forefront of the technological wave
+was AT&T's own Bell Laboratories [Ritchie74].
+It was there that the UNIX system was born and nurtured,
+and it was there that its evolution was controlled --
+up through the release
+of the 7th Edition.
+Universities also were involved with the
+system almost from its inception.
+The University of California at
+Berkeley was among the first participants,
+playing host to several researchers on sabbatical from the Labs.
+This cooperation typified the harmony
+that was characteristic of the early UNIX community.
+Work that was contributed to the Labs by
+different members of the community helped
+produce a rapidly expanding set of tools and facilities.
+.PP
+With the release of the 7th Edition, though,
+the usefulness of UNIX already had been
+clearly established, and other organizations within AT&T began
+to handle the public releases of the system. 
+These groups took far less input from the community
+as they began to freeze the system interface
+in preparation for entry into the commercial marketplace.
+.PP
+As the research community continued to modify the UNIX system,
+it found that it needed an organization that could produce releases.
+Berkeley quickly stepped into the role.
+Before the final public release of UNIX from the Labs, 
+Berkeley's work had been focused on the development of
+tools designed to be added to
+existing UNIX systems.
+After the AT&T freeze, though,
+a group of researchers at
+the university found that they could easily
+expand their role to include the coalescing function
+previously provided by the Labs.
+Out of this came the first full Berkeley distribution of UNIX
+(3.0BSD),
+complete with virtual memory --
+a first for UNIX users.
+The idea was so successful that System V eventually adopted it
+six years later.
+.NH 2
+Motivations for Change
+.PP
+At the same time that AT&T was beginning
+to put the brakes on further
+change in UNIX, local area networks and bitmapped workstations
+were just beginning to emerge from
+Xerox PARC and other research centers.
+Users in the academic and research community realized
+that there were no production-quality operating systems
+capable of using such hardware.
+They also saw that networking unquestionably would be
+an indispensable facility in future systems research.
+Though it was not clear that UNIX
+was the correct base on which to build a networked system,
+it was clear that UNIX offered the most expedient means by which
+to build such a system.
+.PP
+This posed the Berkeley group with an interesting challenge:
+how to meet the needs of the community of users
+without adding needless complexity to existing applications.
+Their efforts were aided by the presence of a large and diverse
+local group of users who were teaching introductory programming,
+typesetting documents, developing software systems, and
+trying to build huge Lisp-based systems capable
+of solving differential equations.
+In addition, they were able to discuss current problems
+and hash out potential solutions at semi-annual
+technical conferences run by the Usenix organization.
+.PP
+The assistance of a steering committee composed of academics,
+commercial vendors, DARPA researchers, and people from the Labs
+made it possible for
+the architecture of a networking-based UNIX system to be developed.
+By keeping with the UNIX tradition of integrating work done by
+others in preference to writing everything from scratch,
+4.2BSD was released less than two years later [Joy83].
diff --git a/share/doc/papers/future/2.t b/share/doc/papers/future/2.t
new file mode 100644
index 00000000000..51a5cb48bba
--- /dev/null
+++ b/share/doc/papers/future/2.t
@@ -0,0 +1,184 @@
+.\" Copyright (c) 1986 The Regents of the University of California.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"	@(#)2.t	5.1 (Berkeley) 4/16/91
+.\"
+.NH
+The Future of UNIX at Berkeley
+.PP
+The release of 4.3BSD in April of 1986 addressed many of the 
+performance problems and unfinished interfaces
+present in 4.2BSD [Leffler84] [McKusick85].
+Berkeley has now embarked on a new development phase to likewise
+update other old parts of the system.
+There are three main areas of work.
+The first is to rewrite the virtual memory system to take
+advantage of current technology and to provide new capabilities
+such as mapped files and shared memory.
+The second is to provide a standard interface to file systems
+so that multiple local and remote file systems can be supported
+much as multiple networking protocols are by 4.3BSD.
+Finally, there is a need to provide more internal flexibility in a
+way similar to the System V Streams paradigm.
+.NH 2
+A New Virtual Memory Implementation
+.PP
+With the cost per byte of memory approaching that of the cost per byte
+for disks, and with file systems increasingly removed from host
+machines, a new approach to the implementation of virtual memory is
+necessary. In 4.3BSD the swap space is preallocated;
+this limits the maximum virtual memory that can be
+supported to the size of the swap area [Babaoglu79] [Someren84].
+The new system should support virtual memory space at least as great as
+the sum of sizes of physical memory plus swap space
+(a system may run with no swap space if it has no local disk).
+For systems that have a local swap
+disk, but utilize remote file systems,
+using some memory to keep track of the contents of swap space
+may be useful to avoid multiple fetches
+of the same data from the file system.
+.PP
+The new implementation should also add new functionality.  Processes
+should be allowed to have large sparse address spaces, to map files
+into their address spaces, to map device memory into their address
+spaces, and to share memory with other processes. The shared address
+space may either be obtained by mapping a file into (possibly
+different) parts of the address space, or by arranging for processes to
+share ``anonymous memory'' (that is, memory that is zero-fill on demand, and
+whose contents are lost when the last process unmaps the memory).
+This latter approach was the one adopted by the developers of System V.
+.PP
+One possible use of shared memory is to provide a high-speed
+Inter-Process Communication (IPC) mechanism between two or more
+cooperating processes. To insure the integrity of data structures
+in a shared region, processes must be able to use semaphores to
+coordinate their access to these shared structures. In System V,
+semaphores are provided as a set of system calls. Unfortunately,
+the use of system calls reduces the throughput of the shared memory
+IPC to that of existing IPC mechanisms.
+To avoid this bottleneck,
+we expect that the next release of BSD will incorporate a scheme
+that places the semaphores in the shared memory segment, so that
+machines with a test-and-set instruction will be able to handle the usual
+uncontested ``lock'' and ``unlock'' without doing two system calls.
+Only in the unusual case of trying to lock an already-locked lock or when
+a desired lock is being released will a system call be required.  The
+interface will allow a user-level implementation of the System V semaphore
+interface on most machines with a much lower runtime cost [McKusick86].
+.NH 2
+Toward a Compatible File System Interface
+.PP
+As network or remote file systems have been implemented for UNIX,
+several stylized interfaces between the file system implementation
+and the rest of the kernel have been developed.
+Among these are Sun Microsystems' Virtual File System interface (VFS)
+using \fBvnodes\fP [Sandburg85] [Kleiman86],
+Digital Equipment's Generic File System (GFS) architecture [Rodriguez86],
+AT&T's File System Switch (FSS) [Rifkin86],
+the LOCUS distributed file system [Walker85],
+and Masscomp's extended file system [Cole85].
+Other remote file systems have been implemented in research or
+university groups for internal use \-
+notably the network file system in the Eighth Edition UNIX
+system [Weinberger84] and two different file systems used at Carnegie Mellon
+University [Satyanarayanan85].
+Numerous other remote file access methods have been devised for use
+within individual UNIX processes,
+many of them by modifications to the C I/O library
+similar to those in the Newcastle Connection [Brownbridge82].
+.PP
+Each design attempts to isolate file system-dependent details
+below a generic interface and to provide a framework within which
+new file systems may be incorporated.
+However, each of these interfaces is different from
+and is incompatible with the others.
+Each addresses somewhat different design goals,
+having been based on a different starting version of UNIX,
+having targeted a different set of file systems with varying characteristics,
+and having selected a different set of file system primitive operations.
+.PP
+We have studied the various file system interfaces to determine
+their generality, completeness, robustness, efficiency, and aesthetics.
+Based on this study, we have developed a proposal for a new
+file system interface that we believe includes the best features of
+each of the existing implementations.
+Briefly, the proposal adopts the 4.3BSD calling convention for name lookup,
+but otherwise is closely related to Sun's VFS.
+A prototype implementation now is being developed.
+This proposal and the rationale underlying its development
+have been presented to major software vendors as an early step
+toward convergence on a compatible file system interface [Karels86].
+.NH 2
+Changes to the Protocol Layering Interface
+.PP
+The original work on restructuring the UNIX character I/O system
+to allow flexible configuration of the internal modules by user
+processes was done at Bell Laboratories [Ritchie84].
+Known as stackable line disciplines, these interfaces allowed a user
+process to open a raw terminal port and then push on appropriate
+processing modules (such as one to do line editing).
+This model allowed terminal processing modules to be used with
+virtual-circuit network modules to create ``network virtual terminals''
+by stacking a terminal processing module on top of a
+networking protocol.
+.PP
+The design of the networking facilities for 4.2BSD took
+a different approach based on the \fBsocket\fP interface.
+This design allows a single system to support multiple sets of networking
+protocols with stream, datagram, and other types of access.
+Protocol modules may deal with multiplexing of data from different connections
+onto a single transport medium.
+.PP
+A problem with stackable line disciplines though, is that they
+are inherently linear in nature.
+Thus, they do not adequately model the fan-in and fan-out
+associated with multiplexing.
+The simple and elegant stackable line discipline implementation
+of Eighth Edition UNIX was converted to the full production implementation
+of Streams in System V Release 3.
+In doing the conversion, many pragmatic issues were addressed,
+including the handling of
+multiplexed connections and commercially important protocols.
+Unfortunately, the implementation complexity increased enormously.
+.PP
+Because AT&T will not allow others to include Streams unless they
+also change their interface to comply with the System V Interface Definition
+base and Networking Extension,
+we cannot use the Release 3 implementation of Streams in the Berkeley system.
+Given that compatibility thus will be difficult,
+we feel we will have complete freedom to make our
+choices based solely on technical merits.
+As a result, our implementation will appear far more like the simpler stackable
+line disciplines than the more complex Release 3 Streams [Chandler86].
+A socket interface will be used rather than a character device interface,
+and demultiplexing will be handled internally by the protocols in the kernel.
+However, like Streams, the interfaces between kernel
+protocol modules will follow a uniform convention.
diff --git a/share/doc/papers/future/Makefile b/share/doc/papers/future/Makefile
new file mode 100644
index 00000000000..2e0c16c746c
--- /dev/null
+++ b/share/doc/papers/future/Makefile
@@ -0,0 +1,10 @@
+#	@(#)Makefile	1.3 (Berkeley) 6/8/93
+
+DIR=	papers/future
+SRCS=	0.t 1.t 2.t r.t
+MACROS=	-ms
+
+paper.ps: ${SRCS}
+	${TBL} ${SRCS} | ${ROFF} > ${.TARGET}
+
+.include <bsd.doc.mk>
diff --git a/share/doc/papers/future/r.t b/share/doc/papers/future/r.t
new file mode 100644
index 00000000000..26906629949
--- /dev/null
+++ b/share/doc/papers/future/r.t
@@ -0,0 +1,144 @@
+.\" Copyright (c) 1986 The Regents of the University of California.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"	@(#)r.t	5.1 (Berkeley) 4/16/91
+.\"
+.NH
+References
+.ls 1
+.sp
+.IP Babaoglu79 \w'Satyanarayanan85\0\0'u
+Babaoglu, O., W. Joy,
+``Data Structures Added in the Berkeley Virtual Memory Extensions
+to the UNIX Operating System''
+Computer Systems Research Group, Dept of EECS, University of California,
+Berkeley, CA 94720, USA, November 1979.
+.sp
+.IP Brownbridge82
+Brownbridge, D.R., L.F. Marshall, B. Randell,
+``The Newcastle Connection, or UNIXes of the World Unite!,''
+\fISoftware\- Practice and Experience\fP, Vol. 12, pp. 1147-1162, 1982.
+.sp
+.IP Chandler86
+Chandler, D.,
+``The Monthly Report \- Up the Streams Without a Standard'',
+\fIUNIX Review\fP, Vol. 4, No. 9, pp. 6-14, September 1986.
+.sp
+.IP Cole85
+Cole, C.T., P.B. Flinn, A.B. Atlas,
+``An Implementation of an Extended File System for UNIX,''
+\fIUsenix Conference Proceedings\fP,
+pp. 131-150, June, 1985.
+.sp
+.IP Joy83
+Joy, W., E. Cooper, R. Fabry, S. Leffler, M. McKusick, D. Mosher,
+``4.2BSD System Manual,''
+\fI4.2BSD UNIX Programmer's Manual\fP, Vol 2c, Document #68
+August 1983.
+.sp
+.IP Karels86
+Karels, M., M. McKusick,
+``Towards a Compatible File System Interface,''
+\fIProceedings of the European UNIX Users Group Meeting\fP,
+Manchester, England, pp. 481-496, September 1986.
+.sp
+.IP Kleiman86
+Kleiman, S.,
+``Vnodes: An Architecture for Multiple File System Types in Sun UNIX,''
+\fIUsenix Conference Proceedings\fP,
+pp. 238-247, June, 1986.
+.sp
+.IP Leffler84
+Leffler, S., M.K. McKusick, M. Karels,
+``Measuring and Improving the Performance of 4.2BSD,''
+\fIUsenix Conference Proceedings\fP, pp. 237-252, June, 1984.
+.sp
+.IP McKusick85
+McKusick, M.K., M. Karels, S. Leffler,
+``Performance Improvements and Functional Enhancements in 4.3BSD,''
+\fIUsenix Conference Proceedings\fP, pp. 519-531, June, 1985.
+.sp
+.IP McKusick86
+McKusick, M., M. Karels,
+``A New Virtual Memory Implementation for Berkeley UNIX,''
+\fIProceedings of the European UNIX Users Group Meeting\fP,
+Manchester, England, pp. 451-460, September 1986.
+.sp
+.IP Someren84
+Someren, J. van,
+``Paging in Berkeley UNIX,''
+Laboratorium voor schakeltechniek en techneik v.d. 
+informatieverwerkende machines,
+Codenummer 051560-44(1984)01, February 1984.
+.sp
+.IP Rifkin86
+Rifkin, A.P., M.P. Forbes, R.L. Hamilton, M. Sabrio, S. Shah, K. Yueh,
+``RFS Architectural Overview,'' \fIUsenix Conference Proceedings\fP,
+pp. 248-259, June, 1986.
+.sp
+.IP Ritchie74
+Ritchie, D.M., K. Thompson,
+``The Unix Time-Sharing System,''
+\fICommunications of the ACM\fP, Vol. 17, pp. 365-375, July, 1974.
+.sp
+.IP Ritchie84
+Ritchie, D.M.,
+``A Stream Input-Output System,''
+\fIAT&T Bell Laboratories Technical Journal\fP, Vol 63, No 8, Part 2,
+pp. 1897-1910, October 1984.
+.sp
+.IP Rodriguez86
+Rodriguez, R., M. Koehler, R. Hyde,
+``The Generic File System,''
+\fIUsenix Conference Proceedings\fP,
+pp. 260-269, June, 1986.
+.sp
+.IP Sandberg85
+Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon,
+``Design and Implementation of the Sun Network File System,''
+\fIUsenix Conference Proceedings\fP,
+pp. 119-130, June, 1985.
+.sp
+.IP Satyanarayanan85
+Satyanarayanan, M., \fIet al.\fP,
+``The ITC Distributed File System: Principles and Design,''
+\fIProc. 10th Symposium on Operating Systems Principles\fP, pp. 35-50,
+ACM, December, 1985.
+.sp
+.IP Walker85
+Walker, B.J. and S.H. Kiser, ``The LOCUS Distributed File System,''
+\fIThe LOCUS Distributed System Architecture\fP,
+G.J. Popek and B.J. Walker, ed., The MIT Press, Cambridge, MA, 1985.
+.sp
+.IP Weinberger84
+Weinberger, P.J., ``The Version 8 Network File System,''
+\fIUsenix Conference presentation\fP,
+June, 1984.
diff --git a/share/doc/papers/future/spell.ok b/share/doc/papers/future/spell.ok
new file mode 100644
index 00000000000..311a84c4d54
--- /dev/null
+++ b/share/doc/papers/future/spell.ok
@@ -0,0 +1,90 @@
+A.B
+A.P
+B.J
+BSD
+Babaoglu
+Babaoglu79
+Brownbridge
+Brownbridge82
+C.T
+CM
+Chandler86
+Codenummer
+Cole85
+D.M
+D.R
+Dept
+EECS
+FSS
+Fabry
+Flinn
+G.J
+GFS
+IDP
+IP
+IPC
+ITC
+Joy83
+Karels
+Karels86
+Kiser
+Kleiman
+Kleiman86
+Koehler
+L.F
+LL
+Laboratorium
+Leffler
+Leffler84
+M.K
+M.P
+Masscomp's
+McKusick
+McKusick85
+McKusick86
+Mosher
+P.B
+P.J
+PARC
+Popek
+Proc
+R.L
+RFS
+Randell
+Rifkin
+Rifkin86
+Ritchie74
+Ritchie84
+Rodriguez86
+S.H
+SPP
+Sabrio
+Sandberg
+Sandberg85
+Sandburg85
+Satyanarayanan
+Satyanarayanan85
+Someren
+Someren84
+TCP
+UNIXes
+Usenix
+VFS
+VS
+Vnodes
+Vol
+Walker85
+Weinberger84
+Yueh
+al
+bitmapped
+informatieverwerkende
+pp
+rlogin
+runtime
+schakeltechniek
+techneik
+telnet
+v.d
+vnodes
+voor
diff --git a/share/doc/papers/jus/Makefile b/share/doc/papers/jus/Makefile
new file mode 100644
index 00000000000..f9bb1576932
--- /dev/null
+++ b/share/doc/papers/jus/Makefile
@@ -0,0 +1,7 @@
+#	@(#)Makefile	5.2 (Berkeley) 6/8/93
+
+DIR=	papers/jus
+SRCS=	paper.ms
+MACROS=	-ms
+
+.include <bsd.doc.mk>
diff --git a/share/doc/papers/jus/paper.ms b/share/doc/papers/jus/paper.ms
new file mode 100644
index 00000000000..c2b7854aaa9
--- /dev/null
+++ b/share/doc/papers/jus/paper.ms
@@ -0,0 +1,435 @@
+.\" Copyright (c) 1992 The Regents of the University of California.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"	@(#)paper.ms	5.3 (Berkeley) 5/26/92
+.\"
+.\" use roff -ms
+.ds CM
+.TL
+Berkeley UNIX
+Yesterday, Today and Tomorrow
+.AU
+Keith Bostic
+.AU
+Marshall Kirk McKusick
+.AU
+Michael J. Karels
+.AI
+Computer Systems Research Group
+Computer Science Division
+Department of Electrical Engineering and Computer Science
+University of California, Berkeley
+Berkeley, California  94720
+.AB
+This paper presents a brief overview of the historic Berkeley releases
+and the role that Berkeley has played in the UNIX\(dg
+.FS
+\(dgUNIX is a registered trademark of UNIX System Laboratories.
+.FE
+world and discusses the role that University and research releases
+should play in the future.
+.AE
+.NH
+A Technical History of the Berkeley Project
+.PP
+This is a \fBbrief\fP technical history of Berkeley UNIX.
+For more details, [McKusick85] is strongly recommended along with the
+other papers listed in the Reference section.
+Specifically, we apologize that space does not permit mentioning most
+of the major contributors and influences on the Berkeley system!
+.PP
+The University of California, Berkeley, first ran Bell Laboratories
+Version 4 UNIX on a PDP-11/45, in January of 1974.
+Later that spring, a PDP-11/40 was configured with the newly available
+Version 5.
+Version 6 was running on a PDP-11/70 by the fall of 1975,
+with the arrival of two new graduate students, Bill Joy and Chuck Haley.
+They initially concentrating on making improvements to a Pascal system
+written by Ken Thompson while on sabbatical at Berkeley.
+With this completed, they turned their attention to the \fBed\fP editor,
+eventually producing a new version they called \fBex\fP.
+By the end of the summer of 1976, Joy and Haley began to take an
+interest in exploring the internals of the UNIX kernel.
+.PP
+In 1977, a steady stream of requests for the enhanced Pascal system
+had begun.
+Early that year, Joy put together the first ``Berkeley Software
+Distribution'', including the Pascal system and the source to \fBex\fP.
+Over the next year, about thirty copies of this distribution
+were sent out.
+At around the same time, Joy began work on what was to become \fBvi\fP.
+By mid-1978, the software distribution clearly needed to be updated.
+The Pascal system had been made markedly more robust through feedback
+from its expanding user community,
+and had been split into two passes so that it could be run on PDP-11/34s.
+The result of the update was the ``Second Berkeley Software Distribution''
+a name that was quickly abbreviated to 2BSD.
+Along with the Pascal system,
+\fBvi\fP and \fBtermcap\fP for several terminals were included.
+Once again Bill Joy single-handedly put together distributions,
+answered the phone, and incorporated user feedback into the system.
+Over the next year nearly seventy-five tapes were shipped.
+Although Joy soon moved on to other projects, the 2BSD distribution
+continued to expand.
+Today the latest version of this distribution, 2.10BSD is still alive
+and being used by people all around the world on PDP-11's.
+.PP
+Early in 1978, Berkeley obtained a newly announced Digital
+Equipment Corp. (DEC) VAX\(dd
+.FS
+\(ddVAX is a registered trademark of Digital Equipment Corporation.
+.FE
+11-780's.
+Shortly after the arrival of the VAX, Bell Laboratories provided Berkeley
+with a copy of their 32/V port of UNIX to the VAX.
+Although 32/V supported a Version 7 UNIX environment on the VAX,
+it did not take advantage of the virtual memory capability of the VAX
+hardware.
+Like its predecessors on the PDP-11, it was a swapping system.
+Ozalp Babaoglu, a Berkeley graduate student, set about finding a way of
+implementing a working set paging system on the VAX.
+As Babaoglu neared the completion of his first attempt at an implementation,
+he approached Bill Joy for some help in understanding the intricacies
+of the UNIX kernel.
+Intrigued by Babaoglu's approach, Joy joined in helping to integrate
+the code into 32/V and then with the ensuing debugging.
+.PP
+Joy realized that the 32-bit VAX would soon make the 16-bit PDP-11
+obsolete, and he began to port the 2BSD software to the VAX.
+By the end of 1979, a complete distribution had been created.
+This distribution included the virtual memory kernel,
+the standard 32/V utilities, and the 2BSD additions, which by now
+included the Pascal system, \fBex\fP/\fBvi\fP, the \fBCshell\fP and
+several other utilities.
+In December, 1979, Joy shipped the first of nearly a hundred copies of 3BSD,
+the first VAX distribution from Berkeley.
+.PP
+In the fall of 1979, the Defense Advanced Research Projects Agency, DARPA,
+accepted a Berkeley proposal to develop an enhanced version of 3BSD for
+the DARPA community.
+With the already good reputation of 3BSD supporting the proposal, the
+Berkeley project was funded.
+Joy took charge of the project, which was to become the Computer Systems
+Research Group (CSRG).
+Joy soon incorporated job control, added auto reboot, a 1K block file
+system, and support for the latest VAX machine, the VAX-11/750.
+By October, 1980, a polished distribution that also included the Franz
+Lisp system and an enhanced mail handling system was released as 4BSD.
+During its nine-month lifetime, nearly 150 copies were shipped.
+.PP
+With the increasingly wide distribution and visibility of Berkeley UNIX,
+several critics began to emerge.
+The major objection cited was the performance of various benchmarks as
+compared to the DEC VMS system.
+Over the course of several months, Joy systematically tuned the kernel,
+soon matching VMS's performance.
+Rather than continue shipping 4BSD, the tuned system, with the addition
+of Robert Elz's auto configuration code, was released as 4.1BSD in June,
+1981.
+Over its two year lifetime about 400 distributions were shipped.
+.PP
+With the release of 4.1BSD, much of the debate over performance died
+down.
+DARPA again funded Berkeley, this time with the intention of adding
+new features to the BSD system.
+These new features eventually included Berkeley reliable signals,
+the fast filesystem, disk quotas,
+and the socket interface with TCP/IP networking support.
+Around this time Joy left the CSRG for Sun Microsystems, and Sam Leffler
+took over responsibility for completing the project.
+In August, 1983, this system was released as 4.2BSD [Joy83].
+The popularity of 4.2BSD was impressive; within eighteen months more
+copies of 4.2BSD had been shipped than of all the previous Berkeley
+software distributions combined.
+.PP
+As with 4BSD, the major criticism of 4.2BSD was performance.
+The problem, not surprisingly, was that the new facilities had not been
+tuned and that many of the kernel data structures were not well suited
+to their new uses.
+In addition, many of the interfaces, particularly in the networking
+area had been left unfinished.
+As Sam Leffler had left the CSRG for Lucasfilm, the tuning and enhancement
+of 4.2BSD was largely done under the direction of Michael Karels and Kirk
+McKusick [Leffler84] [McKusick85].
+This system was released in April of 1986 as 4.3BSD, and had greatly
+enhanced performance and reliability over 4.2BSD, along with several
+new features.
+.PP
+As it had done in 4.2BSD, the CSRG then embarked on a new development
+phase to update other major components of the system, and
+design and integrate new functionality.
+The 4.4BSD release, scheduled for fall of 1992, will contain the results
+of several major new projects.
+Among these projects are an OSI network protocol suite integrated
+with existing ISO applications, an IEEE POSIX 1003.1 standard interface,
+a highly tuned TCP/IP networking interface, support for Sun Microsystem's
+Network File System, the integration of a log-structured file system,
+an integration of the MACH virtual memory system, volume labels and
+user-level database support.
+.PP
+There will have been four interim releases made by the CSRG between 4.3BSD
+and the upcoming 4.4BSD release.
+The first two of these releases, 4.3BSD-Tahoe and 4.3BSD-Reno were
+intended to distribute a subset of the new functionality found in 4.4BSD
+available to vendors.
+The 4.3BSD-Tahoe release, made in the summer of 1988, was the first Berkeley
+release to support two architectures.
+This goal was made possible by the reimplementation of much of the machine
+specific kernel source and a fundamental restructuring of the source code
+pool so that binaries for more than one architecture could be constructed
+from a single source pool.
+The two supported architectures were the VAX and the Computer Consoles Inc.
+Power 6/32 (the Tahoe).
+Since this release, architecture support for the Intel 386/486, the
+Sun Microsystems SPARCstation\(dg
+.FS
+\(dgAll SPARC trademarks are trademarks or registered trademarks
+of SPARC International, Inc.
+SPARCstation is licensed exclusively to Sun Microsystems, Inc.
+.FE
+I and II, the DECstation 3100 and 5000 and the Hewlett-Packard 300 have
+been added as well.
+The 4.3BSD-Reno release, made in the summer of 1990, was intended to make
+the Network File System code available to vendors using Berkeley-derived
+systems, such as The Open Software Foundation (OSF).
+This code had been written by Rick Macklem at the University of Guelph
+and integrated by the CSRG, under a new version of the kernel file
+system switch.
+.PP
+Two other interim releases, the first and second release of the
+``Berkeley Network Software Distribution'', usually abbreviated as NET/1
+and NET/2, were intended to make the source code of the 4BSD system
+available to and redistributable by anyone.
+Over the years of development by the CSRG and others, an increasingly
+larger percentage of the system was not derived from the original AT&T
+32/V distribution.
+In the spring of 1988 Berkeley made its first distribution not requiring
+an AT&T source license, NET/1.
+This distribution primarily contained the networking portions of the system,
+from the utilities all the way through to the kernel device drivers, although
+other items such as \fBlogin\fP and other files were included for various
+reasons.
+This release was extremely popular with many vendors with their own
+versions of UNIX but who wished to run the Berkeley TCP/IP code and
+with vendors wishing to create smart networking cards, not to mention
+the users that wanted access to the source code for class work or other
+research purposes.
+.PP
+Around this time, the CSRG also began to search out freely redistributable
+versions of the UNIX utilities and to rewrite, or encourage BSD users to
+rewrite, those that were not available elsewhere.
+This was an immensely time-consuming task, involving contributions by
+hundreds of programmers from all around the world.
+In the summer of 1991, Berkeley released NET/2, which, like NET/1, did
+not require an AT&T source license.
+The NET/2 release included about 80% of the source code found in
+the 4.3BSD-Reno release.
+This release has proved to be immensely popular, with hundreds of thousands
+of copies taken from the public network archives and an unknown number
+redistributed by other organizations.
+.NH
+The Role of the Berkeley Project in the UNIX World
+.PP
+The role that Berkeley has played in the UNIX world has been a
+constantly changing one.
+In the 1970's, Berkeley was among the first participants in the UNIX
+research community, acting as host to several researchers on sabbatical
+from Bell Laboratories.
+This cooperation typified the harmony that was characteristic of the
+early UNIX community, as led by Bell Laboratories.
+Work that was contributed to the Laboratories by different members of
+the community, Berkeley among them, helped produce a rapidly expanding
+set of tools and facilities.
+With the commercialization of UNIX, the Bell Laboratories researchers were
+no longer able to act as a clearinghouse for the ongoing UNIX research.
+As the research community continued to modify the UNIX system, it found
+that it needed an organization that could produce leading edge research
+releases.
+Because of its early involvement in UNIX and its history of releasing
+UNIX-based tools, the CSRG quickly filled this role.
+.PP
+For the first half of the 1980's, Berkeley served as the focus of the
+leading edge of UNIX research.
+The Berkeley system was widely used, ported and considered the arbiter
+of what should comprise a UNIX system.
+By the mid-1980's, largely because the networking component of the Berkeley
+system was unique and unavailable from vendors for a period of time,
+Berkeley was forced into the role of a vendor [McKusick89].
+This role expanded to the point that there were two major variants of
+UNIX, System V and BSD, and resulted in a breach in the UNIX world that
+is only gradually being healed.
+Acting as a vendor required an immense amount of time, money and effort
+by the CSRG.
+Thousands of hours were devoted to release engineering, thousands more
+to participation in the emerging UNIX standards and thousands more in
+distribution and user support.
+Over the years it became increasingly clear to the people associated with
+the Berkeley UNIX project that its limited funding and manpower were
+insufficient to complete its historical task of designing, implementing
+and supporting a complete, reliable, leading edge system.
+As each portion of the system became more complex and additional features
+were added, more and more effort had to be expended to keep the
+system at a high level of quality, and less and less effort was available
+to move the system technically forward.
+Fortunately, during the last half of the 1980's, as the UNIX interface
+became the consensus choice for an industry standard, and the number of
+vendors marketing, selling and supporting UNIX systems grew, Berkeley
+has been able to start to return to its historical orientation of doing
+leading-edge research instead of customer support.
+.NH 
+Berkeley UNIX Tomorrow
+.PP
+For UNIX to become the system of choice for a large segment of the industry,
+potential customers must have confidence that the product is supported,
+that future versions will continue to be developed and enhanced, and that
+future versions will be upwardly compatible with all past applications.
+In addition, vendors desiring to maximize their return on investment
+require that the source code for their systems be proprietary and are
+unwilling to make it available to users under any but the most onerous
+restrictions.
+Many of these changes, while acceptable for most users,
+are diametrically opposed to what has made UNIX the research platform
+of choice: low cost, wide availability of source code, and leading edge
+technology.
+.PP
+System development can be likened to the process of evolution.
+While gene mutation is critical to the advancement of the species, only
+one in 100 mutations produces a useful feature; the rest result in
+needless or detrimental changes.
+The mere existence of an environment for mutation is not enough --
+some organization must bear responsibility for
+brutally pruning the weak, outdated and useless ideas.
+UNIX was fortunate in this sense.
+Unlike other projects beset by competing groups jealously guarding their
+work from one another, UNIX thrived in an open and cooperative community
+willing to channel its ideas through a central clearinghouse (first Bell
+Laboratories and later the CSRG), in spite of the clearinghouse's
+reputation for selective technical scrutiny.
+.PP
+Here one must distinguish between the selection process provided
+by research and commercial organizations.
+Research organizations can base pruning decisions strictly on the
+coherence of the system and the technical merit of the idea.
+They need not concern themselves with how changes might affect 
+past variants of the system.
+Commercial organizations, though, must ensure that
+changes will not affect programs built to an obsolete interface.
+For example, paging might be a great idea, but it will cause problems for
+software that depends on the execution predictability of a swap-based
+system, making it impossible for paging to replace swapping.
+As a result, both schemes must be maintained, dramatically increasing the
+complexity of the system.
+As the system becomes more complex, its evolutionary paths will become
+increasingly restricted.
+.PP
+Here the role of a dynamic research version of UNIX becomes clear.
+While it is only directly used by a small group of people,
+it provides an important role as the feedstock for the commercial 
+versions of UNIX.
+Over the long term,
+it is reasonable to expect that the most useful functionality
+of the research systems will be grafted into the commercial versions.
+Examples of ideas that began with BSD and moved into commercial systems
+include the fast filesystem, TCP/IP networking, and nearly half of
+the commands and utilities.
+.PP
+The CSRG spends a significant amount of time collecting prototypes of
+projects throughout the research world and molding them together into
+a coherent and usable system.
+Many of the ideas do not work out and are dropped in later releases.
+The ability to experiment without concern for past applications is
+critical.
+The resulting system is a third the size and a fraction of the complexity
+of its roughly equivalently functioned commercial brethren.
+This lean and mean approach allows the system to evolve rapidly (the
+nightmare of every commercial user, but the dream of every researcher).
+A recent example of this type of experimentation is the prototyping of
+various proposed POSIX utilities and interfaces by the CSRG.
+When drafts of the standard were implemented, basic flaws in the
+specification became apparent.
+These flaws and suggested solutions were presented to the standards
+committees, resulting in changes to the standard ensuring that the
+ratified standard could be efficiently and correctly implemented.
+The research system users also benefit from having a reference
+implementation of the standard almost from the day that it is finalized.
+.PP
+Another major influence on the UNIX systems of the future will be the
+NET/2 release.
+At least three separate groups (two in the U.S. and one in Europe) have
+added the necessary source code to the NET/2 release to make it a fully
+functional UNIX system.
+As the NET/2 release was not proprietary to any person or organization
+other than the University of California and may be freely redistributed,
+the cost of a UNIX system with source code will be less in the future
+than in the current UNIX market by two orders of magnitude.
+The UNIX single-server release by the Carnegie Mellon University
+MACH group will also use the NET/2 release as a starting point, making
+their release freely redistributable without a UNIX source license.
+The advent of cheaply available sources will make it far easier than
+ever before for research groups and users to develop and exchange software.
+.PP
+The role of designing and implementing a leading-edge research version
+of UNIX is one that Berkeley is uniquely equipped to fill.
+Future Berkeley releases will be oriented, as they were in the early days
+of Berkeley UNIX, toward the development and integration of a few
+well-chosen pieces of new research into a leading-edge system.
+.NH
+References:
+.sp
+.IP Joy83
+.br
+Joy, W., E. Cooper, R. Fabry, S. Leffler, M. McKusick, D. Mosher,
+``4.2BSD System Manual,''
+\fI4.2BSD UNIX Programmer's Manual\fP, Vol 2c, Document #68
+August 1983.
+.sp
+.IP Leffler84
+Leffler, S., M.K. McKusick, M. Karels,
+``Measuring and Improving the Performance of 4.2BSD,''
+\fIUsenix Conference Proceedings\fP, pp. 237-252, June, 1984.
+.sp
+.IP McKusick85
+McKusick, M.K., M. Karels, S. Leffler,
+``Performance Improvements and Functional Enhancements in 4.3BSD,''
+\fIUsenix Conference Proceedings\fP, pp. 519-531, June, 1985.
+.sp
+.IP McKusick87
+M. McKusick, M. Karels,
+``Directions of UNIX at Berkeley'',
+\fIDigest of Papers of the Thirty-second IEEE Computer Society
+International Conference\fP,
+Compcon, San Francisco, pp. 196-199, February 23-27, 1987.
+.sp
+.IP McKusick89
+M. McKusick, M. Karels, K. Bostic,
+``The Release Engineering of 4.3BSD'',
+\fIProceedings of the New Orleans Usenix Workshop on Software Management\fP,
+pp. 95-100, April 1989.