recording cvs-1.6 file death

73 files changed, 0 insertions, 19320 deletions

diff --git a/share/FAQ/CONTRIB.FreeBSD b/share/FAQ/CONTRIB.FreeBSD
deleted file mode 100644
index 6b77670..0000000
--- a/share/FAQ/CONTRIB.FreeBSD
+++ /dev/null
@@ -1,245 +0,0 @@
-			   FreeBSD 2.0
-		         Contributor List
-
-
-
-Derived Software Contributors:
-
-This software was originally derived from William F. Jolitz's 386BSD
-release 0.1, though almost none of the original 386BSD specific code
-remains.  This software has been essentially reimplemented from the
-4.4 BSD Lite release provided by the Computer Science Research Group
-(CSRG) at the University of California, Berkeley and associated academic
-contributors.
-
-There are also portions of NetBSD that have been integrated into FreeBSD
-as well, and we would therefore like to thank all the contributors
-to NetBSD for their work.  Despite some occasionally rocky moments in
-relations between the two groups, we both want essentially the same
-thing:  More BSD based operating systems on people's computers!  We
-wish the NetBSD group every success in their endevors.
-
-
-Hardware Contributors:
-
-A special thank-you to Walnut Creek CDROM for providing the Pentium P5-90
-and 486/DX2-66 EISA/VL systems that are being used for our development work,
-to say nothing of the network access and other donations of hardware
-resources.  It would have been impossible to do this release without
-their support.
-
-TRW Financial Systems, Inc. provided 130 PCs, three 68 GB fileservers, 
-twelve ethernets, two routers and an ATM switch for debugging the diskless
-code.  They also keep a couple of FreeBSD hackers alive and busy.  Thanks!
-
-Thanks also to Dermot McDonnell for his donation of a Toshiba XM3401B CDROM
-drive.  It's been most useful!
-
-
-The FreeBSD Core Team	[also the Board of Directors for The FreeBSD Project]
-(in alphabetical order):
-
-	Andreas Schulz <ats@FreeBSD.org>
-	Andrey A. Chernov <ache@FreeBSD.org>
-	Bruce Evans <bde@FreeBSD.org>
-	David Greenman <davidg@FreeBSD.org>
-	Garrett A. Wollman <wollman@FreeBSD.org>
-	Gary Palmer <gpalmer@FreeBSD.org>
-	Geoff Rehmet <csgr@FreeBSD.org>
-	Jack Vogel <jackv@FreeBSD.org>
-	John Dyson <dyson@FreeBSD.org>
-	Jordan K. Hubbard <jkh@FreeBSD.org>
-	Justin Gibbs <gibbs@FreeBSD.org>
-	Nate Williams <nate@FreeBSD.org>
-	Paul Richards <paul@FreeBSD.org>
-	Poul-Henning Kamp <phk@FreeBSD.org>
-	Rich Murphey <rich@FreeBSD.org>
-	Rodney W. Grimes <rgrimes@FreeBSD.org>
-	Søren Schmidt <sos@FreeBSD.org>
-
-
-Officers, The FreeBSD Project:
-
-	President:		Jordan K. Hubbard <jkh@FreeBSD.org>
-	Principle Architect:	David Greenman <davidg@FreeBSD.org>
-
-
-Directors, The FreeBSD Project:
-
-	Documentation:		John Fieber <jfieber@FreeBSD.org>
-	Internationalization:   Andrey A. Chernov <ache@FreeBSD.org>
-	Networking:		Garrett A. Wollman <wollman@FreeBSD.org>
-	Postmaster:		Jonathan M. Bresler <jmb@FreeBSD.org>
-	Release Coordinator:	Poul-Henning Kamp <phk@FreeBSD.org>
-	System Administration:	Gary Palmer <gpalmer@FreeBSD.org>
-	WEBMASTERS:		John Fieber <jfieber@FreeBSD.org> and
-				James L. Robinson <jlrobin@FreeBSD.org>
-	XFree86 Project, Inc:	(Liaison) Rich Murphey <rich@FreeBSD.org>
-
-
-Additional FreeBSD Contributors
-(in alphabetical order by first name, just to be different):
-
-Adam Glass <glass@postgres.berkeley.edu>
-Andreas Klemm <andreas@knobel.GUN.de>
-Andrew Herbert <andrew@werple.apana.org.au>
-Andrew Moore <alm@FreeBSD.org>
-Atsushi Murai <amurai@spec.co.jp>
-Bill Paul <wpaul@FreeBSD.org>
-Bob Wilcox <bob@obiwan.uucp>
-Bruce Evans <bde@kralizec.zeta.org.au>
-Charles Hannum <mycroft@ai.mit.edu>
-Chris G. Demetriou <cgd@postgres.berkeley.edu>
-Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at>
-Chris Torek <torek@ee.lbl.gov>
-Christoph Robitschko <chmr@edvz.tu-graz.ac.at>
-Curt Mayer <curt@toad.com>
-Dave Burgess <burgess@hrd769.brooks.af.mil>
-Dave Rivers <rivers@ponds.uucp>
-David Dawes <dawes@physics.su.OZ.AU>
-Frank Maclachlan <fpm@crash.cts.com>
-Gary A. Browning <gab10@griffcd.amdahl.com>
-Gary Clark II <gclarkii@radon.gbdata.com>
-Gary Jennejohn <gj%pcs.dec.com@inet-gw-1.pa.dec.com>
-Gene Stark <stark@cs.sunysb.edu>
-Guido van Rooij <guido@gvr.win.tue.nl>
-Havard Eidnes <Havard.Eidnes@runit.sintef.no>
-Holger Veit <Holger.Veit@gmd.de>
-Ishii Masahiro, R. Kym Horsell
-J.T. Conklin <jtc@winsey.com>
-James Clark <jjc@jclark.com>
-James da Silva <jds@cs.umd.edu> et al
-Jim Wilson <wilson@moria.cygnus.com>
-Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de>
-Julian Elischer <julian@dialix.oz.au>
-Julian Stacey <stacey@guug.de> <fallback: <julian@meepmeep.pcs.com>>
-Keith Bostic <bostic@toe.CS.Berkeley.EDU>
-Keith Moore <?>
-L Jonas Olsson <ljo@po.cwru.edu>
-Marc Frajola <marc@escargot.rain.com>
-Mark Murray <mark@grondar.za>
-Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu>
-Martin Birgmeier
-Matt Thomas <thomas@lkg.dec.com>
-Ollivier Robert <roberto@FreeBSD.org>
-Paul Kranenburg <pk@cs.few.eur.nl>
-Paul Mackerras <paulus@cs.anu.edu.au>
-Paul Traina <pst@cisco.com>
-Poul-Henning Kamp <phk@login.dkuug.dk>
-Chris Provenzano <proven@athena.mit.edu>
-Rob Shady <rls@id.net>
-Sascha Wildner <swildner@channelz.GUN.de>
-Satoshi Asami <asami@FreeBSD.org>
-Scott Mace <smace@FreeBSD.org>
-Sean Eric Fagan <sef@kithrup.com>
-Serge V. Vakulenko <vak@zebub.msk.su>
-Stefan Esser <se@MI.Uni-Koeln.DE>
-Stephen McKay <syssgm@devetir.qld.gov.au>
-Steven Wallace <swallace@ece.uci.edu>
-Søren Schmidt <sos@login.dkuug.dk>
-Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp>
-Terry Lee <terry@uivlsi.csl.uiuc.edu>
-Theo Deraadt <deraadt@fsa.ca>
-Ugen J.S.Antsilevich <ugen@NetVision.net.il>
-Wolfgang Stanglmeier <wolf@kintaro.cologne.de>
-Wolfram Schneider <wosch@cs.tu-berlin.de>
-Yuval Yarom <yval@cs.huji.ac.il>
-Yves Fonk <yves@cpcoup5.tn.tudelft.nl>
-
-
-386BSD Patch kit patch contributors (in alphabetical order):
-
-Adam Glass <glass@postgres.berkeley.edu>
-Adrian Hall <adrian@ibmpcug.co.uk>
-Andrey A. Chernov <ache@astral.msk.su>
-Andrew Herbert <andrew@werple.apana.org.au>
-Andrew Moore <alm@netcom.com>
-Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com>
-Arne Henrik Juul <arnej@Lise.Unit.NO>
-Bakul Shah <bvs@bitblocks.com>
-Barry Lustig <barry@ictv.com>
-Bob Wilcox <bob@obiwan.uucp>
-Branko Lankester
-Brett Lymn <blymn@mulga.awadi.com.AU>
-Bruce Evans <bde@kralizec.zeta.org.au>
-Charles Hannum <mycroft@ai.mit.edu>
-Chris G. Demetriou <cgd@postgres.berkeley.edu>
-Chris Torek <torek@ee.lbl.gov>
-Christoph Robitschko <chmr@edvz.tu-graz.ac.at>
-Daniel Poirot <poirot@aio.jsc.nasa.gov>
-Dave Burgess <burgess@hrd769.brooks.af.mil>
-Dave Rivers <rivers@ponds.uucp>
-David Dawes <dawes@physics.su.OZ.AU>
-David Greenman <davidg@Root.COM>
-Eric J. Haug <ejh@slustl.slu.edu>
-Felix Gaehtgens <felix@escape.vsse.in-berlin.de>
-Frank Maclachlan <fpm@crash.cts.com>
-Gary A. Browning <gab10@griffcd.amdahl.com>
-Geoff Rehmet <csgr@alpha.ru.ac.za>
-Goran Hammarback <goran@astro.uu.se>
-Guido van Rooij <guido@gvr.win.tue.nl>
-Guy Harris <guy@auspex.com>
-Havard Eidnes <Havard.Eidnes@runit.sintef.no>
-Herb Peyerl <hpeyerl@novatel.cuc.ab.ca
-Holger Veit <Holger.Veit@gmd.de>
-Ishii Masahiro, R. Kym Horsell
-J.T. Conklin <jtc@winsey.com>
-Jagane D Sundar < jagane@netcom.com >
-James Clark <jjc@jclark.com>
-James Jegers <jimj@miller.cs.uwm.edu>
-James W. Dolter
-James da Silva <jds@cs.umd.edu> et al
-Jay Fenlason <hack@datacube.com>
-Jim Wilson <wilson@moria.cygnus.com>
-Joerg Lohse <lohse@tech7.informatik.uni-hamburg.de>
-Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de>
-John Dyson - <formerly dyson@ref.tfs.com>
-John Woods <jfw@eddie.mit.edu>
-Jordan K. Hubbard <jkh@whisker.hubbard.ie>
-Julian Elischer <julian@dialix.oz.au>
-Julian Stacey <stacey@guug.de> <fallback: <julian@meepmeep.pcs.com>>
-Karl Lehenbauer <karl@NeoSoft.com> <karl@one.neosoft.com>
-Keith Bostic <bostic@toe.CS.Berkeley.EDU>
-Ken Hughes
-Kent Talarico <kent@shipwreck.tsoft.net>
-Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu> <kml@mosquito.cis.ufl.edu>
-Marc Frajola <marc@escargot.rain.com>
-Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu>
-Martin Renters <martin@innovus.com>
-Michael Galassi <nerd@percival.rain.com>
-Mike Durkin <mdurkin@tsoft.sf-bay.org>
-Nate Williams <nate@bsd.coe.montana.edu>
-Nick Handel <nhandel@NeoSoft.com> <nick@madhouse.neosoft.com>
-Pace Willisson <pace@blitz.com>
-Paul Kranenburg <pk@cs.few.eur.nl>
-Paul Mackerras <paulus@cs.anu.edu.au>
-Paul Popelka <paulp@uts.amdahl.com>
-Peter da Silva <peter@NeoSoft.com>
-Phil Sutherland <philsuth@mycroft.dialix.oz.au>
-Poul-Henning Kamp <phk@login.dkuug.dk>
-Ralf Friedl <friedl@informatik.uni-kl.de>
-Rich Murphey <rich@lamprey.utmb.edu>
-Rick Macklem <root@snowhite.cis.uoguelph.ca>
-Robert D. Thrush <rd@phoenix.aii.com>
-Rodney W. Grimes <rgrimes@cdrom.com>
-Rog Egge <?>
-Sascha Wildner <swildner@channelz.GUN.de>
-Scott Burris <scott@pita.cns.ucla.edu>
-Scott Reynolds <scott@clmqt.marquette.mi.us>
-Sean Eric Fagan <sef@kithrup.com>
-Simon J Gerraty <sjg@melb.bull.oz.au> <sjg@zen.void.oz.au>
-Stephen McKay <syssgm@devetir.qld.gov.au>
-Terry Lambert <terry@icarus.weber.edu>
-Terry Lee <terry@uivlsi.csl.uiuc.edu>
-Warren Toomey <wkt@csadfa.cs.adfa.oz.au>
-Wiljo Heinen <wiljo@freeside.ki.open.de>
-William Jolitz <withheld>
-Wolfgang Solfrank <ws@tools.de>
-Wolfgang Stanglmeier <wolf@dentaro.GUN.de>
-Yuval Yarom <yval@cs.huji.ac.il>
-
-Last, but not least, the release engineer would like to thank:
-	His Wife, for chocolate chip cookies, and some other things.
-	The DGB project @ TFS, for patience and tolerance.
-
-$Id: CONTRIB.FreeBSD,v 1.24 1995/03/16 22:01:57 phk Exp $
diff --git a/share/FAQ/DISKSPACE.FAQ b/share/FAQ/DISKSPACE.FAQ
deleted file mode 100644
index 14bd082..0000000
--- a/share/FAQ/DISKSPACE.FAQ
+++ /dev/null
@@ -1,265 +0,0 @@
-                    How to assign disk space to FreeBSD.
-
-1.0  Getting started.
----------------------
-
-After a general introduction, you will find some explanation on what you
-need to do to assign space to FreeBSD on your disk(s).  This is done
-through the "sysinstall" program, which lives on the inital boot floppy.
-Those already expert with PCs may wish to skip ahead to section 1.2, the
-rest of you may (or may not) enjoy the brief history lesson.
-
-
-1.1  The ins and outs of allocating disk storage on your PC.
-------------------------------------------------------------
-
-Modern hard disk drives are now getting big enough that people don't want
-to allocate all of one to just one operating system anymore, especially
-given the increasing size of disk drives (the latest 9.0 Gbyte models
-holding the equivalent of some six thousand 1.44MB floppies!) and the
-virtual explosion of operating system options available for the PC.  To
-solve this problem, IBM came up with a scheme for "slicing" the disks
-into more manageable chunks, or partitions.  It works, but only just.
-To better understand why, first a brief bit of history:
-
-MS-DOS, when hard disk support was unceremoniously grafted on back in the
-late eighties, didn't have such "slices".  What it had was a way to install
-Xenix and MS-DOS on the same disk (Remember when Microsoft were in the UNIX
-business?).
-
-In the first sector on the disk was a piece of "primary boot code" and a
-table with four entries.  Each of those entries pointed at an arbitrary
-slice of the disk, with one of them was marked "active".  The machine would
-boot by reading the first sector containing the boot code into RAM and then
-jumping to it.  The job of this small piece of boot code was to look at
-the 4 entry table and decide which OS was to be booted by looking
-for the "active" flag.   It would go and load the first sector of that slice
-of the disk into RAM and then and jump to it in turn.  This bit of boot
-code was called the "secondary boot", and could be specific to a given
-operating system.  The primary boot code and 4-entry table is known
-as the Master Boot Record, or MBR, and is very important to the proper
-operation of your PC!  We will discuss the MBR in more detail later.
-
-It was later realized, with the hindsight that IBM is famous for, that disks
-could be bigger than the 32Mb that the early DOS FAT-12 file system could
-handle, so they added a kludge:  They had two MSDOS slices, a "Primary" and
-a "Secondary".  The primary could still only be 32Mb, but the Secondary had
-no size limit.  And the trick was that the secondary had ANOTHER "table
-entry" so that now suddenly up to 5 slices could be available to MS-DOS.
-The Secondary boot record was later made recursive, thus effectively
-avoiding any fixed limit.  Of course, they were still stuck with a maximum
-of 26 slices given the use of "drive letters" in DOS.  They also reserved
-only 10 bits for cylinder addressing, limiting DOS to being able to address
-a maximum of 1024 cylinders (and cause of the dreaded "cylinder translation"
-kludges, the misconfiguration of which many users have seen as the notorious
-"Missing Operating System" message).  Yes, truly DOS was and is an utterly
-terrible operating system, which of course explains its amazing degree of
-success.  Anyway, this all brings us up to today, which is where FreeBSD
-comes in:
-
-
-1.2  What FreeBSD does
-----------------------
-FreeBSD has, like any other UNIX-like operating system, the concept of
-"partitions."  Partitions are used to implement its own "slicing"
-abstraction, and although there is no real difference between a slice and a
-partition as such, we use the two words to distinguish between these two
-different levels of slicing.
-
-The result is that we have a two-tier structure on the disk:
-
-+-----------+
-| MBR-table |
-+-----------+        +---------+
-| Slice 1   | -----> |  MSDOS  |
-+-----------+        +---------+
-| Slice 2   | 
-+-----------+        +-------------------+
-| Slice 3   | -----> | FreeBSD-disklabel |
-+-----------+        +-------------------+        +-----------------+
-| Slice 4   |        |    Partition A    | -----> | Root-filesystem |
-+-----------+        +-------------------+        +-----------------+
-                     |    Partition B    | ---
-                     +-------------------+    \    +----------------+
-                     |    Partition C    |     --> | swap-partition |
-                     +-------------------+         +----------------+
-                     |  ...              |
-
-
-Here are the rules that FreeBSD plays by:
-
-A:  FreeBSD always has an MBR slice with type 0xa5 (each of the 4 slices can
-    also have a unique integer identifier so you can tell your DOS slices
-    from your FreeBSD slices from your Linux slices, etc).  This means that
-    there should always be an MBR record, even in the case where FreeBSD
-    occupies the entire disk.
-B:  The FreeBSD slice contains the FreeBSD disklabel in the second sector
-    (remember, the first sector contains the secondary boot code for FreeBSD,
-     which is what prints that FreeBSD prompt at you when you first boot
-     FreeBSD from a floppy or hard disk).
-C:  The 'C' partition in the FreeBSD disklabel corresponds to the entire
-    FreeBSD slice.
-D:  The 'D' partition corresponds to the entire physical disk.
-E:  Should a disk not have a FreeBSD slice (because there simply is no 
-    FreeBSD on it anywhere), then the MBR slices are mapped into partitions
-    'E' to 'H' of an artificially created FreeBSD disklabel.  This is useful
-    for getting at DOS-only disks.
-
-Therefore, to get FreeBSD onto your disk, you need to do the following:
-
-  Step                                                          FreeBSD utility
-  ------------------------------------------------------------  ---------------
-  1.  Make an MBR slice for FreeBSD                             (FDISK)
-  2.  Partition the diskspace in the MBR slice into partitions  (DISKLABEL)
-  3.  Assign mountpoints to the partitions.                     (DISKLABEL)
-
-
-
-2.  The sysinstall utility
---------------------------
-
-The sysinstall utility is the program you first see when you boot
-FreeBSD's install floppy.  It is responsible for partitioning your
-disk, creating an MBR slice for FreeBSD, setting up the disklabel
-within that slice and creating filesystems for each FreeBSD partition
-you create within that slice.  It is composed of a number of screens.
-These are described below.
-
-
-2.1  The main screen
---------------------
-The main screen shows you the current status,  It shows you which disks
-FreeBSD has found, how big they are and how much of it is assigned to 
-FreeBSD in a FreeBSD MBR slice.  It also shows the partitions which have
-had a mountpoint assigned to them (not necessarily FreeBSD partitions; 
-FreeBSD is perfectly capable of mounting DOS disks directly).
-
-(H)elp  -- shows you this file.
-
-(F)disk -- enters the Fdisk editor, where you can change the MBR record.
- This is what you want to use to assign some part of the disk to FreeBSD.
-
-(D)isklabel -- enters the Disklabel editor, here you can change how the
- FreeBSD slice is partitioned for FreeBSD.
-
-(P)rocede -- will continue the installation process.
-
-(Q)uit -- Go back to the entry screen.
-
-
-2.2  FDISK - how to make an MBR slice
--------------------------------------
-There are some rules to follow here since altering your MBR is a potential
-minefield.  There is really no way for the sysinstall program to genuinely
-know that you have a valid MBR, so you have to be extra careful in what
-you edit.  Failure to do this properly can and will destroy your other
-operating system entries!
-
-Even if you don't plan to have MSDOS on a disk, make an MSDOS slice
-using the MSDOS's FDISK.COM program.  The reason for this is that if you
-do it that way, you are 100% sure that FreeBSD will use the same number
-of heads, sectors and cylinders as MSDOS would use.  If you really don't
-plan to have MSDOS on the disk, just (D)elete the slice in the FreeBSD's
-(F)disk editor.
-
-From the main screen press 'F' to enter the MBR editor.  You have five
-commands available:
-
-(H)elp -- Shows you this file.
-
-(D)elete -- Deletes a slice entirely.
-
-(E)dit -- Allows you to edit a slice.  It will ask how many megabytes
-  you want to assign to the slice, and will suggest the maximum possible
-  as a default.  It might say zero, even though there is disk space
-  available, in which case you will probably need to delete and recreate the
-  other partitions to get it to see where the free space is.
-  It will then ask you what type to give the slice, for which the default is
-  0xa5 (a FreeBSD slice).  You can enter any other number here too, which
-  can be useful as a placeholder for some other OS you plan to install
-  later.  Finally, it will ask you about the "boot flag".  0x80 means "boot
-  from this" slice by default, and anything else means "don't".
-
-  If you specified a FreeBSD slice, any existing slices with the 0xa5 
-  type will be reset to 0x00 "unused".  FreeBSD only supports one slice
-  per disk for FreeBSD.
-
-(R)eread -- This is your "undo" function.  It will read the data of the
-  disk again, disposing of any changes you may have made.
-
-(W)rite -- When you are satisfied with the data, this function will write
-  the new MBR to the disk.
-
-(Q)uit -- Go back to the main screen.
-
-
-2.3  Disklabel - How to divide up the FreeBSD slice.
-----------------------------------------------------
-
-The disklabel screen provides the following commands:
-
-(H)elp -- Shows you this file.
-
-(S)ize -- Resizes a partition for you, it will suggest as a default the
-   maximum amount of diskspace it can find.  This algorithm isn't too smart
-   and may say zero, even though there is diskspace available.  If it
-   does, delete and resize the other partitions.
-
-(A)ssign -- Here you assign where the filesystem in a partition is to
-   be mounted.  `b' partitions will always be made into "swap" partitions.
-
-(D)elete -- Delete a partition.
-
-(R)eread -- The undo function.  It will reread the current disklabel from
-   the kernel.
-
-(W)rite -- This will write the disklabel to the disk.  You must always write
-   before you quit, otherwise your changes will be lost.
-
-(Q)uit -- Exit back to the main screen.
-
-
-2.4.  Hints on partition sizing
--------------------------------
-
-While it's impossible to say how much space you're going to want to
-make your various partitions without knowing more about your intended
-applicatins, here are some good rules of thumb to follow:
-
-1. Root (/) should be at least 18MB, and probably no more than 50MB unless
-   you have some special reason for making your root partition really
-   large.  Remember that the root filesystem is only supposed to contain
-   vital system files and little else.
-
-2. Swap should be at least 2*memory.  That is to say if you have 8MB of
-   memory, then you probably want 16MB of swap.  Even more swap space
-   certainly doesn't hurt, if you can afford to allocate it, and you should
-   also think ahead a little to any planned memory upgrades you may have
-   in mind since increasing this later can be very painful!
-
-   If you're going to run the X Window System (XFree86), you should also
-   consider having a *minimum* of 16MB of swap, since X tends to really
-   use it up.
-
-3. /usr can take up the rest of your disk, though some people like to create
-   extra partitions for user home directories and the like.  Be sure to make
-   your /usr big enough to contain the system software (about 50MB) and
-   perhaps some of your own, unless you're going to use symbolic links to
-   point things like /usr/local (or /usr/src) somewhere else.
-
-
-Here are some suggested filesystem names and sizes, just for reference:
-
-Mountpoint	Filesystem size
--------------------------------
-/var		10Mb
-/usr		50Mb
-/		16Mb
-
-/usr/src       120Mb    If you want to have the sources online
-/usr/obj       100Mb    If you want to compile all of them at one time
-
-/usr/X11R6	50Mb	If you load the entire XFree86 binary kit.
-
-
-$Id: DISKSPACE.FAQ,v 1.6 1994/11/18 10:32:43 jkh Exp $
diff --git a/share/FAQ/Diskless.FAQ b/share/FAQ/Diskless.FAQ
deleted file mode 100644
index 84af09c..0000000
--- a/share/FAQ/Diskless.FAQ
+++ /dev/null
@@ -1,130 +0,0 @@
-Setting up a Diskless FreeBSD system
-====================================
-
-netboot.com/netboot.rom allow you to boot your FreeBSD machine over the
-network and run FreeBSD without having a disk on your client.  Under 2.0
-it is now possible to have local swap.  Swapping over NFS is also still
-supported.
-
-The list of supported Ethernet cards:
-
-	Western Digital/SMC 8003, 8013, 8216 and compatibles
-	NE1000/NE2000 and compatibles (requires recompile)
-
-
-Setup Instructions
-------------------
-
-  - Find a machine that will be your server.  This machine will require
-    enough disk space to hold the FreeBSD 2.0 binaries and have bootp, tftp
-    and NFS services available.
-
-	tested machines:
-
-		HP9000/8xx running HP-UX 9.04 or later (pre 9.04 doesn't work)
-		Sun/Solaries 2.3. (you may need to get bootp)
-
-
-  - Set up a bootp server to provide the client with IP, gateway, netmask
-
-	sample entry:
-
-                diskless:\
-                        :ht=ether:\
-                        :ha=0000c01f848a:\
-                        :sm=255.255.255.0:\
-                        :hn:\
-                        :ds=192.1.2.3:\
-                        :ip=192.1.2.4:\
-			:gw=192.1.2.5:\
-                        :vm=rfc1048:
-
-  - Set up a TFTP server (on same machine as bootp server) to provide
-    booting information to client.  The name of this file is cfg.X.X.X.X
-    (or /tftpboot/cfg.X.X.X.X, it will try both) where X.X.X.X is the
-    IP address of the client.  The contents of this file can be any valid
-    netboot commands.  Under 2.0, netboot has the following commands:
-
-	help			- print help list
-	ip <X.X.X.X>		- print/set client's IP address
-	server <X.X.X.X>	- print/set bootp/tftp server address
-	netmask <X.X.X.X>	- print/set netmask
-	hostname <name>		- print/set hostname
-	kernel <name>		- print/set kernel name
-	rootfs <ip:/fs>		- print/set rootfilesystem
-	swapfs <ip:/fs>		- print/set swapfilesystem
-	swapsize <size>		- set diskless swapsize in Kbytes
-	diskboot		- boot from disk
-	autoboot		- continue boot process
-
-    A typical completely diskless cfg file might contain:
-
-	rootfs 192.1.2.3:/rootfs/myclient
-	swapfs 192.1.2.3:/swapfs
-	swapsize 20000
-	hostname myclient.mydomain
-
-    A cfg file for a machine with local swap might contain:
-
-	rootfs 192.1.2.3:/rootfs/myclient
-	hostname myclient.mydomain
-
-  - Ensure that your NFS server has exported the root (and swap if applicable)
-    filesystems to your client, and that the client has root access to these
-    filesystems
-
-    A typical /etc/exports file might look like:
-
-	(FreeBSD)
-
-	/rootfs/myclient -maproot=0:0 myclient.mydomain
-	/swapfs -maproot=0:0 myclient.mydomain
-
-
-	(HP-UX)
-
-	/rootfs/myclient -root=myclient.mydomain
-	/swapfs -root=myclient.mydomain
-
-
-  - If you are swapping over NFS (completely diskless configuration) create a
-    swap file for your client using touch.  If your 'swapfs' command
-    has the argument /swapfs as in the example above, the swapfile for myclient
-    will be called /swapfs/swap.X.X.X.X where X.X.X.X is the client's IP addr.
-
-	eg:   # touch /swapfs/swap.192.1.2.4
-
-  - Unpack the root filesystem in the directory the client will use for its
-    root filesystem (/rootfs/myclient in the example above).
-
-	*** On HP-UX systems:  The server should be running HP-UX 9.04 or
-	    later for HP9000/800 series machines.  Prior versions don't allow
-	    the creation of device files over NFS.
-
-	*** When extracting /dev in /rootfs/myclient, beware that some systems
-	    (HPUX) will not create device files that FreeBSD is happy with.
-	    You may have to go to single user mode on the first bootup
-	    (press control-c during the bootup phase), cd /dev  and do a
-	    "sh ./MAKEDEV all" from the client to fix this.
-
-  - Run netboot.com on the client or make an EPROM from the netboot.rom file
-    
-
-Using Shared / and /usr filesystems
------------------------------------
-At present there isn't an officially sanctioned way of doing this, although
-I have been using a shared /usr filesystem and individual / filesystems for
-each client.  If anyone has any suggestions on how to do this cleanly, please
-let me and/or the core group know.
-
-
-
-Compiling netboot for specific setups
--------------------------------------
-
-Netboot can be compiled to support NE1000/2000 cards by changing the
-configuration in /sys/i386/boot/netboot/Makefile.  See the comments
-at the top of this file.
-
-
-Martin Renters				martin@innovus.com
diff --git a/share/FAQ/FreeBSD-1.1.FAQ b/share/FAQ/FreeBSD-1.1.FAQ
deleted file mode 100644
index 13a078e..0000000
--- a/share/FAQ/FreeBSD-1.1.FAQ
+++ /dev/null
@@ -1,987 +0,0 @@
-
-                               FreeBSD
-                      Frequently Asked Questions
-                      For Versions 1.1 and below 
-
-Please mail all suggestions and additions to <FreeBSD-FAQ@FreeBSD.ORG>
-
-
-Revision: $Id: FreeBSD-1.1.FAQ,v 1.4 1994/10/10 10:46:14 gclarkii Exp $
-
-All entries are assumed to be relevant to both FreeBSD 1.1 and FreeBSD 1.1.5,
-unless otherwise noted.
-
-
-Table of Contents
------------------
-
-0 Preface
-1 Installation
-2 Hardware Compatibility
-3 Commercial applications
-4 User Applications
-5 Miscellaneous Questions
-6 Kernel Configuration 
-7 System Administration
-8 Networking
-9 Serial Communications
-
-
-
-0 Preface
----------
-
-Welcome to the FreeBSD 1.1 FAQ!  This document tries to answer some of
-the most frequently asked questions about FreeBSD 1.1 (or later,
-unless specifically indicated).  If there's something you're having
-trouble with and you just don't see it here, then please send mail to:
-
-        <questions@FreeBSD.ORG>
-
-
-Some of the instructions here will also refer to auxiliary utilities
-in the /usr/src/share/FAQ directory.  CDROM purchasers and net folks
-who've grabbed the FreeBSD current `srcdist' will have these files.  If
-you don't have the source distribution, then you can either grab the
-whole thing from:
-
-        ftp.FreeBSD.ORG:pub/FreeBSD/FreeBSD-current/src
-
-0.1:  What is FreeBSD?  
-
-FreeBSD is a UN*X type operating system based on William Jolitz's port
-of U.C. Berkeley's Networking Release 2 to the i386, 386BSD.  It is no
-longer correct to say that FreeBSD is only 386BSD with the patchkit
-applied!  There have been many additions and bug fixes made throughout
-the entire system, some of the highlights of which are:
-
-   More robust and extensive PC device support
-   System V-style IPC, messaging and semaphores
-   Shared Libraries
-   Much improved virtual memory code
-   Better console driver support
-   Network booting (diskless) support
-   /proc filesystem
-   Yellow Pages support
-   `LDT' support for WINE (primitive but developing Windows emulation)
-   Too many additional utilities and applications to mention
- 
-
-0.2:  My friends told me that FreeBSD was illegal and I shouldn't use it.
-      Is this really true?
-
-FreeBSD versions up to and including 1.1 have included code from
-Berkeley's Net/2 distribution.  UNIX Systems Laboratories (now Novell)
-sued Berkeley claiming that Net/2 included some code that belonged to
-USL.  In February of 1994, USL and Berkeley announced a settlement in
-which neither side admitted to doing anything wrong, but UCB agreed to
-stop distributing the disputed software.
-
-Since Berkeley will no longer defend this code, we have been requested
-to stop distributing it, and will be integrating all the improvements
-we have made in the VM system and i386-specific code into Berkeley's
-4.4-Lite distribution; the result will form the basis of FreeBSD 2.0.
-We expect the integration to take place over a period of three to six
-months, during which time we will have to stop work on 1.1 and
-concentrate all our efforts on the merge, and we expect to make more 
-information available on the status of the merge effort as the situation 
-progresses.
-
-However, to answer the question, "No.  FreeBSD is not illegal."  We
-have been allowed by USL to distribute 1.1 as the last Net/2 derived
-version, after which we have committed to move to 4.4 as previously 
-stated.
-
-We expect to make more information available on the status of the
-merge effort as the situation progresses.
-
-0.3:  What are the FreeBSD mailing lists, and how can I get on them? 
-
-The following mailing lists are provided for FreeBSD users and
-developers.  For more information, send to
-<majordomo@FreeBSD.ORG> and include a single line saying
-``help'' in the body of your message.
-
-announce:  	For announcements about or on FreeBSD.
-hackers:   	Useful for persons wishing to work on the internals. 
-questions: 	General questions on FreeBSD. 
-bugs:      	Where bugs should be sent.
-commit:    	This list carries the commit messages for freefall.  Useful
-                for tracking ongoing work.
-SCSI:      	Mailing list for SCSI developers. 
-current:   	This list is for persons wishing to run FreeBSD-current
-                and carries announcements and discussions on current.
-ports:          Discussion of "/usr/ports"
-hardware:       Types of hardware FreeBSD runs on
-security:       Security issues
-platforms:      Porting to non-Intel platforms
-
-Please see also the FreeBSD mailing list FAQ in:
-
-        /usr/src/share/FAQ/FreeBSD.mailing-list.FAQ
-
-0.4:  What are the various FreeBSD news groups? 
-
-While there are no groups currently dedicated to FreeBSD, you may find
-the following groups useful.
-
-comp.os.386bsd.announce:     For announcements
-comp.os.386bsd.apps:         For applications
-comp.os.386bsd.questions:    For questions
-comp.os.386bsd.development:  For working on the internals
-comp.os.386bsd.bugs:         About bugs
-comp.os.386bsd.misc:         For items that don't fit anywhere else
-
-NOTE: These groups cover all the *BSDs (FreeBSD, NetBSD, 386BSD).
-
-
-
-1 Installation
---------------
-
-1.1:  I just installed my system and rebooted.  Now I can't find the
-      extract or configure programs, where did they go?
-
-These two commands are just shell functions defined in /.profile.  To
-get these back, boot FreeBSD with a `-s' at the boot prompt.
-
-
-1.2:  I want to install FreeBSD onto a SCSI disk that has more than
-      1024 cylinders.  How do I do it?
-
-This depends.  If you don't have DOS (or another operating system) on
-the system, you can just keep the drive in native mode and simply make
-sure that your root partition is below 1024 so the BIOS can boot the
-kernel from it.  It you also have DOS/some other OS on the drive then
-your best bet is to find out what parameters that it thinks you have
-before installing FreeBSD.  When FreeBSD's installation procedure
-prompts you for these values, you should then enter them rather than
-simply going with the defaults.
-
-There is a freely available utility distributed with FreeBSD called
-`pfdisk' (located in the tools/ subdirectory) which can be used for
-this purpose.
-
-
-1.3:  When I boot FreeBSD it says ``Missing Operating System''.
-
-See question 1.2.  This is classically a case of FreeBSD and DOS or
-some other OS conflicting over their ideas of disk geometry.  You will
-have to reinstall FreeBSD, but obeying the instructions given above
-will almost always get you going.
-
-
-1.4:  I have an IDE drive with lots of bad blocks on it and FreeBSD doesn't
-      seem to install properly.
-
-FreeBSD's bad block (bad144) handling is still not 100% (to put it
-charitably) and it must unfortunately be said that if you've got an
-IDE or ESDI drive with lots of bad blocks, then FreeBSD is probably
-not for you!  That said, it does work on thousands of IDE based
-systems, so you'd do well to try it first before simply giving up.
-
-IDE drives are *supposed* to come with built-in bad-block remapping;
-if you have documentation for your drive, you may want to see if this
-feature has been disabled on your drive.  However, ESDI, RLL, and
-ST-506 drives normally do not do this.
-
-<1.1.5>
-FreeBSD-current has better bad block handling due to improvments made
-to the wd driver.
-
-1.5:  I have 32MB of memory, should I expect any special problems?
-
-If you have an IDE controller, no.  Likewise, if you have a full EISA
-system with EISA disk controller or a working local bus controller
-(read further) you'll have no problems. If you have an ISA system, or
-an EISA system with an ISA disk controller then you will most
-certainly have problems with the upper 16MB of memory due to the ISA
-24 bit DMA limitation (which ISA cards in EISA systems will also
-exhibit).  If you have a local bus disk controller, then you should be
-OK, UNLESS it's a Buslogic Bt445S with a revision less than `D' (BIOS
-3.36 or earlier).
-
-<1.1.5>
-1.1.5 has bounce-buffer support that make all of the above scenarios work
-with a full 32MB of memory or more.  You are therefore advised to simply pull
-16MB of memory out, install, and then see about upgrading to FreeBSD 1.1.5
-so that you can put it back.
-
-
-1.6:  Do I need to install the complete sources?
-
-In general, no.  However, we would strongly recommend that you
-install, at a minimum, the `base' source kit, which includes several
-of the files mentioned here, and the `sys' (kernel) source kit, which
-includes sources for the kernel.  There is nothing in the system which
-requires the presence of the sources to operate, however, except for
-the kernel-configuration program config(8).  With the exception of the
-kernel sources, our build structure is set up so that you can
-read-only mount the sources from elsewhere via NFS and still be able
-to make new binaries.  (Because of the kernel-source restriction, we
-recommend that you not mount this on /usr/src directly, but rather in
-some other location with appropriate symbolic links to duplicate the
-top-level structure of the source tree.)
-
-Having the sources on-line and knowing how to build a system with them
-will make it much easier for you to upgrade to future releases of
-FreeBSD.
-
-1.7:  DES encryption software can not be exported from the United
-      States.  If I live outside the US, how can I encrypt passwords?
-
-Since the DES encryption algorithm, which is used by passwd(1) and
-friends to encrypt passwords cannot legally be exported from the US,
-non-US users should not download this software from US FTP sites.
-
-There is however a replacement libcrypt available, based on sources
-written in Australia by David Burren.  This code is now available on
-some non-US FreeBSD mirror sites.  Sources for the unencumbered
-libcrypt, and binaries of the programs which use it, can be obtained
-from the following FTP sites:
-
-        South Africa:   braae.ru.ac.za:/pub/FreeBSD/securedist/
-                        owl.und.ac.za (currently uncertain)
-        Iceland:        ftp.veda.is:/pub/crypt/FreeBSD/
-
-The non-US securedist can be used as a direct replacement for the
-encumbered US securedist.  This securedist package is installed the
-same way as the US package (see installation notes for details).  If
-you are going to install DES encryption, you should do so as soon as
-possible, before installing other software.
-
-Non-US users should please not download any encryption software from
-the USA.  This can get the maintainers of the sites from which the
-software is downloaded into severe legal difficulties.
-
-A non-US distribution of Kerberos is also being developed, and current
-versions can generally be obtained by anonymous FTP from
-braae.ru.ac.za.
-
-There is also a mailing list for the discussion of non-US encryption
-software.  For more information, send an email message with a single
-line saying ``help'' in the body of your message to
-<majordomo@braae.ru.ac.za>.
-
-1.8     HELP!  My keyboard locked up during the install!
-
-Some keyboard controllers are not a friend to FreeBSD.  Among these are
-those on certain models of Gateway, IBM and AST machines.  The most frequent
-symptom encountered in such cases is that the keyboard refuses to respond
-to input when at the `kcopy>' prompt in the second phase of bootstrapping
-FreeBSD.  Fortunately, there is a work-around that may get you all the
-way home.  Reset the machine and boot the kcopy floppy again, but this
-time, as the kernel is booting, tap periodically on the num-lock key
-until the kcopy prompt appears.  Your keyboard should respond properly.
-
-Once your system is on the hard disk the problem generally goes away.
-Some folks for whom the problem persists even after this stage find
-relief in switching to the SYSCONS console driver (see /sys/i386/conf/SYSCONS),
-which is in any case far more featureful than pccons and a recommended
-upgrade.
-
-
-
-2 Hardware compatibility
-------------------------
-
-2.1:  What kind of hard drives does FreeBSD run on?
-
-FreeBSD supports ST-506 (sometimes called ``MFM''), RLL, and ESDI
-drives, which are usually connected to WD-1002, WD-1003, or WD-1006
-controllers (although clones should also work).  FreeBSD also supports
-IDE and SCSI hard drives.
-
-2.2:  What SCSI controllers are supported?
-
-FreeBSD supports the following SCSI controllers:
-
-Adaptec              AH-1542 Series <ISA>
-                     AH-1742 Series <EISA>
-Buslogic             BT-445 Series <VLB> (but see section 1.5)
-                     BT-545 Series <ISA>
-                     BT-742 Series <EISA>
-                     BT-747 Series <EISA>
-Future Domain        TMC-8XX/950 Series <ISA> (1.1.5 ONLY)
-Seagate              ST-01/02 Series <ISA> (1.1.5 ONLY)
-UltraStor            UH-14f Series <ISA>
-                     UH-34f Series <EISA/VLB>
-
-There is supposed to be a UltraStor 24f driver floating around, but
-we're not sure where (could someone please point us at it?).   
-
-2.3:  What CD-ROM drives are supported by FreeBSD?
-
-Any SCSI drive connected to a supported controller.  Mitsumi
-LU002(8bit), LU005(16bit) and FX001D(16bit 2x Speed).
-
-FreeBSD does NOT support drives connected to a Sound Blaster or
-non-SCSI SONY or Panasonic drives.  A general rule of thumb when
-selecting a CDROM drive for FreeBSD use is to buy a very standard SCSI
-model; they cost more, but deliver very solid performance in return.
-Do not be fooled by very cheap drives that, in turn, deliver VERY LOW
-performance!  As always, you get what you pay for.
-
-The Mitsumi driver is known to be extremely slow compared to SCSI
-drives.
-
-
-2.4:  What multi-port serial cards are supported by FreeBSD?
-
-AST/4 and BOCA 4/8/16 port cards.  Some unnamed clone cards have also
-been known to work, especially those that claim to be AST compatible.
-Check the sio(4) man page to get more information on configuring such
-cards.
-
-
-2.5:  Does FreeBSD support the AHA-2742 SCSI adapter from Adaptec?
-
-No, FreeBSD does not.  This is due to Adaptec's unwillingness to
-supply programming information under other than non-disclosure.  This
-is unfortunate, but there's nothing we can do about it.
-
- 
-2.6:  I have a Mumbleco bus mouse.  Is it supported and if so, how do I set
-      it up for XFree86?
-
-FreeBSD supports the Logitech and ATI Inport bus mice.  You need to
-add the following line to the kernel config file and recompile for the
-Logitech and ATI mice:
-
-        device        mse0    at isa? port 0x23c tty irq6 vector mseintr
-
-
-2.7:  I have a PS/2 mouse (`keyboard' mouse) [Alternatively:  I have a
-      laptop with a track-ball mouse].  How do I use it?
-
-<1.1.5>:  The PS/2 mouse is part of the system.  See the psm0 driver 
-description in /sys/doc/options.doc.
-
-
-2.8:  What types of tape drives are supported under FreeBSD?
-
-FreeBSD supports SCSI, QIC-02 and QIC-40/80 (Floppy based) tape
-drives.  This includes 8-mm (aka Exabyte) and DAT drives.
-
-
-2.9:  What sound cards are supported by FreeBSD?
-
-FreeBSD supports the SoundBlaster, SoundBlaster Pro, Pro Audio
-Spectrum 16, AdLib and Gravis UltraSound sound cards. There is also
-limited support for MPU-401 and compatible MIDI cards.  The
-SoundBlaster 16 and SoundBlaster 16 ASP cards are not yet supported.
-NOTE: This is only for sound!  This driver does not support CD-ROMs,
-SCSI or joysticks on these cards.
-
-
-2.10:   What network cards does FreeBSD support?
-
-There is support for the following cards:
-
-`ed' driver:
-        NE2000 and 1000
-        WD/SMC 8003, 8013 and Elite Ultra (8216)
-        3Com 3c503 
-        And clones of the above
-
-`ie' driver:
-        AT&T EN100/StarLAN 10
-
-`is' driver:
-        Isolan AT 4141-0
-        Isolink 4110
-
-`ep' driver:
-        3com 3c509 (*)
-
-
-(*)The `ep' driver is known to have some problems; see the
-/usr/src/KNOWNBUGS file for more details.
-
-
-2.11:  I have a 386/486sx/486SLC machine without a math co-processor.
-       Will this cause me any problems?
-
-Generally no, but there are circumstances where you will take a hit,
-either in performance or accuracy of the math emulation code (see
-section 4.1).  In particular, drawing arcs in X will be VERY slow.  It
-is highly recommended that you lay out the $50 or so for a math
-co-processor; it's well worth it.  NOTE: Some math co-processors are
-better than others.  It pains us to say it, but nobody ever got fired
-for buying Intel.  Unless you're sure it works with FreeBSD, beware of
-clones.
-
-2.12:  I am about to buy a new machine to run FreeBSD on and
-       want an idea of what other people are running.  Is there list
-       of other systems anywhere? 
-
-Yes.  Please look at the file FAQ/Systems-1.1.FAQ.  This file
-is a listing of hardware that people are running in their machines.
-Please note, this is a raw listing of equipment that other users
-have sent in.
-
-
-
-3 Commercial Applications
--------------------------
-
-Note: This section is still very sparse, though we're hoping, of
-course, that companies will add to it! :) The FreeBSD group has no
-financial interest in any of the companies listed here but simply
-lists them as a public service (and feels that commercial interest in
-FreeBSD can have very positive effects on FreeBSD's long-term
-viability).  We encourage commercial software vendors to send their
-entries here for inclusion.
-
-
-3.1:  Where can I get Motif for FreeBSD?
-
-Sequoia International provides commercial quality Motif 1.2.3
-development kits for FreeBSD 1.1 (with full shared library support)
-under the product name of `SWiM'.  Due to licensing restrictions from
-the OSF, and the fact that Sequoia needs to make a living, these are
-NOT FREE, but nonetheless quite reasonably priced in comparison to
-many other commercial Motif distributions.  Send electronic mail to
-<info@seq.com> for further information.
-
-3.2:  What about other commercial quality development systems for FreeBSD?
-
-ParcPlace Systems, Inc., who currently provides their excellent
-`Object Interface & Object Builder' GUI development environment free
-of charge to Linux users, is considering the the FreeBSD platform and
-will make their intentions known fairly shortly.
-
-
-
-4 User Applications
--------------------
-
-4.1:  I want to run X, how do I go about it?
-
-First, get the XFree86 distribution of X11R5 from XFree86.cdrom.com.
-The version you want for FreeBSD 1.1 and later is XFree86 2.1.  Follow
-the instructions for installation carefully. You may then wish to read
-the documentation for the ConfigXF86 tool, which assists you in
-configuring XFree86 for your particular graphics card/mouse/etc.
-
-
-4.1:  I've been trying to run ghostscript on a 386 (or 486sx) with no
-      math co-processor and I keep getting errors.  What's up?
-
-<1.1.5>:  For 1.1.5 you may add the following to your kernel config file and
-it  will be compiled in.
-options                         GPL_MATH_EMULATE
-
-NOTE:  You will need to remove the MATH_EMULATE option when you do this.
-
-
-4.2:  If I want something like seyon, term, Kermit, emacs or any one of
-      hundreds of popular freeware utilities, is there a good place to
-      search through first?
-
-Yes, the FreeBSD `ports collection' was put together for just that
-purpose.  It contains some of the most often requested languages,
-editors, mail and news reading programs, network software and many
-many megabytes of other types of useful goodies.  CDROM people will
-probably have the ports collection already in /usr/ports, other folks
-can get at the latest snapshot of the entire collection in:
-
-        ftp.FreeBSD.ORG:pub/FreeBSD/FreeBSD-current/ports
-
-Note that this FTP server permits getting entire directories as one
-(optionally gzipped or compressed) tar file.  Read the FTP welcome
-banner carefully for details.
-
-
-4.3:  I want all this neat software, but I haven't got the space or
-      CPU power to compile it all myself.  Is there any way of getting
-      binaries?
-
-Yes.  We support the concept of a `package', which is essentially a
-gzipped binary distribution with a little extra intelligence embedded
-in it for doing any custom installation work required.  Packages can
-also be installed or deinstalled again easily without having to know
-the gory details.  CDROM people will have a packages/ directory on
-their CD, others can get the currently available packages from:
-
-        ftp.FreeBSD.ORG:pub/FreeBSD/packages-1.1
-
-Note that all ports may not be available as packages, and that new
-packages are constantly being added.  It is always a good idea to
-check periodically to see which packages are available.  A README file
-in the packages directory provides more details on the care and
-feeding of the package software, so no explicit details will be given
-here.
-
-4.4:  I'm trying to get Perl to work properly, but I keep getting
-      errors about dbm failures when I test it.  How can I fix this?
-
-The problem here is that the tests are written for an older version of
-the dbm code.  There is nothing wrong with perl and the errors can
-be ignored.
-
-4.5:  I've been trying to get GCC 2.6.0 running on my system and it
-      keeps bombing.  What can I do about?
-
-Due to problems with 2.6.0 and the advent of FreeBSD 2.0, we do not
-support GCC 2.6.0 and suggest that you wait for 2.0.
-
-
-
-5 Miscellaneous Questions
-----------------
-
-5.1:  I've heard of something called FreeBSD-current.  How do I run it, and
-      where can I get more information?
-
-Read the file /usr/src/share/FAQ/FreeBSD.current.policy,
-it will tell you all you need to know.
-
-
-5.2:  What is this thing called `sup', and how do I use it?
-
-SUP stands for Software Update Protocol, and was developed by CMU for
-keeping their development trees in sync.  We use it to keep remote
-sites in sync with our central development sources.
-
-To use it, you need to have direct internet connectivity (not just
-mail or news).  First, pick up the sup_bin.tgz package from:
-
-        ftp.FreeBSD.ORG:pub/FreeBSD/packages-1.1
-
-Second, read the file /usr/src/share/FAQ/FreeBSD.sup.faq.
-
-This file describes how to setup sup on your machine.  You may also
-want to look at /usr/src/contrib/FAQ/FreeBSD.*.supfile,
-which are a set of supfiles for supping from FreeBSD.ORG
-
-
-5.3:  How do I create customized installation disks that I can give
-      out to other people at my site?
-
-The entire process of creating installation disks and source and
-binary archives is automated by various targets in
-/usr/src/etc/Makefile.  The information there should be enough to get
-you started.
-
-5.4:  How do I re-build my system without clobbering the existing
-      installed binaries?
-
-If you define the environment variable DESTDIR while running `make
-world' or `make install', the newly-created binaries will be deposited
-in a directory tree identical to the installed one, rooted at
-${DESTDIR}.  Some random combination of shared libraries modifications
-and program rebuilds can cause this to fail in `make world', however.
-
-
-5.5:  When my system booted, it told me that ``(bus speed defaulted)''.
-      What does that mean?
-
-The Adaptec 1542 SCSI host adapters allow the user to configure their
-bus access speed in software.  Previous versions of the 1542 driver tried
-to determine the fastest usable speed and set the adapter to that.  We
-found that this breaks some users' systems, so you now have to define
-the ``TUNE_1542''' kernel configuration option in order to have this
-take place.  Using it on those systems where it works may make your
-disks run faster, but on those systems where it doesn't, your data could
-be corrupted.
-
-5.6:  I would like to track changes to current and do not have net access.  
-      Is there any way besides downloading the whole tree?
-
-Yes, Poul-Henning has set up a source tracking list.  Please email 
-majordomo@ref.tfs.com with a body of "get ctm-src-cur README" for
-futher information.
-
-5.7:  How do I split up large binary files into smaller 240k files
-      like the distribution does?
-
-Newer BSD based systems have a "-b" option to split that allows them to
-split files on arbitary byte bondaries.
-
-Here is an example from /usr/src/Makefile.
-bin-tarball:
-	(cd ${DISTDIR}; \
-		tar cf - . \
-		gzip --no-name -9 -c | \
-		split -b 240640 - \
-		${RELEASEDIR}/tarballs/bindist/bin_tgz.)
-
-5.8:  I'm running Syscons and every morning my console locks up.  What
-      is going on here?
-
-This sounds like the "kill -1 syslogd" problem.  Make sure that the
-following is correct on your system.
-1. The attributes of the following nodes are correct.
-/dev/console
-crw-------	1 root		0,	0 May 23 15:32 /dev/console
-/dev/ttyv0
-crw-------	1 root		12,	0 May 23 15:32 /dev/ttyv0
-The part you are concerned with are the major and minor device numbers.
-
-2. Make sure that getty is running on ttyv0 and NOT console.
-
-3. If /dev/vga exists that it is a symlink to /dev/ttyv0.
-
-5.9:  I've had a couple of system panics and would like to be able
-      browse the system dumps.  The normal kernel is stripped and
-      I don't want to run a bloated kernel.  What can I do?
-
-Please retrieve the file FAQ/FreeBSD.kdebug.FAQ.  This
-file covers the instructions for looking at system dumps.
-
-5.10: I've got a Buslogic BT-946c with an Intel motherboard and
-      right after the kernel probes, my system hangs.  How do I
-      fix it?
-
-Two things here.
-1. Some intel motherboards have fixed PCI INT pins and you will have
-   to match the BT-946c's INT to match the motherboards.
-2. FreeBSD 1.1.5.1 expects the INT on a non-standard pin and you
-   will have to also match this one.
-
-
-6 Kernel Configuration
-----------------------
-
-6.1:  When I compile a kernel with multi-port serial code, it tells me
-      that only the first port is probed and the rest skipped due to
-      interrupt conflicts.  How do I fix this?
-
-The problem here is that FreeBSD has code built-in to keep the kernel
-from getting trashed due to hardware or software conflicts.  The way
-to fix this is to leave out the IRQ settings on other ports besides
-the first.  Here is a example:
-
-#
-# Multiport high-speed serial line - 16550 UARTS
-#
-device    sio2    at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr
-device    sio3    at isa? port 0x2a8 tty flags 0x501 vector siointr 
-device    sio4    at isa? port 0x2b0 tty flags 0x501 vector siointr
-device    sio5    at isa? port 0x2b8 tty flags 0x501 vector siointr
-
-
-6.2:  FreeBSD is supposed to come with support for QIC-40/80 drives but
-      when I look, I can't find it.
-
-You need to uncomment the following line in the generic config file
-(or add it to your config file) and recompile.
-
-controller      fdc0    at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
-disk            fd0     at fdc0 drive 0
-disk            fd1     at fdc0 drive 1
-#tape           ft0     at fdc0 drive 2
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You will have a device called /dev/ft0, which you can write to through
-a special program to manage it called `ft' - see the man page on ft for
-further details.  Versions previous to -current also had some trouble dealing
-wiht bad tape media; if you have trouble where ft seems to go back and forth
-over the same spot, try grabbing the latest version of ft from /usr/src/sbin/ft 
-in current and try that.
-
-
-6.3:  Does FreeBSD support IPC primitives like those in System V?
-
-Yes, FreeBSD supports System V-style IPC.  This includes shared
-memory, messages and semaphores.  You need to add the following lines
-to your kernel config to enable them.
-
-options         SYSVSHM
-options         "SHMMAXPGS=64"          # 256Kb of sharable memory
-options         SYSVSEM                 # enable for semaphores
-options         SYSVMSG                 # enable for messaging
-
-Recompile and install.
-
-
-6.4:  Are there any utilities that make configuring a kernel easier?
-
-Well, yes and no.  Look in /sys/i386/doc/options.doc (/sys/doc on post
-1.1 systems) for a list of kernel options you can set, and what they
-do.  For a friendlier front-end to the process, see
-/usr/src/contrib/configit
-
-
-6.5:  Will FreeBSD ever support other architectures?
-
-Several different groups have expressed interest in working on
-multi-architecture support for FreeBSD.  If you are interested in
-doing so, please contact the developers at
-<hackers@FreeBSD.ORG> for more information on our
-strategy for porting.
-
-
-6.6:  I just wrote a device driver for a Foobar Systems, Inc.
-      Integrated Adaptive Gronkulator card.  How do I get the
-      appropriate major numbers assigned?
-
-This depends on whether or not you plan on making the driver publicly
-available.  If you do, then please send us a copy of the driver source
-code, plus the appropriate modifications to files.i386, a sample
-configuration file entry, and the appropriate MAKEDEV code to create
-any special files your device uses.  If you do not, or are unable to
-because of licensing restrictions, then character major number 32 and
-block major number 8 have been reserved specifically for this purpose;
-please use them.  In any case, we'd appreciate hearing about your
-driver on <hackers@FreeBSD.ORG>.
-
-6.7:  I'm wanting to switch console drivers to Syscons.  I changed my
-      kernel config file to run Syscons, but when I reboot the system
-      locks up!  How do I fix it?
-
-There are four things that need to be done to properly install syscons
-on a system.
-1. Add the following line to your kernel config file while deleting the
-   line for pccons.
-device	sc0	at isa? port "IO_KBD" tty irq 1 vector scintr
-(Note the changed vector 'scintr'.  It is a common error to change the 
-device name but NOT the vector.
-
-2. Add the following option to your config file.
-options		"NCONS=6" # Change to reflect the number of consoles
-
-3. Modify /etc/ttys to enable gettys on ttyv0 - ttyv??.  Here is an
-example line.
-ttyv0	"/usr/libexec/getty Pc" Pc3	on	secure
-Please make sure that you have disabled the getty on /dev/console.
-
-4. Create the device nodes in /dev.  This is done useing the MAKEDEV
-script located in that directory.  Here is a command line that will create
-6 virtual consoles.
-MAKEDEV vty6
-If /dev/vga exists, it should now be a symlink to /dev/ttyv0.
-
-NOTE:  If you are going to be running X, you will need an unused vty that
-       has no getty running on it.
-
-
-
-7 System Administration
------------------------
-
-7.1:  How do I add a user easily?  I read the man page and am more confused
-      than ever!  [Alternatively:  I didn't read the man page, I never read
-      man pages! :-) ]
-
-Look at Gary Clark's Perl package ``AddIt'', which may be found in
-/usr/src/contrib/adduser.  This is a first attempt at solving the
-problem and may be replaced with a more complex but capable solution
-later.
-
-
-7.2: I'm trying to use my printer and keep running into problems.  I tried
-     looking at /etc/printcap, but it's close to useless.  Any ideas?
-
-Yes, you can pick up Andreas Klemm's apsfilter package from:
-
-ftp.germany.eu.net:pub/comp/i386/Linux/Local.EUnet/People/akl/apsfilter-1.11.gz
-
-This is a complete package for printing text, PS and DVI files.  It
-requires ghostscript and dvips.
-
-If you are looking for a simple printcap just for PS and text files,
-try picking up the printcap01 sources in:
-
-      /usr/src/contrib/FAQ/code/printcap01 
-
-NOTE: We're looking for printcap entries for all printers.  If you
-have one, or a filter for one, please send it or mail us a pointer to
-<FreeBSD-FAQ@FreeBSD.ORG>.  Thanks!
-
-7.3:	Help!  I've lost my root password!  How do I log in now?
-	Alternatively:  I botched something bad in my root partition
-	that keeps me from booting, how do I fix it!?
-
-Follow these steps:
-
-1. First off, you need to boot the system single-user:  Do this by rebooting
-or resetting the machine, and when you come to the very first boot prompt
-(the one you probably generally just hit `return' at or wait for it to
-time-out) type:
-
-		386bsd -s
-
-This will send the `-s' flag to init(1) telling it to not bring you up all
-the way into multi-user mode.  The system should come up single-user and
-present you with a simple `#' prompt.
-
-2. Now is probably a good time to type `fsck' and make sure your filesystems
-are alright.  If problems on your root filesystem are found and fixed, I would
-recommend hitting the reset switch again and going back to step 1.  Your
-filesystems should all check fine the second time.
-
-3. At this point, your root filesystem is mounted *read only* for safety.
-If the problems you must fix are not on the root fs then I recommend that
-you simply leave it this way and fix the other problems.  If you need to
-write to the root fs (fixing passwords requires this, for one thing) and
-you're using SCSI for your root fs then type:
-
-	mount -u /dev/sd0a /
-
-If you're using IDE/ESDI for your rootfs, then instead type:
-
-	mount -u /dev/wd0a /
-
-This will remount your root filesystem read/write and allow you to make
-your changes.  Once you have done so, I recommend another reboot.  -Jordan
-
-
-8 Networking
-------------
-
-8.1:  Where can I get information booting FreeBSD `diskless', that is
-      booting and running a FreeBSD box from a server rather than having
-      a local disk?
-
-Please read /sys/i386/netboot/netboot.doc.
-
-
-8.2:  I've heard that you can use a FreeBSD box as a dedicated network
-      router - is there any easy support for this?
-
-Internet standards and good engineering practice prohibit us from
-providing packet forwarding by default in FreeBSD.  You can enable
-this support by adding `options GATEWAY' to your kernel configuration
-file and recompiling.  In most cases, you will also need to run a
-routing process to tell other systems on your network about your
-router; FreeBSD comes with the standard BSD routing daemon routed(8),
-or for more complex situations you may want to try GateD (available by
-FTP from gated.Cornell.edu). FreeBSD is supported as of 3_5Alpha7.
-
-It is our duty to warn you that, even when FreeBSD is configured in
-this way, it does not completely comply with the Internet standard
-requirements for routers; however, it comes close enough for ordinary
-usage.
-
-There is a standard `router floppy' that you can boot on a FreeBSD
-machine to configure it as a network router.  Please look in:
-
-       freefall.cdrom.com:pub/incoming/freertr
-
-and follow the instructions.
-
-
-8.3:  Does FreeBSD support SLIP and PPP?
-
-Yes.  See the man pages for slattach(8) and/or pppd(8) if you're using
-FreeBSD to connect to another site.  If you're using FreeBSD as a
-server for other machines, look at the man page for sliplogin(8).
-You may also want to take a look at the slip FAQ in:
-             FAQ/FreeBSD.slip.dialup.faq
-
-8.4:  How do I set up NTP?
-
-NTP configuration is so complex and widely variable from site to site
-that it would be impossible to make a blanket statement here.  Your
-best bet is to ask whoever's in charge of NTP at your site or network
-provider; chances are that they are running a similar version of NTP
-to the one that we provide, and they can probably provide you with the
-right configuration files to get things going.
-
-If you can't find anyone in charge, you should examine the files in
-/usr/src/contrib/xntpd/doc and see if they help any.  If not, you
-could ask on the comp.protocols.time.ntp newsgroup, or the
-<ntp@ni.umd.edu> mailing-list.
-
-8.5:  How do I get my network set up?  I don't see how to make my
-      /dev/ed0 device!
-
-In the Berkeley networking framework, network interfaces are only
-directly accessible by kernel code.  Please see the /etc/netstart file
-and the manual pages for the various network programs mentioned there
-for more information.  If this leaves you totally confused, then you
-should pick up a book describing network administration on another
-BSD-related operating system; with few significant exceptions,
-administering networking on FreeBSD is basically the same as on SunOS
-4.0 or Ultrix.
-
-8.6:  How do I get my 3C503 to use the other network port?
-
-Use `ifconfig ed0' to see whether the ALTPHYS flag is set, and then
-use either `ifconfig ed0 altphys' if it was off, or `ifconfig ed0
--altphys' if it was on.
-
-8.7:  I'm having problems with NFS to/from FreeBSD and my Wuffotronics
-      Workstation / generic NFS appliance, where should I look first?
-
-Certain PC network cards are better than others (to put it mildly) and
-can sometimes cause problems with network intensive applications like
-NFS.  See /usr/src/share/FAQ/NFS.FAQ for more information on this
-topic.
-
-8.8:  I want to enable IP multicast support on my FreeBSD box, how do I do it?
-      [Alternatively:  What the heck IS multicasting and what applications
-      make use of it?]
-
-First off, to you'll need to rebuild a kernel with multicast support in it.
-This requires that you have the sources to at least the kernel and the config
-utility.  See /usr/src/sys/i386/conf/LINT for its comments on multicast; you'll
-need to set the MROUTING and MULTICAST options as shown there.
-
-Further reading/exploration for those interested in multicast:
-
-Product		Description		Where
---------------- ----------------------- ---------------------------------------
-faq.txt		Mbone FAQ		ftp.isi.edu:/mbone/faq.txt
-imm/immserv	IMage Multicast 	ftp.hawaii.edu:/paccom/imm.src.tar.Z
-		for jpg/gif images.
-nv		Network Video.		ftp.parc.xerox.com:
-					/pub/net-reseach/exp/nv3.3alpha.tar.Z
-vat		LBL Visual Audio Tool.	ftp.ee.lbl.gov:
-					/conferencing/vat/i386-vat.tar.Z
-wb		LBL White Board.	ftp.ee.lbl.gov:
-					/conferencing/wb/i386-wb.tar.Z
-mmcc		MultiMedia Conference	ftp.isi.edu:
-		Control program		/confctrl/mmcc/mmcc-intel.tar.Z
-rtpqual		Tools for testing the	ftp.psc.edu:/pub/net_tools/rtpqual.c
-		quality of RTP packets.
-vat_nv_record	Recording tools for vat	ftp.sics.se:archive/vat_nv_record.tar.Z
-		and nv.
-
-[Many thanks to Jim Lowe for providing multicast support for FreeBSD, and this
-information]
-
-
-9 Serial Communications
------------------------
-
-9.1:  When I do a set line in Kermit it locks up, what's the problem?
-
-The problem here is that FreeBSD thinks it's talking to a incoming
-modem connection, and is waiting for carrier to come up on it before
-completing the open.  To disable modem control, do an:
-
-        stty -f /dev/ttyXX clocal
-
-(Where `ttyXX' is the tty port you're using).  If you use a given port
-only for outgoing connections, you may wish to put this command in
-your /etc/rc.local to avoid having to do it every time you reboot your
-system.
-
-
-NOTE: Anyone wishing to submit a FAQ entry on how to get tip and cu working
-      would have it much appreciated!  We all use Kermit over here! :-)
-
------------------------------------------------------------------------------
-If you see a problem with this FAQ, or wish to submit an entry, please
-mail us at <FreeBSD-FAQ@FreeBSD.ORG>.  We appreciate your
-feedback, and cannot make this a better FAQ without your help!
-
-
-                                        FreeBSD Core Team
-
------------------------------------------------------------------------------
-
-ACKNOWLEDGMENTS:
-
-Gary Clark II           - Our head FreeBSD FAQ maintenance man
-Jordan Hubbard          - Janitorial services (I don't do windows)
-Garrett Wollman         - Networking and formatting
-Robert Oliver, Jr.      - Ideas and dumb questions (That made me think)
-Ollivier Robert         - Invaluable feedback and contributions
-The FreeBSD Team        - Kvetching, moaning, submitting data
-
-And to any others we've forgotten, apologies and heartfelt thanks!
-
diff --git a/share/FAQ/FreeBSD-1.X/FreeBSD-1.1.FAQ b/share/FAQ/FreeBSD-1.X/FreeBSD-1.1.FAQ
deleted file mode 100644
index bdaf736..0000000
--- a/share/FAQ/FreeBSD-1.X/FreeBSD-1.1.FAQ
+++ /dev/null
@@ -1,987 +0,0 @@
-
-                               FreeBSD
-                      Frequently Asked Questions
-                      For Versions 1.1 and below 
-
-Please mail all suggestions and additions to <FreeBSD-FAQ@FreeBSD.ORG>
-
-
-Revision: $Id: FreeBSD-1.1.FAQ,v 1.5 1994/11/23 10:21:59 gclarkii Exp $
-
-All entries are assumed to be relevant to both FreeBSD 1.1 and FreeBSD 1.1.5,
-unless otherwise noted.
-
-
-Table of Contents
------------------
-
-0 Preface
-1 Installation
-2 Hardware Compatibility
-3 Commercial applications
-4 User Applications
-5 Miscellaneous Questions
-6 Kernel Configuration 
-7 System Administration
-8 Networking
-9 Serial Communications
-
-
-
-0 Preface
----------
-
-Welcome to the FreeBSD 1.1 FAQ!  This document tries to answer some of
-the most frequently asked questions about FreeBSD 1.1 (or later,
-unless specifically indicated).  If there's something you're having
-trouble with and you just don't see it here, then please send mail to:
-
-        <questions@FreeBSD.ORG>
-
-
-Some of the instructions here will also refer to auxiliary utilities
-in the /usr/src/share/FAQ directory.  CDROM purchasers and net folks
-who've grabbed the FreeBSD current `srcdist' will have these files.  If
-you don't have the source distribution, then you can either grab the
-whole thing from:
-
-        ftp.FreeBSD.ORG:pub/FreeBSD/FreeBSD-current/src
-
-0.1:  What is FreeBSD?  
-
-FreeBSD is a UN*X type operating system based on William Jolitz's port
-of U.C. Berkeley's Networking Release 2 to the i386, 386BSD.  It is no
-longer correct to say that FreeBSD is only 386BSD with the patchkit
-applied!  There have been many additions and bug fixes made throughout
-the entire system, some of the highlights of which are:
-
-   More robust and extensive PC device support
-   System V-style IPC, messaging and semaphores
-   Shared Libraries
-   Much improved virtual memory code
-   Better console driver support
-   Network booting (diskless) support
-   /proc filesystem
-   Yellow Pages support
-   `LDT' support for WINE (primitive but developing Windows emulation)
-   Too many additional utilities and applications to mention
- 
-
-0.2:  My friends told me that FreeBSD was illegal and I shouldn't use it.
-      Is this really true?
-
-FreeBSD versions up to and including 1.1 have included code from
-Berkeley's Net/2 distribution.  UNIX Systems Laboratories (now Novell)
-sued Berkeley claiming that Net/2 included some code that belonged to
-USL.  In February of 1994, USL and Berkeley announced a settlement in
-which neither side admitted to doing anything wrong, but UCB agreed to
-stop distributing the disputed software.
-
-Since Berkeley will no longer defend this code, we have been requested
-to stop distributing it, and will be integrating all the improvements
-we have made in the VM system and i386-specific code into Berkeley's
-4.4-Lite distribution; the result will form the basis of FreeBSD 2.0.
-We expect the integration to take place over a period of three to six
-months, during which time we will have to stop work on 1.1 and
-concentrate all our efforts on the merge, and we expect to make more 
-information available on the status of the merge effort as the situation 
-progresses.
-
-However, to answer the question, "No.  FreeBSD is not illegal."  We
-have been allowed by USL to distribute 1.1 as the last Net/2 derived
-version, after which we have committed to move to 4.4 as previously 
-stated.
-
-We expect to make more information available on the status of the
-merge effort as the situation progresses.
-
-0.3:  What are the FreeBSD mailing lists, and how can I get on them? 
-
-The following mailing lists are provided for FreeBSD users and
-developers.  For more information, send to
-<majordomo@FreeBSD.ORG> and include a single line saying
-``help'' in the body of your message.
-
-announce:  	For announcements about or on FreeBSD.
-hackers:   	Useful for persons wishing to work on the internals. 
-questions: 	General questions on FreeBSD. 
-bugs:      	Where bugs should be sent.
-commit:    	This list carries the commit messages for freefall.  Useful
-                for tracking ongoing work.
-SCSI:      	Mailing list for SCSI developers. 
-current:   	This list is for persons wishing to run FreeBSD-current
-                and carries announcements and discussions on current.
-ports:          Discussion of "/usr/ports"
-hardware:       Types of hardware FreeBSD runs on
-security:       Security issues
-platforms:      Porting to non-Intel platforms
-
-Please see also the FreeBSD mailing list FAQ in:
-
-        /usr/src/share/FAQ/FreeBSD.mailing-list.FAQ
-
-0.4:  What are the various FreeBSD news groups? 
-
-While there are no groups currently dedicated to FreeBSD, you may find
-the following groups useful.
-
-comp.os.386bsd.announce:     For announcements
-comp.os.386bsd.apps:         For applications
-comp.os.386bsd.questions:    For questions
-comp.os.386bsd.development:  For working on the internals
-comp.os.386bsd.bugs:         About bugs
-comp.os.386bsd.misc:         For items that don't fit anywhere else
-
-NOTE: These groups cover all the *BSDs (FreeBSD, NetBSD, 386BSD).
-
-
-
-1 Installation
---------------
-
-1.1:  I just installed my system and rebooted.  Now I can't find the
-      extract or configure programs, where did they go?
-
-These two commands are just shell functions defined in /.profile.  To
-get these back, boot FreeBSD with a `-s' at the boot prompt.
-
-
-1.2:  I want to install FreeBSD onto a SCSI disk that has more than
-      1024 cylinders.  How do I do it?
-
-This depends.  If you don't have DOS (or another operating system) on
-the system, you can just keep the drive in native mode and simply make
-sure that your root partition is below 1024 so the BIOS can boot the
-kernel from it.  It you also have DOS/some other OS on the drive then
-your best bet is to find out what parameters that it thinks you have
-before installing FreeBSD.  When FreeBSD's installation procedure
-prompts you for these values, you should then enter them rather than
-simply going with the defaults.
-
-There is a freely available utility distributed with FreeBSD called
-`pfdisk' (located in the tools/ subdirectory) which can be used for
-this purpose.
-
-
-1.3:  When I boot FreeBSD it says ``Missing Operating System''.
-
-See question 1.2.  This is classically a case of FreeBSD and DOS or
-some other OS conflicting over their ideas of disk geometry.  You will
-have to reinstall FreeBSD, but obeying the instructions given above
-will almost always get you going.
-
-
-1.4:  I have an IDE drive with lots of bad blocks on it and FreeBSD doesn't
-      seem to install properly.
-
-FreeBSD's bad block (bad144) handling is still not 100% (to put it
-charitably) and it must unfortunately be said that if you've got an
-IDE or ESDI drive with lots of bad blocks, then FreeBSD is probably
-not for you!  That said, it does work on thousands of IDE based
-systems, so you'd do well to try it first before simply giving up.
-
-IDE drives are *supposed* to come with built-in bad-block remapping;
-if you have documentation for your drive, you may want to see if this
-feature has been disabled on your drive.  However, ESDI, RLL, and
-ST-506 drives normally do not do this.
-
-<1.1.5>
-FreeBSD-current has better bad block handling due to improvments made
-to the wd driver.
-
-1.5:  I have 32MB of memory, should I expect any special problems?
-
-If you have an IDE controller, no.  Likewise, if you have a full EISA
-system with EISA disk controller or a working local bus controller
-(read further) you'll have no problems. If you have an ISA system, or
-an EISA system with an ISA disk controller then you will most
-certainly have problems with the upper 16MB of memory due to the ISA
-24 bit DMA limitation (which ISA cards in EISA systems will also
-exhibit).  If you have a local bus disk controller, then you should be
-OK, UNLESS it's a Buslogic Bt445S with a revision less than `D' (BIOS
-3.36 or earlier).
-
-<1.1.5>
-1.1.5 has bounce-buffer support that make all of the above scenarios work
-with a full 32MB of memory or more.  You are therefore advised to simply pull
-16MB of memory out, install, and then see about upgrading to FreeBSD 1.1.5
-so that you can put it back.
-
-
-1.6:  Do I need to install the complete sources?
-
-In general, no.  However, we would strongly recommend that you
-install, at a minimum, the `base' source kit, which includes several
-of the files mentioned here, and the `sys' (kernel) source kit, which
-includes sources for the kernel.  There is nothing in the system which
-requires the presence of the sources to operate, however, except for
-the kernel-configuration program config(8).  With the exception of the
-kernel sources, our build structure is set up so that you can
-read-only mount the sources from elsewhere via NFS and still be able
-to make new binaries.  (Because of the kernel-source restriction, we
-recommend that you not mount this on /usr/src directly, but rather in
-some other location with appropriate symbolic links to duplicate the
-top-level structure of the source tree.)
-
-Having the sources on-line and knowing how to build a system with them
-will make it much easier for you to upgrade to future releases of
-FreeBSD.
-
-1.7:  DES encryption software can not be exported from the United
-      States.  If I live outside the US, how can I encrypt passwords?
-
-Since the DES encryption algorithm, which is used by passwd(1) and
-friends to encrypt passwords cannot legally be exported from the US,
-non-US users should not download this software from US FTP sites.
-
-There is however a replacement libcrypt available, based on sources
-written in Australia by David Burren.  This code is now available on
-some non-US FreeBSD mirror sites.  Sources for the unencumbered
-libcrypt, and binaries of the programs which use it, can be obtained
-from the following FTP sites:
-
-        South Africa:   braae.ru.ac.za:/pub/FreeBSD/securedist/
-                        owl.und.ac.za (currently uncertain)
-        Iceland:        ftp.veda.is:/pub/crypt/FreeBSD/
-
-The non-US securedist can be used as a direct replacement for the
-encumbered US securedist.  This securedist package is installed the
-same way as the US package (see installation notes for details).  If
-you are going to install DES encryption, you should do so as soon as
-possible, before installing other software.
-
-Non-US users should please not download any encryption software from
-the USA.  This can get the maintainers of the sites from which the
-software is downloaded into severe legal difficulties.
-
-A non-US distribution of Kerberos is also being developed, and current
-versions can generally be obtained by anonymous FTP from
-braae.ru.ac.za.
-
-There is also a mailing list for the discussion of non-US encryption
-software.  For more information, send an email message with a single
-line saying ``help'' in the body of your message to
-<majordomo@braae.ru.ac.za>.
-
-1.8     HELP!  My keyboard locked up during the install!
-
-Some keyboard controllers are not a friend to FreeBSD.  Among these are
-those on certain models of Gateway, IBM and AST machines.  The most frequent
-symptom encountered in such cases is that the keyboard refuses to respond
-to input when at the `kcopy>' prompt in the second phase of bootstrapping
-FreeBSD.  Fortunately, there is a work-around that may get you all the
-way home.  Reset the machine and boot the kcopy floppy again, but this
-time, as the kernel is booting, tap periodically on the num-lock key
-until the kcopy prompt appears.  Your keyboard should respond properly.
-
-Once your system is on the hard disk the problem generally goes away.
-Some folks for whom the problem persists even after this stage find
-relief in switching to the SYSCONS console driver (see /sys/i386/conf/SYSCONS),
-which is in any case far more featureful than pccons and a recommended
-upgrade.
-
-
-
-2 Hardware compatibility
-------------------------
-
-2.1:  What kind of hard drives does FreeBSD run on?
-
-FreeBSD supports ST-506 (sometimes called ``MFM''), RLL, and ESDI
-drives, which are usually connected to WD-1002, WD-1003, or WD-1006
-controllers (although clones should also work).  FreeBSD also supports
-IDE and SCSI hard drives.
-
-2.2:  What SCSI controllers are supported?
-
-FreeBSD supports the following SCSI controllers:
-
-Adaptec              AH-1542 Series <ISA>
-                     AH-1742 Series <EISA>
-Buslogic             BT-445 Series <VLB> (but see section 1.5)
-                     BT-545 Series <ISA>
-                     BT-742 Series <EISA>
-                     BT-747 Series <EISA>
-Future Domain        TMC-8XX/950 Series <ISA> (1.1.5 ONLY)
-Seagate              ST-01/02 Series <ISA> (1.1.5 ONLY)
-UltraStor            UH-14f Series <ISA>
-                     UH-34f Series <EISA/VLB>
-
-There is supposed to be a UltraStor 24f driver floating around, but
-we're not sure where (could someone please point us at it?).   
-
-2.3:  What CD-ROM drives are supported by FreeBSD?
-
-Any SCSI drive connected to a supported controller.  Mitsumi
-LU002(8bit), LU005(16bit) and FX001D(16bit 2x Speed).
-
-FreeBSD does NOT support drives connected to a Sound Blaster or
-non-SCSI SONY or Panasonic drives.  A general rule of thumb when
-selecting a CDROM drive for FreeBSD use is to buy a very standard SCSI
-model; they cost more, but deliver very solid performance in return.
-Do not be fooled by very cheap drives that, in turn, deliver VERY LOW
-performance!  As always, you get what you pay for.
-
-The Mitsumi driver is known to be extremely slow compared to SCSI
-drives.
-
-
-2.4:  What multi-port serial cards are supported by FreeBSD?
-
-AST/4 and BOCA 4/8/16 port cards.  Some unnamed clone cards have also
-been known to work, especially those that claim to be AST compatible.
-Check the sio(4) man page to get more information on configuring such
-cards.
-
-
-2.5:  Does FreeBSD support the AHA-2742 SCSI adapter from Adaptec?
-
-No, FreeBSD does not.  This is due to Adaptec's unwillingness to
-supply programming information under other than non-disclosure.  This
-is unfortunate, but there's nothing we can do about it.
-
- 
-2.6:  I have a Mumbleco bus mouse.  Is it supported and if so, how do I set
-      it up for XFree86?
-
-FreeBSD supports the Logitech and ATI Inport bus mice.  You need to
-add the following line to the kernel config file and recompile for the
-Logitech and ATI mice:
-
-        device        mse0    at isa? port 0x23c tty irq6 vector mseintr
-
-
-2.7:  I have a PS/2 mouse (`keyboard' mouse) [Alternatively:  I have a
-      laptop with a track-ball mouse].  How do I use it?
-
-<1.1.5>:  The PS/2 mouse is part of the system.  See the psm0 driver 
-description in /sys/doc/options.doc.
-
-
-2.8:  What types of tape drives are supported under FreeBSD?
-
-FreeBSD supports SCSI, QIC-02 and QIC-40/80 (Floppy based) tape
-drives.  This includes 8-mm (aka Exabyte) and DAT drives.
-
-
-2.9:  What sound cards are supported by FreeBSD?
-
-FreeBSD supports the SoundBlaster, SoundBlaster Pro, Pro Audio
-Spectrum 16, AdLib and Gravis UltraSound sound cards. There is also
-limited support for MPU-401 and compatible MIDI cards.  The
-SoundBlaster 16 and SoundBlaster 16 ASP cards are not yet supported.
-NOTE: This is only for sound!  This driver does not support CD-ROMs,
-SCSI or joysticks on these cards.
-
-
-2.10:   What network cards does FreeBSD support?
-
-There is support for the following cards:
-
-`ed' driver:
-        NE2000 and 1000
-        WD/SMC 8003, 8013 and Elite Ultra (8216)
-        3Com 3c503 
-        And clones of the above
-
-`ie' driver:
-        AT&T EN100/StarLAN 10
-
-`is' driver:
-        Isolan AT 4141-0
-        Isolink 4110
-
-`ep' driver:
-        3com 3c509 (*)
-
-
-(*)The `ep' driver is known to have some problems; see the
-/usr/src/KNOWNBUGS file for more details.
-
-
-2.11:  I have a 386/486sx/486SLC machine without a math co-processor.
-       Will this cause me any problems?
-
-Generally no, but there are circumstances where you will take a hit,
-either in performance or accuracy of the math emulation code (see
-section 4.1).  In particular, drawing arcs in X will be VERY slow.  It
-is highly recommended that you lay out the $50 or so for a math
-co-processor; it's well worth it.  NOTE: Some math co-processors are
-better than others.  It pains us to say it, but nobody ever got fired
-for buying Intel.  Unless you're sure it works with FreeBSD, beware of
-clones.
-
-2.12:  I am about to buy a new machine to run FreeBSD on and
-       want an idea of what other people are running.  Is there list
-       of other systems anywhere? 
-
-Yes.  Please look at the file FAQ/Systems-1.1.FAQ.  This file
-is a listing of hardware that people are running in their machines.
-Please note, this is a raw listing of equipment that other users
-have sent in.
-
-
-
-3 Commercial Applications
--------------------------
-
-Note: This section is still very sparse, though we're hoping, of
-course, that companies will add to it! :) The FreeBSD group has no
-financial interest in any of the companies listed here but simply
-lists them as a public service (and feels that commercial interest in
-FreeBSD can have very positive effects on FreeBSD's long-term
-viability).  We encourage commercial software vendors to send their
-entries here for inclusion.
-
-
-3.1:  Where can I get Motif for FreeBSD?
-
-Sequoia International provides commercial quality Motif 1.2.3
-development kits for FreeBSD 1.1 (with full shared library support)
-under the product name of `SWiM'.  Due to licensing restrictions from
-the OSF, and the fact that Sequoia needs to make a living, these are
-NOT FREE, but nonetheless quite reasonably priced in comparison to
-many other commercial Motif distributions.  Send electronic mail to
-<info@seq.com> for further information.
-
-3.2:  What about other commercial quality development systems for FreeBSD?
-
-ParcPlace Systems, Inc., who currently provides their excellent
-`Object Interface & Object Builder' GUI development environment free
-of charge to Linux users, is considering the the FreeBSD platform and
-will make their intentions known fairly shortly.
-
-
-
-4 User Applications
--------------------
-
-4.1:  I want to run X, how do I go about it?
-
-First, get the XFree86 distribution of X11R5 from XFree86.cdrom.com.
-The version you want for FreeBSD 1.1 and later is XFree86 2.1.  Follow
-the instructions for installation carefully. You may then wish to read
-the documentation for the ConfigXF86 tool, which assists you in
-configuring XFree86 for your particular graphics card/mouse/etc.
-
-
-4.1:  I've been trying to run ghostscript on a 386 (or 486sx) with no
-      math co-processor and I keep getting errors.  What's up?
-
-<1.1.5>:  For 1.1.5 you may add the following to your kernel config file and
-it  will be compiled in.
-options                         GPL_MATH_EMULATE
-
-NOTE:  You will need to remove the MATH_EMULATE option when you do this.
-
-
-4.2:  If I want something like seyon, term, Kermit, emacs or any one of
-      hundreds of popular freeware utilities, is there a good place to
-      search through first?
-
-Yes, the FreeBSD `ports collection' was put together for just that
-purpose.  It contains some of the most often requested languages,
-editors, mail and news reading programs, network software and many
-many megabytes of other types of useful goodies.  CDROM people will
-probably have the ports collection already in /usr/ports, other folks
-can get at the latest snapshot of the entire collection in:
-
-        ftp.FreeBSD.ORG:pub/FreeBSD/FreeBSD-current/ports
-
-Note that this FTP server permits getting entire directories as one
-(optionally gzipped or compressed) tar file.  Read the FTP welcome
-banner carefully for details.
-
-
-4.3:  I want all this neat software, but I haven't got the space or
-      CPU power to compile it all myself.  Is there any way of getting
-      binaries?
-
-Yes.  We support the concept of a `package', which is essentially a
-gzipped binary distribution with a little extra intelligence embedded
-in it for doing any custom installation work required.  Packages can
-also be installed or deinstalled again easily without having to know
-the gory details.  CDROM people will have a packages/ directory on
-their CD, others can get the currently available packages from:
-
-        ftp.FreeBSD.ORG:pub/FreeBSD/packages-1.1
-
-Note that all ports may not be available as packages, and that new
-packages are constantly being added.  It is always a good idea to
-check periodically to see which packages are available.  A README file
-in the packages directory provides more details on the care and
-feeding of the package software, so no explicit details will be given
-here.
-
-4.4:  I'm trying to get Perl to work properly, but I keep getting
-      errors about dbm failures when I test it.  How can I fix this?
-
-The problem here is that the tests are written for an older version of
-the dbm code.  There is nothing wrong with perl and the errors can
-be ignored.
-
-4.5:  I've been trying to get GCC 2.6.0 running on my system and it
-      keeps bombing.  What can I do about?
-
-Due to problems with 2.6.0 and the advent of FreeBSD 2.0, we do not
-support GCC 2.6.0 and suggest that you wait for 2.0.
-
-
-
-5 Miscellaneous Questions
-----------------
-
-5.1:  I've heard of something called FreeBSD-current.  How do I run it, and
-      where can I get more information?
-
-Read the file /usr/src/share/FAQ/FreeBSD.current.policy,
-it will tell you all you need to know.
-
-
-5.2:  What is this thing called `sup', and how do I use it?
-
-SUP stands for Software Update Protocol, and was developed by CMU for
-keeping their development trees in sync.  We use it to keep remote
-sites in sync with our central development sources.
-
-To use it, you need to have direct internet connectivity (not just
-mail or news).  First, pick up the sup_bin.tgz package from:
-
-        ftp.FreeBSD.ORG:pub/FreeBSD/packages-1.1
-
-Second, read the file /usr/src/share/FAQ/FreeBSD.sup.faq.
-
-This file describes how to setup sup on your machine.  You may also
-want to look at /usr/src/contrib/FAQ/FreeBSD.*.supfile,
-which are a set of supfiles for supping from FreeBSD.ORG
-
-
-5.3:  How do I create customized installation disks that I can give
-      out to other people at my site?
-
-The entire process of creating installation disks and source and
-binary archives is automated by various targets in
-/usr/src/etc/Makefile.  The information there should be enough to get
-you started.
-
-5.4:  How do I re-build my system without clobbering the existing
-      installed binaries?
-
-If you define the environment variable DESTDIR while running `make
-world' or `make install', the newly-created binaries will be deposited
-in a directory tree identical to the installed one, rooted at
-${DESTDIR}.  Some random combination of shared libraries modifications
-and program rebuilds can cause this to fail in `make world', however.
-
-
-5.5:  When my system booted, it told me that ``(bus speed defaulted)''.
-      What does that mean?
-
-The Adaptec 1542 SCSI host adapters allow the user to configure their
-bus access speed in software.  Previous versions of the 1542 driver tried
-to determine the fastest usable speed and set the adapter to that.  We
-found that this breaks some users' systems, so you now have to define
-the ``TUNE_1542''' kernel configuration option in order to have this
-take place.  Using it on those systems where it works may make your
-disks run faster, but on those systems where it doesn't, your data could
-be corrupted.
-
-5.6:  I would like to track changes to current and do not have net access.  
-      Is there any way besides downloading the whole tree?
-
-Yes, Poul-Henning has set up a source tracking list.  Please email 
-majordomo@ref.tfs.com with a body of "get ctm-src-cur README" for
-futher information.
-
-5.7:  How do I split up large binary files into smaller 240k files
-      like the distribution does?
-
-Newer BSD based systems have a "-b" option to split that allows them to
-split files on arbitary byte bondaries.
-
-Here is an example from /usr/src/Makefile.
-bin-tarball:
-	(cd ${DISTDIR}; \
-		tar cf - . \
-		gzip --no-name -9 -c | \
-		split -b 240640 - \
-		${RELEASEDIR}/tarballs/bindist/bin_tgz.)
-
-5.8:  I'm running Syscons and every morning my console locks up.  What
-      is going on here?
-
-This sounds like the "kill -1 syslogd" problem.  Make sure that the
-following is correct on your system.
-1. The attributes of the following nodes are correct.
-/dev/console
-crw-------	1 root		0,	0 May 23 15:32 /dev/console
-/dev/ttyv0
-crw-------	1 root		12,	0 May 23 15:32 /dev/ttyv0
-The part you are concerned with are the major and minor device numbers.
-
-2. Make sure that getty is running on ttyv0 and NOT console.
-
-3. If /dev/vga exists that it is a symlink to /dev/ttyv0.
-
-5.9:  I've had a couple of system panics and would like to be able
-      browse the system dumps.  The normal kernel is stripped and
-      I don't want to run a bloated kernel.  What can I do?
-
-Please retrieve the file FAQ/FreeBSD.kdebug.FAQ.  This
-file covers the instructions for looking at system dumps.
-
-5.10: I've got a Buslogic BT-946c with an Intel motherboard and
-      right after the kernel probes, my system hangs.  How do I
-      fix it?
-
-Two things here.
-1. Some intel motherboards have fixed PCI INT pins and you will have
-   to match the BT-946c's INT to match the motherboards.
-2. FreeBSD 1.1.5.1 expects the INT on a non-standard pin and you
-   will have to also match this one.
-
-
-6 Kernel Configuration
-----------------------
-
-6.1:  When I compile a kernel with multi-port serial code, it tells me
-      that only the first port is probed and the rest skipped due to
-      interrupt conflicts.  How do I fix this?
-
-The problem here is that FreeBSD has code built-in to keep the kernel
-from getting trashed due to hardware or software conflicts.  The way
-to fix this is to leave out the IRQ settings on other ports besides
-the first.  Here is a example:
-
-#
-# Multiport high-speed serial line - 16550 UARTS
-#
-device    sio2    at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr
-device    sio3    at isa? port 0x2a8 tty flags 0x501 vector siointr 
-device    sio4    at isa? port 0x2b0 tty flags 0x501 vector siointr
-device    sio5    at isa? port 0x2b8 tty flags 0x501 vector siointr
-
-
-6.2:  FreeBSD is supposed to come with support for QIC-40/80 drives but
-      when I look, I can't find it.
-
-You need to uncomment the following line in the generic config file
-(or add it to your config file) and recompile.
-
-controller      fdc0    at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
-disk            fd0     at fdc0 drive 0
-disk            fd1     at fdc0 drive 1
-#tape           ft0     at fdc0 drive 2
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You will have a device called /dev/ft0, which you can write to through
-a special program to manage it called `ft' - see the man page on ft for
-further details.  Versions previous to -current also had some trouble dealing
-wiht bad tape media; if you have trouble where ft seems to go back and forth
-over the same spot, try grabbing the latest version of ft from /usr/src/sbin/ft 
-in current and try that.
-
-
-6.3:  Does FreeBSD support IPC primitives like those in System V?
-
-Yes, FreeBSD supports System V-style IPC.  This includes shared
-memory, messages and semaphores.  You need to add the following lines
-to your kernel config to enable them.
-
-options         SYSVSHM
-options         "SHMMAXPGS=64"          # 256Kb of sharable memory
-options         SYSVSEM                 # enable for semaphores
-options         SYSVMSG                 # enable for messaging
-
-Recompile and install.
-
-
-6.4:  Are there any utilities that make configuring a kernel easier?
-
-Well, yes and no.  Look in /sys/i386/doc/options.doc (/sys/doc on post
-1.1 systems) for a list of kernel options you can set, and what they
-do.  For a friendlier front-end to the process, see
-/usr/src/contrib/configit
-
-
-6.5:  Will FreeBSD ever support other architectures?
-
-Several different groups have expressed interest in working on
-multi-architecture support for FreeBSD.  If you are interested in
-doing so, please contact the developers at
-<hackers@FreeBSD.ORG> for more information on our
-strategy for porting.
-
-
-6.6:  I just wrote a device driver for a Foobar Systems, Inc.
-      Integrated Adaptive Gronkulator card.  How do I get the
-      appropriate major numbers assigned?
-
-This depends on whether or not you plan on making the driver publicly
-available.  If you do, then please send us a copy of the driver source
-code, plus the appropriate modifications to files.i386, a sample
-configuration file entry, and the appropriate MAKEDEV code to create
-any special files your device uses.  If you do not, or are unable to
-because of licensing restrictions, then character major number 32 and
-block major number 8 have been reserved specifically for this purpose;
-please use them.  In any case, we'd appreciate hearing about your
-driver on <hackers@FreeBSD.ORG>.
-
-6.7:  I'm wanting to switch console drivers to Syscons.  I changed my
-      kernel config file to run Syscons, but when I reboot the system
-      locks up!  How do I fix it?
-
-There are four things that need to be done to properly install syscons
-on a system.
-1. Add the following line to your kernel config file while deleting the
-   line for pccons.
-device	sc0	at isa? port "IO_KBD" tty irq 1 vector scintr
-(Note the changed vector 'scintr'.  It is a common error to change the 
-device name but NOT the vector.
-
-2. Add the following option to your config file.
-options		"NCONS=6" # Change to reflect the number of consoles
-
-3. Modify /etc/ttys to enable gettys on ttyv0 - ttyv??.  Here is an
-example line.
-ttyv0	"/usr/libexec/getty Pc" Pc3	on	secure
-Please make sure that you have disabled the getty on /dev/console.
-
-4. Create the device nodes in /dev.  This is done useing the MAKEDEV
-script located in that directory.  Here is a command line that will create
-6 virtual consoles.
-MAKEDEV vty6
-If /dev/vga exists, it should now be a symlink to /dev/ttyv0.
-
-NOTE:  If you are going to be running X, you will need an unused vty that
-       has no getty running on it.
-
-
-
-7 System Administration
------------------------
-
-7.1:  How do I add a user easily?  I read the man page and am more confused
-      than ever!  [Alternatively:  I didn't read the man page, I never read
-      man pages! :-) ]
-
-Look at Gary Clark's Perl package ``AddIt'', which may be found in
-/usr/src/contrib/adduser.  This is a first attempt at solving the
-problem and may be replaced with a more complex but capable solution
-later.
-
-
-7.2: I'm trying to use my printer and keep running into problems.  I tried
-     looking at /etc/printcap, but it's close to useless.  Any ideas?
-
-Yes, you can pick up Andreas Klemm's apsfilter package from:
-
-ftp.germany.eu.net:pub/comp/i386/Linux/Local.EUnet/People/akl/apsfilter-1.11.gz
-
-This is a complete package for printing text, PS and DVI files.  It
-requires ghostscript and dvips.
-
-If you are looking for a simple printcap just for PS and text files,
-try picking up the printcap01 sources in:
-
-      /usr/src/contrib/FAQ/code/printcap01 
-
-NOTE: We're looking for printcap entries for all printers.  If you
-have one, or a filter for one, please send it or mail us a pointer to
-<FreeBSD-FAQ@FreeBSD.ORG>.  Thanks!
-
-7.3:	Help!  I've lost my root password!  How do I log in now?
-	Alternatively:  I botched something bad in my root partition
-	that keeps me from booting, how do I fix it!?
-
-Follow these steps:
-
-1. First off, you need to boot the system single-user:  Do this by rebooting
-or resetting the machine, and when you come to the very first boot prompt
-(the one you probably generally just hit `return' at or wait for it to
-time-out) type:
-
-		386bsd -s
-
-This will send the `-s' flag to init(1) telling it to not bring you up all
-the way into multi-user mode.  The system should come up single-user and
-present you with a simple `#' prompt.
-
-2. Now is probably a good time to type `fsck' and make sure your filesystems
-are alright.  If problems on your root filesystem are found and fixed, I would
-recommend hitting the reset switch again and going back to step 1.  Your
-filesystems should all check fine the second time.
-
-3. At this point, your root filesystem is mounted *read only* for safety.
-If the problems you must fix are not on the root fs then I recommend that
-you simply leave it this way and fix the other problems.  If you need to
-write to the root fs (fixing passwords requires this, for one thing) and
-you're using SCSI for your root fs then type:
-
-	mount -u /dev/sd0a /
-
-If you're using IDE/ESDI for your rootfs, then instead type:
-
-	mount -u /dev/wd0a /
-
-This will remount your root filesystem read/write and allow you to make
-your changes.  Once you have done so, I recommend another reboot.  -Jordan
-
-
-8 Networking
-------------
-
-8.1:  Where can I get information booting FreeBSD `diskless', that is
-      booting and running a FreeBSD box from a server rather than having
-      a local disk?
-
-Please read /sys/i386/netboot/netboot.doc.
-
-
-8.2:  I've heard that you can use a FreeBSD box as a dedicated network
-      router - is there any easy support for this?
-
-Internet standards and good engineering practice prohibit us from
-providing packet forwarding by default in FreeBSD.  You can enable
-this support by adding `options GATEWAY' to your kernel configuration
-file and recompiling.  In most cases, you will also need to run a
-routing process to tell other systems on your network about your
-router; FreeBSD comes with the standard BSD routing daemon routed(8),
-or for more complex situations you may want to try GateD (available by
-FTP from gated.Cornell.edu). FreeBSD is supported as of 3_5Alpha7.
-
-It is our duty to warn you that, even when FreeBSD is configured in
-this way, it does not completely comply with the Internet standard
-requirements for routers; however, it comes close enough for ordinary
-usage.
-
-There is a standard `router floppy' that you can boot on a FreeBSD
-machine to configure it as a network router.  Please look in:
-
-       freefall.cdrom.com:pub/incoming/freertr
-
-and follow the instructions.
-
-
-8.3:  Does FreeBSD support SLIP and PPP?
-
-Yes.  See the man pages for slattach(8) and/or pppd(8) if you're using
-FreeBSD to connect to another site.  If you're using FreeBSD as a
-server for other machines, look at the man page for sliplogin(8).
-You may also want to take a look at the slip FAQ in:
-             FAQ/FreeBSD.slip.dialup.faq
-
-8.4:  How do I set up NTP?
-
-NTP configuration is so complex and widely variable from site to site
-that it would be impossible to make a blanket statement here.  Your
-best bet is to ask whoever's in charge of NTP at your site or network
-provider; chances are that they are running a similar version of NTP
-to the one that we provide, and they can probably provide you with the
-right configuration files to get things going.
-
-If you can't find anyone in charge, you should examine the files in
-/usr/src/contrib/xntpd/doc and see if they help any.  If not, you
-could ask on the comp.protocols.time.ntp newsgroup, or the
-<ntp@ni.umd.edu> mailing-list.
-
-8.5:  How do I get my network set up?  I don't see how to make my
-      /dev/ed0 device!
-
-In the Berkeley networking framework, network interfaces are only
-directly accessible by kernel code.  Please see the /etc/netstart file
-and the manual pages for the various network programs mentioned there
-for more information.  If this leaves you totally confused, then you
-should pick up a book describing network administration on another
-BSD-related operating system; with few significant exceptions,
-administering networking on FreeBSD is basically the same as on SunOS
-4.0 or Ultrix.
-
-8.6:  How do I get my 3C503 to use the other network port?
-
-Use `ifconfig ed0' to see whether the ALTPHYS flag is set, and then
-use either `ifconfig ed0 altphys' if it was off, or `ifconfig ed0
--altphys' if it was on.
-
-8.7:  I'm having problems with NFS to/from FreeBSD and my Wuffotronics
-      Workstation / generic NFS appliance, where should I look first?
-
-Certain PC network cards are better than others (to put it mildly) and
-can sometimes cause problems with network intensive applications like
-NFS.  See /usr/src/share/FAQ/NFS.FAQ for more information on this
-topic.
-
-8.8:  I want to enable IP multicast support on my FreeBSD box, how do I do it?
-      [Alternatively:  What the heck IS multicasting and what applications
-      make use of it?]
-
-First off, to you'll need to rebuild a kernel with multicast support in it.
-This requires that you have the sources to at least the kernel and the config
-utility.  See /usr/src/sys/i386/conf/LINT for its comments on multicast; you'll
-need to set the MROUTING and MULTICAST options as shown there.
-
-Further reading/exploration for those interested in multicast:
-
-Product		Description		Where
---------------- ----------------------- ---------------------------------------
-faq.txt		Mbone FAQ		ftp.isi.edu:/mbone/faq.txt
-imm/immserv	IMage Multicast 	ftp.hawaii.edu:/paccom/imm.src.tar.Z
-		for jpg/gif images.
-nv		Network Video.		ftp.parc.xerox.com:
-					/pub/net-reseach/exp/nv3.3alpha.tar.Z
-vat		LBL Visual Audio Tool.	ftp.ee.lbl.gov:
-					/conferencing/vat/i386-vat.tar.Z
-wb		LBL White Board.	ftp.ee.lbl.gov:
-					/conferencing/wb/i386-wb.tar.Z
-mmcc		MultiMedia Conference	ftp.isi.edu:
-		Control program		/confctrl/mmcc/mmcc-intel.tar.Z
-rtpqual		Tools for testing the	ftp.psc.edu:/pub/net_tools/rtpqual.c
-		quality of RTP packets.
-vat_nv_record	Recording tools for vat	ftp.sics.se:archive/vat_nv_record.tar.Z
-		and nv.
-
-[Many thanks to Jim Lowe for providing multicast support for FreeBSD, and this
-information]
-
-
-9 Serial Communications
------------------------
-
-9.1:  When I do a set line in Kermit it locks up, what's the problem?
-
-The problem here is that FreeBSD thinks it's talking to a incoming
-modem connection, and is waiting for carrier to come up on it before
-completing the open.  To disable modem control, do an:
-
-        stty -f /dev/ttyXX clocal
-
-(Where `ttyXX' is the tty port you're using).  If you use a given port
-only for outgoing connections, you may wish to put this command in
-your /etc/rc.local to avoid having to do it every time you reboot your
-system.
-
-
-NOTE: Anyone wishing to submit a FAQ entry on how to get tip and cu working
-      would have it much appreciated!  We all use Kermit over here! :-)
-
------------------------------------------------------------------------------
-If you see a problem with this FAQ, or wish to submit an entry, please
-mail us at <FreeBSD-FAQ@FreeBSD.ORG>.  We appreciate your
-feedback, and cannot make this a better FAQ without your help!
-
-
-                                        FreeBSD Core Team
-
------------------------------------------------------------------------------
-
-ACKNOWLEDGMENTS:
-
-Gary Clark II           - Our head FreeBSD FAQ maintenance man
-Jordan Hubbard          - Janitorial services (I don't do windows)
-Garrett Wollman         - Networking and formatting
-Robert Oliver, Jr.      - Ideas and dumb questions (That made me think)
-Ollivier Robert         - Invaluable feedback and contributions
-The FreeBSD Team        - Kvetching, moaning, submitting data
-
-And to any others we've forgotten, apologies and heartfelt thanks!
-
diff --git a/share/FAQ/FreeBSD-1.X/Systems-1.1.FAQ b/share/FAQ/FreeBSD-1.X/Systems-1.1.FAQ
deleted file mode 100644
index 29b2c06..0000000
--- a/share/FAQ/FreeBSD-1.X/Systems-1.1.FAQ
+++ /dev/null
@@ -1,266 +0,0 @@
-                                  Systems FAQ
-                                  For FreeBSD
- Last Modified: $Id: Systems-1.1.FAQ,v 1.1 1994/09/16 18:24:40 gclarkii Exp $
-
-This FAQ is a list of systems that people have sent to the FAQ maintnance
-person for inclusion.  If you have a system you would like to be included
-please send it to FreeBSD-FAQ@freefall.cdrom.com.  
-
-Disclaimer:  This document is composed of systems that people have sent to
-the FAQ maintnance person.  It is the not to be taken as an endorsement
-for any system or manufacture.
-
-
-1.
-
-386DX/20 real AMI, ISA
-Oak SVGA (no X)
-8MB
-Adaptec 1542B, WD1007V ESDI
-Wren VI and Miniscribe 660MB 20Mbit/sec ESDI
-WD 8013EBT
-
-2.
-
-486DX/25 clone, AMI BIOS, ISA
-Orchid PCIII gas plasma (yes, VGA16)
-8MB
-Adaptec 1542B
-Micropolis 1684 SCSI 
-SMC 8013EEWC
-
-3.
-
- ??? OPTI chipset AMI BIOS 486/50 ISA
-ISA ET4000 w/ X11 (not so slow)
-16 Mb - 48 Mb swap
-ISA aha1542 B
-ISA no-name IDE w/ floppies
-FUJITSU M2623S-512 405MB  set to SCSI2
-SEAGATE ST3283N    237MB  SCSI2 
-SANYO   CRD-400I   SCSI2 cdromcdrom
-
-4.
-
-Lipizzan LDO-1 486DX-33 motherboard
-Orchid ProIIs (1M) video
-8 MB memory
-Generic 2S/1P/2FD/IDE controller:
-Maxtor 7213 AT
-WDC AC2420H
-PAS-16 + Sony CDU31A CD drive (Fusion 16 package).
-	*** The CD drive does not currently work with FreeBSD.
-
-5.
-
-Asus VL/ISA-486SV2 (ISA-VLB as you can see)
-Orchid Fahrenheit 1280+ VLB (yes)
-20MB
-Some no-name IDE VLB controller
-Conner CP30504 (I think....the 540MB IDE one)
-Zoltrix 14.4/14.4 Fax/Modem on tty01
-Intel 486DX2/66 CPU + fan
-Conner CP30104 (120MB....for DOS)
-
-6.
-
-AIR 486El (running with AMD486/40)
-ATI Graphics Ultra Pro running XFree862.1
-16M
-Adaptec 1742
-Micropolis 2217
-Wangtec 6130FS DAT drive (Some problems)
-
-7.
-
-Compudyne 486 DX2/66
-ATI Local Bus GUP w/ 2megs
-16 Megs Memory
-504 IDE Hard Drive
-Colorado 250 meg QIC-80 tape drive
-
-8.
-
-American Megatrends Enterprise III, 486DX2-66
-ATI VLB Mach 32 (with X)
-16 meg
-Adaptec 1742 EISA SCSI with floppy
-Toshiba 5030 SCSI-II
-Toshiba 5157 SCSI-II
-SMC Elite16T ISA Ethernet (ISA)
-
-9.
-
-American Megatrends Enterprise III, 486DX
-ATI VLB Mach 32 (with X)
-32 meg
-Adaptec 1742 EISA SCSI with floppy
-Maxtor P0-12S SCSI
-Digital DSP5200S SCSI-II
-Pro Audio Spectrum 16
-Wonder Board, 4 serial (16550), 3 parallel, each on a different interrupt
-
-10.
-
-NoName 486DX/33, Intel Chipset, EISA-Bus
-ATI Graphics Ultra Pro EISA,
-17"  Nanao (Eizo) F550-i Monitor
-Running the Mach32 X-Server XFree86-2.1.1 with fonts created from source.
-16 MB RAM (planning to add another 8 MB).
-AHA1742A
-Conner CP3100
-Fujitsu 520 MB
-Archive 525MB streamer tape.
-Gravis UltraSound - works for mod-files.
-
-11.
-
-ASUS SP3 PCI Board with i486 DX/2 66 MHz
-ISA ET4000 (I already tested a S3 805 PCI card successfully)
-Adaptec 1542B
-Toshiba XM3301TA CD-Rom
-CDC Harddisk, 572 MB (I don't know the exact specs)
-
-12.
-
-Mylex MAE486/33 EISA Motherboard
-16MB memory
-Actix GE32+ S3 801 gfx
-Adaptec 1742A controller
-Seagate ST3160 drive
-Seagate ST5120 drive
-Archive Viper 150MB tape
-Roland SCC-1 sound card
-Gravis Ultrasound card
-Longshine SMC/Novell compatable ethernet card
-
-13.
-
-Model:	DECpc LPv 466d2
-Config: Local (Motherboard) S3 801 gfx, IDE controller, PS/2 mouse, 12MB memory
-
-14.
-
-
-??? 486/DX266 EISA/VLB Motherboard
-16MB memory
-#9 GXE L12 VLB 3MB graphics card
-Bt445S VLB disk controller
-DEC DSP3105S drive
-MAXSTOR P-17S drive
-Tandberg 525MB tape drive
-Toshiba XM3301 CDROM
-Soundblaster 2.0
-Longshine SMC/Novell compatable ethernet card
-
-15.
-
-M407 PC chips with 33Mhz 486.
-Had to disable external cache due to DMA problems. Board uses write-through
-cache unless a second chip is added to allow write-back.write-back.
-Orchid ProDesigner II (yes)
-16Mb
-IDE
-Maxtor 7213 AT and Maxtor 7120 AT
-2 BICC Isolans (Lance based cards)
-
-16.
-
-Gigabyte EISA/VLB motherboard with SIS chipset, AMI bios, 32 MB ram
-Adaptec 1742 SCSI 2 controller with floppy controller enabled
-Spea/V7 Mirage - S3/805 based localbus graphics card with 1 MB d-ram
-no name wd8013 compatible ethernet card
-Gravis Ultrasound card with 1 MB ram
-2 Fujitsu 400 MB and 1 Seagate 500 MB SCSI 2 harddisks
-5 1/4 + 3 1/2 inch floppy drives
-Tandberg TDC3600 60 MB + Tandberg TDC3800 525 MB Streamer (these don't work
-quite properly yet)
-
-17.
-
-i486DX33, 16 Mb RAM, 256 Kb external cache, VLB board
-no-name IDE/floppy controller
-Western Digital Caviar 2340 (325 Mb)
-Kalok KL-343 (40 Mb)
-Chips & Technologies 451 SuperVGA card (800x600, 16 colours, 256Kb)
-
-18.
-
-no name EISA i486DX/33 board, 16 MB RAM
-Adaptec AHA-1540*A*  (not knowing if the current -current might cause
-  problems, my kernel is from end of march)
-Maxtor MXT-1240S, 1.2Gig very fast SCSI disk
-Seagate ST-1144A, just to boot off the beast (also has a messdos partition yet)
-Archive Viper 150 tape; has a firmware braindeadness when appending files,
-  works very well otherwise
-ELSA Winner 1000 ISA/EISA, 1MB VRAM, S3 86C928 (unfortunately, D-step chip)
-Nokia 447-B 17in monitor, running ~ 1100x800 resolution, very nice
-true `Mouse Systems' optical mouse, fine thing!
-sometimes a Toshiba XM-3301 CDROM, rather old, but solid & reliable
-
-19.
-
-older south-east Asia made notebook, i386SX/16, 5 MB RAM (where the 384 k hole
-  can be re-mapped, so all the 5 MB are useable)
-Seagate ST-9145AG, 120 MB 2.5in IDE disk, very low power consumption, but
-  rather slow transfer rate, only about 350 K/s, so paging is a mess
-640x480 LCD, ~ 16 gray tones distinguishable, Cirrus Logic CL-GD610/620
-  chipset; runs generic VGA-Mono and VGA-16 XFree86[tm] servers; needs
-  some hacks in rc.local to give full contrast when running with the
-  pcvt display driver (due to their different default attribute handling)
-
-
-20.
-
-Data General Dasher 386sx/16, 8 MB RAM
-Adaptec AHA-1542B
-Seagate ST-3655N, 525 MB SCSI disk
-Conner CP-3044, 40 MB IDE disk
-has been working with a Western Digital WD-1007V ESDI controller (on
-  secondary wdc address), and a Micropolis 1664-7 330 MB ESDI disk -
-  but this beast was terribly slow, loud (& unreliable) and therefore
-  had to go
-ET-3000 based 512 K VGA, slow (wrt. XFree86), but reliable
-3Com 3C503 Ethernet adaptor, suffers from the `do not nfs mount with
-  too large packets' problem, but works well otherwise
-`Mouse Systems' optical mouse
-Toshiba XM-3301 CDROM
-already ran with a Micropolis 1664-3 330 MB SCSI disk (same drive as
-  above, but different interface)
-already ran with an IBM 2Gig SCSI disk (don't remember the type)
-
-
-21.
-
-Mylex MNA 486/33 EISA Motherboard
-16Mb of Memory
-1.2 GB Toshiba 538 SCSI disk
-400Mb IBM SCSI disk
-150/250Mb Tandberg SCSI tape drive
-Toshiba 3401 SCSI CD-ROM
-Tseng 4000 Video Controller
-Logitech Bus Mouse
-Mediavision Pro Audio Stereo Sound Card
-Adaptech 1742A SCSI controller
-WD8013EBT Ethernet Card
-
-22.
-
-386DX-40 w/Cyrix math co-processor
-ET-4000 running X
-16MB
-IDE
-540MB Western Digital
-WD8003EP
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/share/FAQ/FreeBSD.FAQ b/share/FAQ/FreeBSD.FAQ
deleted file mode 100644
index d5804b0..0000000
--- a/share/FAQ/FreeBSD.FAQ
+++ /dev/null
@@ -1,1304 +0,0 @@
-
-                               FreeBSD
-                      Frequently Asked Questions
-                           For Version 2.0 
-
-Please mail all suggestions and additions to <FAQ@FreeBSD.ORG>
-
-
-Revision: $Id: FreeBSD.FAQ,v 1.23 1995/03/11 16:48:17 roberto Exp $
-
-All entries are assumed to be relevant to FreeBSD 2.0. 
-Any entries with a <XXX> are under construction.
-
-
-Table of Contents
------------------
-
-0 Preface
-1 Installation
-2 Hardware Compatibility
-3 Commercial applications
-4 User Applications
-5 Miscellaneous Questions
-6 Kernel Configuration 
-7 System Administration
-8 Networking
-9 Serial Communications
-
-
-
-0 Preface
----------
-
-Welcome to the FreeBSD 2.0 FAQ!  This document tries to answer some of
-the most frequently asked questions about FreeBSD 2.0.  
-If there's something you're having trouble with and you do not see it
-here, please send email to:
-
-    	            <questions@FreeBSD.ORG>
-
-
-Some of the instructions here will also refer to auxiliary utilities
-in the /usr/src/share/FAQ directory.  CDROM purchasers and net folks
-who've grabbed the FreeBSD 2.0 `srcdist' will have these files.  If
-you don't have the source distribution, then you can either grab the
-whole thing from:
-
-               ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current
-
-Or you can grab only those files you're interested in straight out of
-the FreeBSD-current distribution in:
-
-              ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src
-
-0.1:  What is FreeBSD?  
-
-FreeBSD 2.0 is a UN*X type operating system based on U.C. Berkeley's 
-4.4BSD-lite release for the i386 platform.  It is also based indirectly
-on William Jolitz's port of U.C. Berkeley's Net/2 to the i386, 386BSD.
-There have been many additions and bug fixes made throughout
-the entire system, some of the highlights of which are:
-
-   More robust and extensive PC device support
-   System V-style IPC, messaging and semaphores
-   Shared Libraries
-   Much improved virtual memory code
-   Better console driver support
-   Network booting (diskless) support
-   Yellow Pages support
-   Full support of the PCI bus
-   Loadable kernel modules
-   Too many additional utilities and applications to mention
-
-<2.X-Current>
-   Serial Console Support
-   Merged VM/Buffer Cache
-   On demand PPP
-   Sync PPP
-   Improved SCSI support
-
-
-0.2:  What are the FreeBSD mailing lists, and how can I get on them? 
-
-The following mailing lists are provided for FreeBSD users and
-developers.  For more information, send to
-<majordomo@FreeBSD.ORG> and include a single line saying
-``help'' in the body of your message.
-
-announce:  For announcements about or on FreeBSD.
-hackers:   Useful for persons wishing to work on the internals. 
-questions: General questions on FreeBSD. 
-bugs:      Where bugs should be sent.
-SCSI:      Mailing list for SCSI developers. 
-current:   This list is for persons wishing to run FreeBSD-current
-           and carries announcements and discussions on current.
-security:  For issues dealing with system security. 
-platforms: Deals with ports to non-Intel platforms
-ports:     Discussion of /usr/ports/???
-fs:        Discussion of FreeBSD Filesystems
-hardware:  Discussion on hardware requirements for FreeBSD.
-
-The FreeBSD-commit list has been broken up into groups dealing with different
-areas of interest.  Please see the FreeBSD mailing list FAQ in:
-
-        /usr/src/share/FAQ/mailing-list.FAQ
-
-
-0.3:  What are the various FreeBSD news groups? 
-
-While there are no groups currently dedicated to FreeBSD, you may find
-the following groups useful.
-
-comp.os.386bsd.announce:     For announcements
-comp.os.386bsd.apps:         For applications
-comp.os.386bsd.questions:    For questions
-comp.os.386bsd.development:  For working on the internals
-comp.os.386bsd.bugs:         About bugs
-comp.os.386bsd.misc:         For items that don't fit anywhere else
-
-NOTE: These groups cover all the *BSDs (FreeBSD, NetBSD, 386BSD).
-
-comp.os.bsd:                 General BSD topics, maybe of intrest
-
-NOTE: As of the date of this writing, there is has been a break up of 
-newsgroups into groups for each OS.  These groups can be found under
-``comp.unix.bsd''.
-
-
-1 Installation
---------------
-
-1.1:  I want to install FreeBSD onto a SCSI disk that has more than
-      1024 cylinders.  How do I do it?
-
-This depends.  If you don't have DOS (or another operating system) on
-the system, you can just keep the drive in native mode and simply make
-sure that your root partition is below 1024 so the BIOS can boot the
-kernel from it.  It you also have DOS/some other OS on the drive then
-your best bet is to find out what parameters that it thinks you have
-before installing FreeBSD.  When FreeBSD's installation procedure
-prompts you for these values, you should then enter them rather than
-simply going with the defaults.
-
-There is a freely available utility distributed with FreeBSD called
-`pfdisk' (located in the tools/dos-tools subdirectory) which can be used for
-this purpose.
-
-
-1.2:  When I boot FreeBSD it says ``Missing Operating System''.
-
-See question 1.2.  This is classically a case of FreeBSD and DOS or
-some other OS conflicting over their ideas of disk geometry.  You will
-have to reinstall FreeBSD, but obeying the instructions given above
-will almost always get you going.
-
-1.3:  When I install the boot manager and try to boot FreeBSD for the
-      first time, it just comes back with the boot manager prompt again.
-
-This is another symptom of the problem described in 1.2.  Your
-BIOS geometry and FreeBSD geometry settings do not agree!  If your
-controller or BIOS supports cylinder translation (often marked
-as ">1GB drive support"), try toggling its setting and reinstalling
-FreeBSD.
-
-1.4:  I have an IDE drive with lots of bad blocks on it and FreeBSD doesn't
-      seem to install properly.
-
-FreeBSD's bad block (bad144) handling is still not 100% (to put it
-charitably) and it must unfortunately be said that if you've got an
-IDE or ESDI drive with lots of bad blocks, then FreeBSD is probably
-not for you!  That said, it does work on thousands of IDE based
-systems, so you'd do well to try it first before simply giving up.
-
-IDE drives are *supposed* to come with built-in bad-block remapping;
-if you have documentation for your drive, you may want to see if this
-feature has been disabled on your drive.  However, ESDI, RLL, and
-ST-506 drives normally do not do this.
-
-1.5:  I have 32MB of memory, should I expect any special problems?
-
-No.  FreeBSD 2.0 comes with bounce buffers which allows your bus
-mastering controller access to greater than 16MB.
-
-1.6:  Do I need to install the complete sources?
-
-In general, no.  However, we would strongly recommend that you
-install, at a minimum, the `base' source kit, which includes several
-of the files mentioned here, and the `sys' (kernel) source kit, which
-includes sources for the kernel.  There is nothing in the system which
-requires the presence of the sources to operate, however, except for
-the kernel-configuration program config(8).  With the exception of the
-kernel sources, our build structure is set up so that you can
-read-only mount the sources from elsewhere via NFS and still be able
-to make new binaries.  (Because of the kernel-source restriction, we
-recommend that you not mount this on /usr/src directly, but rather in
-some other location with appropriate symbolic links to duplicate the
-top-level structure of the source tree.)
-
-Having the sources on-line and knowing how to build a system with them
-will make it much easier for you to upgrade to future releases of
-FreeBSD.
-
-1.7:  DES encryption software can not be exported from the United
-      States.  If I live outside the US, how can I encrypt passwords?
-
-If it is not absolutely imperative that you use DES style encryption,
-you can use FreeBSD's default encryption for even _better_ security,
-and with no export restrictions.  FreeBSD 2.0's password default
-scrambler is now MD5 based, and is more CPU-intensive to crack
-with an automated password cracker than DES.
-
-Since the DES encryption algorithm cannot legally be exported from the US,
-non-US users should not download this software (as part of the secrdist)
-from US FTP sites.
-
-There is however a replacement libcrypt available, based on sources
-written in Australia by David Burren.  This code is now available on
-some non-US FreeBSD mirror sites.  Sources for the unencumbered
-libcrypt, and binaries of the programs which use it, can be obtained
-from the following FTP sites:
-
-        South Africa:   braae.ru.ac.za:/pub/FreeBSD/securedist/
-                        owl.und.ac.za (currently uncertain)
-        Iceland:        ftp.veda.is:/pub/crypt/FreeBSD/
-
-The non-US securedist can be used as a direct replacement for the
-encumbered US securedist.  This securedist package is installed the
-same way as the US package (see installation notes for details).  If
-you are going to install DES encryption, you should do so as soon as
-possible, before installing other software.
-
-Non-US users should please not download any encryption software from
-the USA.  This can get the maintainers of the sites from which the
-software is downloaded into severe legal difficulties.
-
-A non-US distribution of Kerberos is also being developed, and current
-versions can generally be obtained by anonymous FTP from
-braae.ru.ac.za.
-
-There is a mailing list for the discussion of non-US encryption
-software.  For more information, send an email message with a single
-line saying ``help'' in the body of your message to
-<majordomo@braae.ru.ac.za>.
-
-
-
-2 Hardware compatibility
-------------------------
-
-2.1:  What kind of hard drives does FreeBSD run on?
-
-FreeBSD supports ST-506 (sometimes called ``MFM''), RLL, and ESDI
-drives, which are usually connected to WD-1002, WD-1003, or WD-1006
-controllers (although clones should also work).
-
-FreeBSD also supports IDE and SCSI hard drives.
-
-2.2:  What SCSI controllers are supported?
-
-FreeBSD supports the following SCSI controllers:
-
-Adaptec              AH-154x Series <ISA>
-                     AH-174x Series <EISA>
-                     AH-152x Series <ISA>
-		     Sound Blaster SCSI (AH-152x compat) <ISA>
-                     AH-2742/2842 Series <ISA/EISA>
-		     AH-2820/2822/2825 Series <VLB>
-Buslogic             BT-445 Series <VLB> (but see section 1.5)
-		     BT-545 Series <ISA>
-                     BT-742 Series <EISA>
-                     BT-747 Series <EISA>
-                     BT-964 Series <PCI>
-Future Domain        TMC-950 Series <ISA> 
-PCI Generic          NCR 53C810 based controllers <PCI> 
-ProAudioSpectrum     Zilog 5380 based controllers <ISA>
-Seagate              ST-01/02 Series <ISA>
-UltraStor            UH-14f Series <ISA>
-                     UH-34f Series <EISA/VLB>
-
-<2.X-Current Only>
-Western Digital	     WD7000 <ISA> <No scatter/gather>
-Adaptec		     AH-294x and aic7870 MB controllers <PCI>
-ProAudioSpectrum     Trantor 130 based controllers <ISA>
-
-2.3:  What CD-ROM drives are supported by FreeBSD?
-
-Any SCSI drive connected to a supported controller.
-Mitsumi LU002(8bit), LU005(16bit) and FX001D(16bit 2x Speed).
-
-<2.X-Current>
-Sound Blaster Non-SCSI CD-ROM
-
-FreeBSD does not support any of the ``IDE'' CD-ROM interfaces.
-All non-SCSI cards are known to be extremely slow compared to SCSI
-drives.
-
-2.4:  What multi-port serial cards are supported by FreeBSD?
-
-AST/4
-BOCA 4/8/16 port cards.  
-
-<2.X-Current>
-Cyclades 8/16 port <Alpha>
-
-Some unnamed clone cards have also been known to work,, especially those
-that claim to be AST compatible.
-Check the sio(4) man page to get more information on configuring such
-cards.
-
-
-2.5:  Does FreeBSD support the AHA-2742/2842 SCSI adapters from Adaptec?
-
-Yes, though portions of the sources are currently GPL'd (that is to say,
-distributed under the GNU Public License), so be aware of the fact should
-you wish to distribute kernel binaries compiled with it - you MUST also
-provide the sources to the driver with the kernel image to stay legal
-with the GPL!  This is easily enough done by simply including the contents
-of /usr/src/sys/gnu/{aic7770,misc} on whatever media you distribute the
-kernel.
-
-We are working to get the GPL restriction removed, but for now you should
-at least be aware of it.
-
- 
-2.6:  I have a Mumbleco bus mouse.  Is it supported and if so, how do I set
-      it up for XFree86?
-
-FreeBSD supports the Logitech and ATI Inport bus mice.  You need to
-add the following line to the kernel config file and recompile for the
-Logitech and ATI mice:
-
-        device        mse0    at isa? port 0x23c tty irq6 vector mseintr
-
-
-2.7:  I have a PS/2 mouse (`keyboard' mouse) [Alternatively:  I have a
-      laptop with a track-ball mouse].  How do I use it?
-
-
-
-2.8:  What types of tape drives are supported under FreeBSD?
-
-FreeBSD supports SCSI, QIC-02 and QIC-40/80 (Floppy based) tape
-drives.  This includes 8-mm (aka Exabyte) and DAT drives.
-
-
-2.9:  What sound cards are supported by FreeBSD?
-
-FreeBSD supports the SoundBlaster, SoundBlaster Pro, Pro Audio
-Spectrum 16, AdLib and Gravis UltraSound sound cards. There is also
-limited support for MPU-401 and compatible MIDI cards.  The
-SoundBlaster 16 and SoundBlaster 16 ASP cards are not yet supported.
-NOTE: This is only for sound!  This driver does not support CD-ROMs,
-SCSI or joysticks on these cards.
-
-
-2.10:   What network cards does FreeBSD support?
-
-There is support for the following cards:
-
-`ed' driver:
-        NE2000 and 1000
-        WD/SMC 8003, 8013 and Elite Ultra (8216)
-        3Com 3c503 
-        And clones of the above
-
-`de' driver:
-	DEC and compatible PCI controllers.
-
-`le' driver:
-	DEC LANCE ethernet based controllers.
-
-`ie' driver:
-        AT&T EN100/StarLAN 10
-        3Com 3c507 
-
-`is' driver:
-        Isolan AT 4141-0
-        Isolink 4110
-
-`ep' driver:
-        3com 3c509 (*)
-
-`el' driver:
-	3com 3c501 (*)
-
-`ze' driver:
-        IBM PCMCIA credit card adapter
-
-`lnc' driver:
-	Unknown Lance based (*)
-
-<2.X-Current>
-
-`cx' driver
-	Cronyx/Sigma multiport Sync/Async (Cisco and PPP framing)
-
-`zp' driver
-	3Com PCMCIA Etherlink III
-
-Note:	Drivers marked with (*) are known to have problems.
-
-Note:	We also support TCP/IP over parallel lines.  At this point we are
-	incompatiable with other versions, but we hope to correct this in
-	the near future.
-
-2.11:  I have a 386/486sx/486SLC machine without a math co-processor.
-       Will this cause me any problems?
-
-Generally no, but there are circumstances where you will take a hit,
-either in performance or accuracy of the math emulation code (see
-section 4.1).  In particular, drawing arcs in X will be VERY slow.  It
-is highly recommended that you lay out the $50 or so for a math
-co-processor; it's well worth it.  NOTE: Some math co-processors are
-better than others.  It pains us to say it, but nobody ever got fired
-for buying Intel.  Unless you're sure it works with FreeBSD, beware of
-clones.
-
-2.12:  What other devices does 2.X support?
-
-Here is a listing of drivers that do not fit into any of the above areas.
-
-b004.c		Driver for B004 compatiable Transputer boards
-ctx.c		Driver for CORTEX-I Frame grabber
-gpib.c		Driver for National Instruments AT-GPIB and AT-GPIB/TNT boards
-pcaudio.c	Driver for PC speakers to allow the playing of audio files
-tw.c		Driver for the X-10 POWERHOUSE 
-
-<2.X-Current>
-spigot.c	Driver for the Creative Labs Video Spigot
-gsc.c		Driver for the Genuis GS-4500 Hand scanner
-joy.c		Driver for a joystick
-
-2.13:  I am about to buy a new machine to run FreeBSD on and
-       want an idea of what other people are running.  Is there list
-       of other systems anywhere? 
-
-Yes.  Please look at the file Systems.FAQ.  This file
-is a listing of hardware that people are running in their machines.
-Please note, this is a raw listing of equipment that other users
-have sent in, and does not constitute any kind of endorsement by the
-FreeBSD Project.
-
-2.14:	I have a lap-top with power management.  Can FreeBSD take advantage
-	of this?
-
-Yes it can on certain machines.  Please look in the LINT kernel config 
-file under APM.
-
-
-
-3 Commercial Applications
--------------------------
-
-Note: This section is still very sparse, though we're hoping, of
-course, that companies will add to it! :) The FreeBSD group has no
-financial interest in any of the companies listed here but simply
-lists them as a public service (and feels that commercial interest in
-FreeBSD can have very positive effects on FreeBSD's long-term
-viability).  We encourage commercial software vendors to send their
-entries here for inclusion.
-
-
-3.1:  Where can I get Motif for FreeBSD?
-
-You can purchase Motif 1.2.3 for FreeBSD (SWiM) from the ACC Bookstore, 
-P.O. Box 3364, Westport CT. 06880.  1-800-546-7274 or FAX: 1-203-454-2582
-
-This software works flawlessly for for FreeBSD 1.1.5 but has shown
-one problem with 2.0 in that the "uil" program core dumps.  This is
-apparently because of the way uil is installed, and it's quite possible
-that ACC will have a fixed version by the time you read this.  No
-other compatibility problems with the programs or libraries have been
-found, and ACC can hardly be blamed for failing to work perfectly with
-a brand-new release they haven't even seen yet! :)
-
-
-3.2:  Are there any commercial X servers for some of the high-end
-      graphics cards like the Matrox or #9 I-128, or offering 8/16/24
-      bit deep pallettes?
-
-Yes, X Inside Incorporated sells their Accelerated-X product for
-FreeBSD and other Intel based systems.
-
-This high performance X Server offers easy configuration, support
-for multiple concurrent video boards and is distributed in binary
-form only.
-
-Price is $99.50 (promotional price for Linux/FreeBSD version) for
-the 1.1 version, which is available now.
-
-This product is for FreeBSD 1.1 and runs under 2.0 with the FreeBSD 1.1
-compatibility libs (`compat1xdist').
-
-More info: URL http://www.xinside.com/
-	or URL ftp://ftp.xinside.com/accelx/1.1/prodinfo.txt
-	or email info@xinside.com
-	or phone +1(303)384-9999
-
-
-3.3:  Any other applications I might be interested in?
-
-RenderMorphics, Ltd. sells a high-speed 3D rendering package for
-FreeBSD called "Reality Lab" (tm).  Send email to info@render.com
-or call: +44(0)71-251-4411 / FAX: +44(0)71-251-0939
-
-This package is also for FreeBSD 1.1.5 but has been tested and shown
-to run under FreeBSD 2.0 with the compat1xdist installed.
-
-Thanks must be extended to all of these companies for showing enough faith
-in FreeBSD to port their products to it.  While we get no direct benefit
-from the sales of these products, the indirect benefits of FreeBSD
-proving itself to be a successful platform for such commercial interests
-will be immense!  We wish these companies every measure of success, and
-can only hope that others are encouraged to follow suit.
-
-
-4 User Applications
--------------------
-
-4.1:  I want to run X, how do I go about it?
-
-First, get the XFree86 distribution of X11R6 from XFree86.cdrom.com.
-The version you want for FreeBSD 2.X and later is XFree86 3.1.1.  Follow
-the instructions for installation carefully. You may then wish to read
-the documentation for the ConfigXF86 tool, which assists you in
-configuring XFree86 for your particular graphics card/mouse/etc.
-
-You may also wish to investigate the Xaccel server, which is available
-at a very reasonable price.  See section 3.2 for more details.
-
-4.2:  I've been trying to run ghostscript on a 386 (or 486sx) with no
-      math co-processor and I keep getting errors.  What's up?
-
-You will need to add the alternate math emulator to your kernel, you do this
-by adding  the following to your kernel config file and it will be compiled in.
-
-options                         GPL_MATH_EMULATE
-
-NOTE:  You will need to remove the MATH_EMULATE option when you do this.
-
-
-4.2:  I want all this neat software, but I haven't got the space or
-      CPU power to compile it all myself.  Is there any way of getting
-      binaries?
-
-Yes.  We support the concept of a `package', which is essentially a
-gzipped binary distribution with a little extra intelligence embedded
-in it for doing any custom installation work required.  Packages can
-also be installed or deinstalled again easily without having to know
-the gory details.  CDROM people will have a packages/ directory on
-their CD, others can get the currently available packages from:
-
-                ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages
-
-Note that all ports may not be available as packages, and that new
-packages are constantly being added.  It is always a good idea to
-check periodically to see which packages are available.  A README file
-in the packages directory provides more details on the care and
-feeding of the package software, so no explicit details will be given
-here.
-
-
-
-
-5 Miscellaneous Questions
-----------------
-
-5.1:  I've heard of something called FreeBSD-current.  How do I run it, and
-      where can I get more information?
-
-Read the file /usr/src/share/FAQ/current-policy.FAQ,
-it will tell you all you need to know.
-
-
-5.2:  What is this thing called `sup', and how do I use it?
-
-SUP stands for Software Update Protocol, and was developed by CMU for
-keeping their development trees in sync.  We use it to keep remote
-sites in sync with our central development sources.
-
-Unless you have direct internet connectivity, and don't care too much
-about the cost/duration of the sessions, you shouldn't use sup.  For
-those "low/expensive-bandwidth" applications, we have developed CTM,
-see 5.6 for more about that.
-
-To use it, you need to have direct internet connectivity (not just
-mail or news).  First, pick up the sup.tgz package from:
-
-        ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages/sup.tgz
-
-Second, read the file /usr/src/share/FAQ/sup.FAQ.
-
-This file describes how to setup sup on your machine.  You may also
-want to look at /usr/src/share/FAQ/extras/*.supfile, or you may grab updated
-supfiles from:
-
-	ftp://ftp.FreeBSD.ORG//pub/FreeBSD/FAQ/extras
-
-which are a set of supfiles for supping from FreeBSD.ORG. 
-
-
-5.3:  How do I create customized installation disks that I can give
-      out to other people at my site?
-
-The entire process of creating installation disks and source and
-binary archives is automated by various targets in
-/usr/src/etc/Makefile.  The information there should be enough to get
-you started.
-
-5.4:  How do I re-build my system without clobbering the existing
-      installed binaries?
-
-If you define the environment variable DESTDIR while running `make
-world' or `make install', the newly-created binaries will be deposited
-in a directory tree identical to the installed one, rooted at
-${DESTDIR}.  Some random combination of shared libraries modifications
-and program rebuilds can cause this to fail in `make world', however.
-
-
-5.5:  When my system booted, it told me that ``(bus speed defaulted)''.
-      What does that mean?
-
-The Adaptec 1542 SCSI host adapters allow the user to configure their
-bus access speed in software.  Previous versions of the 1542 driver tried
-to determine the fastest usable speed and set the adapter to that.  We
-found that this breaks some users' systems, so you now have to define
-the ``TUNE_1542''' kernel configuration option in order to have this
-take place.  Using it on those systems where it works may make your
-disks run faster, but on those systems where it doesn't, your data could
-be corrupted.
-
-5.6:  I would like to track changes to current and do not have net access.  
-      Is there any way besides downloading the whole tree?
-
-Yes, you can use the CTM facility.  Check out the ctm.FAQ file or
-	ftp://freefall.cdrom.com/pub/CTM/README
-for more information.
-
-5.7:  How do I split up large binary files into smaller 240k files
-      like the distribution does?
-
-Newer BSD based systems have a "-b" option to split that allows them to
-split files on arbitary byte bondaries.
-
-Here is an example from /usr/src/Makefile.
-bin-tarball:
-	(cd ${DISTDIR}; \
-		tar cf - . \
-		gzip --no-name -9 -c | \
-		split -b 240640 - \
-		${RELEASEDIR}/tarballs/bindist/bin_tgz.)
-
-
-<XXX> 5.8:  I've had a couple of system panics and would like to be able
-      browse the system dumps.  The normal kernel is stripped and
-      I don't want to run a bloated kernel.  What can I do?
-
-5.9:  I just got a Perl application and it's bombing looking for
-      *.ph.  Where is it?
-
-There was a minor SNAFU in the 2.0-R bindist and they got left out.
-If you have the source, you just have to do a "make install" from
-/usr/src/gnu/usr.bin/perl/lib and everything will be fine.  Or you
-may ftp to phoenix-gw.gbdata.com and grab them from ~/pub/perl/libs.tar.gz.
-
-5.10: I've got this neato kernel extension I just know everyone will
-      will want.  How do I get it included into the distribution?
-
-Please take a look at the FAQ for submiting code to FreeBSD at:
-
-	ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FAQ/submitters.FAQ
-
-And thanks for the thought.
-
-
-6 Kernel Configuration
-----------------------
-
-6.0:  Ok, so how DO I compile my own kernel, anyway?
-
-Before you can compile a kernel, you need either the complete srcdist
-or, at the minimum, the kerndist loaded on your system.  This provides
-the necessary sources for building the kernel, as we have a policy of
-NOT shipping our kernels in linkable object form as most commercial
-UNIX vendors do.  Shipping the source takes a bit more space, but it also
-means that you can refer to the actual kernel sources in case of difficulty
-or to further your understanding of what's *actually* happening.
-
-Anyway, to answer the question, once you have the kerndist or srcdist
-loaded, do this:
-
-	6.0.1:		cd /usr/src/sys/i386/conf
-	6.0.2:		cp GENERIC MYKERNEL
-	6.0.3:		vi MYKERNEL
-	6.0.4:		config MYKERNEL
-	6.0.5:		cd ../../compile/MYKERNEL
-	6.0.6:		make all
-	6.0.7:		make install
-	6.0.8:		reboot
-
-Step 6.0.2 may not be necessary if you already have a kernel configuration
-file from a previous release of FreeBSD 2.x. - simply bring your old one
-over and check it carefully for any drivers that may have changed boot
-syntax or been rendered obsolete.
-
-A good kernel config file to look into is LINT, which contains entries for
-*all* possible kernel options and documents them fairly well.  The GENERIC
-kernel config file is used to build the initial release you probably loaded
-(unless you upgraded in-place) and contains entries for the most common
-configurations.  It's a pretty good place to start from.
-
-If you don't need to make any changes to GENERIC, you can also skip step
-6.0.3, where you customize the kernel for your configuration.  Step 6.0.7
-should only be undertaken if step 6.0.6 succeeds.  This will copy
-the new kernel image to /kernel and BACK UP YOUR OLD ONE IN /kernel.old!
-It's very important to remember this in case the new kernel fails to work
-for some reason - you can still select /kernel.old at the boot prompt to
-boot the old one.  When you reboot, the new kernel will boot by default.
-
-If the compile in 6.0.6 falls over for some reason, then it's recommended
-that you start from step 6.0.4 but substitute GENERIC for MYKERNEL.  If you
-can generate a GENERIC kernel, then it's likely something in your special
-configuration file that's bad (or you've uncovered a bug!).  If the build
-of the GENERIC kernel does NOT succeed, then it's very likely that your
-sources are somehow corrupted.
-
-Finally, if you need to see your original boot messages again to compile
-a new kernel that's better tailored to your hardware, try the `dmesg' command.
-It should print out all the boot-time messages printed by your old kernel,
-some of which may be quite helpful in configuring the new one.
-
-
-6.1:  When I compile a kernel with multi-port serial code, it tells me
-      that only the first port is probed and the rest skipped due to
-      interrupt conflicts.  How do I fix this?
-
-The problem here is that FreeBSD has code built-in to keep the kernel
-from getting trashed due to hardware or software conflicts.  The way
-to fix this is to leave out the IRQ settings on other ports besides
-the first.  Here is a example:
-
-#
-# Multiport high-speed serial line - 16550 UARTS
-#
-device    sio2    at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr
-device    sio3    at isa? port 0x2a8 tty flags 0x501 vector siointr 
-device    sio4    at isa? port 0x2b0 tty flags 0x501 vector siointr
-device    sio5    at isa? port 0x2b8 tty flags 0x501 vector siointr
-
-
-6.2:  FreeBSD is supposed to come with support for QIC-40/80 drives but
-      when I look, I can't find it.
-
-You need to uncomment the following line in the generic config file
-(or add it to your config file) and recompile.
-
-controller      fdc0    at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
-disk            fd0     at fdc0 drive 0
-disk		fd1     at fdc0 drive 1
-#tape           ft0     at fdc0 drive 2
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You will have a device called /dev/ft0, which you can write to through
-a special program to manage it called `ft' - see the man page on ft for
-further details.  Versions previous to -current also had some trouble dealing
-wiht bad tape media; if you have trouble where ft seems to go back and forth
-over the same spot, try grabbing the latest version of ft from /usr/src/sbin/ft 
-in current and try that.
-
-
-6.3:  Does FreeBSD support IPC primitives like those in System V?
-
-Yes, FreeBSD supports System V-style IPC.  This includes shared
-memory, messages and semaphores.  You need to add the following lines
-to your kernel config to enable them.
-
-options         SYSVSHM
-options         "SHMMAXPGS=64"          # 256Kb of sharable memory
-options         SYSVSEM                 # enable for semaphores
-options         SYSVMSG                 # enable for messaging
-
-Recompile and install.
-
-
-6.4:  Will FreeBSD ever support other architectures?
-
-Several different groups have expressed interest in working on
-multi-architecture support for FreeBSD.  If you are interested in
-doing so, please contact the developers at
-<FreeBSD-hackers@FreeBSD.ORG> for more information on our
-strategy for porting.
-
-
-6.5:  I just wrote a device driver for a Foobar Systems, Inc.
-      Integrated Adaptive Gronkulator card.  How do I get the
-      appropriate major numbers assigned?
-
-This depends on whether or not you plan on making the driver publicly
-available.  If you do, then please send us a copy of the driver source
-code, plus the appropriate modifications to files.i386, a sample
-configuration file entry, and the appropriate MAKEDEV code to create
-any special files your device uses.  If you do not, or are unable to
-because of licensing restrictions, then character major number 32 and
-block major number 8 have been reserved specifically for this purpose;
-please use them.  In any case, we'd appreciate hearing about your
-driver on <FreeBSD-hackers@FreeBSD.ORG>.
-
-
-
-7 System Administration
------------------------
-
-7.1:  How do I add a user easily?  I read the man page and am more confused
-      than ever!  [Alternatively:  I didn't read the man page, I never read
-      man pages! :-) ]
-
-Use the adduser command.
-
-
-<XXX> 7.2: I'm trying to use my printer and keep running into problems.  I tried
-     looking at /etc/printcap, but it's close to useless.  Any ideas?
-
-
-
-8 Networking
-------------
-
-
-8.2:  I've heard that you can use a FreeBSD box as a dedicated network
-      router - is there any easy support for this?
-
-Internet standards and good engineering practice prohibit us from
-providing packet forwarding by default in FreeBSD.  You can enable
-this support by adding `options GATEWAY' to your kernel configuration
-file and recompiling.  In most cases, you will also need to run a
-routing process to tell other systems on your network about your
-router; FreeBSD comes with the standard BSD routing daemon routed(8),
-or for more complex situations you may want to try GateD (available by
-FTP from gated.Cornell.edu) which supports FreeBSD as of 3_5Alpha7.
-
-It is our duty to warn you that, even when FreeBSD is configured in
-this way, it does not completely comply with the Internet standard
-requirements for routers; however, it comes close enough for ordinary
-usage.
-
-
-8.3:  Does FreeBSD support SLIP and PPP?
-
-Yes.  See the man pages for slattach(8) and/or pppd(8) if you're using
-FreeBSD to connect to another site.  If you're using FreeBSD as a
-server for other machines, look at the man page for sliplogin(8).
-You may also want to take a look at the slip FAQ in:
-             /usr/src/share/FAQ/Slip.FAQ
-
-8.4:  How do I get my network set up?  I don't see how to make my
-      /dev/ed0 device!
-
-In the Berkeley networking framework, network interfaces are only
-directly accessible by kernel code.  Please see the /etc/netstart file
-and the manual pages for the various network programs mentioned there
-for more information.  If this leaves you totally confused, then you
-should pick up a book describing network administration on another
-BSD-related operating system; with few significant exceptions,
-administering networking on FreeBSD is basically the same as on SunOS
-4.0 or Ultrix.
-
-8.5:  How do I get my 3C503 to use the other network port?
-
-Use `ifconfig ed0' to see whether the ALTPHYS flag is set, and then
-use either `ifconfig ed0 altphys' if it was off, or `ifconfig ed0
--altphys' if it was on.
-
-8.6:  I'm having problems with NFS to/from FreeBSD and my Wuffotronics
-      Workstation / generic NFS appliance, where should I look first?
-
-Certain PC network cards are better than others (to put it mildly) and
-can sometimes cause problems with network intensive applications like
-NFS.  See /usr/src/share/FAQ/NFS.FAQ for more information on this
-topic.
-
-8.8:  I want to enable IP multicast support on my FreeBSD box, how do I do it?
-      [Alternatively:  What the heck IS multicasting and what applications
-      make use of it?]
-
-Multicast host operations are fully supported in FreeBSD 2.0 by default.
-If you want your box to run as a multicast router, you will need to load
-the ip_mroute_mod loadable kernel module and run mrouted.
-
-For more information:
-
-Product		Description		Where
---------------- ----------------------- ---------------------------------------
-faq.txt		Mbone FAQ		ftp.isi.edu:/mbone/faq.txt
-imm/immserv	IMage Multicast 	ftp.hawaii.edu:/paccom/imm.src.tar.Z
-		for jpg/gif images.
-nv		Network Video.		ftp.parc.xerox.com:
-					/pub/net-reseach/exp/nv3.3alpha.tar.Z
-vat		LBL Visual Audio Tool.	ftp.ee.lbl.gov:
-					/conferencing/vat/i386-vat.tar.Z
-wb		LBL White Board.	ftp.ee.lbl.gov:
-					/conferencing/wb/i386-wb.tar.Z
-mmcc		MultiMedia Conference	ftp.isi.edu:
-		Control program		/confctrl/mmcc/mmcc-intel.tar.Z
-rtpqual		Tools for testing the	ftp.psc.edu:/pub/net_tools/rtpqual.c
-		quality of RTP packets.
-vat_nv_record	Recording tools for vat	ftp.sics.se:archive/vat_nv_record.tar.Z
-		and nv.
-
-
-
-9 Serial Communications
------------------------
-
-This section answers common questions about serial communications with
-FreeBSD.
-
-9.1: How do I tell if FreeBSD found my serial ports or modem cards?
-
-As the FreeBSD kernel boots, it will probe for the serial ports in
-your system for which the kernel was configured.  You can either watch
-your system closely for the messages it prints or run the command
-
-    dmesg | grep sio
-
-after your system's up and running.
-
-Here's some example output from the above command:
-
-    sio0 at 0x3f8-0x3ff irq 4 on isa
-    sio0: type 16550A
-    sio1 at 0x2f8-0x2ff irq 3 on isa
-    sio1: type 16550A
-
-This shows two serial ports.  The first is on irq 4, is using port
-address 0x3f8, and has a 16550A-type UART chip.  The second uses the
-same kind of chip but is on irq 3 and is at port address 0x2f8.
-Internal modem cards are treated just like serial ports---except that
-they always have a modem ``attached'' to the port.
-
-The GENERIC kernel includes support for two serial ports using the
-same irq and port address settings in the above example.  If these
-settings aren't right for your system, or if you've added modem cards
-or have more serial ports than your kernel is configured for, just
-reconfigure your kernel.  See section 7 of the FAQ for more details.
-
-9.2: How do I access the serial ports once FreeBSD is running?
-
-The third serial port, sio2 (known as COM3 in DOS), is on /dev/tty02
-for directly-connected devices, on /dev/cuaa2 for dial-out devices,
-and on /dev/ttyd2 for dial-in devices.  What's the difference between
-these three classes of devices?
-
-You use ttyXX for directly-connected or hardwired devices, like
-printers or terminals.
-
-In place of ttyXX, you can use the pair of devices cuaaX and ttydX.
-You use ttydX for dial-ins.  The ttydX device acts like the ttyXX
-device, but it also uses the modem control lines.  When opening
-/dev/ttydX in blocking mode, a process will wait for the corresponding
-cuaaX device to become inactive, and then wait for the carrier detect
-line to go active.  When you open the cuaaX device, it makes sure the
-serial port isn't already in use by the ttydX device.  If the port's
-available, it ``steals'' it from the ttydX device.  Also, the cuaaX
-device doesn't care about carrier detect.  With this scheme and an
-auto-answer modem, you can have remote users log in and you can still
-dialout with the same modem and the system will take care of all the
-conflicts.
-
-9.3: How do I configure the kernel for my multiport serial card?
-
-Again, the section on kernel configuration provides information about
-configuring your kernel.  For a multiport serial card, place an sio
-line for each serial port on the card in the kernel configuration
-file.  But place the irq and vector specifiers on only one of the
-entries.  All of the ports on the card should share one irq.  For
-consistency, use the last serial port to specify the irq.  Also,
-specify the COM_MULTIPORT option.
-
-The following example is for an AST 4-port serial card on irq 7:
-
-    options "COM_MULTIPORT"
-    device sio4 at isa? port 0x2a0 tty flags 0x781
-    device sio5 at isa? port 0x2a8 tty flags 0x781
-    device sio6 at isa? port 0x2b0 tty flags 0x781
-    device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr
-
-The flags indicate that the master port has minor number 7 (0x700),
-diagnostics enabled during probe (0x080), and all the ports share an
-irq (0x001).
-
-9.4: I have two multiport serial cards that can share irqs.  Can
-      FreeBSD handle this?
-
-Not yet.  You'll have to use a different irq for each card.
-
-9.5: What's the difference between tty01, ttyi01, and ttyl01?  Or,
-      how can I set the default serial parameters for a port?
-
-The ttyXX (or cuaaX or ttydX) device is the regular device you'll want
-to open for your applications.  When a process opens the device, it'll
-have a default set of terminal I/O settings.  You can see these
-settings with the command
-
-    stty -a -f /dev/tty01
-
-When you change the settings to this device, the settings are in
-effect until the device is closed.  When it's reopened, it goes back
-to the default set.  To make changes to the default set, you can open
-and adjust the settings of the ``initial state'' device.  For example,
-to turn on CLOCAL mode, 8 bits, and XON/XOFF flow control by default
-for tty05, do:
-
-    stty -f /dev/ttyi05 clocal cs8 ixon ixoff
-
-A good place to do this is in /etc/rc.serial.  Now, an application
-will have these settings by default when it opens tty05.  It can still
-change these settings to its liking, though.
-
-You can also prevent certain settings from being changed by an
-application by making adjustments to the ``lock state'' device.  For
-example, to lock the speed of tty05 to 57600 bps, do
-
-    stty -f /dev/ttyl05 57600
-
-Now, an application that opens tty05 and tries to change the speed of
-the port will be stuck with 57600 bps.
-
-Naturally, you should make the initial state and lock state devices
-writable only by root.  The MAKEDEV script does NOT do this when it
-creates the device entries.
-
-9.6: How can I enable dialup logins on my modem?
-
-So you want to become an Internet service provider, eh?  First, you'll
-need one or more modems that can autoanswer.  Your modem will need to
-assert carrier-detect when it detects a carrier and not assert it all
-the time.  It will need to hang up the phone and reset itself when the
-data terminal ready (DTR) line goes from on to off.  It should
-probably use RTS/CTS flow control or no local flow control at all.
-Finally, it must use a constant speed between the computer and itself,
-but (to be nice to your callers) it should negotiate a speed between
-itself and the remote modem.
-
-For many Hayes command-set--compatible modems, this command will
-make these settings and store them in nonvolatile memory:
-
-    AT &C1 &D3 &K3 &Q6 S0=1 &W
-
-See 9.10 below for information on how to make these settings without
-resorting to an MS-DOS terminal program.
-
-Next, make an entry in /etc/ttys for the modem.  This file lists all
-the ports on which the operating system will await logins.  Add a line
-that looks something like this:
-
-    ttyd1 "/usr/libexec/getty std.57600" dialup on insecure
-
-This line indicates that the second serial port (/dev/ttyd1) has a
-modem connected running at 57600 bps and no parity (std.57600, which
-comes from the file /etc/gettytab).  The terminal type for this port
-is ``dialup.''  The port is ``on'' and is ``insecure''---meaning root
-logins on the port aren't allowed.  For dialin ports like this one,
-use the ttydX entry.
-
-It's common practice to use ``dialup'' as the terminal type.  Many
-users set up in their .profile or .login files a prompt for the actual
-terminal type if the starting type is dialup.  The example shows the
-port as insecure.  To become root on this port, you have to login as a
-regular user, then ``su'' to root.  If you use ``secure'' then root
-can login in directly.
-
-After making modifications to /etc/ttys, you need to send a hangup or
-HUP signal to the init process:
-
-    kill -1 1
-
-This forces the init process to reread /etc/ttys.  The init process
-will then start getty processes on all ``on'' ports.  You can find out
-if logins are available for your port by typing
-
-    ps -ax | grep '[t]tyd1'
-
-You should see something like:
-
-    747 ??  I      0:00.04 /usr/libexec/getty std.57600 ttyd1 
-
-9.7: How can I make my spare computer a dumb terminal connected to my
-      FreeBSD box?
-
-If you're using another computer as a terminal into your FreeBSD
-system, get a null modem cable to go between the two serial ports.  If
-you're using an actual terminal, see its accompanying instructions.
-
-Then, modify /etc/ttys, like above.  For example, if you're hooking up
-a WYSE-50 terminal to the fifth serial port, use an entry like this:
-
-    tty04 "/usr/libexec/getty std.38400" wyse50 on secure
-
-This example shows that the port on /dev/tty04 has a wyse50 terminal
-connected at 38400 bps with no parity (std.38400 from /etc/gettytab)
-and root logins are allowed (secure).  For directly-connected
-terminals, use the ttyXX entry.
-
-9.8: Why can't I run tip or cu?
-
-On your system, the programs tip and cu are probably executable only
-by uucp and group dialer.  You can use the group dialer to control who
-has access to your modem or remote systems.  Just add yourself to
-group dialer.
-
-Alternatively, you can let everyone on your system run tip and cu by
-typing:
-
-    chmod 4511 /usr/bin/tip
-
-You don't have to run this command for cu, since cu is just a hard
-link to tip.
-
-9.9: My stock Hayes modem isn't supported---what should I do?
-
-Actually, the man page for tip is out of date.  There is a generic
-Hayes dialer already built in.  Just use ``at=hayes'' in your
-/etc/remote file.
-
-The Hayes driver isn't smart enough to recognize some of the advanced
-features of newer modems---messages like BUSY, NO DIALTONE, or CONNECT
-115200 will just confuse it.  You should turn those messages off when
-you use tip (using ATX0&W).
-
-Also, the dial timeout for tip is 60 seconds.  Your modem should use
-something less, or else tip will think there's a communication
-problem.  Try ATS7=45&W.
-
-9.10: How am I expected to enter these AT commands without
-       resorting to some DOS-based terminal program?
-
-Make what's called a ``direct'' entry in your /etc/remote file.  For
-example, if your modem's hooked up to the first serial port,
-/dev/cuaa0, then put in the following line:
-
-    cuaa0:dv=/dev/cuaa0:br#19200:pa=none
-
-Use the highest bps rate your modem supports in the br capability.
-Then, type ``tip cuaa0'' and you'll be connected to your modem.
-
-If there is no /dev/cuaa0 on your system, do this:
-
-    cd /dev
-    MAKEDEV cuaa0
-
-9.11: Why doesn't the @ sign for the phone number capability work?
-
-The @ sign in the pn capability tells tip to look in /etc/phones for a
-phone number.  But the @ sign is also a special character in
-capability files like /etc/remote.  Escape it with a backslash:
-``pn=\@''.
-
-9.12: How can I dial a phone number on the command line?
-
-Put what's called a ``generic'' entry in your /etc/remote file.  For
-example:
-
-    tip115200|Dial any phone number at 115200 bps:\
-        :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du:
-    tip57600|Dial any phone number at 57600 bps:\
-        :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du:
-
-Then you can things like ``tip -115200 5551234''.  If you prefer cu
-over tip, use a generic cu entry:
-
-    cu115200|Use cu to dial any number at 115200bps:\
-        :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:
-
-and type ``cu 5551234 -s 115200''.
-
-9.13: Great---but how can I do that without having to specify the bps
-       rate on the command line?
-
-Put in an entry for tip1200 or cu1200, but go ahead and use whatever
-bps rate is appropriate with the br capability.  tip thinks a good
-default is 1200 bps which is why it looks for a ``tip1200'' entry.
-You don't have to use 1200 bps, though.
-
-9.14: I want separate entries for various hosts I access through a
-       terminal server, but I don't want to type ``CONNECT <host>''
-       each time once I'm connected.  Can tip do that for me?
-
-Yes.  Use the cm capability.  For example, these entries in
-/etc/remote:
-
-    pain|pain.deep13.com|Forrester's machine:\
-        :cm=CONNECT pain\n:tc=deep13:
-    muffin|muffin.deep13.com|Frank's machine:\
-        :cm=CONNECT muffin\n:tc=deep13:
-    deep13:Gizmonics Institute terminal server:\
-        :dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234:
-
-will let you type ``tip pain'' or ``tip muffin'' to connect to the
-hosts pain or muffin; and ``tip deep13'' to get to the terminal
-server.
-
-9.15: My university has 42 billion students but only 4 modem lines.
-       Can tip automatically try each line?
-
-Sure.  Make an entry for your university in /etc/remote and use \@ for
-the pn capability:
-
-    big-university:\
-        :pn=\@:tc=dialout
-    dialout:\
-        :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none:
-
-Then, list the phone numbers for the university in /etc/phones:
-
-    big-university 5551111
-    big-university 5551112
-    big-university 5551113
-    big-university 5551114
-
-tip will try each one in the listed order, then give up.  If you want
-to keep retrying, run tip in a while loop.
-
-9.16: How come I have to hit CTRL+P twice to send CTRL+P once?
-
-CTRL+P is the default ``force'' character, used to tell tip that the
-next character is literal data.  You can set the force character to
-any other character with the ~s escape, which means ``set a
-variable.''
-
-Type ``~sforce=<single-char>'' followed by a newline.  <single-char>
-is any single character.  If you leave out <single-char>, then the
-force character is the nul character, which you can get by typing
-CTRL+2 or CTRL+SPACE.  A pretty good value for <single-char> is
-SHIFT+CTRL+6, which I've seen only used on some terminal servers.
-
-You can have the force character be whatever you want by specifying
-the following in your $HOME/.tiprc file:
-
-    force=<single-char>
-
-9.17: Suddenly everything I type is all UPPER CASE.  What gives?
-
-You must've pressed CTRL+A, tip's ``raise character,'' specially
-designed for people with broken caps-lock keys.  Use ~s as above and
-set the variable ``raisechar'' to something reasonable.  In fact, you
-can set it to the same as the force character, if you never expect to
-use either of these features.
-
-Here's a sample .tiprc file perfect for Emacs users who need to type
-CTRL+2 and CTRL+A a lot:
-
-    force=^^
-    raisechar=^^
-
-The ^^ is SHIFT+CTRL+6.
-
-9.18: How can I do file transfers with tip?
-
-If you're talking to another UNIX system, you can send and receive
-files with ~p (put) and ~t (take).  These commands run ``cat'' and
-``echo'' on the remote system to accept and send files.  The syntax
-is:
-
-    ~p <local-file> [<remote-file>]
-    ~t <remote-file> [<local-file>]
-
-There's no error checking, so you probably should use another
-protocol, like zmodem.
-
-9.19: Okay, how can I run zmodem with tip?
-
-To receive files, start the sending program on the remote end.  Then,
-type ``~C rz'' to begin receiving them locally.
-
-To send files, start the receiving program on the remote end.  Then,
-type ``~C sz <files>'' to send them to the remote system.
-
-
-
-NOTE: Anyone wishing to submit a FAQ entry on how to get tip and cu working
-      would have it much appreciated!  We all use Kermit over here! :-)
-
------------------------------------------------------------------------------
-If you see a problem with this FAQ, or wish to submit an entry, please
-mail us at <FreeBSD-FAQ@FreeBSD.ORG>.  We appreciate your
-feedback, and cannot make this a better FAQ without your help!
-
-
-                                        FreeBSD Core Team
-
------------------------------------------------------------------------------
-
-ACKNOWLEDGMENTS:
-
-Ollivier Robert		- FreeBSD FAQ maintenance man 
-Gary Clark II           - Ex-FreeBSD FAQ maintenance man  
-Jordan Hubbard          - Janitorial services (I don't do windows)
-Garrett Wollman         - Networking and formatting
-Robert Oliver, Jr.      - Ideas and dumb questions (That made me think)
-Jim Lowe                - Multicast information 
-The FreeBSD Team        - Kvetching, moaning, submitting data
-
-And to any others we've forgotten, apologies and heartfelt thanks!
-
diff --git a/share/FAQ/HW.TROUBLE b/share/FAQ/HW.TROUBLE
deleted file mode 100644
index ced53f4..0000000
--- a/share/FAQ/HW.TROUBLE
+++ /dev/null
@@ -1,58 +0,0 @@
-$Id: HW.TROUBLE,v 1.2 1995/02/22 03:49:46 phk Exp $
-
-This file lists hardware, which doesn't do what it should do.
-
-Due to the nature of FreeBSD, we do not have the resources to test all
-possible kinds of hardware.  We do however every now and then find, buy
-or hear about hardware which doesn't work with FreeBSD or in general.
-
-This is that list.
-
-To be added to this list, a piece of hardware has to:
-	A: not do what it claims.
-or
-	B: not do what common sense would expect it to.
-
-Only if performance claims are wildly of the mark will it be listed here.
-
-All entries must have a date and a mail-address associated with them, to
-reflect when and by whom they were added.
-For multifunctional devices, please indicate if other parts of the device
-work OK, or are untested.
-For mutual incompabilities, list both devices.
-For SCSI and IDE-devices, list the string seen on boot of FreeBSD, if 
-possible, and trade name.
-Infer format from other entries, Keep sorted by first line.
-
-Thankyou.
-
----
-Controller, Data Technology DTC2280, "PC/AT Super I/O Card"
-IDE interface can be set to secondary address, but doesn't work there.  Suspect
-Interrupt isn't moved along.  Works fine on primary address.  Other parts of
-card not tested.
-19940828 phk@freefall.cdrom.com
----
-IDE-disk, <WDC AC2540H>, "Western Digital Caviar 2540"
-IDE-disk, <Maxtor 7345 AT>, "Maxtor 7345"
-Cannot coexist on the same IDE-controller.
-Jumpers not exhaustively experimented with, as neither of the companies 
-make sufficient information available.  Disk works fine when alone on
-IDE-controller.
-19940828 phk@freefall.cdrom.com
----
-IDE-disk, <AC31000> "Western Digital Caviar 31000"
-IDE-disk, <ST3550A> "Seagate ST3550A"
-Western Digital AC31000 (Caviar 31000) 1080 meg IDE drive will not
-co-exist with a Seagate ST3550A.
-The Seagate as master causes a constant drive light and system lockup,
-The WD will work fine alone or as master, but the Seagate is inaccessable
-if configured as slave in this config.                
-19950221 jbryant@server.iadfw.net
-
-On Packard Bell computers with a BIOS Reference ID of less than 25, Packard
-Bell will replace the BIOS at no charge.  I waited, I got the bios, popped
-the case, popped the chip, put in the new, and plugged in the drives.  It
-works.  WD as master, seagate as slave.         
-19950228 jbryant@server.iadfw.net
----
diff --git a/share/FAQ/MIRROR.SITES b/share/FAQ/MIRROR.SITES
deleted file mode 100644
index 15b9b53..0000000
--- a/share/FAQ/MIRROR.SITES
+++ /dev/null
@@ -1,107 +0,0 @@
-                          Mirror Sites
-                    For FreeBSD 2.0 and later
-
-$Id: MIRROR.SITES,v 1.24 1995/02/15 07:07:18 jkh Exp $
-
-The latest versions of FreeBSD (2.0 or later) are being mirrored at the
-following locations:
-
-Country		Site and Maintainer
-=======		=========================================================
-Australia	ftp://ftp.physics.usyd.edu.au/FreeBSD
-		<dawes@xfree86.org>
-
-Finland		ftp://nic.funet.fi/pub/unix/FreeBSD
-		<ftp@nic.funet.fi>
-
-France		ftp://ftp.ibp.fr/pub/FreeBSD
-		<Remy.Card@ibp.fr>
-
-Germany		ftp://ftp.fb9dv.uni-duisburg.de/pub/unix/FreeBSD
-		<ftp@ftp.fb9dv.uni-duisburg.de>
-
-Hong Kong	ftp://ftp.hk.super.net/pub/FreeBSD
-		<ftp-admin@HK.Super.NET>
-
-Korea		ftp://ftp.cau.ac.kr/pub/FreeBSD
-		<ftpadm@ftp.cau.ac.kr>
-
-Netherlands	ftp://ftp.nl.net/pub/os/FreeBSD
-		<archive@nl.net>
-
-Russia		ftp://ftp.kiae.su/FreeBSD
-		<ftp@ftp.kiae.su>
-
-Sweden		ftp://ftp.luth.se/pub/FreeBSD
-		<ragge@ludd.luth.se>
-
-Taiwan		ftp://netbsd.csie.nctu.edu.tw/pub/FreeBSD
-		<ftp@netbsd.csie.nctu.edu.tw>
-
-Thailand	ftp://ftp.nectec.or.th/pub/FreeBSD
-		<ftpadmin@ftp.nectec.or.th>
-
-USA		ftp://gatekeeper.dec.com/pub/BSD/FreeBSD
-		<hubbard@gatekeeper.dec.com>
-
-USA		ftp://ftp.cybernetics.net/pub/FreeBSD
-		<michael@Cybernetics.NET>
-
-USA		ftp://ftp.neosoft.com/systems/FreeBSD
-		<smace@NeoSoft.COM>
-
-USA		ftp://kryten.atinc.com/pub/FreeBSD
-		<jmb@kryten.atinc.com>
-
-USA             ftp://ftp.dataplex.net/pub/FreeBSD
-                <rkw@dataplex.net>
-
-Japan		ftp://tutserver.tutcc.tut.ac.jp/FreeBSD
-		Ashida Hiroyuki <assie@bpel.tutics.tut.ac.jp>
-
-Japan		ftp://ftp.sra.co.jp/pub/os/FreeBSD
-		<ftp-admin@sra.co.jp>
-
-Japan		ftp://ftp.ee.uec.ac.jp/pub/os/FreeBSD.other
-		<ftp-admin@ftp.ee.uec.ac.jp>
-
-Japan		ftp://ftp.mei.co.jp/free/PC-UNIX/FreeBSD
-		TANIGUCHI Syuuhei <tanig@isl.mei.co.jp>
-
-Japan		ftp://ftp.waseda.ac.jp/pub/FreeBSD
-		<ftp-admin@waseda.ac.jp>
-
-Japan		ftp://ftp.pu-toyama.ac.jp/pub/FreeBSD
-		Yoshihiko USUI <usui@pu-toyama.ac.jp>
-
-Japan           ftp://ftpsv1.u-aizu.ac.jp/pub/os/FreeBSD
-		<ftp-admin@u-aizu.ac.jp>
-
-UK		ftp://src.doc.ic.ac.uk/packages/unix/FreeBSD
-		<wizards@doc.ic.ac.uk>
-
-UK		ftp://unix.hensa.ac.uk/pub/walnut.creek/FreeBSD
-		<archive-admin@unix.hensa.ac.uk>
-
-UK		ftp://ftp.demon.co.uk/pub/BSD/FreeBSD
-		<uploads@demon.net>
-
----
-
-The latest versions of export-restricted code for FreeBSD (2.0C or later)
-(eBones and secure) are being made available at the following locations.
-
-If you are outside the U.S. or Canada, please get secure (DES) and
-eBones (Kerberos) from one of the following foreign distribution sites:
-
-Country		Site and Maintainer
-=======		========================================================
-South Africa	ftp://skeleton.mikom.csir.co.za/pub/FreeBSD
-		Mark Murray <mark@grondar.za>
-
-South Africa	ftp://storm.sea.uct.ac.za/pub/FreeBSD
-		Shaun Courtney <ftp@storm.sea.uct.ac.za>
-
-Brazil          ftp://ftp.iqm.unicamp.br/pub/FreeBSD
-                Pedro A M Vazquez <vazquez@iqm.unicamp.br>
-
diff --git a/share/FAQ/Makefile b/share/FAQ/Makefile
deleted file mode 100644
index 033633b..0000000
--- a/share/FAQ/Makefile
+++ /dev/null
@@ -1,28 +0,0 @@
-#	$Id: Makefile,v 1.1 1994/11/08 03:58:48 phk Exp $
-#
-# Doing a make install builds /usr/share/examples
-
-DDIR=	${DESTDIR}/usr/share/FAQ
-NOOBJ=	noobj
-
-# Define SHARED to indicate whether you want symbolic links to the system
-# source (``symlinks''), or a separate copy (``copies''); (latter useful
-# in environments where it's not possible to keep /sys publicly readable)
-SHARED?=	copies
-
-all clean cleandir depend lint tags:
-
-beforeinstall: ${SHARED}
-
-copies:
-	@${ECHO} installing ${DDIR}
-	rm -rf ${DDIR}
-	mkdir ${DDIR}
-	find . -print | grep -v /CVS | grep -v Makefile | cpio -dumpv ${DDIR}
-
-symlinks:
-	@${ECHO} installing symlink to ${DDIR}
-	rm -rf ${DDIR}; \
-	ln -s ${.CURDIR} ${DDIR}; \
-
-.include <bsd.prog.mk>
diff --git a/share/FAQ/NEW_FOR_2_0 b/share/FAQ/NEW_FOR_2_0
deleted file mode 100644
index 331d840..0000000
--- a/share/FAQ/NEW_FOR_2_0
+++ /dev/null
@@ -1,8 +0,0 @@
-; This file describes new features, conventions or newly introduced "gotchas"
-; that a user coming from a 1.x environment should know about.
-;
-; This actual file can be a simple dumping ground for this information
-; until such time as we want to fold it into the release notes, or we
-; can try to tart it up around release time and simply refer to it in
-; various places.  I personally prefer the former option, though it's
-; not a religious issue.  -jkh
diff --git a/share/FAQ/NFS.FAQ b/share/FAQ/NFS.FAQ
deleted file mode 100644
index e6f7af8..0000000
--- a/share/FAQ/NFS.FAQ
+++ /dev/null
@@ -1,77 +0,0 @@
-FreeBSD and NFS [for a FAQ]
-
-Certain Ethernet adapters for ISA PC systems have limitations which
-can lead to serious network problems, particularly with NFS.  This
-difficulty is not specific to FreeBSD, but FreeBSD systems are affected
-by it.
-
-The problem nearly always occurs when (FreeBSD) PC systems are networked
-with high-performance workstations, such as those made by Silicon Graphics,
-Inc., and Sun Microsystems, Inc.  The NFS mount will work fine, and some
-operations may succeed, but suddenly the server will seem to become
-unresponsive to the client, even though requests to and from other systems
-continue to be processed.  This happens to the client system, whether the
-client is the FreeBSD system or the workstation.  On many systems, there is
-no way to shut down the client gracefully once this problem has manifested
-itself.  The only solution is often to reset the client, because the NFS
-situation cannot be resolved.
-
-Though the "correct" solution is to get a higher performance and capacity
-Ethernet adapter for the FreeBSD system, there is a simple workaround that
-will allow satisfactory operation.  If the FreeBSD system is the SERVER,
-include the option "wsize=1024" on the mount from the client.  If the
-FreeBSD system is the CLIENT, then mount the NFS file system with the
-option "rsize=1024".  These options may be specified using the fourth
-field of the fstab entry on the client for automatic mounts, or by using
-the "-o" parameter of the mount command for manual mounts.
-
-In the following examples, "fastws" is the host (interface) name of a
-high-performance workstation, and "freebox" is the host (interface) name of
-a FreeBSD system with a lower-performance Ethernet adapter.  Also,
-"/sharedfs" will be the exported NFS filesystem (see "man exports"), and
-"/project" will be the mount point on the client for the exported file
-system.  In all cases, note that additional options, such as "hard" or
-"soft" and "bg" may be desireable in your application.
-
-Examples for the FreeBSD system ("freebox") as the client:
-    in /etc/fstab on freebox:
-fastws:/sharedfs /project nfs rw,rsize=1024 0 0
-    as a manual mount command on freebox:
-mount -t nfs -o rsize=1024 fastws:/sharedfs /project
-
-Examples for the FreeBSD system as the server:
-    in /etc/fstab on fastws:
-freebox:/sharedfs /project nfs rw,wsize=1024 0 0
-    as a manual mount command on fastws:
-mount -t nfs -o wsize=1024 freebox:/sharedfs /project
-
-Nearly any 16-bit Ethernet adapter will allow operation without the above
-restrictions on the read or write size.
-
-For anyone who cares, here is what happens when the failure occurs, which
-also explains why it is unrecoverable.  NFS typically works with a "block"
-size of 8k (though it may do fragments of smaller sizes).  Since the maximum
-Ethernet packet is around 1500 bytes, the NFS "block" gets split into
-multiple Ethernet packets, even though it is still a single unit to the
-upper-level code, and must be received, assembled, and ACKNOWLEDGED as a
-unit.  The high-performance workstations can pump out the packets which
-comprise the NFS unit one right after the other, just as close together as
-the standard allows.  On the smaller, lower capacity cards, the later
-packets overrun the earlier packets of the same unit before they can be
-transferred to the host and the unit as a whole cannot be reconstructed or
-acknowledged.  As a result, the workstation will time out and try again,
-but it will try again with the entire 8K unit, and the process will be
-repeated, ad infinitum.
-
-By keeping the unit size below the Ethernet packet size limitation, we
-ensure that any complete Ethernet packet received can be acknowledged
-individually, avoiding the deadlock situation.
-
-Overruns may still occur when a high-performance workstations is slamming
-data out to a PC system, but with the better cards, such overruns are
-not guarranteed on NFS "units".  When an overrun occurs, the units affected
-will be retransmitted, and there will be a fair chance that they will be
-received, assembled, and acknowledged.
--- 
-		   John Lind, Starfire Consulting Services
-E-mail: john@starfire.MN.ORG		USnail: PO Box 17247, Mpls MN  55417
diff --git a/share/FAQ/PORTS.FAQ b/share/FAQ/PORTS.FAQ
deleted file mode 100644
index 2e04fd0..0000000
--- a/share/FAQ/PORTS.FAQ
+++ /dev/null
@@ -1,211 +0,0 @@
-			The FreeBSD Ports FAQ file
-
-Revision: $Id: PORTS.FAQ,v 1.1 1995/01/04 00:43:35 jkh Exp $
-
-The ports system is kinda new, so there haven't been too many FAQ's to
-date, but hopefully this document will pre-empt (some|most) of them!!
-The ports system is constantly changing, but hopefully this document
-will be kept reasonably up to date (and you never know, it might even
-make sense!).
-
-					- Gary Palmer
-					& jkh
-
-1) What is a port?
-
-    Unfortunately, there are more variations of UN*X than most people
-know of, and hence not all software for UN*X available on the Internet
-will work on all versions of UN*X (in fact, I can guarantee it!).
-Hence, some software needs modifications to work under some UN*Xs. The
-process of making those modifications is known as ``porting'' and the
-result known as a ``port'' (not to be confused with the sockets on the
-back of your computer!).
-
-
-2) What is the FreeBSD Ports Collection?
-
-    People who (allegedly) know what they are doing have automated the
-process of ``porting'' software to FreeBSD, and the result is the
-Ports Collection.  The general idea is that a combination of various
-programming tools available in the base FreeBSD installation will
-allow you to fetch the port from a FreeBSD mirror site, type ``make''
-and get the fully working program.
-
-    The ports collection itself normally doesn't have any of the
-original source code necessary for the compilation in the tree, just
-those shell scripts, Makefiles and source code ``diffs'' that are
-necessary to compile the program under FreeBSD.  This is meant to keep
-the entire system down to a manageable size, and the current system
-has over 100 ports in the master source tree, and yet a compressed tar
-file of that tree is about 2 megabytes (all the source code needed is
-over 100Mb's!).
-
-
-3) How does the system compile with no source code?
-
-    A ports' Makefile automatically looks in a central location on
-your system (usually /usr/ports/distfiles, though this value can be
-customized) for the associated set of original distribution files that
-have been ``ported''.  These are generally provided at various places
-on the Internet, though if you have a CDROM distribution of FreeBSD
-then you've already got them available on your CD for ease of use.
-See section 3.1 if you have such a CD distribution, otherwise skip to
-section 3.2.
-
-3.1  Compiling ports from CD
-
-    Type something profound here.
-
-3.2  Compiling ports using an Internet connection
-
-    The ports collection can also use an auto-fetch system to keep
-your ports collection source tree up to date, updating the central
-``distfiles'' version for you the next time you compile the port.
-
-    Of course, this always assumes you have a permanent network link,
-or don't mind heavy usage of your telephone.  If you don't want heavy
-network usage when you compile your ports tree, you can pre-fetch the
-necessary tarballs beforehand and put them into /usr/ports/distfiles
-(or wherever DISTDIR points) by hand.  A good way to see what files a
-port is going to need is to cd to that port's directory and do a
-``make -n fetch'' to see what it does.
-
-    You can also chose to get the source files either from the master
-FTP site as defined in the relevant Makefile (in the MASTER_SITES
-line), or some FreeBSD mirror site also carrying a set of distfiles,
-as does the master FTP site on ftp.FreeBSD.org (aka ftp.cdrom.com) in
-the directory /pub/FreeBSD/ports/distfiles.  Note that the files in
-that directory are not guarenteed to be kept up to date - this is a
-volunteer project!  We can't make any guarantees about the mirror
-sites either - they are obviously under independant control and don't
-even have to mirror the distfiles directory.
-
-    If you have a non-permanant link, you can fetch all the distfiles by
-going to the top of the tree and typing ``make fetch''.
-
-
-4) It doesn't work?!
-
-Oh. You can do one of four (4) things :
-
-a) Fix it yourself. Technical details can be found in the GUIDELINES file,
-   available from URL ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/GUIDELINES
-
-b) Gripe. This is done by e-mail *ONLY*! The people at Walnut Creek are
-   in no way responsible for the functionality (or lack thereof) of the
-   FreeBSD system as a whole, and especially the ports system, which
-   is mainly contributed by 3rd parties. (If you don't believe me, check
-   the catalogue, especially the line saying "We cannot offer tech-support
-   on this product")
-
-   The e-mail address is Ports@FreeBSD.org.  Please include details of
-   the port, where you got both the port source & distfile(s) from, and
-   what the error was.
-
-   Note: At time of writing, lang/Sather doesn't seem to work on Pentium
-   machines due to the Intel Curse (aka the Floating Point Division Bug).
-   Please don't tell us about this - gripe to Intel instead - it's their
-   bug!
-
-c) Forget it. This is the easiest for most - very few of the programs in
-   ports can be classed as `essential'!
-
-d) Grab the pre-compiled package from a ftp server. The ``master'' package
-   collection is in:
-	   ftp://ftp.FreeBSD.org/pub/FreeBSD/packages/
-
-   though check your local mirror first, please!
-
-   These are more likely to work (on the whole) than trying to compile from
-   source, and a lot faster!
-
-
-5) I've ported a program and I want to make a port out of it. What now?
-
-   See the file GUIDELINES, in:
-	   ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/GUIDELINES
-
-   This contains details of the procedure and structure involved.
-
-
-6) I've got a good port, what now?
-
-   Upload the fixed version to freefall.cdrom.com /pub/incoming or
-ftp.FreeBSD.org /pub/FreeBSD/incoming and send e-mail to
-ports@FreeBSD.org with the filename and details.  Someone on the
-all-volunteer `ports committee' will (hopefully) look it over and
-commit it to the ports collection if they like the looks of it.
-
-
-7) Things go funny during the fetch stage of compilation!
-
-   We know.  Please don't blame us. There is a program called `ncftp'
-which is used instead of the normal ftp as it can do so-called
-``background'' or ``batch'' transfers, ideal for this situation.
-Unfortunately it can do strange things, and has crashed at least one
-machine (during circumstances stranger than most, I'll admit, but it
-was still responsible). Hopefully a future release of ncftp will fix
-these problems (it is not maintained by the main FreeBSD team, but a
-third party, who is I believe aware of its shortcomings)
-
-
-8) I want to leave the compile going overnight, but some ports don't
-   like this.
-
-   There is a way around this. Before starting the compilation, type:
-	setenv BATCH yes # (if you use csh/tcsh) or
-	BATCH=yes # (for sh/bash)
-
-    This should miss out ports which need user interaction. Unfortunately,
-ncftp doesn't know about this trick, and can often screw up and ask
-stupid questions in unattended batch mode. See (7).
-
-    To compile those ports left out by doing the above, using a
-different login shell (or unsetting the above BATCH variable), set the
-INTERACTIVE variable instead (you can use the same statements as above
-except replace ``BATCH'' with ``INTERACTIVE'') and re-run make. This
-should now compile only those ports which will definitely ask for user
-interaction.
-
-
-9) The ports collection is weak.  What can I do to help?
-
-    First read the bsd.port.mk file (which may be found in
-/usr/share/mk/) and the associated bsd.port.subdir.mk file. A lot of
-the weirdness can be explained properly in there (most of the current
-weirdness is due to the lack of assumptions about anything, which is
-necessary due to the generic nature of these files). Also check that
-you have an up-to-date copy, as the file can change from minute to
-minute.  A reasonably up-to-date copy can be found in:
-
-  ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/mk/bsd.port*
-
-    If you find that you still need to go in there and alter things,
-by all means do so, and then send the diffs to ports@FreeBSD.org if
-you'd like them to be a part of the default distribution.  Please also
-remember that any changes must respect backwards-compatability with
-any and all older Makefiles, unless you want a real nightmare of
-/usr/ports munging ahead of you!  Large scale changes will generally
-not be warmly welcomed unless all the existing makefiles work without
-alteration. Sorry!
-
-
-10) This FAQ is weak.  What can I do?
-
-    Send changes to ports@FreeBSD.org.  Changes are most welcome!
-This FAQ is also very green and should be considered no more than
-a `good start' for now.  Authors?  You can come out of hiding any
-time now! :-)
-
-
-11) How do I get more information on all the ports?
-
-    One good method is to cd to the top of the ports tree (say /usr/ports)
-and type something like:
-
-	make describe | sed -e '/===/D' -e 's;/usr/ports/;;' | expand -40
-
-The ``make describe'' will try to extract the one-line description from
-each port, and the ``sed'' will delete the extraneous output.  ``expand''
-just makes it a little more readable (sort of - you may want to season
-the output of this more to taste).
diff --git a/share/FAQ/PPP.doc b/share/FAQ/PPP.doc
deleted file mode 100755
index 26133eb..0000000
--- a/share/FAQ/PPP.doc
+++ /dev/null
@@ -1,368 +0,0 @@
-
-         Info about setting up pppd daemon on FreeBSD-2.0
-
-Before you start setting up PPP on your machine make
-sure that pppd is located in /usr/sbin and directory /etc/ppp
-exists.
-
-pppd can work in two modes:
-
-i) as a "client" , i.e. you want to connect your machine to outside
-world via PPP serial connection or modem line.
-
-ii) as a "server" , i.e. your machine is located on the network and
-used to connect other computers using PPP.
-
-In both cases you will need to set up an options file ( /etc/ppp/options
-or ~/.ppprc if you have more then one user on your machine that uses
-PPP ).
-
-You also will need some modem/serial software ( preferably kermit )
-so you can dial and establish connection with remote host.
-
-1) Working as a PPP client
-
-I used the following options to connect to CISCO terminal server PPP
-line.
-
-----/etc/ppp/options-------
-crtscts		# enable hardware flow control
-modem		# modem control line
-noipdefault	# remote PPP server must supply your IP address.
-		# if the remote host doesn't send your IP during IPCP
-		# negotiation , remove this option
-passive		# wait for LCP packets
-domain ppp.foo.com	# put your domain name here
-
-:<remote_ip>	# put the IP of remote PPP host here
-		# it will be used to route packets via PPP link
-		# if you didn't specified the noipdefault option
-		# change this line to <local_ip>:<remote_ip>
-
-defaultroute	# put this if you want that PPP server will be your
-		# default router
--------------------------
-
-To connect:
-i) Dial to the remote host using kermit ( or other modem program )
-enter your user name and password ( or whatever is needed to enable PPP
-ont the remote host )
-
-ii) Exit kermit. ( without hanging up the line )
-
-iii) enter: 
-/usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200
-( put the appropriate speed and device name )
-
-Now your computer is connected with PPP. If the connection fails for some
-reasons you can add the "debug" option to the /etc/ppp/options file
-and check messages on the console to track the problem
-
-Following script will make all 3 stages automatically:
------/etc/ppp/pppup--------
-#!/bin/sh 
-ps ax |grep pppd |grep -v grep
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill ${pid}
-fi
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-
-ifconfig ppp0 down
-ifconfig ppp0 delete
-
-kermit -y /etc/ppp/kermit.dial
-pppd /dev/tty01 19200
------------------------------
-
-/etc/ppp/kermit.dial is kermit script that dials and makes all
-necessary authorization on the remote host.
-( Example of such script is attached to the end of this document )
-
-Use the follwing script to disconnect the PPP line:
------/etc/ppp/pppdown--------
-#!/bin/sh
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ X${pid} != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill -TERM ${pid}
-fi
-
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-
-/sbin/ifconfig ppp0 down
-/sbin/ifconfig ppp0 delete
-kermit -y /etc/ppp/kermit.hup 
-/etc/ppp/ppptest
-------------------------------
-
-Check if PPP is still running:
-
------/etc/ppp/ppptest---------
-#!/bin/sh
-pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'`
-if [ X${pid} != "X" ] ; then
-        echo 'pppd running: PID=' ${pid-NONE}
-else
-        echo 'No pppd running.'
-fi
-set -x
-netstat -n -I ppp0
-ifconfig ppp0
------------------------------
-
-Hangs up modem line:
-
------/etc/ppp/kermit.hup-----
-set line /dev/tty01	; put your modem device here
-set speed 19200
-set file type binary
-set file names literal
-set win 8
-set rec pack 1024
-set send pack 1024
-set block 3
-set term bytesize 8
-set command bytesize 8
-set flow none
-
-pau 1
-out +++
-inp 5 OK
-out ATH0\13
-echo \13
-exit
-----------------------------
-
-2) Working as a PPP server
-
-------/etc/ppp/options------
-crtscts				# Hardware flow control
-netmask 255.255.255.0		# netmask ( not required )
-192.114.208.20:192.114.208.165  # ip's of local and remote hosts
-				# local ip must be different from one
-				# you assigned to the ethernet ( or other )
-				# interface on your machine.
-				# remote IP is ip address that will be 
-				# assigned to the remote machine
-domain ppp.foo.com		# your domain
-passive				# wait for LCP
-modem				# modem line
-----------------------------
-
-Following script will enable ppp server on your machine
-
------/etc/ppp/pppserv-------
-#!/bin/sh 
-ps ax |grep pppd |grep -v grep
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill ${pid}
-fi
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-
-# reset ppp interface
-ifconfig ppp0 down
-ifconfig ppp0 delete
-
-# enable autoanswer mode
-kermit -y /etc/ppp/kermit.ans
-
-# run ppp
-pppd /dev/tty01 19200
-----------------------------
-
-Use this script to stop ppp server:
-
------/etc/ppp/pppservdown---
-#!/bin/sh 
-ps ax |grep pppd |grep -v grep
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill ${pid}
-fi
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-ifconfig ppp0 down
-ifconfig ppp0 delete
-
-kermit -y /etc/ppp/kermit.noans
-----------------------------
-
-Following kermit script will enable/disable autoanswer mode 
-on your modem:
-
------/etc/ppp/kermit.ans----
-set line /dev/tty01
-set speed 19200
-set file type binary
-set file names literal
-set win 8
-set rec pack 1024
-set send pack 1024
-set block 3
-set term bytesize 8
-set command bytesize 8
-set flow none
-
-pau 1
-out +++
-inp 5 OK
-out ATH0\13
-inp 5 OK
-echo \13
-out ATS0=1\13	; change this to out ATS0=0\13 if you want to disable
-		; autoanswer mod
-inp 5 OK
-echo \13
-exit
------------------------------
-
-This script is used for dialing and authorizing on remote host.
-You will need to customize it for your needs.
-Put your login and password in this script , also you'll need
-to change input statement depending on responces from your modem
-and remote host.
-
------/etc/ppp/kermit.dial----
-
-;
-; put the com line attached to the modem here:
-;
-set line /dev/tty01
-;
-; put the modem speed here:
-;
-set speed 19200
-set file type binary		; full 8 bit file xfer
-set file names literal
-set win 8
-set rec pack 1024
-set send pack 1024
-set block 3
-set term bytesize 8
-set command bytesize 8
-set flow none
-set modem hayes
-set dial hangup off
-set carrier auto		; Then SET CARRIER if necessary,
-set dial display on		; Then SET DIAL if necessary,
-set input echo on
-set input timeout proceed
-set input case ignore
-def \%x 0			; login prompt counter
-goto slhup
-
-:slcmd				; put the modem in command mode
-echo Put the modem in command mode.
-clear				; Clear unread characters from input buffer
-pause 1
-output +++			; hayes escape sequence
-input 1 OK\13\10		; wait for OK
-if success goto slhup
-output \13
-pause 1
-output at\13
-input 1 OK\13\10
-if fail goto slcmd		; if modem doesn't answer OK, try again
-
-:slhup				; hang up the phone
-clear				; Clear unread characters from input buffer
-pause 1
-echo Hanging up the phone.
-output ath0\13			; hayes command for on hook
-input 2 OK\13\10
-if fail goto slcmd		; if no OK answer, put modem in command mode
-
-:sldial				; dial the number
-pause 1
-echo Dialing.
-output atdt9,550311\13\10		; put phone number here
-assign \%x 0			; zero the time counter
-
-:look
-clear				; Clear unread characters from input buffer
-increment \%x			; Count the seconds
-input 1 {CONNECT }
-if success goto sllogin
-reinput 1 {NO CARRIER\13\10}
-if success goto sldial
-reinput 1 {NO DIALTONE\13\10}
-if success goto slnodial
-reinput 1 {\255}
-if success goto slhup
-reinput 1 {\127}
-if success goto slhup
-if < \%x 60 goto look
-else goto slhup
-
-:sllogin			; login
-assign \%x 0			; zero the time counter
-pause 1
-echo Looking for login prompt.
-
-:slloop
-increment \%x			; Count the seconds
-clear				; Clear unread characters from input buffer
-output \13
-;
-; put your expected login prompt here:
-;
-input 1 {Username: }
-if success goto sluid
-reinput 1 {\255}
-if success goto slhup
-reinput 1 {\127}
-if success goto slhup
-if < \%x 10 goto slloop		; try 10 times to get a login prompt
-else goto slhup			; hang up and start again if 10 failures
-
-:sluid
-;
-; put your userid here:
-;
-output ppp-login\13
-input 1 {Password: }
-;
-; put your password here:
-;
-output ppp-password\13
-input 1 {Entering SLIP mode.}
-echo
-quit
-
-:slnodial
-echo \7No dialtone.  Check the telephone line!\7
-exit 1
-
-; local variables:
-; mode: csh
-; comment-start: "; "
-; comment-start-skip: "; "
-; end:
-------------------------
-
-###################################################################
-Gennady B. Sorokopud ( gena@NetVision.net.il ) 24/10/94 12:00
diff --git a/share/FAQ/README b/share/FAQ/README
deleted file mode 100644
index bf326c0..0000000
--- a/share/FAQ/README
+++ /dev/null
@@ -1,55 +0,0 @@
-This directory contains frequently asked questions, short user guides,
-tutorials and other miscellaneous information that may be of help
-to the beginning (or even advanced) FreeBSD user.  Any submissions
-to this directory should be sent to:
-
-                        FreeBSD-FAQ@FreeBSD.ORG
-
-For inclusion with the next release.  Your contributions are not only
-welcome, but often save new users from uncountable headaches!  If you've
-written something you think may help new users, please - by all means
-send it to us!
-
-Thanks!
-
-					The FreeBSD Project
-
-----
-ROADMAP:
-
-File				Description
-===============================================================================
-FreeBSD.FAQ			The overall FreeBSD FAQ - posted regularly to
-				USENET.
-
-FreeBSD-1.1.FAQ			FreeBSD FAQ for versions 1.1.5.1 and below.
-
-HW.TROUBLE			User feedback on finicky or broken hardware.
-
-MIRROR.SITES			A list of all sites mirroring FreeBSD 2.x.
-
-NFS.FAQ				Tips for users using NFS between FreeBSD
-				and workstation hardware.
-
-Systems.FAQ			Systems and configurations on which FreeBSD
-				is "known" to work.
-
-Systems-1.1.FAQ			Systems for 1.1.5.1 and below
-
-current-policy.FAQ		What you should know about running
-				FreeBSD-current.
-
-kernel-debug.FAQ		How to debug kernels for 1.1.5.1 and below.
-
-mailing-list.FAQ		All about the FreeBSD mailing lists.
-
-ports-supfile			A sample supfile for the FreeBSD ports
-				collection.
-
-slip-dialup			How to configure SLIP.
-
-standard-supfile		A sample supfile for the FreeBSD source tree.
-
-sup.FAQ				All about sup in general.
-
-
diff --git a/share/FAQ/README-2.0 b/share/FAQ/README-2.0
deleted file mode 100644
index c9d81f9..0000000
--- a/share/FAQ/README-2.0
+++ /dev/null
@@ -1,75 +0,0 @@
-Use PageUp, PageDown or Arrow keys to navigate this screen.
-
-   -----------------------------------------
-       FreeBSD 2.0  ---  RELEASE Version               ,        ,
-   -----------------------------------------          /(        )`
-                                                      \ \___   / |
-Welcome to the first public release of FreeBSD 2.0    /- _  `-/  '
-first public snapshot of our new 4.4BSD Lite based   (/\/ \ \   /\
-operating system environment.  Our installation      / /   | `    \
-procedure has been completely revamped, and should   O O   ) /    |
-now be much easier for both the novice and           `-^--'`<     '
-experienced user alike.  We've also gone to some    (_.)  _  )   /
-care to make the process of installing the           `.___/`    /
-subsequent bindist and other miscellaneous             `-----' /
-distributions considerably more seamless  <----.     __ / __   \
-as well as offering a greater variety     <----|====O)))==) \) /====
-of installation methods and options.      <----'    `--' `.__,' \
-                                                       |        |
-We hope you'll find this new process as enjoyable       \       /	/\
-to use as it was to write!  (No, really, it        ______( (_  / \______/
-was! :-)                                         ,'  ,-----'   |
-                                                 `--{__________)
-Disclaimer:  Please note that despite numerous     
-safeguards, it's still more than possible to WIPE OUT YOUR ENTIRE DISK
-with this installation!  Please do not proceed unless you've
-adequately backed up any important data first!  We really mean it!
-
-If any errors occur during this installation, you can see them
-by toggling over to the alternate screen.  Type ALT-F2 to switch
-to the debugging screen and ALT-F1 to switch back to the install screen.
-The debugging output on the second screen may be very valuable to us in
-understanding your bug report, so please be sure to take note of it when
-reporting any failures in the installation!  Thanks!
-
-You may also wish to read the TROUBLESHOOTING document in _advance_
-and perhaps save yourself from making those sorts of errors in
-the first place! :-)
-
-Menus and scrolling output windows may be traversed with the arrow,
-PageUp/PageDown and TAB keys.  To suspend the installation at any point,
-hit ESC twice.  If you've ever dealt with a DOS installation before, then
-you'll probably know how to deal with this.
-
-For a more complete description of what's new in this release, please
-see the release notes.
-
-For more documentation on this system, it is recommended that you purchase
-the 4.4BSD Document Set from O'Reilly Associates and the USENIX Association.
-ISBN 1-56592-082-1  We have no connection with O'Reilly, we're just
-satisfied customers!
-
-Have fun, and please let us know of any problems you encounter with
-this release!
-
-Comments should be sent to:
-
-	hackers@FreeBSD.org
-
-Bug reports should be sent using the `send-pr' utility, if you
-were able to get the system installed, otherwise to:
-
-	bugs@FreeBSD.org
-
-And general questions to:
-
-	questions@FreeBSD.org
-
-
-Please have patience if your questions are not answered right away -
-this is an especially busy time for us, and our volunteer resources
-are often strained to the limit (if not somewhat past!).
-
-Thanks!
-
-				The FreeBSD Project
diff --git a/share/FAQ/REGISTER.FreeBSD b/share/FAQ/REGISTER.FreeBSD
deleted file mode 100644
index 92ae0ae..0000000
--- a/share/FAQ/REGISTER.FreeBSD
+++ /dev/null
@@ -1,85 +0,0 @@
-In the absence of any other mechanism for counting the number of users
-of FreeBSD, we like to kindly suggest that you take a few minutes to please
-register with the counter set up by <Harald.T.Alvestrand@uninett.no>.  
-
-The justification for such "registration" is twofold:  First, we really would
-like to know more about the size and demographics of our user-base in order
-to better support its needs.  Second, it's a sad fact of life that many
-people rely on counters and statistics (even when highly dubious) rather
-than on actual experience when chosing an operating system, and the best we
-can hope to do in such circumstances is to at least try to provide some
-indication of how popular we are (or are not).  This is not how we recommend
-that people go about chosing an operating system, but the necessity of
-such "marketing" remains an undeniable fact.
-
-The FreeBSD team does not necessarily feel that Harald's counter represents
-the best approach to such statistics gathering, and its accuracy can only
-be as good as people's willingness to register with it (and may not reflect
-the actual OS population at any single point in time), but in the total absence
-of any other mechanism for providing such useful statistics, it's certainly a
-start and we thank Harald for his efforts in providing this service.
-It's a community service, and of potential benefit to everyone (all *BSD
-users), so let's see if we can't make it work!
-
-Included below is the standard blurb from the counter.
-
-Thanks in advance,
-
-				The FreeBSD team.
-
-
-How to get registered
-=====================
-
-In brief:
-
-  [To register a running installation of FreeBSD]
-  Send E-mail to bsd-counter@uninett.no with the SUBJECT line
-  
-    "I use FreeBSD at <place>"
-
-Introduction
-============
-The intention of this counting project is to count all users of UNIXes
-that are:
-
- - BSD-derived
- - Freely available
-
-The variants NetBSD, 386BSD and FreeBSD are currently distinguished.
-
-(NOTE: Linux is NOT BSD-derived. If you use that, send mail to
-linux-counter@uninett.no instead!!!)
-
-The information is *not* used for any purpose but statistics, and unless
-you request it, information about single persons are *never* made public.
-(A list of users who have requested publication is available from the
-FTP file ftp://aun.uninett.no/pub/misc/386bsd/persons)
-
-How to register
-===============
-Send E-mail to bsd-counter@uninett.no
-
-The subject should be
-
-  I use FreeBSD|NetBSD|386BSD at <place>
-
-Where FreeBSD, NetBSD or 386BSD is the particular variant you're using
-and "place" can be school, work or home, or a combination of these.
-
-You will get back a letter with 3 things:
-
-  - An acknowledgement
-  - A form that you can fill out and send in with more information
-    about yourself, your machine, and your 386bsd-using friends
-  - A report giving the current status of the counter
-
-You can update your "vote" at any time, by sending an E-mail message
-from the same account. Duplicates will be weeded out.
-
-The current report, available by anonymous FTP to aun.uninett.no,
-directory pub/misc/386bsd-counter, file "short", is given below.
-
-For all questions, contact Harald.T.Alvestrand@uninett.no!
-
-$Id: REGISTER.FreeBSD,v 1.1 1994/11/18 12:03:29 jkh Exp $
diff --git a/share/FAQ/RELNOTES.FreeBSD b/share/FAQ/RELNOTES.FreeBSD
deleted file mode 100644
index 4d56492..0000000
--- a/share/FAQ/RELNOTES.FreeBSD
+++ /dev/null
@@ -1,624 +0,0 @@
-                                 RELEASE NOTES
-                                    FreeBSD
-                                 Release 2.0
-
-1. Technical overview
----------------------
-
-FreeBSD is a freely available, full source 4.4 BSD Lite based release
-for Intel i386/i486/Pentium (or compatible) based PC's.  It is based
-primarily on software from U.C. Berkeley's CSRG group, with some
-enhancements from NetBSD, 386BSD, and the Free Software Foundation.
-
-Since our first release of FreeBSD 1.0 some 18 months ago, FreeBSD
-has changed almost entirely.  A new port from the Berkeley 4.4 code
-base was done, which brought the legal status of the system out of the
-shadows with the blessing of Novell (new owners of USL and UNIX).  The
-port to 4.4 has also brought in a host of new features, filesystems
-and enhanced driver support.  With our new unencumbered code base, we
-have every reason to hope that we'll be able to release quality
-operating systems without further legal encumbrance for some time to
-come!
-
-FreeBSD 2.0 represents the culmination of almost 2 years of work and
-many thousands of man hours put in by an international development team.
-We hope you enjoy it!
-
-Many packages have also been upgraded or added, such as XFree86 3.1,
-xview 3.2, elm, nntp, mh, InterViews and dozens of other miscellaneous
-utilities have been ported and are now available as add-ons.  See the
-ports collection (or the package collection) for a complete summary.
-
-For a list of contributors and a general project description, please see
-the file "CONTRIB.FreeBSD" which should be bundled with your binary
-distribution.
-
-Also see the "REGISTER.FreeBSD" file for information on registering
-with the "Free BSD user counter".   This counter is for ALL freely
-available variants of BSD, not just FreeBSD, and we urge you to register
-yourself with it.
-
-The core of FreeBSD does not contain DES code which would inhibit its
-being exported outside the United States.  There is an add-on package
-to the core distribution, for use only in the United States, that
-contains the programs that normally use DES.  The auxilliary packages
-provided separately can be used by anyone.   A freely (from outside the
-U.S.) exportable European distribution of DES for our non U.S. users also
-exists and is described in the FreeBSD FAQ.
-
-If password security for FreeBSD is all you need, and you have no
-requirement for copying encrypted passwords from different hosts (Suns,
-DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5
-based security may be all you require!  We feel that our default security
-model is more than a match for DES, and without any messy export issues
-to deal with.  If you're outside (or even inside) the U.S., give it a try!
-
-
-1.1 What's new in 2.0?
-----------------------
-
-4.4 Lite
---------
-As previously stated, this release is based entirely on CSRG's
-latest (and last) BSD release - 4.4 Lite.  This features a number
-of improvements over 4.2BSD (Net/2), not least of which are:
-
-o	Legal approval of Novell & U.C. Berkeley.  After the settlement
-	of the longstanding lawsuit between USL/UCB/Novell/BSDI, all
-	parties were (strongly) encouraged to move to 4.4 Lite in order
-	to avoid future legal entanglements.  The fact that we've now done
-	so should make this release much more attractive to potential
-	commercial users.
-
-o	Many new filesystem types, such as stackable filesystems, union
-	filesystems, "portals", kernfs, a simple log-structured filesystem, a
-	new version of NFS (NQNFS), etc.  While some of these new filesystems
-	are also rather unpolished and will require significant additional
-	work to be truly robust, they're a good start.
-
-o	64bit offsets, allowing filesystems of up to 2^63 bytes in size.
-
-o	Further work towards full POSIX compliance.
-
-IP multicast support
---------------------
-The IP multicast support has been upgraded from the woefully ancient
-1.x code in 4.4-Lite to the most current and up-to-date 3.3 release
-from Steve D. and Ajit.  The non-forwarding code is known to work (for
-some limited test cases).  The multicast forwarder and user-mode
-multicast routing process are known to compile, but have not been
-significantly tested (hopefully this will happen before 2.0 release).
-
-Owner:			wollman
-Sources involved:	sys/netinet, usr.sbin/mrouted
-
-Loadable Kernel Modules
------------------------
-David Greenman incorporated NetBSD's port of Terry Lambert's loadable
-kernel module support.  Garrett Wollman wrote the support for loadable
-file systems, and Søren Schmidt did the same for loadable execution
-classes.
-
-Owner:			core
-Sources involved:	sys/kern, sbin/modload, sbin/modunload,
-			usr.bin/modstat
-
-
-Loadable filesystems
---------------------
-Most filesystems are now dynamically loadable on demand, with the
-exception of the UFS family (FFS, LFS, and MFS).  With the exception
-of NFS, all such filesystems can be unloaded when all references are
-unmounted.  To support this functionality, the getvfsbyname(3)
-family of functions has been added to the C library and the lsvfs(1)
-command provides the same information at the shell level.  Be aware of
-the following current restrictions:
-
-	- /usr/bin may not reside on a dynamically loaded filesystem.
-	- There must be a writable /tmp directory available
-	  before filesystems are loaded (moving / to the top of your
-	  /etc/fstab file will accomplish this).
-	- Some of the more esoteric filesystems simply don't work when loaded
-	  dynamically (though they often don't work "static", either.)
-
-Owner:			wollman
-Sources involved:	sys/*fs, lkm/*fs, usr.bin/lsvfs, lib/libc/gen
-
-
-S/Key
------
-Since version 1.1.5, FreeBSD has supported the S/Key one time password
-scheme.  The version used is derived from the logdaemon package of Wietse
-Venema.
-Some of the features new in 2.0 are:
-	- New access control table format to impose the use of S/Keys
-	  based on: hostname, ip address, port, username, group id.
-	- S/Key support can be disabled by not having the access control
-	  table.
-The second item explains the absence of skey.access in the installed /etc.
-To enable S/Key support, create a file skey.access in /etc and fill it
-according to your needs. See also skey.access(5) and the example in
-/usr/share/examples/etc/skey.access.
-
-Owner:			pst, guido
-Sources involved:	lib/libskey, usr.bin/key* (plus patches to others)
-
-
-TCP/IP over parallel (printer) port
------------------------------------
-You can now run TCP/IP over a standard LapLink(tm) cable, if both ends
-have an interrupt-driven printerport.  The interface is named "lp0"
-where '0' is the same as the lpt# unit number.  This is not compatible
-with PLIP.  If you run NFS, try setting MTU to 9180, otherwise leave
-it at 1500 unless you have a good reason to change it.  Speed varies
-with the CPU-type, with up to 70 kbyte/sec having been seen and 50
-kbyte/sec being the norm.
-
-Owner:			phk
-Sources involved:	isa/lpt.c
-
-
-ProAudioSpectrum SCSI driver
-----------------------------
-If you have a PAS board with a CD-ROM, and the MS-DOS driver is called
-TSLCDR.SYS, then the "pas" driver should work on your card.  You can
-attach disks, cdroms and tapes, but due to the nature of the hardware
-involved, the transfer rate is limited to < 690 kbyte/sec.  For CD-ROM
-use, this is generally more than enough.
-
-Owner:			phk
-Sources involved:	isa/pas.c
-
-
-Adaptec 2742/2842 SCSI driver
------------------------------
-Despite the non-cooperation of Adaptec in providing technical
-information, we now have a driver for the AHA-274x and AHA-284x
-series SCSI controller family.  This driver uses the GPL'd
-Linux sequencer code, so until we find an alternative, this
-will be part of the kernel that requires source code to be
-distributed with it at all times.  This shouldn't be a problem
-for any of FreeBSD's current users.
-
-Owner:			gibbs
-Sources involved:	isa/aic7770.c sys/gnu/misc/*
-
-
-Gzip'd binaries
-----------------
-We have an experimental implementation for direct execution of gzip'ed
-binaries in this release.  When enabled, it allows you to simply gzip
-your binaries, remove the '.gz' extension and make the file
-executable.  There is a big speed and memory consumption penalty for
-doing this, but for laptop users it may be worthwhile.  The maximum
-savings are generally around 10 Mb of disk space.
-
-Owner:			phk
-Sources involved:	kern/imgact_gzip.c kern/inflate.c
-
-
-Diskless booting
-----------------
-
-Diskless booting in 2.0 is much improved since 1.1.5.  The
-boot-program is in src/sys/i386/boot/netboot, and can be run from an
-MSDOS system or burned into an EPROM.  Local swapping is also
-possible.  WD, SMC, 3COM and Novell ethernet cards are currently
-supported.
-
-Owner:			Martin Renters & phk
-Sources involved:	i386/boot/netboot, sys/nfs/nfs_vfsops.h
-
-
-Device configuration database
------------------------------
-The kernel now keeps better track of which device drivers are active and
-where the devices are attached; this information is made available to
-user programs via the new sysctl(3) management interface.  Current
-applications include lsdev(8), which lists the currently configured
-devices.  In the future, we expect to use this code to automatically
-generate a configuration file for you at installation time.
-
-Owner:			wollman
-Sources involved:	sys/i386, sys/scsi, sys/kern/kern_devconf.c,
-			sys/sys/devconf.h, usr.sbin/lsdev
-
-
-Kernel management interface
----------------------------
-With 4.4-Lite, we now have a better management interface for the endless
-series of kernel variables and parameters which were previously manipulated
-by reading and writing /dev/kmem.  Many programs have been rewritten to
-use this interface, although many old-style programs still remain.  Some
-variables which were never accessible before are now available through
-the sysctl(1) program.  In addition to the standard 4.4BSD MIB variables,
-we have added support for YP/NIS domains (kern.domainname), controlling
-the update daemon (kern.update), retrieving the OS release date
-(kern.osreldate), determining the name of the booted kernel (kern.bootfile),
-and checking for hardware floating-point support (hw.floatingpoint).
-We have also added support to make management queries of devices and
-filesystems.
-
-Owner:			core
-Sources involved:	sys, usr.bin/sysctl
-
-
-iBCS2 support
--------------
-FreeBSD now supports running iBCS2 compatible binaries (currently
-SCO UNIX 3.2.2 & 3.2.4 and ISC 2.2 COFF format are supported).
-The iBCS2 emulator is in its early stages, but it is functional, we
-haven't been able to do exhaustive testing (lack of commercial apps),
-but almost all of SCO's 3.2.2 binaries are working, so is an old
-INFORMIX-2.10 for SCO. Further testing is nessesary to complete this
-project. There is also work under way for ELF & XOUT loaders, and
-most of the svr4 syscall wrappers have been written.
-
-Owner:			Soren Schmidt (sos) & Sean Eric Fagan (sef)
-Sources involved:	sys/i386/ibcs2/* + misc kernel changes.
-
-
-2. Supported Configurations
----------------------------
-
-FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus
-based PC's, ranging from 386sx to Pentium class machines (though the
-386sx is not recommended).  Support for generic IDE or ESDI drive
-configurations, various SCSI controller, network and serial cards is
-also provided.
-
-Following is a list of all currently known disk controllers and
-ethernet cards known to work with FreeBSD.  Other configurations may
-very well work, and we have simply not received any indication of
-this.
-
-
-2.1. Disk Controllers
-
-WD1003 (any generic MFM/RLL)
-WD1007 (any generic IDE/ESDI)
-[Note: the new Extended IDE controllers in newer PC's work, although no
-extended features are used.]
-
-Adaptec 152x series ISA SCSI controllers
-Adaptec 154x series ISA SCSI controllers
-Adaptec 174x series EISA SCSI controller in standard and enhanced mode.
-Adaptec 2742/2842 series ISA/EISA SCSI controllers
-Adaptec AIC-6260 and AIC-6360 based boards, which includes
-the AHA-152x and SoundBlaster SCSI cards.
-
-** Note: You cannot boot from the Soundblaster cards
-as they have no on-board BIOS, which is necessary for mapping
-the boot device into the system BIOS I/O vectors.
-They're perfectly usable for external tapes, CDROMs, etc,
-however.  The same goes for any other AIC-6x60 based card
-without a boot ROM.  Some systems DO have a boot ROM, which
-is generally indicated by some sort of message when the system
-is first powered up or reset.  Check your system/board documentation
-for more details.
-
-[Note that Buslogic was formerly known as "Bustec"]
-Buslogic 545S & 545c
-Buslogic 445S/445c VLB SCSI controller
-Buslogic 742A, 747S, 747c EISA SCSI controller.
-Buslogic 946c PCI SCSI controller
-
-NCR 53C810 and 53C825 PCI SCSI controller.
-
-DTC 3290 EISA SCSI controller in 1542 emulation mode.
-
-UltraStor 14F, 24F and 34F SCSI controllers.
-
-Seagate ST01/02 SCSI controllers.
-
-Future Domain 8xx/950 series SCSI controllers.
-
-With all supported SCSI controllers, full support is provided for
-SCSI-I & SCSI-II peripherals, including Disks, tape drives (including
-DAT) and CD ROM drives.  Note: This and the mcd driver (Mitsumi CDROM
-interface card) are the only way a CD ROM drive may be currently
-attached to a FreeBSD system; we do not support SoundBlaster
-(non-SCSI) CDROM interface, or other "non-SCSI" adapters.  The
-ProAudio Spectrum SCSI and SoundBlaster SCSI controllers are
-supported.
-
-Some controllers have limitations with the way they deal with >16MB of
-memory, due to the fact that the ISA bus only has a DMA address space of
-24 bits.  If you do your arithmetic, you'll see that this makes it
-impossible to do direct DMA to any address >16MB.  This limitation is
-even true of some EISA controllers (which are normally 32 bit) when
-they're configured to emulate an ISA card, which they then do in *all*
-respects.  This problem is avoided entirely by IDE controllers (which do
-not use DMA), true EISA controllers (like the UltraStor or Adaptec
-1742A) and most VLB (local bus) controllers.  In the cases where it's
-necessary, the system will use "bounce buffers" to talk to the
-controller so that you can still use more than 16Mb of memory without
-difficulty.
-
-
-2.2. Ethernet cards
-
-SMC Elite 16 WD8013 ethernet interface, and most other WD8003E,
-WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT
-based clones.  SMC Elite Ultra is also supported.
-
-DEC EtherWORKS III NICs (DE203, DE204, and DE205)
-DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422)
-
-Isolan AT 4141-0 (16 bit)
-Isolink 4110     (8 bit)
-
-Novell NE1000, NE2000, and NE2100 ethernet interface.
-
-3Com 3C501 cards
-
-3Com 3C503 Etherlink II
-
-3Com 3C507 Etherlink 16/TP
-
-3Com 3C509 and 3C579 Etherlink III
-
-Toshiba ethernet cards
-
-PCMCIA ethernet cards from IBM and National Semiconductor are also
-supported.
-
-2.3. Misc
-
-AST 4 port serial card using shared IRQ.
-
-ARNET 8 port serial card using shared IRQ.
-
-BOCA ATIO66 6 port serial card using shared IRQ.
-
-STB 4 port card using shared IRQ.
-
-Mitsumi (all models) CDROM interface and drive.
-
-Soundblaster SCSI and ProAudio Spectrum SCSI CDROM interface and drive.
-
-Adlib, Soundblaster, Soundblaster Pro, ProAudioSpectrum, Gravis UltraSound
-and Roland MPU-401 sound cards.
-
-FreeBSD currently does NOT support IBM's microchannel (MCA) bus, but
-support is apparently close to materializing.  Details will be posted
-as the situation develops.
-
-
-3. Obtaining FreeBSD.
----------------------
-
-You may obtain FreeBSD in a variety of ways:
-
-1. FTP/Mail
-
-You can ftp FreeBSD and any or all of its optional packages from
-`freebsd.cdrom.com' - the offical FreeBSD release site.
-
-For other locations that mirror the FreeBSD software see the file
-MIRROR.SITES.  Please ftp the distribution from the nearest site
-to you netwise.
-
-If you do not have access to the internet and electronic mail is your
-only recourse, then you may still fetch the files by sending mail to
-`ftpmail@decwrl.dec.com' - putting the keyword "help" in your message
-to get more information on how to fetch files from freebsd.cdrom.com.
-Note: This approach will end up sending many *tens of megabytes*
-through the mail, and should only be employed as an absolute LAST
-resort!
-
-
-2. CDROM
-
-FreeBSD 2.0 may be ordered on CDROM from:
-
-	Walnut Creek CDROM
-	4041 Pike Lane, Suite D
-	Concord CA  94520
-	1-800-786-9907, +1-510-674-0783, +1-510-674-0821 (fax)
-
-Or via the internet from orders@cdrom.com.  Their current catalog can
-be obtained via ftp as ftp.cdrom.com:/cdrom/catalog.
-
-Cost is $39.95.  Shipping (per order not per disc) is $5 in the US, Canada,
-or Mexico and $10.00 overseas.  They accept Visa, Mastercard, American
-Express, and ship COD to the United States.  California residents please
-add 8.25% sales tax.
-
-Should you be dissatisfied for any reason, the CD comes with an
-unconditional return policy.
-
-Note that Walnut Creek CDROM does NOT provide technical support for FreeBSD,
-you need to contact the FreeBSD team for that.  Please see section 5 for
-more information.
-
-
-4. Preparing for the installation.
-----------------------------------
-
-1. Floppy Installation
-
-If you must install from floppy disks, either due to space contraints
-on your hard disk or just because you enjoy doing things the hard
-way, you must first prepare some floppies for the install.
-
-You will need either 10 1.44MB floppies or 12 1.2MB floppies to
-store just the bindist (binary distribution).  These *must* be
-formatted using MS-DOS, using either the FORMAT command in MS-DOS
-or the File Manager in Microsoft Windows to prepare the floppies
-(though factory preformatted floppies will also well well, provided
-that they haven't been previously used for something else).
-
-After you've formatted the floppy disks, you'll need to copy the
-files onto them.  There are 56 total files for the bindist itself,
-plus three small files (CKSUMS, do_cksum.sh, and extract.sh) for
-the install program to use.  ALL of these files must be copies onto
-the floppies.  Each of the bindist files are named "bindist.??",
-where the "??" is replaced by the letter sequence aa through cd.
-Copy these files onto the floppies, placing the three small install
-files onto the final floppy.  The order in which you copy the files
-to floppy is not important, but it makes labelling the disks easier
-if you go in some sort of alphabetical order.
-
-After you've done this, the floppy disks are ready for the install
-program to use.
-
-Later on, after you get the binary distribution installed and everything
-is going great, the same instructions will apply for the other
-distributions, such as the manpages distribution or the XFree86 distribution.
-The number of floppies required will, of course, change for bigger or
-smaller distributions.
-
-
-2. Hard Disk Installation
-
-To prepare for installation from an MS-DOS partition, you should simply
-copy the files from the distribution into a directory with the same
-name as the distribution.  For example, if you are preparing to
-install the bindist set, then make a directory on your C: drive named
-C:\BINDIST and copy the files there.  This will allow the installation
-program to find the files automatically.
-
-
-3. QIC/SCSI Tape Installation.
-
-Installing from tape is probably the easiest method, short of an
-on-line install using ftp or installing from a CDROM.  The installation
-program expects the files to be simply tar'red onto the tape, so after
-getting all of the files for distribution you're interested in, simply
-tar them onto the tape with something like:
-
-	cd <where the *.?? files are>
-	tar cvf /dev/rwt0 (or /dev/rst0) .
-
-from a directory with just the distribution files in it.  Make sure
-that you remember to put CKSUMS, do_cksum.sh, and extract.sh files
-in this directory as well!
-
-If you wish to install multiple *dist releases from one tape, do the
-following:
-
-1. cd to the parent directory of the distributions and put them on tape
-   like so:
-		tar cvf /dev/rwt0 (or /dev/rst0) bindist srcdist ...
-
-2. Install the first distribution on the tape using the tape installation
-   method as normal.  Afterwards, *do not* erase the contents of the temporary
-   directory.  Get a shell with ESC-ESC and cd to the temporary directory
-   yourself.  For each additional *dist you want to load, cd to its
-   subdirectory and type `sh ./extract.sh'.
-
-
-5. Reporting problems, making suggestions, submitting code.
------------------------------------------------------------
-
-Your suggestions, bug reports and contributions of code are always
-valued - please do not hesitate to report any problems you may find
-(preferably with a fix attached if you can!).
-
-The preferred method to submit bug reports from a machine with internet
-mail connectivity is to use the send-pr command.  Bug reports will be
-dutifully filed by our faithful bugfiler program and you can be sure
-that we'll do our best to respond to all reported bugs as soon as
-possible.
-
-If, for some reason, you are unable to use the send-pr command to
-submit a bug report, you can try to send it to:
-
-		bugs@FreeBSD.org
-
-
-Otherwise, for any questions or suggestions, please send mail to:
-
-		questions@FreeBSD.org
-
-Additionally, being a volunteer effort, we are always happy to have
-extra hands willing to help - there are already far more enhancements
-to be done than we can ever manage to do by ourselves!  To contact us
-on technical matters, or with offers of help, you may send mail to:
-
-		hackers@FreeBSD.org
-
-Since these mailing lists can experience significant amounts of
-traffic, if you've got slow or expensive mail access and you're
-only interested in keeping up with significant FreeBSD events, you may
-find it preferable to subscribe to:
-
-		announce@FreeBSD.org
-
-
-All but the FreeBSD-bugs groups can be freely joined by anyone wishing
-to do so.  Send mail to MajorDomo@FreeBSD.org and include the keyword
-`help' on a line by itself somewhere in the body of the message.  This
-will give you more information on joining the various lists, accessing
-archives, etc.  There are a number of mailing lists targeted at
-special interest groups not mentioned here, so send mail to majordomo
-and ask about them!
-
-
-6. Acknowledgements
--------------------
-
-FreeBSD represents the cumulative work of many dozens, if not
-hundreds, of individuals from around the world who have worked very
-hard to bring you this release.  It would be very difficult, if not
-impossible, to enumerate everyone who's contributed to FreeBSD, but
-nonetheless we shall try (in alphabetical order, of course). If your
-name is not mentioned, please be assured that its omission is entirely
-accidental.
-
-
-The Computer Systems Research Group (CSRG), U.C. Berkeley.
-
-Bill Jolitz, for his extensive work with 386BSD.
-
-The FreeBSD "core" team:
-
-	Andrey A. Chernov
-	John Dyson
-	Bruce Evans
-	David Greenman
-	Rodney W. Grimes
-	Jordan K. Hubbard
-	Poul-Henning Kamp
-	Rich Murphey
-	Gary Palmer
-	Geoff Rehmet
-	Paul Richards
-	Soren Schmidt
-	Andreas Schulz
-	Jack Vogel
-	Garrett A. Wollman
-
-
-Special mention to:
-
-	Robert Bruce and Jack Velte of Walnut Creek CDROM, without
-	whose help (and continuing support) this release would never
-	have been possible.
-
-	Dermot McDonnell for his donation of a Toshiba XM3401B CDROM
-	drive.
-
-	The NetBSD group for their frequent assistance and commentary.
-
-	Additional FreeBSD helpers and beta testers:
-
-	J.T. Conklin				Julian Elischer
-	Sean Eric Fagan				Jeffrey Hsu
-	Terry Lambert				L Jonas Olsson
-	Chris Provenzano 			Dave Rivers
-	Guido van Rooij				Steven Wallace
-	Atsushi Murai				Scott Mace
-	Andrew Moore				Nate Williams
-
-	And everyone at Montana State University for their initial support.
-
-
-Thanks to everyone, especially those not mentioned, and we sincerely
-hope you enjoy this release of FreeBSD!
-
-
-			The FreeBSD Core Team
-
-$Id: RELNOTES.FreeBSD,v 1.22 1995/01/27 23:15:31 jkh Exp $
diff --git a/share/FAQ/Slip.FAQ b/share/FAQ/Slip.FAQ
deleted file mode 100644
index 1135c1f..0000000
--- a/share/FAQ/Slip.FAQ
+++ /dev/null
@@ -1,190 +0,0 @@
-***********************************************************************
-***                 How to Set Up SLIP on FreeBSD                   ***
-***********************************************************************
-
-Updated for 1.1.5(.1) support by Satoshi Asami, 8/6/94.
-
-The following is I (asami) set up my FreeBSD machine for SLIP on a
-static host network.  For dynamic hostname assignments (i.e., your
-address changes each time you dial up), you probably need to do
-something much fancier.
-
-This is just "what I did, and it worked for me".  I'm sharing this
-just for your reference, I'm no expert in SLIP nor networking so your
-mileage may vary.
-
-Note: for 1.1 systems (not 1.1.5), you need to use /dev/tty01 instead
-of /dev/cua01. substitute all the occurences of "cua" in this document
-with "tty".
-
-Note: the default 1.1.5(.1) system only comes with cua/ttyd pairs for
-the last two ports (2 and 3), so if your modem is at sio0/sio1
-(COM1/COM2), you need to make the devices.  Try "cd /dev; sh MAKEDEV
-cua01" to make the new special files for sio1 (ditto for sio0).  This
-will delete tty01, but you shouldn't need it anymore...or you can make
-a symbolic link /dev/tty01 -> ttyd1 if you don't want to hunt down all
-occurences of tty01 in your setup files.
-
-I actually have a symbolic link /dev/modem -> cua01 (and /dev/mouse ->
-ttyd0). I use only the modem/mouse names in my configuration files.
-This helped a lot when I switched from 1.1 to 1.1.5.1 (tty01 => cua01)
-and when I had to move my modem temporarily to sio2 to enable the
-RS-232C port on the serial card.  It can become quite cumbersome when
-you need to fix a bunch of files in /etc and .kermrc's all over the
-system!
-
-First, make sure you have
-
-pseudo-device   sl      2
-
-in your kernel's config file.  It is included in the GENERIC, GENERICAH
-and GENERICBT kernels, so this won't be a problem unless you deleted it.
-
-Things you have to do only once:
-
-(1) Add your home machine, the gateway and nameservers to your
-    /etc/hosts file.  Mine looks like this:
-
-127.0.0.1               localhost loghost
-136.152.64.181          silvia.HIP.Berkeley.EDU silvia.HIP silvia
-
-136.152.64.1            inr-3.Berkeley.EDU inr-3 slip-gateway
-128.32.136.9            ns1.Berkeley.edu ns1
-128.32.136.12           ns2.Berkeley.edu ns2
-
-    By the way, silvia is the name of the car that I had when I was
-    back in Japan (it's called 2?0SX here in U.S.).
-
-(2) Make sure you have "hosts" before "bind" in your /etc/host.conf.
-    Otherwise, funny things may happen.
-
-(3) Edit the /etc/netstart and add this to the end of the file:
-
-# set up slip
-gateway=slip-gateway
-ifconfig sl0 inet $hostname $gateway netmask 0xffffff00
-route add default $gateway
-
-    Note that because of the "slip-gateway" entry in /etc/hosts, there
-    is no local dependency in the netstart file.  Also, you might want
-    to un-comment the "route add $hostname localhost" line.
-
-(3') Make a file /etc/resolv.conf which contains:
-
-domain HIP.Berkeley.EDU
-nameserver 128.32.136.9
-nameserver 128.32.136.12
-
-    As you can see, these set up the nameserver hosts.  Of course, the
-    actual addresses depend on your environment.
-
-(4) Set the password for root and toor (and any other accounts that
-    doesn't have a password).  Use passwd, don't edit the passwd or
-    passwd.master files!
-
-(5) Edit /etc/myname and reboot the machine.
-
-How to set up the connection:
-
-(6) Dial up, type "slip" at the prompt, enter your machine name and
-    password.  The things you need to enter depends on your
-    environment.  I use kermit, with a script like this:
-
-# kermit setup
-set modem hayes
-set line /dev/cua01
-set speed 57600
-set parity none
-set flow rts/cts
-set terminal bytesize 8
-set file type binary
-# The next macro will dial up and login
-define slip dial 643-9600, input 10 =>, if failure stop, -
-output slip\x0d, input 10 Username:, if failure stop, -
-output silvia\x0d, input 10 Password:, if failure stop, -
-output ***\x0d, echo \x0aCONNECTED\x0a
-
-    (of course, you have to change the hostname and password to fit
-    yours).  Then you can just type "slip" from the kermit prompt to
-    get connected.
-
-    Note: leaving your password in plain text anywhere in the
-    filesystem is generally a BAD idea.  Do it at your own risk.  I'm
-    just too lazy.
-
-    Note: If you have an 1.1 machine, and kermit doesn't give you a
-    prompt, try "stty -f /dev/tty01 clocal".  I put this in
-    /etc/rc.local so that it works the first time I boot the machine.
-    This doesn't apply to 1.1.5(.1) systems, as cua0? are already
-    configured for dialouts.
-
-(7) Leave the kermit there (you can suspend it by "z") and as root,
-    type
-
-slattach -h -c -s 57600 /dev/cua01
-
-    if you are able to "ping" hosts on campus, you are connected!
-
-    If it doesn't work, you might want to try "-a" instead of "-c".
-
-(8) Happy slipping!
-
-How to shutdown the connection:
-
-(9) Type "ps gx" (as root) to find out the PID of slattach, and use
-    "kill -INT" to kill it.
-
-    Then go back to kermit ("fg" if you suspended it) and exit from it
-    ("q").
-
-    The slattach man page says you have to use "ifconfig sl0 down" to
-    mark the interface down, but this doesn't seem to make any
-    difference for me.  ("ifconfig sl0" reports the same thing.)
-
-    Some times, your modem might refuse to drop the carrier (mine
-    often does).  In that case, simply start kermit and quit it again.
-    It usually goes out on the second try.
-
-    When you want to connect again, go back to (6).  You may have to
-    watch out for clocal mode.  If "stty -f /dev/tty01" doesn't tell
-    you it's clocal, you need to re-set it before kermitting.  Again,
-    this is only for 1.1 machines.
-
-TROUBLESHOOTING:
-
-If it doesn't work, feel free to ask me.  The things that people
-tripped over so far:
-
-* Not using "-c" or "-a" in slattach (I have no idea why this can be
-  fatal, but adding this flag solved the problem for at least one
-  person)
-
-* Using "s10" instead of "sl0" (might be hard to see the difference on
-  some fonts :)
-
-Try "ifconfig sl0" to see your interface status.  I get:
-
-silvia# ifconfig sl0
-sl0: flags=10<POINTOPOINT>
-        inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00
-
-Also, "netstat -r" will give the routing table, in case you get the
-"no route to host" messages from ping.  Mine looks like:
-
-silvia# netstat -r
-Routing tables
-Destination      Gateway            Flags     Refs     Use  IfaceMTU    Rtt   
-Netmasks:
-(root node)
-(root node)
-
-Route Tree for Protocol Family inet:
-(root node) =>
-default          inr-3.Berkeley.EDU UG          8   224515  sl0 -      -     
-localhost.Berkel localhost.Berkeley UH          5    42127  lo0 -       0.438
-inr-3.Berkeley.E silvia.HIP.Berkele UH          1        0  sl0 -      -     
-silvia.HIP.Berke localhost.Berkeley UGH        34 47641234  lo0 -       0.438
-(root node)
-
-(this is after transferring a bunch of files, your numbers should be
-smaller).
diff --git a/share/FAQ/Systems-1.1.FAQ b/share/FAQ/Systems-1.1.FAQ
deleted file mode 100644
index ff3b1c8..0000000
--- a/share/FAQ/Systems-1.1.FAQ
+++ /dev/null
@@ -1,266 +0,0 @@
-                                  Systems FAQ
-                                  For FreeBSD
- Last Modified: $Id: Systems.FAQ,v 1.1 1994/09/11 10:56:04 jkh Exp $
-
-This FAQ is a list of systems that people have sent to the FAQ maintnance
-person for inclusion.  If you have a system you would like to be included
-please send it to FreeBSD-FAQ@freefall.cdrom.com.  
-
-Disclaimer:  This document is composed of systems that people have sent to
-the FAQ maintnance person.  It is the not to be taken as an endorsement
-for any system or manufacture.
-
-
-1.
-
-386DX/20 real AMI, ISA
-Oak SVGA (no X)
-8MB
-Adaptec 1542B, WD1007V ESDI
-Wren VI and Miniscribe 660MB 20Mbit/sec ESDI
-WD 8013EBT
-
-2.
-
-486DX/25 clone, AMI BIOS, ISA
-Orchid PCIII gas plasma (yes, VGA16)
-8MB
-Adaptec 1542B
-Micropolis 1684 SCSI 
-SMC 8013EEWC
-
-3.
-
- ??? OPTI chipset AMI BIOS 486/50 ISA
-ISA ET4000 w/ X11 (not so slow)
-16 Mb - 48 Mb swap
-ISA aha1542 B
-ISA no-name IDE w/ floppies
-FUJITSU M2623S-512 405MB  set to SCSI2
-SEAGATE ST3283N    237MB  SCSI2 
-SANYO   CRD-400I   SCSI2 cdromcdrom
-
-4.
-
-Lipizzan LDO-1 486DX-33 motherboard
-Orchid ProIIs (1M) video
-8 MB memory
-Generic 2S/1P/2FD/IDE controller:
-Maxtor 7213 AT
-WDC AC2420H
-PAS-16 + Sony CDU31A CD drive (Fusion 16 package).
-	*** The CD drive does not currently work with FreeBSD.
-
-5.
-
-Asus VL/ISA-486SV2 (ISA-VLB as you can see)
-Orchid Fahrenheit 1280+ VLB (yes)
-20MB
-Some no-name IDE VLB controller
-Conner CP30504 (I think....the 540MB IDE one)
-Zoltrix 14.4/14.4 Fax/Modem on tty01
-Intel 486DX2/66 CPU + fan
-Conner CP30104 (120MB....for DOS)
-
-6.
-
-AIR 486El (running with AMD486/40)
-ATI Graphics Ultra Pro running XFree862.1
-16M
-Adaptec 1742
-Micropolis 2217
-Wangtec 6130FS DAT drive (Some problems)
-
-7.
-
-Compudyne 486 DX2/66
-ATI Local Bus GUP w/ 2megs
-16 Megs Memory
-504 IDE Hard Drive
-Colorado 250 meg QIC-80 tape drive
-
-8.
-
-American Megatrends Enterprise III, 486DX2-66
-ATI VLB Mach 32 (with X)
-16 meg
-Adaptec 1742 EISA SCSI with floppy
-Toshiba 5030 SCSI-II
-Toshiba 5157 SCSI-II
-SMC Elite16T ISA Ethernet (ISA)
-
-9.
-
-American Megatrends Enterprise III, 486DX
-ATI VLB Mach 32 (with X)
-32 meg
-Adaptec 1742 EISA SCSI with floppy
-Maxtor P0-12S SCSI
-Digital DSP5200S SCSI-II
-Pro Audio Spectrum 16
-Wonder Board, 4 serial (16550), 3 parallel, each on a different interrupt
-
-10.
-
-NoName 486DX/33, Intel Chipset, EISA-Bus
-ATI Graphics Ultra Pro EISA,
-17"  Nanao (Eizo) F550-i Monitor
-Running the Mach32 X-Server XFree86-2.1.1 with fonts created from source.
-16 MB RAM (planning to add another 8 MB).
-AHA1742A
-Conner CP3100
-Fujitsu 520 MB
-Archive 525MB streamer tape.
-Gravis UltraSound - works for mod-files.
-
-11.
-
-ASUS SP3 PCI Board with i486 DX/2 66 MHz
-ISA ET4000 (I already tested a S3 805 PCI card successfully)
-Adaptec 1542B
-Toshiba XM3301TA CD-Rom
-CDC Harddisk, 572 MB (I don't know the exact specs)
-
-12.
-
-Mylex MAE486/33 EISA Motherboard
-16MB memory
-Actix GE32+ S3 801 gfx
-Adaptec 1742A controller
-Seagate ST3160 drive
-Seagate ST5120 drive
-Archive Viper 150MB tape
-Roland SCC-1 sound card
-Gravis Ultrasound card
-Longshine SMC/Novell compatable ethernet card
-
-13.
-
-Model:	DECpc LPv 466d2
-Config: Local (Motherboard) S3 801 gfx, IDE controller, PS/2 mouse, 12MB memory
-
-14.
-
-
-??? 486/DX266 EISA/VLB Motherboard
-16MB memory
-#9 GXE L12 VLB 3MB graphics card
-Bt445S VLB disk controller
-DEC DSP3105S drive
-MAXSTOR P-17S drive
-Tandberg 525MB tape drive
-Toshiba XM3301 CDROM
-Soundblaster 2.0
-Longshine SMC/Novell compatable ethernet card
-
-15.
-
-M407 PC chips with 33Mhz 486.
-Had to disable external cache due to DMA problems. Board uses write-through
-cache unless a second chip is added to allow write-back.write-back.
-Orchid ProDesigner II (yes)
-16Mb
-IDE
-Maxtor 7213 AT and Maxtor 7120 AT
-2 BICC Isolans (Lance based cards)
-
-16.
-
-Gigabyte EISA/VLB motherboard with SIS chipset, AMI bios, 32 MB ram
-Adaptec 1742 SCSI 2 controller with floppy controller enabled
-Spea/V7 Mirage - S3/805 based localbus graphics card with 1 MB d-ram
-no name wd8013 compatible ethernet card
-Gravis Ultrasound card with 1 MB ram
-2 Fujitsu 400 MB and 1 Seagate 500 MB SCSI 2 harddisks
-5 1/4 + 3 1/2 inch floppy drives
-Tandberg TDC3600 60 MB + Tandberg TDC3800 525 MB Streamer (these don't work
-quite properly yet)
-
-17.
-
-i486DX33, 16 Mb RAM, 256 Kb external cache, VLB board
-no-name IDE/floppy controller
-Western Digital Caviar 2340 (325 Mb)
-Kalok KL-343 (40 Mb)
-Chips & Technologies 451 SuperVGA card (800x600, 16 colours, 256Kb)
-
-18.
-
-no name EISA i486DX/33 board, 16 MB RAM
-Adaptec AHA-1540*A*  (not knowing if the current -current might cause
-  problems, my kernel is from end of march)
-Maxtor MXT-1240S, 1.2Gig very fast SCSI disk
-Seagate ST-1144A, just to boot off the beast (also has a messdos partition yet)
-Archive Viper 150 tape; has a firmware braindeadness when appending files,
-  works very well otherwise
-ELSA Winner 1000 ISA/EISA, 1MB VRAM, S3 86C928 (unfortunately, D-step chip)
-Nokia 447-B 17in monitor, running ~ 1100x800 resolution, very nice
-true `Mouse Systems' optical mouse, fine thing!
-sometimes a Toshiba XM-3301 CDROM, rather old, but solid & reliable
-
-19.
-
-older south-east Asia made notebook, i386SX/16, 5 MB RAM (where the 384 k hole
-  can be re-mapped, so all the 5 MB are useable)
-Seagate ST-9145AG, 120 MB 2.5in IDE disk, very low power consumption, but
-  rather slow transfer rate, only about 350 K/s, so paging is a mess
-640x480 LCD, ~ 16 gray tones distinguishable, Cirrus Logic CL-GD610/620
-  chipset; runs generic VGA-Mono and VGA-16 XFree86[tm] servers; needs
-  some hacks in rc.local to give full contrast when running with the
-  pcvt display driver (due to their different default attribute handling)
-
-
-20.
-
-Data General Dasher 386sx/16, 8 MB RAM
-Adaptec AHA-1542B
-Seagate ST-3655N, 525 MB SCSI disk
-Conner CP-3044, 40 MB IDE disk
-has been working with a Western Digital WD-1007V ESDI controller (on
-  secondary wdc address), and a Micropolis 1664-7 330 MB ESDI disk -
-  but this beast was terribly slow, loud (& unreliable) and therefore
-  had to go
-ET-3000 based 512 K VGA, slow (wrt. XFree86), but reliable
-3Com 3C503 Ethernet adaptor, suffers from the `do not nfs mount with
-  too large packets' problem, but works well otherwise
-`Mouse Systems' optical mouse
-Toshiba XM-3301 CDROM
-already ran with a Micropolis 1664-3 330 MB SCSI disk (same drive as
-  above, but different interface)
-already ran with an IBM 2Gig SCSI disk (don't remember the type)
-
-
-21.
-
-Mylex MNA 486/33 EISA Motherboard
-16Mb of Memory
-1.2 GB Toshiba 538 SCSI disk
-400Mb IBM SCSI disk
-150/250Mb Tandberg SCSI tape drive
-Toshiba 3401 SCSI CD-ROM
-Tseng 4000 Video Controller
-Logitech Bus Mouse
-Mediavision Pro Audio Stereo Sound Card
-Adaptech 1742A SCSI controller
-WD8013EBT Ethernet Card
-
-22.
-
-386DX-40 w/Cyrix math co-processor
-ET-4000 running X
-16MB
-IDE
-540MB Western Digital
-WD8003EP
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/share/FAQ/Systems.FAQ b/share/FAQ/Systems.FAQ
deleted file mode 100644
index ad1715e..0000000
--- a/share/FAQ/Systems.FAQ
+++ /dev/null
@@ -1,59 +0,0 @@
-
-                               Systems FAQ
-                             for FreeBSD 2.0
-
-This FAQ lists systems (and componets) known to work with FreeBSD 2.0.  None
-of these lists should be seen as a recomandation for a manufacture.
-
-Revision: $Id: Systems.FAQ,v 1.5 1994/09/16 18:51:50 gclarkii Exp $
-
-
-i386:
-
-
-Motherboard: Magitronics 386DX-40
-CPU: i386DX-40
-Busses: ISA and VLB (VLB not tested)
-Ram: 20 Megs
-Video: Generic 1MB Tseng 4000 (ISA)
-Disks:
-	2 - Segate ST1126 (SCSI)
-	1 - Seagate ST1480 (SCSI)
-	1 - Toshiba MK-234FC-C (IDE)
-Controllers:
-	Generic IDE
-	Adaptec AH-1542CF
-
-Motherboard: Magitronics 386SX-40
-CPU: i386SX-40
-Busses: ISA
-Ram: 4 Megs
-Video: Monochrome
-Disks:
-	1-Seagate ST1126 (SCSI)
-Controllers:
-	Future Domain 850
-Notes: Slow but useable
-
-i486:
-
-Motherboard:  Gateway 2000 Handbook 486 HB486DX2-40
-CPU: i486SL DX2/40
-BUS(S): PCMCIA, one type II
-Video Card: Monochrome VGA.
-Are you running X on this?: no, havn't really tried.
-Types of Disks (manufacture and bus): 130Mb builtin.  <Areal A130 U>
-If you wish to be credited: Poul-Henning Kamp phk@freefall.cdrom.com
-
-NOTES:
-This is a 3 pound portable.  Runs perfect.  Suspend works great.  Has one
-serial and one parallel/floppy port, which can drive either a floppy or
-a parallel port, but not at the same time.  Builtin "EZ" mouse-thinge.
-Highly recommended for people on the road.
-
-
-Credits:
-	FreeBSD Core Team
-	Gary Clark II
-	Poul-Henning Kamp
-
diff --git a/share/FAQ/TROUBLESHOOTING b/share/FAQ/TROUBLESHOOTING
deleted file mode 100644
index d1cb25f..0000000
--- a/share/FAQ/TROUBLESHOOTING
+++ /dev/null
@@ -1,185 +0,0 @@
-Troubleshooting Tips - or "These are the times that try men's souls"
---------------------------------------------------------------------
-
-The following tips and tricks may help you turn a failing (or failed)
-installation attempt into a success.  Please read them carefully.
-
----
-
-Symptom:	Hardware conflict or misconfiguration.
-		Device not being found when it should be.
-
-Problem:	A device is conflicting with another, or its settings
-		don't match the kernel's expected IRQ or address.
-
-Explanation:	While most device drivers in FreeBSD are now smart
-		enough to match themselves to your hardware settings
-		dynamically, there are a few that still require fairly
-		rigid configuration parameters to be compiled in (and
-		matched by the hardware) before they'll work.  We're
-		working hard to eliminate as many of these last
-		hold-outs as we can, but it's not always as easy as
-		it looks.
-
-Solution:	There are several possible solutions.  The first,
-		and easiest, is to boot the kernel with the -c flag.
-		When you see the initial boot prompt (from floppy or
-		hard disk), type:
-
-			/kernel -c
-
-		This will boot just past the memory sizing code and
-		then drop into a dynamic kernel configuration utility.
-		Type `?' at the prompt to see a list of commands.  You
-		can use this utility to reset the IRQ, memory address,
-		IO address or a number of other device configuration
-		parameters.  You can also disable a device entirely
-		if it's causing problems for other devices you'd much
-		rather have work.  Note that this only affects the
-		kernel being booted temporarily, it does not "write out"
-		the information to the kernel so that these settings
-		are permanantly altered (this would be actually rather
-		hard).  If you reboot, you'll have to make the same
-		changes again.  The goal of the -c utility is to get
-		you up far enough to be able to download the appropriate
-		sources and configure and rebuild a kernel more specific
-		to your needs.
-
-		Another solution is, obviously, to remove the offending
-		hardware or simply strip the system down to the bare
-		essentials until the problem (hopefully) goes away.
-		Once you're up, you can do the same thing mentioned
-		above - compile a kernel more suited to your hardware,
-		or incrementally try to figure out what it was about
-		your original hardware configuration that didn't work.
-
----
-Symptom:       	My floppy-tape drive isn't probed.
-
-Problem:	Last-minute problems with this driver caused it to be disabled
-		by default.
-
-Solution:       Boot with -c (described above) and set the flags value of
-                fdc0 to 1. This will re-enable the floppy tape driver.
-                Sorry, but it was causing problems for people without floppy
-		tape drives!
----
-
-Symptom:	When I boot for the first time, it still looks for /386bsd!
-
-Problem:	You still have the old FreeBSD 1.x boot blocks on your
-		boot partition.
-
-Solution:	You should re-enter the installation process, invoke
-		the (F)disk editor and chose the (W)rite option.  This
-		won't hurt an existing installation and will make sure
-		that the new boot blocks get written to the drive.
-		If you're installing for the first time, don't forget
-		to (W)rite out your new boot blocks! :-)
-
----
-
-Symptom:	I want to boot FreeBSD off the second drive.  It doesn't!
-
-Problem:	FreeBSD will actually install just fine on a drive other
-		than 0 (the first drive), and the boot manager will even
-		allow you to select it, but the boot blocks rather
-		pathologically assume 0.  This should be fixed in 2.1.
-
-Solution:	Easy - follow these steps:
-
-		1.  Select the first (0) drive from the (F)disk editor
-		    and write out the boot manager with the (B) option.
-		    This will enable the boot manager that allows you to
-		    actually boot off the other drive.
-
-		2.  Exit the fdisk editor for the first drive and and
-		    re-enter it again for the drive you wish to install
-		    on.  Set up a partition on this drive, or select
-		    (A)ll for the entire drive.
-
-		3.  Enter the disklabel editor and allocate space on
-		    your second drive as normal.  Proceed with the
-		    installation.
-
-		4.  Once you've installed on the disk and are going to
-		    reboot from the hard disk, enter the following at
-		    the boot prompt:
-
-				wd(1,a)/kernel
-
-		    [ If you're using a SCSI drive, substitute
-		      `sd' for `wd' above ]
-
-		    This will ensure that you really boot from the second
-		    drive.  If you've actually installed on a drive other
-		    than 1 (the 3rd or 4th drive?), substitute that number
-		    in for the above.  You will need to enter this EVERY
-		    time you reboot from the hard disk.  If you're feeling
-		    brave and have a srcdist + the requisite experience,
-		    you can hack the boot blocks in:
-
-			/usr/src/sys/i386/boot/biosboot
-
-		    So that this drive you're booting from is hard-coded.
-		    Recompile the boot blocks and reinstall them on your
-		    drive with `disklabel -B ...'  You can then have the
-		    default Do The Right Thing.
----
-
-Symptom:	Newfs crashes, requesting that blocksize be 32K
-
-Problem:	You have your disk controller configured to translate
-		to a some really large cylinder size because you're using
-		a drive with lots of cylinders.
-
-Solution:	Turn such translation OFF in your controller's BIOS
-		setup if you can.  If you must share the disk with other
-		Operating Systems, then this may not be possible and
-		you may simply be unable to install FreeBSD until we have
-		support for large translated geometries, sorry!
-		[ Hopefully in 2.1 ].
-
----
-
-Symptom:	FreeBSD won't boot off the hard disk
-
-Problem:	Root partition does not start and end below cylinder 1024.
-
-Solution:	See solution for newfs crashes, or move your root
-		partition.  This limitation holds true for ANY operating
-		system you wish to boot from your hard drive.
-
----
-
-Symptom:	FreeBSD still won't boot off the hard disk
-
-Problem:	No boot code is installed in sector 1.
-
-Solution:	Chose the Write MBR (B)oot code in the FDISK editor and
-		write out the boot manager so that you have a chance to
-		select operating systems.
-
-		[ ** NOTE:  If you are using the entire disk for FreeBSD, or
-		  you have a Connor drive that does cylinder translation
-		  from the MBR boot code, do NOT chose this option! ** ].
-
----
-Summary:	Nope, FreeBSD's still not booting from the hard disk.
-
-Cause:		BIOS disk geometry different from that used when
-		installing FreeBSD.
-
-Solution:	With IDE drives, pay careful attention to the geometry
-		information that FreeBSD prints out when it's first
-		booting off the floppy.  Use this geometry in your BIOS
-		setup or use the BIOS geometry when you install FreeBSD.
-		Either way, they have to match.
-
-		With SCSI drives, the values they report is most often
-		bogus and cannot be used.  In this situation, the SCSI
-		controller is performing geometry translation and
-		it's probably wise to assume a default of 64 heads,
-		32 sectors and 1MB/cylinder.  Use these values when
-		you install FreeBSD.  See above comments concerning
-		newfs failures for more info.
diff --git a/share/FAQ/Text/CONTRIB.FreeBSD b/share/FAQ/Text/CONTRIB.FreeBSD
deleted file mode 100644
index 16e46b5..0000000
--- a/share/FAQ/Text/CONTRIB.FreeBSD
+++ /dev/null
@@ -1,278 +0,0 @@
-			  FreeBSD 2.0.5
-		         Contributor List
-
-
-
-Derived Software Contributors:
-
-This software was originally derived from William F. Jolitz's 386BSD
-release 0.1, though almost none of the original 386BSD specific code
-remains.  This software has been essentially reimplemented from the
-4.4 BSD Lite release provided by the Computer Science Research Group
-(CSRG) at the University of California, Berkeley and associated academic
-contributors.
-
-There are also portions of NetBSD that have been integrated into FreeBSD
-as well, and we would therefore like to thank all the contributors
-to NetBSD for their work.  Despite some occasionally rocky moments in
-relations between the two groups, we both want essentially the same
-thing:  More BSD based operating systems on people's computers!  We
-wish the NetBSD group every success in their endevors.
-
-
-Hardware Contributors:
-
-A special thank-you to Walnut Creek CDROM for providing the Pentium P5-90
-and 486/DX2-66 EISA/VL systems that are being used for our development work,
-to say nothing of the network access and other donations of hardware
-resources.  It would have been impossible to do this release without
-their support.
-
-TRW Financial Systems, Inc. provided 130 PCs, three 68 GB fileservers, 
-twelve ethernets, two routers and an ATM switch for debugging the diskless
-code.  They also keep a couple of FreeBSD hackers alive and busy.  Thanks!
-
-Thanks also to Dermot McDonnell for his donation of a Toshiba XM3401B CDROM
-drive.  It's been most useful!
-
-Thanks to Chuck Robey (chuckr@eng.umd.edu) who's been contributing his
-floppy tape streamer for experimental work.
-
-
-The FreeBSD Core Team
-(in alphabetical order):
-
-	Andrey A. Chernov <ache@FreeBSD.org>
-	Bruce Evans <bde@FreeBSD.org>
-	David Greenman <davidg@FreeBSD.org>
-	Garrett A. Wollman <wollman@FreeBSD.org>
-	Gary Palmer <gpalmer@FreeBSD.org>
-	Jörg Wunsch <joerg@FreeBSD.org>
-	John Dyson <dyson@FreeBSD.org>
-	Jordan K. Hubbard <jkh@FreeBSD.org>
-	Justin Gibbs <gibbs@FreeBSD.org>
-	Poul-Henning Kamp <phk@FreeBSD.org>
-	Rich Murphey <rich@FreeBSD.org>
-	Rodney W. Grimes <rgrimes@FreeBSD.org>
-	Satoshi Asami <asami@FreeBSD.org>
-	Søren Schmidt <sos@FreeBSD.org>
-
-
-Who's Responsible For What:
-
-	President:		Jordan K. Hubbard <jkh@FreeBSD.org>
-	Principle Architect:	David Greenman <davidg@FreeBSD.org>
-	Documentation:		John Fieber <jfieber@FreeBSD.org>
-	Internationalization:   Andrey A. Chernov <ache@FreeBSD.org>
-	Networking:		Garrett A. Wollman <wollman@FreeBSD.org>
-	Postmaster:		Jonathan M. Bresler <jmb@FreeBSD.org>
-	Public Relations:	Jordan Hubbard <jkh@FreeBSD.org>
-	Release Coordinator:	Jordan Hubbard <jkh@FreeBSD.org>
-	System Administration:	Gary Palmer <gpalmer@FreeBSD.org>
-	WEBMASTERS:		John Fieber <jfieber@FreeBSD.org> and
-				James L. Robinson <jlrobin@FreeBSD.org>
-	XFree86 Project, Inc. Liason:  Rich Murphey <rich@FreeBSD.org>
-
-
-Additional FreeBSD Contributors
-(in alphabetical order by first name, just to be different):
-
-Adam David <adam@veda.is>
-Adam Glass <glass@postgres.berkeley.edu>
-Akito Fujita <fujita@zoo.ncl.omron.co.jp>
-Andras Olah <olah@cs.utwente.nl>
-Andreas Klemm <andreas@knobel.GUN.de>
-Andrew Herbert <andrew@werple.apana.org.au>
-Andrew Moore <alm@FreeBSD.org>
-Anthony Yee-Hang Chan <yeehang@netcom.com>
-Atsushi Murai <amurai@spec.co.jp>
-Bill Fenner <fenner@parc.xerox.com>
-Bill Paul <wpaul@FreeBSD.org>
-Bob Wilcox <bob@obiwan.uucp>
-Brian Tao <taob@gate.sinica.edu.tw>
-Charles Hannum <mycroft@ai.mit.edu>
-Chris G. Demetriou <cgd@postgres.berkeley.edu>
-Chris Provenzano <proven@athena.mit.edu>
-Chris Stenton <jacs@gnome.co.uk>
-Chris Torek <torek@ee.lbl.gov>
-Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at>
-Christoph Robitschko <chmr@edvz.tu-graz.ac.at>
-Chuck Robey <chuckr@Glue.umd.edu>
-Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de>
-Craig Struble <cstruble@vt.edu>
-Curt Mayer <curt@toad.com>
-Danny J. Zerkel <dzerkel@feephi.phofarm.com>
-Dave Burgess <burgess@hrd769.brooks.af.mil>
-Dave Chapeskie <dchapes@zeus.leitch.com>
-Dave Rivers <rivers@ponds.uucp>
-David Dawes <dawes@physics.su.OZ.AU>
-Dean Huxley <dean@fsa.ca>
-Don Whiteside <dwhite@anshar.shadow.net>
-Eric L. Hernes <erich@lodgenet.com>
-Frank Durda IV  <bsdmail@nemesis.lonestar.org>
-Frank Maclachlan <fpm@crash.cts.com>
-Frank Nobis <fn@trinity.radio-do.de>
-Gary A. Browning <gab10@griffcd.amdahl.com>
-Gary Clark II <gclarkii@radon.gbdata.com>
-Gary Jennejohn <gj%pcs.dec.com@inet-gw-1.pa.dec.com>
-Gene Stark <stark@cs.sunysb.edu>
-Guido van Rooij <guido@gvr.win.tue.nl>
-Havard Eidnes <Havard.Eidnes@runit.sintef.no>
-Holger Veit <Holger.Veit@gmd.de>
-Ishii Masahiro, R. Kym Horsell
-J.T. Conklin <jtc@winsey.com>
-James Clark <jjc@jclark.com>
-James da Silva <jds@cs.umd.edu> et al
-Janusz Kokot <janek@gaja.ipan.lublin.pl>
-Javier Martin Rueda <jmrueda@diatel.upm.es>
-Jim Wilson <wilson@moria.cygnus.com>
-Josh MacDonald <jmacd@uclink.berkeley.edu>
-Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de>
-Julian Elischer <julian@dialix.oz.au>
-Julian Stacey <stacey@guug.de> <fallback: <julian@meepmeep.pcs.com>>
-Keith Bostic <bostic@toe.CS.Berkeley.EDU>
-Keith Moore <?>
-Kirk McKusick <mckusick@mckusick.com>
-L Jonas Olsson <ljo@po.cwru.edu>
-Lars Fredriksen <fredriks@mcs.com>
-Lucas James <Lucas.James@ldjpc.apana.org.au>
-Marc Frajola <marc@dev.com>
-Marc Ramirez <mrami@mramirez.sy.yale.edu
-Mark Murray <mark@grondar.za>
-Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu>
-Marc van Kempen <wmbfmk@urc.tue.nl>
-Martin Birgmeier
-Martin Renters <martin@innovus.com>
-Matt Thomas <thomas@lkg.dec.com>
-Michael Smith <msmith@atrad.adelaide.edu.au>
-Nate Williams <nate@FreeBSD.org>
-NIIMI Satoshi <sa2c@and.or.jp>
-Nobuhiro Yasutomi <nobu@@psrc.isac.co.jp>
-Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp>
-Ollivier Robert <roberto@FreeBSD.org>
-Paul Kranenburg <pk@cs.few.eur.nl>
-Paul Mackerras <paulus@cs.anu.edu.au>
-Paul Traina <pst@cisco.com>
-Paul Richards <paul@FreeBSD.org>
-Peter Dufault <dufault@hda.com>
-Peter Wemm <peter@haywire.DIALix.COM>
-Philippe Charnier <charnier@lirmm.fr>
-Rob Shady <rls@id.net>
-Rob Snow <rsnow@txdirect.net>
-Richard Stallman <rms@gnu.ai.mit.edu>
-Sascha Wildner <swildner@channelz.GUN.de>
-Scott Mace <smace@FreeBSD.org>
-Sean Eric Fagan <sef@kithrup.com>
-Serge V. Vakulenko <vak@zebub.msk.su>
-Stefan Esser <se@MI.Uni-Koeln.DE>
-Stephen McKay <syssgm@devetir.qld.gov.au>
-Steve Gerakines <steve2@genesis.tiac.net>
-Steven Wallace <swallace@ece.uci.edu>
-Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp>
-Terry Lee <terry@uivlsi.csl.uiuc.edu>
-Theo Deraadt <deraadt@fsa.ca>
-Thomas Gellekum <thomas@ghpc8.ihf.rwth-aachen.de>
-Tom Samplonius <tom@misery.sdf.com>
-Torbjorn Granlund <tege@matematik.su.se>
-Torsten Blum <torstenb@FreeBSD.ORG>
-Ugen J.S.Antsilevich <ugen@NetVision.net.il>
-Werner Griessl <werner@btp1da.phy.uni-bayreuth.de>
-Wolfgang Stanglmeier <wolf@kintaro.cologne.de>
-Wolfram Schneider <wosch@cs.tu-berlin.de>
-Yuval Yarom <yval@cs.huji.ac.il>
-Yves Fonk <yves@cpcoup5.tn.tudelft.nl>
-
-
-386BSD Patch kit patch contributors (in alphabetical order):
-
-Adam Glass <glass@postgres.berkeley.edu>
-Adrian Hall <adrian@ibmpcug.co.uk>
-Andrey A. Chernov <ache@astral.msk.su>
-Andrew Herbert <andrew@werple.apana.org.au>
-Andrew Moore <alm@netcom.com>
-Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com>
-Arne Henrik Juul <arnej@Lise.Unit.NO>
-Bakul Shah <bvs@bitblocks.com>
-Barry Lustig <barry@ictv.com>
-Bob Wilcox <bob@obiwan.uucp>
-Branko Lankester
-Brett Lymn <blymn@mulga.awadi.com.AU>
-Charles Hannum <mycroft@ai.mit.edu>
-Chris G. Demetriou <cgd@postgres.berkeley.edu>
-Chris Torek <torek@ee.lbl.gov>
-Christoph Robitschko <chmr@edvz.tu-graz.ac.at>
-Daniel Poirot <poirot@aio.jsc.nasa.gov>
-Dave Burgess <burgess@hrd769.brooks.af.mil>
-Dave Rivers <rivers@ponds.uucp>
-David Dawes <dawes@physics.su.OZ.AU>
-David Greenman <davidg@Root.COM>
-Eric J. Haug <ejh@slustl.slu.edu>
-Felix Gaehtgens <felix@escape.vsse.in-berlin.de>
-Frank Maclachlan <fpm@crash.cts.com>
-Gary A. Browning <gab10@griffcd.amdahl.com>
-Geoff Rehmet <csgr@alpha.ru.ac.za>
-Goran Hammarback <goran@astro.uu.se>
-Guido van Rooij <guido@gvr.win.tue.nl>
-Guy Harris <guy@auspex.com>
-Havard Eidnes <Havard.Eidnes@runit.sintef.no>
-Herb Peyerl <hpeyerl@novatel.cuc.ab.ca
-Holger Veit <Holger.Veit@gmd.de>
-Ishii Masahiro, R. Kym Horsell
-J.T. Conklin <jtc@winsey.com>
-Jagane D Sundar < jagane@netcom.com >
-James Clark <jjc@jclark.com>
-James Jegers <jimj@miller.cs.uwm.edu>
-James W. Dolter
-James da Silva <jds@cs.umd.edu> et al
-Jay Fenlason <hack@datacube.com>
-Jim Wilson <wilson@moria.cygnus.com>
-Joerg Lohse <lohse@tech7.informatik.uni-hamburg.de>
-Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de>
-John Dyson - <formerly dyson@ref.tfs.com>
-John Woods <jfw@eddie.mit.edu>
-Jordan K. Hubbard <jkh@whisker.hubbard.ie>
-Julian Elischer <julian@dialix.oz.au>
-Julian Stacey <stacey@guug.de> <fallback: <julian@meepmeep.pcs.com>>
-Karl Lehenbauer <karl@NeoSoft.com> <karl@one.neosoft.com>
-Keith Bostic <bostic@toe.CS.Berkeley.EDU>
-Ken Hughes
-Kent Talarico <kent@shipwreck.tsoft.net>
-Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu> <kml@mosquito.cis.ufl.edu>
-Marc Frajola <marc@dev.com>
-Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu>
-Martin Renters <martin@innovus.com>
-Michael Galassi <nerd@percival.rain.com>
-Mike Durkin <mdurkin@tsoft.sf-bay.org>
-Nate Williams <nate@bsd.coe.montana.edu>
-Nick Handel <nhandel@NeoSoft.com> <nick@madhouse.neosoft.com>
-Pace Willisson <pace@blitz.com>
-Paul Kranenburg <pk@cs.few.eur.nl>
-Paul Mackerras <paulus@cs.anu.edu.au>
-Paul Popelka <paulp@uts.amdahl.com>
-Peter da Silva <peter@NeoSoft.com>
-Phil Sutherland <philsuth@mycroft.dialix.oz.au>
-Ralf Friedl <friedl@informatik.uni-kl.de>
-Rick Macklem <root@snowhite.cis.uoguelph.ca>
-Robert D. Thrush <rd@phoenix.aii.com>
-Rodney W. Grimes <rgrimes@cdrom.com>
-Rog Egge <?>
-Sascha Wildner <swildner@channelz.GUN.de>
-Scott Burris <scott@pita.cns.ucla.edu>
-Scott Reynolds <scott@clmqt.marquette.mi.us>
-Sean Eric Fagan <sef@kithrup.com>
-Simon J Gerraty <sjg@melb.bull.oz.au> <sjg@zen.void.oz.au>
-Stephen McKay <syssgm@devetir.qld.gov.au>
-Terry Lambert <terry@icarus.weber.edu>
-Terry Lee <terry@uivlsi.csl.uiuc.edu>
-Warren Toomey <wkt@csadfa.cs.adfa.oz.au>
-Wiljo Heinen <wiljo@freeside.ki.open.de>
-William Jolitz <withheld>
-Wolfgang Solfrank <ws@tools.de>
-Wolfgang Stanglmeier <wolf@dentaro.GUN.de>
-Yuval Yarom <yval@cs.huji.ac.il>
-
-Last, but not least, the release engineer would like to thank:
-	His Wife, for chocolate chip cookies, and some other things.
-	The DGB project @ TFS, for patience and tolerance.
-
-$Id: CONTRIB.FreeBSD,v 1.23 1995/08/31 15:17:02 jkh Exp $
diff --git a/share/FAQ/Text/ESDI.FAQ b/share/FAQ/Text/ESDI.FAQ
deleted file mode 100644
index 8d86924..0000000
--- a/share/FAQ/Text/ESDI.FAQ
+++ /dev/null
@@ -1,187 +0,0 @@
-                                  FreeBSD
-             Using "Mature Technology" (MFM, ESDI) hard drives
-
-First, please read and make sure that you understand the "diskspace" FAQ.
-
-The term "partition" has become overloaded when referring to an area of a
-hard disk drive.  I will use "slice" in this document to refer to an area
-which is a "partition" to DOS FDISK.  This usage is consistent with most of
-current FreeBSD.  I will use the word "partition" to refer to an area de-
-fined by a FreeBSD disklabel, of which there is one per FreeBSD slice.  The
-FreeBSD partitions may contain filesystems, swap space, or be available as
-raw disk devices to applications.
-
-This document covers the steps you will need to perform before starting the
-FreeBSD installation and which are specific to these types of disk drives.
-
-1 Disk layout planning
-2 Disk installation (may already be done)
-3 Low-level formatting (may or may not be required)
-
-If your drive is installed and formatted properly, careful planning is all
-that you need to do.
-
-During the installation, there is only one special step that is required.
-This is also one place where the FreeBSD taxonomic convention breaks down
--- the assignment of slices is called "Partitioning" in the FreeBSD proce-
-dures at the time of this writing.  During that step, when you assign the
-FDISK slices, be sure to specify that the bad144 lists should be created
-(the "B" command).
-
-1 Disk layout planning
-----------------------
-
-To be able to make the right decisions regarding the setup of slices for
-FreeBSD, you need to understand that the initial boot stages for FreeBSD
-rely on the ROM BIOS, but that the ROM BIOS is not used in any way once the
-FreeBSD kernel is loaded.  After the kernel is loaded, it uses its own
-driver instead of the BIOS to access the disk.
-
-These older disks do not do automatic bad block management.  Some con-
-trollers seem to do so, but this is a feature of the ROM BIOS on that con-
-troller, and therefore is not available once FreeBSD is running.  Other
-controllers use a different method of bad sector handling (slipping), but
-this feature can also induce translations in the sectoring which will pre-
-vent successful installation.  Do not use automatic sector mapping or sec-
-tor slipping, even if it is supported on the controller, for the same rea-
-sons that you cannot use a translated disk geometry.
-
-To be able to use these drives, the driver has to be able to substitute
-good sectors for the bad ones.  The FreeBSD filesystems assume "perfect"
-disks, so the bad sector handling is done in the driver.  The way this is
-done is that a few copies of the list of bad sectors is kept at the end of
-the slice.  When a slice is opened, this list is read and kept in the driv-
-er.  On every access to the drive, the list is consulted to see if a sub-
-stitute sector, also from the end of the slice, must be used rather than
-the sector that the filesystem or application is actually asking for.  This
-list is called the bad144 list, which name comes from a Digital Equipment
-Corporation standard for keeping this information.
-
-There are three reasons that you would be required to use more than one
-FreeBSD slice on your disk, and all of them are more probable the larger
-your drive is.
-
-1)  The FreeBSD portion of your drive will extend beyond cylinder 1023.
-2)  The FreeBSD portion of your drive has (or is likely to have) more than
-    126 bad sectors.
-3)  You need more than 7 filesystems for FreeBSD.
-
-It is not sufficient to make sure that the entire boot filesystem is inside
-of cylinder 1024, unless it just so happens that that filesystem occupies a
-flawless part of the disk.  To be able to read the bad144 list during the
-boot process (via the ROM BIOS), the end of the slice must be within the
-first 1024 cylinders.  There are also some boot managers, e.g. the OS/2
-boot manager, that require a bootable slice to be entirely below cylinder
-1024.
-
-The bad144 data format only allows for 126 sectors to be mapped.  If your
-drive is large, it could easily have more than this many over its entire
-size.  I have a 320 Mb drive which is unusually error-filled, but still
-within acceptable tolerances, and it has this problem (but it also has more
-than 1024 cylinders, so I'd have had to split it, anyway).
-
-The FreeBSD disk label has room for 8 partitions.  It is not recommended
-that filesystems be placed on partitions b or c, even on non-booted slices,
-so that leaves 6 partitions within each slice which may contain filesys-
-tems.  Older versions of FreeBSD did not support filesystems on partition d
-either, but the slice-handling capability has eliminated that restriction.
-It may be best to avoid using partition d if you can for compatibility pur-
-poses.  The installation procedures skip from a to e for this reason.
-
-2 Disk installation
--------------------
-
-Physical installation is outside the scope of this document.  Consult the
-documentation provided by your computer, controller, and disk drive ven-
-dor(s).
-
-3 Low-level formatting
-----------------------
-
-If you are starting from scratch, you may need to low-level format your
-drive(s).  If you have been using your drive with the intended controller
-for DOS or some other system, and will not be changing the physical orien-
-tation of the drive, then you can skip this step.  If the drive is new, if
-you are changing the physical orientation of the drive, or it has been used
-with a different controller, you may need to do the low-level format.  Be
-aware that some drives have jumpers on them to help compensate for changes
-in physical orientation (horizontal, right side, or left side), but it is
-highly recommended that, if you are changing the physical orientation of
-the drive, you redo the low-level format.  The "sag" of the disk head arma-
-ture and other effects of gravity are quite significant at the sizes of the
-bits and tracks on these drives.  The greater the capacity of your drive,
-the more critical this becomes.  With 10-40Mb MFM drives, you may get away
-with it.  Beyond that, you are definitely rolling dice.
-
-The MFM drive format is standard, and a drive formatted on one manufacturer
-and model of controller should work just fine on another, but ESDI drive
-formats vary between manufacturers and sometimes even between models.  A
-new ESDI drive (yes, they can still be found new in the box, years old), or
-one that has been in use on a different controller or in a different physi-
-cal orientation will definitely require reformatting.
-
-As the ESDI specification developed, the ability to put the error map in-
-formation (Manufacturer's Defect List, or MDL) on the drive was added.
-Since it was not known how the drive would be formatted, or even what the
-size of the data part of the sectors would be, each bad spot is expressed
-as bytes from the index and length of the bad area in bits.  This informa-
-tion is recorded in a few different cylinders on each track and contains
-only information pertinent to the corresponding head.  The most universal
-place for this information is in the last cylinder.  Later ESDI drives sup-
-port a "phantom" cylinder at 0xfff (4095) where this information is kept --
-the actual location of this cylinder is beyond the "last" cylinder reported
-for data use.  If your drive does not support cylinder 0xfff, or if your
-controller doesn't know how to use it, and if you wish to preserve the man-
-ufacturer's defect list, do not format the last cylinder of your drive.
-The format of the MDL is such that regular data operations will not work on
-a track containing that information.
-
-As a further caveat, it as been observed that some controllers hang if the
-MDL area is accessed for data use, while others simply report an error and
-go on with life.  You will want to be careful to not include the MDL area
-in any FreeBSD slice, but you will want to be especially careful in case
-your controller is one of those that hangs if you miss.
-
-Now that you have decided how much of the drive to format, you can proceed
-with the actual format process.  How this is done varies widely from con-
-troller to controller.  For most of them, you need to jump into a special
-location in the controller ROM using the DOS DEBUG program.  For a few,
-special software is provided on diskette for the controller.  Because these
-procedures and the ways to initiate them vary so much, it is outside of the
-scope of this document to describe them.  Consult the manufacturer's docu-
-mentation for this procedure.
-
-Many of the controllers have the ability to read and use the MDL.  Even
-though you cannot use the controller's bad block mapping capability, which
-is supported through the BIOS, it may be beneficial to allow the controller
-to use this information during the format process.  When the drive was
-tested at the factory, it was tested at the operating margins, not just op-
-timal conditions.  Therefore, there may be entries in the MDL that would be
-missed by a run-of-the-mill data scan.  If the controller is permitted to
-use the MDL during formatting, many of them will format the sector with a
-special flag set in the sector preamble to guarantee that that sector will
-show up as bad on a read.  This is, in fact, the mechanism that some con-
-trollers use to handle bad sector mapping, though FreeBSD does not use the
-same mechanism.  We can take advantage of this feature as a 'round about
-way to get the MDL represented in the bad144 list.  Having the sectors
-which contain a bad spot formatted as bad will make certain that you don't
-use a sector where some data patterns may fail even though the initial scan
-passed that sector as OK.  Even if the sector doesn't produce hard errors,
-it may cause soft (correctable) errors and time-consuming retries.
-
-Finally, FreeBSD
-----------------
-
-Having made your careful plans and preparations, you are ready to use
-FreeBSD on your MFM or ESDI disk drive.  Don't forget to request bad block
-scanning during the "Partition" slice assignment, and you should be on your
-way to satisfying computing.  Be prepared to allow time for the bad block
-scan to take place.  Depending on a variety of system parameters, such as
-CPU speed, controller type, disk rotational and seek speeds, and so forth,
-this process will take anywhere from several minutes to hours.  If you for-
-get to do the scan, it is likely that the installation will fail trying to
-make the filesystems, and if it should make the filesystems, it will surely
-fail when you start using them.
-
-		   John Lind, Starfire Consulting Services
-E-mail: john@starfire.MN.ORG		USnail: PO Box 17247, Mpls MN  55417
diff --git a/share/FAQ/Text/FreeBSD.FAQ b/share/FAQ/Text/FreeBSD.FAQ
deleted file mode 100644
index a4d6301..0000000
--- a/share/FAQ/Text/FreeBSD.FAQ
+++ /dev/null
@@ -1,1307 +0,0 @@
-
-                               FreeBSD
-                      Frequently Asked Questions
-                           For Version 2.0 
-
-Please mail all suggestions and additions to <FAQ@FreeBSD.ORG>
-
-
-Revision: $Id: FreeBSD.FAQ,v 1.4 1995/04/09 07:02:03 jkh Exp $
-
-All entries are assumed to be relevant to FreeBSD 2.0. 
-Any entries with a <XXX> are under construction.
-
-
-Table of Contents
------------------
-
-0 Preface
-1 Installation
-2 Hardware Compatibility
-3 Commercial applications
-4 User Applications
-5 Miscellaneous Questions
-6 Kernel Configuration 
-7 System Administration
-8 Networking
-9 Serial Communications
-
-
-
-0 Preface
----------
-
-Welcome to the FreeBSD 2.0 FAQ!  This document tries to answer some of
-the most frequently asked questions about FreeBSD 2.0.  
-If there's something you're having trouble with and you do not see it
-here, please send email to:
-
-    	            <questions@FreeBSD.ORG>
-
-
-Some of the instructions here will also refer to auxiliary utilities
-in the /usr/src/share/FAQ directory.  CDROM purchasers and net folks
-who've grabbed the FreeBSD 2.0 `srcdist' will have these files.  If
-you don't have the source distribution, then you can either grab the
-whole thing from:
-
-               ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current
-
-Or you can grab only those files you're interested in straight out of
-the FreeBSD-current distribution in:
-
-              ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src
-
-0.1:  What is FreeBSD?  
-
-FreeBSD 2.0 is a UN*X type operating system based on U.C. Berkeley's 
-4.4BSD-lite release for the i386 platform.  It is also based indirectly
-on William Jolitz's port of U.C. Berkeley's Net/2 to the i386, 386BSD.
-There have been many additions and bug fixes made throughout
-the entire system, some of the highlights of which are:
-
-   More robust and extensive PC device support
-   System V-style IPC, messaging and semaphores
-   Shared Libraries
-   Much improved virtual memory code
-   Better console driver support
-   Network booting (diskless) support
-   Yellow Pages support
-   Full support of the PCI bus
-   Loadable kernel modules
-   Too many additional utilities and applications to mention
-
-<2.X-Current>
-   Serial Console Support
-   Merged VM/Buffer Cache
-   On demand PPP
-   Sync PPP
-   Improved SCSI support
-
-
-0.2:  What are the FreeBSD mailing lists, and how can I get on them? 
-
-The following mailing lists are provided for FreeBSD users and
-developers.  For more information, send to
-<majordomo@FreeBSD.ORG> and include a single line saying
-``help'' in the body of your message.
-
-announce:  For announcements concerning FreeBSD.  Low traffic.  Subscribe!
-hackers:   Useful for persons wishing to work on the internals. 
-questions: General questions on FreeBSD - questioners and question-answerers
-	   please! 
-bugs:      Where bug reports should be sent.
-SCSI:      Mailing list for SCSI developers. 
-current:   This list is for persons wishing to run FreeBSD-current
-           and carries announcements and discussions on current.  This list
-	   is *mandatory* if you run -current!
-security:  Information on issues dealing with system security. 
-platforms: Deals with ports to non-Intel platforms
-ports:     Discussion of /usr/ports/???
-fs:        Discussion of FreeBSD Filesystems
-hardware:  Discussion on hardware requirements for FreeBSD.
-
-The FreeBSD-commit list has been broken up into groups dealing with different
-areas of interest.  Please see the FreeBSD mailing list FAQ in:
-
-        /usr/share/FAQ/mailing-list.FAQ
-
-
-0.3:  What are the various FreeBSD news groups? 
-
-There are two newsgroups currently dedicated to FreeBSD:
-
-comp.unix.bsd.freebsd.announce:     For announcements
-comp.unix.bsd.freebsd.misc:         General discussion
-
-
-The following newsgroups may also be of interest to general BSD
-enthusiasts:
-
-comp.unix.bsd:                      General BSD topics
-comp.os.386bsd.*:                   Ongoing, active FreeBSD discussions
-                                    (probably only for a short time longer).
-
-
-
-1 Installation
---------------
-
-1.1:  I want to install FreeBSD onto a SCSI disk that has more than
-      1024 cylinders.  How do I do it?
-
-This depends.  If you don't have DOS (or another operating system) on
-the system, you can just keep the drive in native mode and simply make
-sure that your root partition is below 1024 so the BIOS can boot the
-kernel from it.  It you also have DOS/some other OS on the drive then
-your best bet is to find out what parameters that it thinks you have
-before installing FreeBSD.  When FreeBSD's installation procedure
-prompts you for these values, you should then enter them rather than
-simply going with the defaults.
-
-There is a freely available utility distributed with FreeBSD called
-`pfdisk' (located in the tools/dos-tools subdirectory) which can be used for
-this purpose.
-
-
-1.2:  When I boot FreeBSD it says ``Missing Operating System''.
-
-See question 1.2.  This is classically a case of FreeBSD and DOS or
-some other OS conflicting over their ideas of disk geometry.  You will
-have to reinstall FreeBSD, but obeying the instructions given above
-will almost always get you going.
-
-1.3:  When I install the boot manager and try to boot FreeBSD for the
-      first time, it just comes back with the boot manager prompt again.
-
-This is another symptom of the problem described in 1.2.  Your
-BIOS geometry and FreeBSD geometry settings do not agree!  If your
-controller or BIOS supports cylinder translation (often marked
-as ">1GB drive support"), try toggling its setting and reinstalling
-FreeBSD.
-
-1.4:  I have an IDE drive with lots of bad blocks on it and FreeBSD doesn't
-      seem to install properly.
-
-FreeBSD's bad block (bad144) handling is still not 100% (to put it
-charitably) and it must unfortunately be said that if you've got an
-IDE or ESDI drive with lots of bad blocks, then FreeBSD is probably
-not for you!  That said, it does work on thousands of IDE based
-systems, so you'd do well to try it first before simply giving up.
-
-IDE drives are *supposed* to come with built-in bad-block remapping;
-if you have documentation for your drive, you may want to see if this
-feature has been disabled on your drive.  However, ESDI, RLL, and
-ST-506 drives normally do not do this.
-
-1.5:  I have 32MB of memory, should I expect any special problems?
-
-No.  FreeBSD 2.0 comes with bounce buffers which allows your bus
-mastering controller access to greater than 16MB.
-
-1.6:  Do I need to install the complete sources?
-
-In general, no.  However, we would strongly recommend that you
-install, at a minimum, the `base' source kit, which includes several
-of the files mentioned here, and the `sys' (kernel) source kit, which
-includes sources for the kernel.  There is nothing in the system which
-requires the presence of the sources to operate, however, except for
-the kernel-configuration program config(8).  With the exception of the
-kernel sources, our build structure is set up so that you can
-read-only mount the sources from elsewhere via NFS and still be able
-to make new binaries.  (Because of the kernel-source restriction, we
-recommend that you not mount this on /usr/src directly, but rather in
-some other location with appropriate symbolic links to duplicate the
-top-level structure of the source tree.)
-
-Having the sources on-line and knowing how to build a system with them
-will make it much easier for you to upgrade to future releases of
-FreeBSD.
-
-1.7:  DES encryption software can not be exported from the United
-      States.  If I live outside the US, how can I encrypt passwords?
-
-If it is not absolutely imperative that you use DES style encryption,
-you can use FreeBSD's default encryption for even _better_ security,
-and with no export restrictions.  FreeBSD 2.0's password default
-scrambler is now MD5 based, and is more CPU-intensive to crack
-with an automated password cracker than DES.
-
-Since the DES encryption algorithm cannot legally be exported from the US,
-non-US users should not download this software (as part of the secrdist)
-from US FTP sites.
-
-There is however a replacement libcrypt available, based on sources
-written in Australia by David Burren.  This code is now available on
-some non-US FreeBSD mirror sites.  Sources for the unencumbered
-libcrypt, and binaries of the programs which use it, can be obtained
-from the following FTP sites:
-
-        South Africa:   braae.ru.ac.za:/pub/FreeBSD/securedist/
-                        owl.und.ac.za (currently uncertain)
-        Iceland:        ftp.veda.is:/pub/crypt/FreeBSD/
-
-The non-US securedist can be used as a direct replacement for the
-encumbered US securedist.  This securedist package is installed the
-same way as the US package (see installation notes for details).  If
-you are going to install DES encryption, you should do so as soon as
-possible, before installing other software.
-
-Non-US users should please not download any encryption software from
-the USA.  This can get the maintainers of the sites from which the
-software is downloaded into severe legal difficulties.
-
-A non-US distribution of Kerberos is also being developed, and current
-versions can generally be obtained by anonymous FTP from
-braae.ru.ac.za.
-
-There is a mailing list for the discussion of non-US encryption
-software.  For more information, send an email message with a single
-line saying ``help'' in the body of your message to
-<majordomo@braae.ru.ac.za>.
-
-
-
-2 Hardware compatibility
-------------------------
-
-2.1:  What kind of hard drives does FreeBSD run on?
-
-FreeBSD supports ST-506 (sometimes called ``MFM''), RLL, and ESDI
-drives, which are usually connected to WD-1002, WD-1003, or WD-1006
-controllers (although clones should also work).
-
-FreeBSD also supports IDE and SCSI hard drives.
-
-2.2:  What SCSI controllers are supported?
-
-FreeBSD supports the following SCSI controllers:
-
-Adaptec              AH-154x Series <ISA>
-                     AH-174x Series <EISA>
-                     AH-152x Series <ISA>
-		     Sound Blaster SCSI (AH-152x compat) <ISA>
-                     AH-2742/2842 Series <ISA/EISA>
-		     AH-2820/2822/2825 Series <VLB>
-Buslogic             BT-445 Series <VLB> (but see section 1.5)
-		     BT-545 Series <ISA>
-                     BT-742 Series <EISA>
-                     BT-747 Series <EISA>
-                     BT-964 Series <PCI>
-Future Domain        TMC-950 Series <ISA> 
-PCI Generic          NCR 53C810 based controllers <PCI> 
-ProAudioSpectrum     Zilog 5380 based controllers <ISA>
-Seagate              ST-01/02 Series <ISA>
-UltraStor            UH-14f Series <ISA>
-                     UH-24f Series <EISA>
-                     UH-34f Series <VLB>
-
-<2.X-Current Only>
-Western Digital	     WD7000 <ISA> <No scatter/gather>
-Adaptec		     AH-294x and aic7870 MB controllers <PCI>
-ProAudioSpectrum     Trantor 130 based controllers <ISA>
-
-2.3:  What CD-ROM drives are supported by FreeBSD?
-
-Any SCSI drive connected to a supported controller.
-Mitsumi LU002(8bit), LU005(16bit) and FX001D(16bit 2x Speed).
-
-<2.X-Current>
-Sound Blaster Non-SCSI CD-ROM
-
-FreeBSD does not support any of the ``IDE'' CD-ROM interfaces.
-All non-SCSI cards are known to be extremely slow compared to SCSI
-drives.
-
-2.4:  What multi-port serial cards are supported by FreeBSD?
-
-AST/4
-ARNET/8
-BOCA 4/8/16 port cards.  
-RISCom/8
-
-<2.X-Current>
-Cyclades 8/16 port <Alpha>
-
-Some unnamed clone cards have also been known to work,, especially those
-that claim to be AST compatible.
-Check the sio(4) man page to get more information on configuring such
-cards.
-
-
-2.5:  Does FreeBSD support the AHA-2742/2842 SCSI adapters from Adaptec?
-
-Yes, though portions of the sources are currently GPL'd (that is to say,
-distributed under the GNU Public License), so be aware of the fact should
-you wish to distribute kernel binaries compiled with it - you MUST also
-provide the sources to the driver with the kernel image to stay legal
-with the GPL!  This is easily enough done by simply including the contents
-of /usr/src/sys/gnu/{aic7770,misc} on whatever media you distribute the
-kernel.
-
-We are working to get the GPL restriction removed, but for now you should
-at least be aware of it.
-
- 
-2.6:  I have a Mumbleco bus mouse.  Is it supported and if so, how do I set
-      it up for XFree86?
-
-FreeBSD supports the Logitech and ATI Inport bus mice.  You need to
-add the following line to the kernel config file and recompile for the
-Logitech and ATI mice:
-
-        device        mse0    at isa? port 0x23c tty irq6 vector mseintr
-
-
-2.7:  I have a PS/2 mouse (`keyboard' mouse) [Alternatively:  I have a
-      laptop with a track-ball mouse].  How do I use it?
-
-
-
-2.8:  What types of tape drives are supported under FreeBSD?
-
-FreeBSD supports SCSI, QIC-02 and QIC-40/80 (Floppy based) tape
-drives.  This includes 8-mm (aka Exabyte) and DAT drives.
-
-
-2.9:  What sound cards are supported by FreeBSD?
-
-FreeBSD supports the SoundBlaster, SoundBlaster Pro, Pro Audio
-Spectrum 16, AdLib and Gravis UltraSound sound cards. There is also
-limited support for MPU-401 and compatible MIDI cards.  The
-SoundBlaster 16 and SoundBlaster 16 ASP cards are not yet supported.
-NOTE: This is only for sound!  This driver does not support CD-ROMs,
-SCSI or joysticks on these cards.
-
-
-2.10:   What network cards does FreeBSD support?
-
-There is support for the following cards:
-
-`ed' driver:
-        NE2000 and 1000
-        WD/SMC 8003, 8013 and Elite Ultra (8216)
-        3Com 3c503 
-        And clones of the above
-
-`de' driver:
-	DEC and compatible PCI controllers.
-
-`le' driver:
-	DEC LANCE ethernet based controllers.
-
-`ie' driver:
-        AT&T EN100/StarLAN 10
-        3Com 3c507 
-
-`is' driver:
-        Isolan AT 4141-0
-        Isolink 4110
-
-`ep' driver:
-        3com 3c509 (*)
-
-`el' driver:
-	3com 3c501 (*)
-
-`ze' driver:
-        IBM PCMCIA credit card adapter
-
-`lnc' driver:
-	Unknown Lance based (*)
-
-<2.X-Current>
-
-`cx' driver
-	Cronyx/Sigma multiport Sync/Async (Cisco and PPP framing)
-
-`zp' driver
-	3Com PCMCIA Etherlink III
-
-Note:	Drivers marked with (*) are known to have problems.
-
-Note:	We also support TCP/IP over parallel lines.  At this point we are
-	incompatiable with other versions, but we hope to correct this in
-	the near future.
-
-2.11:  I have a 386/486sx/486SLC machine without a math co-processor.
-       Will this cause me any problems?
-
-Generally no, but there are circumstances where you will take a hit,
-either in performance or accuracy of the math emulation code (see
-section 4.1).  In particular, drawing arcs in X will be VERY slow.  It
-is highly recommended that you lay out the $50 or so for a math
-co-processor; it's well worth it.  NOTE: Some math co-processors are
-better than others.  It pains us to say it, but nobody ever got fired
-for buying Intel.  Unless you're sure it works with FreeBSD, beware of
-clones.
-
-2.12:  What other devices does 2.X support?
-
-Here is a listing of drivers that do not fit into any of the above areas.
-
-b004.c		Driver for B004 compatiable Transputer boards
-ctx.c		Driver for CORTEX-I Frame grabber
-gpib.c		Driver for National Instruments AT-GPIB and AT-GPIB/TNT boards
-pcaudio.c	Driver for PC speakers to allow the playing of audio files
-tw.c		Driver for the X-10 POWERHOUSE 
-
-<2.X-Current>
-spigot.c	Driver for the Creative Labs Video Spigot
-gsc.c		Driver for the Genuis GS-4500 Hand scanner
-joy.c		Driver for a joystick
-
-2.13:  I am about to buy a new machine to run FreeBSD on and
-       want an idea of what other people are running.  Is there list
-       of other systems anywhere? 
-
-Yes.  Please look at the file Systems.FAQ.  This file
-is a listing of hardware that people are running in their machines.
-Please note, this is a raw listing of equipment that other users
-have sent in, and does not constitute any kind of endorsement by the
-FreeBSD Project.
-
-2.14:	I have a lap-top with power management.  Can FreeBSD take advantage
-	of this?
-
-Yes it can on certain machines.  Please look in the LINT kernel config 
-file under APM.
-
-
-
-3 Commercial Applications
--------------------------
-
-Note: This section is still very sparse, though we're hoping, of
-course, that companies will add to it! :) The FreeBSD group has no
-financial interest in any of the companies listed here but simply
-lists them as a public service (and feels that commercial interest in
-FreeBSD can have very positive effects on FreeBSD's long-term
-viability).  We encourage commercial software vendors to send their
-entries here for inclusion.
-
-
-3.1:  Where can I get Motif for FreeBSD?
-
-You can purchase Motif 1.2.3 for FreeBSD (SWiM) from the ACC Bookstore, 
-P.O. Box 3364, Westport CT. 06880.  1-800-546-7274 or FAX: 1-203-454-2582
-
-This software works flawlessly for for FreeBSD 1.1.5 but has shown
-one problem with 2.0 in that the "uil" program core dumps.  This is
-apparently because of the way uil is installed, and it's quite possible
-that ACC will have a fixed version by the time you read this.  No
-other compatibility problems with the programs or libraries have been
-found, and ACC can hardly be blamed for failing to work perfectly with
-a brand-new release they haven't even seen yet! :)
-
-
-3.2:  Are there any commercial X servers for some of the high-end
-      graphics cards like the Matrox or #9 I-128, or offering 8/16/24
-      bit deep pallettes?
-
-Yes, X Inside Incorporated sells their Accelerated-X product for
-FreeBSD and other Intel based systems.
-
-This high performance X Server offers easy configuration, support
-for multiple concurrent video boards and is distributed in binary
-form only.
-
-Price is $99.50 (promotional price for Linux/FreeBSD version) for
-the 1.1 version, which is available now.
-
-This product is for FreeBSD 1.1 and runs under 2.0 with the FreeBSD 1.1
-compatibility libs (`compat1xdist').
-
-More info: URL http://www.xinside.com/
-	or URL ftp://ftp.xinside.com/accelx/1.1/prodinfo.txt
-	or email info@xinside.com
-	or phone +1(303)384-9999
-
-
-3.3:  Any other applications I might be interested in?
-
-RenderMorphics, Ltd. sells a high-speed 3D rendering package for
-FreeBSD called "Reality Lab" (tm).  Send email to info@render.com
-or call: +44(0)71-251-4411 / FAX: +44(0)71-251-0939
-
-This package is also for FreeBSD 1.1.5 but has been tested and shown
-to run under FreeBSD 2.0 with the compat1xdist installed.
-
-Thanks must be extended to all of these companies for showing enough faith
-in FreeBSD to port their products to it.  While we get no direct benefit
-from the sales of these products, the indirect benefits of FreeBSD
-proving itself to be a successful platform for such commercial interests
-will be immense!  We wish these companies every measure of success, and
-can only hope that others are encouraged to follow suit.
-
-
-4 User Applications
--------------------
-
-4.1:  I want to run X, how do I go about it?
-
-First, get the XFree86 distribution of X11R6 from XFree86.cdrom.com.
-The version you want for FreeBSD 2.X and later is XFree86 3.1.1.  Follow
-the instructions for installation carefully. You may then wish to read
-the documentation for the ConfigXF86 tool, which assists you in
-configuring XFree86 for your particular graphics card/mouse/etc.
-
-You may also wish to investigate the Xaccel server, which is available
-at a very reasonable price.  See section 3.2 for more details.
-
-4.2:  I've been trying to run ghostscript on a 386 (or 486sx) with no
-      math co-processor and I keep getting errors.  What's up?
-
-You will need to add the alternate math emulator to your kernel, you do this
-by adding  the following to your kernel config file and it will be compiled in.
-
-options                         GPL_MATH_EMULATE
-
-NOTE:  You will need to remove the MATH_EMULATE option when you do this.
-
-
-4.2:  I want all this neat software, but I haven't got the space or
-      CPU power to compile it all myself.  Is there any way of getting
-      binaries?
-
-Yes.  We support the concept of a `package', which is essentially a
-gzipped binary distribution with a little extra intelligence embedded
-in it for doing any custom installation work required.  Packages can
-also be installed or deinstalled again easily without having to know
-the gory details.  CDROM people will have a packages/ directory on
-their CD, others can get the currently available packages from:
-
-                ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages
-
-Note that all ports may not be available as packages, and that new
-packages are constantly being added.  It is always a good idea to
-check periodically to see which packages are available.  A README file
-in the packages directory provides more details on the care and
-feeding of the package software, so no explicit details will be given
-here.
-
-
-
-
-5 Miscellaneous Questions
-----------------
-
-5.1:  I've heard of something called FreeBSD-current.  How do I run it, and
-      where can I get more information?
-
-Read the file /usr/src/share/FAQ/current-policy.FAQ,
-it will tell you all you need to know.
-
-
-5.2:  What is this thing called `sup', and how do I use it?
-
-SUP stands for Software Update Protocol, and was developed by CMU for
-keeping their development trees in sync.  We use it to keep remote
-sites in sync with our central development sources.
-
-Unless you have direct internet connectivity, and don't care too much
-about the cost/duration of the sessions, you shouldn't use sup.  For
-those "low/expensive-bandwidth" applications, we have developed CTM,
-see 5.6 for more about that.
-
-To use it, you need to have direct internet connectivity (not just
-mail or news).  First, pick up the sup.tgz package from:
-
-        ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages/sup.tgz
-
-Second, read the file /usr/src/share/FAQ/sup.FAQ.
-
-This file describes how to setup sup on your machine.  You may also
-want to look at /usr/src/share/FAQ/extras/*.supfile, or you may grab updated
-supfiles from:
-
-	ftp://ftp.FreeBSD.ORG//pub/FreeBSD/FAQ/extras
-
-which are a set of supfiles for supping from FreeBSD.ORG. 
-
-
-5.3:  How do I create customized installation disks that I can give
-      out to other people at my site?
-
-The entire process of creating installation disks and source and
-binary archives is automated by various targets in
-/usr/src/etc/Makefile.  The information there should be enough to get
-you started.
-
-5.4:  How do I re-build my system without clobbering the existing
-      installed binaries?
-
-If you define the environment variable DESTDIR while running `make
-world' or `make install', the newly-created binaries will be deposited
-in a directory tree identical to the installed one, rooted at
-${DESTDIR}.  Some random combination of shared libraries modifications
-and program rebuilds can cause this to fail in `make world', however.
-
-
-5.5:  When my system booted, it told me that ``(bus speed defaulted)''.
-      What does that mean?
-
-The Adaptec 1542 SCSI host adapters allow the user to configure their
-bus access speed in software.  Previous versions of the 1542 driver tried
-to determine the fastest usable speed and set the adapter to that.  We
-found that this breaks some users' systems, so you now have to define
-the ``TUNE_1542''' kernel configuration option in order to have this
-take place.  Using it on those systems where it works may make your
-disks run faster, but on those systems where it doesn't, your data could
-be corrupted.
-
-5.6:  I would like to track changes to current and do not have net access.  
-      Is there any way besides downloading the whole tree?
-
-Yes, you can use the CTM facility.  Check out the ctm.FAQ file or
-	ftp://freefall.cdrom.com/pub/CTM/README
-for more information.
-
-5.7:  How do I split up large binary files into smaller 240k files
-      like the distribution does?
-
-Newer BSD based systems have a "-b" option to split that allows them to
-split files on arbitary byte bondaries.
-
-Here is an example from /usr/src/Makefile.
-bin-tarball:
-	(cd ${DISTDIR}; \
-		tar cf - . \
-		gzip --no-name -9 -c | \
-		split -b 240640 - \
-		${RELEASEDIR}/tarballs/bindist/bin_tgz.)
-
-
-<XXX> 5.8:  I've had a couple of system panics and would like to be able
-      browse the system dumps.  The normal kernel is stripped and
-      I don't want to run a bloated kernel.  What can I do?
-
-5.9:  I just got a Perl application and it's bombing looking for
-      *.ph.  Where is it?
-
-There was a minor SNAFU in the 2.0-R bindist and they got left out.
-If you have the source, you just have to do a "make install" from
-/usr/src/gnu/usr.bin/perl/lib and everything will be fine.  Or you
-may ftp to phoenix-gw.gbdata.com and grab them from ~/pub/perl/libs.tar.gz.
-
-5.10: I've got this neato kernel extension I just know everyone will
-      will want.  How do I get it included into the distribution?
-
-Please take a look at the FAQ for submiting code to FreeBSD at:
-
-	ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FAQ/submitters.FAQ
-
-And thanks for the thought.
-
-
-6 Kernel Configuration
-----------------------
-
-6.0:  Ok, so how DO I compile my own kernel, anyway?
-
-Before you can compile a kernel, you need either the complete srcdist
-or, at the minimum, the kerndist loaded on your system.  This provides
-the necessary sources for building the kernel, as we have a policy of
-NOT shipping our kernels in linkable object form as most commercial
-UNIX vendors do.  Shipping the source takes a bit more space, but it also
-means that you can refer to the actual kernel sources in case of difficulty
-or to further your understanding of what's *actually* happening.
-
-Anyway, to answer the question, once you have the kerndist or srcdist
-loaded, do this:
-
-	6.0.1:		cd /usr/src/sys/i386/conf
-	6.0.2:		cp GENERIC MYKERNEL
-	6.0.3:		vi MYKERNEL
-	6.0.4:		config MYKERNEL
-	6.0.5:		cd ../../compile/MYKERNEL
-	6.0.6:		make all
-	6.0.7:		make install
-	6.0.8:		reboot
-
-Step 6.0.2 may not be necessary if you already have a kernel configuration
-file from a previous release of FreeBSD 2.x. - simply bring your old one
-over and check it carefully for any drivers that may have changed boot
-syntax or been rendered obsolete.
-
-A good kernel config file to look into is LINT, which contains entries for
-*all* possible kernel options and documents them fairly well.  The GENERIC
-kernel config file is used to build the initial release you probably loaded
-(unless you upgraded in-place) and contains entries for the most common
-configurations.  It's a pretty good place to start from.
-
-If you don't need to make any changes to GENERIC, you can also skip step
-6.0.3, where you customize the kernel for your configuration.  Step 6.0.7
-should only be undertaken if step 6.0.6 succeeds.  This will copy
-the new kernel image to /kernel and BACK UP YOUR OLD ONE IN /kernel.old!
-It's very important to remember this in case the new kernel fails to work
-for some reason - you can still select /kernel.old at the boot prompt to
-boot the old one.  When you reboot, the new kernel will boot by default.
-
-If the compile in 6.0.6 falls over for some reason, then it's recommended
-that you start from step 6.0.4 but substitute GENERIC for MYKERNEL.  If you
-can generate a GENERIC kernel, then it's likely something in your special
-configuration file that's bad (or you've uncovered a bug!).  If the build
-of the GENERIC kernel does NOT succeed, then it's very likely that your
-sources are somehow corrupted.
-
-Finally, if you need to see your original boot messages again to compile
-a new kernel that's better tailored to your hardware, try the `dmesg' command.
-It should print out all the boot-time messages printed by your old kernel,
-some of which may be quite helpful in configuring the new one.
-
-
-6.1:  When I compile a kernel with multi-port serial code, it tells me
-      that only the first port is probed and the rest skipped due to
-      interrupt conflicts.  How do I fix this?
-
-The problem here is that FreeBSD has code built-in to keep the kernel
-from getting trashed due to hardware or software conflicts.  The way
-to fix this is to leave out the IRQ settings on other ports besides
-the first.  Here is a example:
-
-#
-# Multiport high-speed serial line - 16550 UARTS
-#
-device    sio2    at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr
-device    sio3    at isa? port 0x2a8 tty flags 0x501 vector siointr 
-device    sio4    at isa? port 0x2b0 tty flags 0x501 vector siointr
-device    sio5    at isa? port 0x2b8 tty flags 0x501 vector siointr
-
-
-6.2:  FreeBSD is supposed to come with support for QIC-40/80 drives but
-      when I look, I can't find it.
-
-You need to uncomment the following line in the generic config file
-(or add it to your config file), make the change to the fdc0 line shown,
-and recompile.
-
-controller      fdc0    at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr flags 0x1
-                                                                            ^^^^^^^^^
-disk            fd0     at fdc0 drive 0
-disk		fd1     at fdc0 drive 1
-#tape           ft0     at fdc0 drive 2
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You will have a device called /dev/ft0, which you can write to through
-a special program to manage it called `ft' - see the man page on ft for
-further details.  Versions previous to -current also had some trouble dealing
-wiht bad tape media; if you have trouble where ft seems to go back and forth
-over the same spot, try grabbing the latest version of ft from /usr/src/sbin/ft 
-in current and try that.
-
-
-6.3:  Does FreeBSD support IPC primitives like those in System V?
-
-Yes, FreeBSD supports System V-style IPC.  This includes shared
-memory, messages and semaphores.  You need to add the following lines
-to your kernel config to enable them.
-
-options         SYSVSHM
-options         "SHMMAXPGS=64"          # 256Kb of sharable memory
-options         SYSVSEM                 # enable for semaphores
-options         SYSVMSG                 # enable for messaging
-
-Recompile and install.
-
-
-6.4:  Will FreeBSD ever support other architectures?
-
-Several different groups have expressed interest in working on
-multi-architecture support for FreeBSD.  If you are interested in
-doing so, please contact the developers at
-<FreeBSD-hackers@FreeBSD.ORG> for more information on our
-strategy for porting.
-
-
-6.5:  I just wrote a device driver for a Foobar Systems, Inc.
-      Integrated Adaptive Gronkulator card.  How do I get the
-      appropriate major numbers assigned?
-
-This depends on whether or not you plan on making the driver publicly
-available.  If you do, then please send us a copy of the driver source
-code, plus the appropriate modifications to files.i386, a sample
-configuration file entry, and the appropriate MAKEDEV code to create
-any special files your device uses.  If you do not, or are unable to
-because of licensing restrictions, then character major number 32 and
-block major number 8 have been reserved specifically for this purpose;
-please use them.  In any case, we'd appreciate hearing about your
-driver on <FreeBSD-hackers@FreeBSD.ORG>.
-
-
-
-7 System Administration
------------------------
-
-7.1:  How do I add a user easily?  I read the man page and am more confused
-      than ever!  [Alternatively:  I didn't read the man page, I never read
-      man pages! :-) ]
-
-Use the adduser command.
-
-
-<XXX> 7.2: I'm trying to use my printer and keep running into problems.  I tried
-     looking at /etc/printcap, but it's close to useless.  Any ideas?
-
-
-
-8 Networking
-------------
-
-
-8.2:  I've heard that you can use a FreeBSD box as a dedicated network
-      router - is there any easy support for this?
-
-Internet standards and good engineering practice prohibit us from
-providing packet forwarding by default in FreeBSD.  You can enable
-this support by adding `options GATEWAY' to your kernel configuration
-file and recompiling.  In most cases, you will also need to run a
-routing process to tell other systems on your network about your
-router; FreeBSD comes with the standard BSD routing daemon routed(8),
-or for more complex situations you may want to try GateD (available by
-FTP from gated.Cornell.edu) which supports FreeBSD as of 3_5Alpha7.
-
-It is our duty to warn you that, even when FreeBSD is configured in
-this way, it does not completely comply with the Internet standard
-requirements for routers; however, it comes close enough for ordinary
-usage.
-
-
-8.3:  Does FreeBSD support SLIP and PPP?
-
-Yes.  See the man pages for slattach(8) and/or pppd(8) if you're using
-FreeBSD to connect to another site.  If you're using FreeBSD as a
-server for other machines, look at the man page for sliplogin(8).
-You may also want to take a look at the slip FAQ in:
-             /usr/src/share/FAQ/Slip.FAQ
-
-8.4:  How do I get my network set up?  I don't see how to make my
-      /dev/ed0 device!
-
-In the Berkeley networking framework, network interfaces are only
-directly accessible by kernel code.  Please see the /etc/netstart file
-and the manual pages for the various network programs mentioned there
-for more information.  If this leaves you totally confused, then you
-should pick up a book describing network administration on another
-BSD-related operating system; with few significant exceptions,
-administering networking on FreeBSD is basically the same as on SunOS
-4.0 or Ultrix.
-
-8.5:  How do I get my 3C503 to use the other network port?
-
-Use `ifconfig ed0' to see whether the ALTPHYS flag is set, and then
-use either `ifconfig ed0 altphys' if it was off, or `ifconfig ed0
--altphys' if it was on.
-
-8.6:  I'm having problems with NFS to/from FreeBSD and my Wuffotronics
-      Workstation / generic NFS appliance, where should I look first?
-
-Certain PC network cards are better than others (to put it mildly) and
-can sometimes cause problems with network intensive applications like
-NFS.  See /usr/src/share/FAQ/NFS.FAQ for more information on this
-topic.
-
-8.8:  I want to enable IP multicast support on my FreeBSD box, how do I do it?
-      [Alternatively:  What the heck IS multicasting and what applications
-      make use of it?]
-
-Multicast host operations are fully supported in FreeBSD 2.0 by default.
-If you want your box to run as a multicast router, you will need to load
-the ip_mroute_mod loadable kernel module and run mrouted.
-
-For more information:
-
-Product		Description		Where
---------------- ----------------------- ---------------------------------------
-faq.txt		Mbone FAQ		ftp.isi.edu:/mbone/faq.txt
-imm/immserv	IMage Multicast 	ftp.hawaii.edu:/paccom/imm.src.tar.Z
-		for jpg/gif images.
-nv		Network Video.		ftp.parc.xerox.com:
-					/pub/net-reseach/exp/nv3.3alpha.tar.Z
-vat		LBL Visual Audio Tool.	ftp.ee.lbl.gov:
-					/conferencing/vat/i386-vat.tar.Z
-wb		LBL White Board.	ftp.ee.lbl.gov:
-					/conferencing/wb/i386-wb.tar.Z
-mmcc		MultiMedia Conference	ftp.isi.edu:
-		Control program		/confctrl/mmcc/mmcc-intel.tar.Z
-rtpqual		Tools for testing the	ftp.psc.edu:/pub/net_tools/rtpqual.c
-		quality of RTP packets.
-vat_nv_record	Recording tools for vat	ftp.sics.se:archive/vat_nv_record.tar.Z
-		and nv.
-
-
-
-9 Serial Communications
------------------------
-
-This section answers common questions about serial communications with
-FreeBSD.
-
-9.1: How do I tell if FreeBSD found my serial ports or modem cards?
-
-As the FreeBSD kernel boots, it will probe for the serial ports in
-your system for which the kernel was configured.  You can either watch
-your system closely for the messages it prints or run the command
-
-    dmesg | grep sio
-
-after your system's up and running.
-
-Here's some example output from the above command:
-
-    sio0 at 0x3f8-0x3ff irq 4 on isa
-    sio0: type 16550A
-    sio1 at 0x2f8-0x2ff irq 3 on isa
-    sio1: type 16550A
-
-This shows two serial ports.  The first is on irq 4, is using port
-address 0x3f8, and has a 16550A-type UART chip.  The second uses the
-same kind of chip but is on irq 3 and is at port address 0x2f8.
-Internal modem cards are treated just like serial ports---except that
-they always have a modem ``attached'' to the port.
-
-The GENERIC kernel includes support for two serial ports using the
-same irq and port address settings in the above example.  If these
-settings aren't right for your system, or if you've added modem cards
-or have more serial ports than your kernel is configured for, just
-reconfigure your kernel.  See section 7 of the FAQ for more details.
-
-9.2: How do I access the serial ports once FreeBSD is running?
-
-The third serial port, sio2 (known as COM3 in DOS), is on /dev/tty02
-for directly-connected devices, on /dev/cuaa2 for dial-out devices,
-and on /dev/ttyd2 for dial-in devices.  What's the difference between
-these three classes of devices?
-
-You use ttyXX for directly-connected or hardwired devices, like
-printers or terminals.
-
-In place of ttyXX, you can use the pair of devices cuaaX and ttydX.
-You use ttydX for dial-ins.  The ttydX device acts like the ttyXX
-device, but it also uses the modem control lines.  When opening
-/dev/ttydX in blocking mode, a process will wait for the corresponding
-cuaaX device to become inactive, and then wait for the carrier detect
-line to go active.  When you open the cuaaX device, it makes sure the
-serial port isn't already in use by the ttydX device.  If the port's
-available, it ``steals'' it from the ttydX device.  Also, the cuaaX
-device doesn't care about carrier detect.  With this scheme and an
-auto-answer modem, you can have remote users log in and you can still
-dialout with the same modem and the system will take care of all the
-conflicts.
-
-9.3: How do I configure the kernel for my multiport serial card?
-
-Again, the section on kernel configuration provides information about
-configuring your kernel.  For a multiport serial card, place an sio
-line for each serial port on the card in the kernel configuration
-file.  But place the irq and vector specifiers on only one of the
-entries.  All of the ports on the card should share one irq.  For
-consistency, use the last serial port to specify the irq.  Also,
-specify the COM_MULTIPORT option.
-
-The following example is for an AST 4-port serial card on irq 7:
-
-    options "COM_MULTIPORT"
-    device sio4 at isa? port 0x2a0 tty flags 0x781
-    device sio5 at isa? port 0x2a8 tty flags 0x781
-    device sio6 at isa? port 0x2b0 tty flags 0x781
-    device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr
-
-The flags indicate that the master port has minor number 7 (0x700),
-diagnostics enabled during probe (0x080), and all the ports share an
-irq (0x001).
-
-9.4: I have two multiport serial cards that can share irqs.  Can
-      FreeBSD handle this?
-
-Not yet.  You'll have to use a different irq for each card.
-
-9.5: What's the difference between tty01, ttyi01, and ttyl01?  Or,
-      how can I set the default serial parameters for a port?
-
-The ttyXX (or cuaaX or ttydX) device is the regular device you'll want
-to open for your applications.  When a process opens the device, it'll
-have a default set of terminal I/O settings.  You can see these
-settings with the command
-
-    stty -a -f /dev/tty01
-
-When you change the settings to this device, the settings are in
-effect until the device is closed.  When it's reopened, it goes back
-to the default set.  To make changes to the default set, you can open
-and adjust the settings of the ``initial state'' device.  For example,
-to turn on CLOCAL mode, 8 bits, and XON/XOFF flow control by default
-for tty05, do:
-
-    stty -f /dev/ttyi05 clocal cs8 ixon ixoff
-
-A good place to do this is in /etc/rc.serial.  Now, an application
-will have these settings by default when it opens tty05.  It can still
-change these settings to its liking, though.
-
-You can also prevent certain settings from being changed by an
-application by making adjustments to the ``lock state'' device.  For
-example, to lock the speed of tty05 to 57600 bps, do
-
-    stty -f /dev/ttyl05 57600
-
-Now, an application that opens tty05 and tries to change the speed of
-the port will be stuck with 57600 bps.
-
-Naturally, you should make the initial state and lock state devices
-writable only by root.  The MAKEDEV script does NOT do this when it
-creates the device entries.
-
-9.6: How can I enable dialup logins on my modem?
-
-So you want to become an Internet service provider, eh?  First, you'll
-need one or more modems that can autoanswer.  Your modem will need to
-assert carrier-detect when it detects a carrier and not assert it all
-the time.  It will need to hang up the phone and reset itself when the
-data terminal ready (DTR) line goes from on to off.  It should
-probably use RTS/CTS flow control or no local flow control at all.
-Finally, it must use a constant speed between the computer and itself,
-but (to be nice to your callers) it should negotiate a speed between
-itself and the remote modem.
-
-For many Hayes command-set--compatible modems, this command will
-make these settings and store them in nonvolatile memory:
-
-    AT &C1 &D3 &K3 &Q6 S0=1 &W
-
-See 9.10 below for information on how to make these settings without
-resorting to an MS-DOS terminal program.
-
-Next, make an entry in /etc/ttys for the modem.  This file lists all
-the ports on which the operating system will await logins.  Add a line
-that looks something like this:
-
-    ttyd1 "/usr/libexec/getty std.57600" dialup on insecure
-
-This line indicates that the second serial port (/dev/ttyd1) has a
-modem connected running at 57600 bps and no parity (std.57600, which
-comes from the file /etc/gettytab).  The terminal type for this port
-is ``dialup.''  The port is ``on'' and is ``insecure''---meaning root
-logins on the port aren't allowed.  For dialin ports like this one,
-use the ttydX entry.
-
-It's common practice to use ``dialup'' as the terminal type.  Many
-users set up in their .profile or .login files a prompt for the actual
-terminal type if the starting type is dialup.  The example shows the
-port as insecure.  To become root on this port, you have to login as a
-regular user, then ``su'' to root.  If you use ``secure'' then root
-can login in directly.
-
-After making modifications to /etc/ttys, you need to send a hangup or
-HUP signal to the init process:
-
-    kill -1 1
-
-This forces the init process to reread /etc/ttys.  The init process
-will then start getty processes on all ``on'' ports.  You can find out
-if logins are available for your port by typing
-
-    ps -ax | grep '[t]tyd1'
-
-You should see something like:
-
-    747 ??  I      0:00.04 /usr/libexec/getty std.57600 ttyd1 
-
-9.7: How can I make my spare computer a dumb terminal connected to my
-      FreeBSD box?
-
-If you're using another computer as a terminal into your FreeBSD
-system, get a null modem cable to go between the two serial ports.  If
-you're using an actual terminal, see its accompanying instructions.
-
-Then, modify /etc/ttys, like above.  For example, if you're hooking up
-a WYSE-50 terminal to the fifth serial port, use an entry like this:
-
-    tty04 "/usr/libexec/getty std.38400" wyse50 on secure
-
-This example shows that the port on /dev/tty04 has a wyse50 terminal
-connected at 38400 bps with no parity (std.38400 from /etc/gettytab)
-and root logins are allowed (secure).  For directly-connected
-terminals, use the ttyXX entry.
-
-9.8: Why can't I run tip or cu?
-
-On your system, the programs tip and cu are probably executable only
-by uucp and group dialer.  You can use the group dialer to control who
-has access to your modem or remote systems.  Just add yourself to
-group dialer.
-
-Alternatively, you can let everyone on your system run tip and cu by
-typing:
-
-    chmod 4511 /usr/bin/tip
-
-You don't have to run this command for cu, since cu is just a hard
-link to tip.
-
-9.9: My stock Hayes modem isn't supported---what should I do?
-
-Actually, the man page for tip is out of date.  There is a generic
-Hayes dialer already built in.  Just use ``at=hayes'' in your
-/etc/remote file.
-
-The Hayes driver isn't smart enough to recognize some of the advanced
-features of newer modems---messages like BUSY, NO DIALTONE, or CONNECT
-115200 will just confuse it.  You should turn those messages off when
-you use tip (using ATX0&W).
-
-Also, the dial timeout for tip is 60 seconds.  Your modem should use
-something less, or else tip will think there's a communication
-problem.  Try ATS7=45&W.
-
-9.10: How am I expected to enter these AT commands without
-       resorting to some DOS-based terminal program?
-
-Make what's called a ``direct'' entry in your /etc/remote file.  For
-example, if your modem's hooked up to the first serial port,
-/dev/cuaa0, then put in the following line:
-
-    cuaa0:dv=/dev/cuaa0:br#19200:pa=none
-
-Use the highest bps rate your modem supports in the br capability.
-Then, type ``tip cuaa0'' and you'll be connected to your modem.
-
-If there is no /dev/cuaa0 on your system, do this:
-
-    cd /dev
-    MAKEDEV cuaa0
-
-9.11: Why doesn't the @ sign for the phone number capability work?
-
-The @ sign in the pn capability tells tip to look in /etc/phones for a
-phone number.  But the @ sign is also a special character in
-capability files like /etc/remote.  Escape it with a backslash:
-``pn=\@''.
-
-9.12: How can I dial a phone number on the command line?
-
-Put what's called a ``generic'' entry in your /etc/remote file.  For
-example:
-
-    tip115200|Dial any phone number at 115200 bps:\
-        :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du:
-    tip57600|Dial any phone number at 57600 bps:\
-        :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du:
-
-Then you can things like ``tip -115200 5551234''.  If you prefer cu
-over tip, use a generic cu entry:
-
-    cu115200|Use cu to dial any number at 115200bps:\
-        :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:
-
-and type ``cu 5551234 -s 115200''.
-
-9.13: Great---but how can I do that without having to specify the bps
-       rate on the command line?
-
-Put in an entry for tip1200 or cu1200, but go ahead and use whatever
-bps rate is appropriate with the br capability.  tip thinks a good
-default is 1200 bps which is why it looks for a ``tip1200'' entry.
-You don't have to use 1200 bps, though.
-
-9.14: I want separate entries for various hosts I access through a
-       terminal server, but I don't want to type ``CONNECT <host>''
-       each time once I'm connected.  Can tip do that for me?
-
-Yes.  Use the cm capability.  For example, these entries in
-/etc/remote:
-
-    pain|pain.deep13.com|Forrester's machine:\
-        :cm=CONNECT pain\n:tc=deep13:
-    muffin|muffin.deep13.com|Frank's machine:\
-        :cm=CONNECT muffin\n:tc=deep13:
-    deep13:Gizmonics Institute terminal server:\
-        :dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234:
-
-will let you type ``tip pain'' or ``tip muffin'' to connect to the
-hosts pain or muffin; and ``tip deep13'' to get to the terminal
-server.
-
-9.15: My university has 42 billion students but only 4 modem lines.
-       Can tip automatically try each line?
-
-Sure.  Make an entry for your university in /etc/remote and use \@ for
-the pn capability:
-
-    big-university:\
-        :pn=\@:tc=dialout
-    dialout:\
-        :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none:
-
-Then, list the phone numbers for the university in /etc/phones:
-
-    big-university 5551111
-    big-university 5551112
-    big-university 5551113
-    big-university 5551114
-
-tip will try each one in the listed order, then give up.  If you want
-to keep retrying, run tip in a while loop.
-
-9.16: How come I have to hit CTRL+P twice to send CTRL+P once?
-
-CTRL+P is the default ``force'' character, used to tell tip that the
-next character is literal data.  You can set the force character to
-any other character with the ~s escape, which means ``set a
-variable.''
-
-Type ``~sforce=<single-char>'' followed by a newline.  <single-char>
-is any single character.  If you leave out <single-char>, then the
-force character is the nul character, which you can get by typing
-CTRL+2 or CTRL+SPACE.  A pretty good value for <single-char> is
-SHIFT+CTRL+6, which I've seen only used on some terminal servers.
-
-You can have the force character be whatever you want by specifying
-the following in your $HOME/.tiprc file:
-
-    force=<single-char>
-
-9.17: Suddenly everything I type is all UPPER CASE.  What gives?
-
-You must've pressed CTRL+A, tip's ``raise character,'' specially
-designed for people with broken caps-lock keys.  Use ~s as above and
-set the variable ``raisechar'' to something reasonable.  In fact, you
-can set it to the same as the force character, if you never expect to
-use either of these features.
-
-Here's a sample .tiprc file perfect for Emacs users who need to type
-CTRL+2 and CTRL+A a lot:
-
-    force=^^
-    raisechar=^^
-
-The ^^ is SHIFT+CTRL+6.
-
-9.18: How can I do file transfers with tip?
-
-If you're talking to another UNIX system, you can send and receive
-files with ~p (put) and ~t (take).  These commands run ``cat'' and
-``echo'' on the remote system to accept and send files.  The syntax
-is:
-
-    ~p <local-file> [<remote-file>]
-    ~t <remote-file> [<local-file>]
-
-There's no error checking, so you probably should use another
-protocol, like zmodem.
-
-9.19: Okay, how can I run zmodem with tip?
-
-To receive files, start the sending program on the remote end.  Then,
-type ``~C rz'' to begin receiving them locally.
-
-To send files, start the receiving program on the remote end.  Then,
-type ``~C sz <files>'' to send them to the remote system.
-
-
-
-NOTE: Anyone wishing to submit a FAQ entry on how to get tip and cu working
-      would have it much appreciated!  We all use Kermit over here! :-)
-
------------------------------------------------------------------------------
-If you see a problem with this FAQ, or wish to submit an entry, please
-mail us at <FreeBSD-FAQ@FreeBSD.ORG>.  We appreciate your
-feedback, and cannot make this a better FAQ without your help!
-
-
-                                        FreeBSD Core Team
-
------------------------------------------------------------------------------
-
-ACKNOWLEDGMENTS:
-
-Ollivier Robert		- FreeBSD FAQ maintenance man 
-Gary Clark II           - Ex-FreeBSD FAQ maintenance man  
-Jordan Hubbard          - Janitorial services (I don't do windows)
-Garrett Wollman         - Networking and formatting
-Robert Oliver, Jr.      - Ideas and dumb questions (That made me think)
-Jim Lowe                - Multicast information 
-The FreeBSD Team        - Kvetching, moaning, submitting data
-
-And to any others we've forgotten, apologies and heartfelt thanks!
-
diff --git a/share/FAQ/Text/HW.TROUBLE b/share/FAQ/Text/HW.TROUBLE
deleted file mode 100644
index 86e3e42..0000000
--- a/share/FAQ/Text/HW.TROUBLE
+++ /dev/null
@@ -1,58 +0,0 @@
-$Id: HW.TROUBLE,v 1.3 1995/03/01 06:43:12 phk Exp $
-
-This file lists hardware, which doesn't do what it should do.
-
-Due to the nature of FreeBSD, we do not have the resources to test all
-possible kinds of hardware.  We do however every now and then find, buy
-or hear about hardware which doesn't work with FreeBSD or in general.
-
-This is that list.
-
-To be added to this list, a piece of hardware has to:
-	A: not do what it claims.
-or
-	B: not do what common sense would expect it to.
-
-Only if performance claims are wildly of the mark will it be listed here.
-
-All entries must have a date and a mail-address associated with them, to
-reflect when and by whom they were added.
-For multifunctional devices, please indicate if other parts of the device
-work OK, or are untested.
-For mutual incompabilities, list both devices.
-For SCSI and IDE-devices, list the string seen on boot of FreeBSD, if 
-possible, and trade name.
-Infer format from other entries, Keep sorted by first line.
-
-Thankyou.
-
----
-Controller, Data Technology DTC2280, "PC/AT Super I/O Card"
-IDE interface can be set to secondary address, but doesn't work there.  Suspect
-Interrupt isn't moved along.  Works fine on primary address.  Other parts of
-card not tested.
-19940828 phk@freefall.cdrom.com
----
-IDE-disk, <WDC AC2540H>, "Western Digital Caviar 2540"
-IDE-disk, <Maxtor 7345 AT>, "Maxtor 7345"
-Cannot coexist on the same IDE-controller.
-Jumpers not exhaustively experimented with, as neither of the companies 
-make sufficient information available.  Disk works fine when alone on
-IDE-controller.
-19940828 phk@freefall.cdrom.com
----
-IDE-disk, <AC31000> "Western Digital Caviar 31000"
-IDE-disk, <ST3550A> "Seagate ST3550A"
-Western Digital AC31000 (Caviar 31000) 1080 meg IDE drive will not
-co-exist with a Seagate ST3550A.
-The Seagate as master causes a constant drive light and system lockup,
-The WD will work fine alone or as master, but the Seagate is inaccessable
-if configured as slave in this config.                
-19950221 jbryant@server.iadfw.net
-
-On Packard Bell computers with a BIOS Reference ID of less than 25, Packard
-Bell will replace the BIOS at no charge.  I waited, I got the bios, popped
-the case, popped the chip, put in the new, and plugged in the drives.  It
-works.  WD as master, seagate as slave.         
-19950228 jbryant@server.iadfw.net
----
diff --git a/share/FAQ/Text/MIRROR.SITES b/share/FAQ/Text/MIRROR.SITES
deleted file mode 100644
index 96ed2ec..0000000
--- a/share/FAQ/Text/MIRROR.SITES
+++ /dev/null
@@ -1,145 +0,0 @@
-                          Mirror Sites
-                    For FreeBSD 2.0 and later
-
-$Id: MIRROR.SITES,v 1.16 1995/08/05 02:04:18 jkh Exp $
-
-The latest versions of FreeBSD (2.0 or later) are being mirrored at the
-following locations:
-
-Country		Site and Maintainer
-=======		=========================================================
-Australia	ftp://ftp.physics.usyd.edu.au/FreeBSD
-		<dawes@xfree86.org>
-
-Australia	ftp://minnie.cs.adfa.oz.au/FreeBSD
-		<wkt@dolphin.cs.adfa.oz.au>
-
-Canada          ftp://ftp.synapse.net/contrib/FreeBSD
-                <evanc@synapse.net>
-
-Finland		ftp://nic.funet.fi/pub/unix/FreeBSD
-		<count@nic.funet.fi>
-
-France		ftp://ftp.ibp.fr/pub/FreeBSD
-		<Remy.Card@ibp.fr>
-
-Germany		ftp://ftp.fb9dv.uni-duisburg.de/pub/unix/FreeBSD
-		<ftp@ftp.fb9dv.uni-duisburg.de>
-
-Germany		ftp://gil.physik.rwth-aachen.de/pub/FreeBSD
-		<kuku@gil.physik.rwth-aachen.de>
-
-Germany		ftp://ftp.uni-paderborn.de/freebsd
-		<ftp@uni-paderborn.de>
-
-Germany         ftp://ftp.leo.org/pub/comp/os/bsd/FreeBSD
-                <bsd@leo.org>
-
-Germany		ftp://ftp.tu-dresden.de/pub/soft/unix/bsd/FreeBSD
-		<pdsowner@rcs1.urz.tu-dresden.de>
-
-Ireland		ftp://ftp.internet-eireann.ie/pub/FreeBSD
-		<ftpadmin@internet-eireann.ie>
-
-Israel		ftp://orgchem.weizmann.ac.il/pub/FreeBSD
-		<serg@klara.weizmann.ac.il>
-
-Hong Kong	ftp://ftp.hk.super.net/pub/FreeBSD
-		<ftp-admin@HK.Super.NET>
-
-Korea		ftp://ftp.cau.ac.kr/pub/FreeBSD
-		<ftpadm@ftp.cau.ac.kr>
-
-Netherlands	ftp://ftp.nl.net/pub/os/FreeBSD
-		<archive@nl.net>
-
-Russia		ftp://ftp.kiae.su/FreeBSD
-		<ftp@ftp.kiae.su>
-
-Sweden		ftp://ftp.luth.se/pub/FreeBSD
-		<ragge@ludd.luth.se>
-
-Taiwan          ftp://NCTUCCCA.edu.tw/Operating-Systems/FreeBSD
-                <freebsd@NCTUCCCA.edu.tw>
-
-Taiwan		ftp://netbsd.csie.nctu.edu.tw/pub/FreeBSD
-		<ftp@netbsd.csie.nctu.edu.tw>
-
-Thailand	ftp://ftp.nectec.or.th/pub/FreeBSD
-		<ftpadmin@ftp.nectec.or.th>
-
-USA		ftp://gatekeeper.dec.com/pub/BSD/FreeBSD
-		<hubbard@gatekeeper.dec.com>
-
-USA		ftp://ftp.cybernetics.net/pub/FreeBSD
-		<michael@Cybernetics.NET>
-
-USA		ftp://ftp.neosoft.com/systems/FreeBSD
-		<smace@NeoSoft.COM>
-
-USA		ftp://kryten.atinc.com/pub/FreeBSD
-		<jmb@kryten.atinc.com>
-
-USA             ftp://ftp.dataplex.net/pub/FreeBSD
-                <rkw@dataplex.net>
-
-USA             ftp://ftp.cps.cmich.edu/pub/ftp.freebsd.org
-                <ftpadmin@cps.cmich.edu>
-
-USA		ftp://ftp.cslab.vt.edu/pub/FreeBSD
-		<ftp@ftp.cslab.vt.edu>
-
-Japan		ftp://ftp.tokyonet.ad.jp/pub/FreeBSD
-		<ftpadmin@TokyoNet.AD.JP>
-
-Japan		ftp://ftp.tut.ac.jp/FreeBSD
-		Ashida Hiroyuki <ashida@ftp.tut.ac.jp>
-
-Japan		ftp://ftp.sra.co.jp/pub/os/FreeBSD
-		<ftp-admin@sra.co.jp>
-
-Japan		ftp://ftp.ee.uec.ac.jp/pub/os/mirror/ftp.freebsd.org
-		<ftp-admin@ftp.ee.uec.ac.jp>
-
-Japan		ftp://ftp.mei.co.jp/free/PC-UNIX/FreeBSD
-		TANIGUCHI Syuuhei <tanig@isl.mei.co.jp>
-
-Japan		ftp://ftp.waseda.ac.jp/pub/FreeBSD
-		<ftp-admin@waseda.ac.jp>
-
-Japan		ftp://ftp.pu-toyama.ac.jp/pub/FreeBSD
-		Yoshihiko USUI <usui@pu-toyama.ac.jp>
-
-Japan           ftp://ftpsv1.u-aizu.ac.jp/pub/os/FreeBSD
-		<ftp-admin@u-aizu.ac.jp>
-
-UK		ftp://src.doc.ic.ac.uk/packages/unix/FreeBSD
-		<wizards@doc.ic.ac.uk>
-
-UK		ftp://unix.hensa.ac.uk/pub/walnut.creek/FreeBSD
-		<archive-admin@unix.hensa.ac.uk>
-
-UK		ftp://ftp.demon.co.uk/pub/BSD/FreeBSD
-		<uploads@demon.net>
-
----
-
-The latest versions of export-restricted code for FreeBSD (2.0C or later)
-(eBones and secure) are being made available at the following locations.
-
-If you are outside the U.S. or Canada, please get secure (DES) and
-eBones (Kerberos) from one of the following foreign distribution sites:
-
-Country		Site and Maintainer
-=======		========================================================
-South Africa	ftp://skeleton.mikom.csir.co.za/pub/FreeBSD
-		Mark Murray <mark@grondar.za>
-
-South Africa	ftp://storm.sea.uct.ac.za/pub/FreeBSD
-		Shaun Courtney <ftp@storm.sea.uct.ac.za>
-
-Brazil          ftp://ftp.iqm.unicamp.br/pub/FreeBSD
-                Pedro A M Vazquez <vazquez@iqm.unicamp.br>
-
-Finland		ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt
-		<count@nic.funet.fi>
diff --git a/share/FAQ/Text/README b/share/FAQ/Text/README
deleted file mode 100644
index 2e7293b..0000000
--- a/share/FAQ/Text/README
+++ /dev/null
@@ -1,104 +0,0 @@
-   -----------------------------------------
-       FreeBSD 2.0.5  ---  RELEASE Version             ,        ,
-   -----------------------------------------          /(        )`
-                                                      \ \___   / |
-Welcome to the 2.0.5 release of FreeBSD!  2.0.5 is    /- _  `-/  '
-an interim release of FreeBSD, filling a much needed (/\/ \ \   /\
-gap during the period between 2.0R (which was        / /   | `    \
-released in Nov 94) and 2.1R, which will be          O O   ) /    |
-released in late July of '95.  FreeBSD 2.0.5         `-^--'`<     '
-contains many substantial improvements from 2.0R,   (_.)  _  )   /
-not least of which is greater stability (by          `.___/`    /
-a considerable margin), dozens of new                  `-----' /
-features and a greatly enhanced           <----.     __ / __   \
-installation program.  See the release    <----|====O)))==) \) /====
-notes for more details on what's new in   <----'    `--' `.__,' \
-FreeBSD 2.0.5!                                         |        |
-                                                        \       /       /\
-                                                   ______( (_  / \______/
-                                                 ,'  ,-----'   |
-                                                 `--{__________)
-
-
-What is FreeBSD?  FreeBSD is an operating system based on 4.4 BSD Lite
-for Intel, AMD, Cyrix or NexGen "x86" based PC hardware.  It works
-with a very wide variety of PC peripherals and configurations and can
-be used for everything from software development to Internet Service
-Provision; the busiest site on the Internet, ftp.cdrom.com, is a
-FreeBSD machine!
-
-This release of FreeBSD contains everything you need to run such a
-system, plus full source code for everything.  With the source
-distribution installed you can literally recompile the entire system
-from scratch with one command, making it ideal for students,
-researchers or folks who simply want to see how it all works.
-
-A large collection of 3rd party ported software (the "ports
-collection") is also provided to make it easier for you to obtain and
-install all your favorite traditional UNIX utilities for FreeBSD.
-Over 270 ports, comprising everything from the EMACS editor to the
-lisp language, make FreeBSD a powerful and comprehensive operating
-system that rivals that of many large workstations for general utility
-and power.
-
-
-For more documentation on this system, it is recommended that you
-purchase the 4.4BSD Document Set from O'Reilly Associates and the
-USENIX Association, ISBN 1-56592-082-1.  We have no connection with
-O'Reilly, we're just satisfied customers!
-
-You may also wish to read the HARDWARE GUIDE *before* proceeding any
-further with the installation.  Configuring PC hardware for anything
-other than DOS/Windows (which don't actually make very significant
-demands on the hardware) is actually quite a bit harder than it looks,
-and if you think you understand PCs then you clearly haven't been
-using them for long enough! :) This guide will give you some tips on
-how to configure your hardware and what symptoms to watch for in case
-of trouble.  This guide is available in the Documentation menu of the
-FreeBSD boot floppy.
-
-DISCLAIMER: While FreeBSD does its best to safeguard against accidental
-loss of data, it's still more than possible to WIPE OUT YOUR ENTIRE DISK
-with this installation!  Please do not proceed to the final FreeBSD
-installation menu unless you've adequately backed up any important
-data first!  We really mean it!
-
-Technical comments on this release should be sent to:
-
-        hackers@FreeBSD.org
-
-
-Bug reports should be sent using the `send-pr' command, if you were
-able to get the system installed, otherwise to:
-
-        bugs@FreeBSD.org
-
-Please be sure to indicate WHICH VERSION of FreeBSD you're running in
-any bug reports!
-
-
-General questions should be sent to:
-
-        questions@FreeBSD.org
-
-Please have patience if your questions are not answered right away -
-this is an especially busy time for us, and our volunteer resources
-are often strained to the limit!  Bug reports submitted with the
-send-pr command are logged and tracked in our bugs database, and
-you'll be kept informed of any changes in status during the life of
-the bug (or feature request).
-
-Our WEB site, http://www.freebsd.org, is also a very good source for
-updated information and provides a number of advanced documentation
-facilities.  You may use the BSDI version of Netscape for browsing the
-World Wide Web directly from FreeBSD.
-
-You may also wish to look in /usr/share/FAQ and /usr/share/doc for
-further information on the system.
-
-
-Thanks for reading all of this, and we sincerely hope you enjoy this
-release of FreeBSD!
-
-                                Jordan Hubbard,
-                                for The FreeBSD Project
diff --git a/share/FAQ/Text/REGISTER.FreeBSD b/share/FAQ/Text/REGISTER.FreeBSD
deleted file mode 100644
index 8501628..0000000
--- a/share/FAQ/Text/REGISTER.FreeBSD
+++ /dev/null
@@ -1,85 +0,0 @@
-In the absence of any other mechanism for counting the number of users
-of FreeBSD, we like to kindly suggest that you take a few minutes to please
-register with the counter set up by <Harald.T.Alvestrand@uninett.no>.  
-
-The justification for such "registration" is twofold:  First, we really would
-like to know more about the size and demographics of our user-base in order
-to better support its needs.  Second, it's a sad fact of life that many
-people rely on counters and statistics (even when highly dubious) rather
-than on actual experience when chosing an operating system, and the best we
-can hope to do in such circumstances is to at least try to provide some
-indication of how popular we are (or are not).  This is not how we recommend
-that people go about chosing an operating system, but the necessity of
-such "marketing" remains an undeniable fact.
-
-The FreeBSD team does not necessarily feel that Harald's counter represents
-the best approach to such statistics gathering, and its accuracy can only
-be as good as people's willingness to register with it (and may not reflect
-the actual OS population at any single point in time), but in the total absence
-of any other mechanism for providing such useful statistics, it's certainly a
-start and we thank Harald for his efforts in providing this service.
-It's a community service, and of potential benefit to everyone (all *BSD
-users), so let's see if we can't make it work!
-
-Included below is the standard blurb from the counter.
-
-Thanks in advance,
-
-				The FreeBSD team.
-
-
-How to get registered
-=====================
-
-In brief:
-
-  [To register a running installation of FreeBSD]
-  Send E-mail to bsd-counter@uninett.no with the SUBJECT line
-  
-    "I use FreeBSD at <place>"
-
-Introduction
-============
-The intention of this counting project is to count all users of UNIXes
-that are:
-
- - BSD-derived
- - Freely available
-
-The variants NetBSD, 386BSD and FreeBSD are currently distinguished.
-
-(NOTE: Linux is NOT BSD-derived. If you use that, send mail to
-linux-counter@uninett.no instead!!!)
-
-The information is *not* used for any purpose but statistics, and unless
-you request it, information about single persons are *never* made public.
-(A list of users who have requested publication is available from the
-FTP file ftp://aun.uninett.no/pub/misc/386bsd/persons)
-
-How to register
-===============
-Send E-mail to bsd-counter@uninett.no
-
-The subject should be
-
-  I use FreeBSD|NetBSD|386BSD at <place>
-
-Where FreeBSD, NetBSD or 386BSD is the particular variant you're using
-and "place" can be school, work or home, or a combination of these.
-
-You will get back a letter with 3 things:
-
-  - An acknowledgement
-  - A form that you can fill out and send in with more information
-    about yourself, your machine, and your 386bsd-using friends
-  - A report giving the current status of the counter
-
-You can update your "vote" at any time, by sending an E-mail message
-from the same account. Duplicates will be weeded out.
-
-The current report, available by anonymous FTP to aun.uninett.no,
-directory pub/misc/386bsd-counter, file "short", is given below.
-
-For all questions, contact Harald.T.Alvestrand@uninett.no!
-
-$Id: REGISTER.FreeBSD,v 1.2 1994/12/01 13:24:20 jkh Exp $
diff --git a/share/FAQ/Text/RELNOTES.FreeBSD b/share/FAQ/Text/RELNOTES.FreeBSD
deleted file mode 100644
index 9b6c5c6..0000000
--- a/share/FAQ/Text/RELNOTES.FreeBSD
+++ /dev/null
@@ -1,723 +0,0 @@
-                                 RELEASE NOTES
-                                    FreeBSD
-                                 Release 2.0.5
-
-1. Technical overview
----------------------
-
-FreeBSD is a freely available, full source 4.4 BSD Lite based release
-for Intel i386/i486/Pentium (or compatible) based PC's.  It is based
-primarily on software from U.C. Berkeley's CSRG group, with some
-enhancements from NetBSD, 386BSD, and the Free Software Foundation.
-
-Since our release of FreeBSD 2.0 some 8 months ago, the performance,
-feature set, and stability of FreeBSD has improved dramatically.  The
-largest change is a revamped VM system with a merged VM/file buffer
-cache that not only increases performance, but reduces FreeBSD's
-memory footprint, making a 4MB configuration a more acceptible
-minimum.  Other enhancements include full NIS client and server
-support, transaction TCP support, dial-on-demand PPP, an improved SCSI
-subsystem, early ISDN support, support for FDDI and Fast Ethernet
-(100Mbit) adapters, improved support for the Adaptec 2940 (WIDE and
-narrow) and many hundreds of bug fixes.
-
-We've also taken the comments and suggestions of many of our users to
-heart and have attempted to provide what we hope is a more sane and
-easily understood installation process.  Your feedback on this
-(constantly evolving) process is especially welcome!
-
-In addition to the base distributions, FreeBSD offers a new ported
-software collection with some 270 commonly sought-after programs.  The
-list of ports ranges from http (WWW) servers, to games, languages,
-editors and almost everything in between.  The entire ports collection
-requires only 10MB of storage, all ports being expressed as "deltas"
-to their original sources.  This makes it much easier for us to update
-ports, and greatly reduces the disk space demands made by the older
-1.0 ports collection.  To compile a port, you simply change to the
-directory of the program you wish to install, type make and let the
-system do the rest.  The full original distribution for each port you
-build is retrieved dynamically off of CDROM or a local ftp site, so
-you need only enough disk space to build the ports you want.  Each
-port is also provided as a pre-compiled "package" which can be
-installed with a simple command (pkg_add) by those who do not wish to
-compile their own ports from source.  See the file:
-        /usr/share/FAQ/Text/ports.FAQ
-for a more complete description of the ports collection.
-
-
-Since our first release of FreeBSD 1.0 nearly two years ago, FreeBSD
-has changed almost entirely.  A new port from the Berkeley 4.4 code
-base was done, which brought the legal status of the system out of the
-shadows with the blessing of Novell (the new owners of USL and UNIX).  The
-port to 4.4 has also brought in a host of new features, filesystems
-and enhanced driver support.  With our new unencumbered code base, we
-have every reason to hope that we'll be able to release quality
-operating systems without further legal encumbrance for some time to
-come!
-
-FreeBSD 2.0.5 represents the culmination of 2 years of work and many
-thousands of man hours put in by an international development team.
-We hope you enjoy it!
-
-For a list of contributors and a general project description, please see
-the file "CONTRIB.FreeBSD" which should be bundled with your binary
-distribution.
-
-Also see the "REGISTER.FreeBSD" file for information on registering
-with the "Free BSD user counter".   This counter is for ALL freely
-available variants of BSD, not just FreeBSD, and we urge you to register
-yourself with it.
-
-The core of FreeBSD does not contain DES code which would inhibit its
-being exported outside the United States.  There is an add-on package
-to the core distribution, for use only in the United States, that
-contains the programs that normally use DES.  The auxiliary packages
-provided separately can be used by anyone.   A freely (from outside the
-U.S.) exportable European distribution of DES for our non-U.S. users also
-exists and is described in the FreeBSD FAQ.
-
-If password security for FreeBSD is all you need, and you have no
-requirement for copying encrypted passwords from different hosts
-(Suns, DEC machines, etc) into FreeBSD password entries, then
-FreeBSD's MD5 based security may be all you require!  We feel that our
-default security model is more than a match for DES, and without any
-messy export issues to deal with.  If you're outside (or even inside)
-the U.S., give it a try!
-
-
-1.1 What's new in 2.0.5?
-----------------------
-
-The following features were added or substantially improved between
-the release of 2.0 and this 2.0.5 release.  In order to facilitate
-better communication, the person, or persons, responsible for each
-enhancement is noted.  Any questions regarding the new functionality
-should be directed to them first.
-
-KERNEL:
-
-Merged VM-File Buffer Cache
----------------------------
-A merged VM/buffer cache design greatly enhances overall system
-performance and makes it possible to do a number of more optimal
-memory allocation strategies that were not possible before.
-
-Owner:                  David Greenman (davidg@FreeBSD.org) and
-                        John Dyson (dyson@implode.root.com)
-
-
-Network PCB hash optimization
------------------------------
-For systems with a great number of active TCP connections (WEB and ftp
-servers, for example), this greatly speeds up the lookup time required
-to match an incoming packet up to its associated connection.
-
-Owner:                  David Greenman (davidg@FreeBSD.org)
-
-
-Name cache optimization
------------------------
-The name-cache would cache all files of the same name to the same bucket,
-which would put for instance all ".." entries in the same bucket.  We added
-the parent directory version to frustrate the hash, and improved the 
-management of the cache in various other ways while we were at it.
-
-Owner:			Poul-Henning Kamp (phk@FreeBSD.org)
-			David GreenMan (davidg@FreeBSD.org)
-
-
-Less restrictive swap-spaces
-----------------------------
-The need to compile the names of the swap devices into the kernel has been
-removed.  Now swapon will accept any block devices, up to the maximum
-number of swap devices configured in the kernel.
-
-Owner:			Poul-Henning Kamp (phk@FreeBSD.org)
-			David GreenMan (davidg@FreeBSD.org)
-
-
-Hard Wired SCSI Devices
------------------------
-Prior to 2.0.5, FreeBSD performed dynamic assignment of unit numbers
-to SCSI devices as they were probed, allowing a SCSI device failure to
-possibly change unit number assignment and prevent filesystems on
-still functioning disks from mounting.  Hard wiring allows static
-allocation of unit numbers (and hence device names) to scsi devices
-based on SCSI ID and bus.  SCSI configuration occurs in the kernel
-config file.  Samples of the configuration syntax can be found in the
-scsi(4) man page or the LINT kernel config file.
-
-Owner:                  Peter Dufault (dufault@hda.com)
-Sources involved:       sys/scsi/* usr.sbin/config/*
-
-
-Slice Support
--------------
-FreeBSD now supports a "slice" abstraction which makes it more
-completely interoperable with other operating system partitions.  This
-support will allow FreeBSD to inhabit DOS extended partitions.
-
-Owner:                  Bruce Evans (bde@FreeBSD.org)
-Sources involved:       sys/disklabel.h sys/diskslice.h sys/dkbad.h
-                        kern/subr_diskslice.c kern/subr_dkbad.c
-                        i386/isa/diskslice_machdep.c
-                        i386/isa/wd.c scsi/sd.c dev/vn/vn.c
-
-
-Support for Ontrack Disk Manager Version 6.0
---------------------------------------------
-Support has been added for disks which use Ontrack Disk Manager.  The
-fdisk program does NOT know about it however, so make all changes
-using the install program on the boot.flp or the Ontrack Disk Manager
-tool under DOS.
-
-Owner:			Poul-Henning Kamp (phk@FreeBSD.org)
-
-
-Bad144 is back and working
---------------------------
-Bad144 works again, though the semantics are slightly different than
-before in that the bad-spots are kept relative to the slice rather
-than absolute on the disk.
-
-Owner:                  Bruce Evans (bde@FreeBSD.org)
-			Poul-Henning Kamp (phk@FreeBSD.org)
-
-
-NEW DEVICE SUPPORT:
-
-                        SCSI and CDROM Devices
-
-Matsushita/Panasonic (Creative) CD-ROM driver
----------------------------------------------
-The Matsushita/Panasonic CR-562 and CR-563 drives are now supported
-when connected to a Sound Blaster or 100% compatible host adapter.  Up
-to four host adapters are supported for a total of 16 CD-ROM drives.
-The audio functions are supported with the Karoke variable speed
-playback.
-
-Owner:                  Frank Durda IV   bsdmail@nemesis.lonestar.org
-Sources involved:       isa/matcd
-
-
-Adaptec 2742/2842/2940 SCSI driver
------------------------------
-The original 274x/284x driver has evolved considerably since the 2.0
-release.  We now offer full support for the 2940 series as well as the
-Wide models of these cards.  The arbitration bug (as well as many
-others) that caused the driver problems with fast devices has been
-corrected and there is even experimental tagged queuing support
-(kernel option "AHC_TAGENABLE").  John Aycock has also released the
-sequencer code under a "Berkeley style" copyright making the driver
-entirely clean of the GPL.
-
-Owner:                  Justin Gibbs (gibbs@FreeBSD.org)
-Sources involved:       isa/aic7770.c pci/aic7870.c i386/scsi/*
-                        sys/dev/aic7xxx/*
-
-
-NCR5380/NCR53400 SCSI ("ProAudio Spectrum") driver
---------------------------------------------------
-Owner:                  core
-Submitted by:           Serge Vakulenko (vak@cronyx.ru)
-Sources involved:       isa/ncr5380.c
-
-
-Sony CDROM driver
------------------
-Owner:                  core
-Submitted by:           Mikael Hybsch (micke@dynas.se)
-Sources involved:       isa/scd.c
-
-
-                        Serial Devices
-
-SDL Communications Riscom/8 Serial Board Driver
------------------------------------------------
-Owner:                  Andrey Chernov (ache@FreeBSD.org)
-Sources involved:       isa/rc.c isa/rcreg.h
-
-
-Cyclades Cyclom-y Serial Board Driver
--------------------------------------
-Owner:                  Bruce Evans (bde@FreeBSD.org)
-Submitted by:           Andrew Werple (andrew@werple.apana.org.au) and
-                        Heikki Suonsivu (hsu@cs.hut.fi)
-Obtained from:          NetBSD
-Sources involved:       isa/cy.c
-
-
-Cronyx/Sigma sync/async serial driver
--------------------------------------
-Owner:                  core
-Submitted by:           Serge Vakulenko
-Sources involved:       isa/cronyx.c            
-
-
-
-                        Networking
-
-Diskless booting
-----------------
-Diskless booting in 2.0.5 is much improved.  The boot-program is in
-src/sys/i386/boot/netboot, and can be run from an MSDOS system or
-burned into an EPROM.  Local swapping is also possible.  WD, SMC, 3COM
-and Novell ethernet cards are currently supported.
-
-
-DEC DC21140 Fast Ethernet driver
---------------------------------
-This driver supports any of the numerous NICs using the DC21140 chipset 
-including the 100Mb DEC DE-500-XA and SMC 9332.
-
-Owner:                  core
-Submitted by:           Matt Thomas (thomas@lkg.dec.com)
-Sources involved:       pci/if_de.c pci/dc21040.h
-
-
-DEC FDDI (DEFPA/DEFEA) driver
------------------------------
-Owner:                  core
-Submitted by:           Matt Thomas (thomas@lkg.dec.com)
-Sources involved:       pci/if_pdq.c pci/pdq.c pci/pdq_os.h pci/pdqreg.h
-
-
-3Com 3c505 (Etherlink/+) NIC driver
------------------------------------
-Owner:                  core
-Submitted by:           Dean Huxley (dean@fsa.ca)
-Obtained from:          NetBSD
-Sources involved:       isa/if_eg.c
-
-
-Fujitsu MB86960A family of NICs driver
--------------------------------------
-Owner:                  core
-Submitted by:           M.S. (seki@sysrap.cs.fujitsu.co.jp)
-Sources involved:       isa/if_fe.c
-
-
-Intel EtherExpress driver
--------------------------
-Owner:                  Rodney W. Grimes (rgrimes@FreeBSD.org)
-Sources involved:       isa/if_ix.c isa/if_ixreg.h
-
-
-3Com 3c589 driver
------------------
-Owner:                  core
-Submitted by:           "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp),
-                        Seiji Murata (seiji@mt.cs.keio.ac.jp) and
-                        Noriyuki Takahashi (hor@aecl.ntt.jp)
-Sources involved:       isa/if_zp.c
-
-
-IBM Credit Card Adapter driver
-------------------------------
-Owner:                  core
-Submitted by:           "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp),
-Sources involved:       isa/pcic.c isa/pcic.h
-
-
-EDSS1 and 1TR6 ISDN interface driver
-------------------------------------
-Owner:                  core
-Submitted by:           Dietmar Friede (dfriede@drnhh.neuhaus.de) and
-                        Juergen Krause (jkr@saarlink.de)
-Sources involved:       gnu/isdn/*
-
-
-                        Miscellaneous Drivers
-
-Joystick driver
----------------
-Owner:                  Jean-Marc Zucconi (jmz@FreeBSD.org)
-Sources involved:       isa/joy.c
-
-
-National Instruments "LabPC" driver
------------------------------------
-Owner:                  Peter Dufault (dufault@hda.com)
-Sources involved:       isa/labpc.c
-
-
-WD7000 driver
--------------
-Owner:                  Olof Johansson (offe@ludd.luth.se)
-
-
-Pcvt Console driver
--------------------
-Owner:                  Joerg Wunsch (joerg@FreeBSD.org)
-Submitted by:           Hellmuth Michaelis (hm@altona.hamburg.com)
-Sources involved:       isa/pcvt/*
-
-
-BSD-audio emulator for VAT driver
----------------------------------
-Owner:                  Amancio Hasty (ahasty@FreeBSD.org) and
-                        Paul Traina (pst@FreeBSD.org)
-Sources involved:       isa/sound/vat_audio.c isa/sound/vat_audioio.h
-
-
-National Instruments AT-GPIB and AT-GPIB/TNT GPIB driver
---------------------------------------------------------
-Owner:                  core
-Submitted by:           Fred Cawthorne (fcawth@delphi.umd.edu)
-Sources involved:       isa/gpib.c isa/gpib.h isa/gpibreg.h
-
-
-Genius GS-4500 hand scanner driver
-----------------------------------
-Owner:                  core
-Submitted by:           Gunther Schadow (gusw@fub46.zedat.fu-berlin.de)
-Sources involved:       isa/gsc.c isa/gscreg.h
-
-
-CORTEX-I Frame Grabber
-----------------------
-Owner:                  core
-Submitted by:           Paul S. LaFollette, Jr. (
-Sources involved:       isa/ctx.c isa/ctxreg.h
-
-
-Video Spigot video capture card
--------------------------------
-Owner:                  Jim Lowe
-
-
-
-1.2 Experimental features
----------------------------------------------
-
-The unionfs and LFS file systems are known to be severely broken in
-2.0.5.  This is in part due to old bugs that we haven't had time to
-resolve yet and the need to update these file systems to deal with the
-new VM system.  We hope to address these issues in a later release of
-FreeBSD.
-
-FreeBSD now supports running iBCS2 compatible binaries (currently SCO
-UNIX 3.2.2 & 3.2.4 and ISC 2.2 COFF format are supported).  The iBCS2
-emulator is in its early stages, but it is functional, we haven't been
-able to do exhaustive testing (lack of commercial apps), but almost
-all of SCO's 3.2.2 binaries are working, so is an old INFORMIX-2.10
-for SCO. Further testing is nessesary to complete this project. There
-is also work under way for ELF & XOUT loaders, and most of the svr4
-syscall wrappers have been written.
-
-Owner:                  Soren Schmidt (sos) & Sean Eric Fagan (sef)
-Sources involved:       sys/i386/ibcs2/* + misc kernel changes.
-=======
-
-
-2. Supported Configurations
----------------------------
-
-FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus
-based PC's, ranging from 386sx to Pentium class machines (though the
-386sx is not recommended).  Support for generic IDE or ESDI drive
-configurations, various SCSI controller, network and serial cards is
-also provided.
-
-Following is a list of all disk controllers and ethernet cards currently
-known to work with FreeBSD.  Other configurations may very well work, and
-we have simply not received any indication of this.
-
-
-2.1. Disk Controllers
-
-WD1003 (any generic MFM/RLL)
-WD1007 (any generic IDE/ESDI)
-WD7000
-IDE
-ATA
-
-Adaptec 152x series ISA SCSI controllers
-Adaptec 154x series ISA SCSI controllers
-Adaptec 174x series EISA SCSI controller in standard and enhanced mode.
-Adaptec 274X/284X/2940 (Narrow/Wide/Twin) series ISA/EISA/PCI SCSI controllers
-Adaptec AIC-6260 and AIC-6360 based boards, which includes
-the AHA-152x and SoundBlaster SCSI cards.
-
-** Note: You cannot boot from the SoundBlaster cards
-as they have no on-board BIOS, which is necessary for mapping
-the boot device into the system BIOS I/O vectors.
-They're perfectly usable for external tapes, CDROMs, etc,
-however.  The same goes for any other AIC-6x60 based card
-without a boot ROM.  Some systems DO have a boot ROM, which
-is generally indicated by some sort of message when the system
-is first powered up or reset.  Check your system/board documentation
-for more details.
-
-[Note that Buslogic was formerly known as "Bustec"]
-Buslogic 545S & 545c
-Buslogic 445S/445c VLB SCSI controller
-Buslogic 742A, 747S, 747c EISA SCSI controller.
-Buslogic 946c PCI SCSI controller
-Buslogic 956c PCI SCSI controller
-
-NCR 53C810 and 53C825 PCI SCSI controller.
-NCR5380/NCR53400 ("ProAudio Spectrum") SCSI controller. 
-
-DTC 3290 EISA SCSI controller in 1542 emulation mode.
-
-UltraStor 14F, 24F and 34F SCSI controllers.
-
-Seagate ST01/02 SCSI controllers.
-
-Future Domain 8xx/950 series SCSI controllers.
-
-With all supported SCSI controllers, full support is provided for
-SCSI-I & SCSI-II peripherals, including Disks, tape drives (including
-DAT) and CD ROM drives.
-The following CD-ROM type systems are supported at this time:
-(cd)    SCSI (also includes ProAudio Spectrum and SoundBlaster SCSI)
-(mcd)   Mitsumi proprietary interface 
-(matcd) Matsushita/Panasonic (Creative) proprietary interface
-(scd)   Sony proprietary interface
-
-Note: CD-Drives with IDE interfaces are not supported at this time.
-
-Some controllers have limitations with the way they deal with >16MB of
-memory, due to the fact that the ISA bus only has a DMA address space
-of 24 bits.  If you do your arithmetic, you'll see that this makes it
-impossible to do direct DMA to any address >16MB.  This limitation is
-even true of some EISA controllers (which are normally 32 bit) when
-they're configured to emulate an ISA card, which they then do in *all*
-respects.  This problem is avoided entirely by IDE controllers (which
-do not use DMA), true EISA controllers (like the UltraStor, Adaptec
-1742A or Adaptec 2742) and most VLB (local bus) controllers.  In the
-cases where it's necessary, the system will use "bounce buffers" to
-talk to the controller so that you can still use more than 16Mb of
-memory without difficulty.
-
-
-2.2. Ethernet cards
-
-SMC Elite 16 WD8013 ethernet interface, and most other WD8003E,
-WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT
-based clones.  SMC Elite Ultra is also supported.
-
-DEC EtherWORKS III NICs (DE203, DE204, and DE205)
-DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422)
-DEC DC21140 based NICs (SMC???? DE???)
-DEC FDDI (DEFPA/DEFEA) NICs
-
-Fujitsu MB86960A family of NICs
-
-Intel EtherExpress
-
-Isolan AT 4141-0 (16 bit)
-Isolink 4110     (8 bit)
-
-Novell NE1000, NE2000, and NE2100 ethernet interface.
-
-3Com 3C501 cards
-
-3Com 3C503 Etherlink II
-
-3Com 3c505 Etherlink/+
-
-3Com 3C507 Etherlink 16/TP
-
-3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III
-
-Toshiba ethernet cards
-
-PCMCIA ethernet cards from IBM and National Semiconductor are also
-supported.
-
-
-2.3. Misc
-
-AST 4 port serial card using shared IRQ.
-
-ARNET 8 port serial card using shared IRQ.
-
-BOCA ATIO66 6 port serial card using shared IRQ.
-
-Cyclades Cyclom-y Serial Board.
-
-STB 4 port card using shared IRQ.
-
-Mitsumi (all models) CDROM interface and drive.
-
-SDL Communications Riscom/8 Serial Board.
-
-Soundblaster SCSI and ProAudio Spectrum SCSI CDROM interface and drive.
-
-Matsushita/Panasonic (Creative SoundBlaster) CDROM interface and drive.
-
-Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound
-and Roland MPU-401 sound cards.
-
-FreeBSD currently does NOT support IBM's microchannel (MCA) bus, but
-support is apparently close to materializing.  Details will be posted
-as the situation develops.
-
-
-3. Obtaining FreeBSD.
----------------------
-
-You may obtain FreeBSD in a variety of ways:
-
-1. FTP/Mail
-
-You can ftp FreeBSD and any or all of its optional packages from
-`ftp.freebsd.org' - the offical FreeBSD release site.
-
-For other locations that mirror the FreeBSD software see the file
-MIRROR.SITES.  Please ftp the distribution from the nearest site
-to you netwise.
-
-If you do not have access to the internet and electronic mail is your
-only recourse, then you may still fetch the files by sending mail to
-`ftpmail@decwrl.dec.com' - putting the keyword "help" in your message
-to get more information on how to fetch files from freebsd.cdrom.com.
-Note: This approach will end up sending many *tens of megabytes*
-through the mail, and should only be employed as an absolute LAST
-resort!
-
-
-2. CDROM
-
-FreeBSD 2.0.5 may be ordered on CDROM from:
-
-        Walnut Creek CDROM
-        4041 Pike Lane, Suite D
-        Concord CA  94520
-        1-800-786-9907, +1-510-674-0783, +1-510-674-0821 (fax)
-
-Or via the internet from orders@cdrom.com or http://www.cdrom.com.
-Their current catalog can be obtained via ftp as:
-        ftp://ftp.cdrom.com/cdrom/catalog.
-
-Cost is $39.95.  Shipping (per order not per disc) is $5 in the US,
-Canada, or Mexico and $10.00 overseas.  They accept Visa, Mastercard,
-American Express, and ship COD within the United States.  California
-residents please add 8.25% sales tax.
-
-Should you be dissatisfied for any reason, the CD comes with an
-unconditional return policy.
-
-
-Reporting problems, making suggestions, submitting code.
------------------------------------------------------------
-
-Your suggestions, bug reports and contributions of code are always
-valued - please do not hesitate to report any problems you may find
-(preferably with a fix attached if you can!).
-
-The preferred method to submit bug reports from a machine with
-internet mail connectivity is to use the send-pr command.  Bug reports
-will be dutifully filed by our faithful bugfiler program and you can
-be sure that we'll do our best to respond to all reported bugs as soon
-as possible.
-
-If, for some reason, you are unable to use the send-pr command to
-submit a bug report, you can try to send it to:
-
-                bugs@FreeBSD.org
-
-
-Otherwise, for any questions or suggestions, please send mail to:
-
-                questions@FreeBSD.org
-
-Additionally, being a volunteer effort, we are always happy to have
-extra hands willing to help - there are already far more enhancements
-to be done than we can ever manage to do by ourselves!  To contact us
-on technical matters, or with offers of help, you may send mail to:
-
-                hackers@FreeBSD.org
-
-Since these mailing lists can experience significant amounts of
-traffic, if you have slow or expensive mail access and you are
-only interested in keeping up with significant FreeBSD events, you may
-find it preferable to subscribe to:
-
-                announce@FreeBSD.org
-
-
-All but the freebsd-bugs groups can be freely joined by anyone wishing
-to do so.  Send mail to MajorDomo@FreeBSD.org and include the keyword
-`help' on a line by itself somewhere in the body of the message.  This
-will give you more information on joining the various lists, accessing
-archives, etc.  There are a number of mailing lists targeted at
-special interest groups not mentioned here, so send mail to majordomo
-and ask about them!
-
-
-6. Acknowledgements
--------------------
-
-FreeBSD represents the cumulative work of many dozens, if not
-hundreds, of individuals from around the world who have worked very
-hard to bring you this release.  It would be very difficult, if not
-impossible, to enumerate everyone who's contributed to FreeBSD, but
-nonetheless we shall try (in alphabetical order, of course). If your
-name is not mentioned, please be assured that its omission is entirely
-accidental.
-
-
-The Computer Systems Research Group (CSRG), U.C. Berkeley.
-
-Bill Jolitz, for his initial work with 386BSD.
-
-The FreeBSD Core Team
-(in alphabetical order by first name):
-
-        Andreas Schulz <ats@FreeBSD.org>
-        Andrey A. Chernov <ache@FreeBSD.org>
-        Bruce Evans <bde@FreeBSD.org>
-        David Greenman <davidg@FreeBSD.org>
-        Garrett A. Wollman <wollman@FreeBSD.org>
-        Gary Palmer <gpalmer@FreeBSD.org>
-        Geoff Rehmet <csgr@FreeBSD.org>
-        Jack Vogel <jackv@FreeBSD.org>
-        John Dyson <dyson@FreeBSD.org>
-        Jordan K. Hubbard <jkh@FreeBSD.org>
-        Justin Gibbs <gibbs@FreeBSD.org>
-        Paul Richards <paul@FreeBSD.org>
-        Poul-Henning Kamp <phk@FreeBSD.org>
-        Rich Murphey <rich@FreeBSD.org>
-        Rodney W. Grimes <rgrimes@FreeBSD.org>
-        Satoshi Asami <asami@FreeBSD.org>
-        Søren Schmidt <sos@FreeBSD.org>
-
-Special mention to:
-
-        Walnut Creek CDROM, without whose help (and continuing support)
-        this release would never have been possible.
-
-        Dermot McDonnell for his donation of a Toshiba XM3401B CDROM
-        drive.
-
-        Additional FreeBSD helpers and beta testers:
-
-        J.T. Conklin                            Julian Elischer
-        Frank Durda IV                          Peter Dufault
-        Sean Eric Fagan                         Jeffrey Hsu
-        Terry Lambert                           L Jonas Olsson
-        Chris Provenzano                        Dave Rivers
-        Guido van Rooij                         Steven Wallace
-        Atsushi Murai                           Scott Mace
-        Nate Williams
-
-        And everyone at Montana State University for their initial support.
-
-
-Jordan would also like to give special mention to Poul-Henning Kamp
-and Gary Palmer, both of whom put in long hours helping him to
-construct the new installation utility.  Poul, being a proud new
-father, was especially pressed for time yet somehow managed to put in
-significant amount of effort anyway and this release could not have
-happened without him.  Thank you both!
-
-Thanks also to everyone else who helped, especially those not
-mentioned, and we sincerely hope you enjoy this release of FreeBSD!
-
-
-                        The FreeBSD Core Team
-
-$Id: RELNOTES.FreeBSD,v 1.6 1995/05/28 18:56:01 phk Exp $
diff --git a/share/FAQ/Text/ROADMAP b/share/FAQ/Text/ROADMAP
deleted file mode 100644
index 9561691..0000000
--- a/share/FAQ/Text/ROADMAP
+++ /dev/null
@@ -1,58 +0,0 @@
-This directory contains frequently asked questions, short user guides,
-tutorials and other miscellaneous information that may be of help
-to the beginning (or even advanced) FreeBSD user.  Any submissions
-to this directory should be sent to:
-
-                        FreeBSD-FAQ@FreeBSD.ORG
-
-For inclusion with the next release.  Your contributions are not only
-welcome, but often save new users from uncountable headaches!  If you've
-written something you think may help new users, please - by all means
-send it to us!
-
-Thanks!
-
-					The FreeBSD Project
-
-----
-ROADMAP:
-
-File				Description
-===============================================================================
-ESDI.FAQ			All about installing FreeBSD on older
-				ESDI/MFM drives.
-
-FreeBSD.FAQ			The overall FreeBSD FAQ - posted regularly to
-				USENET.
-
-FreeBSD-1.1.FAQ			FreeBSD FAQ for versions 1.1.5.1 and below.
-
-HW.TROUBLE			User feedback on finicky or broken hardware.
-
-MIRROR.SITES			A list of all sites mirroring FreeBSD 2.x.
-
-NFS.FAQ				Tips for users using NFS between FreeBSD
-				and workstation hardware.
-
-Systems.FAQ			Systems and configurations on which FreeBSD
-				is "known" to work.
-
-Systems-1.1.FAQ			Systems for 1.1.5.1 and below
-
-current-policy.FAQ		What you should know about running
-				FreeBSD-current.
-
-kernel-debug.FAQ		How to debug kernels for 1.1.5.1 and below.
-
-mailing-list.FAQ		All about the FreeBSD mailing lists.
-
-ports-supfile			A sample supfile for the FreeBSD ports
-				collection.
-
-slip-dialup			How to configure SLIP.
-
-standard-supfile		A sample supfile for the FreeBSD source tree.
-
-sup.FAQ				All about sup in general.
-
-
diff --git a/share/FAQ/Text/TROUBLESHOOTING b/share/FAQ/Text/TROUBLESHOOTING
deleted file mode 100644
index d1cb25f..0000000
--- a/share/FAQ/Text/TROUBLESHOOTING
+++ /dev/null
@@ -1,185 +0,0 @@
-Troubleshooting Tips - or "These are the times that try men's souls"
---------------------------------------------------------------------
-
-The following tips and tricks may help you turn a failing (or failed)
-installation attempt into a success.  Please read them carefully.
-
----
-
-Symptom:	Hardware conflict or misconfiguration.
-		Device not being found when it should be.
-
-Problem:	A device is conflicting with another, or its settings
-		don't match the kernel's expected IRQ or address.
-
-Explanation:	While most device drivers in FreeBSD are now smart
-		enough to match themselves to your hardware settings
-		dynamically, there are a few that still require fairly
-		rigid configuration parameters to be compiled in (and
-		matched by the hardware) before they'll work.  We're
-		working hard to eliminate as many of these last
-		hold-outs as we can, but it's not always as easy as
-		it looks.
-
-Solution:	There are several possible solutions.  The first,
-		and easiest, is to boot the kernel with the -c flag.
-		When you see the initial boot prompt (from floppy or
-		hard disk), type:
-
-			/kernel -c
-
-		This will boot just past the memory sizing code and
-		then drop into a dynamic kernel configuration utility.
-		Type `?' at the prompt to see a list of commands.  You
-		can use this utility to reset the IRQ, memory address,
-		IO address or a number of other device configuration
-		parameters.  You can also disable a device entirely
-		if it's causing problems for other devices you'd much
-		rather have work.  Note that this only affects the
-		kernel being booted temporarily, it does not "write out"
-		the information to the kernel so that these settings
-		are permanantly altered (this would be actually rather
-		hard).  If you reboot, you'll have to make the same
-		changes again.  The goal of the -c utility is to get
-		you up far enough to be able to download the appropriate
-		sources and configure and rebuild a kernel more specific
-		to your needs.
-
-		Another solution is, obviously, to remove the offending
-		hardware or simply strip the system down to the bare
-		essentials until the problem (hopefully) goes away.
-		Once you're up, you can do the same thing mentioned
-		above - compile a kernel more suited to your hardware,
-		or incrementally try to figure out what it was about
-		your original hardware configuration that didn't work.
-
----
-Symptom:       	My floppy-tape drive isn't probed.
-
-Problem:	Last-minute problems with this driver caused it to be disabled
-		by default.
-
-Solution:       Boot with -c (described above) and set the flags value of
-                fdc0 to 1. This will re-enable the floppy tape driver.
-                Sorry, but it was causing problems for people without floppy
-		tape drives!
----
-
-Symptom:	When I boot for the first time, it still looks for /386bsd!
-
-Problem:	You still have the old FreeBSD 1.x boot blocks on your
-		boot partition.
-
-Solution:	You should re-enter the installation process, invoke
-		the (F)disk editor and chose the (W)rite option.  This
-		won't hurt an existing installation and will make sure
-		that the new boot blocks get written to the drive.
-		If you're installing for the first time, don't forget
-		to (W)rite out your new boot blocks! :-)
-
----
-
-Symptom:	I want to boot FreeBSD off the second drive.  It doesn't!
-
-Problem:	FreeBSD will actually install just fine on a drive other
-		than 0 (the first drive), and the boot manager will even
-		allow you to select it, but the boot blocks rather
-		pathologically assume 0.  This should be fixed in 2.1.
-
-Solution:	Easy - follow these steps:
-
-		1.  Select the first (0) drive from the (F)disk editor
-		    and write out the boot manager with the (B) option.
-		    This will enable the boot manager that allows you to
-		    actually boot off the other drive.
-
-		2.  Exit the fdisk editor for the first drive and and
-		    re-enter it again for the drive you wish to install
-		    on.  Set up a partition on this drive, or select
-		    (A)ll for the entire drive.
-
-		3.  Enter the disklabel editor and allocate space on
-		    your second drive as normal.  Proceed with the
-		    installation.
-
-		4.  Once you've installed on the disk and are going to
-		    reboot from the hard disk, enter the following at
-		    the boot prompt:
-
-				wd(1,a)/kernel
-
-		    [ If you're using a SCSI drive, substitute
-		      `sd' for `wd' above ]
-
-		    This will ensure that you really boot from the second
-		    drive.  If you've actually installed on a drive other
-		    than 1 (the 3rd or 4th drive?), substitute that number
-		    in for the above.  You will need to enter this EVERY
-		    time you reboot from the hard disk.  If you're feeling
-		    brave and have a srcdist + the requisite experience,
-		    you can hack the boot blocks in:
-
-			/usr/src/sys/i386/boot/biosboot
-
-		    So that this drive you're booting from is hard-coded.
-		    Recompile the boot blocks and reinstall them on your
-		    drive with `disklabel -B ...'  You can then have the
-		    default Do The Right Thing.
----
-
-Symptom:	Newfs crashes, requesting that blocksize be 32K
-
-Problem:	You have your disk controller configured to translate
-		to a some really large cylinder size because you're using
-		a drive with lots of cylinders.
-
-Solution:	Turn such translation OFF in your controller's BIOS
-		setup if you can.  If you must share the disk with other
-		Operating Systems, then this may not be possible and
-		you may simply be unable to install FreeBSD until we have
-		support for large translated geometries, sorry!
-		[ Hopefully in 2.1 ].
-
----
-
-Symptom:	FreeBSD won't boot off the hard disk
-
-Problem:	Root partition does not start and end below cylinder 1024.
-
-Solution:	See solution for newfs crashes, or move your root
-		partition.  This limitation holds true for ANY operating
-		system you wish to boot from your hard drive.
-
----
-
-Symptom:	FreeBSD still won't boot off the hard disk
-
-Problem:	No boot code is installed in sector 1.
-
-Solution:	Chose the Write MBR (B)oot code in the FDISK editor and
-		write out the boot manager so that you have a chance to
-		select operating systems.
-
-		[ ** NOTE:  If you are using the entire disk for FreeBSD, or
-		  you have a Connor drive that does cylinder translation
-		  from the MBR boot code, do NOT chose this option! ** ].
-
----
-Summary:	Nope, FreeBSD's still not booting from the hard disk.
-
-Cause:		BIOS disk geometry different from that used when
-		installing FreeBSD.
-
-Solution:	With IDE drives, pay careful attention to the geometry
-		information that FreeBSD prints out when it's first
-		booting off the floppy.  Use this geometry in your BIOS
-		setup or use the BIOS geometry when you install FreeBSD.
-		Either way, they have to match.
-
-		With SCSI drives, the values they report is most often
-		bogus and cannot be used.  In this situation, the SCSI
-		controller is performing geometry translation and
-		it's probably wise to assume a default of 64 heads,
-		32 sectors and 1MB/cylinder.  Use these values when
-		you install FreeBSD.  See above comments concerning
-		newfs failures for more info.
diff --git a/share/FAQ/Text/UUCP_Internals.FAQ b/share/FAQ/Text/UUCP_Internals.FAQ
deleted file mode 100644
index 5a0702b..0000000
--- a/share/FAQ/Text/UUCP_Internals.FAQ
+++ /dev/null
@@ -1,1603 +0,0 @@
-Path: bloom-beacon.mit.edu!cambridge-news.cygnus.com!comton.airs.com!ian
-From: ian@airs.com (Ian Lance Taylor)
-Newsgroups: comp.mail.uucp,comp.answers,news.answers
-Subject: UUCP Internals Frequently Asked Questions
-Keywords: UUCP, protocol, FAQ
-Message-ID: <uucp-internals_787915801@airs.com>
-Date: 20 Dec 94 09:30:02 GMT
-Expires: 31 Jan 95 09:30:01 GMT
-Reply-To: ian@airs.com (Ian Lance Taylor)
-Followup-To: comp.mail.uucp
-Organization: Infinity Development, Waltham, MA
-Lines: 1587
-Approved: news-answers-request@MIT.Edu
-Supersedes: <uucp-internals_785496601@airs.com>
-Xref: bloom-beacon.mit.edu comp.mail.uucp:5270 comp.answers:9043 news.answers:31575
-
-Archive-name: uucp-internals
-Version: $Revision: 1.1 $
-Last-modified: $Date: 1995/01/04 01:53:38 $
-
- This article was written by Ian Lance Taylor <ian@airs.com> and I may
- even update it periodically.  Please send me mail about suggestions
- or inaccuracies.
-
- This article describes how the various UUCP protocols work, and
- discusses some other internal UUCP issues.  It does not describe how
- to configure UUCP, nor how to solve UUCP connection problems, nor how
- to deal with UUCP mail.  I do not know of any FAQ postings on these
- topics.  There are some documents on the net describing UUCP
- configuration, but I can not keep an up to date list here; try using
- archie.
-
- If you haven't read the news.announce.newusers articles, read them.
-
- This article is in digest format.  Some newsreaders will be able to
- break it apart into separate articles.  Please don't ask me how to do
- this, though.
-
- This article answers the following questions.  If one of these
- questions is posted to comp.mail.uucp, please send mail to the poster
- referring her or him to this FAQ.  There is no reason to post a
- followup, as most of us know the answer already.
-
-Sources
-What does "alarm" mean in debugging output?
-What are UUCP grades?
-What is the format of a UUCP lock file?
-What is the format of a UUCP X.* file?
-What is the UUCP protocol?
-What is the 'g' protocol?
-What is the 'f' protocol?
-What is the 't' protocol?
-What is the 'e' protocol?
-What is the 'G' protocol?
-What is the 'i' protocol?
-What is the 'j' protocol?
-What is the 'x' protocol?
-What is the 'y' protocol?
-What is the 'd' protocol?
-What is the 'h' protocol?
-What is the 'v' protocol?
-Thanks
-
-----------------------------------------------------------------------
-
-From: Sources
-Subject: Sources
-
-"Unix-to-Unix Copy Program," said PDP-1.  "You will never find a more
-wretched hive of bugs and flamers.  We must be cautious."
-                                                --DECWars
-
-I took a lot of the information from Jamie E. Hanrahan's paper in the
-Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim
-O'Reilly and Grace Todino (with contributions by several other
-people).  The latter includes most of the former, and is published by
-        O'Reilly & Associates, Inc.
-        103 Morris Street, Suite A
-        Sebastopol, CA 95472
-It is currently in its tenth edition.  The ISBN number is
-0-937175-93-5.
-
-Some information is originally due to a Usenet article by Chuck
-Wegrzyn.  The information on execution files comes partially from
-Peter Honeyman.  The information on the 'g' protocol comes partially
-from a paper by G.L. Chesson of Bell Laboratories, partially from
-Jamie E. Hanrahan's paper, and partially from source code by John
-Gilmore.  The information on the 'f' protocol comes from the source
-code by Piet Berteema.  The information on the 't' protocol comes from
-the source code by Rick Adams.  The information on the 'e' protocol
-comes from a Usenet article by Matthias Urlichs.  The information on
-the 'd' protocol comes from Jonathan Clark, who also supplied
-information about QFT.  The FSUUCP information comes straight from
-Christopher J. Ambler; it applies to version 1.4 and up.
-
-Although there are few books about UUCP, there are many about networks
-and protocols in general.  I recommend two non-technical books which
-describe the sorts of things that are available on the network: ``The
-Whole Internet,'' by Ed Krol, and ``Zen and the Art of the Internet,''
-by Brendan P. Kehoe.  Good technical discussions of networking issues
-can be found in ``Internetworking with TCP/IP,'' by Douglas E. Comer
-and David L. Stevens and in ``Design and Validation of Computer
-Protocols'' by Gerard J. Holzmann.
-
-------------------------------
-
-From: alarm
-Subject: What does "alarm" mean in debugging output?
-
-The debugging output of many versions of UUCP (but not Taylor UUCP)
-will include messages like
-    alarm 1
-or
-    pkcget: alarm 1
-
-This message means that the UUCP package has timed out while waiting
-for some sort of response from the remote system.  This normally
-indicates some sort of connection problem.  For example, the modems
-might have lost their connection, or perhaps one of the modems will
-not transmit the XON and XOFF characters, or perhaps one side or the
-other is dropping characters.  It can also mean that the packages
-disagree about some aspect of the UUCP protocol, although this is less
-common.
-
-Using the information in the rest of this posting, you should be able
-to figure out what type of data your UUCP was expecting to receive.
-This may give some indication as to exactly what the problem is.  It
-is difficult to be more specific, since there are many possiblities.
-
-------------------------------
-
-From: UUCP-grades
-Subject: What are UUCP grades?
-
-Modern UUCP packages support grades for each command.  The grades
-generally range from 'A' (the highest) to 'Z' followed by 'a' to 'z'.
-Some UUCP packages also support '0' to '9' before 'A'.  Some UUCP
-packages may permit any ASCII character as a grade.
-
-On Unix, these grades are encoded in the name of the command file.  A
-command file name generally has the form
-    C.nnnngssss
-where nnnn is the remote system name for which the command is queued,
-g is a single character grade, and ssss is a four character sequence
-number.  For example, a command file created for the system ``airs''
-at grade 'Z' might be named
-    C.airsZ2551
-
-The remote system name will be truncated to seven characters, to
-ensure that the command file name will fit in the 14 character file
-name limit of the traditional Unix file system.  UUCP packages which
-have no other means of distinguishing which command files are intended
-for which systems thus require all systems they connect to to have
-names that are unique in the first seven characters.  Some UUCP
-packages use a variant of this format which truncates the system name
-to six characters.  HDB and Taylor UUCP use a different spool
-directory format, which allows up to fourteen characters to be used
-for each system name.
-
-The sequence number in the command file name may be a decimal integer,
-or it may be a hexadecimal integer, or it may contain any alphanumeric
-character.  Different UUCP packages are different.
-
-FSUUCP (a DOS based UUCP and news package) uses up to 8 characters for
-file names in the spool (this is a DOS file name limitation; actually,
-with the extension, 11 characters are available, but FSUUCP reserves
-that for future use).  FSUUCP defaults mail to grade D, and news to
-grade N, except that when the grade of incoming mail can be
-determined, that grade is preserved if the mail is forwarded to
-another system.  Mail and news are currently the only 2 types of
-transfers supported.  The default grades may be changed by editing
-the MAIL.RC file for mail, or the FSUUCP.CFG file for news.
-
-UUPC/extended for DOS, OS/2 and Windows NT handles mail at grade 'C',
-news at grade 'd', and file transfers at grade 'n'.  The UUPC/extended
-UUCP and RMAIL commands accept grades to override the default, the
-others do not.
-
-I do not know how command grades are handled in other non-Unix UUCP
-packages.
-
-Modern UUCP packages allow you to restrict file transfer by grade
-depending on the time of day.  Typically this is done with a line in
-the Systems (or L.sys) file like this:
-    airs Any/Z,Any2305-0855 ...
-This allows grades 'Z' and above to be transferred at any time.  Lower
-grades may only be transferred at night.  I believe that this grade
-restriction applies to local commands as well as to remote commands,
-but I am not sure.  It may only apply if the UUCP package places the
-call, not if it is called by the remote system.
-
-Taylor UUCP can use the ``timegrade'' and ``call-timegrade'' commands
-to achieve the same effect (and supports the above format when reading
-Systems or L.sys).
-
-UUPC/extended provides the symmetricgrades option to announce the
-current grade in effect when calling the remote system.
-
-This sort of grade restriction is most useful if you know what grades
-are being used at the remote site.  The default grades used depend on
-the UUCP package.  Generally uucp and uux have different defaults.  A
-particular grade can be specified with the -g option to uucp or uux.
-For example, to request execution of rnews on airs with grade 'd', you
-might use something like
-    uux -gd - airs!rnews <article
-
-Uunet queues up mail at grade 'C', but increases the grade based on
-the size.  News is queued at grade 'd', and file transfers at grade
-'n'.  The example above would allow mail (below some large size) to be
-received at any time, but would only permit news to be transferred at
-night.
-
-------------------------------
-
-From: UUCP-lock-file
-Subject: What is the format of a UUCP lock file?
-
-This discussion applies only to Unix.  I have no idea how UUCP locks
-ports on other systems.
-
-UUCP creates files to lock serial ports and systems.  On most if not
-all systems these same lock files are also used by cu to coordinate
-access to serial ports.  On some systems getty also uses these lock
-files, often under the name uugetty.
-
-The lock file normally contains the process ID of the locking process.
-This makes it easy to determine whether a lock is still valid.  The
-algorithm is to create a temporary file and then link it to the name
-that must be locked.  If the link fails because a file with that name
-already exists, the existing file is read to get the process ID.  If
-the process still exists, the lock attempt fails.  Otherwise the lock
-file is deleted and the locking algorithm is retried.
-
-Older UUCP packages put the lock files in the main UUCP spool
-directory, /usr/spool/uucp.  HDB UUCP generally puts the lock files in
-a directory of their own, usually /usr/spool/locks or /etc/locks.
-
-The original UUCP lock file format encodes the process ID as a four
-byte binary number.  The order of the bytes is host-dependent.  HDB
-UUCP stores the process ID as a ten byte ASCII decimal number, with a
-trailing newline.  For example, if process 1570 holds a lock file, it
-would contain the eleven characters space, space, space, space, space,
-space, one, five, seven, zero, newline.  Some versions of UUCP add a
-second line indicating which program created the lock (uucp, cu, or
-getty/uugetty).  I have also seen a third type of UUCP lock file which
-does not contain the process ID at all.
-
-The name of the lock file is traditionally "LCK.." followed by the
-base name of the device.  For example, to lock /dev/ttyd0 the file
-LCK..ttyd0 would be created.  On SCO Unix, the lock file name is
-always forced to lower case even if the device name has upper case
-letters.
-
-System V Release 4 UUCP names the lock file using the major and minor
-device numbers rather than the device name.  The file is named
-LK.XXX.YYY.ZZZ, where XXX, YYY and ZZZ are all three digit decimal
-numbers.  XXX is the major device number of the device holding the
-directory holding the device file (e.g., /dev).  YYY is the major
-device number of the device file itself.  ZZZ is the minor device
-number of the device file itself.  If s holds the result of passing
-the device to the stat system call (e.g., stat ("/dev/ttyd0", &s)),
-the following line of C code will print out the corresponding lock
-file name:
-    printf ("LK.%03d.%03d.%03d", major (s.st_dev),
-            major (s.st_rdev), minor (s.st_rdev));
-The advantage of this system is that even if there are several links
-to the same device, they will all use the same lock file name.
-
-------------------------------
-
-From: X-file
-Subject: What is the format of a UUCP X.* file?
-
-UUCP X.* files control program execution.  They are created by uux.
-They are transferred between computers just like any other file.  The
-uuxqt daemon reads them to figure out how to execute the job requested
-by uux.
-
-An X.* file is simply a text file.  The first character of each line
-is a command, and the remainder of the line supplies arguments.  The
-following commands are defined:
-    C command
-        This gives the command to execute, including the program and
-        all arguments.  For example,
-            C rmail ian@airs.com
-    U user system
-        This names the user who requested the command, and the system
-        from which the request came.
-    I standard-input
-        This names the file from which standard input is taken.  If no
-        standard input file is given, the standard input will probably
-        be attached to /dev/null.  If the standard input file is not
-        from the system on which the execution is to occur, it will
-        also appear in an F command.
-    O standard-output [ system ]
-        This names the standard output file.  The optional second
-        argument names the system to which the file should be sent.
-        If there is no second argument, the file should be created on
-        the executing system.
-    F required-file [ filename-to-use ]
-        The F command can appear multiple times.  Each F command names
-        a file which must exist before the execution can proceed.
-        This will usually be a file which is transferred from the
-        system on which uux was executed, but it can also be a file
-        from the local system or some other system.  If the file is
-        not from the local system, then the command will usually name
-        a file in the spool directory.  If the optional second
-        argument appears, then the file should be copied to the
-        execution directory under that name.  This is necessary for
-        any file other than the standard input file.  If the standard
-        input file is not from the local system, it will appear in
-        both an F command and an I command.
-    R requestor-address
-        This is the address to which mail about the job should be
-        sent.  It is relative to the system named in the U command.
-        If the R command does not appear, then mail is sent to the
-        user named in the U command.
-    Z
-        This command takes no arguments.  It means that a mail message
-        should be sent if the command failed.  This is the default
-        behaviour for most modern UUCP packages, and for them the Z
-        command does not actually do anything.
-    N
-        This command takes no arguments.  It means that no mail
-        message should be sent, even if the command failed.
-    n
-        This command takes no arguments.  It means that a mail message
-        should be sent if the command succeeded.  Normally a message
-        is sent only if the command failed.
-    B
-        This command takes no arguments.  It means that the standard
-        input should be returned with any error message.  This can be
-        useful in cases where the input would otherwise be lost.
-    e
-        This command takes no arguments.  It means that the command
-        should be processed with /bin/sh.  For some packages this is
-        the default anyhow.  Most packages will refuse to execute
-        complex commands or commands containing wildcards, because of
-        the security holes this opens.
-    E
-        This command takes no arguments.  It means that the command
-        should be processed with the execve system call.  For some
-        packages this is the default anyhow.
-    M status-file
-        This command means that instead of mailing a message, the
-        message should be copied to the named file on the system named
-        by the U command.
-    # comment
-        This command is ignored, as is any other unrecognized command.  
-
-Here is an example.  Given the following command executed on system
-test1
-    uux - test2!cat - test2!~ian/bar !qux '>~/gorp'
-(this is only an example, as most UUCP systems will not permit the cat
-command to be executed) Taylor UUCP will produce the following X.
-file:
-    U ian test1
-    F D.test1N003r qux
-    O /usr/spool/uucppublic test1
-    F D.test1N003s
-    I D.test1N003s
-    C cat - ~ian/bar qux
-The standard input will be read into a file and then transferred to
-the file D.test1N003s on system test2, and the file qux will be
-transferred to D.test1N003r on system test2.  When the command is
-executed, the latter file will be copied to the execution directory
-under the name qux.  Note that since the file ~ian/bar is already on
-the execution system, no action need be taken for it.  The standard
-output will be collected in a file, then copied to the directory
-/usr/spool/uucppublic on the system test1.
-
-------------------------------
-
-From: UUCP-protocol
-Subject: What is the UUCP protocol?
-
-The UUCP protocol is a conversation between two UUCP packages.  A UUCP
-conversation consists of three parts: an initial handshake, a series
-of file transfer requests, and a final handshake.
-
-Before the initial handshake, the caller will usually have logged in
-the called machine and somehow started the UUCP package there.  On
-Unix this is normally done by setting the shell of the login name used
-to /usr/lib/uucp/uucico.
-
-All messages in the initial handshake begin with a ^P (a byte with the
-octal value \020) and end with a null byte (\000).  A few systems end
-these messages with a line feed character (\012) instead of a null
-byte; the examples below assume a null byte is being used.
-
-Some options below are supported by QFT, which stands for Queued File
-Transfer, and is (or was) an internal Bell Labs version of UUCP.  
-
-Taylor UUCP size negotiation was introduced by Taylor UUCP, and is
-also supported by DOS based FSUUCP and Amiga based wUUCP and
-UUCP-1.17.
-
-The initial handshake goes as follows.  It is begun by the called
-machine.
-
-called: \020Shere=hostname\000
-    The hostname is the UUCP name of the called machine.  Older UUCP
-    packages do not output it, and simply send \020Shere\000.
-
-caller: \020Shostname options\000
-    The hostname is the UUCP name of the calling machine.  The
-    following options may appear (or there may be none):
-        -QSEQ
-            Report sequence number for this conversation.  The
-            sequence number is stored at both sites, and incremented
-            after each call.  If there is a sequence number mismatch,
-            something has gone wrong (somebody may have broken
-            security by pretending to be one of the machines) and the
-            call is denied.  If the sequence number changes on one of
-            the machines, perhaps because of an attempted breakin or
-            because a disk backup was restored, the sequence numbers
-            on the two machines must be reconciled manually.  This is
-            not supported by FSUUCP.
-        -xLEVEL
-            Requests the called system to set its debugging level to
-            the specified value.  This is not supported by all
-            systems.
-        -pGRADE
-        -vgrade=GRADE
-            Requests the called system to only transfer files of the
-            specified grade or higher.  This is not supported by all
-            systems.  Some systems support -p, some support -vgrade=.
-        -R
-            Indicates that the calling UUCP understands how to restart
-            failed file transmissions.  Supported only by System V
-            Release 4 UUCP and QFT.
-        -ULIMIT
-            Reports the ulimit value of the calling UUCP.  The limit
-            is specified as a base 16 number in C notation (e.g.,
-            -U0x1000000).  This number is the number of 512 byte
-            blocks in the largest file which the calling UUCP can
-            create.  The called UUCP may not transfer a file larger
-            than this.  Supported only by System V Release 4 UUCP, QFT
-            and FSUUCP.  FSUUCP reports the lesser of the
-            available disk space on the spool directory drive and the
-            ulimit variable in FSUUCP.CFG.
-        -N
-            Indicates that the calling UUCP understands the Taylor
-            UUCP size negotiation extension.  Not supported by
-	    traditional UUCP packages.
-
-called: \020ROK\000
-    There are actually several possible responses.
-        ROK
-            The calling UUCP is acceptable, and the handshake proceeds
-            to the protocol negotiation.  Some options may also
-            appear; see below.
-        ROKN
-            The calling UUCP is acceptable, it specified -N, and the
-            called UUCP also understands the Taylor UUCP size limiting
-            extensions.
-        RLCK
-            The called UUCP already has a lock for the calling UUCP,
-            which normally indicates the two machines are already
-            communicating.
-        RCB
-            The called UUCP will call back.  This may be used to avoid
-            impostors (but only one machine out of each pair should
-            call back, or no conversation will ever begin).
-        RBADSEQ
-            The call sequence number is wrong (see the -Q discussion
-            above). 
-        RLOGIN
-            The calling UUCP is using the wrong login name.
-        RYou are unknown to me
-            The calling UUCP is not known to the called UUCP, and the
-            called UUCP does not permit connections from unknown
-            systems.  Some versions of UUCP just drop the line rather
-            than sending this message.
-
-    If the response is ROK, the following options are supported by
-    System V Release 4 UUCP and QFT.
-        -R
-            The called UUCP knows how to restart failed file
-            transmissions.
-        -ULIMIT
-            Reports the ulimit value of the called UUCP.  The limit is
-            specified as a base 16 number in C notation.  This number
-            is the number of 512 byte blocks in the largest file which
-            the called UUCP can create.  The calling UUCP may not send
-            a file larger than this.  Also supported by FSUUCP.
-        -xLEVEL
-            I'm not sure just what this means.  It may request the
-            calling UUCP to set its debugging level to the specified
-            value.
-    If the response is not ROK (or ROKN) both sides hang up the phone,
-    abandoning the call.
-
-called: \020Pprotocols\000
-    Note that the called UUCP outputs two strings in a row.  The
-    protocols string is a list of UUCP protocols supported by the
-    caller.  Each UUCP protocol has a single character name.  These
-    protocols are discussed in more detail later in this document.
-    For example, the called UUCP might send \020Pgf\000.
-
-caller: \020Uprotocol\000
-    The calling UUCP selects which protocol to use out of the
-    protocols offered by the called UUCP.  If there are no mutually
-    supported protocols, the calling UUCP sends \020UN\000 and both
-    sides hang up the phone.  Otherwise the calling UUCP sends
-    something like \020Ug\000.
-
-Most UUCP packages will consider each locally supported protocol in
-turn and select the first one supported by the called UUCP.  With some
-versions of HDB UUCP, this can be modified by giving a list of
-protocols after the device name in the Devices file or the Systems
-file.  For example, to select the 'e' protocol in Systems,
-    airs Any ACU,e ...
-or in Devices,
-    ACU,e ttyXX ...
-Taylor UUCP provides the ``protocol'' command which may be used either
-for a system or a port.
-
-After the protocol has been selected and the initial handshake has been
-completed, both sides turn on the selected protocol.  For some
-protocols (notably 'g') a further handshake is done at this point.
-
-Each protocol supports a method for sending a command to the remote
-system.  This method is used to transmit a series of commands between
-the two UUCP packages.  At all times, one package is the master and
-the other is the slave.  Initially, the calling UUCP is the master.
-
-If a protocol error occurs during the exchange of commands, both sides
-move immediately to the final handshake.
-
-The master will send one of four commands: S, R, X or H.
-
-Any file name referred to below is either an absolute pathname
-beginning with "/", a public directory pathname beginning with "~/", a
-pathname relative to a user's home directory beginning with "~USER/",
-or a spool directory file name.  File names in the spool directory are
-not pathnames, but instead are converted to pathnames within the spool
-directory by UUCP.  They always begin with "C." (for a command file
-created by uucp or uux), "D." (for a data file created by uucp, uux or
-by an execution, or received from another system for an execution), or
-"X." (for an execution file created by uux or received from another
-system).
-
-master: S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE
-    The S and the - are literal characters.  This is a request by the
-    master to send a file to the slave.
-        FROM
-            The name of the file to send.  If the C option does not
-            appear in OPTIONS, the master will actually open and send
-            this file.  Otherwise the file has been copied to the
-            spool directory, where it is named TEMP.  The slave
-            ignores this field unless TO is a directory, in which case
-            the basename of FROM will be used as the file name.  If
-            FROM is a spool directory filename, it must be a data file
-            created for or by an execution, and must begin with "D.".
-        TO
-            The name to give the file on the slave.  If this field
-            names a directory the file is placed within that directory
-            with the basename of FROM.  A name ending in `/' is taken
-            to be a directory even if one does not already exist with
-            that name.  If TO begins with `X.', an execution file will
-            be created on the slave.  Otherwise, if TO begins with
-            `D.' it names a data file to be used by some execution
-            file.  Otherwise, TO should not be in the spool directory.
-        USER
-            The name of the user who requested the transfer.
-        OPTIONS
-            A list of options to control the transfer.  The following
-            options are defined (all options are single characters):
-                C
-                    The file has been copied to the spool directory
-                    (the master should use TEMP rather than FROM).
-                c
-                    The file has not been copied to the spool
-                    directory (this is the default).
-                d
-                    The slave should create directories as necessary
-                    (this is the default).
-                f
-                    The slave should not create directories if
-                    necessary, but should fail the transfer instead.
-                m
-                    The master should send mail to USER when the
-                    transfer is complete (not supported by FSUUCP).
-                n
-                    The slave should send mail to NOTIFY when the
-                    transfer is complete (not supported by FSUUCP).
-        TEMP
-            If the C option appears in OPTIONS, this names the file to
-            be sent.  Otherwise if FROM is in the spool directory,
-            TEMP is the same as FROM.  Otherwise TEMP may be a dummy
-            string, such as "D.0".  After the transfer has been
-            succesfully completed, the master will delete the file
-            TEMP.
-        MODE
-            This is an octal number giving the mode of the file on
-            MASTER.  If the file is not in the spool directory, the
-            slave will always create it with mode 0666, except that if
-            (MODE & 0111) is not zero (the file is executable), the
-            slave will create the file with mode 0777.  If the file is
-            in the spool directory, some UUCP packages will use the
-            algorithm above and some will always create the file with
-            mode 0600.  This field is not used by FSUUCP, since it is
-            meaningless on DOS.
-        NOTIFY
-            This field may not be present, and in any case is only
-            meaningful if the n option appears in OPTIONS.  If the n
-            option appears, then when the transfer is successfully
-            completed, the slave will send mail to NOTIFY, which must
-            be a legal mailing address on the slave.  If a SIZE field
-            will appear but the n option does not appear, NOTIFY will
-            always be present, typically as the string "dummy" or
-            simply a pair of double quotes.
-        SIZE
-            This field is only present when doing Taylor UUCP or SVR4
-            UUCP size negotiation, It is the size of the file in
-            bytes.  Taylor UUCP version 1.03 sends the size as a
-            decimal integer, while versions 1.04 and up, and all other
-            UUCP packages that support size negotiation, send the size
-            in base 16 with a leading 0x.
-
-    The slave then responds with an S command response.
-        SY START
-            The slave is willing to accept the file, and file transfer
-            begins.  The START field will only be present when using
-            file restart.  It specifies the byte offset into the file
-            at which to start sending.  If this is a new file, START
-            will be 0x0.
-        SN2
-            The slave denies permission to transfer the file.  This
-            can mean that the destination directory may not be
-            accessed, or that no requests are permitted.  It implies
-            that the file transfer will never succeed.
-        SN4
-            The slave is unable to create the necessary temporary
-            file.  This implies that the file transfer might succeed
-            later.
-        SN6
-            This is only used by Taylor UUCP size negotiation.  It
-            means that the slave considers the file too large to
-            transfer at the moment, but it may be possible to transfer
-            it at some other time.
-        SN7
-            This is only used by Taylor UUCP size negotiation.  It
-            means that the slave considers the file too large to ever
-            transfer.
-        SN8
-            This is only used by Taylor UUCP.  It means that the file
-            was already received in a previous conversation.  This can
-            happen if the receive acknowledgement was lost after it
-            was sent by the receiver but before it was received by the
-            sender.
-	SN9
-	    This is only used by Taylor UUCP (versions 1.05 and up)
-	    and FSUUCP (versions 1.5 and up).  It means that the
-	    remote system was unable to open another channel (see the
-	    discussion of the 'i' protocol for more information about
-	    channels).  This implies that the file transfer might
-	    succeed later.
-        SN10
-            This is reportedly used by SVR4 UUCP to mean that the file
-            size is too large.
-
-    If the slave responds with SY, a file transfer begins.  When the
-    file transfer is complete, the slave sends a C command response.
-        CY
-            The file transfer was successful.
-        CYM
-            The file transfer was successful, and the slave wishes to
-            become the master; the master should send an H command,
-            described below.
-        CN5
-            The temporary file could not be moved into the final
-            location.  This implies that the file transfer will never
-            succeed.
-
-    After the C command response has been received (in the SY case) or
-    immediately (in an SN case) the master will send another command.
-
-master: R FROM TO USER -OPTIONS SIZE
-    The R and the - are literal characters.  This is a request by the
-    master to receive a file from the slave.  I do not know how SVR4
-    UUCP or QFT implement file transfer restart in this case.
-        FROM
-            This is the name of the file on the slave which the master
-            wishes to receive.  It must not be in the spool directory,
-            and it may not contain any wildcards.
-        TO
-            This is the name of the file to create on the master.  I
-            do not believe that it can be a directory.  It may only be
-            in the spool directory if this file is being requested to
-            support an execution either on the master or on some
-            system other than the slave.
-        USER
-            The name of the user who requested the transfer.
-        OPTIONS
-            A list of options to control the transfer.  The following
-            options are defined (all options are single characters):
-                d
-                    The master should create directories as necessary
-                    (this is the default).
-                f
-                    The master should not create directories if
-                    necessary, but should fail the transfer instead.
-                m
-                    The master should send mail to USER when the
-                    transfer is complete.
-        SIZE
-            This only appears if Taylor UUCP size negotiation is being
-            used.  It specifies the largest file which the master is
-            prepared to accept (when using SVR4 UUCP or QFT, this was
-            specified in the -U option during the initial handshake).
-
-    The slave then responds with an R command response.  FSUUCP does
-    not support R requests, and always responds with RN2.
-        RY MODE [ SIZE ]
-            The slave is willing to send the file, and file transfer
-            begins.  MODE is the octal mode of the file on the slave.
-            The master treats this just as the slave does the MODE
-            argument in the send command, q.v.  I am told that SVR4
-            UUCP sends a trailing SIZE argument.  For some versions of
-            BSD UUCP, the MODE argument may have a trailing M
-            character (e.g., RY 0666M).  This means that the slave
-            wishes to become the master.
-        RN2
-            The slave is not willing to send the file, either because
-            it is not permitted or because the file does not exist.
-            This implies that the file request will never succeed.
-        RN6
-            This is only used by Taylor UUCP size negotiation.  It
-            means that the file is too large to send, either because
-            of the size limit specifies by the master or because the
-            slave considers it too large.  The file transfer might
-            succeed later, or it might not (this will be cleared up in
-            a later release of Taylor UUCP).
-	RN9
-	    This is only used by Taylor UUCP (versions 1.05 and up)
-	    and FSUUCP (versions 1.5 and up).  It means that the
-	    remote system was unable to open another channel (see the
-	    discussion of the 'i' protocol for more information about
-	    channels).  This implies that the file transfer might
-	    succeed later.
-
-    If the slave responds with RY, a file transfer begins.  When the
-    file transfer is complete, the master sends a C command.  The
-    slave pretty much ignores this, although it may log it.
-        CY
-            The file transfer was successful.
-        CN5
-            The temporary file could not be moved into the final
-            location.
-
-    After the C command response has been sent (in the RY case) or
-    immediately (in an RN case) the master will send another command.
-
-master: X FROM TO USER -OPTIONS
-    The X and the - are literal characters.  This is a request by the
-    master to, in essence, execute uucp on the slave.  The slave
-    should execute "uucp FROM TO".
-        FROM
-            This is the name of the file or files on the slave which
-            the master wishes to transfer.  Any wildcards are expanded
-            on the slave.  If the master is requesting that the files
-            be transferred to itself, the request would normally
-            contain wildcard characters, since otherwise an `R'
-            command would suffice.  The master can also use this
-            command to request that the slave transfer files to a
-            third system.
-        TO
-            This is the name of the file or directory to which the
-            files should be transferred.  This will normally use a
-            UUCP name.  For example, if the master wishes to receive
-            the files itself, it would use "master!path".
-        USER
-            The name of the user who requested the transfer.
-        OPTIONS
-            A list of options to control the transfer.  It is not
-            clear which, if any, options are supported by most UUCP
-            packages.
-
-    The slave then responds with an X command response.  FSUUCP does
-    not support X requests, and always responds with XN.
-        XY
-            The request was accepted, and the appropriate file
-            transfer commands have been queued up for later
-            processing.
-        XN
-            The request was denied.  No particular reason is given.
-
-    In either case, the master will then send another command.
-
-master: H
-    This is used by the master to hang up the connection.  The slave
-    will respond with an H command response.
-        HY
-            The slave agrees to hang up the connection.  In this case
-            the master sends another HY command.  In some UUCP
-            packages the slave will then send a third HY command.  At
-            this point the protocol is shut down, and the final
-            handshake is begun.
-        HN
-            The slave does not agree to hang up.  In this case the
-            master and the slave exchange roles.  The next command
-            will be sent by the former slave, which is the new master.
-            The roles may be reversed several times during a single
-            connection.
-
-After the protocol has been shut down, the final handshake is
-performed.  This handshake has no real purpose, and some UUCP packages
-simply drop the connection rather than do it (in fact, some will drop
-the connection immediately after both sides agree to hangup, without
-even closing down the protocol).
-
-caller: \020OOOOOO\000
-called: \020OOOOOOO\000
-
-That is, the calling UUCP sends six O's and the called UUCP replies
-with seven O's.  Some UUCP packages always send six O's.
-
-------------------------------
-
-From: UUCP-g
-Subject: What is the 'g' protocol?
-
-The 'g' protocol is a packet based flow controlled error correcting
-protocol that requires an eight bit clear connection.  It is the
-original UUCP protocol, and is supported by all UUCP implementations.
-Many implementations of it are only able to support small window and
-packet sizes, specifically a window size of 3 and a packet size of 64
-bytes, but the protocol itself can support up to a window size of 7
-and a packet size of 4096 bytes.  Complaints about the inefficiency of
-the 'g' protocol generally refer to specific implementations, rather
-than to the correctly implemented protocol.
-
-The 'g' protocol was originally designed for general packet drivers,
-and thus contains some features that are not used by UUCP, including
-an alternate data channel and the ability to renegotiate packet and
-window sizes during the communication session.
-
-The 'g' protocol is spoofed by many Telebit modems.  When spoofing is
-in effect, each Telebit modem uses the 'g' protocol to communicate
-with the attached computer, but the data between the modems is sent
-using a Telebit proprietary error correcting protocol.  This allows
-for very high throughput over the Telebit connection, which, because
-it is half-duplex, would not normally be able to handle the 'g'
-protocol very well at all.  When a Telebit is spoofing the 'g'
-protocol, it forces the packet size to be 64 bytes and the window size
-to be 3.
-
-This discussion of the 'g' protocol explains how it works, but does
-not discuss useful error handling techniques.  Some discussion of this
-can be found in Jamie E. Hanrahan's paper, cited above.
-
-All 'g' protocol communication is done with packets.  Each packet
-begins with a six byte header.  Control packets consist only of the
-header.  Data packets contain additional data.
-
-The header is as follows:
-
-    \020
-        Every packet begins with a ^P.
-    k (1 <= k <= 9)
-        The k value is always 9 for a control packet.  For a data
-        packet, the k value indicates how much data follows the six
-        byte header.  The amount of data is 2 ** (k + 4), where **
-        indicates exponentiation.  Thus a k value of 1 means 32 data
-        bytes and a k value of 8 means 4096 data bytes.  The k value
-        for a data packet must be between 1 and 8 inclusive.
-    checksum low byte
-    checksum high byte
-        The checksum value is described below.
-    control byte
-        The control byte indicates the type of packet, and is
-        described below.
-    xor byte
-        This byte is the xor of k, the checksum low byte, the checksum
-        high byte and the control byte (i.e., the second, third,
-        fourth and fifth header bytes).  It is used to ensure that the
-        header data is valid.
-
-The control byte in the header is composed of three bit fields,
-referred to here as TT (two bits), XXX (three bits) and YYY (three
-bits).  The control is TTXXXYYY, or (TT << 6) + (XXX << 3) + YYY.
-
-The TT field takes on the following values:
-    0
-        This is a control packet.  In this case the k byte in the
-        header must be 9.  The XXX field indicates the type of control
-        packet; these types are described below.
-    1
-        This is an alternate data channel packet.  This is not used by
-        UUCP.
-    2
-        This is a data packet, and the entire contents of the attached
-        data field (whose length is given by the k byte in the header)
-        are valid.  The XXX and YYY fields are described below.
-    3
-        This is a short data packet.  Let the length of the data field
-        (as given by the k byte in the header) be L.  Let the first
-        byte in the data field be B1.  If B1 is less than 128 (if the
-        most significant bit of B1 is 0), then there are L - B1 valid
-        bytes of data in the data field, beginning with the second
-        byte.  If B1 >= 128, let B2 be the second byte in the data
-        field.  Then there are L - ((B1 & 0x7f) + (B2 << 7)) valid
-        bytes of data in the data field, beginning with the third
-        byte.  In all cases L bytes of data are sent (and all data
-        bytes participate in the checksum calculation) but some of the
-        trailing bytes may be dropped by the receiver.   The XXX and
-        YYY fields are described below.
-
-In a data packet (short or not) the XXX field gives the sequence
-number of the packet.  Thus sequence numbers can range from 0 to 7,
-inclusive.  The YYY field gives the sequence number of the last
-correctly received packet.
-
-Each communication direction uses a window which indicates how many
-unacknowledged packets may be transmitted before waiting for an
-acknowledgement.  The window may range from 1 to 7, and may be
-different in each direction. For example, if the window is 3 and the
-last packet acknowledged was packet number 6, packet numbers 7, 0 and
-1 may be sent but the sender must wait for an acknowledgement before
-sending packet number 2.  This acknowledgement could come as the YYY
-field of a data packet or as the YYY field of a RJ or RR control
-packet (described below).
-
-Each packet must be transmitted in order (the sender may not skip
-sequence numbers).  Each packet must be acknowledged, and each packet
-must be acknowledged in order.
-
-In a control packet, the XXX field takes on the following values:
-    1 CLOSE
-        The connection should be closed immediately.  This is
-        typically sent when one side has seen too many errors and
-        wants to give up.  It is also sent when shutting down the
-        protocol.  If an unexpected CLOSE packet is received, a CLOSE
-        packet should be sent in reply and the 'g' protocol should
-        halt, causing UUCP to enter the final handshake.
-    2 RJ or NAK
-        The last packet was not received correctly.  The YYY field
-        contains the sequence number of the last correctly received
-        packet.
-    3 SRJ
-        Selective reject.  The YYY field contains the sequence number
-        of a packet that was not received correctly, and should be
-        retransmitted.  This is not used by UUCP, and most
-        implementations will not recognize it.
-    4 RR or ACK
-        Packet acknowledgement.  The YYY field contains the sequence
-        number of the last correctly received packet.
-    5 INITC
-        Third initialization packet.  The YYY field contains the
-        maximum window size to use.
-    6 INITB
-        Second initialization packet.  The YYY field contains the
-        packet size to use.  It requests a size of 2 ** (YYY + 5).
-        Note that this is not the same coding used for the k byte in
-        the packet header (it is 1 less).  Most UUCP implementations
-        that request a packet size larger than 64 bytes can handle any
-        packet size up to that specified.
-    7 INITA
-        First initialization packet.  The YYY field contains the
-        maximum window size to use.
-
-The checksum of a control packet is simply 0xaaaa - the control byte.
-
-The checksum of a data packet is 0xaaaa - (CHECK ^ the control byte),
-where ^ denotes exclusive or, and CHECK is the result of the following
-routine as run on the contents of the data field (every byte in the
-data field participates in the checksum, even for a short data
-packet).  Below is the routine used by Taylor UUCP; it is a slightly
-modified version of a routine which John Gilmore patched from G.L.
-Chesson's original paper.  The z argument points to the data and the c
-argument indicates how much data there is.
-
-int
-igchecksum (z, c)
-     register const char *z;
-     register int c;
-{
-  register unsigned int ichk1, ichk2;
-
-  ichk1 = 0xffff;
-  ichk2 = 0;
-
-  do
-    {
-      register unsigned int b;
-
-      /* Rotate ichk1 left.  */
-      if ((ichk1 & 0x8000) == 0)
-        ichk1 <<= 1;
-      else
-        {
-          ichk1 <<= 1;
-          ++ichk1;
-        }
-
-      /* Add the next character to ichk1.  */
-      b = *z++ & 0xff;
-      ichk1 += b;
-
-      /* Add ichk1 xor the character position in the buffer counting from
-         the back to ichk2.  */
-      ichk2 += ichk1 ^ c;
-
-      /* If the character was zero, or adding it to ichk1 caused an
-         overflow, xor ichk2 to ichk1.  */
-      if (b == 0 || (ichk1 & 0xffff) < b)
-        ichk1 ^= ichk2;
-    }
-  while (--c > 0);
-
-  return ichk1 & 0xffff;
-}
-
-When the 'g' protocol is started, the calling UUCP sends an INITA
-control packet with the window size it wishes the called UUCP to use.
-The called UUCP responds with an INITA packet with the window size it
-wishes the calling UUCP to use.  Pairs of INITB and INITC packets are
-then similarly exchanged.  When these exchanges are completed, the
-protocol is considered to have been started.
-
-Note that the window and packet sizes are not a negotiation.  Each
-system announces the window and packet size which the other system
-should use.  It is possible that different window and packet sizes
-will be used in each direction.  The protocol works this way on the
-theory that each system knows how much data it can accept without
-getting overrun.  Therefore, each system tells the other how much data
-to send before waiting for an acknowledgement.
-
-When a UUCP package transmits a command, it sends one or more data
-packets.  All the data packets will normally be complete, although
-some UUCP packages may send the last one as a short packet.  The
-command string is sent with a trailing null byte, to let the receiving
-package know when the command is finished.  Some UUCP packages require
-the last byte of the last packet sent to be null, even if the command
-ends earlier in the packet.  Some packages may require all the
-trailing bytes in the last packet to be null, but I have not confirmed
-this.
-
-When a UUCP package sends a file, it will send a sequence of data
-packets.  The end of the file is signalled by a short data packet
-containing zero valid bytes (it will normally be preceeded by a short
-data packet containing the last few bytes in the file).
-
-Note that the sequence numbers cover the entire communication session,
-including both command and file data.
-
-When the protocol is shut down, each UUCP package sends a CLOSE
-control packet.
-
-------------------------------
-
-From: UUCP-f
-Subject: What is the 'f' protocol?
-
-The 'f' protocol is a seven bit protocol which checksums an entire
-file at a time.  It only uses the characters between \040 and \176
-(ASCII space and ~) inclusive as well as the carriage return
-character.  It can be very efficient for transferring text only data,
-but it is very inefficient at transferring eight bit data (such as
-compressed news).  It is not flow controlled, and the checksum is
-fairly insecure over large files, so using it over a serial connection
-requires handshaking (XON/XOFF can be used) and error correcting
-modems.  Some people think it should not be used even under those
-circumstances.
-
-I believe the 'f' protocol originated in BSD versions of UUCP.  It was
-originally intended for transmission over X.25 PAD links.
-
-The 'f' protocol has no startup or finish protocol.  However, both
-sides typically sleep for a couple of seconds before starting up,
-because they switch the terminal into XON/XOFF mode and want to allow
-the changes to settle before beginning transmission.
-
-When a UUCP package transmits a command, it simply sends a string
-terminated by a carriage return.
-
-When a UUCP package transmits a file, each byte b of the file is
-translated according to the following table:
-
-       0 <= b <=  037: 0172, b + 0100 (0100 to 0137)
-     040 <= b <= 0171:       b        ( 040 to 0171)
-    0172 <= b <= 0177: 0173, b - 0100 ( 072 to  077)
-    0200 <= b <= 0237: 0174, b - 0100 (0100 to 0137)
-    0240 <= b <= 0371: 0175, b - 0200 ( 040 to 0171)
-    0372 <= b <= 0377: 0176, b - 0300 ( 072 to  077)
-
-That is, a byte between \040 and \171 inclusive is transmitted as is,
-and all other bytes are prefixed and modified as shown.
-
-When all the file data is sent, a seven byte sequence is sent: two
-bytes of \176 followed by four ASCII bytes of the checksum as printed
-in base 16 followed by a carriage return.  For example, if the
-checksum was 0x1234, this would be sent: "\176\1761234\r".
-
-The checksum is initialized to 0xffff.  For each byte that is sent it
-is modified as follows (where b is the byte before it has been
-transformed as described above):
-
-      /* Rotate the checksum left.  */
-      if ((ichk & 0x8000) == 0)
-        ichk <<= 1;
-      else
-        {
-          ichk <<= 1;
-          ++ichk;
-        }
-
-      /* Add the next byte into the checksum.  */
-      ichk += b;
-
-When the receiving UUCP sees the checksum, it compares it against its
-own calculated checksum and replies with a single character followed
-by a carriage return.
-    G
-        The file was received correctly.
-    R
-        The checksum did not match, and the file should be resent from
-        the beginning.
-    Q
-        The checksum did not match, but too many retries have occurred
-        and the communication session should be abandoned.
-
-The sending UUCP checks the returned character and acts accordingly.
-
-------------------------------
-
-From: UUCP-t
-Subject: What is the 't' protocol?
-
-The 't' protocol is intended for use on links which provide reliable
-end-to-end connections, such as TCP.  It does no error checking or
-flow control, and requires an eight bit clear channel.
-
-I believe the 't' protocol originated in BSD versions of UUCP.
-
-When a UUCP package transmits a command, it first gets the length of
-the command string, C.  It then sends ((C / 512) + 1) * 512 bytes (the
-smallest multiple of 512 which can hold C bytes plus a null byte)
-consisting of the command string itself followed by trailing null
-bytes.
-
-When a UUCP package sends a file, it sends it in blocks.  Each block
-contains at most 1024 bytes of data.  Each block consists of four
-bytes containing the amount of data in binary (most significant byte
-first, the same format as used by the Unix function htonl) followed by
-that amount of data.  The end of the file is signalled by a block
-containing zero bytes of data.
-
-------------------------------
-
-From: UUCP-e
-Subject: What is the 'e' protocol?
-
-The 'e' protocol is similar to the 't' protocol.  It does no flow
-control or error checking and is intended for use over networks
-providing reliable end-to-end connections, such as TCP.
-
-The 'e' protocol originated in versions of HDB UUCP.
-
-When a UUCP package transmits a command, it simply sends the command
-as an ASCII string terminated by a null byte.
-
-When a UUCP package transmits a file, it sends the complete size of
-the file as an ASCII decimal number.  The ASCII string is padded out
-to 20 bytes with null bytes (i.e. if the file is 1000 bytes long, it
-sends "1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0").  It then sends the
-entire file.
-
-------------------------------
-
-From: UUCP-G
-Subject: What is the 'G' protocol?
-
-The 'G' protocol is used by SVR4 UUCP.  It is identical to the 'g'
-protocol, except that it is possible to modify the window and packet
-sizes.  The SVR4 implementation of the 'g' protocol reportedly is
-fixed at a packet size of 64 and a window size of 7.  Supposedly SVR4
-chose to implement a new protocol using a new letter to avoid any
-potential incompatibilities when using different packet or window
-sizes.
-
-Most implementations of the 'g' protocol that accept packets larger
-than 64 bytes will also accept packets smaller than whatever they
-requested in the INITB packet.  The SVR4 'G' implementation is an
-exception; it will only accept packets of precisely the size it
-requests in the INITB packet.
-
-------------------------------
-
-From: UUCP-i
-Subject: What is the 'i' protocol?
-
-The 'i' protocol was written by Ian Lance Taylor (who also wrote this
-FAQ).  It is used by Taylor UUCP version 1.04.
-
-It is a sliding window packet protocol, like the 'g' protocol, but it
-supports bidirectional transfers (i.e., file transfers in both
-directions simultaneously).  It requires an eight bit clear
-connection.  Several ideas for the protocol were taken from the paper
-``A High-Throughput Message Transport System'' by P. Lauder.  I don't
-know where the paper was published, but the author's e-mail address is
-piers@cs.su.oz.au.  The 'i' protocol does not adopt his main idea,
-which is to dispense with windows entirely.  This is because some
-links still do require flow control and, more importantly, because
-using windows sets a limit to the amount of data which the protocol
-must be able to resend upon request.  To reduce the costs of window
-acknowledgements, the protocol uses a large window and only requires
-an ack at the halfway point.
-
-Each packet starts with a six byte header, optionally followed by data
-bytes with a four byte checksum.  There are currently five defined
-packet types (DATA, SYNC, ACK, NAK, SPOS, CLOSE) which are described
-below.  Although any packet type may include data, any data provided
-with an ACK, NAK or CLOSE packet is ignored.
-
-Every DATA, SPOS and CLOSE packet has a sequence number.  The sequence
-numbers are independent for each side.  The first packet sent by each
-side is always number 1.  Each packet is numbered one greater than the
-previous packet, modulo 32.
-
-Every packet has a local channel number and a remote channel number.
-For all packets at least one channel number is zero.  When a UUCP
-command is sent to the remote system, it is assigned a non-zero local
-channel number.  All packets associated with that UUCP command sent by
-the local system are given the selected local channel number.  All
-associated packets sent by the remote system are given the selected
-number as the remote channel number.  This permits each UUCP command
-to be uniquely identified by the channel number on the originating
-system, and therefore each UUCP package can associate all file data
-and UUCP command responses with the appropriate command.  This is a
-requirement for bidirectional UUCP transfers.
-
-The protocol maintains a single global file position, which starts at
-0.  For each incoming packet, any associated data is considered to
-occur at the current file position, and the file position is
-incremented by the amount of data contained.  The exception is a
-packet of type SPOS, which is used to change the file position.
-The reason for keeping track of the file position is described below.
-
-The header is as follows:
-
-    \007
-	Every packet begins with ^G.
-    (PACKET << 3) + LOCCHAN
-	The five bit packet number combined with the three bit local
-	channel number.  DATA, SPOS and CLOSE packets use the packet
-	sequence number for the PACKET field.  NAK packet types use
-	the PACKET field for the sequence number to be resent.  ACK
-	and SYNC do not use the PACKET field, and generally leave it
-	set to 0.  Packets which are not associated with a UUCP
-	command from the local system use a local channel number of 0.
-    (ACK << 3) + REMCHAN
-	The five bit packet acknowledgement combined with the three
-	bit remote channel number.  The packet acknowledgement is the
-	number of the last packet successfully received; it is used by
-	all packet types.  Packets which are not sent in response to a
-	UUCP command from the remote system use a remote channel
-	number of 0.
-    (TYPE << 5) + (CALLER << 4) + LEN1
-	The three bit packet type combined with the one bit packet
-	direction combined with the upper four bits of the data
-	length.  The packet direction bit is always 1 for packets sent
-	by the calling UUCP, and 0 for packets sent by the called
-	UUCP.  This prevents confusion caused by echoed packets.
-    LEN2
-	The lower eight bits of the data length.  The twelve bits of
-	data length permit packets ranging in size from 0 to 4095
-	bytes.
-    CHECK
-	The exclusive or of the second through fifth bytes of the
-	header.  This provides an additional check that the header is
-	valid.
-
-If the data length is non-zero, the packet is immediately followed by
-the specified number of data bytes.  The data bytes are followed by a
-four byte CRC 32 checksum, with the most significant byte first.  The
-CRC is calculated over the contents of the data field.
-
-The defined packet types are as follows:
-
-    0 (DATA)
-	This is a plain data packet.
-    1 (SYNC)
-	SYNC packets are exchanged when the protocol is initialized,
-	and are described further below.  SYNC packets do not carry
-	sequence numbers (that is, the PACKET field is ignored).
-    2 (ACK)
-	This is an acknowledgement packet.  Since DATA packets also
-	carry packet acknowledgements, ACK packets are only used when
-	one side has no data to send.  ACK packets do not carry
-	sequence numbers.
-    3 (NAK)
-	This is a negative acknowledgement.  This is sent when a
-	packet is received incorrectly, and means that the packet
-	number appearing in the PACKET field must be resent.  NAK
-	packets do not carry sequence numbers (the PACKET field is
-	already used).
-    4 (SPOS)
-	This packet changes the file position.  The packet contains
-	four bytes of data holding the file position, most significant
-	byte first.  The next packet received will be considered to be
-	at the named file position.
-    5 (CLOSE)
-	When the protocol is shut down, each side sends a CLOSE
-	packet.	 This packet does have a sequence number, which could
-	be used to ensure that all packets were correctly received
-	(this is not needed by UUCP, however, which uses the higher
-	level H command with an HY response).
-
-When the protocol starts up, both systems send a SYNC packet.  The
-SYNC packet includes at least three bytes of data.  The first two
-bytes are the maximum packet size the remote system should send, most
-significant byte first.  The third byte is the window size the remote
-system should use.  The remote system may send packets of any size up
-to the maximum.  If there is a fourth byte, it is the number of
-channels the remote system may use (this must be between 1 and 7,
-inclusive).  Additional data bytes may be defined in the future.
-
-The window size is the number of packets that may be sent before a
-packet is acknowledged.  There is no requirement that every packet be
-acknowledged; any acknowledgement is considered to acknowledge all
-packets through the number given.  In the current implementation, if
-one side has no data to send, it sends an ACK when half the window is
-received.
-
-Note that the NAK packet corresponds to the unused 'g' protocol SRJ
-packet type, rather than to the RJ packet type.  When a NAK is
-received, only the named packet should be resent, not any subsequent
-packets.
-
-Note that if both sides have data to send, but a packet is lost, it is
-perfectly reasonable for one side to continue sending packets, all of
-which will acknowledge the last packet correctly received, while the
-system whose packet was lost will be unable to send a new packet
-because the send window will be full.  In this circumstance, neither
-side will time out and one side of the communication will be
-effectively shut down for a while.  Therefore, any system with
-outstanding unacknowledged packets should arrange to time out and
-resend a packet even if data is being received.
-
-Commands are sent as a sequence of data packets with a non-zero local
-channel number.  The last data packet for a command includes a
-trailing null byte (normally a command will fit in a single data
-packet).  Files are sent as a sequence of data packets ending with one
-of length zero.
-
-The channel numbers permit a more efficient implementation of the UUCP
-file send command.  Rather than send the command and then wait for the
-SY response before sending the file, the file data is sent beginning
-immediately after the S command is sent.  If an SN response is
-received, the file send is aborted, and a final data packet of length
-zero is sent to indicate that the channel number may be reused.  If an
-SY reponse with a file position indicator is received, the file send
-adjusts to the file position; this is why the protocol maintains a
-global file position.
-
-Note that the use of channel numbers means that each UUCP system may
-send commands and file data simultaneously.  Moreover, each UUCP
-system may send multiple files at the same time, using the channel
-number to disambiguate the data.  Sending a file before receiving an
-acknowledgement for the previous file helps to eliminate the round
-trip delays inherent in other UUCP protocols.
-
-------------------------------
-
-From: UUCP-j
-Subject: What is the 'j' protocol?
-
-The 'j' protocol is a variant of the 'i' protocol.  It was also
-written by Ian Lance Taylor, and first appeared in Taylor UUCP version
-1.04.
-
-The 'j' protocol is a version of the 'i' protocol designed for
-communication links which intercept a few characters, such as XON or
-XOFF.  It is not efficient to use it on a link which intercepts many
-characters, such as a seven bit link.  The 'j' protocol performs no
-error correction or detection; that is presumed to be the
-responsibility of the 'i' protocol.
-
-When the 'j' protocol starts up, each system sends a printable ASCII
-string indicating which characters it wants to avoid using.  The
-string begins with the ASCII character '^' (octal 136) and ends with
-the ASCII character '~' (octal 176).  After sending this string, each
-system looks for the corresponding string from the remote system.  The
-strings are composed of escape sequences: \ooo, where o is an octal
-digit.  For example, sending the string ^\021\023~ means that the
-ASCII XON and XOFF characters should be avoided.  The union of the
-characters described in both strings (the string which is sent and the
-string which is received) is the set of characters which must be
-avoided in this conversation.  Avoiding a printable ASCII character
-(octal 040 to octal 176, inclusive) is not permitted.
-
-After the exchange of characters to avoid, the normal 'i' protocol
-start up is done, and the rest of the conversation uses the normal 'i'
-protocol.  However, each 'i' protocol packet is wrapped to become a
-'j' protocol packet.
-
-Each 'j' protocol packet consists of a seven byte header, followed by
-data bytes, followed by index bytes, followed by a one byte trailer.
-The packet header looks like this:
-
-    ^
-        Every packet begins with the ASCII character '^', octal 136.
-    HIGH
-    LOW
-        These two characters give the total number of bytes in the
-        packet.  Both HIGH and LOW are printable ASCII characters.
-        The length of the packet is (HIGH - 040) * 0100 + (LOW - 040),
-        where 040 <= HIGH < 0177 and 040 <= LOW < 0140.  This permits
-        a length of 6079 bytes, but there is a further restriction on
-        packet size described below.
-    =
-        The ASCII character '=', octal 075.
-    DATA-HIGH
-    DATA-LOW
-	These two characters give the total number of data bytes in
-        the packet.  The encoding is as described for HIGH and LOW.
-        The number of data bytes is the size of the 'i' protocol
-        packet wrapped inside this 'j' protocol packet.
-    @
-	The ASCII character '@', octal 100.
-
-The header is followed by the number of data bytes given in DATA-HIGH
-and DATA-LOW.  These data bytes are the 'i' protocol packet which is
-being wrapped in the 'j' protocol packet.  However, each character in
-the 'i' protocol packet which the 'j' protocol must avoid is
-transformed into a printable ASCII character (recall that avoiding a
-printable ASCII character is not permitted).  Two index bytes are used
-for each character which must be transformed.
-
-The index bytes immediately follow the data bytes.  The index bytes
-are created in pairs.  Each pair of index bytes encodes the location
-of a character in the 'i' protocol packet which was transformed to
-become a printable ASCII character.  Each pair of index bytes also
-encodes the precise transformation which was performed.
-
-When the sender finds a character which must be avoided, it will
-transform it using one or two operations.  If the character is 0200 or
-greater, it will subtract 0200.  If the resulting character is less
-than 020, or is equal to 0177, it will xor by 020.  The result is
-a printable ASCII character.
-
-The zero based byte index of the character within the 'i' protocol
-packet is determined.  This index is turned into a two byte printable
-ASCII index, INDEX-HIGH and INDEX-LOW, such that the index is
-(INDEX-HIGH - 040) * 040 + (INDEX-LOW - 040).  INDEX-LOW is restricted
-such that 040 <= INDEX-LOW < 0100.  INDEX-HIGH is not permitted to be
-0176, so 040 <= INDEX-HIGH < 0176.  INDEX-LOW is then modified to
-encode the transformation:
-
-    If the character transformation only had to subtract 0200, then
-    INDEX-LOW is used as is.
-
-    If the character transformation only had to xor by 020, then 040
-    is added to INDEX-LOW.
-
-    If both operations had to be performed, then 0100 is added to
-    INDEX-LOW.  However, if the value of INDEX-LOW were initially 077,
-    then adding 0100 would result in 0177, which is not a printable
-    ASCII character.  For that special case, INDEX-HIGH is set to
-    0176, and INDEX-LOW is set to the original value of INDEX-HIGH.
-
-The receiver decodes the index bytes as follows (this is the reverse
-of the operations performed by the sender, presented here for
-additional clarity):
-
-    The first byte in the index is INDEX-HIGH, and the second is
-    INDEX-LOW.
-
-    If 040 <= INDEX-HIGH < 0176, the index refers to the data byte at
-    position (INDEX-HIGH - 040) * 040 + INDEX-LOW % 040.
-
-        If 040 <= INDEX-LOW < 0100, then 0200 must be added to indexed
-        byte.
-
-        If 0100 <= INDEX-LOW < 0140, then 020 must be xor'ed to the
-        indexed byte.
-
-        If 0140 <= INDEX-LOW < 0177, then 0200 must be added to the
-        indexed byte, and 020 must be xor'ed to the indexed byte.
-
-    If INDEX-HIGH == 0176, the index refers to the data byte at
-    position (INDEX-LOW - 040) * 040 + 037.  0200 must be added to the
-    indexed byte, and 020 must be xor'ed to the indexed byte.
-
-This means the largest 'i' protocol packet which may be wrapped inside
-a 'j' protocol packet is (0175 - 040) * 040 + (077 - 040) == 3007
-bytes.
-
-The final character in a 'j' protocol packet, following the index
-bytes, is the ASCII character '~' (octal 176).
-
-The motivation behind using an indexing scheme, rather than escape
-characters, is to avoid data movement.  The sender may simply add a
-header and a trailer to the 'i' protocol packet.  Once the receiver
-has loaded the 'j' protocol packet, it may scan the index bytes,
-transforming the data bytes, and then pass the data bytes directly on
-to the 'i' protocol routine.
-
-------------------------------
-
-From: UUCP-x
-Subject: What is the 'x' protocol?
-
-The 'x' protocol is used in Europe (and probably elsewhere) with
-machines that contain an builtin X.25 card and can send eight bit data
-transparently across X.25 circuits, without interference from the X.28
-or X.29 layers.  The protocol sends packets of 512 bytes, and relies
-on a write of zero bytes being read as zero bytes without stopping
-communication.  It first appeared in the original System V UUCP
-implementation.
-
-------------------------------
-
-From: UUCP-y
-Subject: What is the 'y' protocol?
-
-The 'y' protocol was developed by Jorge Cwik for use in FX UUCICO, a
-PC uucico program.  It is designed for communication lines which
-handle error correction and flow control.  It is a streaming protocol,
-like the 'f' protocol.  It requires an eight bit clean connection.  It
-performs error detection, but not error correction; when an error is
-detected, the line is dropped.  I do not know the implementation
-details.
-
-------------------------------
-
-From: UUCP-d
-Subject: What is the 'd' protocol?
-
-This is apparently used for DataKit muxhost (not RS-232) connections.
-No file size is sent.  When a file has been completely transferred, a
-write of zero bytes is done; this must be read as zero bytes on the
-other end.
-
-------------------------------
-
-From: UUCP-h
-Subject: What is the 'h' protocol?
-
-This is apparently used in some places with HST modems.  It does no
-error checking, and is not that different from the 't' protocol.  I
-don't know the details.
-
-------------------------------
-
-From: UUCP-v
-Subject: What is the 'v' protocol?
-
-The 'v' protocol is used by UUPC/extended, a PC UUCP program.  It is
-simply a version of the 'g' protocol which supports packets of any
-size, and also supports sending packets of different sizes during the
-same conversation.  There are many 'g' protocol implementations which
-support both, but there are also many which do not.  Using 'v' ensures
-that everything is supported.
-
-------------------------------
-
-From: Thanks
-Subject: Thanks
-
-Besides the papers and information acknowledged at the top of this
-article, the following people have contributed help, advice,
-suggestions and information:
-    Earle Ake 513-429-6500 <ake@Dayton.SAIC.COM>
-    cambler@nike.calpoly.edu (Christopher J. Ambler)
-    jhc@iscp.bellcore.com (Jonathan Clark)
-    jorge@laser.satlink.net (Jorge Cwik)
-    celit!billd@UCSD.EDU (Bill Davidson)
-    "Drew Derbyshire" <ahd@kew.com>
-    erik@pdnfido.fidonet.org
-    Matthew Farwell <dylan@ibmpcug.co.uk>
-    dgilbert@gamiga.guelphnet.dweomer.org (David Gilbert)
-    kherron@ms.uky.edu (Kenneth Herron)
-    Mike Ipatow <mip@fido.itc.e-burg.su>
-    Romain Kang <romain@pyramid.com>
-    "Jonathan I. Kamens" <jik@GZA.COM>
-    "David J. MacKenzie" <djm@eng.umd.edu>
-    jum@helios.de (Jens-Uwe Mager)
-    peter@xpoint.ruessel.sub.org (Peter Mandrella)
-    david nugent <david@csource.oz.au>
-    Stephen.Page@prg.oxford.ac.uk
-    joey@tessi.UUCP (Joey Pruett)
-    James Revell <revell@uunet.uu.net>
-    Larry Rosenman <ler@lerami.lerctr.org>
-    Rich Salz <rsalz@bbn.com>
-    evesg@etlrips.etl.go.jp (Gjoen Stein)
-    kls@ditka.Chicago.COM (Karl Swartz)
-    Dima Volodin <dvv@hq.demos.su>
-    jon@console.ais.org (Jon Zeeff)
-    Eric Ziegast <ziegast@uunet.uu.net>
-
-------------------------------
-
-End of UUCP Internals Frequently Asked Questions
-******************************
--- 
-Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
-``You don't have to sleep.  That's just something *they* tell you to keep
-  *control* over you.  Nobody has to sleep; you're *taught* to sleep when
-  you're a kid.  If you're really determined, you can get over it.''
diff --git a/share/FAQ/Text/ctm.FAQ b/share/FAQ/Text/ctm.FAQ
deleted file mode 100644
index 9dc0d05..0000000
--- a/share/FAQ/Text/ctm.FAQ
+++ /dev/null
@@ -1,191 +0,0 @@
-# ----------------------------------------------------------------------------
-# "THE BEER-WARE LICENSE" (Revision 42):
-# <phk@login.dknet.dk> wrote this file.  As long as you retain this notice you
-# can do whatever you want with this stuff. If we meet some day, and you think
-# this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
-# ----------------------------------------------------------------------------
-#
-# $Id: ctm.FAQ,v 1.6 1995/03/16 22:03:09 phk Exp $
-#
-
-		Obtaining FreeBSD-current sources using CTM.
-		============================================
-
-CTM is a method for keeping a remote directory tree in sync with a
-central one.  It has been developed for usage with FreeBSD's source
-trees, though other people may find it useful for other purposes as
-time goes by.  Little, if any, documentation currently exists at this
-time on the process of creating deltas so talk to phk@FreeBSD.org for
-more information should you wish to use CTM for other things.
-
-
-Why should I use CTM ?
-----------------------
-CTM will give you a local copy of the "FreeBSD-current" sources.  If
-you are an active developer on FreeBSD, but have lousy or non-existent
-TCP/IP connectivity, CTM was made for you.  You will need to transfer
-up to four deltas per day (or you can have them arrive in email
-automatically), the sizes for which are always kept as small as
-possible.  This is typically less than 5K, with the occasional (one in
-ten) being 10-50K and every now and then a biggie of 100K+ or more
-coming around.
-
-You will also need to make yourself aware of the various caveats in
-running "current" sources, and for this it is recommended that you
-refer to the relevant FAQ: /usr/share/FAQ/current-policy.FAQ
-
-
-What do I need to use CTM?
---------------------------
-
-You will need two things: The "ctm" program and the initial deltas to
-feed it (to get up to "current" levels).
-
-The ctm program is in the FreeBSD-current tree from version 2.0.0 and
-forward (/usr/src/usr.sbin/ctm).  If you are running an older version
-of FreeBSD, you can fetch the current ctm sources directly from:
-
-	ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/
-
-The "deltas" you feed ctm can be had two ways, ftp or email.  If you
-have general ftp access to the Internet, then the following ftp sites
-support access to CTM:
-
-	ftp://freefall.cdrom.com/pub/CTM
-
-Ftp the the relevant directory and fetch the README file, starting
-from there.
-
-If you only have access to electronic mail or are otherwise blocked
-from using ftp, then you may wish to receive your deltas via email:
-
-Send email to majordomo@freebsd.org to subscribe to the list
-"ctm-src-cur" (if you do not know how to subscribe yourself using
-majordomo, send a message first containing the word `help' - it will
-send you back usage instructions).
-
-When you begin receiving your CTM updates in the mail, you may use the
-ctm_rmail program to unpack and apply them with.  You can actually use
-the ctm_rmail program directly from a entry in /etc/aliases if you
-want.  Check the "ctm_rmail" man page for more details.
-
-NOTE:
------
-
-No matter what method you use to get the CTM deltas, you should subscribe
-to the ctm-announce@freebsd.org mailing list.  In the future this will be
-the only place where announcements about the operation of the CTM system
-will be posted.  Send an email to majordomo@freebsd.org with a single
-line of "subscribe ctm-announce" to get added to the list.
-
-
-Starting off with CTM for the first time:
------------------------------------------
-
-Before you can start using CTM deltas, you will need to get a special
-"base" delta that provides a starting point for all deltas produced
-subsequently to it.
-
-You can recognize a base delta by the 'A' appended to the number
-(src-cur.0341A.gz for instance).  As a rule a base delta is produced
-every 100 deltas, the next one will be src-cur.0400A.gz.
-By the way,  they are large!  25 to 30 Megabytes of gzip'ed data is
-common for a base delta.
-
-If you do have the 2.0-RELEASE srcdist, you can instead retreive the
-src-cur.0372R20.gz file, it's only 4Mb and it will take you to current
-from the 2.0-RELEASE sources.
-
-Once you've picked a base delta to start from, you will also need all 
-deltas with higher numbers following it.
-
-
-Using CTM in your daily life:
------------------------------
-
-To apply the deltas, simply say
-
-	cd /where/ever/you/want/the/stuff
-	ctm -v -v /where/you/store/your/deltas/src-cur.*
-
-CTM understands deltas which have been put through gzip, so you don't
-need to gunzip them first, this saves diskspace.
-
-Unless it feels very secure about the entire process, ctm will not
-touch your tree.  To check out a delta you can also use the "-c" flag
-and CTM won't actually touch your tree, but only check the integrity
-of the delta, and see if it would apply cleanly to the tree.
-
-There are other options to ctm as well, look in the sources.
-
-I would also be very happy if somebody could help with the "user
-interface" portions, as I have realized that I can't make up my mind
-on what options should do what, how and when...
-
-That's really all there is to it.  Everytime you get a new delta, you
-run it through ctm.
-
-Don't remove the deltas, if they are hard to download again.  You just
-might want to keep them around in case something bad happens.  Even if
-you only have floppy disks, consider using "fdwrite" to make a copy.
-
-
-Plans:
-------
-
-Tons of them:
-
- - Make local modifications to the tree possible.  One way to do it
-     could be this:
-     When CTM wants to edit the file "foo/bar.c", it would first check
-     for the existense of "foo/bar.c#ctm"  If this file exists, the
-     delta is applied to it instead.  This way the foo/bar.c file can
-     be edited to suit local needs.
- - Make a "restore file(s)" option to ctm, something like:
-	ctm -r src/sys/i386/wd.c /here/are/my/deltas/src-cur.*
-     would restore wd.c to the current status from the files.
- - Clean up the options to ctm, they became confusing and 
-     counter intuitive.
-
-The bad news is that I am very busy, so any help in doing this will be
-most welcome.  And don't forget to tell me what you want also...
-
-
-Misc. stuff:
-------------
-
-All the "DES infected" (e.g. export controlled) source is not included.
-You will get the "international" version only.  If sufficient interest
-appears, we will set up a "sec-cur" sequence too.
-
-If you are a frequent or valuable contributor to FreeBSD, I will be
-willing to arrange special services, one option is delivery via ftp or
-rcp to a machine closer to you.  You need to have earned this, since
-it takes time to do, but I'll be all the more happy to do it for you
-then.
-
-There is a sequence of deltas for the ports collection too, but interest
-has not been all that high yet.  Tell me if you want an email list for
-that too and we'll consider setting it up.
-
-If you have commit priviledges or are similary authorized by the
-FreeBSD core team, you can also get access to the CVS repository tree
-by the same means.  Contact me (phk@FreeBSD.org) for details.
-
-
-Thanks!
--------
-
-Bruce Evans, for his pointed pen and invaluable comments.
-Soren Schmidt, for patience.
-Stephen McKay, wrote ctm_[rs]mail, much appreciated.
-Jordan Hubbard, for being so stubborn that I had to make it better.
-All the users,  I hope you like it...
-
-Comments ?
-----------
-
-email phk@FreeBSD.org
-
-
-Poul-Henning
diff --git a/share/FAQ/Text/current-policy.FAQ b/share/FAQ/Text/current-policy.FAQ
deleted file mode 100644
index dd61dbd..0000000
--- a/share/FAQ/Text/current-policy.FAQ
+++ /dev/null
@@ -1,170 +0,0 @@
-                        THE FREEBSD CURRENT POLICY 
-
-Last updated: $Date: 1995/02/27 08:25:50 $
-
-This document attempts to explain the rationale behind FreeBSD-current,
-what you should expect should you decide to run it, and states some
-prerequisites for making sure the process goes as smoothly as possible.
-
-
-1.  What is FreeBSD-current?
-
-FreeBSD-current is, quite literally, nothing more than a daily snapshot of
-the working sources for FreeBSD.  These include work in progress, experimental
-changes, and transitional mechanisms that may or may not be present in
-the next official release of the software.  While many of us compile
-almost daily from FreeBSD-current sources, there are periods of time when
-the sources are literally uncompilable.  These problems are generally resolved
-as expeditiously as possible, but whether or not FreeBSD-current sources bring
-disaster or greatly desired functionality can literally be a matter of which
-part of any given 24 hour period you grabbed them in!  Please read on..
-
-Under certain circumstances we will sometimes make binaries for parts of
-FreeBSD-current available, but only because we're interested in getting
-something tested, not because we're in the business of providing binary
-releases of current.  If we don't offer, please don't ask!  It takes far
-too much time to do this as a general task.
-
-
-2. Who needs FreeBSD-current?
-
-FreeBSD-current is made generally available for 3 primary interest groups:
-
-    1.  Members of the FreeBSD group who are actively working on one
-        part or another of the source tree and for whom keeping `current'
-        is an absolute requirement.
-
-    2.  Members of the FreeBSD group who are active ALPHA/BETA testers
-        and willing to spend time working through problems in order to
-        ensure that FreeBSD-current remains as sane as possible.  These
-        are also people who wish to make topical suggestions on changes
-        and the general direction of FreeBSD.
-
-    3.  Peripheral members of the FreeBSD (or some other) group who merely
-        wish to keep an eye on things and use the current sources for
-        reference purposes (e.g. for *reading*, not running).  These
-        people also make the occasional comment or contribute code.
-
-
-3. What is FreeBSD-current _NOT_?
-
-    1.  A fast-track to getting pre-release bits because there's something
-        you heard was pretty cool in there and you want to be the first on
-        your block to have it.
-
-    2.  A quick way of getting bug fixes.
-
-    3.  In any way "officially supported" by us.
-
-        We do our best to help people genuinely in one of the 3
-        "legitimate" FreeBSD-current catagories, but we simply DO NOT
-        HAVE THE TIME to help every person who jumps into FreeBSD-current
-        with more enthusiasm than knowledge of how to deal with
-        experimental system software.  This is not because we're mean and
-        nasty people who don't like helping people out (we wouldn't even be
-        doing FreeBSD if we were), it's literally because we can't answer
-        400 messages a day AND actually work on FreeBSD!  I'm sure if
-        given the choice between having us answer lots of questions or
-        continue to improve FreeBSD, most of you would vote for us
-        improving it (and so would we! :-).
-
-
-4.  Ok.  I still think I "qualify" for FreeBSD-current, so what do I do?
-
-    1.  Join the freebsd-hackers and freebsd-commit mailing lists.
-        This is not just a good idea, it's ESSENTIAL.  If you aren't on
-        freebsd-hackers, you won't read the comments that people are
-        making about the current state of the system and thus will end
-        up stumbling over a lot of problems that others have already
-        found and solved.  Even more importantly, you will miss out on
-        potentially critical information (e.g. "Yo, Everybody!  Before you
-        rebuild /usr/src, you MUST rebuild the kernel or your system
-        will crash horribly!").
-
-        The freebsd-commit list will allow you to see the commit log
-        entry for each change as its made.  This can also contain
-        important information, and will let you know what parts of the
-        system are being actively changed.
-
-        To join these lists, send mail to `majordomo@FreeBSD.ORG'
-        and say:
-
-            subscribe freebsd-hackers
-            subscribe freebsd-commit
-
-        In the body of your message.  Optionally, you can also say `help'
-        and MajorDomo will send you full help on how to subscribe and
-        unsubscribe to the various other mailing lists we support.
-
-    2.  Grab the sources from ftp.FreeBSD.ORG.  You can do this in
-        three ways:
-
-	1.  Using the CTM facility.  Read the ctm.FAQ file for more
-	    information.  Unless you have a good TCP/IP connection at
-	    a flat rate, this is the way to do it.
-
-        2.  Use the CMU `sup' program (Software Update Protocol).
-            This is the second most recommended method, since it allows 
-	    you to grab the entire collection once and then only what's
-            changed from then on.  Many people run sup from cron
-            and keep their sources up-to-date automatically.
-
-	    The problem is that sup does not use the bandwidth efficient,
-	    unless the round-trip is very fast.  If the cost of connection
-	    or the duration of the session is a concern, use CTM.
-
-            To get a binary of the sup program for FreeBSD, as well
-            as the documentation and some sample configuration files,
-            look in:
-
-            FreeBSD.ORG:~ftp/pub/sup
-
-        3.  Use ftp.  The source tree for FreeBSD-current is always
-            "exported" on:
-
-             ftp.FreeBSD.ORG:~ftp/pub/FreeBSD/FreeBSD-current
-
-            We use `wu-ftpd' which allows compressed/tar'd grabbing
-            of whole trees.  e.g. you see:
-
-            usr.bin/lex
-
-            You can do:
-
-            ftp> cd usr.bin
-            ftp> get lex.tar.Z
-
-            And it will get the whole directory for you as a compressed
-            tar file.
-
-    3.  If you're grabbing the sources to run, and not just look at,
-	then grab ALL of current, not just selected portions.  The
-	reason for this is that various parts of the source depend on
-	updates elsewhere and trying to compile just a subset is almost
-	guaranteed to get you into trouble.
-
-    4.  Before compiling current, read the Makefile in /usr/src
-	carefully.  You'll see one-time targets like `bootstrapld'
-	which *MUST* be run as part of the upgrading process.  Reading
-	freebsd-hackers will keep you up-to-date on other bootstrapping
-	procedures that sometimes become necessary as we move towards
-	the next release.
-
-    5.  Be active!  If you're running FreeBSD-current, we want to know
-	what you have to say about it, especially if you have suggestions
-	for enhancements or bug fixes.  Suggestions with accompanying code
-	are received most enthusiastically! :-)
-
-
-Thank you for taking the time to read this all the way through.  We're
-always very keen to remain "open" and share the fruits of our labor
-with the widest possible audience, but sharing development sources has
-always had certain pitfalls associated with it (which is why most
-commercial organizations won't even consider it) and I want to make
-sure that people at least come into this with their eyes open, and
-don't make the leap unless they're good at working without a net!
-
-                                    Jordan
-
-
-
diff --git a/share/FAQ/Text/diskspace.FAQ b/share/FAQ/Text/diskspace.FAQ
deleted file mode 100644
index b696f1c..0000000
--- a/share/FAQ/Text/diskspace.FAQ
+++ /dev/null
@@ -1,267 +0,0 @@
-                    How to assign disk space to FreeBSD.
-
-$Id: diskspace.FAQ,v 1.2 1995/01/03 15:54:02 gclarkii Exp $
-
-1.0  Getting started.
----------------------
-
-After a general introduction, you will find some explanation on what you
-need to do to assign space to FreeBSD on your disk(s).  This is done
-through the "sysinstall" program, which lives on the inital boot floppy.
-Those already expert with PCs may wish to skip ahead to section 1.2, the
-rest of you may (or may not) enjoy the brief history lesson.
-
-
-1.1  The ins and outs of allocating disk storage on your PC.
-------------------------------------------------------------
-
-Modern hard disk drives are now getting big enough that people don't want
-to allocate all of one to just one operating system anymore, especially
-given the increasing size of disk drives (the latest 9.0 Gbyte models
-holding the equivalent of some six thousand 1.44MB floppies!) and the
-virtual explosion of operating system options available for the PC.  To
-solve this problem, IBM came up with a scheme for "slicing" the disks
-into more manageable chunks, or partitions.  It works, but only just.
-To better understand why, first a brief bit of history:
-
-MS-DOS, when hard disk support was unceremoniously grafted on back in the
-late eighties, didn't have such "slices".  What it had was a way to install
-Xenix and MS-DOS on the same disk (Remember when Microsoft were in the UNIX
-business?).
-
-In the first sector on the disk was a piece of "primary boot code" and a
-table with four entries.  Each of those entries pointed at an arbitrary
-slice of the disk, with one of them was marked "active".  The machine would
-boot by reading the first sector containing the boot code into RAM and then
-jumping to it.  The job of this small piece of boot code was to look at
-the 4 entry table and decide which OS was to be booted by looking
-for the "active" flag.   It would go and load the first sector of that slice
-of the disk into RAM and then and jump to it in turn.  This bit of boot
-code was called the "secondary boot", and could be specific to a given
-operating system.  The primary boot code and 4-entry table is known
-as the Master Boot Record, or MBR, and is very important to the proper
-operation of your PC!  We will discuss the MBR in more detail later.
-
-It was later realized, with the hindsight that IBM is famous for, that disks
-could be bigger than the 32Mb that the early DOS FAT-12 file system could
-handle, so they added a kludge:  They had two MSDOS slices, a "Primary" and
-a "Secondary".  The primary could still only be 32Mb, but the Secondary had
-no size limit.  And the trick was that the secondary had ANOTHER "table
-entry" so that now suddenly up to 5 slices could be available to MS-DOS.
-The Secondary boot record was later made recursive, thus effectively
-avoiding any fixed limit.  Of course, they were still stuck with a maximum
-of 26 slices given the use of "drive letters" in DOS.  They also reserved
-only 10 bits for cylinder addressing, limiting DOS to being able to address
-a maximum of 1024 cylinders (and cause of the dreaded "cylinder translation"
-kludges, the misconfiguration of which many users have seen as the notorious
-"Missing Operating System" message).  Yes, truly DOS was and is an utterly
-terrible operating system, which of course explains its amazing degree of
-success.  Anyway, this all brings us up to today, which is where FreeBSD
-comes in:
-
-
-1.2  What FreeBSD does
-----------------------
-FreeBSD has, like any other UNIX-like operating system, the concept of
-"partitions."  Partitions are used to implement its own "slicing"
-abstraction, and although there is no real difference between a slice and a
-partition as such, we use the two words to distinguish between these two
-different levels of slicing.
-
-The result is that we have a two-tier structure on the disk:
-
-+-----------+
-| MBR-table |
-+-----------+        +---------+
-| Slice 1   | -----> |  MSDOS  |
-+-----------+        +---------+
-| Slice 2   | 
-+-----------+        +-------------------+
-| Slice 3   | -----> | FreeBSD-disklabel |
-+-----------+        +-------------------+        +-----------------+
-| Slice 4   |        |    Partition A    | -----> | Root-filesystem |
-+-----------+        +-------------------+        +-----------------+
-                     |    Partition B    | ---
-                     +-------------------+    \    +----------------+
-                     |    Partition C    |     --> | swap-partition |
-                     +-------------------+         +----------------+
-                     |  ...              |
-
-
-Here are the rules that FreeBSD plays by:
-
-A:  FreeBSD always has an MBR slice with type 0xa5 (each of the 4 slices can
-    also have a unique integer identifier so you can tell your DOS slices
-    from your FreeBSD slices from your Linux slices, etc).  This means that
-    there should always be an MBR record, even in the case where FreeBSD
-    occupies the entire disk.
-B:  The FreeBSD slice contains the FreeBSD disklabel in the second sector
-    (remember, the first sector contains the secondary boot code for FreeBSD,
-     which is what prints that FreeBSD prompt at you when you first boot
-     FreeBSD from a floppy or hard disk).
-C:  The 'C' partition in the FreeBSD disklabel corresponds to the entire
-    FreeBSD slice.
-D:  The 'D' partition corresponds to the entire physical disk.
-E:  Should a disk not have a FreeBSD slice (because there simply is no 
-    FreeBSD on it anywhere), then the MBR slices are mapped into partitions
-    'E' to 'H' of an artificially created FreeBSD disklabel.  This is useful
-    for getting at DOS-only disks.
-
-Therefore, to get FreeBSD onto your disk, you need to do the following:
-
-  Step                                                          FreeBSD utility
-  ------------------------------------------------------------  ---------------
-  1.  Make an MBR slice for FreeBSD                             (FDISK)
-  2.  Partition the diskspace in the MBR slice into partitions  (DISKLABEL)
-  3.  Assign mountpoints to the partitions.                     (DISKLABEL)
-
-
-
-2.  The sysinstall utility
---------------------------
-
-The sysinstall utility is the program you first see when you boot
-FreeBSD's install floppy.  It is responsible for partitioning your
-disk, creating an MBR slice for FreeBSD, setting up the disklabel
-within that slice and creating filesystems for each FreeBSD partition
-you create within that slice.  It is composed of a number of screens.
-These are described below.
-
-
-2.1  The main screen
---------------------
-The main screen shows you the current status,  It shows you which disks
-FreeBSD has found, how big they are and how much of it is assigned to 
-FreeBSD in a FreeBSD MBR slice.  It also shows the partitions which have
-had a mountpoint assigned to them (not necessarily FreeBSD partitions; 
-FreeBSD is perfectly capable of mounting DOS disks directly).
-
-(H)elp  -- shows you this file.
-
-(F)disk -- enters the Fdisk editor, where you can change the MBR record.
- This is what you want to use to assign some part of the disk to FreeBSD.
-
-(D)isklabel -- enters the Disklabel editor, here you can change how the
- FreeBSD slice is partitioned for FreeBSD.
-
-(P)rocede -- will continue the installation process.
-
-(Q)uit -- Go back to the entry screen.
-
-
-2.2  FDISK - how to make an MBR slice
--------------------------------------
-There are some rules to follow here since altering your MBR is a potential
-minefield.  There is really no way for the sysinstall program to genuinely
-know that you have a valid MBR, so you have to be extra careful in what
-you edit.  Failure to do this properly can and will destroy your other
-operating system entries!
-
-Even if you don't plan to have MSDOS on a disk, make an MSDOS slice
-using the MSDOS's FDISK.COM program.  The reason for this is that if you
-do it that way, you are 100% sure that FreeBSD will use the same number
-of heads, sectors and cylinders as MSDOS would use.  If you really don't
-plan to have MSDOS on the disk, just (D)elete the slice in the FreeBSD's
-(F)disk editor.
-
-From the main screen press 'F' to enter the MBR editor.  You have five
-commands available:
-
-(H)elp -- Shows you this file.
-
-(D)elete -- Deletes a slice entirely.
-
-(E)dit -- Allows you to edit a slice.  It will ask how many megabytes
-  you want to assign to the slice, and will suggest the maximum possible
-  as a default.  It might say zero, even though there is disk space
-  available, in which case you will probably need to delete and recreate the
-  other partitions to get it to see where the free space is.
-  It will then ask you what type to give the slice, for which the default is
-  0xa5 (a FreeBSD slice).  You can enter any other number here too, which
-  can be useful as a placeholder for some other OS you plan to install
-  later.  Finally, it will ask you about the "boot flag".  0x80 means "boot
-  from this" slice by default, and anything else means "don't".
-
-  If you specified a FreeBSD slice, any existing slices with the 0xa5 
-  type will be reset to 0x00 "unused".  FreeBSD only supports one slice
-  per disk for FreeBSD.
-
-(R)eread -- This is your "undo" function.  It will read the data of the
-  disk again, disposing of any changes you may have made.
-
-(W)rite -- When you are satisfied with the data, this function will write
-  the new MBR to the disk.
-
-(Q)uit -- Go back to the main screen.
-
-
-2.3  Disklabel - How to divide up the FreeBSD slice.
-----------------------------------------------------
-
-The disklabel screen provides the following commands:
-
-(H)elp -- Shows you this file.
-
-(S)ize -- Resizes a partition for you, it will suggest as a default the
-   maximum amount of diskspace it can find.  This algorithm isn't too smart
-   and may say zero, even though there is diskspace available.  If it
-   does, delete and resize the other partitions.
-
-(A)ssign -- Here you assign where the filesystem in a partition is to
-   be mounted.  `b' partitions will always be made into "swap" partitions.
-
-(D)elete -- Delete a partition.
-
-(R)eread -- The undo function.  It will reread the current disklabel from
-   the kernel.
-
-(W)rite -- This will write the disklabel to the disk.  You must always write
-   before you quit, otherwise your changes will be lost.
-
-(Q)uit -- Exit back to the main screen.
-
-
-2.4.  Hints on partition sizing
--------------------------------
-
-While it's impossible to say how much space you're going to want to
-make your various partitions without knowing more about your intended
-applicatins, here are some good rules of thumb to follow:
-
-1. Root (/) should be at least 18MB, and probably no more than 50MB unless
-   you have some special reason for making your root partition really
-   large.  Remember that the root filesystem is only supposed to contain
-   vital system files and little else.
-
-2. Swap should be at least 2*memory.  That is to say if you have 8MB of
-   memory, then you probably want 16MB of swap.  Even more swap space
-   certainly doesn't hurt, if you can afford to allocate it, and you should
-   also think ahead a little to any planned memory upgrades you may have
-   in mind since increasing this later can be very painful!
-
-   If you're going to run the X Window System (XFree86), you should also
-   consider having a *minimum* of 16MB of swap, since X tends to really
-   use it up.
-
-3. /usr can take up the rest of your disk, though some people like to create
-   extra partitions for user home directories and the like.  Be sure to make
-   your /usr big enough to contain the system software (about 50MB) and
-   perhaps some of your own, unless you're going to use symbolic links to
-   point things like /usr/local (or /usr/src) somewhere else.
-
-
-Here are some suggested filesystem names and sizes, just for reference:
-
-Mountpoint	Filesystem size
--------------------------------
-/var		10Mb
-/usr		50Mb
-/		16Mb
-
-/usr/src       120Mb    If you want to have the sources online
-/usr/obj       100Mb    If you want to compile all of them at one time
-
-/usr/X11R6	50Mb	If you load the entire XFree86 binary kit.
-
-
-$Id: diskspace.FAQ,v 1.2 1995/01/03 15:54:02 gclarkii Exp $
diff --git a/share/FAQ/Text/kernel-debug.FAQ b/share/FAQ/Text/kernel-debug.FAQ
deleted file mode 100644
index 304bcd3..0000000
--- a/share/FAQ/Text/kernel-debug.FAQ
+++ /dev/null
@@ -1,417 +0,0 @@
-# Hello emacs, this is -*- indented-text -*-
-
-                   Kernel debugging FAQ for FreeBSD
-
-$Id: kernel-debug.FAQ,v 1.3 1995/07/30 12:53:39 joerg Exp $
-
-
-*** Debugging a kernel crash dump with kgdb ***
-
-  [In the following, the term ``kgdb'' refers to gdb run in `kernel
-  debug mode'.  This can be accomplished by either starting the gdb
-  with the option ``-k'', or by linking and starting it under the
-  name ``kgdb''.  This is not being done by default, however.]
-
-  Here are some instructions for getting kernel debugging working on a
-  crash dump, it assumes that you have enough swap space for a crash
-  dump.  If you happen to have multiple swap partitions with the first
-  one being too small to keep the dump, you can configure your kernel
-  to use an alternate dump device (in the ``config kernel'' line), or
-  you can tell this using the dumpon(8) command.  Dumps to non-swap
-  devices (e.g. tapes) are currently not supported.
-
-  Config your kernel using config -g
-
-  Either, use the dumpon(8) command to tell the kernel where to dump
-  to (note that this will have to be done after configuring the
-  partition in question as swap space via swapon(8)).  This is
-  normally arranged via sysconfig and /etc/rc.  Alternatively, you can
-  hard-code the dump device via the `dump' clause in the `config' line
-  of your kernel config file.
-
-  When the kernel's been built make a copy of it, say kernel.debug,
-  and then run strip -x on the original. Install the original as
-  normal.  You may also install the unstripped kernel, but symtab
-  lookup time for some programs might drastically increase, and since
-  the whole kernel is loaded entirely at boot time and cannot be
-  swapped out later, you're going to waste several megabytes of
-  physical RAM.
-
-  If you are testing a new kernel (e.g. by typing the new kernel's
-  name at the boot prompt), but need to boot a different one in order
-  to get your system up & running again, do boot it only into single
-  user state (the -s flag at the boot prompt), and then perform the
-  following steps:
-
-  fsck -p
-  mount -a -t ufs       # so your file system for /var/crash is writable
-  savecore -N /kernel.panicked /var/crash
-  exit                  # ...to multi-user
-
-  This instructs savecore to use another kernel for symbol name
-  extraction; it would default to the currently running kernel
-  otherwise.
-
-  Now, after a crash dump, go to /sys/compile/WHATEVER and run
-  kgdb. From kgdb do:
-
-  symbol-file kernel.debug
-  exec-file /var/crash/system.0
-  core-file /var/crash/ram.0
-
-  and voila, you can debug the crash dump using the kernel sources
-  just like you can for any other program.
-
-  If your kernel panicked due to a trap (perhaps the most common case
-  for getting a core dump), the following trick might help you.  Examine
-  the stack (`where') and look for the stack frame in the function
-  trap().  Go `up' to that frame, and then type:
-
-  frame frame->tf_ebp frame->tf_eip
-
-  This will tell kgdb to go to the stack frame explicitly named by a
-  frame pointer and instruction pointer, which is the location where
-  the trap occured.  There are still some bugs in kgdb (you can go
-  `up' from there, but not `down'; the stack trace will still remain
-  as it was before going to here), but generally this method will lead
-  you much closer to the failing piece of code.
-
-  Here's a script log of a kgdb session illustrating the above.  Long
-  lines have been folded to improve readability, and the lines are
-  numbered for reference.  Despite of this, it's a real-world error
-  trace taken during the development of the pcvt console driver.
-
-   1:Script started on Fri Dec 30 23:15:22 1994
-   2:uriah # cd /sys/compile/URIAH
-   3:uriah # kgdb kernel /var/crash/vmcore.1 
-   4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done.
-   5:IdlePTD 1f3000
-   6:panic: because you said to!
-   7:current pcb at 1e3f70
-   8:Reading in symbols for ../../i386/i386/machdep.c...done.
-   9:(kgdb) where
-  10:#0  boot (arghowto=256) (../../i386/i386/machdep.c line 767)
-  11:#1  0xf0115159 in panic ()
-  12:#2  0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698)
-  13:#3  0xf010185e in db_fncall ()
-  14:#4  0xf0101586 in db_command (-266509132, -266509516, -267381073)
-  15:#5  0xf0101711 in db_command_loop ()
-  16:#6  0xf01040a0 in db_trap ()
-  17:#7  0xf0192976 in kdb_trap (12, 0, -272630436, -266743723)
-  18:#8  0xf019d2eb in trap_fatal (...)
-  19:#9  0xf019ce60 in trap_pfault (...)
-  20:#10 0xf019cb2f in trap (...)
-  21:#11 0xf01932a1 in exception:calltrap ()
-  22:#12 0xf0191503 in cnopen (...)
-  23:#13 0xf0132c34 in spec_open ()
-  24:#14 0xf012d014 in vn_open ()
-  25:#15 0xf012a183 in open ()
-  26:#16 0xf019d4eb in syscall (...)
-  27:(kgdb) up 10
-  28:Reading in symbols for ../../i386/i386/trap.c...done.
-  29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\
-  30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\
-  31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\
-  32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\
-  33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\
-  34:ss = -266427884}) (../../i386/i386/trap.c line 283)
-  35:283                             (void) trap_pfault(&frame, FALSE);
-  36:(kgdb) frame frame->tf_ebp frame->tf_eip
-  37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done.
-  38:#0  0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\
-  39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403)
-  40:403             return ((*linesw[tp->t_line].l_open)(dev, tp));
-  41:(kgdb) list
-  42:398        
-  43:399             tp->t_state |= TS_CARR_ON;
-  44:400             tp->t_cflag |= CLOCAL;  /* cannot be a modem (:-) */
-  45:401     
-  46:402     #if PCVT_NETBSD || (PCVT_FREEBSD >= 200)
-  47:403             return ((*linesw[tp->t_line].l_open)(dev, tp));
-  48:404     #else
-  49:405             return ((*linesw[tp->t_line].l_open)(dev, tp, flag));
-  50:406     #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */
-  51:407     }
-  52:(kgdb) print tp
-  53:Reading in symbols for ../../i386/i386/cons.c...done.
-  54:$1 = (struct tty *) 0x1bae
-  55:(kgdb) print tp->t_line
-  56:$2 = 1767990816
-  57:(kgdb) up
-  58:#1  0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\
-  59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126)
-  60:       return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p));
-  61:(kgdb) up
-  62:#2  0xf0132c34 in spec_open ()
-  63:(kgdb) up
-  64:#3  0xf012d014 in vn_open ()
-  65:(kgdb) up
-  66:#4  0xf012a183 in open ()
-  67:(kgdb) up
-  68:#5  0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\
-  69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\
-  70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \
-  71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \
-  72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673)
-  73:673             error = (*callp->sy_call)(p, args, rval);
-  74:(kgdb) up
-  75:Initial frame selected; you cannot go up.
-  76:(kgdb) quit
-  77:uriah # exit
-  78:exit
-  79:
-  80:Script done on Fri Dec 30 23:18:04 1994
-
-  Comments to the above script:
-  
-  line  6:  this is a dump taken from within DDB (see below), hence the
-            panic comment ``because you said to!'', and a rather long
-            stack trace; the initial reason for going into DDB has been
-            a page fault trap though
-  
-  line 20:  the location of function ``trap()'' in the stack trace
-  
-  line 36:  force usage of a new stack frame, kgdb responds and displays
-            the source line where the trap happened; from looking at the
-            code, there's a high probability that either the pointer
-            access for ``tp'' was messed up, or the array access was
-            out of bounds
-  
-  line 52:  the pointer looks suspicious, but happens to be a valid
-            address...
-  
-  line 56:  ... but obviously points to garbage, so we have found our
-            error, sigh!  [For those uncommon with that particular piece
-            of code: tp->t_line refers to the line discipline of the
-            console device here, which must be a rather small integer
-            number.]
-  
-
-
-*** Post-mortem analysis of a dump ***
-
-  What to do if a kernel dumped core but you didn't expect it, and it's
-  therefore not compiled using config -g?
-
-  Not everything is lost here.  Don't panic. :-)
-
-  Of course, you still need to enable crash dumps at all.  See above
-  on the options you've got to do this.  (This is for safety reasons
-  in the default kernels, to avoid them trying to dump e.g. during
-  system installation where there's no FreeBSD partition at all and
-  valuable data on the disk could be destroyed.)
-
-  Go to your kernel compile directory, and edit the line containing
-  COPTFLAGS?=-O.  Add the `-g' option there (but DON'T change anything
-  on the level of optimization).  If you do already know roughly the
-  probable location of the failing piece of code (e.g., the `pcvt'
-  driver in the example above), remove all the object files for this
-  code.  Rebuild the kernel. Due to the time stamp change on the
-  Makefile, there will be some other object files rebuild, e.g.
-  trap.o.  With a bit of luck, the added -g option won't change
-  anything for the generated code, so you'll finally get a new kernel
-  with similiar code to the faulting one but some debugging symbols.
-  You should at least verify the old and new sizes with the `size'
-  command; if they mismatch, you probably need to give up here.
-
-  Go and examine the dump as described above.  The debugging symbols
-  might be incomplete for some places (as can be seen in the stack trace
-  in the example above: some functions are displayed without line
-  numbers and argument lists).  If you need more debugging symbols,
-  remove the appropriate object files and repeat the kgdb session until
-  you know enough.
-
-  All this is not guaranteed to work, but most likely will do it fine.
-
-
-
-*** On-line kernel debugging using DDB ***
-
-  While kgdb as an offline debugger provides a very high level of user
-  interface (e.g. it can lookup source files, display C structures
-  etc.), there are some things it cannot do.  The most important ones
-  being breakpointing and single-stepping kernel code.
-
-  If you need to do low-level debugging on your kernel, there's an on-
-  line debugger available called DDB.  It allows to set breakpoints,
-  single-step kernel functions, examine and change kernel variables
-  etc.  It can however not access kernel source files, and it does
-  only have access to the global and static symbols, but not to the
-  full debug information (including type and line number information)
-  like kgdb.
-
-  To configure your kernel to include DDB, add the option line
-
-        options DDB
-
-  to your config file, and rebuild.
-
-  (Note that if you have an older version of the boot blocks, your
-  debugger symbols might not be loaded at all.  Update the boot
-  blocks, the recent ones do load the DDB symbols automagically.)
-
-  Once your DDB kernel is running, there are several ways to enter
-  DDB.  The first (and most early) way is to set the boot flag `-d'
-  (right at the boot prompt).  The kernel will start up in debug mode
-  and enter DDB prior to any device probing.  Hence you are able to
-  even debug the device probe/attach functions.
-
-  The second scenario is a hot-key on the keyboard, usually Ctrl-Alt-
-  ESC.  (For syscons, this can be remapped, and some of the
-  distributed maps do this, so watch out.)  There's an option
-  available for a COMCONSOLE kernel (``options BREAK_TO_DEBUGGER'')
-  that allows the use of a serial line BREAK on the console line to
-  enter DDB.
-
-  The third way is that any panic condition will branch to DDB if the
-  kernel is configured to use it.  (Thus it is not wise to configure a
-  kernel with DDB for a machine running unattended.)
-
-
-  The DDB commands roughly resemble some gdb commands.  The first you
-  probably need is to set a breakpoint:
-
-  b function-name
-  b address
-
-  Numbers are taken hexadecimal by default, but to make them distinct
-  from symbol names, hex numbers starting with the letters `a' - `f'
-  need to be preceded with `0x' (for other numbers, this is optional).
-  Simple expressions are allowed, e.g. ``function-name + 0x103''.
-
-  To continue the operation of an interrupted kernel, simply type
-
-  c
-
-  To get a stack trace, use
-
-  trace
-
-  Note that when entering DDB via a hot-key, the kernel is currently
-  servicing an interrupt, so the stack trace might be not of much use
-  for you.
-
-  If you want to remove a breakpoint, use
-
-  del
-  del address-expression
-
-  The first form will be accepted immediately after a breakpoint hit,
-  and deletes the current breakpoint.  The second form can remove any
-  breakpoint, but you need to specify the exact address, as it can be
-  obtained from
-
-  show b
-
-  To single-step the kernel, try
-
-  s
-
-  This will step into functions, but you can make DDB trace them until
-  the matching return statement is reached by
-
-  n
-
-  NOTE: this is different from gdb's ``next'' statement, it's like
-  gdb's ``finish''.
-
-  To examine data from memory, use e.g.
-
-  x/wx 0xf0133fe0,40
-  x/hd db_symtab_space
-  x/bc termbuf,10
-  x/s stringbuf
-
-  for word/halfword/byte access, and hexadecimal/decimal/character/
-  string display.  The number after the comma is the object count.
-  To display the next 0x10 items, simply use
-
-  x ,10
-
-  Similiarly, use
-
-  x/ia foofunc,10
-
-  to disassemble the first 0x10 instructions of foofunc, and display
-  them along with their offset from the beginning of foofunc.
-
-  To modify the memory, use the write command:
-
-  w/b termbuf 0xa 0xb 0
-  w/w 0xf0010030 0 0
-
-  The command modifier (b/h/w) specifies the size of the data to be
-  writtten, the first following expression is the address to write to,
-  the remainder is interpreted as data to write to successive memory
-  locations.
-
-  If you need to know the current registers, use
-
-  show reg
-
-  Alternatively, you can display a single register value by e.g.
-
-  print $eax
-
-  and modify it by
-
-  set $eax new-value
-
-
-  Should you need to call some kernel functions from DDB, simply
-  say
-
-  call func(arg1, arg2, ...)
-
-  The return value will be printed.
-
-  For a ps-style summary of all running processes, use
-
-  ps
-
-
-
-  Well, you've now examined why your kernel failed, and you wish to
-  reboot.  Remember that, depending on the severity of previous
-  malfunctioning, not all parts of the kernel might still be working
-  as expected.  Perform one of the following actions to shut down and
-  reboot your system:
-
-
-  call diediedie()
-
-  (must usually be followed by another ``c[ontinue]'' statement),
-  will cause your kernel to dump core and reboot, so you can later
-  analyze the core on a higher level with kgdb.
-
-  There's now an alias for this: ``panic''.
-
-
-  call boot(0)
-
-  might be a good way to cleanly shut down the running system, sync()
-  all disks, and finally reboot.  As long as the disk and file system
-  interfaces of the kernel are not damaged, this might be a good way
-  for an almost clean shutdown.
-
-
-  call cpu_reset()
-
-  ...is the final way out of the desaster, almost similiar to hitting
-  the Big Red Button.
-
-
-
-*** What to do if i want to debug a console driver? ***
-
-  Since you need a console driver to run DDB on, things are more
-  complicated if the console driver itself is flakey.  You might
-  remember the ``options COMCONSOLE'' line, and hook up a standard
-  terminal onto your first serial port.  DDB works on any configured
-  console driver, of course it also works on a COMCONSOLE.
-
-
-
-  Paul Richards, FreeBSD core team member. (paul@FreeBSD.org)
-  J"org Wunsch (joerg@FreeBSD.org)
-
diff --git a/share/FAQ/Text/kernel-memory.FAQ b/share/FAQ/Text/kernel-memory.FAQ
deleted file mode 100644
index 79ab09a..0000000
--- a/share/FAQ/Text/kernel-memory.FAQ
+++ /dev/null
@@ -1,72 +0,0 @@
-~From: J Wunsch <j@uriah.heep.sax.de>
-~Message-Id: <199504160843.KAA16160@uriah.heep.sax.de>
-~Subject: Memory usage (Was Re: Memory init pattern)
-~To: freebsd-hackers@FreeBSD.org (FreeBSD hackers)
-~Date: Sun, 16 Apr 1995 10:43:29 +0200 (MET DST)
-
-[Audience extended to -hackers, since it's a general topic.]
-
-As Frank Durda IV wrote:
-> 
-> By the way, I have seen no description of how FreeBSD uses PC memory, ie
-> what 0-640K gets used for, does the kernel load there or higher,
-> is the kernel relocated, etc.  Is there a paper on this?
-
-Since i've just digged through the boot code, i can tell you what's
-going there. :)  [Someone going to collect this sort of messages
-and making a kernel hackers manual?]
-
-The boot sector will be loaded at 0:0x7c00, and relocates itself
-immediately to 0x7c0:0.  (This is nothing magic, just an adjustment
-for the %cs selector, done by an ljmp.)
-
-It then loads the first 15 sectors at 0x10000 (segment BOOTSEG in the
-biosboot Makefile), and sets up the stack to work below 0x1fff0.
-After this, it jumps to the entry of boot2 within that code.  I.e., it
-jumps over itself and the (dummy) partition table, and it's going to
-adjust the %cs selector -- we are still in 16-bit mode there.
-
-boot2 asks for the boot file, and examines the a.out header.  It masks
-the file entry point (usually 0xf0100000) by 0x00ffffff, and loads the
-file there.  Hence the usual load point is 1 MB (0x00100000).  During
-load, the boot code toggles back and forth between real and protected
-mode, to use the BIOS in real mode.
-
-The boot code itself uses segment selectors 0x18 and 0x20 for %cs and
-%ds/%es in protected mode, and 0x28 to jump back into real mode.  The
-kernel is finally started with %cs 0x08 and %ds/%es/%ss 0x10, which
-refer to dummy descriptors covering the whole address space.
-
-The kernel will be started at its load point.  Since it's been linked
-for another (high) address, it will have to execute PIC until the page
-table and page directory stuff is setup properly, at which point
-paging will be enabled and the kernel finally runs at the address
-where it has been linked to.
-
-[... -- no longer valid]
-
-The later memory usage (once paging is enabled) could better be
-explained by the VM folks.
-
--- 
-cheers, J"org
-
-joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/
-Never trust an operating system you don't have sources for. ;-)
-
-~Message-Id: <199504160955.CAA00143@corbin.Root.COM>
-~To: freebsd-hackers@FreeBSD.org (FreeBSD hackers)
-~Subject: Re: Memory usage (Was Re: Memory init pattern) 
-~From: David Greenman <davidg@Root.COM>
-~Date: Sun, 16 Apr 1995 02:55:50 -0700
-
-...
-   The physical pages immediately following the kernel BSS contain proc0's page
-directory, page tables, and upages. Some time later when the VM system is
-initialized, the physical memory between 0x1000-0x9ffff and the physical memory
-after the kernel (text+data+bss+proc0 stuff+other misc) is made available in
-the form of general VM pages and added to the global free page list.
-   Does this answer the question?
-
--DG
-
diff --git a/share/FAQ/Text/mailing-list.FAQ b/share/FAQ/Text/mailing-list.FAQ
deleted file mode 100644
index 881890f..0000000
--- a/share/FAQ/Text/mailing-list.FAQ
+++ /dev/null
@@ -1,105 +0,0 @@
-                     THE FREEBSD MAILING LIST FAQ 
-
-$Id: mailing-list.FAQ,v 1.5 1995/01/03 15:54:04 gclarkii Exp $
-
---
-Though many of the FreeBSD development members read USENET, we cannot
-always guarantee that we'll get to your questions in a timely fashion
-(or at all) if you post them only to one of the comp.os.386bsd.*
-groups.  By addressing your questions to the appropriate mailing list
-you will reach both us and a concentrated FreeBSD audience, invariably
-assuring a better (or at least faster) response.
-
-The following is a summary of the mailing lists:  
-
-List                            Purpose
------------------------------------------------------------------------------
-freebsd-admim                   Administrative issues (limited)
-freebsd-arch                    Architecture and design discussions (limited)
-freebsd-bugs                    Bug reports
-freebsd-hackers                 Technical discussions and suggestions
-freebsd-questions               User questions
-freebsd-announce                Important events / milestones
-freebsd-current                 Discussions about the use of FreeBSD-current
-freebsd-commit			Commit messages to source repository
-freebsd-core			FreeBSD core team (limited)
-freebsd-security                Security issues
-freebsd-fs                      Filesystems
-freebsd-ports                   Discussion of "ports"
-freebsd-platforms               Porting to Non-Intel platforms
-freebsd-hardware                General discussion of FreeBSD hardware
-freebsd-install                 Installation issues (limited)
-
------------------------------------------------------------------------------
-
-The following lists are for people seeing the log messages for source changes 
-in specific areas:
-
-List name	Source area		Area Description (source for)
------------------------------------------------------------------------------
-cvs-CVSROOT	/usr/src/[A-Z]*		Top level /usr/src file changes
-cvs-all		/usr/src		All changes to the tree (superset)
-cvs-bin		/usr/src/bin		System binaries
-cvs-etc		/usr/src/etc		System files
-cvs-games	/usr/src/games		Games
-cvs-gnu		/usr/src/gnu		GPL'd utilities
-cvs-include	/usr/src/include	Include files
-cvs-kerberosIV	/usr/src/kerberosIV	Kerberos encryption code
-cvs-lib		/usr/src/lib		System libraries
-cvs-libexec	/usr/src/libexec	System binaries
-cvs-sbin	/usr/src/sbin		System binaries
-cvs-share	/usr/src/share		System shared files
-cvs-sys		/usr/src/sys		Kernel
-cvs-usrbin	/usr/src/usr.bin	Use binaries
-cvs-usrsbin	/usr/src/usr.sbin	System binaries
-cvs-ports	/usr/ports		Ported software
------------------------------------------------------------------------------
-
-Even though the lists freebsd-core, freebsd-admin, freebsd-install and 
-freebsd-arch are closed, anyone is free to send suggestions and comments
-to them.  All other lists are open.
-
-All mailing lists live on `FreeBSD.ORG', so to post to a list you
-simply mail to `<listname>@FreeBSD.ORG'.  It will then be redistributed
-to mailing list members throughout the world.
-
-To subscribe to a list, send mail to:
-
-                      majordomo@FreeBSD.ORG
-
-And include the keyword
-
-                subscribe <listname> [<optional address>]
-
-In the body of your message.  For example, to subscribe yourself to
-freebsd-hackers, you'd do:
-
-                % mail majordomo@FreeBSD.ORG
-                subscribe freebsd-hackers
-                ^D
-
-If you want to subscribe yourself under a different name, or submit a
-subscription request for a local mailing list (note: this is more efficient
-if you have several interested parties at one site, and highly appreciated by
-us!), you would do something like:
-
-                % mail majordomo@FreeBSD.ORG
-                subscribe freebsd-hackers local-hackers@somesite.com
-                ^D
-
-Finally, it is also possible to unsubscribe yourself from a list, get a
-list of other list members or see the list of mailing lists again by
-sending other types of control messages to majordomo.  For a complete
-list of available commands, do this:
-
-                % mail majordomo@FreeBSD.ORG
-                help
-                ^D
-
-Finally, it is suggested that you only join the freebsd-hackers or
-freebsd-questions mailing lists if you're also willing to see upwards
-of 100 messages a day (peak)!  If you're only interested in the "high points",
-then it's suggested that you join freebsd-announce, which will contain
-only infrequent traffic.
-
-                                Thank you!
diff --git a/share/FAQ/Text/nfs.FAQ b/share/FAQ/Text/nfs.FAQ
deleted file mode 100644
index 88c5fc5..0000000
--- a/share/FAQ/Text/nfs.FAQ
+++ /dev/null
@@ -1,79 +0,0 @@
-FreeBSD and NFS [for a FAQ]
-
-$Id: nfs.FAQ,v 1.2 1995/01/03 15:54:05 gclarkii Exp $
-
-Certain Ethernet adapters for ISA PC systems have limitations which
-can lead to serious network problems, particularly with NFS.  This
-difficulty is not specific to FreeBSD, but FreeBSD systems are affected
-by it.
-
-The problem nearly always occurs when (FreeBSD) PC systems are networked
-with high-performance workstations, such as those made by Silicon Graphics,
-Inc., and Sun Microsystems, Inc.  The NFS mount will work fine, and some
-operations may succeed, but suddenly the server will seem to become
-unresponsive to the client, even though requests to and from other systems
-continue to be processed.  This happens to the client system, whether the
-client is the FreeBSD system or the workstation.  On many systems, there is
-no way to shut down the client gracefully once this problem has manifested
-itself.  The only solution is often to reset the client, because the NFS
-situation cannot be resolved.
-
-Though the "correct" solution is to get a higher performance and capacity
-Ethernet adapter for the FreeBSD system, there is a simple workaround that
-will allow satisfactory operation.  If the FreeBSD system is the SERVER,
-include the option "wsize=1024" on the mount from the client.  If the
-FreeBSD system is the CLIENT, then mount the NFS file system with the
-option "rsize=1024".  These options may be specified using the fourth
-field of the fstab entry on the client for automatic mounts, or by using
-the "-o" parameter of the mount command for manual mounts.
-
-In the following examples, "fastws" is the host (interface) name of a
-high-performance workstation, and "freebox" is the host (interface) name of
-a FreeBSD system with a lower-performance Ethernet adapter.  Also,
-"/sharedfs" will be the exported NFS filesystem (see "man exports"), and
-"/project" will be the mount point on the client for the exported file
-system.  In all cases, note that additional options, such as "hard" or
-"soft" and "bg" may be desireable in your application.
-
-Examples for the FreeBSD system ("freebox") as the client:
-    in /etc/fstab on freebox:
-fastws:/sharedfs /project nfs rw,rsize=1024 0 0
-    as a manual mount command on freebox:
-mount -t nfs -o rsize=1024 fastws:/sharedfs /project
-
-Examples for the FreeBSD system as the server:
-    in /etc/fstab on fastws:
-freebox:/sharedfs /project nfs rw,wsize=1024 0 0
-    as a manual mount command on fastws:
-mount -t nfs -o wsize=1024 freebox:/sharedfs /project
-
-Nearly any 16-bit Ethernet adapter will allow operation without the above
-restrictions on the read or write size.
-
-For anyone who cares, here is what happens when the failure occurs, which
-also explains why it is unrecoverable.  NFS typically works with a "block"
-size of 8k (though it may do fragments of smaller sizes).  Since the maximum
-Ethernet packet is around 1500 bytes, the NFS "block" gets split into
-multiple Ethernet packets, even though it is still a single unit to the
-upper-level code, and must be received, assembled, and ACKNOWLEDGED as a
-unit.  The high-performance workstations can pump out the packets which
-comprise the NFS unit one right after the other, just as close together as
-the standard allows.  On the smaller, lower capacity cards, the later
-packets overrun the earlier packets of the same unit before they can be
-transferred to the host and the unit as a whole cannot be reconstructed or
-acknowledged.  As a result, the workstation will time out and try again,
-but it will try again with the entire 8K unit, and the process will be
-repeated, ad infinitum.
-
-By keeping the unit size below the Ethernet packet size limitation, we
-ensure that any complete Ethernet packet received can be acknowledged
-individually, avoiding the deadlock situation.
-
-Overruns may still occur when a high-performance workstations is slamming
-data out to a PC system, but with the better cards, such overruns are
-not guarranteed on NFS "units".  When an overrun occurs, the units affected
-will be retransmitted, and there will be a fair chance that they will be
-received, assembled, and acknowledged.
--- 
-		   John Lind, Starfire Consulting Services
-E-mail: john@starfire.MN.ORG		USnail: PO Box 17247, Mpls MN  55417
diff --git a/share/FAQ/Text/ports.FAQ b/share/FAQ/Text/ports.FAQ
deleted file mode 100644
index 2a447ad..0000000
--- a/share/FAQ/Text/ports.FAQ
+++ /dev/null
@@ -1,246 +0,0 @@
-			The FreeBSD Ports FAQ file
-
-Revision: $Id: ports.FAQ,v 1.2 1995/01/06 19:24:13 gpalmer Exp $
-
-The ports system is kinda new, so there haven't been too many FAQ's to
-date, but hopefully this document will pre-empt (some|most) of them!!
-The ports system is constantly changing, but hopefully this document
-will be kept reasonably up to date (and you never know, it might even
-make sense!).
-
-					- Gary Palmer
-					& jkh
-
-1) What is a port?
-
-    Unfortunately, there are more variations of UN*X than most people
-know of, and hence not all software for UN*X available on the Internet
-will work on all versions of UN*X (in fact, I can guarantee it!).
-Hence, some software needs modifications to work under some UN*Xs. The
-process of making those modifications is known as ``porting'' and the
-result known as a ``port'' (not to be confused with the sockets on the
-back of your computer!).
-
-
-2) What is the FreeBSD Ports Collection?
-
-    People who (allegedly) know what they are doing have automated the
-process of ``porting'' software to FreeBSD, and the result is the
-Ports Collection.  The general idea is that a combination of various
-programming tools available in the base FreeBSD installation will
-allow you to fetch the port from a FreeBSD mirror site, type ``make''
-and get the fully working program.
-
-    The ports collection itself normally doesn't have any of the
-original source code necessary for the compilation in the tree, just
-those shell scripts, Makefiles and source code ``diffs'' that are
-necessary to compile the program under FreeBSD.  This is meant to keep
-the entire system down to a manageable size, and the current system
-has over 100 ports in the master source tree, and yet a compressed tar
-file of that tree is about 2 megabytes (all the source code needed is
-over 100Mb's!).
-
-
-3) How does the system compile with no source code?
-
-    A ports' Makefile automatically looks in a central location on
-your system (usually /usr/ports/distfiles, though this value can be
-customized) for the associated set of original distribution files that
-have been ``ported''.  These are generally provided at various places
-on the Internet, though if you have a CDROM distribution of FreeBSD
-then you've already got them available on your CD for ease of use.
-See section 3.1 if you have such a CD distribution, otherwise skip to
-section 3.2.
-
-3.1  Compiling ports from CD
-
-    Type something profound here.
-
-3.2  Compiling ports using an Internet connection
-
-    The ports collection can also use an auto-fetch system to keep
-your ports collection source tree up to date, updating the central
-``distfiles'' version for you the next time you compile the port.
-
-    Of course, this always assumes you have a permanent network link,
-or don't mind heavy usage of your telephone.  If you don't want heavy
-network usage when you compile your ports tree, you can pre-fetch the
-necessary tarballs beforehand and put them into /usr/ports/distfiles
-(or wherever DISTDIR points) by hand.  A good way to see what files a
-port is going to need is to cd to that port's directory and do a
-``make -n fetch'' to see what it does.
-
-    You can also chose to get the source files either from the master
-FTP site as defined in the relevant Makefile (in the MASTER_SITES
-line), or some FreeBSD mirror site also carrying a set of distfiles,
-as does the master FTP site on ftp.FreeBSD.org (aka ftp.cdrom.com) in
-the directory /pub/FreeBSD/ports/distfiles.  Note that the files in
-that directory are not guarenteed to be kept up to date - this is a
-volunteer project!  We can't make any guarantees about the mirror
-sites either - they are obviously under independant control and don't
-even have to mirror the distfiles directory.
-
-    If you have a non-permanant link, you can fetch all the distfiles by
-going to the top of the tree and typing ``make fetch''.
-
-
-4) It doesn't work?!
-
-Oh. You can do one of four (4) things :
-
-a) Fix it yourself. Technical details can be found in the GUIDELINES file,
-   available from URL ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/GUIDELINES
-
-b) Gripe. This is done by e-mail *ONLY*! The people at Walnut Creek are
-   in no way responsible for the functionality (or lack thereof) of the
-   FreeBSD system as a whole, and especially the ports system, which
-   is mainly contributed by 3rd parties. (If you don't believe me, check
-   the catalogue, especially the line saying "We cannot offer tech-support
-   on this product")
-
-   The e-mail address is Ports@FreeBSD.org.  Please include details of
-   the port, where you got both the port source & distfile(s) from, and
-   what the error was.
-
-   Note: At time of writing, lang/Sather doesn't seem to work on Pentium
-   machines due to the Intel Curse (aka the Floating Point Division Bug).
-   Please don't tell us about this - gripe to Intel instead - it's their
-   bug!
-
-c) Forget it. This is the easiest for most - very few of the programs in
-   ports can be classed as `essential'!
-
-d) Grab the pre-compiled package from a ftp server. The ``master'' package
-   collection is in:
-	   ftp://ftp.FreeBSD.org/pub/FreeBSD/packages/
-
-   though check your local mirror first, please!
-
-   These are more likely to work (on the whole) than trying to compile from
-   source, and a lot faster!
-
-
-5) I've ported a program and I want to make a port out of it. What now?
-
-   See the file GUIDELINES, in:
-	   ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/GUIDELINES
-
-   This contains details of the procedure and structure involved.
-
-
-6) I've got a good port, what now?
-
-   Upload the fixed version to freefall.cdrom.com /pub/incoming or
-ftp.FreeBSD.org /pub/FreeBSD/incoming and send e-mail to
-ports@FreeBSD.org with the filename and details.  Someone on the
-all-volunteer `ports committee' will (hopefully) look it over and
-commit it to the ports collection if they like the looks of it.
-
-
-7) Things go funny during the fetch stage of compilation!
-
-   We know.  Please don't blame us. There is a program called `ncftp'
-which is used instead of the normal ftp as it can do so-called
-``background'' or ``batch'' transfers, ideal for this situation.
-Unfortunately it can do strange things, and has crashed at least one
-machine (during circumstances stranger than most, I'll admit, but it
-was still responsible). Hopefully a future release of ncftp will fix
-these problems (it is not maintained by the main FreeBSD team, but a
-third party, who is I believe aware of its shortcomings)
-
-
-8) I want to leave the compile going overnight, but some ports don't
-   like this.
-
-   There is a way around this. Before starting the compilation, type:
-	setenv BATCH yes # (if you use csh/tcsh) or
-	BATCH=yes # (for sh/bash)
-
-    This should miss out ports which need user interaction. Unfortunately,
-ncftp doesn't know about this trick, and can often screw up and ask
-stupid questions in unattended batch mode. See (7).
-
-    To compile those ports left out by doing the above, using a
-different login shell (or unsetting the above BATCH variable), set the
-INTERACTIVE variable instead (you can use the same statements as above
-except replace ``BATCH'' with ``INTERACTIVE'') and re-run make. This
-should now compile only those ports which will definitely ask for user
-interaction.
-
-
-9) The ports collection is weak.  What can I do to help?
-
-    First read the bsd.port.mk file (which may be found in
-/usr/share/mk/) and the associated bsd.port.subdir.mk file. A lot of
-the weirdness can be explained properly in there (most of the current
-weirdness is due to the lack of assumptions about anything, which is
-necessary due to the generic nature of these files). Also check that
-you have an up-to-date copy, as the file can change from minute to
-minute.  A reasonably up-to-date copy can be found in:
-
-  ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/mk/bsd.port*
-
-    If you find that you still need to go in there and alter things,
-by all means do so, and then send the diffs to ports@FreeBSD.org if
-you'd like them to be a part of the default distribution.  Please also
-remember that any changes must respect backwards-compatability with
-any and all older Makefiles, unless you want a real nightmare of
-/usr/ports munging ahead of you!  Large scale changes will generally
-not be warmly welcomed unless all the existing makefiles work without
-alteration. Sorry!
-
-
-10) This FAQ is weak.  What can I do?
-
-    Send changes to ports@FreeBSD.org.  Changes are most welcome!
-This FAQ is also very green and should be considered no more than
-a `good start' for now.  Authors?  You can come out of hiding any
-time now! :-)
-
-
-11) How do I get more information on all the ports?
-
-    One good method is to cd to the top of the ports tree (say /usr/ports)
-and type something like:
-
-	make describe | sed -e '/===/D' -e 's;/usr/ports/;;' | expand -40
-
-The ``make describe'' will try to extract the one-line description from
-each port, and the ``sed'' will delete the extraneous output.  ``expand''
-just makes it a little more readable (sort of - you may want to season
-the output of this more to taste).
-
-
-12) I've heard of a new checksum system. What is this for?
-
-    For various reasons, when using FTP over the Internet to obtain the
-source code, you may not always end up with the same copy of the code
-that the origional porter worked from, and this can lead to problems.
-So a simple checksumming system has been employed to try and highlight
-problems in this area.
-
-    To check the entire system, go to the top of the ports tree
-(defaults to /usr/ports) and type
-
-	make checksum
-
-This will give a report on the validity of the files you have FTP'd. If some
-are missing, the system will attempt to retrieve them before running the
-checksum routine. The same technique can be applied to a single port.
-
-    The system will complain if there is no pre-computed checksum available
-for that port. Not all ports currently have checksums, but this should be
-cured soon.
-
-    Some older versions of the system don't recognise the ``checksum''
-target. In that case, try the command
-
-	make check-md5
-
-(``check-md5'' was the pre-cursor to the ``checksum'' target). If neither
-work, get the latest copies of bsd.port.mk and bsd.port.subdir.mk from
-
-   ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/mk/bsd.port*
-
-and install them in /usr/share/mk. This will get you the latest version
-of the ports system.
diff --git a/share/FAQ/Text/ppp.FAQ b/share/FAQ/Text/ppp.FAQ
deleted file mode 100644
index 46cc8bc..0000000
--- a/share/FAQ/Text/ppp.FAQ
+++ /dev/null
@@ -1,369 +0,0 @@
-         Info about setting up pppd daemon on FreeBSD-2.0
-
-$Id: ppp.FAQ,v 1.2 1995/01/03 15:54:05 gclarkii Exp $
-
-Before you start setting up PPP on your machine make
-sure that pppd is located in /usr/sbin and directory /etc/ppp
-exists.
-
-pppd can work in two modes:
-
-i) as a "client" , i.e. you want to connect your machine to outside
-world via PPP serial connection or modem line.
-
-ii) as a "server" , i.e. your machine is located on the network and
-used to connect other computers using PPP.
-
-In both cases you will need to set up an options file ( /etc/ppp/options
-or ~/.ppprc if you have more then one user on your machine that uses
-PPP ).
-
-You also will need some modem/serial software ( preferably kermit )
-so you can dial and establish connection with remote host.
-
-1) Working as a PPP client
-
-I used the following options to connect to CISCO terminal server PPP
-line.
-
-----/etc/ppp/options-------
-crtscts		# enable hardware flow control
-modem		# modem control line
-noipdefault	# remote PPP server must supply your IP address.
-		# if the remote host doesn't send your IP during IPCP
-		# negotiation , remove this option
-passive		# wait for LCP packets
-domain ppp.foo.com	# put your domain name here
-
-:<remote_ip>	# put the IP of remote PPP host here
-		# it will be used to route packets via PPP link
-		# if you didn't specified the noipdefault option
-		# change this line to <local_ip>:<remote_ip>
-
-defaultroute	# put this if you want that PPP server will be your
-		# default router
--------------------------
-
-To connect:
-i) Dial to the remote host using kermit ( or other modem program )
-enter your user name and password ( or whatever is needed to enable PPP
-ont the remote host )
-
-ii) Exit kermit. ( without hanging up the line )
-
-iii) enter: 
-/usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200
-( put the appropriate speed and device name )
-
-Now your computer is connected with PPP. If the connection fails for some
-reasons you can add the "debug" option to the /etc/ppp/options file
-and check messages on the console to track the problem
-
-Following script will make all 3 stages automatically:
------/etc/ppp/pppup--------
-#!/bin/sh 
-ps ax |grep pppd |grep -v grep
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill ${pid}
-fi
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-
-ifconfig ppp0 down
-ifconfig ppp0 delete
-
-kermit -y /etc/ppp/kermit.dial
-pppd /dev/tty01 19200
------------------------------
-
-/etc/ppp/kermit.dial is kermit script that dials and makes all
-necessary authorization on the remote host.
-( Example of such script is attached to the end of this document )
-
-Use the follwing script to disconnect the PPP line:
------/etc/ppp/pppdown--------
-#!/bin/sh
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ X${pid} != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill -TERM ${pid}
-fi
-
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-
-/sbin/ifconfig ppp0 down
-/sbin/ifconfig ppp0 delete
-kermit -y /etc/ppp/kermit.hup 
-/etc/ppp/ppptest
-------------------------------
-
-Check if PPP is still running:
-
------/etc/ppp/ppptest---------
-#!/bin/sh
-pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'`
-if [ X${pid} != "X" ] ; then
-        echo 'pppd running: PID=' ${pid-NONE}
-else
-        echo 'No pppd running.'
-fi
-set -x
-netstat -n -I ppp0
-ifconfig ppp0
------------------------------
-
-Hangs up modem line:
-
------/etc/ppp/kermit.hup-----
-set line /dev/tty01	; put your modem device here
-set speed 19200
-set file type binary
-set file names literal
-set win 8
-set rec pack 1024
-set send pack 1024
-set block 3
-set term bytesize 8
-set command bytesize 8
-set flow none
-
-pau 1
-out +++
-inp 5 OK
-out ATH0\13
-echo \13
-exit
-----------------------------
-
-2) Working as a PPP server
-
-------/etc/ppp/options------
-crtscts				# Hardware flow control
-netmask 255.255.255.0		# netmask ( not required )
-192.114.208.20:192.114.208.165  # ip's of local and remote hosts
-				# local ip must be different from one
-				# you assigned to the ethernet ( or other )
-				# interface on your machine.
-				# remote IP is ip address that will be 
-				# assigned to the remote machine
-domain ppp.foo.com		# your domain
-passive				# wait for LCP
-modem				# modem line
-----------------------------
-
-Following script will enable ppp server on your machine
-
------/etc/ppp/pppserv-------
-#!/bin/sh 
-ps ax |grep pppd |grep -v grep
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill ${pid}
-fi
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-
-# reset ppp interface
-ifconfig ppp0 down
-ifconfig ppp0 delete
-
-# enable autoanswer mode
-kermit -y /etc/ppp/kermit.ans
-
-# run ppp
-pppd /dev/tty01 19200
-----------------------------
-
-Use this script to stop ppp server:
-
------/etc/ppp/pppservdown---
-#!/bin/sh 
-ps ax |grep pppd |grep -v grep
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill ${pid}
-fi
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-ifconfig ppp0 down
-ifconfig ppp0 delete
-
-kermit -y /etc/ppp/kermit.noans
-----------------------------
-
-Following kermit script will enable/disable autoanswer mode 
-on your modem:
-
------/etc/ppp/kermit.ans----
-set line /dev/tty01
-set speed 19200
-set file type binary
-set file names literal
-set win 8
-set rec pack 1024
-set send pack 1024
-set block 3
-set term bytesize 8
-set command bytesize 8
-set flow none
-
-pau 1
-out +++
-inp 5 OK
-out ATH0\13
-inp 5 OK
-echo \13
-out ATS0=1\13	; change this to out ATS0=0\13 if you want to disable
-		; autoanswer mod
-inp 5 OK
-echo \13
-exit
------------------------------
-
-This script is used for dialing and authorizing on remote host.
-You will need to customize it for your needs.
-Put your login and password in this script , also you'll need
-to change input statement depending on responces from your modem
-and remote host.
-
------/etc/ppp/kermit.dial----
-
-;
-; put the com line attached to the modem here:
-;
-set line /dev/tty01
-;
-; put the modem speed here:
-;
-set speed 19200
-set file type binary		; full 8 bit file xfer
-set file names literal
-set win 8
-set rec pack 1024
-set send pack 1024
-set block 3
-set term bytesize 8
-set command bytesize 8
-set flow none
-set modem hayes
-set dial hangup off
-set carrier auto		; Then SET CARRIER if necessary,
-set dial display on		; Then SET DIAL if necessary,
-set input echo on
-set input timeout proceed
-set input case ignore
-def \%x 0			; login prompt counter
-goto slhup
-
-:slcmd				; put the modem in command mode
-echo Put the modem in command mode.
-clear				; Clear unread characters from input buffer
-pause 1
-output +++			; hayes escape sequence
-input 1 OK\13\10		; wait for OK
-if success goto slhup
-output \13
-pause 1
-output at\13
-input 1 OK\13\10
-if fail goto slcmd		; if modem doesn't answer OK, try again
-
-:slhup				; hang up the phone
-clear				; Clear unread characters from input buffer
-pause 1
-echo Hanging up the phone.
-output ath0\13			; hayes command for on hook
-input 2 OK\13\10
-if fail goto slcmd		; if no OK answer, put modem in command mode
-
-:sldial				; dial the number
-pause 1
-echo Dialing.
-output atdt9,550311\13\10		; put phone number here
-assign \%x 0			; zero the time counter
-
-:look
-clear				; Clear unread characters from input buffer
-increment \%x			; Count the seconds
-input 1 {CONNECT }
-if success goto sllogin
-reinput 1 {NO CARRIER\13\10}
-if success goto sldial
-reinput 1 {NO DIALTONE\13\10}
-if success goto slnodial
-reinput 1 {\255}
-if success goto slhup
-reinput 1 {\127}
-if success goto slhup
-if < \%x 60 goto look
-else goto slhup
-
-:sllogin			; login
-assign \%x 0			; zero the time counter
-pause 1
-echo Looking for login prompt.
-
-:slloop
-increment \%x			; Count the seconds
-clear				; Clear unread characters from input buffer
-output \13
-;
-; put your expected login prompt here:
-;
-input 1 {Username: }
-if success goto sluid
-reinput 1 {\255}
-if success goto slhup
-reinput 1 {\127}
-if success goto slhup
-if < \%x 10 goto slloop		; try 10 times to get a login prompt
-else goto slhup			; hang up and start again if 10 failures
-
-:sluid
-;
-; put your userid here:
-;
-output ppp-login\13
-input 1 {Password: }
-;
-; put your password here:
-;
-output ppp-password\13
-input 1 {Entering SLIP mode.}
-echo
-quit
-
-:slnodial
-echo \7No dialtone.  Check the telephone line!\7
-exit 1
-
-; local variables:
-; mode: csh
-; comment-start: "; "
-; comment-start-skip: "; "
-; end:
-------------------------
-
-###################################################################
-Gennady B. Sorokopud ( gena@NetVision.net.il ) 24/10/94 12:00
diff --git a/share/FAQ/Text/slip.FAQ b/share/FAQ/Text/slip.FAQ
deleted file mode 100644
index 4baf38c..0000000
--- a/share/FAQ/Text/slip.FAQ
+++ /dev/null
@@ -1,192 +0,0 @@
-***********************************************************************
-***                 How to Set Up SLIP on FreeBSD                   ***
-***********************************************************************
-
-$Id: slip.FAQ,v 1.2 1995/01/03 15:54:06 gclarkii Exp $
-
-Updated for 1.1.5(.1) support by Satoshi Asami, 8/6/94.
-
-The following is I (asami) set up my FreeBSD machine for SLIP on a
-static host network.  For dynamic hostname assignments (i.e., your
-address changes each time you dial up), you probably need to do
-something much fancier.
-
-This is just "what I did, and it worked for me".  I'm sharing this
-just for your reference, I'm no expert in SLIP nor networking so your
-mileage may vary.
-
-Note: for 1.1 systems (not 1.1.5), you need to use /dev/tty01 instead
-of /dev/cua01. substitute all the occurences of "cua" in this document
-with "tty".
-
-Note: the default 1.1.5(.1) system only comes with cua/ttyd pairs for
-the last two ports (2 and 3), so if your modem is at sio0/sio1
-(COM1/COM2), you need to make the devices.  Try "cd /dev; sh MAKEDEV
-cua01" to make the new special files for sio1 (ditto for sio0).  This
-will delete tty01, but you shouldn't need it anymore...or you can make
-a symbolic link /dev/tty01 -> ttyd1 if you don't want to hunt down all
-occurences of tty01 in your setup files.
-
-I actually have a symbolic link /dev/modem -> cua01 (and /dev/mouse ->
-ttyd0). I use only the modem/mouse names in my configuration files.
-This helped a lot when I switched from 1.1 to 1.1.5.1 (tty01 => cua01)
-and when I had to move my modem temporarily to sio2 to enable the
-RS-232C port on the serial card.  It can become quite cumbersome when
-you need to fix a bunch of files in /etc and .kermrc's all over the
-system!
-
-First, make sure you have
-
-pseudo-device   sl      2
-
-in your kernel's config file.  It is included in the GENERIC, GENERICAH
-and GENERICBT kernels, so this won't be a problem unless you deleted it.
-
-Things you have to do only once:
-
-(1) Add your home machine, the gateway and nameservers to your
-    /etc/hosts file.  Mine looks like this:
-
-127.0.0.1               localhost loghost
-136.152.64.181          silvia.HIP.Berkeley.EDU silvia.HIP silvia
-
-136.152.64.1            inr-3.Berkeley.EDU inr-3 slip-gateway
-128.32.136.9            ns1.Berkeley.edu ns1
-128.32.136.12           ns2.Berkeley.edu ns2
-
-    By the way, silvia is the name of the car that I had when I was
-    back in Japan (it's called 2?0SX here in U.S.).
-
-(2) Make sure you have "hosts" before "bind" in your /etc/host.conf.
-    Otherwise, funny things may happen.
-
-(3) Edit the /etc/netstart and add this to the end of the file:
-
-# set up slip
-gateway=slip-gateway
-ifconfig sl0 inet $hostname $gateway netmask 0xffffff00
-route add default $gateway
-
-    Note that because of the "slip-gateway" entry in /etc/hosts, there
-    is no local dependency in the netstart file.  Also, you might want
-    to un-comment the "route add $hostname localhost" line.
-
-(3') Make a file /etc/resolv.conf which contains:
-
-domain HIP.Berkeley.EDU
-nameserver 128.32.136.9
-nameserver 128.32.136.12
-
-    As you can see, these set up the nameserver hosts.  Of course, the
-    actual addresses depend on your environment.
-
-(4) Set the password for root and toor (and any other accounts that
-    doesn't have a password).  Use passwd, don't edit the passwd or
-    passwd.master files!
-
-(5) Edit /etc/myname and reboot the machine.
-
-How to set up the connection:
-
-(6) Dial up, type "slip" at the prompt, enter your machine name and
-    password.  The things you need to enter depends on your
-    environment.  I use kermit, with a script like this:
-
-# kermit setup
-set modem hayes
-set line /dev/cua01
-set speed 57600
-set parity none
-set flow rts/cts
-set terminal bytesize 8
-set file type binary
-# The next macro will dial up and login
-define slip dial 643-9600, input 10 =>, if failure stop, -
-output slip\x0d, input 10 Username:, if failure stop, -
-output silvia\x0d, input 10 Password:, if failure stop, -
-output ***\x0d, echo \x0aCONNECTED\x0a
-
-    (of course, you have to change the hostname and password to fit
-    yours).  Then you can just type "slip" from the kermit prompt to
-    get connected.
-
-    Note: leaving your password in plain text anywhere in the
-    filesystem is generally a BAD idea.  Do it at your own risk.  I'm
-    just too lazy.
-
-    Note: If you have an 1.1 machine, and kermit doesn't give you a
-    prompt, try "stty -f /dev/tty01 clocal".  I put this in
-    /etc/rc.local so that it works the first time I boot the machine.
-    This doesn't apply to 1.1.5(.1) systems, as cua0? are already
-    configured for dialouts.
-
-(7) Leave the kermit there (you can suspend it by "z") and as root,
-    type
-
-slattach -h -c -s 57600 /dev/cua01
-
-    if you are able to "ping" hosts on campus, you are connected!
-
-    If it doesn't work, you might want to try "-a" instead of "-c".
-
-(8) Happy slipping!
-
-How to shutdown the connection:
-
-(9) Type "ps gx" (as root) to find out the PID of slattach, and use
-    "kill -INT" to kill it.
-
-    Then go back to kermit ("fg" if you suspended it) and exit from it
-    ("q").
-
-    The slattach man page says you have to use "ifconfig sl0 down" to
-    mark the interface down, but this doesn't seem to make any
-    difference for me.  ("ifconfig sl0" reports the same thing.)
-
-    Some times, your modem might refuse to drop the carrier (mine
-    often does).  In that case, simply start kermit and quit it again.
-    It usually goes out on the second try.
-
-    When you want to connect again, go back to (6).  You may have to
-    watch out for clocal mode.  If "stty -f /dev/tty01" doesn't tell
-    you it's clocal, you need to re-set it before kermitting.  Again,
-    this is only for 1.1 machines.
-
-TROUBLESHOOTING:
-
-If it doesn't work, feel free to ask me.  The things that people
-tripped over so far:
-
-* Not using "-c" or "-a" in slattach (I have no idea why this can be
-  fatal, but adding this flag solved the problem for at least one
-  person)
-
-* Using "s10" instead of "sl0" (might be hard to see the difference on
-  some fonts :)
-
-Try "ifconfig sl0" to see your interface status.  I get:
-
-silvia# ifconfig sl0
-sl0: flags=10<POINTOPOINT>
-        inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00
-
-Also, "netstat -r" will give the routing table, in case you get the
-"no route to host" messages from ping.  Mine looks like:
-
-silvia# netstat -r
-Routing tables
-Destination      Gateway            Flags     Refs     Use  IfaceMTU    Rtt   
-Netmasks:
-(root node)
-(root node)
-
-Route Tree for Protocol Family inet:
-(root node) =>
-default          inr-3.Berkeley.EDU UG          8   224515  sl0 -      -     
-localhost.Berkel localhost.Berkeley UH          5    42127  lo0 -       0.438
-inr-3.Berkeley.E silvia.HIP.Berkele UH          1        0  sl0 -      -     
-silvia.HIP.Berke localhost.Berkeley UGH        34 47641234  lo0 -       0.438
-(root node)
-
-(this is after transferring a bunch of files, your numbers should be
-smaller).
diff --git a/share/FAQ/Text/slip_server.FAQ b/share/FAQ/Text/slip_server.FAQ
deleted file mode 100644
index 99b50a2..0000000
--- a/share/FAQ/Text/slip_server.FAQ
+++ /dev/null
@@ -1,433 +0,0 @@
-                            Slip Server
-                               FAQ
-                               For
-                             FreeBSD 
-
-$Id: slip_server.FAQ,v 1.2 1994/12/16 04:01:16 gclarkii Exp $
-
-Help for setting up SLIP Server services on a FreeBSD system
-------------------------------------------------------------
-
-Written by Guy Helmer (ghelmer@alpha.dsu.edu)
-Last Updated December 13, 1994
-
-This document provides suggestions for setting up SLIP Server services
-on a FreeBSD system, which typically means configuring your system to
-automatically startup connections upon login for remote SLIP clients.
-I've written this document based on my own experience; however, as
-your system and needs may be different, this document may not answer
-all of your questions, and I cannot be responsible if you damage your
-system or lose data due to attempting to follow the suggestions here.
-
-I have only setup SLIP Server services on a FreeBSD 1.1 system, so if
-you are running a different version (such as FreeBSD 2.0), your system
-may be different.  I've decided to write this document since I've
-recently been asked for the umpteenth time how to setup a FreeBSD
-machine as a SLIP server :-)
-
-
-1. Prerequisites
-----------------
-
-This document is very technical in nature, so background knowledge is
-required.  I must assume that you are familiar with the TCP/IP network
-protocol, and in particular, network and node addressing, network
-address masks, subnetting, routing, and routing protocols, such as
-RIP.  Configuring SLIP services on a dial-up server requires a
-knowledge of these concepts, and if you are not familiar with them,
-please read a copy of either Craig Hunt's "TCP/IP Network
-Administration" published by O'Reilly & Associates, Inc. (ISBN Number
-0-937175-82-X), or Douglas Comer's book on the TCP/IP protocol.
-
-I will assume that you have already setup your modem(s) and configured
-the appropriate system files to allow logins through your modems (see
-the manual pages for sio(4) for information on the serial port device
-driver and ttys(5), gettytab(5), getty(8), & init(8) for information
-relevant to configuring the system to accept logins on modems, and
-perhaps stty(1) for information on setting serial port parameters
-[such as "clocal" for directly-connected serial interfaces]).
-
-2. Quick Overview
------------------
-
-In its typical configuration, using FreeBSD as a SLIP server works as
-follows: a SLIP user dials up your FreeBSD SLIP Server system and logs
-in with a special SLIP login ID that uses "/usr/sbin/sliplogin" as the
-special user's shell.  The "sliplogin" program browses the file
-"/etc/slip.hosts" to find a matching line for the special user, and if
-it finds a match, connects the serial line to an available SLIP
-interface and then runs /etc/slip.login to configure the SLIP
-interface.
-
-2.1 An Example of a SLIP Server Login
--------------------------------------
-
-For example, if my SLIP user ID were "Shelmerg", that user's entry in
-/etc/master.passwd would look something like this (except it would be
-all on one line):
-
-Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:
-     /usr/users/Shelmerg:/usr/sbin/sliplogin
-
-and, when I log in with that user ID, "sliplogin" will search
-/etc/slip.hosts for a line that had a matching user ID; on my system,
-I may have a line in /etc/slip.hosts that reads:
-
-Shelmerg        dc-slip sl-helmer       0xfffffc00      autocomp
-
-sliplogin will find that matching line, hook the serial line I'm on
-into the next available SLIP interface, and then execute
-/etc/slip.login like this:
-
-/etc/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp
-
-If all goes well, /etc/slip.login will issue an "ifconfig" for the
-SLIP interface to which sliplogin attached itself (slip interface 0,
-in the above example, which was the first parameter in the list given
-to slip.login) to set the local IP address (dc-slip), remote IP
-address (sl-helmer), network mask for the SLIP interface (0xfffffc00),
-and any additional flags (autocomp).  If something goes wrong,
-sliplogin usually logs good informational messages via the daemon
-syslog facility, which usually goes into /var/log/messages (see the
-manual pages for syslogd(8) and syslog.conf(5), and perhaps check
-/etc/syslog.conf to see to which files syslogd is logging).
-
-OK, enough of the examples -- let's dive into setting up the system.
-
-3. Kernel Configuration
------------------------
-
-FreeBSD's default kernels usually come with two SLIP interfaces
-defined (sl0 and sl1); you can use "netstat -i" to see whether these
-interfaces are defined in your kernel.
-
-Sample output from "netstat -i":
-Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
-ed0   1500  <Link>0.0.c0.2c.5f.4a         291311     0   174209     0   133
-ed0   1500  138.247.224 ivory             291311     0   174209     0   133
-lo0   65535 <Link>                            79     0       79     0     0
-lo0   65535 loop        localhost             79     0       79     0     0
-sl0*  296   <Link>                             0     0        0     0     0
-sl1*  296   <Link>                             0     0        0     0     0
-
-The sl0 and sl1 interfaces shown in "netstat -i"'s output indicate
-that there are two SLIP interfaces built into the kernel.  (The
-asterisks after the "sl0" and "sl1" indicate that the interfaces are
-"down".)
-
-However, FreeBSD's default kernels do not come configured to forward
-packets (ie, your FreeBSD machine will not act as a router) due to
-Internet RFC requirements for Internet hosts (see RFC's 1009
-[Requirements for Internet Gateways], 1122 [Requirements for Internet
-Hosts -- Communication Layers], and perhaps 1127 [A Perspective on the
-Host Requirements RFCs]), so if you want your FreeBSD SLIP Server to
-act as a router, you'll have to add the line "options GATEWAY" to your
-machine's kernel configuration file and re-compile the kernel anyway.
-(Trivia: "Gateways" are the Internet's old name for what are now
-usually called "routers".)
-
-Please see the BSD System Manager's Manual chapter on "Building
-Berkeley Kernels with Config" [the source for which is in
-/usr/src/share/doc/smm] and the "FreeBSD Configuration Options" [in
-/sys/doc/options.doc] for more information on configuring and building
-kernels.  You may have to unpack the kernel source distribution if
-haven't installed the system sources already (srcdist/srcsys.?? in
-FreeBSD 1.1, srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire source
-distribution in FreeBSD 2.0-RELEASE) to be able to configure and build
-kernels.
-
-You'll notice that near the end of the default kernel configuration
-file (/sys/i386/conf/GENERICAH) is a line that reads:
-
-pseudo-device sl 2
-
-which is the line that defines the number of SLIP devices available in
-the kernel; the number at the end of the line is the maximum number of
-SLIP connections that may be operating simultaneously.
-
-See the "Building Berkeley Kernels with Config" and the manual page
-for config(8) to see how to configure and build kernels.
-
-4. Sliplogin Configuration
---------------------------
-
-As mentioned earlier, there are three files in the /etc directory that
-are part of the configuration for /usr/sbin/sliplogin (see
-sliplogin(8) for the actual manual page for sliplogin): slip.hosts,
-which lists the SLIP users & their associated IP addresses;
-slip.login, which usually just configures the SLIP interface; and
-slip.logout, which undoes slip.login's effects when the serial
-connection is terminated.
-
-4.1 slip.hosts Configuration & Local and Remote Address Selection
------------------------------------------------------------------
-
-/etc/slip.hosts contains lines which have at least four items listed:
-a SLIP user's login ID, the local address (local to the SLIP server)
-of the SLIP link, the remote address of the SLIP link, and the network
-mask.  The local and remote addresses may be host names (given in
-/etc/hosts or by the domain name service, depending on your
-specifications in /etc/host.conf), and I believe the network mask may
-be a name that can be resolved by a lookup into /etc/networks.  On one
-of my systems, /etc/slip.hosts looks like this:
-
------ begin /etc/slip.hosts -----
-#
-# login local-addr      remote-addr     mask            opt1    opt2 
-#                                               (normal,compress,noicmp)
-#
-Shelmerg  dc-slip       sl-helmerg      0xfffffc00      autocomp
------ end /etc/slip.hosts ------
-
-At the end of the line is one or more of the options:
-
-  "normal" - no header compression
-  "compress" - compress headers
-  "autocomp" - compress headers if the remote end allows it
-  "noicmp" - disable ICMP packets (so any "ping" packets won't use up
-	any of your bandwidth)
-
-Your choice of local and remote addresses for your SLIP links depends
-on whether you are going to dedicate a TCP/IP subnet or if you are
-going to use "proxy ARP" on your SLIP server (it's not "true" proxy
-ARP, but that is the terminology that I will use in this document to
-describe it).  If you're not sure which method to select or how to
-assign IP addresses, please refer to the TCP/IP books referenced in
-the "Prerequisites" section and/or consult your IP network manager.
-
-If you are going to use a separate subnet for your SLIP clients, you
-will need to allocate the subnet number out of your assigned IP
-network number and assign each of your SLIP client's IP numbers out of
-that subnet; then you will probably either need to configure a static
-route to the SLIP subnet via your SLIP server on your nearest IP
-router, or install "gated" on your FreeBSD SLIP server and configure
-it to talk the appropriate routing protocols to your other routers to
-inform them about your SLIP server's route to the SLIP subnet.
-
-Otherwise, if you will use the "proxy ARP" method, you will need to
-assign your SLIP client's IP addresses out of your SLIP server's
-Ethernet subnet, and you'll also need to adjust your /etc/slip.login
-and /etc/slip.logout scripts to use arp(8) to manage the proxy-ARP
-entries in the SLIP server's ARP table.
-
-4.2 slip.login Configuration
-----------------------------
-
-The typical /etc/slip.login file looks like this:
-
------ begin /etc/slip.login -----
-#!/bin/sh -
-#
-#	@(#)slip.login  5.1 (Berkeley) 7/1/90
-
-#
-# generic login file for a slip line.  sliplogin invokes this with
-# the parameters:
-#      1        2         3        4          5         6     7-n
-#   slipunit ttyspeed loginname local-addr remote-addr mask opt-args
-#
-/sbin/ifconfig sl$1 inet $4 $5 netmask $6
------ end /etc/slip.login -----
-
-This slip.login file merely ifconfig's the appropriate SLIP interface
-with the local and remote addresses and network mask of the SLIP
-interface.
-
-If you have decided to use the "proxy ARP" method (instead of using a
-separate subnet for your SLIP clients), your /etc/slip.login file will
-need to look something like this:
-
------ begin /etc/slip.login for "proxy ARP" -----
-#!/bin/sh -
-#
-#	@(#)slip.login  5.1 (Berkeley) 7/1/90
-
-#
-# generic login file for a slip line.  sliplogin invokes this with
-# the parameters:
-#      1        2         3        4          5         6     7-n
-#   slipunit ttyspeed loginname local-addr remote-addr mask opt-args
-#
-/sbin/ifconfig sl$1 inet $4 $5 netmask $6 
-# Answer ARP requests for the SLIP client with our Ethernet addr
-/usr/sbin/arp -s $5 00:11:22:33:44:55 pub
------ end /etc/slip.login for "proxy ARP" -----
-
-The additional line in this slip.login, "arp -s...", creates an ARP
-entry in the SLIP server's ARP table which asks the system to give out
-the SLIP server's Ethernet MAC address whenever a another system or
-router on the Ethernet asks to speak to the SLIP client's IP address.
-
-When using the example above, be sure to replace the Ethernet MAC
-address (00:11:22:33:44:55) with the MAC address of your system's
-Ethernet card, or your "proxy ARP" will definitely not work!  You can
-discover your SLIP server's Ethernet MAC address by looking at the
-results of running "netstat -i"; the second line of the output should
-look something like:
-
-ed0   1500  <Link>0.2.c1.28.5f.4a         191923     0   129457     0   116
-                  ^^^^^^^^^^^^^^^
-
-which indicates that this particular system's Ethernet MAC address is
-"00:02:c1:28:5f:4a" -- the periods in the Ethernet MAC address given
-by "netstat -i" must be changed to colons and leading zeros should be
-added to each single-digit hexadecimal number to convert the address
-into the form that arp(8) desires; see the manual page on arp(8) for
-complete information on usage.
-
-Note that when you create /etc/slip.login and /etc/slip.logout, the
-"execute" bit ("chmod 755 /etc/slip.login /etc/slip.logout") must be
-set, or sliplogin will be unable to execute it.
-
-4.3 slip.logout Configuration
------------------------------
-
-"/etc/slip.logout" isn't strictly needed, but if you decide to create
-it, this is an example of a basic slip.logout script:
-
------ begin /etc/slip.logout -----
-#!/bin/sh -
-#
-#	slip.logout
-
-#
-# logout file for a slip line.  sliplogin invokes this with
-# the parameters:
-#      1        2         3        4          5         6     7-n
-#   slipunit ttyspeed loginname local-addr remote-addr mask opt-args
-#
-/sbin/ifconfig sl$1 down
------ end /etc/slip.logout -----
-
-If you are using "proxy ARP", you'll want to have /etc/slip.logout
-remove the ARP entry for the SLIP client:
-
------ begin /etc/slip.logout for "proxy ARP" -----
-#!/bin/sh -
-#
-#       @(#)slip.logout
-
-#
-# logout file for a slip line.  sliplogin invokes this with
-# the parameters:
-#      1        2         3        4          5         6     7-n
-#   slipunit ttyspeed loginname local-addr remote-addr mask opt-args
-#
-/sbin/ifconfig sl$1 down
-# Quit answering ARP requests for the SLIP client
-/usr/sbin/arp -d $5
------ end /etc/slip.logout for "proxy ARP" -----
-
-The "arp -d $5" removes the ARP entry that the "proxy ARP" slip.login
-added when the SLIP client logged in.
-
-It bears repeating: make sure /etc/slip.logout has the execute bit set
-for after you create it (e.g., "chmod 755 /etc/slip.logout").
-
-5. Routing Considerations
--------------------------
-
-If you are not using the "proxy ARP" method for routing packets
-between your SLIP clients and the rest of your network (and perhaps
-the Internet), you will probably either have to add static routes to
-your closest default router(s) to route your SLIP client subnet via
-your SLIP server, or you will probably need to install and configure
-gated on your FreeBSD SLIP server so that it will tell your routers
-via appropriate routing protocols about your SLIP subnet.
-
-5.1 Static Routes
------------------
-
-Adding static routes to your nearest default routers can be
-troublesome (or impossible, if you don't have authority to do so...).
-If you have a multiple-router network in your organization, some
-routers, such as Cisco and Proteon, may not only need to be configured
-with the static route to the SLIP subnet, but also need to be told
-which static routes to tell other routers about, so some expertise and
-troubleshooting/tweaking may be necessary to get static-route-based
-routing to work...
-
-5.2 Running gated
------------------
-
-An alternative to the headaches of static routes is to install gated
-on your FreeBSD SLIP server and configure it to use the appropriate
-routing protocols (RIP/OSPF/BGP/EGP) to tell other routers about your
-SLIP subnet.  gated is available from ftp.gated.cornell.edu in
-/pub/gated; I believe the current version as of this writing is
-"gated-R3_5Alpha_8.tar.Z", which should include support for FreeBSD
-"out-of-the-box".  Compile and install it, and then write a
-/etc/gated.conf file to configure your gated; here's a sample, similar
-to what I use on my FreeBSD SLIP server:
-
------ begin sample /etc/gated.conf for gated version 3.5Alpha5 -----
-#
-# gated configuration file for dc.dsu.edu; for gated version 3.5alpha5
-# Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface
-#
-#
-# tracing options
-#
-traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ;
-
-rip yes {
- interface sl noripout noripin ;
- interface ed ripin ripout version 1 ;
- traceoptions route ;
-} ;
-
-#
-# Turn on a bunch of tracing info for the interface to the kernel:
-kernel {
- traceoptions remnants request routes info interface ;
-} ;
-
-#
-# Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP
-#
-
-export proto rip interface ed {
-        proto direct {
-                xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections
-        } ;
-} ;
-
-#
-# Accept routes from RIP via ed Ethernet interfaces
-
-import proto rip interface ed {
-        all ;
-} ;
-
------ end sample /etc/gated.conf -----
-
-The above sample gated.conf file broadcasts routing information
-regarding the SLIP subnet "xxx.xxx.yy" via RIP onto the Ethernet; if
-you are using a different Ethernet driver than the "ed" driver, you'll
-need to change the references to the "ed" interface appropriately.
-This sample file also sets up tracing to /var/tmp/gated.output for
-debugging gated; you can certainly turn off the tracing options if
-gated works OK for you.  I've changed my SLIP subnet's address to
-"xxx.xxx.yy" throughout the above file; you'll need to change the
-"xxx.xxx.yy"'s into the network address of your own SLIP subnet (be
-sure to change the net mask in the "proto direct" clause as well).
-Complete gated configuration information may be read through the Web
-at "http://www.gated.cornell.edu/".
-
-When you get gated built and installed, and create a configuration
-file for it, you'll need to run gated in place of routed on your
-FreeBSD system; change the routed/gated startup parameters in
-/etc/netstart as appropriate for your system.  Please see the manual
-page for gated for information on gated's command-line parameters.
-
-6. Acknowledgements
--------------------
-
-Thanks to these people for comments and advice regarding this FAQ:
-
-	Wilko Bulte <wilko@yedi.iaf.nl>
-	Piero Serini <Piero@Strider.Inet.IT>
-
-<<< END OF SLIP SERVER FAQ >>>
-
-
diff --git a/share/FAQ/Text/submitters.FAQ b/share/FAQ/Text/submitters.FAQ
deleted file mode 100644
index 69a79f3..0000000
--- a/share/FAQ/Text/submitters.FAQ
+++ /dev/null
@@ -1,167 +0,0 @@
--- A submitter's guide to FreeBSD --
-
-This guide is intended for those who are moderately familar with FreeBSD
-and are now to the point where they have some locally developed
-customizations or fixes to the system which they'd like to incorporate
-back into the mainstream sources, thus saving the work of having to
-re-integrate the changes for each subsequent FreeBSD release.  Submitting
-something to the FreeBSD project is also an excellent way of getting your
-code seriously *tested*!  Many people have developed an original concept
-far beyond what they might have envisioned at the start just due to the
-flood of feedback and ideas generated by the many thousands of users of
-FreeBSD.  Contributions are also what FreeBSD lives and grows from,
-and so your contributions are very important to the continued survival
-of this communal effort of ours - we're very glad to see you reading this
-documentation! :-)
-
-Submissions to FreeBSD can generally be classified into four catagories:
-
-1. Ideas, general suggestions, bug reports.
-2. Addition, deletion, renaming or patching of existing sources.
-3. Significant contribution of a large body of independant work.
-4. Porting of freely available software.
-
-A submission in *any* of these catagories is highly welcomed as they
-are each, in their own way, quite significant to the project.  
-
-
-1. An idea, suggestion or fix can be communicated in one of the following ways:
-
-	o An idea or suggestion of general technical interest should be
-	  mailed to <hackers@freebsd.org>.  Likewise, people with an interest
-	  in such things (and a tolerance for a HIGH volume of mail!) may
-	  subscribe by sendimg mail to <majordomo@freebsd.org>.  See also the
-	  file /usr/share/FAQ/mailing-list.FAQ.
-
-	o An actual bug report should be filed by using the send-pr(1)
-	  command (``man send-pr'' for information).  This will prompt
-	  you for various fields to fill in.  Simply go to the fields
-	  surrounded by <>'s and fill in your own information in place of
-	  what's suggested there.  You should receive confirmation of your
-	  bug report and a tracking number (which you should also reference in
-	  any subsequent correspondence).
-
-          If you do not receive confirmation in a timely fashion (3 days to
-          a week, depending on your email connection) or are, for some
-          reason, unable to use the send-pr command, then you may also
-	  file a bug report (or follow-up to one) by sending mail to:
-
-	  		<bugs@freebsd.org>
-
-
-2. An addition or change to the existing source code is a somewhat trickier
-   affair and depends a lot on how far out of date you are with the current
-   state of the core FreeBSD development.  There is a special on-going release
-   of FreeBSD known as "FreeBSD-current" and made available in a variety of
-   ways (see /usr/share/FAQ/current-policy.FAQ and /usr/share/FAQ/ctm.FAQ) for
-   the convenience of developers who wish to actively work on the system.
-
-   Working from older sources unfortunately means that your changes may
-   sometimes be too obsolete to use, or too divergent to allow for easy
-   re-integration.  This can be minimized somewhat by subscribing to the
-   <announce@freebsd.org> mailing list (among others) where periodic
-   announcements concerning the current state of the system are made.
-   If you see a change being proposed for which you have a better solution,
-   then please, by all means come forward with your contribution and we
-   will do our very best to evaluate it fairly and perhaps integrate it if
-   it is indeed a better (or easier :) solution.
-
-   Assuming that you can manage to secure fairly up-to-date sources to base
-   your changes on, the next step is to produce a set of diffs to send to the
-   FreeBSD maintainers for evaluation and possible adoption.  This is done
-   with the diff(1) command, with the FreeBSD maintainers preferring to receive
-   diffs in `context diff' form.  See the man page for diff for more details
-   on producing both context and recursive context diffs
-   (diff -c <oldfile> <newfile> or diff -c -r <olddir> <newdir>).
-
-   Once you have a set of diffs that are capable of taking a copy of the
-   original code and bringing it to a state identical to the "new" sources
-   (you may test this with the patch(1) command - see patch man page), you
-   should bundle them up in an email message and send it, along with a brief
-   description of what the diffs are for, to <hackers@freebsd.org>.  Someone
-   will very likely get back in touch with you in 24 hours or less, assuming
-   of course that your diffs are interesting! :-)
-
-   If your changes don't express themselves well as diffs alone (e.g. you've
-   perhaps added, deleted or renamed files as well) then you may be better off
-   bundling any new files, diffs and instructions for deleting/renaming any
-   others into a tar file and running the `uuencode' program on it before
-   sending the output of that to <hackers@freebsd.org>.  See the man pages
-   on tar and uuencode for more info on bundling files through the mail this
-   way.
-
-   If your change is of a potentially sensitive nature, e.g. you're unsure
-   of copyright issues governing its further distribution, or you're simply
-   not ready to release it without a tighter review first, then you should
-   send it to <core@freebsd.org> rather than <hackers@freebsd.org>.  The core
-   mailing list reaches a much smaller group of people who do much of the
-   day-to-day work on FreeBSD.  Note that this group is also VERY BUSY and so
-   you should really only mail to them in cases where mailing to hackers
-   truly is impractical.
-
-
-3. In the case of a significant contribution of a large body work, or the
-   addition of an important new feature to FreeBSD, it becomes almost always
-   necessary to either send changes as uuencoded tar files (see above)
-   or upload them to our ftp site:
-		ftp://freefall.cdrom.com/pub/FreeBSD/incoming
-
-   Users may log in anonymously and upload their work or download the
-   work-in-progress files left by others.
-
-   When working with large amounts of code, the touchy subject of copyrights
-   also invariably comes up.  The view of the FreeBSD project towards
-   acceptable copyrights (for code included in FreeBSD) are:
-
-	3a. Contributions under the BSD copyright (see the file
-	    /usr/share/examples/etc/bsd-style-copyright for a template)
-	    is greatly preferred due to its "no strings attached"
-	    nature and general attractiveness to commercial enterprises
-	    who might then be inclined to invest something of their own
-	    into FreeBSD.
-
-	3b. Contributions under the GNU Public License, or "GPL".  This is
-	    not quite as popular a solution for us, due to (all religious
-	    issues aside) the amount of extra effort demanded of anyone
-	    using the code for commercial purposes.  However, given the
-	    sheer quantity of GPL'd code we currently require (compiler,
-	    assembler, text formatter, etc), it would be silly to pretend
-	    that we couldn't deal with the GPL at all and so we have become
-	    more willing to accept code with either the BSD or the GPL
-	    copyright.  Code under the GPL also goes into a different part
-	    of the tree, that being /sys/gnu or /usr/src/gnu.
-
-	3c. Contributions coming under any other type of copyright must be
-	    carefully reviewed before their inclusion into FreeBSD will even
-	    be considered.  Contributions for which particularly restrictive
-	    commercial copyrights apply are generally rejected, though the
-	    authors are always free to make the changes available through
-	    their own channels.
-
-
-4. The porting of freely available software, while perhaps not as gratifying
-   as developing your own package from scratch, is still a vital part of
-   FreeBSD's growth and of great usefulness to those who wouldn't otherwise
-   know where to turn for it.  All ported software is organized into a
-   hierarchy know as ``the ports collection''.  This collection enables
-   a new user to get a complete overview of what's available in a short time,
-   and with a logical (we hope) framework.  The ports collection also saves
-   considerable space by not actually containing the the majority of the
-   sources being ported.  This can be confusing to the new user and the file
-   /usr/share/FAQ/ports.FAQ goes some way towards explaing how it all works.
-
-   If you have the ports collection on your machine, the file
-   /usr/ports/GUIDELINES also helps to explain the process of creating
-   and contributing a port of your own.  For more information on the ports
-   collection (that wasn't available in the FAQ), you may also send mail to
-   <ports@freebsd.org>.
-
-
-Whichever way you decide to contribute, we hope you'll find it an enjoyable
-process and also realize how valuable your contributions are to the project!
-FreeBSD is one of those great projects where the more we all put in, the
-more we all get back out of it again, and with enough steady contributions
-it begins to aquire a momentum of its own.  It is through such momentum
-that mountains are moved! :-)
-
-					Jordan
diff --git a/share/FAQ/Text/sup.FAQ b/share/FAQ/Text/sup.FAQ
deleted file mode 100644
index 681d123..0000000
--- a/share/FAQ/Text/sup.FAQ
+++ /dev/null
@@ -1,91 +0,0 @@
-                                 FreeBSD
-                                 Sup FAQ
-
-$Id: sup.FAQ,v 1.1 1995/03/21 20:19:46 jkh Exp $
-
-	SUP is a network based software update tool developed at CMU.  The
-purpose of this document is get the beginner up and running with sup.
-
-	First off you will need to pick up the sup binaries.  The easiest
-way of doing this is to grab the sup.tgz package from:
-
-	ftp://ftp.FreeBSD.ORG:/pub/FreeBSD/packages/sup.tgz
-
-Install the sup package using pkg_add and add the following line to
-your /etc/services file:
-
-        sup                 871/tcp        #sup
-
-SUP gets the information it needs to run from a configuration file 
-called a supfile.  This file tells sup what collections it will be updating
-and/or installing and where they go.  The supfile in this directory will
-sup both the source and ports collection - look for the blank line seperating
-the two collections; if you don't want ports, you can simply delete all the
-ports entries.  If you're inside the United States, you may also uncomment
-the `secure' collection line to grab the DES code.  If you're outside the
-U.S., you should NOT sup this code from FreeBSD.ORG as this will
-violate U.S. export restrictions.  Simply sup everything *but* the secure
-collection and then go look on "braae.ru.ac.za", where it's available for
-anonymous ftp for those outside the U.S.
-
-Any other distributions you do not wish to receive can be commented out
-with a # at the begining of the distribution line.
-
-Once this is setup, you're ready to go.  To start sup type:
-
-	sup supfile
-
-If you wish to see what sup is doing "verbosely", give it the -v option,
-like so:
-
-	sup -v supfile
-
-Thats all there is to it!  Remember that if you're running current,
-which is what you will have if you sup, please join the freebsd-current
-mailing list.  You should also be sure to read:
-
-	ftp://ftp.FreeBSD.ORG:/pub/FreeBSD/FAQ/current-policy.FAQ
-
-For important information on just what we can and cannot do for you as
-a -current user.  
-
-Gary Clark II / Jordan Hubbard
-FreeBSD maintainance persons.
-
-----
-
-Description of FreeBSD SUP distributions:
-
-base:		/usr/src/...		misc files at the top of /usr/src
-bin:		/usr/src/bin		system binaries
-secure:		/usr/src/secure		DES Sources.  U.S./Canada only!
-etc:		/usr/src/etc		system files
-games:		/usr/src/games		games
-gnu:		/usr/src/gnu		sources under the GNU Public License
-include:	/usr/src/include	include files
-sys:		/usr/src/sys		kernel sources
-lib:		/usr/src/lib		libraries
-libexec:	/usr/src/libexec	more system binaries
-share:		/usr/src/share		various shared resources
-sbin:		/usr/src/sbin		even more system binaries
-usrbin:		/usr/src/usr.bin	user binaries
-usrsbin:	/usr/src/usr.sbin	that's it for the system binaries
-
-Ports:
-
-ports-base:	/usr/ports/...		misc files at the top of /usr/ports
-ports-editors:  /usr/ports/editors	text editors
-ports-game:	/usr/ports/games	games
-ports-lang:	/usr/ports/lang		programming languages
-ports-mail:	/usr/ports/mail		mail software
-ports-math:	/usr/ports/math		math software
-ports-net:	/usr/ports/net		networking software
-ports-news:	/usr/ports/news		USENET news software
-ports-print:	/usr/ports/print	printing software
-ports-russian:	/usr/ports/russian	russian	software
-ports-shells:	/usr/ports/shells	various UN*X shells
-ports-utils:	/usr/ports/utils	miscellaneous utilities
-ports-x11:	/usr/ports/x11		X11 software
-
-
-
diff --git a/share/FAQ/Text/systems.FAQ b/share/FAQ/Text/systems.FAQ
deleted file mode 100644
index 34c8e71..0000000
--- a/share/FAQ/Text/systems.FAQ
+++ /dev/null
@@ -1,59 +0,0 @@
-
-                               Systems FAQ
-                             for FreeBSD 2.0
-
-This FAQ lists systems (and componets) known to work with FreeBSD 2.0.  None
-of these lists should be seen as a recomandation for a manufacture.
-
-$Id: systems.FAQ,v 1.2 1995/01/03 15:54:08 gclarkii Exp $
-
-
-i386:
-
-
-Motherboard: Magitronics 386DX-40
-CPU: i386DX-40
-Busses: ISA and VLB (VLB not tested)
-Ram: 20 Megs
-Video: Generic 1MB Tseng 4000 (ISA)
-Disks:
-	2 - Segate ST1126 (SCSI)
-	1 - Seagate ST1480 (SCSI)
-	1 - Toshiba MK-234FC-C (IDE)
-Controllers:
-	Generic IDE
-	Adaptec AH-1542CF
-
-Motherboard: Magitronics 386SX-40
-CPU: i386SX-40
-Busses: ISA
-Ram: 4 Megs
-Video: Monochrome
-Disks:
-	1-Seagate ST1126 (SCSI)
-Controllers:
-	Future Domain 850
-Notes: Slow but useable
-
-i486:
-
-Motherboard:  Gateway 2000 Handbook 486 HB486DX2-40
-CPU: i486SL DX2/40
-BUS(S): PCMCIA, one type II
-Video Card: Monochrome VGA.
-Are you running X on this?: no, havn't really tried.
-Types of Disks (manufacture and bus): 130Mb builtin.  <Areal A130 U>
-If you wish to be credited: Poul-Henning Kamp phk@freefall.cdrom.com
-
-NOTES:
-This is a 3 pound portable.  Runs perfect.  Suspend works great.  Has one
-serial and one parallel/floppy port, which can drive either a floppy or
-a parallel port, but not at the same time.  Builtin "EZ" mouse-thinge.
-Highly recommended for people on the road.
-
-
-Credits:
-	FreeBSD Core Team
-	Gary Clark II
-	Poul-Henning Kamp
-
diff --git a/share/FAQ/UUCP_Internals.FAQ b/share/FAQ/UUCP_Internals.FAQ
deleted file mode 100644
index b927122..0000000
--- a/share/FAQ/UUCP_Internals.FAQ
+++ /dev/null
@@ -1,1603 +0,0 @@
-Path: bloom-beacon.mit.edu!cambridge-news.cygnus.com!comton.airs.com!ian
-From: ian@airs.com (Ian Lance Taylor)
-Newsgroups: comp.mail.uucp,comp.answers,news.answers
-Subject: UUCP Internals Frequently Asked Questions
-Keywords: UUCP, protocol, FAQ
-Message-ID: <uucp-internals_787915801@airs.com>
-Date: 20 Dec 94 09:30:02 GMT
-Expires: 31 Jan 95 09:30:01 GMT
-Reply-To: ian@airs.com (Ian Lance Taylor)
-Followup-To: comp.mail.uucp
-Organization: Infinity Development, Waltham, MA
-Lines: 1587
-Approved: news-answers-request@MIT.Edu
-Supersedes: <uucp-internals_785496601@airs.com>
-Xref: bloom-beacon.mit.edu comp.mail.uucp:5270 comp.answers:9043 news.answers:31575
-
-Archive-name: uucp-internals
-Version: $Revision: 1.26 $
-Last-modified: $Date: 1994/10/26 02:39:07 $
-
- This article was written by Ian Lance Taylor <ian@airs.com> and I may
- even update it periodically.  Please send me mail about suggestions
- or inaccuracies.
-
- This article describes how the various UUCP protocols work, and
- discusses some other internal UUCP issues.  It does not describe how
- to configure UUCP, nor how to solve UUCP connection problems, nor how
- to deal with UUCP mail.  I do not know of any FAQ postings on these
- topics.  There are some documents on the net describing UUCP
- configuration, but I can not keep an up to date list here; try using
- archie.
-
- If you haven't read the news.announce.newusers articles, read them.
-
- This article is in digest format.  Some newsreaders will be able to
- break it apart into separate articles.  Please don't ask me how to do
- this, though.
-
- This article answers the following questions.  If one of these
- questions is posted to comp.mail.uucp, please send mail to the poster
- referring her or him to this FAQ.  There is no reason to post a
- followup, as most of us know the answer already.
-
-Sources
-What does "alarm" mean in debugging output?
-What are UUCP grades?
-What is the format of a UUCP lock file?
-What is the format of a UUCP X.* file?
-What is the UUCP protocol?
-What is the 'g' protocol?
-What is the 'f' protocol?
-What is the 't' protocol?
-What is the 'e' protocol?
-What is the 'G' protocol?
-What is the 'i' protocol?
-What is the 'j' protocol?
-What is the 'x' protocol?
-What is the 'y' protocol?
-What is the 'd' protocol?
-What is the 'h' protocol?
-What is the 'v' protocol?
-Thanks
-
-----------------------------------------------------------------------
-
-From: Sources
-Subject: Sources
-
-"Unix-to-Unix Copy Program," said PDP-1.  "You will never find a more
-wretched hive of bugs and flamers.  We must be cautious."
-                                                --DECWars
-
-I took a lot of the information from Jamie E. Hanrahan's paper in the
-Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim
-O'Reilly and Grace Todino (with contributions by several other
-people).  The latter includes most of the former, and is published by
-        O'Reilly & Associates, Inc.
-        103 Morris Street, Suite A
-        Sebastopol, CA 95472
-It is currently in its tenth edition.  The ISBN number is
-0-937175-93-5.
-
-Some information is originally due to a Usenet article by Chuck
-Wegrzyn.  The information on execution files comes partially from
-Peter Honeyman.  The information on the 'g' protocol comes partially
-from a paper by G.L. Chesson of Bell Laboratories, partially from
-Jamie E. Hanrahan's paper, and partially from source code by John
-Gilmore.  The information on the 'f' protocol comes from the source
-code by Piet Berteema.  The information on the 't' protocol comes from
-the source code by Rick Adams.  The information on the 'e' protocol
-comes from a Usenet article by Matthias Urlichs.  The information on
-the 'd' protocol comes from Jonathan Clark, who also supplied
-information about QFT.  The FSUUCP information comes straight from
-Christopher J. Ambler; it applies to version 1.4 and up.
-
-Although there are few books about UUCP, there are many about networks
-and protocols in general.  I recommend two non-technical books which
-describe the sorts of things that are available on the network: ``The
-Whole Internet,'' by Ed Krol, and ``Zen and the Art of the Internet,''
-by Brendan P. Kehoe.  Good technical discussions of networking issues
-can be found in ``Internetworking with TCP/IP,'' by Douglas E. Comer
-and David L. Stevens and in ``Design and Validation of Computer
-Protocols'' by Gerard J. Holzmann.
-
-------------------------------
-
-From: alarm
-Subject: What does "alarm" mean in debugging output?
-
-The debugging output of many versions of UUCP (but not Taylor UUCP)
-will include messages like
-    alarm 1
-or
-    pkcget: alarm 1
-
-This message means that the UUCP package has timed out while waiting
-for some sort of response from the remote system.  This normally
-indicates some sort of connection problem.  For example, the modems
-might have lost their connection, or perhaps one of the modems will
-not transmit the XON and XOFF characters, or perhaps one side or the
-other is dropping characters.  It can also mean that the packages
-disagree about some aspect of the UUCP protocol, although this is less
-common.
-
-Using the information in the rest of this posting, you should be able
-to figure out what type of data your UUCP was expecting to receive.
-This may give some indication as to exactly what the problem is.  It
-is difficult to be more specific, since there are many possiblities.
-
-------------------------------
-
-From: UUCP-grades
-Subject: What are UUCP grades?
-
-Modern UUCP packages support grades for each command.  The grades
-generally range from 'A' (the highest) to 'Z' followed by 'a' to 'z'.
-Some UUCP packages also support '0' to '9' before 'A'.  Some UUCP
-packages may permit any ASCII character as a grade.
-
-On Unix, these grades are encoded in the name of the command file.  A
-command file name generally has the form
-    C.nnnngssss
-where nnnn is the remote system name for which the command is queued,
-g is a single character grade, and ssss is a four character sequence
-number.  For example, a command file created for the system ``airs''
-at grade 'Z' might be named
-    C.airsZ2551
-
-The remote system name will be truncated to seven characters, to
-ensure that the command file name will fit in the 14 character file
-name limit of the traditional Unix file system.  UUCP packages which
-have no other means of distinguishing which command files are intended
-for which systems thus require all systems they connect to to have
-names that are unique in the first seven characters.  Some UUCP
-packages use a variant of this format which truncates the system name
-to six characters.  HDB and Taylor UUCP use a different spool
-directory format, which allows up to fourteen characters to be used
-for each system name.
-
-The sequence number in the command file name may be a decimal integer,
-or it may be a hexadecimal integer, or it may contain any alphanumeric
-character.  Different UUCP packages are different.
-
-FSUUCP (a DOS based UUCP and news package) uses up to 8 characters for
-file names in the spool (this is a DOS file name limitation; actually,
-with the extension, 11 characters are available, but FSUUCP reserves
-that for future use).  FSUUCP defaults mail to grade D, and news to
-grade N, except that when the grade of incoming mail can be
-determined, that grade is preserved if the mail is forwarded to
-another system.  Mail and news are currently the only 2 types of
-transfers supported.  The default grades may be changed by editing
-the MAIL.RC file for mail, or the FSUUCP.CFG file for news.
-
-UUPC/extended for DOS, OS/2 and Windows NT handles mail at grade 'C',
-news at grade 'd', and file transfers at grade 'n'.  The UUPC/extended
-UUCP and RMAIL commands accept grades to override the default, the
-others do not.
-
-I do not know how command grades are handled in other non-Unix UUCP
-packages.
-
-Modern UUCP packages allow you to restrict file transfer by grade
-depending on the time of day.  Typically this is done with a line in
-the Systems (or L.sys) file like this:
-    airs Any/Z,Any2305-0855 ...
-This allows grades 'Z' and above to be transferred at any time.  Lower
-grades may only be transferred at night.  I believe that this grade
-restriction applies to local commands as well as to remote commands,
-but I am not sure.  It may only apply if the UUCP package places the
-call, not if it is called by the remote system.
-
-Taylor UUCP can use the ``timegrade'' and ``call-timegrade'' commands
-to achieve the same effect (and supports the above format when reading
-Systems or L.sys).
-
-UUPC/extended provides the symmetricgrades option to announce the
-current grade in effect when calling the remote system.
-
-This sort of grade restriction is most useful if you know what grades
-are being used at the remote site.  The default grades used depend on
-the UUCP package.  Generally uucp and uux have different defaults.  A
-particular grade can be specified with the -g option to uucp or uux.
-For example, to request execution of rnews on airs with grade 'd', you
-might use something like
-    uux -gd - airs!rnews <article
-
-Uunet queues up mail at grade 'C', but increases the grade based on
-the size.  News is queued at grade 'd', and file transfers at grade
-'n'.  The example above would allow mail (below some large size) to be
-received at any time, but would only permit news to be transferred at
-night.
-
-------------------------------
-
-From: UUCP-lock-file
-Subject: What is the format of a UUCP lock file?
-
-This discussion applies only to Unix.  I have no idea how UUCP locks
-ports on other systems.
-
-UUCP creates files to lock serial ports and systems.  On most if not
-all systems these same lock files are also used by cu to coordinate
-access to serial ports.  On some systems getty also uses these lock
-files, often under the name uugetty.
-
-The lock file normally contains the process ID of the locking process.
-This makes it easy to determine whether a lock is still valid.  The
-algorithm is to create a temporary file and then link it to the name
-that must be locked.  If the link fails because a file with that name
-already exists, the existing file is read to get the process ID.  If
-the process still exists, the lock attempt fails.  Otherwise the lock
-file is deleted and the locking algorithm is retried.
-
-Older UUCP packages put the lock files in the main UUCP spool
-directory, /usr/spool/uucp.  HDB UUCP generally puts the lock files in
-a directory of their own, usually /usr/spool/locks or /etc/locks.
-
-The original UUCP lock file format encodes the process ID as a four
-byte binary number.  The order of the bytes is host-dependent.  HDB
-UUCP stores the process ID as a ten byte ASCII decimal number, with a
-trailing newline.  For example, if process 1570 holds a lock file, it
-would contain the eleven characters space, space, space, space, space,
-space, one, five, seven, zero, newline.  Some versions of UUCP add a
-second line indicating which program created the lock (uucp, cu, or
-getty/uugetty).  I have also seen a third type of UUCP lock file which
-does not contain the process ID at all.
-
-The name of the lock file is traditionally "LCK.." followed by the
-base name of the device.  For example, to lock /dev/ttyd0 the file
-LCK..ttyd0 would be created.  On SCO Unix, the lock file name is
-always forced to lower case even if the device name has upper case
-letters.
-
-System V Release 4 UUCP names the lock file using the major and minor
-device numbers rather than the device name.  The file is named
-LK.XXX.YYY.ZZZ, where XXX, YYY and ZZZ are all three digit decimal
-numbers.  XXX is the major device number of the device holding the
-directory holding the device file (e.g., /dev).  YYY is the major
-device number of the device file itself.  ZZZ is the minor device
-number of the device file itself.  If s holds the result of passing
-the device to the stat system call (e.g., stat ("/dev/ttyd0", &s)),
-the following line of C code will print out the corresponding lock
-file name:
-    printf ("LK.%03d.%03d.%03d", major (s.st_dev),
-            major (s.st_rdev), minor (s.st_rdev));
-The advantage of this system is that even if there are several links
-to the same device, they will all use the same lock file name.
-
-------------------------------
-
-From: X-file
-Subject: What is the format of a UUCP X.* file?
-
-UUCP X.* files control program execution.  They are created by uux.
-They are transferred between computers just like any other file.  The
-uuxqt daemon reads them to figure out how to execute the job requested
-by uux.
-
-An X.* file is simply a text file.  The first character of each line
-is a command, and the remainder of the line supplies arguments.  The
-following commands are defined:
-    C command
-        This gives the command to execute, including the program and
-        all arguments.  For example,
-            C rmail ian@airs.com
-    U user system
-        This names the user who requested the command, and the system
-        from which the request came.
-    I standard-input
-        This names the file from which standard input is taken.  If no
-        standard input file is given, the standard input will probably
-        be attached to /dev/null.  If the standard input file is not
-        from the system on which the execution is to occur, it will
-        also appear in an F command.
-    O standard-output [ system ]
-        This names the standard output file.  The optional second
-        argument names the system to which the file should be sent.
-        If there is no second argument, the file should be created on
-        the executing system.
-    F required-file [ filename-to-use ]
-        The F command can appear multiple times.  Each F command names
-        a file which must exist before the execution can proceed.
-        This will usually be a file which is transferred from the
-        system on which uux was executed, but it can also be a file
-        from the local system or some other system.  If the file is
-        not from the local system, then the command will usually name
-        a file in the spool directory.  If the optional second
-        argument appears, then the file should be copied to the
-        execution directory under that name.  This is necessary for
-        any file other than the standard input file.  If the standard
-        input file is not from the local system, it will appear in
-        both an F command and an I command.
-    R requestor-address
-        This is the address to which mail about the job should be
-        sent.  It is relative to the system named in the U command.
-        If the R command does not appear, then mail is sent to the
-        user named in the U command.
-    Z
-        This command takes no arguments.  It means that a mail message
-        should be sent if the command failed.  This is the default
-        behaviour for most modern UUCP packages, and for them the Z
-        command does not actually do anything.
-    N
-        This command takes no arguments.  It means that no mail
-        message should be sent, even if the command failed.
-    n
-        This command takes no arguments.  It means that a mail message
-        should be sent if the command succeeded.  Normally a message
-        is sent only if the command failed.
-    B
-        This command takes no arguments.  It means that the standard
-        input should be returned with any error message.  This can be
-        useful in cases where the input would otherwise be lost.
-    e
-        This command takes no arguments.  It means that the command
-        should be processed with /bin/sh.  For some packages this is
-        the default anyhow.  Most packages will refuse to execute
-        complex commands or commands containing wildcards, because of
-        the security holes this opens.
-    E
-        This command takes no arguments.  It means that the command
-        should be processed with the execve system call.  For some
-        packages this is the default anyhow.
-    M status-file
-        This command means that instead of mailing a message, the
-        message should be copied to the named file on the system named
-        by the U command.
-    # comment
-        This command is ignored, as is any other unrecognized command.  
-
-Here is an example.  Given the following command executed on system
-test1
-    uux - test2!cat - test2!~ian/bar !qux '>~/gorp'
-(this is only an example, as most UUCP systems will not permit the cat
-command to be executed) Taylor UUCP will produce the following X.
-file:
-    U ian test1
-    F D.test1N003r qux
-    O /usr/spool/uucppublic test1
-    F D.test1N003s
-    I D.test1N003s
-    C cat - ~ian/bar qux
-The standard input will be read into a file and then transferred to
-the file D.test1N003s on system test2, and the file qux will be
-transferred to D.test1N003r on system test2.  When the command is
-executed, the latter file will be copied to the execution directory
-under the name qux.  Note that since the file ~ian/bar is already on
-the execution system, no action need be taken for it.  The standard
-output will be collected in a file, then copied to the directory
-/usr/spool/uucppublic on the system test1.
-
-------------------------------
-
-From: UUCP-protocol
-Subject: What is the UUCP protocol?
-
-The UUCP protocol is a conversation between two UUCP packages.  A UUCP
-conversation consists of three parts: an initial handshake, a series
-of file transfer requests, and a final handshake.
-
-Before the initial handshake, the caller will usually have logged in
-the called machine and somehow started the UUCP package there.  On
-Unix this is normally done by setting the shell of the login name used
-to /usr/lib/uucp/uucico.
-
-All messages in the initial handshake begin with a ^P (a byte with the
-octal value \020) and end with a null byte (\000).  A few systems end
-these messages with a line feed character (\012) instead of a null
-byte; the examples below assume a null byte is being used.
-
-Some options below are supported by QFT, which stands for Queued File
-Transfer, and is (or was) an internal Bell Labs version of UUCP.  
-
-Taylor UUCP size negotiation was introduced by Taylor UUCP, and is
-also supported by DOS based FSUUCP and Amiga based wUUCP and
-UUCP-1.17.
-
-The initial handshake goes as follows.  It is begun by the called
-machine.
-
-called: \020Shere=hostname\000
-    The hostname is the UUCP name of the called machine.  Older UUCP
-    packages do not output it, and simply send \020Shere\000.
-
-caller: \020Shostname options\000
-    The hostname is the UUCP name of the calling machine.  The
-    following options may appear (or there may be none):
-        -QSEQ
-            Report sequence number for this conversation.  The
-            sequence number is stored at both sites, and incremented
-            after each call.  If there is a sequence number mismatch,
-            something has gone wrong (somebody may have broken
-            security by pretending to be one of the machines) and the
-            call is denied.  If the sequence number changes on one of
-            the machines, perhaps because of an attempted breakin or
-            because a disk backup was restored, the sequence numbers
-            on the two machines must be reconciled manually.  This is
-            not supported by FSUUCP.
-        -xLEVEL
-            Requests the called system to set its debugging level to
-            the specified value.  This is not supported by all
-            systems.
-        -pGRADE
-        -vgrade=GRADE
-            Requests the called system to only transfer files of the
-            specified grade or higher.  This is not supported by all
-            systems.  Some systems support -p, some support -vgrade=.
-        -R
-            Indicates that the calling UUCP understands how to restart
-            failed file transmissions.  Supported only by System V
-            Release 4 UUCP and QFT.
-        -ULIMIT
-            Reports the ulimit value of the calling UUCP.  The limit
-            is specified as a base 16 number in C notation (e.g.,
-            -U0x1000000).  This number is the number of 512 byte
-            blocks in the largest file which the calling UUCP can
-            create.  The called UUCP may not transfer a file larger
-            than this.  Supported only by System V Release 4 UUCP, QFT
-            and FSUUCP.  FSUUCP reports the lesser of the
-            available disk space on the spool directory drive and the
-            ulimit variable in FSUUCP.CFG.
-        -N
-            Indicates that the calling UUCP understands the Taylor
-            UUCP size negotiation extension.  Not supported by
-	    traditional UUCP packages.
-
-called: \020ROK\000
-    There are actually several possible responses.
-        ROK
-            The calling UUCP is acceptable, and the handshake proceeds
-            to the protocol negotiation.  Some options may also
-            appear; see below.
-        ROKN
-            The calling UUCP is acceptable, it specified -N, and the
-            called UUCP also understands the Taylor UUCP size limiting
-            extensions.
-        RLCK
-            The called UUCP already has a lock for the calling UUCP,
-            which normally indicates the two machines are already
-            communicating.
-        RCB
-            The called UUCP will call back.  This may be used to avoid
-            impostors (but only one machine out of each pair should
-            call back, or no conversation will ever begin).
-        RBADSEQ
-            The call sequence number is wrong (see the -Q discussion
-            above). 
-        RLOGIN
-            The calling UUCP is using the wrong login name.
-        RYou are unknown to me
-            The calling UUCP is not known to the called UUCP, and the
-            called UUCP does not permit connections from unknown
-            systems.  Some versions of UUCP just drop the line rather
-            than sending this message.
-
-    If the response is ROK, the following options are supported by
-    System V Release 4 UUCP and QFT.
-        -R
-            The called UUCP knows how to restart failed file
-            transmissions.
-        -ULIMIT
-            Reports the ulimit value of the called UUCP.  The limit is
-            specified as a base 16 number in C notation.  This number
-            is the number of 512 byte blocks in the largest file which
-            the called UUCP can create.  The calling UUCP may not send
-            a file larger than this.  Also supported by FSUUCP.
-        -xLEVEL
-            I'm not sure just what this means.  It may request the
-            calling UUCP to set its debugging level to the specified
-            value.
-    If the response is not ROK (or ROKN) both sides hang up the phone,
-    abandoning the call.
-
-called: \020Pprotocols\000
-    Note that the called UUCP outputs two strings in a row.  The
-    protocols string is a list of UUCP protocols supported by the
-    caller.  Each UUCP protocol has a single character name.  These
-    protocols are discussed in more detail later in this document.
-    For example, the called UUCP might send \020Pgf\000.
-
-caller: \020Uprotocol\000
-    The calling UUCP selects which protocol to use out of the
-    protocols offered by the called UUCP.  If there are no mutually
-    supported protocols, the calling UUCP sends \020UN\000 and both
-    sides hang up the phone.  Otherwise the calling UUCP sends
-    something like \020Ug\000.
-
-Most UUCP packages will consider each locally supported protocol in
-turn and select the first one supported by the called UUCP.  With some
-versions of HDB UUCP, this can be modified by giving a list of
-protocols after the device name in the Devices file or the Systems
-file.  For example, to select the 'e' protocol in Systems,
-    airs Any ACU,e ...
-or in Devices,
-    ACU,e ttyXX ...
-Taylor UUCP provides the ``protocol'' command which may be used either
-for a system or a port.
-
-After the protocol has been selected and the initial handshake has been
-completed, both sides turn on the selected protocol.  For some
-protocols (notably 'g') a further handshake is done at this point.
-
-Each protocol supports a method for sending a command to the remote
-system.  This method is used to transmit a series of commands between
-the two UUCP packages.  At all times, one package is the master and
-the other is the slave.  Initially, the calling UUCP is the master.
-
-If a protocol error occurs during the exchange of commands, both sides
-move immediately to the final handshake.
-
-The master will send one of four commands: S, R, X or H.
-
-Any file name referred to below is either an absolute pathname
-beginning with "/", a public directory pathname beginning with "~/", a
-pathname relative to a user's home directory beginning with "~USER/",
-or a spool directory file name.  File names in the spool directory are
-not pathnames, but instead are converted to pathnames within the spool
-directory by UUCP.  They always begin with "C." (for a command file
-created by uucp or uux), "D." (for a data file created by uucp, uux or
-by an execution, or received from another system for an execution), or
-"X." (for an execution file created by uux or received from another
-system).
-
-master: S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE
-    The S and the - are literal characters.  This is a request by the
-    master to send a file to the slave.
-        FROM
-            The name of the file to send.  If the C option does not
-            appear in OPTIONS, the master will actually open and send
-            this file.  Otherwise the file has been copied to the
-            spool directory, where it is named TEMP.  The slave
-            ignores this field unless TO is a directory, in which case
-            the basename of FROM will be used as the file name.  If
-            FROM is a spool directory filename, it must be a data file
-            created for or by an execution, and must begin with "D.".
-        TO
-            The name to give the file on the slave.  If this field
-            names a directory the file is placed within that directory
-            with the basename of FROM.  A name ending in `/' is taken
-            to be a directory even if one does not already exist with
-            that name.  If TO begins with `X.', an execution file will
-            be created on the slave.  Otherwise, if TO begins with
-            `D.' it names a data file to be used by some execution
-            file.  Otherwise, TO should not be in the spool directory.
-        USER
-            The name of the user who requested the transfer.
-        OPTIONS
-            A list of options to control the transfer.  The following
-            options are defined (all options are single characters):
-                C
-                    The file has been copied to the spool directory
-                    (the master should use TEMP rather than FROM).
-                c
-                    The file has not been copied to the spool
-                    directory (this is the default).
-                d
-                    The slave should create directories as necessary
-                    (this is the default).
-                f
-                    The slave should not create directories if
-                    necessary, but should fail the transfer instead.
-                m
-                    The master should send mail to USER when the
-                    transfer is complete (not supported by FSUUCP).
-                n
-                    The slave should send mail to NOTIFY when the
-                    transfer is complete (not supported by FSUUCP).
-        TEMP
-            If the C option appears in OPTIONS, this names the file to
-            be sent.  Otherwise if FROM is in the spool directory,
-            TEMP is the same as FROM.  Otherwise TEMP may be a dummy
-            string, such as "D.0".  After the transfer has been
-            succesfully completed, the master will delete the file
-            TEMP.
-        MODE
-            This is an octal number giving the mode of the file on
-            MASTER.  If the file is not in the spool directory, the
-            slave will always create it with mode 0666, except that if
-            (MODE & 0111) is not zero (the file is executable), the
-            slave will create the file with mode 0777.  If the file is
-            in the spool directory, some UUCP packages will use the
-            algorithm above and some will always create the file with
-            mode 0600.  This field is not used by FSUUCP, since it is
-            meaningless on DOS.
-        NOTIFY
-            This field may not be present, and in any case is only
-            meaningful if the n option appears in OPTIONS.  If the n
-            option appears, then when the transfer is successfully
-            completed, the slave will send mail to NOTIFY, which must
-            be a legal mailing address on the slave.  If a SIZE field
-            will appear but the n option does not appear, NOTIFY will
-            always be present, typically as the string "dummy" or
-            simply a pair of double quotes.
-        SIZE
-            This field is only present when doing Taylor UUCP or SVR4
-            UUCP size negotiation, It is the size of the file in
-            bytes.  Taylor UUCP version 1.03 sends the size as a
-            decimal integer, while versions 1.04 and up, and all other
-            UUCP packages that support size negotiation, send the size
-            in base 16 with a leading 0x.
-
-    The slave then responds with an S command response.
-        SY START
-            The slave is willing to accept the file, and file transfer
-            begins.  The START field will only be present when using
-            file restart.  It specifies the byte offset into the file
-            at which to start sending.  If this is a new file, START
-            will be 0x0.
-        SN2
-            The slave denies permission to transfer the file.  This
-            can mean that the destination directory may not be
-            accessed, or that no requests are permitted.  It implies
-            that the file transfer will never succeed.
-        SN4
-            The slave is unable to create the necessary temporary
-            file.  This implies that the file transfer might succeed
-            later.
-        SN6
-            This is only used by Taylor UUCP size negotiation.  It
-            means that the slave considers the file too large to
-            transfer at the moment, but it may be possible to transfer
-            it at some other time.
-        SN7
-            This is only used by Taylor UUCP size negotiation.  It
-            means that the slave considers the file too large to ever
-            transfer.
-        SN8
-            This is only used by Taylor UUCP.  It means that the file
-            was already received in a previous conversation.  This can
-            happen if the receive acknowledgement was lost after it
-            was sent by the receiver but before it was received by the
-            sender.
-	SN9
-	    This is only used by Taylor UUCP (versions 1.05 and up)
-	    and FSUUCP (versions 1.5 and up).  It means that the
-	    remote system was unable to open another channel (see the
-	    discussion of the 'i' protocol for more information about
-	    channels).  This implies that the file transfer might
-	    succeed later.
-        SN10
-            This is reportedly used by SVR4 UUCP to mean that the file
-            size is too large.
-
-    If the slave responds with SY, a file transfer begins.  When the
-    file transfer is complete, the slave sends a C command response.
-        CY
-            The file transfer was successful.
-        CYM
-            The file transfer was successful, and the slave wishes to
-            become the master; the master should send an H command,
-            described below.
-        CN5
-            The temporary file could not be moved into the final
-            location.  This implies that the file transfer will never
-            succeed.
-
-    After the C command response has been received (in the SY case) or
-    immediately (in an SN case) the master will send another command.
-
-master: R FROM TO USER -OPTIONS SIZE
-    The R and the - are literal characters.  This is a request by the
-    master to receive a file from the slave.  I do not know how SVR4
-    UUCP or QFT implement file transfer restart in this case.
-        FROM
-            This is the name of the file on the slave which the master
-            wishes to receive.  It must not be in the spool directory,
-            and it may not contain any wildcards.
-        TO
-            This is the name of the file to create on the master.  I
-            do not believe that it can be a directory.  It may only be
-            in the spool directory if this file is being requested to
-            support an execution either on the master or on some
-            system other than the slave.
-        USER
-            The name of the user who requested the transfer.
-        OPTIONS
-            A list of options to control the transfer.  The following
-            options are defined (all options are single characters):
-                d
-                    The master should create directories as necessary
-                    (this is the default).
-                f
-                    The master should not create directories if
-                    necessary, but should fail the transfer instead.
-                m
-                    The master should send mail to USER when the
-                    transfer is complete.
-        SIZE
-            This only appears if Taylor UUCP size negotiation is being
-            used.  It specifies the largest file which the master is
-            prepared to accept (when using SVR4 UUCP or QFT, this was
-            specified in the -U option during the initial handshake).
-
-    The slave then responds with an R command response.  FSUUCP does
-    not support R requests, and always responds with RN2.
-        RY MODE [ SIZE ]
-            The slave is willing to send the file, and file transfer
-            begins.  MODE is the octal mode of the file on the slave.
-            The master treats this just as the slave does the MODE
-            argument in the send command, q.v.  I am told that SVR4
-            UUCP sends a trailing SIZE argument.  For some versions of
-            BSD UUCP, the MODE argument may have a trailing M
-            character (e.g., RY 0666M).  This means that the slave
-            wishes to become the master.
-        RN2
-            The slave is not willing to send the file, either because
-            it is not permitted or because the file does not exist.
-            This implies that the file request will never succeed.
-        RN6
-            This is only used by Taylor UUCP size negotiation.  It
-            means that the file is too large to send, either because
-            of the size limit specifies by the master or because the
-            slave considers it too large.  The file transfer might
-            succeed later, or it might not (this will be cleared up in
-            a later release of Taylor UUCP).
-	RN9
-	    This is only used by Taylor UUCP (versions 1.05 and up)
-	    and FSUUCP (versions 1.5 and up).  It means that the
-	    remote system was unable to open another channel (see the
-	    discussion of the 'i' protocol for more information about
-	    channels).  This implies that the file transfer might
-	    succeed later.
-
-    If the slave responds with RY, a file transfer begins.  When the
-    file transfer is complete, the master sends a C command.  The
-    slave pretty much ignores this, although it may log it.
-        CY
-            The file transfer was successful.
-        CN5
-            The temporary file could not be moved into the final
-            location.
-
-    After the C command response has been sent (in the RY case) or
-    immediately (in an RN case) the master will send another command.
-
-master: X FROM TO USER -OPTIONS
-    The X and the - are literal characters.  This is a request by the
-    master to, in essence, execute uucp on the slave.  The slave
-    should execute "uucp FROM TO".
-        FROM
-            This is the name of the file or files on the slave which
-            the master wishes to transfer.  Any wildcards are expanded
-            on the slave.  If the master is requesting that the files
-            be transferred to itself, the request would normally
-            contain wildcard characters, since otherwise an `R'
-            command would suffice.  The master can also use this
-            command to request that the slave transfer files to a
-            third system.
-        TO
-            This is the name of the file or directory to which the
-            files should be transferred.  This will normally use a
-            UUCP name.  For example, if the master wishes to receive
-            the files itself, it would use "master!path".
-        USER
-            The name of the user who requested the transfer.
-        OPTIONS
-            A list of options to control the transfer.  It is not
-            clear which, if any, options are supported by most UUCP
-            packages.
-
-    The slave then responds with an X command response.  FSUUCP does
-    not support X requests, and always responds with XN.
-        XY
-            The request was accepted, and the appropriate file
-            transfer commands have been queued up for later
-            processing.
-        XN
-            The request was denied.  No particular reason is given.
-
-    In either case, the master will then send another command.
-
-master: H
-    This is used by the master to hang up the connection.  The slave
-    will respond with an H command response.
-        HY
-            The slave agrees to hang up the connection.  In this case
-            the master sends another HY command.  In some UUCP
-            packages the slave will then send a third HY command.  At
-            this point the protocol is shut down, and the final
-            handshake is begun.
-        HN
-            The slave does not agree to hang up.  In this case the
-            master and the slave exchange roles.  The next command
-            will be sent by the former slave, which is the new master.
-            The roles may be reversed several times during a single
-            connection.
-
-After the protocol has been shut down, the final handshake is
-performed.  This handshake has no real purpose, and some UUCP packages
-simply drop the connection rather than do it (in fact, some will drop
-the connection immediately after both sides agree to hangup, without
-even closing down the protocol).
-
-caller: \020OOOOOO\000
-called: \020OOOOOOO\000
-
-That is, the calling UUCP sends six O's and the called UUCP replies
-with seven O's.  Some UUCP packages always send six O's.
-
-------------------------------
-
-From: UUCP-g
-Subject: What is the 'g' protocol?
-
-The 'g' protocol is a packet based flow controlled error correcting
-protocol that requires an eight bit clear connection.  It is the
-original UUCP protocol, and is supported by all UUCP implementations.
-Many implementations of it are only able to support small window and
-packet sizes, specifically a window size of 3 and a packet size of 64
-bytes, but the protocol itself can support up to a window size of 7
-and a packet size of 4096 bytes.  Complaints about the inefficiency of
-the 'g' protocol generally refer to specific implementations, rather
-than to the correctly implemented protocol.
-
-The 'g' protocol was originally designed for general packet drivers,
-and thus contains some features that are not used by UUCP, including
-an alternate data channel and the ability to renegotiate packet and
-window sizes during the communication session.
-
-The 'g' protocol is spoofed by many Telebit modems.  When spoofing is
-in effect, each Telebit modem uses the 'g' protocol to communicate
-with the attached computer, but the data between the modems is sent
-using a Telebit proprietary error correcting protocol.  This allows
-for very high throughput over the Telebit connection, which, because
-it is half-duplex, would not normally be able to handle the 'g'
-protocol very well at all.  When a Telebit is spoofing the 'g'
-protocol, it forces the packet size to be 64 bytes and the window size
-to be 3.
-
-This discussion of the 'g' protocol explains how it works, but does
-not discuss useful error handling techniques.  Some discussion of this
-can be found in Jamie E. Hanrahan's paper, cited above.
-
-All 'g' protocol communication is done with packets.  Each packet
-begins with a six byte header.  Control packets consist only of the
-header.  Data packets contain additional data.
-
-The header is as follows:
-
-    \020
-        Every packet begins with a ^P.
-    k (1 <= k <= 9)
-        The k value is always 9 for a control packet.  For a data
-        packet, the k value indicates how much data follows the six
-        byte header.  The amount of data is 2 ** (k + 4), where **
-        indicates exponentiation.  Thus a k value of 1 means 32 data
-        bytes and a k value of 8 means 4096 data bytes.  The k value
-        for a data packet must be between 1 and 8 inclusive.
-    checksum low byte
-    checksum high byte
-        The checksum value is described below.
-    control byte
-        The control byte indicates the type of packet, and is
-        described below.
-    xor byte
-        This byte is the xor of k, the checksum low byte, the checksum
-        high byte and the control byte (i.e., the second, third,
-        fourth and fifth header bytes).  It is used to ensure that the
-        header data is valid.
-
-The control byte in the header is composed of three bit fields,
-referred to here as TT (two bits), XXX (three bits) and YYY (three
-bits).  The control is TTXXXYYY, or (TT << 6) + (XXX << 3) + YYY.
-
-The TT field takes on the following values:
-    0
-        This is a control packet.  In this case the k byte in the
-        header must be 9.  The XXX field indicates the type of control
-        packet; these types are described below.
-    1
-        This is an alternate data channel packet.  This is not used by
-        UUCP.
-    2
-        This is a data packet, and the entire contents of the attached
-        data field (whose length is given by the k byte in the header)
-        are valid.  The XXX and YYY fields are described below.
-    3
-        This is a short data packet.  Let the length of the data field
-        (as given by the k byte in the header) be L.  Let the first
-        byte in the data field be B1.  If B1 is less than 128 (if the
-        most significant bit of B1 is 0), then there are L - B1 valid
-        bytes of data in the data field, beginning with the second
-        byte.  If B1 >= 128, let B2 be the second byte in the data
-        field.  Then there are L - ((B1 & 0x7f) + (B2 << 7)) valid
-        bytes of data in the data field, beginning with the third
-        byte.  In all cases L bytes of data are sent (and all data
-        bytes participate in the checksum calculation) but some of the
-        trailing bytes may be dropped by the receiver.   The XXX and
-        YYY fields are described below.
-
-In a data packet (short or not) the XXX field gives the sequence
-number of the packet.  Thus sequence numbers can range from 0 to 7,
-inclusive.  The YYY field gives the sequence number of the last
-correctly received packet.
-
-Each communication direction uses a window which indicates how many
-unacknowledged packets may be transmitted before waiting for an
-acknowledgement.  The window may range from 1 to 7, and may be
-different in each direction. For example, if the window is 3 and the
-last packet acknowledged was packet number 6, packet numbers 7, 0 and
-1 may be sent but the sender must wait for an acknowledgement before
-sending packet number 2.  This acknowledgement could come as the YYY
-field of a data packet or as the YYY field of a RJ or RR control
-packet (described below).
-
-Each packet must be transmitted in order (the sender may not skip
-sequence numbers).  Each packet must be acknowledged, and each packet
-must be acknowledged in order.
-
-In a control packet, the XXX field takes on the following values:
-    1 CLOSE
-        The connection should be closed immediately.  This is
-        typically sent when one side has seen too many errors and
-        wants to give up.  It is also sent when shutting down the
-        protocol.  If an unexpected CLOSE packet is received, a CLOSE
-        packet should be sent in reply and the 'g' protocol should
-        halt, causing UUCP to enter the final handshake.
-    2 RJ or NAK
-        The last packet was not received correctly.  The YYY field
-        contains the sequence number of the last correctly received
-        packet.
-    3 SRJ
-        Selective reject.  The YYY field contains the sequence number
-        of a packet that was not received correctly, and should be
-        retransmitted.  This is not used by UUCP, and most
-        implementations will not recognize it.
-    4 RR or ACK
-        Packet acknowledgement.  The YYY field contains the sequence
-        number of the last correctly received packet.
-    5 INITC
-        Third initialization packet.  The YYY field contains the
-        maximum window size to use.
-    6 INITB
-        Second initialization packet.  The YYY field contains the
-        packet size to use.  It requests a size of 2 ** (YYY + 5).
-        Note that this is not the same coding used for the k byte in
-        the packet header (it is 1 less).  Most UUCP implementations
-        that request a packet size larger than 64 bytes can handle any
-        packet size up to that specified.
-    7 INITA
-        First initialization packet.  The YYY field contains the
-        maximum window size to use.
-
-The checksum of a control packet is simply 0xaaaa - the control byte.
-
-The checksum of a data packet is 0xaaaa - (CHECK ^ the control byte),
-where ^ denotes exclusive or, and CHECK is the result of the following
-routine as run on the contents of the data field (every byte in the
-data field participates in the checksum, even for a short data
-packet).  Below is the routine used by Taylor UUCP; it is a slightly
-modified version of a routine which John Gilmore patched from G.L.
-Chesson's original paper.  The z argument points to the data and the c
-argument indicates how much data there is.
-
-int
-igchecksum (z, c)
-     register const char *z;
-     register int c;
-{
-  register unsigned int ichk1, ichk2;
-
-  ichk1 = 0xffff;
-  ichk2 = 0;
-
-  do
-    {
-      register unsigned int b;
-
-      /* Rotate ichk1 left.  */
-      if ((ichk1 & 0x8000) == 0)
-        ichk1 <<= 1;
-      else
-        {
-          ichk1 <<= 1;
-          ++ichk1;
-        }
-
-      /* Add the next character to ichk1.  */
-      b = *z++ & 0xff;
-      ichk1 += b;
-
-      /* Add ichk1 xor the character position in the buffer counting from
-         the back to ichk2.  */
-      ichk2 += ichk1 ^ c;
-
-      /* If the character was zero, or adding it to ichk1 caused an
-         overflow, xor ichk2 to ichk1.  */
-      if (b == 0 || (ichk1 & 0xffff) < b)
-        ichk1 ^= ichk2;
-    }
-  while (--c > 0);
-
-  return ichk1 & 0xffff;
-}
-
-When the 'g' protocol is started, the calling UUCP sends an INITA
-control packet with the window size it wishes the called UUCP to use.
-The called UUCP responds with an INITA packet with the window size it
-wishes the calling UUCP to use.  Pairs of INITB and INITC packets are
-then similarly exchanged.  When these exchanges are completed, the
-protocol is considered to have been started.
-
-Note that the window and packet sizes are not a negotiation.  Each
-system announces the window and packet size which the other system
-should use.  It is possible that different window and packet sizes
-will be used in each direction.  The protocol works this way on the
-theory that each system knows how much data it can accept without
-getting overrun.  Therefore, each system tells the other how much data
-to send before waiting for an acknowledgement.
-
-When a UUCP package transmits a command, it sends one or more data
-packets.  All the data packets will normally be complete, although
-some UUCP packages may send the last one as a short packet.  The
-command string is sent with a trailing null byte, to let the receiving
-package know when the command is finished.  Some UUCP packages require
-the last byte of the last packet sent to be null, even if the command
-ends earlier in the packet.  Some packages may require all the
-trailing bytes in the last packet to be null, but I have not confirmed
-this.
-
-When a UUCP package sends a file, it will send a sequence of data
-packets.  The end of the file is signalled by a short data packet
-containing zero valid bytes (it will normally be preceeded by a short
-data packet containing the last few bytes in the file).
-
-Note that the sequence numbers cover the entire communication session,
-including both command and file data.
-
-When the protocol is shut down, each UUCP package sends a CLOSE
-control packet.
-
-------------------------------
-
-From: UUCP-f
-Subject: What is the 'f' protocol?
-
-The 'f' protocol is a seven bit protocol which checksums an entire
-file at a time.  It only uses the characters between \040 and \176
-(ASCII space and ~) inclusive as well as the carriage return
-character.  It can be very efficient for transferring text only data,
-but it is very inefficient at transferring eight bit data (such as
-compressed news).  It is not flow controlled, and the checksum is
-fairly insecure over large files, so using it over a serial connection
-requires handshaking (XON/XOFF can be used) and error correcting
-modems.  Some people think it should not be used even under those
-circumstances.
-
-I believe the 'f' protocol originated in BSD versions of UUCP.  It was
-originally intended for transmission over X.25 PAD links.
-
-The 'f' protocol has no startup or finish protocol.  However, both
-sides typically sleep for a couple of seconds before starting up,
-because they switch the terminal into XON/XOFF mode and want to allow
-the changes to settle before beginning transmission.
-
-When a UUCP package transmits a command, it simply sends a string
-terminated by a carriage return.
-
-When a UUCP package transmits a file, each byte b of the file is
-translated according to the following table:
-
-       0 <= b <=  037: 0172, b + 0100 (0100 to 0137)
-     040 <= b <= 0171:       b        ( 040 to 0171)
-    0172 <= b <= 0177: 0173, b - 0100 ( 072 to  077)
-    0200 <= b <= 0237: 0174, b - 0100 (0100 to 0137)
-    0240 <= b <= 0371: 0175, b - 0200 ( 040 to 0171)
-    0372 <= b <= 0377: 0176, b - 0300 ( 072 to  077)
-
-That is, a byte between \040 and \171 inclusive is transmitted as is,
-and all other bytes are prefixed and modified as shown.
-
-When all the file data is sent, a seven byte sequence is sent: two
-bytes of \176 followed by four ASCII bytes of the checksum as printed
-in base 16 followed by a carriage return.  For example, if the
-checksum was 0x1234, this would be sent: "\176\1761234\r".
-
-The checksum is initialized to 0xffff.  For each byte that is sent it
-is modified as follows (where b is the byte before it has been
-transformed as described above):
-
-      /* Rotate the checksum left.  */
-      if ((ichk & 0x8000) == 0)
-        ichk <<= 1;
-      else
-        {
-          ichk <<= 1;
-          ++ichk;
-        }
-
-      /* Add the next byte into the checksum.  */
-      ichk += b;
-
-When the receiving UUCP sees the checksum, it compares it against its
-own calculated checksum and replies with a single character followed
-by a carriage return.
-    G
-        The file was received correctly.
-    R
-        The checksum did not match, and the file should be resent from
-        the beginning.
-    Q
-        The checksum did not match, but too many retries have occurred
-        and the communication session should be abandoned.
-
-The sending UUCP checks the returned character and acts accordingly.
-
-------------------------------
-
-From: UUCP-t
-Subject: What is the 't' protocol?
-
-The 't' protocol is intended for use on links which provide reliable
-end-to-end connections, such as TCP.  It does no error checking or
-flow control, and requires an eight bit clear channel.
-
-I believe the 't' protocol originated in BSD versions of UUCP.
-
-When a UUCP package transmits a command, it first gets the length of
-the command string, C.  It then sends ((C / 512) + 1) * 512 bytes (the
-smallest multiple of 512 which can hold C bytes plus a null byte)
-consisting of the command string itself followed by trailing null
-bytes.
-
-When a UUCP package sends a file, it sends it in blocks.  Each block
-contains at most 1024 bytes of data.  Each block consists of four
-bytes containing the amount of data in binary (most significant byte
-first, the same format as used by the Unix function htonl) followed by
-that amount of data.  The end of the file is signalled by a block
-containing zero bytes of data.
-
-------------------------------
-
-From: UUCP-e
-Subject: What is the 'e' protocol?
-
-The 'e' protocol is similar to the 't' protocol.  It does no flow
-control or error checking and is intended for use over networks
-providing reliable end-to-end connections, such as TCP.
-
-The 'e' protocol originated in versions of HDB UUCP.
-
-When a UUCP package transmits a command, it simply sends the command
-as an ASCII string terminated by a null byte.
-
-When a UUCP package transmits a file, it sends the complete size of
-the file as an ASCII decimal number.  The ASCII string is padded out
-to 20 bytes with null bytes (i.e. if the file is 1000 bytes long, it
-sends "1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0").  It then sends the
-entire file.
-
-------------------------------
-
-From: UUCP-G
-Subject: What is the 'G' protocol?
-
-The 'G' protocol is used by SVR4 UUCP.  It is identical to the 'g'
-protocol, except that it is possible to modify the window and packet
-sizes.  The SVR4 implementation of the 'g' protocol reportedly is
-fixed at a packet size of 64 and a window size of 7.  Supposedly SVR4
-chose to implement a new protocol using a new letter to avoid any
-potential incompatibilities when using different packet or window
-sizes.
-
-Most implementations of the 'g' protocol that accept packets larger
-than 64 bytes will also accept packets smaller than whatever they
-requested in the INITB packet.  The SVR4 'G' implementation is an
-exception; it will only accept packets of precisely the size it
-requests in the INITB packet.
-
-------------------------------
-
-From: UUCP-i
-Subject: What is the 'i' protocol?
-
-The 'i' protocol was written by Ian Lance Taylor (who also wrote this
-FAQ).  It is used by Taylor UUCP version 1.04.
-
-It is a sliding window packet protocol, like the 'g' protocol, but it
-supports bidirectional transfers (i.e., file transfers in both
-directions simultaneously).  It requires an eight bit clear
-connection.  Several ideas for the protocol were taken from the paper
-``A High-Throughput Message Transport System'' by P. Lauder.  I don't
-know where the paper was published, but the author's e-mail address is
-piers@cs.su.oz.au.  The 'i' protocol does not adopt his main idea,
-which is to dispense with windows entirely.  This is because some
-links still do require flow control and, more importantly, because
-using windows sets a limit to the amount of data which the protocol
-must be able to resend upon request.  To reduce the costs of window
-acknowledgements, the protocol uses a large window and only requires
-an ack at the halfway point.
-
-Each packet starts with a six byte header, optionally followed by data
-bytes with a four byte checksum.  There are currently five defined
-packet types (DATA, SYNC, ACK, NAK, SPOS, CLOSE) which are described
-below.  Although any packet type may include data, any data provided
-with an ACK, NAK or CLOSE packet is ignored.
-
-Every DATA, SPOS and CLOSE packet has a sequence number.  The sequence
-numbers are independent for each side.  The first packet sent by each
-side is always number 1.  Each packet is numbered one greater than the
-previous packet, modulo 32.
-
-Every packet has a local channel number and a remote channel number.
-For all packets at least one channel number is zero.  When a UUCP
-command is sent to the remote system, it is assigned a non-zero local
-channel number.  All packets associated with that UUCP command sent by
-the local system are given the selected local channel number.  All
-associated packets sent by the remote system are given the selected
-number as the remote channel number.  This permits each UUCP command
-to be uniquely identified by the channel number on the originating
-system, and therefore each UUCP package can associate all file data
-and UUCP command responses with the appropriate command.  This is a
-requirement for bidirectional UUCP transfers.
-
-The protocol maintains a single global file position, which starts at
-0.  For each incoming packet, any associated data is considered to
-occur at the current file position, and the file position is
-incremented by the amount of data contained.  The exception is a
-packet of type SPOS, which is used to change the file position.
-The reason for keeping track of the file position is described below.
-
-The header is as follows:
-
-    \007
-	Every packet begins with ^G.
-    (PACKET << 3) + LOCCHAN
-	The five bit packet number combined with the three bit local
-	channel number.  DATA, SPOS and CLOSE packets use the packet
-	sequence number for the PACKET field.  NAK packet types use
-	the PACKET field for the sequence number to be resent.  ACK
-	and SYNC do not use the PACKET field, and generally leave it
-	set to 0.  Packets which are not associated with a UUCP
-	command from the local system use a local channel number of 0.
-    (ACK << 3) + REMCHAN
-	The five bit packet acknowledgement combined with the three
-	bit remote channel number.  The packet acknowledgement is the
-	number of the last packet successfully received; it is used by
-	all packet types.  Packets which are not sent in response to a
-	UUCP command from the remote system use a remote channel
-	number of 0.
-    (TYPE << 5) + (CALLER << 4) + LEN1
-	The three bit packet type combined with the one bit packet
-	direction combined with the upper four bits of the data
-	length.  The packet direction bit is always 1 for packets sent
-	by the calling UUCP, and 0 for packets sent by the called
-	UUCP.  This prevents confusion caused by echoed packets.
-    LEN2
-	The lower eight bits of the data length.  The twelve bits of
-	data length permit packets ranging in size from 0 to 4095
-	bytes.
-    CHECK
-	The exclusive or of the second through fifth bytes of the
-	header.  This provides an additional check that the header is
-	valid.
-
-If the data length is non-zero, the packet is immediately followed by
-the specified number of data bytes.  The data bytes are followed by a
-four byte CRC 32 checksum, with the most significant byte first.  The
-CRC is calculated over the contents of the data field.
-
-The defined packet types are as follows:
-
-    0 (DATA)
-	This is a plain data packet.
-    1 (SYNC)
-	SYNC packets are exchanged when the protocol is initialized,
-	and are described further below.  SYNC packets do not carry
-	sequence numbers (that is, the PACKET field is ignored).
-    2 (ACK)
-	This is an acknowledgement packet.  Since DATA packets also
-	carry packet acknowledgements, ACK packets are only used when
-	one side has no data to send.  ACK packets do not carry
-	sequence numbers.
-    3 (NAK)
-	This is a negative acknowledgement.  This is sent when a
-	packet is received incorrectly, and means that the packet
-	number appearing in the PACKET field must be resent.  NAK
-	packets do not carry sequence numbers (the PACKET field is
-	already used).
-    4 (SPOS)
-	This packet changes the file position.  The packet contains
-	four bytes of data holding the file position, most significant
-	byte first.  The next packet received will be considered to be
-	at the named file position.
-    5 (CLOSE)
-	When the protocol is shut down, each side sends a CLOSE
-	packet.	 This packet does have a sequence number, which could
-	be used to ensure that all packets were correctly received
-	(this is not needed by UUCP, however, which uses the higher
-	level H command with an HY response).
-
-When the protocol starts up, both systems send a SYNC packet.  The
-SYNC packet includes at least three bytes of data.  The first two
-bytes are the maximum packet size the remote system should send, most
-significant byte first.  The third byte is the window size the remote
-system should use.  The remote system may send packets of any size up
-to the maximum.  If there is a fourth byte, it is the number of
-channels the remote system may use (this must be between 1 and 7,
-inclusive).  Additional data bytes may be defined in the future.
-
-The window size is the number of packets that may be sent before a
-packet is acknowledged.  There is no requirement that every packet be
-acknowledged; any acknowledgement is considered to acknowledge all
-packets through the number given.  In the current implementation, if
-one side has no data to send, it sends an ACK when half the window is
-received.
-
-Note that the NAK packet corresponds to the unused 'g' protocol SRJ
-packet type, rather than to the RJ packet type.  When a NAK is
-received, only the named packet should be resent, not any subsequent
-packets.
-
-Note that if both sides have data to send, but a packet is lost, it is
-perfectly reasonable for one side to continue sending packets, all of
-which will acknowledge the last packet correctly received, while the
-system whose packet was lost will be unable to send a new packet
-because the send window will be full.  In this circumstance, neither
-side will time out and one side of the communication will be
-effectively shut down for a while.  Therefore, any system with
-outstanding unacknowledged packets should arrange to time out and
-resend a packet even if data is being received.
-
-Commands are sent as a sequence of data packets with a non-zero local
-channel number.  The last data packet for a command includes a
-trailing null byte (normally a command will fit in a single data
-packet).  Files are sent as a sequence of data packets ending with one
-of length zero.
-
-The channel numbers permit a more efficient implementation of the UUCP
-file send command.  Rather than send the command and then wait for the
-SY response before sending the file, the file data is sent beginning
-immediately after the S command is sent.  If an SN response is
-received, the file send is aborted, and a final data packet of length
-zero is sent to indicate that the channel number may be reused.  If an
-SY reponse with a file position indicator is received, the file send
-adjusts to the file position; this is why the protocol maintains a
-global file position.
-
-Note that the use of channel numbers means that each UUCP system may
-send commands and file data simultaneously.  Moreover, each UUCP
-system may send multiple files at the same time, using the channel
-number to disambiguate the data.  Sending a file before receiving an
-acknowledgement for the previous file helps to eliminate the round
-trip delays inherent in other UUCP protocols.
-
-------------------------------
-
-From: UUCP-j
-Subject: What is the 'j' protocol?
-
-The 'j' protocol is a variant of the 'i' protocol.  It was also
-written by Ian Lance Taylor, and first appeared in Taylor UUCP version
-1.04.
-
-The 'j' protocol is a version of the 'i' protocol designed for
-communication links which intercept a few characters, such as XON or
-XOFF.  It is not efficient to use it on a link which intercepts many
-characters, such as a seven bit link.  The 'j' protocol performs no
-error correction or detection; that is presumed to be the
-responsibility of the 'i' protocol.
-
-When the 'j' protocol starts up, each system sends a printable ASCII
-string indicating which characters it wants to avoid using.  The
-string begins with the ASCII character '^' (octal 136) and ends with
-the ASCII character '~' (octal 176).  After sending this string, each
-system looks for the corresponding string from the remote system.  The
-strings are composed of escape sequences: \ooo, where o is an octal
-digit.  For example, sending the string ^\021\023~ means that the
-ASCII XON and XOFF characters should be avoided.  The union of the
-characters described in both strings (the string which is sent and the
-string which is received) is the set of characters which must be
-avoided in this conversation.  Avoiding a printable ASCII character
-(octal 040 to octal 176, inclusive) is not permitted.
-
-After the exchange of characters to avoid, the normal 'i' protocol
-start up is done, and the rest of the conversation uses the normal 'i'
-protocol.  However, each 'i' protocol packet is wrapped to become a
-'j' protocol packet.
-
-Each 'j' protocol packet consists of a seven byte header, followed by
-data bytes, followed by index bytes, followed by a one byte trailer.
-The packet header looks like this:
-
-    ^
-        Every packet begins with the ASCII character '^', octal 136.
-    HIGH
-    LOW
-        These two characters give the total number of bytes in the
-        packet.  Both HIGH and LOW are printable ASCII characters.
-        The length of the packet is (HIGH - 040) * 0100 + (LOW - 040),
-        where 040 <= HIGH < 0177 and 040 <= LOW < 0140.  This permits
-        a length of 6079 bytes, but there is a further restriction on
-        packet size described below.
-    =
-        The ASCII character '=', octal 075.
-    DATA-HIGH
-    DATA-LOW
-	These two characters give the total number of data bytes in
-        the packet.  The encoding is as described for HIGH and LOW.
-        The number of data bytes is the size of the 'i' protocol
-        packet wrapped inside this 'j' protocol packet.
-    @
-	The ASCII character '@', octal 100.
-
-The header is followed by the number of data bytes given in DATA-HIGH
-and DATA-LOW.  These data bytes are the 'i' protocol packet which is
-being wrapped in the 'j' protocol packet.  However, each character in
-the 'i' protocol packet which the 'j' protocol must avoid is
-transformed into a printable ASCII character (recall that avoiding a
-printable ASCII character is not permitted).  Two index bytes are used
-for each character which must be transformed.
-
-The index bytes immediately follow the data bytes.  The index bytes
-are created in pairs.  Each pair of index bytes encodes the location
-of a character in the 'i' protocol packet which was transformed to
-become a printable ASCII character.  Each pair of index bytes also
-encodes the precise transformation which was performed.
-
-When the sender finds a character which must be avoided, it will
-transform it using one or two operations.  If the character is 0200 or
-greater, it will subtract 0200.  If the resulting character is less
-than 020, or is equal to 0177, it will xor by 020.  The result is
-a printable ASCII character.
-
-The zero based byte index of the character within the 'i' protocol
-packet is determined.  This index is turned into a two byte printable
-ASCII index, INDEX-HIGH and INDEX-LOW, such that the index is
-(INDEX-HIGH - 040) * 040 + (INDEX-LOW - 040).  INDEX-LOW is restricted
-such that 040 <= INDEX-LOW < 0100.  INDEX-HIGH is not permitted to be
-0176, so 040 <= INDEX-HIGH < 0176.  INDEX-LOW is then modified to
-encode the transformation:
-
-    If the character transformation only had to subtract 0200, then
-    INDEX-LOW is used as is.
-
-    If the character transformation only had to xor by 020, then 040
-    is added to INDEX-LOW.
-
-    If both operations had to be performed, then 0100 is added to
-    INDEX-LOW.  However, if the value of INDEX-LOW were initially 077,
-    then adding 0100 would result in 0177, which is not a printable
-    ASCII character.  For that special case, INDEX-HIGH is set to
-    0176, and INDEX-LOW is set to the original value of INDEX-HIGH.
-
-The receiver decodes the index bytes as follows (this is the reverse
-of the operations performed by the sender, presented here for
-additional clarity):
-
-    The first byte in the index is INDEX-HIGH, and the second is
-    INDEX-LOW.
-
-    If 040 <= INDEX-HIGH < 0176, the index refers to the data byte at
-    position (INDEX-HIGH - 040) * 040 + INDEX-LOW % 040.
-
-        If 040 <= INDEX-LOW < 0100, then 0200 must be added to indexed
-        byte.
-
-        If 0100 <= INDEX-LOW < 0140, then 020 must be xor'ed to the
-        indexed byte.
-
-        If 0140 <= INDEX-LOW < 0177, then 0200 must be added to the
-        indexed byte, and 020 must be xor'ed to the indexed byte.
-
-    If INDEX-HIGH == 0176, the index refers to the data byte at
-    position (INDEX-LOW - 040) * 040 + 037.  0200 must be added to the
-    indexed byte, and 020 must be xor'ed to the indexed byte.
-
-This means the largest 'i' protocol packet which may be wrapped inside
-a 'j' protocol packet is (0175 - 040) * 040 + (077 - 040) == 3007
-bytes.
-
-The final character in a 'j' protocol packet, following the index
-bytes, is the ASCII character '~' (octal 176).
-
-The motivation behind using an indexing scheme, rather than escape
-characters, is to avoid data movement.  The sender may simply add a
-header and a trailer to the 'i' protocol packet.  Once the receiver
-has loaded the 'j' protocol packet, it may scan the index bytes,
-transforming the data bytes, and then pass the data bytes directly on
-to the 'i' protocol routine.
-
-------------------------------
-
-From: UUCP-x
-Subject: What is the 'x' protocol?
-
-The 'x' protocol is used in Europe (and probably elsewhere) with
-machines that contain an builtin X.25 card and can send eight bit data
-transparently across X.25 circuits, without interference from the X.28
-or X.29 layers.  The protocol sends packets of 512 bytes, and relies
-on a write of zero bytes being read as zero bytes without stopping
-communication.  It first appeared in the original System V UUCP
-implementation.
-
-------------------------------
-
-From: UUCP-y
-Subject: What is the 'y' protocol?
-
-The 'y' protocol was developed by Jorge Cwik for use in FX UUCICO, a
-PC uucico program.  It is designed for communication lines which
-handle error correction and flow control.  It is a streaming protocol,
-like the 'f' protocol.  It requires an eight bit clean connection.  It
-performs error detection, but not error correction; when an error is
-detected, the line is dropped.  I do not know the implementation
-details.
-
-------------------------------
-
-From: UUCP-d
-Subject: What is the 'd' protocol?
-
-This is apparently used for DataKit muxhost (not RS-232) connections.
-No file size is sent.  When a file has been completely transferred, a
-write of zero bytes is done; this must be read as zero bytes on the
-other end.
-
-------------------------------
-
-From: UUCP-h
-Subject: What is the 'h' protocol?
-
-This is apparently used in some places with HST modems.  It does no
-error checking, and is not that different from the 't' protocol.  I
-don't know the details.
-
-------------------------------
-
-From: UUCP-v
-Subject: What is the 'v' protocol?
-
-The 'v' protocol is used by UUPC/extended, a PC UUCP program.  It is
-simply a version of the 'g' protocol which supports packets of any
-size, and also supports sending packets of different sizes during the
-same conversation.  There are many 'g' protocol implementations which
-support both, but there are also many which do not.  Using 'v' ensures
-that everything is supported.
-
-------------------------------
-
-From: Thanks
-Subject: Thanks
-
-Besides the papers and information acknowledged at the top of this
-article, the following people have contributed help, advice,
-suggestions and information:
-    Earle Ake 513-429-6500 <ake@Dayton.SAIC.COM>
-    cambler@nike.calpoly.edu (Christopher J. Ambler)
-    jhc@iscp.bellcore.com (Jonathan Clark)
-    jorge@laser.satlink.net (Jorge Cwik)
-    celit!billd@UCSD.EDU (Bill Davidson)
-    "Drew Derbyshire" <ahd@kew.com>
-    erik@pdnfido.fidonet.org
-    Matthew Farwell <dylan@ibmpcug.co.uk>
-    dgilbert@gamiga.guelphnet.dweomer.org (David Gilbert)
-    kherron@ms.uky.edu (Kenneth Herron)
-    Mike Ipatow <mip@fido.itc.e-burg.su>
-    Romain Kang <romain@pyramid.com>
-    "Jonathan I. Kamens" <jik@GZA.COM>
-    "David J. MacKenzie" <djm@eng.umd.edu>
-    jum@helios.de (Jens-Uwe Mager)
-    peter@xpoint.ruessel.sub.org (Peter Mandrella)
-    david nugent <david@csource.oz.au>
-    Stephen.Page@prg.oxford.ac.uk
-    joey@tessi.UUCP (Joey Pruett)
-    James Revell <revell@uunet.uu.net>
-    Larry Rosenman <ler@lerami.lerctr.org>
-    Rich Salz <rsalz@bbn.com>
-    evesg@etlrips.etl.go.jp (Gjoen Stein)
-    kls@ditka.Chicago.COM (Karl Swartz)
-    Dima Volodin <dvv@hq.demos.su>
-    jon@console.ais.org (Jon Zeeff)
-    Eric Ziegast <ziegast@uunet.uu.net>
-
-------------------------------
-
-End of UUCP Internals Frequently Asked Questions
-******************************
--- 
-Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
-``You don't have to sleep.  That's just something *they* tell you to keep
-  *control* over you.  Nobody has to sleep; you're *taught* to sleep when
-  you're a kid.  If you're really determined, you can get over it.''
diff --git a/share/FAQ/ctm.FAQ b/share/FAQ/ctm.FAQ
deleted file mode 100644
index 60f7010..0000000
--- a/share/FAQ/ctm.FAQ
+++ /dev/null
@@ -1,191 +0,0 @@
-# ----------------------------------------------------------------------------
-# "THE BEER-WARE LICENSE" (Revision 42):
-# <phk@login.dknet.dk> wrote this file.  As long as you retain this notice you
-# can do whatever you want with this stuff. If we meet some day, and you think
-# this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
-# ----------------------------------------------------------------------------
-#
-# $Id: ctm.FAQ,v 1.5 1995/03/05 23:13:08 roberto Exp $
-#
-
-		Obtaining FreeBSD-current sources using CTM.
-		============================================
-
-CTM is a method for keeping a remote directory tree in sync with a
-central one.  It has been developed for usage with FreeBSD's source
-trees, though other people may find it useful for other purposes as
-time goes by.  Little, if any, documentation currently exists at this
-time on the process of creating deltas so talk to phk@FreeBSD.org for
-more information should you wish to use CTM for other things.
-
-
-Why should I use CTM ?
-----------------------
-CTM will give you a local copy of the "FreeBSD-current" sources.  If
-you are an active developer on FreeBSD, but have lousy or non-existent
-TCP/IP connectivity, CTM was made for you.  You will need to transfer
-up to four deltas per day (or you can have them arrive in email
-automatically), the sizes for which are always kept as small as
-possible.  This is typically less than 5K, with the occasional (one in
-ten) being 10-50K and every now and then a biggie of 100K+ or more
-coming around.
-
-You will also need to make yourself aware of the various caveats in
-running "current" sources, and for this it is recommended that you
-refer to the relevant FAQ: /usr/share/FAQ/current-policy.FAQ
-
-
-What do I need to use CTM?
---------------------------
-
-You will need two things: The "ctm" program and the initial deltas to
-feed it (to get up to "current" levels).
-
-The ctm program is in the FreeBSD-current tree from version 2.0.0 and
-forward (/usr/src/usr.sbin/ctm).  If you are running an older version
-of FreeBSD, you can fetch the current ctm sources directly from:
-
-	ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/
-
-The "deltas" you feed ctm can be had two ways, ftp or email.  If you
-have general ftp access to the Internet, then the following ftp sites
-support access to CTM:
-
-	ftp://freefall.cdrom.com/pub/CTM
-
-Ftp the the relevant directory and fetch the README file, starting
-from there.
-
-If you only have access to electronic mail or are otherwise blocked
-from using ftp, then you may wish to receive your deltas via email:
-
-Send email to majordomo@freebsd.org to subscribe to the list
-"ctm-src-cur" (if you do not know how to subscribe yourself using
-majordomo, send a message first containing the word `help' - it will
-send you back usage instructions).
-
-When you begin receiving your CTM updates in the mail, you may use the
-ctm_rmail program to unpack and apply them with.  You can actually use
-the ctm_rmail program directly from a entry in /etc/aliases if you
-want.  Check the "ctm_rmail" man page for more details.
-
-NOTE:
------
-
-No matter what method you use to get the CTM deltas, you should subscribe
-to the ctm-announce@freebsd.org mailing list.  In the future this will be
-the only place where announcements about the operation of the CTM system
-will be posted.  Send an email to majordomo@freebsd.org with a single
-line of "subscribe ctm-announce" to get added to the list.
-
-
-Starting off with CTM for the first time:
------------------------------------------
-
-Before you can start using CTM deltas, you will need to get a special
-"base" delta that provides a starting point for all deltas produced
-subsequently to it.
-
-You can recognize a base delta by the 'A' appended to the number
-(src-cur.0341A.gz for instance).  As a rule a base delta is produced
-every 100 deltas, the next one will be src-cur.0400A.gz.
-By the way,  they are large!  25 to 30 Megabytes of gzip'ed data is
-common for a base delta.
-
-If you do have the 2.0-RELEASE srcdist, you can instead retreive the
-src-cur.0372R20.gz file, it's only 4Mb and it will take you to current
-from the 2.0-RELEASE sources.
-
-Once you've picked a base delta to start from, you will also need all 
-deltas with higher numbers following it.
-
-
-Using CTM in your daily life:
------------------------------
-
-To apply the deltas, simply say
-
-	cd /where/ever/you/want/the/stuff
-	ctm -v -v /where/you/store/your/deltas/src-cur.*
-
-CTM understands deltas which have been put through gzip, so you don't
-need to gunzip them first, this saves diskspace.
-
-Unless it feels very secure about the entire process, ctm will not
-touch your tree.  To check out a delta you can also use the "-c" flag
-and CTM won't actually touch your tree, but only check the integrity
-of the delta, and see if it would apply cleanly to the tree.
-
-There are other options to ctm as well, look in the sources.
-
-I would also be very happy if somebody could help with the "user
-interface" portions, as I have realized that I can't make up my mind
-on what options should do what, how and when...
-
-That's really all there is to it.  Everytime you get a new delta, you
-run it through ctm.
-
-Don't remove the deltas, if they are hard to download again.  You just
-might want to keep them around in case something bad happens.  Even if
-you only have floppy disks, consider using "fdwrite" to make a copy.
-
-
-Plans:
-------
-
-Tons of them:
-
- - Make local modifications to the tree possible.  One way to do it
-     could be this:
-     When CTM wants to edit the file "foo/bar.c", it would first check
-     for the existense of "foo/bar.c#ctm"  If this file exists, the
-     delta is applied to it instead.  This way the foo/bar.c file can
-     be edited to suit local needs.
- - Make a "restore file(s)" option to ctm, something like:
-	ctm -r src/sys/i386/wd.c /here/are/my/deltas/src-cur.*
-     would restore wd.c to the current status from the files.
- - Clean up the options to ctm, they became confusing and 
-     counter intuitive.
-
-The bad news is that I am very busy, so any help in doing this will be
-most welcome.  And don't forget to tell me what you want also...
-
-
-Misc. stuff:
-------------
-
-All the "DES infected" (e.g. export controlled) source is not included.
-You will get the "international" version only.  If sufficient interest
-appears, we will set up a "sec-cur" sequence too.
-
-If you are a frequent or valuable contributor to FreeBSD, I will be
-willing to arrange special services, one option is delivery via ftp or
-rcp to a machine closer to you.  You need to have earned this, since
-it takes time to do, but I'll be all the more happy to do it for you
-then.
-
-There is a sequence of deltas for the ports collection too, but interest
-has not been all that high yet.  Tell me if you want an email list for
-that too and we'll consider setting it up.
-
-If you have commit priviledges or are similary authorized by the
-FreeBSD core team, you can also get access to the CVS repository tree
-by the same means.  Contact me (phk@FreeBSD.org) for details.
-
-
-Thanks!
--------
-
-Bruce Evans, for his pointed pen and invaluable comments.
-Soren Schmidt, for patience.
-Stephen McKay, wrote ctm_[rs]mail, much appreciated.
-Jordan Hubbard, for being so stubborn that I had to make it better.
-All the users,  I hope you like it...
-
-Comments ?
-----------
-
-email phk@FreeBSD.org
-
-
-Poul-Henning
diff --git a/share/FAQ/current-policy.FAQ b/share/FAQ/current-policy.FAQ
deleted file mode 100644
index 4d9e86b..0000000
--- a/share/FAQ/current-policy.FAQ
+++ /dev/null
@@ -1,170 +0,0 @@
-                        THE FREEBSD CURRENT POLICY 
-
-Last updated: $Date: 1994/10/03 03:48:39 $
-
-This document attempts to explain the rationale behind FreeBSD-current,
-what you should expect should you decide to run it, and states some
-prerequisites for making sure the process goes as smoothly as possible.
-
-
-1.  What is FreeBSD-current?
-
-FreeBSD-current is, quite literally, nothing more than a daily snapshot of
-the working sources for FreeBSD.  These include work in progress, experimental
-changes, and transitional mechanisms that may or may not be present in
-the next official release of the software.  While many of us compile
-almost daily from FreeBSD-current sources, there are periods of time when
-the sources are literally uncompilable.  These problems are generally resolved
-as expeditiously as possible, but whether or not FreeBSD-current sources bring
-disaster or greatly desired functionality can literally be a matter of which
-part of any given 24 hour period you grabbed them in!  Please read on..
-
-Under certain circumstances we will sometimes make binaries for parts of
-FreeBSD-current available, but only because we're interested in getting
-something tested, not because we're in the business of providing binary
-releases of current.  If we don't offer, please don't ask!  It takes far
-too much time to do this as a general task.
-
-
-2. Who needs FreeBSD-current?
-
-FreeBSD-current is made generally available for 3 primary interest groups:
-
-    1.  Members of the FreeBSD group who are actively working on one
-        part or another of the source tree and for whom keeping `current'
-        is an absolute requirement.
-
-    2.  Members of the FreeBSD group who are active ALPHA/BETA testers
-        and willing to spend time working through problems in order to
-        ensure that FreeBSD-current remains as sane as possible.  These
-        are also people who wish to make topical suggestions on changes
-        and the general direction of FreeBSD.
-
-    3.  Peripheral members of the FreeBSD (or some other) group who merely
-        wish to keep an eye on things and use the current sources for
-        reference purposes (e.g. for *reading*, not running).  These
-        people also make the occasional comment or contribute code.
-
-
-3. What is FreeBSD-current _NOT_?
-
-    1.  A fast-track to getting pre-release bits because there's something
-        you heard was pretty cool in there and you want to be the first on
-        your block to have it.
-
-    2.  A quick way of getting bug fixes.
-
-    3.  In any way "officially supported" by us.
-
-        We do our best to help people genuinely in one of the 3
-        "legitimate" FreeBSD-current catagories, but we simply DO NOT
-        HAVE THE TIME to help every person who jumps into FreeBSD-current
-        with more enthusiasm than knowledge of how to deal with
-        experimental system software.  This is not because we're mean and
-        nasty people who don't like helping people out (we wouldn't even be
-        doing FreeBSD if we were), it's literally because we can't answer
-        400 messages a day AND actually work on FreeBSD!  I'm sure if
-        given the choice between having us answer lots of questions or
-        continue to improve FreeBSD, most of you would vote for us
-        improving it (and so would we! :-).
-
-
-4.  Ok.  I still think I "qualify" for FreeBSD-current, so what do I do?
-
-    1.  Join the freebsd-hackers and freebsd-commit mailing lists.
-        This is not just a good idea, it's ESSENTIAL.  If you aren't on
-        freebsd-hackers, you won't read the comments that people are
-        making about the current state of the system and thus will end
-        up stumbling over a lot of problems that others have already
-        found and solved.  Even more importantly, you will miss out on
-        potentially critical information (e.g. "Yo, Everybody!  Before you
-        rebuild /usr/src, you MUST rebuild the kernel or your system
-        will crash horribly!").
-
-        The freebsd-commit list will allow you to see the commit log
-        entry for each change as its made.  This can also contain
-        important information, and will let you know what parts of the
-        system are being actively changed.
-
-        To join these lists, send mail to `majordomo@FreeBSD.ORG'
-        and say:
-
-            subscribe freebsd-hackers
-            subscribe freebsd-commit
-
-        In the body of your message.  Optionally, you can also say `help'
-        and MajorDomo will send you full help on how to subscribe and
-        unsubscribe to the various other mailing lists we support.
-
-    2.  Grab the sources from ftp.FreeBSD.ORG.  You can do this in
-        three ways:
-
-	1.  Using the CTM facility.  Read the ctm.FAQ file for more
-	    information.  Unless you have a good TCP/IP connection at
-	    a flat rate, this is the way to do it.
-
-        2.  Use the CMU `sup' program (Software Update Protocol).
-            This is the second most recommended method, since it allows 
-	    you to grab the entire collection once and then only what's
-            changed from then on.  Many people run sup from cron
-            and keep their sources up-to-date automatically.
-
-	    The problem is that sup does not use the bandwidth efficient,
-	    unless the round-trip is very fast.  If the cost of connection
-	    or the duration of the session is a concern, use CTM.
-
-            To get a binary of the sup program for FreeBSD, as well
-            as the documentation and some sample configuration files,
-            look in:
-
-            FreeBSD.ORG:~ftp/pub/sup
-
-        3.  Use ftp.  The source tree for FreeBSD-current is always
-            "exported" on:
-
-             ftp.FreeBSD.ORG:~ftp/pub/FreeBSD/FreeBSD-current
-
-            We use `wu-ftpd' which allows compressed/tar'd grabbing
-            of whole trees.  e.g. you see:
-
-            usr.bin/lex
-
-            You can do:
-
-            ftp> cd usr.bin
-            ftp> get lex.tar.Z
-
-            And it will get the whole directory for you as a compressed
-            tar file.
-
-    3.  If you're grabbing the sources to run, and not just look at,
-	then grab ALL of current, not just selected portions.  The
-	reason for this is that various parts of the source depend on
-	updates elsewhere and trying to compile just a subset is almost
-	guaranteed to get you into trouble.
-
-    4.  Before compiling current, read the Makefile in /usr/src
-	carefully.  You'll see one-time targets like `bootstrapld'
-	which *MUST* be run as part of the upgrading process.  Reading
-	freebsd-hackers will keep you up-to-date on other bootstrapping
-	procedures that sometimes become necessary as we move towards
-	the next release.
-
-    5.  Be active!  If you're running FreeBSD-current, we want to know
-	what you have to say about it, especially if you have suggestions
-	for enhancements or bug fixes.  Suggestions with accompanying code
-	are received most enthusiastically! :-)
-
-
-Thank you for taking the time to read this all the way through.  We're
-always very keen to remain "open" and share the fruits of our labor
-with the widest possible audience, but sharing development sources has
-always had certain pitfalls associated with it (which is why most
-commercial organizations won't even consider it) and I want to make
-sure that people at least come into this with their eyes open, and
-don't make the leap unless they're good at working without a net!
-
-                                    Jordan
-
-
-
diff --git a/share/FAQ/diskspace.FAQ b/share/FAQ/diskspace.FAQ
deleted file mode 100644
index 31346df..0000000
--- a/share/FAQ/diskspace.FAQ
+++ /dev/null
@@ -1,267 +0,0 @@
-                    How to assign disk space to FreeBSD.
-
-$Id$
-
-1.0  Getting started.
----------------------
-
-After a general introduction, you will find some explanation on what you
-need to do to assign space to FreeBSD on your disk(s).  This is done
-through the "sysinstall" program, which lives on the inital boot floppy.
-Those already expert with PCs may wish to skip ahead to section 1.2, the
-rest of you may (or may not) enjoy the brief history lesson.
-
-
-1.1  The ins and outs of allocating disk storage on your PC.
-------------------------------------------------------------
-
-Modern hard disk drives are now getting big enough that people don't want
-to allocate all of one to just one operating system anymore, especially
-given the increasing size of disk drives (the latest 9.0 Gbyte models
-holding the equivalent of some six thousand 1.44MB floppies!) and the
-virtual explosion of operating system options available for the PC.  To
-solve this problem, IBM came up with a scheme for "slicing" the disks
-into more manageable chunks, or partitions.  It works, but only just.
-To better understand why, first a brief bit of history:
-
-MS-DOS, when hard disk support was unceremoniously grafted on back in the
-late eighties, didn't have such "slices".  What it had was a way to install
-Xenix and MS-DOS on the same disk (Remember when Microsoft were in the UNIX
-business?).
-
-In the first sector on the disk was a piece of "primary boot code" and a
-table with four entries.  Each of those entries pointed at an arbitrary
-slice of the disk, with one of them was marked "active".  The machine would
-boot by reading the first sector containing the boot code into RAM and then
-jumping to it.  The job of this small piece of boot code was to look at
-the 4 entry table and decide which OS was to be booted by looking
-for the "active" flag.   It would go and load the first sector of that slice
-of the disk into RAM and then and jump to it in turn.  This bit of boot
-code was called the "secondary boot", and could be specific to a given
-operating system.  The primary boot code and 4-entry table is known
-as the Master Boot Record, or MBR, and is very important to the proper
-operation of your PC!  We will discuss the MBR in more detail later.
-
-It was later realized, with the hindsight that IBM is famous for, that disks
-could be bigger than the 32Mb that the early DOS FAT-12 file system could
-handle, so they added a kludge:  They had two MSDOS slices, a "Primary" and
-a "Secondary".  The primary could still only be 32Mb, but the Secondary had
-no size limit.  And the trick was that the secondary had ANOTHER "table
-entry" so that now suddenly up to 5 slices could be available to MS-DOS.
-The Secondary boot record was later made recursive, thus effectively
-avoiding any fixed limit.  Of course, they were still stuck with a maximum
-of 26 slices given the use of "drive letters" in DOS.  They also reserved
-only 10 bits for cylinder addressing, limiting DOS to being able to address
-a maximum of 1024 cylinders (and cause of the dreaded "cylinder translation"
-kludges, the misconfiguration of which many users have seen as the notorious
-"Missing Operating System" message).  Yes, truly DOS was and is an utterly
-terrible operating system, which of course explains its amazing degree of
-success.  Anyway, this all brings us up to today, which is where FreeBSD
-comes in:
-
-
-1.2  What FreeBSD does
-----------------------
-FreeBSD has, like any other UNIX-like operating system, the concept of
-"partitions."  Partitions are used to implement its own "slicing"
-abstraction, and although there is no real difference between a slice and a
-partition as such, we use the two words to distinguish between these two
-different levels of slicing.
-
-The result is that we have a two-tier structure on the disk:
-
-+-----------+
-| MBR-table |
-+-----------+        +---------+
-| Slice 1   | -----> |  MSDOS  |
-+-----------+        +---------+
-| Slice 2   | 
-+-----------+        +-------------------+
-| Slice 3   | -----> | FreeBSD-disklabel |
-+-----------+        +-------------------+        +-----------------+
-| Slice 4   |        |    Partition A    | -----> | Root-filesystem |
-+-----------+        +-------------------+        +-----------------+
-                     |    Partition B    | ---
-                     +-------------------+    \    +----------------+
-                     |    Partition C    |     --> | swap-partition |
-                     +-------------------+         +----------------+
-                     |  ...              |
-
-
-Here are the rules that FreeBSD plays by:
-
-A:  FreeBSD always has an MBR slice with type 0xa5 (each of the 4 slices can
-    also have a unique integer identifier so you can tell your DOS slices
-    from your FreeBSD slices from your Linux slices, etc).  This means that
-    there should always be an MBR record, even in the case where FreeBSD
-    occupies the entire disk.
-B:  The FreeBSD slice contains the FreeBSD disklabel in the second sector
-    (remember, the first sector contains the secondary boot code for FreeBSD,
-     which is what prints that FreeBSD prompt at you when you first boot
-     FreeBSD from a floppy or hard disk).
-C:  The 'C' partition in the FreeBSD disklabel corresponds to the entire
-    FreeBSD slice.
-D:  The 'D' partition corresponds to the entire physical disk.
-E:  Should a disk not have a FreeBSD slice (because there simply is no 
-    FreeBSD on it anywhere), then the MBR slices are mapped into partitions
-    'E' to 'H' of an artificially created FreeBSD disklabel.  This is useful
-    for getting at DOS-only disks.
-
-Therefore, to get FreeBSD onto your disk, you need to do the following:
-
-  Step                                                          FreeBSD utility
-  ------------------------------------------------------------  ---------------
-  1.  Make an MBR slice for FreeBSD                             (FDISK)
-  2.  Partition the diskspace in the MBR slice into partitions  (DISKLABEL)
-  3.  Assign mountpoints to the partitions.                     (DISKLABEL)
-
-
-
-2.  The sysinstall utility
---------------------------
-
-The sysinstall utility is the program you first see when you boot
-FreeBSD's install floppy.  It is responsible for partitioning your
-disk, creating an MBR slice for FreeBSD, setting up the disklabel
-within that slice and creating filesystems for each FreeBSD partition
-you create within that slice.  It is composed of a number of screens.
-These are described below.
-
-
-2.1  The main screen
---------------------
-The main screen shows you the current status,  It shows you which disks
-FreeBSD has found, how big they are and how much of it is assigned to 
-FreeBSD in a FreeBSD MBR slice.  It also shows the partitions which have
-had a mountpoint assigned to them (not necessarily FreeBSD partitions; 
-FreeBSD is perfectly capable of mounting DOS disks directly).
-
-(H)elp  -- shows you this file.
-
-(F)disk -- enters the Fdisk editor, where you can change the MBR record.
- This is what you want to use to assign some part of the disk to FreeBSD.
-
-(D)isklabel -- enters the Disklabel editor, here you can change how the
- FreeBSD slice is partitioned for FreeBSD.
-
-(P)rocede -- will continue the installation process.
-
-(Q)uit -- Go back to the entry screen.
-
-
-2.2  FDISK - how to make an MBR slice
--------------------------------------
-There are some rules to follow here since altering your MBR is a potential
-minefield.  There is really no way for the sysinstall program to genuinely
-know that you have a valid MBR, so you have to be extra careful in what
-you edit.  Failure to do this properly can and will destroy your other
-operating system entries!
-
-Even if you don't plan to have MSDOS on a disk, make an MSDOS slice
-using the MSDOS's FDISK.COM program.  The reason for this is that if you
-do it that way, you are 100% sure that FreeBSD will use the same number
-of heads, sectors and cylinders as MSDOS would use.  If you really don't
-plan to have MSDOS on the disk, just (D)elete the slice in the FreeBSD's
-(F)disk editor.
-
-From the main screen press 'F' to enter the MBR editor.  You have five
-commands available:
-
-(H)elp -- Shows you this file.
-
-(D)elete -- Deletes a slice entirely.
-
-(E)dit -- Allows you to edit a slice.  It will ask how many megabytes
-  you want to assign to the slice, and will suggest the maximum possible
-  as a default.  It might say zero, even though there is disk space
-  available, in which case you will probably need to delete and recreate the
-  other partitions to get it to see where the free space is.
-  It will then ask you what type to give the slice, for which the default is
-  0xa5 (a FreeBSD slice).  You can enter any other number here too, which
-  can be useful as a placeholder for some other OS you plan to install
-  later.  Finally, it will ask you about the "boot flag".  0x80 means "boot
-  from this" slice by default, and anything else means "don't".
-
-  If you specified a FreeBSD slice, any existing slices with the 0xa5 
-  type will be reset to 0x00 "unused".  FreeBSD only supports one slice
-  per disk for FreeBSD.
-
-(R)eread -- This is your "undo" function.  It will read the data of the
-  disk again, disposing of any changes you may have made.
-
-(W)rite -- When you are satisfied with the data, this function will write
-  the new MBR to the disk.
-
-(Q)uit -- Go back to the main screen.
-
-
-2.3  Disklabel - How to divide up the FreeBSD slice.
-----------------------------------------------------
-
-The disklabel screen provides the following commands:
-
-(H)elp -- Shows you this file.
-
-(S)ize -- Resizes a partition for you, it will suggest as a default the
-   maximum amount of diskspace it can find.  This algorithm isn't too smart
-   and may say zero, even though there is diskspace available.  If it
-   does, delete and resize the other partitions.
-
-(A)ssign -- Here you assign where the filesystem in a partition is to
-   be mounted.  `b' partitions will always be made into "swap" partitions.
-
-(D)elete -- Delete a partition.
-
-(R)eread -- The undo function.  It will reread the current disklabel from
-   the kernel.
-
-(W)rite -- This will write the disklabel to the disk.  You must always write
-   before you quit, otherwise your changes will be lost.
-
-(Q)uit -- Exit back to the main screen.
-
-
-2.4.  Hints on partition sizing
--------------------------------
-
-While it's impossible to say how much space you're going to want to
-make your various partitions without knowing more about your intended
-applicatins, here are some good rules of thumb to follow:
-
-1. Root (/) should be at least 18MB, and probably no more than 50MB unless
-   you have some special reason for making your root partition really
-   large.  Remember that the root filesystem is only supposed to contain
-   vital system files and little else.
-
-2. Swap should be at least 2*memory.  That is to say if you have 8MB of
-   memory, then you probably want 16MB of swap.  Even more swap space
-   certainly doesn't hurt, if you can afford to allocate it, and you should
-   also think ahead a little to any planned memory upgrades you may have
-   in mind since increasing this later can be very painful!
-
-   If you're going to run the X Window System (XFree86), you should also
-   consider having a *minimum* of 16MB of swap, since X tends to really
-   use it up.
-
-3. /usr can take up the rest of your disk, though some people like to create
-   extra partitions for user home directories and the like.  Be sure to make
-   your /usr big enough to contain the system software (about 50MB) and
-   perhaps some of your own, unless you're going to use symbolic links to
-   point things like /usr/local (or /usr/src) somewhere else.
-
-
-Here are some suggested filesystem names and sizes, just for reference:
-
-Mountpoint	Filesystem size
--------------------------------
-/var		10Mb
-/usr		50Mb
-/		16Mb
-
-/usr/src       120Mb    If you want to have the sources online
-/usr/obj       100Mb    If you want to compile all of them at one time
-
-/usr/X11R6	50Mb	If you load the entire XFree86 binary kit.
-
-
-$Id: diskspace.FAQ,v 1.1 1995/01/03 15:48:36 gclarkii Exp $
diff --git a/share/FAQ/extras/ports-supfile b/share/FAQ/extras/ports-supfile
deleted file mode 100644
index ffc078b..0000000
--- a/share/FAQ/extras/ports-supfile
+++ /dev/null
@@ -1,26 +0,0 @@
-ports-base release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-archivers release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-benchmarks release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-audio release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-cad release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-comms release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-databases release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-devel release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-editors release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-emulators release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-games release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-graphics release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-japanese release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-lang release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-mail release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-math release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-net release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-news release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-plan9 release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-print release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-russian release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old
-ports-security release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-shells release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-sysutils release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-utils release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-x11 release=current host=SUP.FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
diff --git a/share/FAQ/extras/secure-stable-supfile b/share/FAQ/extras/secure-stable-supfile
deleted file mode 100644
index 61ac7f0..0000000
--- a/share/FAQ/extras/secure-stable-supfile
+++ /dev/null
@@ -1,2 +0,0 @@
-eBones release=stable host=sup.internat.freebsd.org hostbase=/home base=/usr prefix=/usr/src delete old compress
-secure release=stable host=sup.internat.freebsd.org hostbase=/home base=/usr prefix=/usr/src delete old compress
diff --git a/share/FAQ/extras/secure-supfile b/share/FAQ/extras/secure-supfile
deleted file mode 100644
index 716f70c..0000000
--- a/share/FAQ/extras/secure-supfile
+++ /dev/null
@@ -1,2 +0,0 @@
-eBones release=current host=sup.internat.freebsd.org hostbase=/home base=/usr prefix=/usr/src delete old compress
-secure release=current host=sup.internat.freebsd.org hostbase=/home base=/usr prefix=/usr/src delete old compress
diff --git a/share/FAQ/extras/stable-supfile b/share/FAQ/extras/stable-supfile
deleted file mode 100644
index 5ba1db8..0000000
--- a/share/FAQ/extras/stable-supfile
+++ /dev/null
@@ -1,15 +0,0 @@
-src-base release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-bin release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-#src-eBones release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-etc release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-games release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-gnu release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-include release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-lib release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-libexec release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-sbin release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-#src-secure release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-share release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-sys release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-usrbin release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-usrsbin release=stable host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
diff --git a/share/FAQ/extras/standard-supfile b/share/FAQ/extras/standard-supfile
deleted file mode 100644
index 6d0ed19..0000000
--- a/share/FAQ/extras/standard-supfile
+++ /dev/null
@@ -1,15 +0,0 @@
-src-base release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-bin release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-#src-eBones release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-etc release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-games release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-gnu release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-include release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-lib release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-libexec release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-sbin release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-#src-secure release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-share release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-sys release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-usrbin release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
-src-usrsbin release=current host=sup.FreeBSD.org hostbase=/home base=/usr prefix=/usr/src delete old use-rel-suffix
diff --git a/share/FAQ/help.html b/share/FAQ/help.html
deleted file mode 100644
index 4bbc1a2..0000000
--- a/share/FAQ/help.html
+++ /dev/null
@@ -1,15 +0,0 @@
-<!-- $Id:$ -->
-
-<!DOCTYPE html PUBLIC '-//IETF//DTD HTML 2.0//EN'>
-<html>
-  <head>
-    <title>Using FreeBSD Help</title>
-  </head>
-  <body>
-  <h1>Using FreeBSD Help</h1>
-
-<p>...stay tuned...
-
-  </body>
-</html>
-
diff --git a/share/FAQ/index.html b/share/FAQ/index.html
deleted file mode 100644
index 291ed90..0000000
--- a/share/FAQ/index.html
+++ /dev/null
@@ -1,40 +0,0 @@
-<!-- $Id: index.html,v 1.1 1995/04/06 15:56:10 jfieber Exp $ -->
-
-<!DOCTYPE html PUBLIC '-//IETF//DTD HTML 2.0//EN'>
-<html>
-  <head>
-    <title>FreeBSD Documentation</title>
-  </head>
-  <body>
-  <h1>FreeBSD Documentation</h1>
-
-    <ul>
-      <li><a href="help.html">How to use help</a></li>
-    </ul>
-
-    <p></p>
-
-    <ul>
-      <li><a href="HTML/userman.html">User Guide</a></li>
-      <li><a href="HTML/adminman.html">Administrators Guide</a></li>
-      <li><a href="HTML/refman.html">Reference Manual</a></li>
-    </ul>
-
-    <p></p>
-
-    <ul>
-      <li><a href="tutorials.html">Tutorials</a></li>
-      <li><a href="HTML/freebsd-faq.html">Frequently Asked
-	  Questions with answers</a></li>
-      <li><a href="http://www.freebsd.org/">Internet Resources</a></li>
-    </ul>
-
-    <p></p>
-
-    <ul>
-      <li><a href="HTML/infosources.html">For more information...</a></li>
-    </ul>
-
-  </body>
-</html>
-
diff --git a/share/FAQ/kerberos_setup.latex b/share/FAQ/kerberos_setup.latex
deleted file mode 100644
index fa2e81e..0000000
--- a/share/FAQ/kerberos_setup.latex
+++ /dev/null
@@ -1,326 +0,0 @@
-%% \documentstyle[11pt,a4]{article}
-\documentstyle[11pt]{article}
-%% \pagestyle{headings}
-%% \pagestyle{empty}
-\setlength{\textwidth}{6.5in}
-\setlength{\parindent}{0in}
-%% \setlength{\parskip}{\medskipamount}
-\setlength{\oddsidemargin}{0in}
-\setlength{\evensidemargin}{0in}
-%% \setlength{\footskip}{0.2cm}
-\begin{document}
-
-\begin{center}
-{\LARGE {\bf Configuring Kerberos IV on 4.4 BSD}} \\
-{\it Mark Dapoz} \\
-{\it $<$md@bsc.no$>$} \\
-{\it Bergen Scientific Centre} \\
-{\it Bergen, Norway} \\
-{\it April 4th, 1994} \\
-\end{center}
-
-\section{Introduction}
-
-The following instructions can be used as a quick guide on how to set up
-kerberos as distributed in 4.4 BSD.  However, you should refer to the
-original Athena documentation for a complete description.
-
-
-\section{Creating the initial database}
-
-First make sure that you don't have any old kerberos databases around.  You
-should change to the directory {\bf /etc/kerberosIV} and check that only the
-following files are present:
-
-\begin{verbatim}
-mideon# cd /etc/kerberosIV
-mideon# ls
-README          krb.conf        krb.realms      register_keys
-\end{verbatim}
-
-If any additional files (such as principal.dir) exist, then use the
-{\bf kdb\_destroy} command to destroy the old kerberos database.\\
-
-You should now edit the {\bf krb.conf} and {\bf krb.realms} files to define
-your kerberos realm.  In this case the realm will be {\it BSC.NO} and
-the server is {\it mideon.bsc.no}.  We would edit the {\bf krb.conf}
-file to be as follows:
-
-\begin{verbatim}
-mideon# cat krb.conf
-BSC.NO
-BSC.NO mideon.bsc.no admin server
-CS.BERKELEY.EDU okeeffe.berkeley.edu
-ATHENA.MIT.EDU kerberos.mit.edu
-ATHENA.MIT.EDU kerberos-1.mit.edu
-ATHENA.MIT.EDU kerberos-2.mit.edu
-ATHENA.MIT.EDU kerberos-3.mit.edu
-LCS.MIT.EDU kerberos.lcs.mit.edu
-TELECOM.MIT.EDU bitsy.mit.edu
-ARC.NASA.GOV trident.arc.nasa.gov
-\end{verbatim}
-
-Now we have to add mideon.bsc.no to the BSC.NO realm and also add an entry
-to put all hosts in the .bsc.no domain in the BSC.NO realm.  The 
-{\bf krb.realms} file would be updated as follows:
-
-\begin{verbatim}
-mideon# cat krb.realms
-mideon.bsc.no   BSC.NO
-.bsc.no         BSC.NO
-.berkeley.edu   CS.BERKELEY.EDU
-.MIT.EDU        ATHENA.MIT.EDU
-.mit.edu        ATHENA.MIT.EDU
-\end{verbatim}
-
-Now we're ready to create the database, issue the {\bf kdb\_init} command
-to do this:
-
-\begin{verbatim}
-mideon# kdb_init
-Realm name [default  CS.BERKELEY.EDU ]: BSC.NO
-You will be prompted for the database Master Password.
-It is important that you NOT FORGET this password.
-
-Enter Kerberos master key: 
-\end{verbatim}
-
-Now we have to save the key so that servers on the local machine can pick
-it up.  Use the {\bf kstash} command to do this.
-
-\begin{verbatim}
-mideon# kstash
-
-Enter Kerberos master key: 
-
-Current Kerberos master key version is 1.
-
-Master key entered.  BEWARE!
-\end{verbatim}
-
-\section{Populating the database}
-
-We now have to add some entries into the database.  First lets create an
-entry for the user {\it md}.  Use the {\bf kdb\_edit} command to do this:
-
-\begin{verbatim}
-mideon# kdb_edit
-Opening database...
-
-Enter Kerberos master key: 
-
-Current Kerberos master key version is 1.
-
-Master key entered.  BEWARE!
-Previous or default values are in [brackets] ,
-enter return to leave the same, or new value.
-
-Principal name: md
-Instance: 
-md. not found, Create [y] ? 
-Principal: md, Instance: , kdc_key_ver: 1
-New Password: 
-New Password: 
-
-Principal's new key version = 1
-Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? 
-Max ticket lifetime (*5 minutes) [ 255 ] ? 100
-Attributes [ 0 ] ? 
-Edit O.K.
-\end{verbatim}
-
-Now lets add an entry for the password changing daemon, kpasswd.  The
-principal name must be {\it kpasswd} and the instance must be the name of
-the local machine, {\it mideon} in this case.  Similarily, we must also add
-an entry for the principal {\it rcmd} with an instance equal to the
-hostname of the local machine.
-
-\begin{verbatim}
-Principal name: kpasswd
-Instance: mideon
-kpasswd.mideon not found, Create [y] ? 
-Principal: kpasswd, Instance: mideon, kdc_key_ver: 1
-New Password:                   <---- enter RANDOM here
-New Password:                   <---- and here
-Random password [y] ? 
-
-Principal's new key version = 1
-Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? 
-Max ticket lifetime (*5 minutes) [ 255 ] ? 
-Attributes [ 0 ] ? 
-Edit O.K.
-Principal name: rcmd
-Instance: mideon
-rcmd.mideon not found, Create [y] ? 
-Principal: rcmd, Instance: mideon, kdc_key_ver: 1
-New Password:                   <---- enter RANDOM here
-New Password:                   <---- and here
-Random password [y] ? 
-
-Principal's new key version = 1
-Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? 
-Max ticket lifetime (*5 minutes) [ 255 ] ? 
-Attributes [ 0 ] ? 
-Edit O.K.
-Principal name:                 <---- null entry here will cause an exit
-\end{verbatim}
-
-\section{Creating the server file}
-
-We now have to extract all the instances which define the services on this
-machine.  For this we use the {\bf ext\_srvtab} command.
-
-\begin{verbatim}
-mideon# ext_srvtab mideon
-
-Enter Kerberos master key: 
-
-Current Kerberos master key version is 1.
-
-Master key entered.  BEWARE!
-Generating 'mideon-new-srvtab'....
-\end{verbatim}
-
-Now, this command only generates a temporary file which must be renamed
-to {\bf srvtab} so that all the server can pick it up.  Use the mv command to
-move it into place:
-
-\begin{verbatim}
-mideon# mv mideon-new-srvtab srvtab
-\end{verbatim}
-
-\section{Testing it all out}
-
-First we have to start the kerberos daemon:
-
-\begin{verbatim}
-mideon# kerberos &
-[1] 774
-mideon# Kerberos server starting
-        Sleep forever on error
-        Log file is /var/log/kerberos.log
-Current Kerberos master key version is 1.
-
-Master key entered.  BEWARE!
-
-Current Kerberos master key version is 1
-Local realm: BSC.NO
-\end{verbatim}
-
-Now we can try using the {\bf kinit} command to get tokens for the id 
-{\it md} that we created above:
-
-\begin{verbatim}
-mideon# kinit md
-Kerberos Initialization for "md"
-Kerberos Password: 
-\end{verbatim}
-
-Try listing the tokens using {\bf klist} to see if we really have them:
-
-\begin{verbatim}
-mideon# klist
-Ticket file:    /tmp/tkt0
-Principal:      md@BSC.NO
-
-  Issued           Expires          Principal
-Mar 23 21:06:52  Mar 24 05:06:52  krbtgt.BSC.NO@BSC.NO
-\end{verbatim}
-
-And now try changing the password using {\bf passwd} to check if the 
-kpasswd daemon can get authorisation to the kerberos database:
-
-\begin{verbatim}
-mideon# passwd md
-Changing Kerberos password for md.@BSC.NO.
-Old Kerberos password:
-New Kerberos password:
-Retype new Kerberos password:
-Update complete.
-\end{verbatim}
-
-\section{Adding su priviledges}
-
-We should now add an id which is authorised to su to root.  This is
-controlled by having an instance of {\it root} associated with a principal.
-Using {\bf kdb\_edit} we can create the entry {\it md.root} in the kerberos
-database:
-
-\begin{verbatim}
-mideon# kdb_edit
-Opening database...
-
-Enter Kerberos master key: 
-
-Current Kerberos master key version is 1.
-
-Master key entered.  BEWARE!
-Previous or default values are in [brackets] ,
-enter return to leave the same, or new value.
-
-Principal name: md
-Instance: root
-md.admin not found, Create [y] ? 
-Principal: md, Instance: admin, kdc_key_ver: 1
-New Password: 
-New Password: 
-
-Principal's new key version = 1
-Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? 
-Max ticket lifetime (*5 minutes) [ 255 ] ? 12
-Attributes [ 0 ] ? 
-Edit O.K.
-Principal name: 
-\end{verbatim}
-
-Now try getting tokens for it to make sure it works:
-
-\begin{verbatim}
-mideon# kinit md.root
-Kerberos Initialization for "md.root"
-Kerberos Password: 
-\end{verbatim}
-
-And list them to check expiry times:
-
-\begin{verbatim}
-mideon# klist
-Ticket file:    /tmp/tkt0
-Principal:      md.root@BSC.NO
-
-  Issued           Expires          Principal
-Mar 23 21:08:47  Mar 23 22:08:47  krbtgt.BSC.NO@BSC.NO
-mideon# 
-\end{verbatim}
-
-Now we need to add the user to root's {\bf .klogin} file:
-
-\begin{verbatim}
-mideon# cat /root/.klogin
-md.root@BSC.NO
-\end{verbatim}
-
-Now try doing the su:
-
-\begin{verbatim}
-[md@mideon.bsc.no 10407] su
-Kerberos Password: 
-Warning: tgt not verified.
-\end{verbatim}
-
-and take a look at what tokens we have:
-
-\begin{verbatim}
-mideon# klist
-Ticket file:    /tmp/tkt_root_1250
-Principal:      md.root@BSC.NO
-
-  Issued           Expires          Principal
-Mar 23 22:09:59  Mar 23 22:19:59  krbtgt.BSC.NO@BSC.NO
-mideon# 
-\end{verbatim}
-
-Notice that with this setup each user has their own entry for su'ing to
-root (the {\it user}.root entry in kerberos).  This can allow you to give root
-access to multiple users without the need to share a common root password.
-\end{document}
diff --git a/share/FAQ/kernel-debug.FAQ b/share/FAQ/kernel-debug.FAQ
deleted file mode 100644
index 3ccdf60..0000000
--- a/share/FAQ/kernel-debug.FAQ
+++ /dev/null
@@ -1,417 +0,0 @@
-                   Kernel debugging FAQ for FreeBSD
-
-$Id: kernel-debug.FAQ,v 1.3 1995/01/02 12:01:59 joerg Exp $
-
-
-*** Debugging a kernel crash dump with kgdb ***
-
-  Here are some instructions for getting kernel debugging working on a
-  crash dump, it assumes that you have enough swap space for a crash
-  dump.  If you happen to have multiple swap partitions with the first
-  one being too small to keep the dump, you can configure your kernel to
-  use an alternate dump device (in the ``kernel'' line).  Dumps to non-
-  swap devices (e.g. tapes) are currently not supported.
-
-  Config your kernel using config -g
-
-  Remember that you need to specify ``options DODUMP'' in your config
-  file in order to get kernel core dumps.
-
-  When the kernel's been built make a copy of it, say kernel.debug, and
-  then run strip -x on the original. Install the original as normal.
-  You may also install the unstripped kernel, but symtab lookup time
-  for some programs might drastically increase.
-
-  If you are testing a new kernel (e.g. by typing the new kernel's
-  name at the boot prompt), but need to boot a different one in order
-  to get your system up & running again, do boot it only into single
-  user state (the -s flag at the boot prompt), and then perform the
-  following steps:
-
-  fsck -p
-  mount -a -t ufs       # so your file system for /var/crash is writable
-  savecore -N /kernel.panicked /var/crash
-  exit                  # ...to multi-user
-
-  This instructs savecore to use another kernel for symbol name
-  extraction; it would default to the currently running kernel
-  otherwise.
-
-  Now, after a crash dump, go to /sys/compile/WHATEVER and run
-  kgdb. From kgdb do:
-
-  symbol-file kernel.debug
-  exec-file /var/crash/system.0
-  core-file /var/crash/ram.0
-
-  and voila, you can debug the crash dump using the kernel sources
-  just like you can for any other program.
-
-  If your kernel panicked due to a trap (perhaps the most common case
-  for getting a core dump), the following trick might help you.  Examine
-  the stack (`where') and look for the stack frame in the function
-  trap().  Go `up' to that frame, and then type:
-
-  frame frame->tf_ebp frame->tf_eip
-
-  This will tell kgdb to go to the stack frame explicitly named by a
-  frame pointer and instruction pointer, which is the location where
-  the trap occured.  There are still some bugs in kgdb (you can go
-  `up' from there, but not `down'; the stack trace will still remain
-  as it was before going to here), but generally this method will lead
-  you much closer to the failing piece of code.
-
-  Here's a script log of a kgdb session illustrating the above.  Long
-  lines have been folded to improve readability, and the lines are
-  numbered for reference.  Despite of this, it's a real-world error
-  trace taken during the development of the pcvt console driver.
-
-   1:Script started on Fri Dec 30 23:15:22 1994
-   2:uriah # cd /sys/compile/URIAH
-   3:uriah # kgdb kernel /var/crash/vmcore.1 
-   4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done.
-   5:IdlePTD 1f3000
-   6:panic: because you said to!
-   7:current pcb at 1e3f70
-   8:Reading in symbols for ../../i386/i386/machdep.c...done.
-   9:(kgdb) where
-  10:#0  boot (arghowto=256) (../../i386/i386/machdep.c line 767)
-  11:#1  0xf0115159 in panic ()
-  12:#2  0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698)
-  13:#3  0xf010185e in db_fncall ()
-  14:#4  0xf0101586 in db_command (-266509132, -266509516, -267381073)
-  15:#5  0xf0101711 in db_command_loop ()
-  16:#6  0xf01040a0 in db_trap ()
-  17:#7  0xf0192976 in kdb_trap (12, 0, -272630436, -266743723)
-  18:#8  0xf019d2eb in trap_fatal (...)
-  19:#9  0xf019ce60 in trap_pfault (...)
-  20:#10 0xf019cb2f in trap (...)
-  21:#11 0xf01932a1 in exception:calltrap ()
-  22:#12 0xf0191503 in cnopen (...)
-  23:#13 0xf0132c34 in spec_open ()
-  24:#14 0xf012d014 in vn_open ()
-  25:#15 0xf012a183 in open ()
-  26:#16 0xf019d4eb in syscall (...)
-  27:(kgdb) up 10
-  28:Reading in symbols for ../../i386/i386/trap.c...done.
-  29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\
-  30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\
-  31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\
-  32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\
-  33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\
-  34:ss = -266427884}) (../../i386/i386/trap.c line 283)
-  35:283                             (void) trap_pfault(&frame, FALSE);
-  36:(kgdb) frame frame->tf_ebp frame->tf_eip
-  37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done.
-  38:#0  0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\
-  39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403)
-  40:403             return ((*linesw[tp->t_line].l_open)(dev, tp));
-  41:(kgdb) list
-  42:398        
-  43:399             tp->t_state |= TS_CARR_ON;
-  44:400             tp->t_cflag |= CLOCAL;  /* cannot be a modem (:-) */
-  45:401     
-  46:402     #if PCVT_NETBSD || (PCVT_FREEBSD >= 200)
-  47:403             return ((*linesw[tp->t_line].l_open)(dev, tp));
-  48:404     #else
-  49:405             return ((*linesw[tp->t_line].l_open)(dev, tp, flag));
-  50:406     #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */
-  51:407     }
-  52:(kgdb) print tp
-  53:Reading in symbols for ../../i386/i386/cons.c...done.
-  54:$1 = (struct tty *) 0x1bae
-  55:(kgdb) print tp->t_line
-  56:$2 = 1767990816
-  57:(kgdb) up
-  58:#1  0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\
-  59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126)
-  60:       return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p));
-  61:(kgdb) up
-  62:#2  0xf0132c34 in spec_open ()
-  63:(kgdb) up
-  64:#3  0xf012d014 in vn_open ()
-  65:(kgdb) up
-  66:#4  0xf012a183 in open ()
-  67:(kgdb) up
-  68:#5  0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\
-  69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\
-  70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \
-  71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \
-  72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673)
-  73:673             error = (*callp->sy_call)(p, args, rval);
-  74:(kgdb) up
-  75:Initial frame selected; you cannot go up.
-  76:(kgdb) quit
-  77:uriah # exit
-  78:exit
-  79:
-  80:Script done on Fri Dec 30 23:18:04 1994
-
-  Comments to the above script:
-  
-  line  6:  this is a dump taken from within DDB (see below), hence the
-            panic comment ``because you said to!'', and a rather long
-            stack trace; the initial reason for going into DDB has been
-            a page fault trap though
-  
-  line 20:  the location of function ``trap()'' in the stack trace
-  
-  line 36:  force usage of a new stack frame, kgdb responds and displays
-            the source line where the trap happened; from looking at the
-            code, there's a high probability that either the pointer
-            access for ``tp'' was messed up, or the array access was
-            out of bounds
-  
-  line 52:  the pointer looks suspicious, but happens to be a valid
-            address...
-  
-  line 56:  ... but obviously points to garbage, so we have found our
-            error, sigh!  [For those uncommon with that particular piece
-            of code: tp->t_line refers to the line discipline of the
-            console device here, which must be a rather small integer
-            number.]
-  
-
-
-*** Post-mortem analysis of a dump ***
-
-  What to do if a kernel dumped core but you didn't expect it, and it's
-  therefore not compiled using config -g?
-
-  Not everything is lost here.  Don't panic. :-)
-
-  Of course, you still need to configure all your kernels with the
-  DODUMP option being set, otherwise you won't get a core dump at all.
-  (This is for safety reasons in the default kernels, to avoid them
-  trying to dump e.g. during system installation where there's no
-  FreeBSD partition at all and valuable data on the disk could be
-  destroyed.)
-
-  Go to your kernel compile directory, and edit the line containing
-  COPTFLAGS?=-O.  Add the `-g' option there (but DON'T change anything
-  on the level of optimization).  If you do already know roughly the
-  probable location of the failing piece of code (e.g., the `pcvt'
-  driver in the example above), remove all the object files for this
-  code.  Rebuild the kernel. Due to the time stamp change on the
-  Makefile, there will be some other object files rebuild, e.g.
-  trap.o.  With a bit of luck, the added -g option won't change
-  anything for the generated code, so you'll finally get a new kernel
-  with similiar code to the faulting one but some debugging symbols.
-  You should at least verify the old and new sizes with the `size'
-  command; if they mismatch, you probably need to give up here.
-
-  Go and examine the dump as described above.  The debugging symbols
-  might be incomplete for some places (as can be seen in the stack trace
-  in the example above: some functions are displayed without line
-  numbers and argument lists).  If you need more debugging symbols,
-  remove the appropriate object files and repeat the kgdb session until
-  you know enough.
-
-  All this is not guaranteed to work, but most likely will do it fine.
-
-
-
-*** On-line kernel debugging using DDB ***
-
-  While kgdb as an offline debugger provides a very high level of user
-  interface (e.g. it can lookup source files, display C structures
-  etc.), there are some things it cannot do.  The most important ones
-  being breakpointing and single-stepping kernel code.
-
-  If you need to do low-level debugging on your kernel, there's an on-
-  line debugger available called DDB.  It allows to set breakpoints,
-  single-step kernel functions, examine and change kernel variables
-  etc.  It can however not access kernel source files, and it does
-  only have access to the global and static symbols, but not to the
-  full debug information (including type and line number information)
-  like kgdb.
-
-  To configure your kernel to include DDB, add the option lines
-
-        options DDB
-        options "SYMTAB_SPACE=XXXX"
-
-  to your config file, and rebuild.  XXXX is the amount of space to be
-  reserved into a global array DDB examines to find its symbols at run
-  time.  It must be large enough to hold all symbols, but not too
-  large at all to avoid wasting space.  100000 Bytes are a good first
-  bet for a ``normal'' kernel.  The link stage will tell you about the
-  usage of the symtab space, you'll see something like:
-
-  dbsym: need 98765; avail 100000
-
-  If the amount of allocated space has been too small, the above
-  message is accompanied by the following error message:
-
-  not enough room in db_symtab array
-
-  and the link stage fails.  You then need to increase the number,
-  reconfig and recompile.  If your config(8) has been compiled to not
-  remove the old compile directory before continuing (this is a
-  compile-time option [CONFIG_DONT_CLOBBER]), you need to remove
-  db_aout.o prior to recompilation; this is the only file being
-  affected by the SYMTAB_SPACE option.
-
-
-  Once your DDB kernel is running, there are several ways to enter
-  DDB.  The first (and most early) way is to set the boot flag `-d'
-  (right at the boot prompt).  The kernel will start up in debug mode
-  and enter DDB prior to any device probing.  Hence you are able to
-  even debug the device probe/attach functions.
-
-  The second scenario is a hot-key on the keyboard, usually Ctrl-Alt-
-  ESC.  (For syscons, this can be remapped, and some of the
-  distributed maps do this, so watch out.)  There are patches
-  available for a COMCONSOLE kernel, ask me (joerg@FreeBSD.org) for
-  them.
-
-  The third way is that any panic condition will branch to DDB if the
-  kernel is configured to use it.  (Thus it is not wise to configure a
-  kernel with DDB for a machine running unattended.)
-
-
-  The DDB commands roughly resemble some gdb commands.  The first you
-  probably need is to set a breakpoint:
-
-  b function-name
-  b address
-
-  Numbers are taken hexadecimal by default, but to make them distinct
-  from symbol names, hex numbers starting with the letters `a' - `f'
-  need to be preceded with `0x' (for other numbers, this is optional).
-  Simple expressions are allowed, e.g. ``function-name + 0x103''.
-
-  To continue the operation of an interrupted kernel, simply type
-
-  c
-
-  To get a stack trace, use
-
-  trace
-
-  Note that when entering DDB via a hot-key, the kernel is currently
-  servicing an interrupt, so the stack trace might be not of much use
-  for you.
-
-  If you want to remove a breakpoint, use
-
-  del
-  del address-expression
-
-  The first form will be accepted immediately after a breakpoint hit,
-  and deletes the current breakpoint.  The second form can remove any
-  breakpoint, but you need to specify the exact address, as it can be
-  obtained from
-
-  show b
-
-  To single-step the kernel, try
-
-  s
-
-  This will step into functions, but you can make DDB trace them until
-  the matching return statement is reached by
-
-  n
-
-  NOTE: this is different from gdb's ``next'' statement, it's like
-  gdb's ``finish''.
-
-  To examine data from memory, use e.g.
-
-  x/wx 0xf0133fe0,40
-  x/hd db_symtab_space
-  x/bc termbuf,10
-  x/s stringbuf
-
-  for word/halfword/byte access, and hexadecimal/decimal/character/
-  string display.  The number after the comma is the object count.
-  To display the next 0x10 items, simply use
-
-  x ,10
-
-  Similiarly, use
-
-  x/ia foofunc,10
-
-  to disassemble the first 0x10 instructions of foofunc, and display
-  them along with their offset from the beginning of foofunc.
-
-  To modify the memory, use the write command:
-
-  w/b termbuf 0xa 0xb 0
-  w/w 0xf0010030 0 0
-
-  The command modifier (b/h/w) specifies the size of the data to be
-  writtten, the first following expression is the address to write to,
-  the remainder is interpreted as data to write to successive memory
-  locations.
-
-  If you need to know the current registers, use
-
-  show reg
-
-  Alternatively, you can display a single register value by e.g.
-
-  print $eax
-
-  and modify it by
-
-  set $eax new-value
-
-
-  Should you need to call some kernel functions from DDB, simply
-  say
-
-  call func(arg1, arg2, ...)
-
-  The return value will be printed.
-
-  For a ps-style summary of all running processes, use
-
-  ps
-
-
-
-  Well, you've now examined why your kernel failed, and you wish to
-  reboot.  Remember that, depending on the severity of previous
-  malfunctioning, not all parts of the kernel might still be working
-  as expected.  Perform one of the following actions to shut down and
-  reboot your system:
-
-
-  call diediedie()
-
-  (must usually be followed by another ``c[ontinue]'' statement),
-  will cause your kernel to dump core and reboot, so you can later
-  analyze the core on a higher level with kgdb.
-
-
-  call boot(0)
-
-  might be a good way to cleanly shut down the running system, sync()
-  all disks, and finally reboot.  As long as the disk and file system
-  interfaces of the kernel are not damaged, this might be a good way
-  for an almost clean shutdown.
-
-
-  call cpu_reset()
-
-  ...is the final way out of the desaster, almost similiar to hitting
-  the Big Red Button.
-
-
-
-*** What to do if i want to debug a console driver? ***
-
-  Since you need a console driver to run DDB on, things are more
-  complicated if the console driver itself is flakey.  You might
-  remember the ``options COMCONSOLE'' line, and hook up a standard
-  terminal onto your first serial port.  DDB works on any configured
-  console driver, of course it also works on a COMCONSOLE.
-
-
-
-  Paul Richards, FreeBSD core team member. (paul@FreeBSD.org)
-  J"org Wunsch (joerg@FreeBSD.org)
-
diff --git a/share/FAQ/mailing-list.FAQ b/share/FAQ/mailing-list.FAQ
deleted file mode 100644
index 74e231b..0000000
--- a/share/FAQ/mailing-list.FAQ
+++ /dev/null
@@ -1,105 +0,0 @@
-                     THE FREEBSD MAILING LIST FAQ 
-
-$Id: mailing-list.FAQ,v 1.4 1994/10/10 10:39:10 gclarkii Exp $
-
---
-Though many of the FreeBSD development members read USENET, we cannot
-always guarantee that we'll get to your questions in a timely fashion
-(or at all) if you post them only to one of the comp.os.386bsd.*
-groups.  By addressing your questions to the appropriate mailing list
-you will reach both us and a concentrated FreeBSD audience, invariably
-assuring a better (or at least faster) response.
-
-The following is a summary of the mailing lists:  
-
-List                            Purpose
------------------------------------------------------------------------------
-freebsd-admim                   Administrative issues (limited)
-freebsd-arch                    Architecture and design discussions (limited)
-freebsd-bugs                    Bug reports
-freebsd-hackers                 Technical discussions and suggestions
-freebsd-questions               User questions
-freebsd-announce                Important events / milestones
-freebsd-current                 Discussions about the use of FreeBSD-current
-freebsd-commit			Commit messages to source repository
-freebsd-core			FreeBSD core team (limited)
-freebsd-security                Security issues
-freebsd-fs                      Filesystems
-freebsd-ports                   Discussion of "ports"
-freebsd-platforms               Porting to Non-Intel platforms
-freebsd-hardware                General discussion of FreeBSD hardware
-freebsd-install                 Installation issues (limited)
-
------------------------------------------------------------------------------
-
-The following lists are for people seeing the log messages for source changes 
-in specific areas:
-
-List name	Source area		Area Description (source for)
------------------------------------------------------------------------------
-cvs-CVSROOT	/usr/src/[A-Z]*		Top level /usr/src file changes
-cvs-all		/usr/src		All changes to the tree (superset)
-cvs-bin		/usr/src/bin		System binaries
-cvs-etc		/usr/src/etc		System files
-cvs-games	/usr/src/games		Games
-cvs-gnu		/usr/src/gnu		GPL'd utilities
-cvs-include	/usr/src/include	Include files
-cvs-kerberosIV	/usr/src/kerberosIV	Kerberos encryption code
-cvs-lib		/usr/src/lib		System libraries
-cvs-libexec	/usr/src/libexec	System binaries
-cvs-sbin	/usr/src/sbin		System binaries
-cvs-share	/usr/src/share		System shared files
-cvs-sys		/usr/src/sys		Kernel
-cvs-usrbin	/usr/src/usr.bin	Use binaries
-cvs-usrsbin	/usr/src/usr.sbin	System binaries
-cvs-ports	/usr/ports		Ported software
------------------------------------------------------------------------------
-
-Even though the lists freebsd-core, freebsd-admin, freebsd-install and 
-freebsd-arch are closed, anyone is free to send suggestions and comments
-to them.  All other lists are open.
-
-All mailing lists live on `FreeBSD.ORG', so to post to a list you
-simply mail to `<listname>@FreeBSD.ORG'.  It will then be redistributed
-to mailing list members throughout the world.
-
-To subscribe to a list, send mail to:
-
-                      majordomo@FreeBSD.ORG
-
-And include the keyword
-
-                subscribe <listname> [<optional address>]
-
-In the body of your message.  For example, to subscribe yourself to
-freebsd-hackers, you'd do:
-
-                % mail majordomo@FreeBSD.ORG
-                subscribe freebsd-hackers
-                ^D
-
-If you want to subscribe yourself under a different name, or submit a
-subscription request for a local mailing list (note: this is more efficient
-if you have several interested parties at one site, and highly appreciated by
-us!), you would do something like:
-
-                % mail majordomo@FreeBSD.ORG
-                subscribe freebsd-hackers local-hackers@somesite.com
-                ^D
-
-Finally, it is also possible to unsubscribe yourself from a list, get a
-list of other list members or see the list of mailing lists again by
-sending other types of control messages to majordomo.  For a complete
-list of available commands, do this:
-
-                % mail majordomo@FreeBSD.ORG
-                help
-                ^D
-
-Finally, it is suggested that you only join the freebsd-hackers or
-freebsd-questions mailing lists if you're also willing to see upwards
-of 100 messages a day (peak)!  If you're only interested in the "high points",
-then it's suggested that you join freebsd-announce, which will contain
-only infrequent traffic.
-
-                                Thank you!
diff --git a/share/FAQ/nfs.FAQ b/share/FAQ/nfs.FAQ
deleted file mode 100644
index 047b25a..0000000
--- a/share/FAQ/nfs.FAQ
+++ /dev/null
@@ -1,79 +0,0 @@
-FreeBSD and NFS [for a FAQ]
-
-$Id$
-
-Certain Ethernet adapters for ISA PC systems have limitations which
-can lead to serious network problems, particularly with NFS.  This
-difficulty is not specific to FreeBSD, but FreeBSD systems are affected
-by it.
-
-The problem nearly always occurs when (FreeBSD) PC systems are networked
-with high-performance workstations, such as those made by Silicon Graphics,
-Inc., and Sun Microsystems, Inc.  The NFS mount will work fine, and some
-operations may succeed, but suddenly the server will seem to become
-unresponsive to the client, even though requests to and from other systems
-continue to be processed.  This happens to the client system, whether the
-client is the FreeBSD system or the workstation.  On many systems, there is
-no way to shut down the client gracefully once this problem has manifested
-itself.  The only solution is often to reset the client, because the NFS
-situation cannot be resolved.
-
-Though the "correct" solution is to get a higher performance and capacity
-Ethernet adapter for the FreeBSD system, there is a simple workaround that
-will allow satisfactory operation.  If the FreeBSD system is the SERVER,
-include the option "wsize=1024" on the mount from the client.  If the
-FreeBSD system is the CLIENT, then mount the NFS file system with the
-option "rsize=1024".  These options may be specified using the fourth
-field of the fstab entry on the client for automatic mounts, or by using
-the "-o" parameter of the mount command for manual mounts.
-
-In the following examples, "fastws" is the host (interface) name of a
-high-performance workstation, and "freebox" is the host (interface) name of
-a FreeBSD system with a lower-performance Ethernet adapter.  Also,
-"/sharedfs" will be the exported NFS filesystem (see "man exports"), and
-"/project" will be the mount point on the client for the exported file
-system.  In all cases, note that additional options, such as "hard" or
-"soft" and "bg" may be desireable in your application.
-
-Examples for the FreeBSD system ("freebox") as the client:
-    in /etc/fstab on freebox:
-fastws:/sharedfs /project nfs rw,rsize=1024 0 0
-    as a manual mount command on freebox:
-mount -t nfs -o rsize=1024 fastws:/sharedfs /project
-
-Examples for the FreeBSD system as the server:
-    in /etc/fstab on fastws:
-freebox:/sharedfs /project nfs rw,wsize=1024 0 0
-    as a manual mount command on fastws:
-mount -t nfs -o wsize=1024 freebox:/sharedfs /project
-
-Nearly any 16-bit Ethernet adapter will allow operation without the above
-restrictions on the read or write size.
-
-For anyone who cares, here is what happens when the failure occurs, which
-also explains why it is unrecoverable.  NFS typically works with a "block"
-size of 8k (though it may do fragments of smaller sizes).  Since the maximum
-Ethernet packet is around 1500 bytes, the NFS "block" gets split into
-multiple Ethernet packets, even though it is still a single unit to the
-upper-level code, and must be received, assembled, and ACKNOWLEDGED as a
-unit.  The high-performance workstations can pump out the packets which
-comprise the NFS unit one right after the other, just as close together as
-the standard allows.  On the smaller, lower capacity cards, the later
-packets overrun the earlier packets of the same unit before they can be
-transferred to the host and the unit as a whole cannot be reconstructed or
-acknowledged.  As a result, the workstation will time out and try again,
-but it will try again with the entire 8K unit, and the process will be
-repeated, ad infinitum.
-
-By keeping the unit size below the Ethernet packet size limitation, we
-ensure that any complete Ethernet packet received can be acknowledged
-individually, avoiding the deadlock situation.
-
-Overruns may still occur when a high-performance workstations is slamming
-data out to a PC system, but with the better cards, such overruns are
-not guarranteed on NFS "units".  When an overrun occurs, the units affected
-will be retransmitted, and there will be a fair chance that they will be
-received, assembled, and acknowledged.
--- 
-		   John Lind, Starfire Consulting Services
-E-mail: john@starfire.MN.ORG		USnail: PO Box 17247, Mpls MN  55417
diff --git a/share/FAQ/ports-supfile b/share/FAQ/ports-supfile
deleted file mode 100644
index 8a9b29c..0000000
--- a/share/FAQ/ports-supfile
+++ /dev/null
@@ -1,7 +0,0 @@
-ports-editors release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-lang release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-mail release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-net release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-shells release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-utils release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
-ports-x11 release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/ports delete old 
diff --git a/share/FAQ/ports.FAQ b/share/FAQ/ports.FAQ
deleted file mode 100644
index 485a265..0000000
--- a/share/FAQ/ports.FAQ
+++ /dev/null
@@ -1,246 +0,0 @@
-			The FreeBSD Ports FAQ file
-
-Revision: $Id: ports.FAQ,v 1.1 1995/01/05 07:27:00 gclarkii Exp $
-
-The ports system is kinda new, so there haven't been too many FAQ's to
-date, but hopefully this document will pre-empt (some|most) of them!!
-The ports system is constantly changing, but hopefully this document
-will be kept reasonably up to date (and you never know, it might even
-make sense!).
-
-					- Gary Palmer
-					& jkh
-
-1) What is a port?
-
-    Unfortunately, there are more variations of UN*X than most people
-know of, and hence not all software for UN*X available on the Internet
-will work on all versions of UN*X (in fact, I can guarantee it!).
-Hence, some software needs modifications to work under some UN*Xs. The
-process of making those modifications is known as ``porting'' and the
-result known as a ``port'' (not to be confused with the sockets on the
-back of your computer!).
-
-
-2) What is the FreeBSD Ports Collection?
-
-    People who (allegedly) know what they are doing have automated the
-process of ``porting'' software to FreeBSD, and the result is the
-Ports Collection.  The general idea is that a combination of various
-programming tools available in the base FreeBSD installation will
-allow you to fetch the port from a FreeBSD mirror site, type ``make''
-and get the fully working program.
-
-    The ports collection itself normally doesn't have any of the
-original source code necessary for the compilation in the tree, just
-those shell scripts, Makefiles and source code ``diffs'' that are
-necessary to compile the program under FreeBSD.  This is meant to keep
-the entire system down to a manageable size, and the current system
-has over 100 ports in the master source tree, and yet a compressed tar
-file of that tree is about 2 megabytes (all the source code needed is
-over 100Mb's!).
-
-
-3) How does the system compile with no source code?
-
-    A ports' Makefile automatically looks in a central location on
-your system (usually /usr/ports/distfiles, though this value can be
-customized) for the associated set of original distribution files that
-have been ``ported''.  These are generally provided at various places
-on the Internet, though if you have a CDROM distribution of FreeBSD
-then you've already got them available on your CD for ease of use.
-See section 3.1 if you have such a CD distribution, otherwise skip to
-section 3.2.
-
-3.1  Compiling ports from CD
-
-    Type something profound here.
-
-3.2  Compiling ports using an Internet connection
-
-    The ports collection can also use an auto-fetch system to keep
-your ports collection source tree up to date, updating the central
-``distfiles'' version for you the next time you compile the port.
-
-    Of course, this always assumes you have a permanent network link,
-or don't mind heavy usage of your telephone.  If you don't want heavy
-network usage when you compile your ports tree, you can pre-fetch the
-necessary tarballs beforehand and put them into /usr/ports/distfiles
-(or wherever DISTDIR points) by hand.  A good way to see what files a
-port is going to need is to cd to that port's directory and do a
-``make -n fetch'' to see what it does.
-
-    You can also chose to get the source files either from the master
-FTP site as defined in the relevant Makefile (in the MASTER_SITES
-line), or some FreeBSD mirror site also carrying a set of distfiles,
-as does the master FTP site on ftp.FreeBSD.org (aka ftp.cdrom.com) in
-the directory /pub/FreeBSD/ports/distfiles.  Note that the files in
-that directory are not guarenteed to be kept up to date - this is a
-volunteer project!  We can't make any guarantees about the mirror
-sites either - they are obviously under independant control and don't
-even have to mirror the distfiles directory.
-
-    If you have a non-permanant link, you can fetch all the distfiles by
-going to the top of the tree and typing ``make fetch''.
-
-
-4) It doesn't work?!
-
-Oh. You can do one of four (4) things :
-
-a) Fix it yourself. Technical details can be found in the GUIDELINES file,
-   available from URL ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/GUIDELINES
-
-b) Gripe. This is done by e-mail *ONLY*! The people at Walnut Creek are
-   in no way responsible for the functionality (or lack thereof) of the
-   FreeBSD system as a whole, and especially the ports system, which
-   is mainly contributed by 3rd parties. (If you don't believe me, check
-   the catalogue, especially the line saying "We cannot offer tech-support
-   on this product")
-
-   The e-mail address is Ports@FreeBSD.org.  Please include details of
-   the port, where you got both the port source & distfile(s) from, and
-   what the error was.
-
-   Note: At time of writing, lang/Sather doesn't seem to work on Pentium
-   machines due to the Intel Curse (aka the Floating Point Division Bug).
-   Please don't tell us about this - gripe to Intel instead - it's their
-   bug!
-
-c) Forget it. This is the easiest for most - very few of the programs in
-   ports can be classed as `essential'!
-
-d) Grab the pre-compiled package from a ftp server. The ``master'' package
-   collection is in:
-	   ftp://ftp.FreeBSD.org/pub/FreeBSD/packages/
-
-   though check your local mirror first, please!
-
-   These are more likely to work (on the whole) than trying to compile from
-   source, and a lot faster!
-
-
-5) I've ported a program and I want to make a port out of it. What now?
-
-   See the file GUIDELINES, in:
-	   ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/GUIDELINES
-
-   This contains details of the procedure and structure involved.
-
-
-6) I've got a good port, what now?
-
-   Upload the fixed version to freefall.cdrom.com /pub/incoming or
-ftp.FreeBSD.org /pub/FreeBSD/incoming and send e-mail to
-ports@FreeBSD.org with the filename and details.  Someone on the
-all-volunteer `ports committee' will (hopefully) look it over and
-commit it to the ports collection if they like the looks of it.
-
-
-7) Things go funny during the fetch stage of compilation!
-
-   We know.  Please don't blame us. There is a program called `ncftp'
-which is used instead of the normal ftp as it can do so-called
-``background'' or ``batch'' transfers, ideal for this situation.
-Unfortunately it can do strange things, and has crashed at least one
-machine (during circumstances stranger than most, I'll admit, but it
-was still responsible). Hopefully a future release of ncftp will fix
-these problems (it is not maintained by the main FreeBSD team, but a
-third party, who is I believe aware of its shortcomings)
-
-
-8) I want to leave the compile going overnight, but some ports don't
-   like this.
-
-   There is a way around this. Before starting the compilation, type:
-	setenv BATCH yes # (if you use csh/tcsh) or
-	BATCH=yes # (for sh/bash)
-
-    This should miss out ports which need user interaction. Unfortunately,
-ncftp doesn't know about this trick, and can often screw up and ask
-stupid questions in unattended batch mode. See (7).
-
-    To compile those ports left out by doing the above, using a
-different login shell (or unsetting the above BATCH variable), set the
-INTERACTIVE variable instead (you can use the same statements as above
-except replace ``BATCH'' with ``INTERACTIVE'') and re-run make. This
-should now compile only those ports which will definitely ask for user
-interaction.
-
-
-9) The ports collection is weak.  What can I do to help?
-
-    First read the bsd.port.mk file (which may be found in
-/usr/share/mk/) and the associated bsd.port.subdir.mk file. A lot of
-the weirdness can be explained properly in there (most of the current
-weirdness is due to the lack of assumptions about anything, which is
-necessary due to the generic nature of these files). Also check that
-you have an up-to-date copy, as the file can change from minute to
-minute.  A reasonably up-to-date copy can be found in:
-
-  ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/mk/bsd.port*
-
-    If you find that you still need to go in there and alter things,
-by all means do so, and then send the diffs to ports@FreeBSD.org if
-you'd like them to be a part of the default distribution.  Please also
-remember that any changes must respect backwards-compatability with
-any and all older Makefiles, unless you want a real nightmare of
-/usr/ports munging ahead of you!  Large scale changes will generally
-not be warmly welcomed unless all the existing makefiles work without
-alteration. Sorry!
-
-
-10) This FAQ is weak.  What can I do?
-
-    Send changes to ports@FreeBSD.org.  Changes are most welcome!
-This FAQ is also very green and should be considered no more than
-a `good start' for now.  Authors?  You can come out of hiding any
-time now! :-)
-
-
-11) How do I get more information on all the ports?
-
-    One good method is to cd to the top of the ports tree (say /usr/ports)
-and type something like:
-
-	make describe | sed -e '/===/D' -e 's;/usr/ports/;;' | expand -40
-
-The ``make describe'' will try to extract the one-line description from
-each port, and the ``sed'' will delete the extraneous output.  ``expand''
-just makes it a little more readable (sort of - you may want to season
-the output of this more to taste).
-
-
-12) I've heard of a new checksum system. What is this for?
-
-    For various reasons, when using FTP over the Internet to obtain the
-source code, you may not always end up with the same copy of the code
-that the origional porter worked from, and this can lead to problems.
-So a simple checksumming system has been employed to try and highlight
-problems in this area.
-
-    To check the entire system, go to the top of the ports tree
-(defaults to /usr/ports) and type
-
-	make checksum
-
-This will give a report on the validity of the files you have FTP'd. If some
-are missing, the system will attempt to retrieve them before running the
-checksum routine. The same technique can be applied to a single port.
-
-    The system will complain if there is no pre-computed checksum available
-for that port. Not all ports currently have checksums, but this should be
-cured soon.
-
-    Some older versions of the system don't recognise the ``checksum''
-target. In that case, try the command
-
-	make check-md5
-
-(``check-md5'' was the pre-cursor to the ``checksum'' target). If neither
-work, get the latest copies of bsd.port.mk and bsd.port.subdir.mk from
-
-   ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/mk/bsd.port*
-
-and install them in /usr/share/mk. This will get you the latest version
-of the ports system.
diff --git a/share/FAQ/ppp.FAQ b/share/FAQ/ppp.FAQ
deleted file mode 100755
index 0a6a980..0000000
--- a/share/FAQ/ppp.FAQ
+++ /dev/null
@@ -1,369 +0,0 @@
-         Info about setting up pppd daemon on FreeBSD-2.0
-
-$Id$
-
-Before you start setting up PPP on your machine make
-sure that pppd is located in /usr/sbin and directory /etc/ppp
-exists.
-
-pppd can work in two modes:
-
-i) as a "client" , i.e. you want to connect your machine to outside
-world via PPP serial connection or modem line.
-
-ii) as a "server" , i.e. your machine is located on the network and
-used to connect other computers using PPP.
-
-In both cases you will need to set up an options file ( /etc/ppp/options
-or ~/.ppprc if you have more then one user on your machine that uses
-PPP ).
-
-You also will need some modem/serial software ( preferably kermit )
-so you can dial and establish connection with remote host.
-
-1) Working as a PPP client
-
-I used the following options to connect to CISCO terminal server PPP
-line.
-
-----/etc/ppp/options-------
-crtscts		# enable hardware flow control
-modem		# modem control line
-noipdefault	# remote PPP server must supply your IP address.
-		# if the remote host doesn't send your IP during IPCP
-		# negotiation , remove this option
-passive		# wait for LCP packets
-domain ppp.foo.com	# put your domain name here
-
-:<remote_ip>	# put the IP of remote PPP host here
-		# it will be used to route packets via PPP link
-		# if you didn't specified the noipdefault option
-		# change this line to <local_ip>:<remote_ip>
-
-defaultroute	# put this if you want that PPP server will be your
-		# default router
--------------------------
-
-To connect:
-i) Dial to the remote host using kermit ( or other modem program )
-enter your user name and password ( or whatever is needed to enable PPP
-ont the remote host )
-
-ii) Exit kermit. ( without hanging up the line )
-
-iii) enter: 
-/usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200
-( put the appropriate speed and device name )
-
-Now your computer is connected with PPP. If the connection fails for some
-reasons you can add the "debug" option to the /etc/ppp/options file
-and check messages on the console to track the problem
-
-Following script will make all 3 stages automatically:
------/etc/ppp/pppup--------
-#!/bin/sh 
-ps ax |grep pppd |grep -v grep
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill ${pid}
-fi
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-
-ifconfig ppp0 down
-ifconfig ppp0 delete
-
-kermit -y /etc/ppp/kermit.dial
-pppd /dev/tty01 19200
------------------------------
-
-/etc/ppp/kermit.dial is kermit script that dials and makes all
-necessary authorization on the remote host.
-( Example of such script is attached to the end of this document )
-
-Use the follwing script to disconnect the PPP line:
------/etc/ppp/pppdown--------
-#!/bin/sh
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ X${pid} != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill -TERM ${pid}
-fi
-
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-
-/sbin/ifconfig ppp0 down
-/sbin/ifconfig ppp0 delete
-kermit -y /etc/ppp/kermit.hup 
-/etc/ppp/ppptest
-------------------------------
-
-Check if PPP is still running:
-
------/etc/ppp/ppptest---------
-#!/bin/sh
-pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'`
-if [ X${pid} != "X" ] ; then
-        echo 'pppd running: PID=' ${pid-NONE}
-else
-        echo 'No pppd running.'
-fi
-set -x
-netstat -n -I ppp0
-ifconfig ppp0
------------------------------
-
-Hangs up modem line:
-
------/etc/ppp/kermit.hup-----
-set line /dev/tty01	; put your modem device here
-set speed 19200
-set file type binary
-set file names literal
-set win 8
-set rec pack 1024
-set send pack 1024
-set block 3
-set term bytesize 8
-set command bytesize 8
-set flow none
-
-pau 1
-out +++
-inp 5 OK
-out ATH0\13
-echo \13
-exit
-----------------------------
-
-2) Working as a PPP server
-
-------/etc/ppp/options------
-crtscts				# Hardware flow control
-netmask 255.255.255.0		# netmask ( not required )
-192.114.208.20:192.114.208.165  # ip's of local and remote hosts
-				# local ip must be different from one
-				# you assigned to the ethernet ( or other )
-				# interface on your machine.
-				# remote IP is ip address that will be 
-				# assigned to the remote machine
-domain ppp.foo.com		# your domain
-passive				# wait for LCP
-modem				# modem line
-----------------------------
-
-Following script will enable ppp server on your machine
-
------/etc/ppp/pppserv-------
-#!/bin/sh 
-ps ax |grep pppd |grep -v grep
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill ${pid}
-fi
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-
-# reset ppp interface
-ifconfig ppp0 down
-ifconfig ppp0 delete
-
-# enable autoanswer mode
-kermit -y /etc/ppp/kermit.ans
-
-# run ppp
-pppd /dev/tty01 19200
-----------------------------
-
-Use this script to stop ppp server:
-
------/etc/ppp/pppservdown---
-#!/bin/sh 
-ps ax |grep pppd |grep -v grep
-pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing pppd, PID=' ${pid}
-        kill ${pid}
-fi
-ps ax |grep kermit |grep -v grep
-pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
-if [ "X${pid}" != "X" ] ; then
-        echo 'killing kermit, PID=' ${pid}
-        kill -9 ${pid}
-fi
-ifconfig ppp0 down
-ifconfig ppp0 delete
-
-kermit -y /etc/ppp/kermit.noans
-----------------------------
-
-Following kermit script will enable/disable autoanswer mode 
-on your modem:
-
------/etc/ppp/kermit.ans----
-set line /dev/tty01
-set speed 19200
-set file type binary
-set file names literal
-set win 8
-set rec pack 1024
-set send pack 1024
-set block 3
-set term bytesize 8
-set command bytesize 8
-set flow none
-
-pau 1
-out +++
-inp 5 OK
-out ATH0\13
-inp 5 OK
-echo \13
-out ATS0=1\13	; change this to out ATS0=0\13 if you want to disable
-		; autoanswer mod
-inp 5 OK
-echo \13
-exit
------------------------------
-
-This script is used for dialing and authorizing on remote host.
-You will need to customize it for your needs.
-Put your login and password in this script , also you'll need
-to change input statement depending on responces from your modem
-and remote host.
-
------/etc/ppp/kermit.dial----
-
-;
-; put the com line attached to the modem here:
-;
-set line /dev/tty01
-;
-; put the modem speed here:
-;
-set speed 19200
-set file type binary		; full 8 bit file xfer
-set file names literal
-set win 8
-set rec pack 1024
-set send pack 1024
-set block 3
-set term bytesize 8
-set command bytesize 8
-set flow none
-set modem hayes
-set dial hangup off
-set carrier auto		; Then SET CARRIER if necessary,
-set dial display on		; Then SET DIAL if necessary,
-set input echo on
-set input timeout proceed
-set input case ignore
-def \%x 0			; login prompt counter
-goto slhup
-
-:slcmd				; put the modem in command mode
-echo Put the modem in command mode.
-clear				; Clear unread characters from input buffer
-pause 1
-output +++			; hayes escape sequence
-input 1 OK\13\10		; wait for OK
-if success goto slhup
-output \13
-pause 1
-output at\13
-input 1 OK\13\10
-if fail goto slcmd		; if modem doesn't answer OK, try again
-
-:slhup				; hang up the phone
-clear				; Clear unread characters from input buffer
-pause 1
-echo Hanging up the phone.
-output ath0\13			; hayes command for on hook
-input 2 OK\13\10
-if fail goto slcmd		; if no OK answer, put modem in command mode
-
-:sldial				; dial the number
-pause 1
-echo Dialing.
-output atdt9,550311\13\10		; put phone number here
-assign \%x 0			; zero the time counter
-
-:look
-clear				; Clear unread characters from input buffer
-increment \%x			; Count the seconds
-input 1 {CONNECT }
-if success goto sllogin
-reinput 1 {NO CARRIER\13\10}
-if success goto sldial
-reinput 1 {NO DIALTONE\13\10}
-if success goto slnodial
-reinput 1 {\255}
-if success goto slhup
-reinput 1 {\127}
-if success goto slhup
-if < \%x 60 goto look
-else goto slhup
-
-:sllogin			; login
-assign \%x 0			; zero the time counter
-pause 1
-echo Looking for login prompt.
-
-:slloop
-increment \%x			; Count the seconds
-clear				; Clear unread characters from input buffer
-output \13
-;
-; put your expected login prompt here:
-;
-input 1 {Username: }
-if success goto sluid
-reinput 1 {\255}
-if success goto slhup
-reinput 1 {\127}
-if success goto slhup
-if < \%x 10 goto slloop		; try 10 times to get a login prompt
-else goto slhup			; hang up and start again if 10 failures
-
-:sluid
-;
-; put your userid here:
-;
-output ppp-login\13
-input 1 {Password: }
-;
-; put your password here:
-;
-output ppp-password\13
-input 1 {Entering SLIP mode.}
-echo
-quit
-
-:slnodial
-echo \7No dialtone.  Check the telephone line!\7
-exit 1
-
-; local variables:
-; mode: csh
-; comment-start: "; "
-; comment-start-skip: "; "
-; end:
-------------------------
-
-###################################################################
-Gennady B. Sorokopud ( gena@NetVision.net.il ) 24/10/94 12:00
diff --git a/share/FAQ/slip-dialup b/share/FAQ/slip-dialup
deleted file mode 100644
index 66a6646..0000000
--- a/share/FAQ/slip-dialup
+++ /dev/null
@@ -1,190 +0,0 @@
-***********************************************************************
-***                 How to Set Up SLIP on FreeBSD                   ***
-***********************************************************************
-
-Updated for 1.1.5(.1) support by Satoshi Asami, 8/6/94.
-
-The following is I (asami) set up my FreeBSD machine for SLIP on a
-static host network.  For dynamic hostname assignments (i.e., your
-address changes each time you dial up), you probably need to do
-something much fancier.
-
-This is just "what I did, and it worked for me".  I'm sharing this
-just for your reference, I'm no expert in SLIP nor networking so your
-mileage may vary.
-
-Note: for 1.1 systems (not 1.1.5), you need to use /dev/tty01 instead
-of /dev/cua01. substitute all the occurences of "cua" in this document
-with "tty".
-
-Note: the default 1.1.5(.1) system only comes with cua/ttyd pairs for
-the last two ports (2 and 3), so if your modem is at sio0/sio1
-(COM1/COM2), you need to make the devices.  Try "cd /dev; sh MAKEDEV
-cua01" to make the new special files for sio1 (ditto for sio0).  This
-will delete tty01, but you shouldn't need it anymore...or you can make
-a symbolic link /dev/tty01 -> ttyd1 if you don't want to hunt down all
-occurences of tty01 in your setup files.
-
-I actually have a symbolic link /dev/modem -> cua01 (and /dev/mouse ->
-ttyd0). I use only the modem/mouse names in my configuration files.
-This helped a lot when I switched from 1.1 to 1.1.5.1 (tty01 => cua01)
-and when I had to move my modem temporarily to sio2 to enable the
-RS-232C port on the serial card.  It can become quite cumbersome when
-you need to fix a bunch of files in /etc and .kermrc's all over the
-system!
-
-First, make sure you have
-
-pseudo-device   sl      2
-
-in your kernel's config file.  It is included in the GENERICAH and
-GENERICBT kernels, so this won't be a problem unless you deleted it.
-
-Things you have to do only once:
-
-(1) Add your home machine, the gateway and nameservers to your
-    /etc/hosts file.  Mine looks like this:
-
-127.0.0.1               localhost loghost
-136.152.64.181          silvia.HIP.Berkeley.EDU silvia.HIP silvia
-
-136.152.64.1            inr-3.Berkeley.EDU inr-3 slip-gateway
-128.32.136.9            ns1.Berkeley.edu ns1
-128.32.136.12           ns2.Berkeley.edu ns2
-
-    By the way, silvia is the name of the car that I had when I was
-    back in Japan (it's called 2?0SX here in U.S.).
-
-(2) Make sure you have "hosts" before "bind" in your /etc/host.conf.
-    Otherwise, funny things may happen.
-
-(3) Edit the /etc/netstart and add this to the end of the file:
-
-# set up slip
-gateway=slip-gateway
-ifconfig sl0 inet $hostname $gateway netmask 0xffffff00
-route add default $gateway
-
-    Note that because of the "slip-gateway" entry in /etc/hosts, there
-    is no local dependency in the netstart file.  Also, you might want
-    to un-comment the "route add $hostname localhost" line.
-
-(3') Make a file /etc/resolv.conf which contains:
-
-domain HIP.Berkeley.EDU
-nameserver 128.32.136.9
-nameserver 128.32.136.12
-
-    As you can see, these set up the nameserver hosts.  Of course, the
-    actual addresses depend on your environment.
-
-(4) Set the password for root and toor (and any other accounts that
-    doesn't have a password).  Use passwd, don't edit the passwd or
-    passwd.master files!
-
-(5) Edit /etc/myname and reboot the machine.
-
-How to set up the connection:
-
-(6) Dial up, type "slip" at the prompt, enter your machine name and
-    password.  The things you need to enter depends on your
-    environment.  I use kermit, with a script like this:
-
-# kermit setup
-set modem hayes
-set line /dev/cua01
-set speed 57600
-set parity none
-set flow rts/cts
-set terminal bytesize 8
-set file type binary
-# The next macro will dial up and login
-define slip dial 643-9600, input 10 =>, if failure stop, -
-output slip\x0d, input 10 Username:, if failure stop, -
-output silvia\x0d, input 10 Password:, if failure stop, -
-output ***\x0d, echo \x0aCONNECTED\x0a
-
-    (of course, you have to change the hostname and password to fit
-    yours).  Then you can just type "slip" from the kermit prompt to
-    get connected.
-
-    Note: leaving your password in plain text anywhere in the
-    filesystem is generally a BAD idea.  Do it at your own risk.  I'm
-    just too lazy.
-
-    Note: If you have an 1.1 machine, and kermit doesn't give you a
-    prompt, try "stty -f /dev/tty01 clocal".  I put this in
-    /etc/rc.local so that it works the first time I boot the machine.
-    This doesn't apply to 1.1.5(.1) systems, as cua0? are already
-    configured for dialouts.
-
-(7) Leave the kermit there (you can suspend it by "z") and as root,
-    type
-
-slattach -h -c -s 57600 /dev/cua01
-
-    if you are able to "ping" hosts on campus, you are connected!
-
-    If it doesn't work, you might want to try "-a" instead of "-c".
-
-(8) Happy slipping!
-
-How to shutdown the connection:
-
-(9) Type "ps gx" (as root) to find out the PID of slattach, and use
-    "kill -INT" to kill it.
-
-    Then go back to kermit ("fg" if you suspended it) and exit from it
-    ("q").
-
-    The slattach man page says you have to use "ifconfig sl0 down" to
-    mark the interface down, but this doesn't seem to make any
-    difference for me.  ("ifconfig sl0" reports the same thing.)
-
-    Some times, your modem might refuse to drop the carrier (mine
-    often does).  In that case, simply start kermit and quit it again.
-    It usually goes out on the second try.
-
-    When you want to connect again, go back to (6).  You may have to
-    watch out for clocal mode.  If "stty -f /dev/tty01" doesn't tell
-    you it's clocal, you need to re-set it before kermitting.  Again,
-    this is only for 1.1 machines.
-
-TROUBLESHOOTING:
-
-If it doesn't work, feel free to ask me.  The things that people
-tripped over so far:
-
-* Not using "-c" or "-a" in slattach (I have no idea why this can be
-  fatal, but adding this flag solved the problem for at least one
-  person)
-
-* Using "s10" instead of "sl0" (might be hard to see the difference on
-  some fonts :)
-
-Try "ifconfig sl0" to see your interface status.  I get:
-
-silvia# ifconfig sl0
-sl0: flags=10<POINTOPOINT>
-        inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00
-
-Also, "netstat -r" will give the routing table, in case you get the
-"no route to host" messages from ping.  Mine looks like:
-
-silvia# netstat -r
-Routing tables
-Destination      Gateway            Flags     Refs     Use  IfaceMTU    Rtt   
-Netmasks:
-(root node)
-(root node)
-
-Route Tree for Protocol Family inet:
-(root node) =>
-default          inr-3.Berkeley.EDU UG          8   224515  sl0 -      -     
-localhost.Berkel localhost.Berkeley UH          5    42127  lo0 -       0.438
-inr-3.Berkeley.E silvia.HIP.Berkele UH          1        0  sl0 -      -     
-silvia.HIP.Berke localhost.Berkeley UGH        34 47641234  lo0 -       0.438
-(root node)
-
-(this is after transferring a bunch of files, your numbers should be
-smaller).
diff --git a/share/FAQ/slip.FAQ b/share/FAQ/slip.FAQ
deleted file mode 100644
index f05e9be..0000000
--- a/share/FAQ/slip.FAQ
+++ /dev/null
@@ -1,192 +0,0 @@
-***********************************************************************
-***                 How to Set Up SLIP on FreeBSD                   ***
-***********************************************************************
-
-$Id$
-
-Updated for 1.1.5(.1) support by Satoshi Asami, 8/6/94.
-
-The following is I (asami) set up my FreeBSD machine for SLIP on a
-static host network.  For dynamic hostname assignments (i.e., your
-address changes each time you dial up), you probably need to do
-something much fancier.
-
-This is just "what I did, and it worked for me".  I'm sharing this
-just for your reference, I'm no expert in SLIP nor networking so your
-mileage may vary.
-
-Note: for 1.1 systems (not 1.1.5), you need to use /dev/tty01 instead
-of /dev/cua01. substitute all the occurences of "cua" in this document
-with "tty".
-
-Note: the default 1.1.5(.1) system only comes with cua/ttyd pairs for
-the last two ports (2 and 3), so if your modem is at sio0/sio1
-(COM1/COM2), you need to make the devices.  Try "cd /dev; sh MAKEDEV
-cua01" to make the new special files for sio1 (ditto for sio0).  This
-will delete tty01, but you shouldn't need it anymore...or you can make
-a symbolic link /dev/tty01 -> ttyd1 if you don't want to hunt down all
-occurences of tty01 in your setup files.
-
-I actually have a symbolic link /dev/modem -> cua01 (and /dev/mouse ->
-ttyd0). I use only the modem/mouse names in my configuration files.
-This helped a lot when I switched from 1.1 to 1.1.5.1 (tty01 => cua01)
-and when I had to move my modem temporarily to sio2 to enable the
-RS-232C port on the serial card.  It can become quite cumbersome when
-you need to fix a bunch of files in /etc and .kermrc's all over the
-system!
-
-First, make sure you have
-
-pseudo-device   sl      2
-
-in your kernel's config file.  It is included in the GENERIC, GENERICAH
-and GENERICBT kernels, so this won't be a problem unless you deleted it.
-
-Things you have to do only once:
-
-(1) Add your home machine, the gateway and nameservers to your
-    /etc/hosts file.  Mine looks like this:
-
-127.0.0.1               localhost loghost
-136.152.64.181          silvia.HIP.Berkeley.EDU silvia.HIP silvia
-
-136.152.64.1            inr-3.Berkeley.EDU inr-3 slip-gateway
-128.32.136.9            ns1.Berkeley.edu ns1
-128.32.136.12           ns2.Berkeley.edu ns2
-
-    By the way, silvia is the name of the car that I had when I was
-    back in Japan (it's called 2?0SX here in U.S.).
-
-(2) Make sure you have "hosts" before "bind" in your /etc/host.conf.
-    Otherwise, funny things may happen.
-
-(3) Edit the /etc/netstart and add this to the end of the file:
-
-# set up slip
-gateway=slip-gateway
-ifconfig sl0 inet $hostname $gateway netmask 0xffffff00
-route add default $gateway
-
-    Note that because of the "slip-gateway" entry in /etc/hosts, there
-    is no local dependency in the netstart file.  Also, you might want
-    to un-comment the "route add $hostname localhost" line.
-
-(3') Make a file /etc/resolv.conf which contains:
-
-domain HIP.Berkeley.EDU
-nameserver 128.32.136.9
-nameserver 128.32.136.12
-
-    As you can see, these set up the nameserver hosts.  Of course, the
-    actual addresses depend on your environment.
-
-(4) Set the password for root and toor (and any other accounts that
-    doesn't have a password).  Use passwd, don't edit the passwd or
-    passwd.master files!
-
-(5) Edit /etc/myname and reboot the machine.
-
-How to set up the connection:
-
-(6) Dial up, type "slip" at the prompt, enter your machine name and
-    password.  The things you need to enter depends on your
-    environment.  I use kermit, with a script like this:
-
-# kermit setup
-set modem hayes
-set line /dev/cua01
-set speed 57600
-set parity none
-set flow rts/cts
-set terminal bytesize 8
-set file type binary
-# The next macro will dial up and login
-define slip dial 643-9600, input 10 =>, if failure stop, -
-output slip\x0d, input 10 Username:, if failure stop, -
-output silvia\x0d, input 10 Password:, if failure stop, -
-output ***\x0d, echo \x0aCONNECTED\x0a
-
-    (of course, you have to change the hostname and password to fit
-    yours).  Then you can just type "slip" from the kermit prompt to
-    get connected.
-
-    Note: leaving your password in plain text anywhere in the
-    filesystem is generally a BAD idea.  Do it at your own risk.  I'm
-    just too lazy.
-
-    Note: If you have an 1.1 machine, and kermit doesn't give you a
-    prompt, try "stty -f /dev/tty01 clocal".  I put this in
-    /etc/rc.local so that it works the first time I boot the machine.
-    This doesn't apply to 1.1.5(.1) systems, as cua0? are already
-    configured for dialouts.
-
-(7) Leave the kermit there (you can suspend it by "z") and as root,
-    type
-
-slattach -h -c -s 57600 /dev/cua01
-
-    if you are able to "ping" hosts on campus, you are connected!
-
-    If it doesn't work, you might want to try "-a" instead of "-c".
-
-(8) Happy slipping!
-
-How to shutdown the connection:
-
-(9) Type "ps gx" (as root) to find out the PID of slattach, and use
-    "kill -INT" to kill it.
-
-    Then go back to kermit ("fg" if you suspended it) and exit from it
-    ("q").
-
-    The slattach man page says you have to use "ifconfig sl0 down" to
-    mark the interface down, but this doesn't seem to make any
-    difference for me.  ("ifconfig sl0" reports the same thing.)
-
-    Some times, your modem might refuse to drop the carrier (mine
-    often does).  In that case, simply start kermit and quit it again.
-    It usually goes out on the second try.
-
-    When you want to connect again, go back to (6).  You may have to
-    watch out for clocal mode.  If "stty -f /dev/tty01" doesn't tell
-    you it's clocal, you need to re-set it before kermitting.  Again,
-    this is only for 1.1 machines.
-
-TROUBLESHOOTING:
-
-If it doesn't work, feel free to ask me.  The things that people
-tripped over so far:
-
-* Not using "-c" or "-a" in slattach (I have no idea why this can be
-  fatal, but adding this flag solved the problem for at least one
-  person)
-
-* Using "s10" instead of "sl0" (might be hard to see the difference on
-  some fonts :)
-
-Try "ifconfig sl0" to see your interface status.  I get:
-
-silvia# ifconfig sl0
-sl0: flags=10<POINTOPOINT>
-        inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00
-
-Also, "netstat -r" will give the routing table, in case you get the
-"no route to host" messages from ping.  Mine looks like:
-
-silvia# netstat -r
-Routing tables
-Destination      Gateway            Flags     Refs     Use  IfaceMTU    Rtt   
-Netmasks:
-(root node)
-(root node)
-
-Route Tree for Protocol Family inet:
-(root node) =>
-default          inr-3.Berkeley.EDU UG          8   224515  sl0 -      -     
-localhost.Berkel localhost.Berkeley UH          5    42127  lo0 -       0.438
-inr-3.Berkeley.E silvia.HIP.Berkele UH          1        0  sl0 -      -     
-silvia.HIP.Berke localhost.Berkeley UGH        34 47641234  lo0 -       0.438
-(root node)
-
-(this is after transferring a bunch of files, your numbers should be
-smaller).
diff --git a/share/FAQ/slip_server.FAQ b/share/FAQ/slip_server.FAQ
deleted file mode 100644
index ee6676b..0000000
--- a/share/FAQ/slip_server.FAQ
+++ /dev/null
@@ -1,433 +0,0 @@
-                            Slip Server
-                               FAQ
-                               For
-                             FreeBSD 
-
-$Id$
-
-Help for setting up SLIP Server services on a FreeBSD system
-------------------------------------------------------------
-
-Written by Guy Helmer (ghelmer@alpha.dsu.edu)
-Last Updated December 13, 1994
-
-This document provides suggestions for setting up SLIP Server services
-on a FreeBSD system, which typically means configuring your system to
-automatically startup connections upon login for remote SLIP clients.
-I've written this document based on my own experience; however, as
-your system and needs may be different, this document may not answer
-all of your questions, and I cannot be responsible if you damage your
-system or lose data due to attempting to follow the suggestions here.
-
-I have only setup SLIP Server services on a FreeBSD 1.1 system, so if
-you are running a different version (such as FreeBSD 2.0), your system
-may be different.  I've decided to write this document since I've
-recently been asked for the umpteenth time how to setup a FreeBSD
-machine as a SLIP server :-)
-
-
-1. Prerequisites
-----------------
-
-This document is very technical in nature, so background knowledge is
-required.  I must assume that you are familiar with the TCP/IP network
-protocol, and in particular, network and node addressing, network
-address masks, subnetting, routing, and routing protocols, such as
-RIP.  Configuring SLIP services on a dial-up server requires a
-knowledge of these concepts, and if you are not familiar with them,
-please read a copy of either Craig Hunt's "TCP/IP Network
-Administration" published by O'Reilly & Associates, Inc. (ISBN Number
-0-937175-82-X), or Douglas Comer's book on the TCP/IP protocol.
-
-I will assume that you have already setup your modem(s) and configured
-the appropriate system files to allow logins through your modems (see
-the manual pages for sio(4) for information on the serial port device
-driver and ttys(5), gettytab(5), getty(8), & init(8) for information
-relevant to configuring the system to accept logins on modems, and
-perhaps stty(1) for information on setting serial port parameters
-[such as "clocal" for directly-connected serial interfaces]).
-
-2. Quick Overview
------------------
-
-In its typical configuration, using FreeBSD as a SLIP server works as
-follows: a SLIP user dials up your FreeBSD SLIP Server system and logs
-in with a special SLIP login ID that uses "/usr/sbin/sliplogin" as the
-special user's shell.  The "sliplogin" program browses the file
-"/etc/slip.hosts" to find a matching line for the special user, and if
-it finds a match, connects the serial line to an available SLIP
-interface and then runs /etc/slip.login to configure the SLIP
-interface.
-
-2.1 An Example of a SLIP Server Login
--------------------------------------
-
-For example, if my SLIP user ID were "Shelmerg", that user's entry in
-/etc/master.passwd would look something like this (except it would be
-all on one line):
-
-Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:
-     /usr/users/Shelmerg:/usr/sbin/sliplogin
-
-and, when I log in with that user ID, "sliplogin" will search
-/etc/slip.hosts for a line that had a matching user ID; on my system,
-I may have a line in /etc/slip.hosts that reads:
-
-Shelmerg        dc-slip sl-helmer       0xfffffc00      autocomp
-
-sliplogin will find that matching line, hook the serial line I'm on
-into the next available SLIP interface, and then execute
-/etc/slip.login like this:
-
-/etc/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp
-
-If all goes well, /etc/slip.login will issue an "ifconfig" for the
-SLIP interface to which sliplogin attached itself (slip interface 0,
-in the above example, which was the first parameter in the list given
-to slip.login) to set the local IP address (dc-slip), remote IP
-address (sl-helmer), network mask for the SLIP interface (0xfffffc00),
-and any additional flags (autocomp).  If something goes wrong,
-sliplogin usually logs good informational messages via the daemon
-syslog facility, which usually goes into /var/log/messages (see the
-manual pages for syslogd(8) and syslog.conf(5), and perhaps check
-/etc/syslog.conf to see to which files syslogd is logging).
-
-OK, enough of the examples -- let's dive into setting up the system.
-
-3. Kernel Configuration
------------------------
-
-FreeBSD's default kernels usually come with two SLIP interfaces
-defined (sl0 and sl1); you can use "netstat -i" to see whether these
-interfaces are defined in your kernel.
-
-Sample output from "netstat -i":
-Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
-ed0   1500  <Link>0.0.c0.2c.5f.4a         291311     0   174209     0   133
-ed0   1500  138.247.224 ivory             291311     0   174209     0   133
-lo0   65535 <Link>                            79     0       79     0     0
-lo0   65535 loop        localhost             79     0       79     0     0
-sl0*  296   <Link>                             0     0        0     0     0
-sl1*  296   <Link>                             0     0        0     0     0
-
-The sl0 and sl1 interfaces shown in "netstat -i"'s output indicate
-that there are two SLIP interfaces built into the kernel.  (The
-asterisks after the "sl0" and "sl1" indicate that the interfaces are
-"down".)
-
-However, FreeBSD's default kernels do not come configured to forward
-packets (ie, your FreeBSD machine will not act as a router) due to
-Internet RFC requirements for Internet hosts (see RFC's 1009
-[Requirements for Internet Gateways], 1122 [Requirements for Internet
-Hosts -- Communication Layers], and perhaps 1127 [A Perspective on the
-Host Requirements RFCs]), so if you want your FreeBSD SLIP Server to
-act as a router, you'll have to add the line "options GATEWAY" to your
-machine's kernel configuration file and re-compile the kernel anyway.
-(Trivia: "Gateways" are the Internet's old name for what are now
-usually called "routers".)
-
-Please see the BSD System Manager's Manual chapter on "Building
-Berkeley Kernels with Config" [the source for which is in
-/usr/src/share/doc/smm] and the "FreeBSD Configuration Options" [in
-/sys/doc/options.doc] for more information on configuring and building
-kernels.  You may have to unpack the kernel source distribution if
-haven't installed the system sources already (srcdist/srcsys.?? in
-FreeBSD 1.1, srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire source
-distribution in FreeBSD 2.0-RELEASE) to be able to configure and build
-kernels.
-
-You'll notice that near the end of the default kernel configuration
-file (/sys/i386/conf/GENERICAH) is a line that reads:
-
-pseudo-device sl 2
-
-which is the line that defines the number of SLIP devices available in
-the kernel; the number at the end of the line is the maximum number of
-SLIP connections that may be operating simultaneously.
-
-See the "Building Berkeley Kernels with Config" and the manual page
-for config(8) to see how to configure and build kernels.
-
-4. Sliplogin Configuration
---------------------------
-
-As mentioned earlier, there are three files in the /etc directory that
-are part of the configuration for /usr/sbin/sliplogin (see
-sliplogin(8) for the actual manual page for sliplogin): slip.hosts,
-which lists the SLIP users & their associated IP addresses;
-slip.login, which usually just configures the SLIP interface; and
-slip.logout, which undoes slip.login's effects when the serial
-connection is terminated.
-
-4.1 slip.hosts Configuration & Local and Remote Address Selection
------------------------------------------------------------------
-
-/etc/slip.hosts contains lines which have at least four items listed:
-a SLIP user's login ID, the local address (local to the SLIP server)
-of the SLIP link, the remote address of the SLIP link, and the network
-mask.  The local and remote addresses may be host names (given in
-/etc/hosts or by the domain name service, depending on your
-specifications in /etc/host.conf), and I believe the network mask may
-be a name that can be resolved by a lookup into /etc/networks.  On one
-of my systems, /etc/slip.hosts looks like this:
-
------ begin /etc/slip.hosts -----
-#
-# login local-addr      remote-addr     mask            opt1    opt2 
-#                                               (normal,compress,noicmp)
-#
-Shelmerg  dc-slip       sl-helmerg      0xfffffc00      autocomp
------ end /etc/slip.hosts ------
-
-At the end of the line is one or more of the options:
-
-  "normal" - no header compression
-  "compress" - compress headers
-  "autocomp" - compress headers if the remote end allows it
-  "noicmp" - disable ICMP packets (so any "ping" packets won't use up
-	any of your bandwidth)
-
-Your choice of local and remote addresses for your SLIP links depends
-on whether you are going to dedicate a TCP/IP subnet or if you are
-going to use "proxy ARP" on your SLIP server (it's not "true" proxy
-ARP, but that is the terminology that I will use in this document to
-describe it).  If you're not sure which method to select or how to
-assign IP addresses, please refer to the TCP/IP books referenced in
-the "Prerequisites" section and/or consult your IP network manager.
-
-If you are going to use a separate subnet for your SLIP clients, you
-will need to allocate the subnet number out of your assigned IP
-network number and assign each of your SLIP client's IP numbers out of
-that subnet; then you will probably either need to configure a static
-route to the SLIP subnet via your SLIP server on your nearest IP
-router, or install "gated" on your FreeBSD SLIP server and configure
-it to talk the appropriate routing protocols to your other routers to
-inform them about your SLIP server's route to the SLIP subnet.
-
-Otherwise, if you will use the "proxy ARP" method, you will need to
-assign your SLIP client's IP addresses out of your SLIP server's
-Ethernet subnet, and you'll also need to adjust your /etc/slip.login
-and /etc/slip.logout scripts to use arp(8) to manage the proxy-ARP
-entries in the SLIP server's ARP table.
-
-4.2 slip.login Configuration
-----------------------------
-
-The typical /etc/slip.login file looks like this:
-
------ begin /etc/slip.login -----
-#!/bin/sh -
-#
-#	@(#)slip.login  5.1 (Berkeley) 7/1/90
-
-#
-# generic login file for a slip line.  sliplogin invokes this with
-# the parameters:
-#      1        2         3        4          5         6     7-n
-#   slipunit ttyspeed loginname local-addr remote-addr mask opt-args
-#
-/sbin/ifconfig sl$1 inet $4 $5 netmask $6
------ end /etc/slip.login -----
-
-This slip.login file merely ifconfig's the appropriate SLIP interface
-with the local and remote addresses and network mask of the SLIP
-interface.
-
-If you have decided to use the "proxy ARP" method (instead of using a
-separate subnet for your SLIP clients), your /etc/slip.login file will
-need to look something like this:
-
------ begin /etc/slip.login for "proxy ARP" -----
-#!/bin/sh -
-#
-#	@(#)slip.login  5.1 (Berkeley) 7/1/90
-
-#
-# generic login file for a slip line.  sliplogin invokes this with
-# the parameters:
-#      1        2         3        4          5         6     7-n
-#   slipunit ttyspeed loginname local-addr remote-addr mask opt-args
-#
-/sbin/ifconfig sl$1 inet $4 $5 netmask $6 
-# Answer ARP requests for the SLIP client with our Ethernet addr
-/usr/sbin/arp -s $5 00:11:22:33:44:55 pub
------ end /etc/slip.login for "proxy ARP" -----
-
-The additional line in this slip.login, "arp -s...", creates an ARP
-entry in the SLIP server's ARP table which asks the system to give out
-the SLIP server's Ethernet MAC address whenever a another system or
-router on the Ethernet asks to speak to the SLIP client's IP address.
-
-When using the example above, be sure to replace the Ethernet MAC
-address (00:11:22:33:44:55) with the MAC address of your system's
-Ethernet card, or your "proxy ARP" will definitely not work!  You can
-discover your SLIP server's Ethernet MAC address by looking at the
-results of running "netstat -i"; the second line of the output should
-look something like:
-
-ed0   1500  <Link>0.2.c1.28.5f.4a         191923     0   129457     0   116
-                  ^^^^^^^^^^^^^^^
-
-which indicates that this particular system's Ethernet MAC address is
-"00:02:c1:28:5f:4a" -- the periods in the Ethernet MAC address given
-by "netstat -i" must be changed to colons and leading zeros should be
-added to each single-digit hexadecimal number to convert the address
-into the form that arp(8) desires; see the manual page on arp(8) for
-complete information on usage.
-
-Note that when you create /etc/slip.login and /etc/slip.logout, the
-"execute" bit ("chmod 755 /etc/slip.login /etc/slip.logout") must be
-set, or sliplogin will be unable to execute it.
-
-4.3 slip.logout Configuration
------------------------------
-
-"/etc/slip.logout" isn't strictly needed, but if you decide to create
-it, this is an example of a basic slip.logout script:
-
------ begin /etc/slip.logout -----
-#!/bin/sh -
-#
-#	slip.logout
-
-#
-# logout file for a slip line.  sliplogin invokes this with
-# the parameters:
-#      1        2         3        4          5         6     7-n
-#   slipunit ttyspeed loginname local-addr remote-addr mask opt-args
-#
-/sbin/ifconfig sl$1 down
------ end /etc/slip.logout -----
-
-If you are using "proxy ARP", you'll want to have /etc/slip.logout
-remove the ARP entry for the SLIP client:
-
------ begin /etc/slip.logout for "proxy ARP" -----
-#!/bin/sh -
-#
-#       @(#)slip.logout
-
-#
-# logout file for a slip line.  sliplogin invokes this with
-# the parameters:
-#      1        2         3        4          5         6     7-n
-#   slipunit ttyspeed loginname local-addr remote-addr mask opt-args
-#
-/sbin/ifconfig sl$1 down
-# Quit answering ARP requests for the SLIP client
-/usr/sbin/arp -d $5
------ end /etc/slip.logout for "proxy ARP" -----
-
-The "arp -d $5" removes the ARP entry that the "proxy ARP" slip.login
-added when the SLIP client logged in.
-
-It bears repeating: make sure /etc/slip.logout has the execute bit set
-for after you create it (e.g., "chmod 755 /etc/slip.logout").
-
-5. Routing Considerations
--------------------------
-
-If you are not using the "proxy ARP" method for routing packets
-between your SLIP clients and the rest of your network (and perhaps
-the Internet), you will probably either have to add static routes to
-your closest default router(s) to route your SLIP client subnet via
-your SLIP server, or you will probably need to install and configure
-gated on your FreeBSD SLIP server so that it will tell your routers
-via appropriate routing protocols about your SLIP subnet.
-
-5.1 Static Routes
------------------
-
-Adding static routes to your nearest default routers can be
-troublesome (or impossible, if you don't have authority to do so...).
-If you have a multiple-router network in your organization, some
-routers, such as Cisco and Proteon, may not only need to be configured
-with the static route to the SLIP subnet, but also need to be told
-which static routes to tell other routers about, so some expertise and
-troubleshooting/tweaking may be necessary to get static-route-based
-routing to work...
-
-5.2 Running gated
------------------
-
-An alternative to the headaches of static routes is to install gated
-on your FreeBSD SLIP server and configure it to use the appropriate
-routing protocols (RIP/OSPF/BGP/EGP) to tell other routers about your
-SLIP subnet.  gated is available from ftp.gated.cornell.edu in
-/pub/gated; I believe the current version as of this writing is
-"gated-R3_5Alpha_8.tar.Z", which should include support for FreeBSD
-"out-of-the-box".  Compile and install it, and then write a
-/etc/gated.conf file to configure your gated; here's a sample, similar
-to what I use on my FreeBSD SLIP server:
-
------ begin sample /etc/gated.conf for gated version 3.5Alpha5 -----
-#
-# gated configuration file for dc.dsu.edu; for gated version 3.5alpha5
-# Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface
-#
-#
-# tracing options
-#
-traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ;
-
-rip yes {
- interface sl noripout noripin ;
- interface ed ripin ripout version 1 ;
- traceoptions route ;
-} ;
-
-#
-# Turn on a bunch of tracing info for the interface to the kernel:
-kernel {
- traceoptions remnants request routes info interface ;
-} ;
-
-#
-# Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP
-#
-
-export proto rip interface ed {
-        proto direct {
-                xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections
-        } ;
-} ;
-
-#
-# Accept routes from RIP via ed Ethernet interfaces
-
-import proto rip interface ed {
-        all ;
-} ;
-
------ end sample /etc/gated.conf -----
-
-The above sample gated.conf file broadcasts routing information
-regarding the SLIP subnet "xxx.xxx.yy" via RIP onto the Ethernet; if
-you are using a different Ethernet driver than the "ed" driver, you'll
-need to change the references to the "ed" interface appropriately.
-This sample file also sets up tracing to /var/tmp/gated.output for
-debugging gated; you can certainly turn off the tracing options if
-gated works OK for you.  I've changed my SLIP subnet's address to
-"xxx.xxx.yy" throughout the above file; you'll need to change the
-"xxx.xxx.yy"'s into the network address of your own SLIP subnet (be
-sure to change the net mask in the "proto direct" clause as well).
-Complete gated configuration information may be read through the Web
-at "http://www.gated.cornell.edu/".
-
-When you get gated built and installed, and create a configuration
-file for it, you'll need to run gated in place of routed on your
-FreeBSD system; change the routed/gated startup parameters in
-/etc/netstart as appropriate for your system.  Please see the manual
-page for gated for information on gated's command-line parameters.
-
-6. Acknowledgements
--------------------
-
-Thanks to these people for comments and advice regarding this FAQ:
-
-	Wilko Bulte <wilko@yedi.iaf.nl>
-	Piero Serini <Piero@Strider.Inet.IT>
-
-<<< END OF SLIP SERVER FAQ >>>
-
-
diff --git a/share/FAQ/standard-supfile b/share/FAQ/standard-supfile
deleted file mode 100644
index 6856d4c..0000000
--- a/share/FAQ/standard-supfile
+++ /dev/null
@@ -1,14 +0,0 @@
-base release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-bin release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-etc release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-games release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-gnu release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-include release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-sys release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-lib release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-libexec release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-sbin release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-#secure release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-share release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-usrbin release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
-usrsbin release=current host=FreeBSD.ORG hostbase=/home base=/usr prefix=/usr/src delete old 
diff --git a/share/FAQ/submitters.FAQ b/share/FAQ/submitters.FAQ
deleted file mode 100644
index 69a79f3..0000000
--- a/share/FAQ/submitters.FAQ
+++ /dev/null
@@ -1,167 +0,0 @@
--- A submitter's guide to FreeBSD --
-
-This guide is intended for those who are moderately familar with FreeBSD
-and are now to the point where they have some locally developed
-customizations or fixes to the system which they'd like to incorporate
-back into the mainstream sources, thus saving the work of having to
-re-integrate the changes for each subsequent FreeBSD release.  Submitting
-something to the FreeBSD project is also an excellent way of getting your
-code seriously *tested*!  Many people have developed an original concept
-far beyond what they might have envisioned at the start just due to the
-flood of feedback and ideas generated by the many thousands of users of
-FreeBSD.  Contributions are also what FreeBSD lives and grows from,
-and so your contributions are very important to the continued survival
-of this communal effort of ours - we're very glad to see you reading this
-documentation! :-)
-
-Submissions to FreeBSD can generally be classified into four catagories:
-
-1. Ideas, general suggestions, bug reports.
-2. Addition, deletion, renaming or patching of existing sources.
-3. Significant contribution of a large body of independant work.
-4. Porting of freely available software.
-
-A submission in *any* of these catagories is highly welcomed as they
-are each, in their own way, quite significant to the project.  
-
-
-1. An idea, suggestion or fix can be communicated in one of the following ways:
-
-	o An idea or suggestion of general technical interest should be
-	  mailed to <hackers@freebsd.org>.  Likewise, people with an interest
-	  in such things (and a tolerance for a HIGH volume of mail!) may
-	  subscribe by sendimg mail to <majordomo@freebsd.org>.  See also the
-	  file /usr/share/FAQ/mailing-list.FAQ.
-
-	o An actual bug report should be filed by using the send-pr(1)
-	  command (``man send-pr'' for information).  This will prompt
-	  you for various fields to fill in.  Simply go to the fields
-	  surrounded by <>'s and fill in your own information in place of
-	  what's suggested there.  You should receive confirmation of your
-	  bug report and a tracking number (which you should also reference in
-	  any subsequent correspondence).
-
-          If you do not receive confirmation in a timely fashion (3 days to
-          a week, depending on your email connection) or are, for some
-          reason, unable to use the send-pr command, then you may also
-	  file a bug report (or follow-up to one) by sending mail to:
-
-	  		<bugs@freebsd.org>
-
-
-2. An addition or change to the existing source code is a somewhat trickier
-   affair and depends a lot on how far out of date you are with the current
-   state of the core FreeBSD development.  There is a special on-going release
-   of FreeBSD known as "FreeBSD-current" and made available in a variety of
-   ways (see /usr/share/FAQ/current-policy.FAQ and /usr/share/FAQ/ctm.FAQ) for
-   the convenience of developers who wish to actively work on the system.
-
-   Working from older sources unfortunately means that your changes may
-   sometimes be too obsolete to use, or too divergent to allow for easy
-   re-integration.  This can be minimized somewhat by subscribing to the
-   <announce@freebsd.org> mailing list (among others) where periodic
-   announcements concerning the current state of the system are made.
-   If you see a change being proposed for which you have a better solution,
-   then please, by all means come forward with your contribution and we
-   will do our very best to evaluate it fairly and perhaps integrate it if
-   it is indeed a better (or easier :) solution.
-
-   Assuming that you can manage to secure fairly up-to-date sources to base
-   your changes on, the next step is to produce a set of diffs to send to the
-   FreeBSD maintainers for evaluation and possible adoption.  This is done
-   with the diff(1) command, with the FreeBSD maintainers preferring to receive
-   diffs in `context diff' form.  See the man page for diff for more details
-   on producing both context and recursive context diffs
-   (diff -c <oldfile> <newfile> or diff -c -r <olddir> <newdir>).
-
-   Once you have a set of diffs that are capable of taking a copy of the
-   original code and bringing it to a state identical to the "new" sources
-   (you may test this with the patch(1) command - see patch man page), you
-   should bundle them up in an email message and send it, along with a brief
-   description of what the diffs are for, to <hackers@freebsd.org>.  Someone
-   will very likely get back in touch with you in 24 hours or less, assuming
-   of course that your diffs are interesting! :-)
-
-   If your changes don't express themselves well as diffs alone (e.g. you've
-   perhaps added, deleted or renamed files as well) then you may be better off
-   bundling any new files, diffs and instructions for deleting/renaming any
-   others into a tar file and running the `uuencode' program on it before
-   sending the output of that to <hackers@freebsd.org>.  See the man pages
-   on tar and uuencode for more info on bundling files through the mail this
-   way.
-
-   If your change is of a potentially sensitive nature, e.g. you're unsure
-   of copyright issues governing its further distribution, or you're simply
-   not ready to release it without a tighter review first, then you should
-   send it to <core@freebsd.org> rather than <hackers@freebsd.org>.  The core
-   mailing list reaches a much smaller group of people who do much of the
-   day-to-day work on FreeBSD.  Note that this group is also VERY BUSY and so
-   you should really only mail to them in cases where mailing to hackers
-   truly is impractical.
-
-
-3. In the case of a significant contribution of a large body work, or the
-   addition of an important new feature to FreeBSD, it becomes almost always
-   necessary to either send changes as uuencoded tar files (see above)
-   or upload them to our ftp site:
-		ftp://freefall.cdrom.com/pub/FreeBSD/incoming
-
-   Users may log in anonymously and upload their work or download the
-   work-in-progress files left by others.
-
-   When working with large amounts of code, the touchy subject of copyrights
-   also invariably comes up.  The view of the FreeBSD project towards
-   acceptable copyrights (for code included in FreeBSD) are:
-
-	3a. Contributions under the BSD copyright (see the file
-	    /usr/share/examples/etc/bsd-style-copyright for a template)
-	    is greatly preferred due to its "no strings attached"
-	    nature and general attractiveness to commercial enterprises
-	    who might then be inclined to invest something of their own
-	    into FreeBSD.
-
-	3b. Contributions under the GNU Public License, or "GPL".  This is
-	    not quite as popular a solution for us, due to (all religious
-	    issues aside) the amount of extra effort demanded of anyone
-	    using the code for commercial purposes.  However, given the
-	    sheer quantity of GPL'd code we currently require (compiler,
-	    assembler, text formatter, etc), it would be silly to pretend
-	    that we couldn't deal with the GPL at all and so we have become
-	    more willing to accept code with either the BSD or the GPL
-	    copyright.  Code under the GPL also goes into a different part
-	    of the tree, that being /sys/gnu or /usr/src/gnu.
-
-	3c. Contributions coming under any other type of copyright must be
-	    carefully reviewed before their inclusion into FreeBSD will even
-	    be considered.  Contributions for which particularly restrictive
-	    commercial copyrights apply are generally rejected, though the
-	    authors are always free to make the changes available through
-	    their own channels.
-
-
-4. The porting of freely available software, while perhaps not as gratifying
-   as developing your own package from scratch, is still a vital part of
-   FreeBSD's growth and of great usefulness to those who wouldn't otherwise
-   know where to turn for it.  All ported software is organized into a
-   hierarchy know as ``the ports collection''.  This collection enables
-   a new user to get a complete overview of what's available in a short time,
-   and with a logical (we hope) framework.  The ports collection also saves
-   considerable space by not actually containing the the majority of the
-   sources being ported.  This can be confusing to the new user and the file
-   /usr/share/FAQ/ports.FAQ goes some way towards explaing how it all works.
-
-   If you have the ports collection on your machine, the file
-   /usr/ports/GUIDELINES also helps to explain the process of creating
-   and contributing a port of your own.  For more information on the ports
-   collection (that wasn't available in the FAQ), you may also send mail to
-   <ports@freebsd.org>.
-
-
-Whichever way you decide to contribute, we hope you'll find it an enjoyable
-process and also realize how valuable your contributions are to the project!
-FreeBSD is one of those great projects where the more we all put in, the
-more we all get back out of it again, and with enough steady contributions
-it begins to aquire a momentum of its own.  It is through such momentum
-that mountains are moved! :-)
-
-					Jordan
diff --git a/share/FAQ/sup.FAQ b/share/FAQ/sup.FAQ
deleted file mode 100644
index c543fa0..0000000
--- a/share/FAQ/sup.FAQ
+++ /dev/null
@@ -1,90 +0,0 @@
-                                 FreeBSD
-                                 Sup FAQ
-
-$Id: sup.FAQ,v 1.3 1995/01/03 15:54:07 gclarkii Exp $
-
-	SUP is a network based software update tool developed at CMU.  The
-purpose of this document is get the beginner up and running with sup.
-
-	First off you will need to pick up the sup binaries.  The easiest
-way of doing this is to grab the sup.tgz package from:
-
-	ftp://ftp.FreeBSD.ORG:/pub/FreeBSD/packages/sup.tgz
-
-Install the sup package using pkg_add and add the following line to
-your /etc/services file:
-
-        sup                 871/tcp        #sup
-
-SUP gets the information it needs to run from a configuration file 
-called a supfile.  This file tells sup what collections it will be updating
-and/or installing and where they go.  The supfile in this directory will
-sup both the source and ports collection - look for the blank line seperating
-the two collections; if you don't want ports, you can simply delete all the
-ports entries.  If you're inside the United States, you may also uncomment
-the `secure' collection line to grab the DES code.  If you're outside the
-U.S., you should NOT sup this code from FreeBSD.ORG as this will
-violate U.S. export restrictions.  Simply sup everything *but* the secure
-collection and then go look on "braae.ru.ac.za", where it's available for
-anonymous ftp for those outside the U.S.
-
-Any other distributions you do not wish to receive can be commented out
-with a # at the begining of the distribution line.
-
-Once this is setup, you're ready to go.  To start sup type:
-
-	sup supfile
-
-If you wish to see what sup is doing "verbosely", give it the -v option,
-like so:
-
-	sup -v supfile
-
-Thats all there is to it!  Remember that if you're running current,
-which is what you will have if you sup, please join the freebsd-current
-mailing list.  You should also be sure to read:
-
-	ftp://ftp.FreeBSD.ORG:/pub/FreeBSD/FAQ/current-policy.FAQ
-
-For important information on just what we can and cannot do for you as
-a -current user.  
-
-Gary Clark II / Jordan Hubbard
-FreeBSD maintainance persons.
-
-----
-
-Description of FreeBSD SUP distributions:
-
-base:		/usr/src/...		misc files at the top of /usr/src
-bin:		/usr/src/bin		system binaries
-secure:		/usr/src/secure		DES Sources.  U.S./Canada only!
-etc:		/usr/src/etc		system files
-games:		/usr/src/games		games
-gnu:		/usr/src/gnu		sources under the GNU Public License
-include:	/usr/src/include	include files
-sys:		/usr/src/sys		kernel sources
-lib:		/usr/src/lib		libraries
-libexec:	/usr/src/libexec	more system binaries
-share:		/usr/src/share		various shared resources
-sbin:		/usr/src/sbin		even more system binaries
-usrbin:		/usr/src/usr.bin	user binaries
-usrsbin:	/usr/src/usr.sbin	that's it for the system binaries
-
-Ports:
-
-ports-base:	/usr/ports/...		misc files at the top of /usr/ports
-ports-editors:  /usr/ports/editors	text editors
-ports-game:	/usr/ports/games	games
-ports-lang:	/usr/ports/lang		programming languages
-ports-mail:	/usr/ports/mail		mail software
-ports-math:	/usr/ports/math		math software
-ports-net:	/usr/ports/net		networking software
-ports-news:	/usr/ports/news		USENET news software
-ports-print:	/usr/ports/print	printing software
-ports-shells:	/usr/ports/shells	various UN*X shells
-ports-utils:	/usr/ports/utils	miscellaneous utilities
-ports-x11:	/usr/ports/x11		X11 software
-
-
-
diff --git a/share/FAQ/systems.FAQ b/share/FAQ/systems.FAQ
deleted file mode 100644
index dd0ac4f..0000000
--- a/share/FAQ/systems.FAQ
+++ /dev/null
@@ -1,59 +0,0 @@
-
-                               Systems FAQ
-                             for FreeBSD 2.0
-
-This FAQ lists systems (and componets) known to work with FreeBSD 2.0.  None
-of these lists should be seen as a recomandation for a manufacture.
-
-$Id: systems.FAQ,v 1.1 1995/01/03 15:48:39 gclarkii Exp $
-
-
-i386:
-
-
-Motherboard: Magitronics 386DX-40
-CPU: i386DX-40
-Busses: ISA and VLB (VLB not tested)
-Ram: 20 Megs
-Video: Generic 1MB Tseng 4000 (ISA)
-Disks:
-	2 - Segate ST1126 (SCSI)
-	1 - Seagate ST1480 (SCSI)
-	1 - Toshiba MK-234FC-C (IDE)
-Controllers:
-	Generic IDE
-	Adaptec AH-1542CF
-
-Motherboard: Magitronics 386SX-40
-CPU: i386SX-40
-Busses: ISA
-Ram: 4 Megs
-Video: Monochrome
-Disks:
-	1-Seagate ST1126 (SCSI)
-Controllers:
-	Future Domain 850
-Notes: Slow but useable
-
-i486:
-
-Motherboard:  Gateway 2000 Handbook 486 HB486DX2-40
-CPU: i486SL DX2/40
-BUS(S): PCMCIA, one type II
-Video Card: Monochrome VGA.
-Are you running X on this?: no, havn't really tried.
-Types of Disks (manufacture and bus): 130Mb builtin.  <Areal A130 U>
-If you wish to be credited: Poul-Henning Kamp phk@freefall.cdrom.com
-
-NOTES:
-This is a 3 pound portable.  Runs perfect.  Suspend works great.  Has one
-serial and one parallel/floppy port, which can drive either a floppy or
-a parallel port, but not at the same time.  Builtin "EZ" mouse-thinge.
-Highly recommended for people on the road.
-
-
-Credits:
-	FreeBSD Core Team
-	Gary Clark II
-	Poul-Henning Kamp
-
diff --git a/share/FAQ/tutorials.html b/share/FAQ/tutorials.html
deleted file mode 100644
index 9a260af..0000000
--- a/share/FAQ/tutorials.html
+++ /dev/null
@@ -1,109 +0,0 @@
-<!-- $Id:$ -->
-
-<!DOCTYPE html PUBLIC '-//IETF//DTD HTML 2.0//EN'>
-<html>
-  <head>
-    <title>FreeBSD Tutorials</title>
-  </head>
-  <body>
-<h1>FreeBSD Tutorials</h1>
-<hr>
-
-    <p>This page contains tutorials on topics that the short
-      answer format of the main <a
-      href="HTML/freebsd-faq.html">FAQ</a> cannot do justice to.
-      If you have a particular area of expertise, we would like
-      to here from you!  Your contributions are not only welcome,
-      but often save new users from uncountable headaches.  If
-      you've written something you think may help new users, by
-      all means let us know about it by sending mail to <a
-      href="mailto:doc@freebsd.org">doc@FreeBSD.ORG</a>.
-
-<h2>Installation Topics</h2>
-
-    <ul>
-
-      <li><a href = "Text/INSTALL">How to install a distribution.</a>
-
-      <li><a href="Text/diskspace.FAQ">All about hard disk partitioning.</a>
-
-    </ul>
-
-<h2>Networking topics</h2>
-
-<ul>
-      <li><a href="HTML/dialup.html">Setting up FreeBSD for
-	  dialin access.</a></li>
-
-      <li><a href="Text/slip.FAQ">Setting up FreeBSD as a SLIP
-	  <em>client</em>.</a>
-
-      <li><a href="HTML/slip_server.html">Setting up FreeBSD as a SLIP
-          <em>server</em>.</a>
-
-      <li><a href="Text/ppp.FAQ">How to configure PPP.</a>
-
-      <li><a href="Text/nfs.FAQ">Tips for users using NFS between
-	  FreeBSD and workstation hardware.</a>
-
-      <li><a href="Text/diskless.FAQ">Setting up a diskless FreeBSD
-	  workstation.</a>
-
-      <li><a href="LaTeX/kerberos_setup.latex">Setting up Kerberos</a>
-	(this is a LaTeX document)
-
-      <li><a href="Text/UUCP_Internals.FAQ">UUCP internals</a>
-
-    </ul>
-
-
-<h2>FreeBSD-current topics</h2>
-
-<ul>
-      <li><a href="Text/current-policy.FAQ">What you should know about running
-	  FreeBSD-current.</a>
-      
-      <li><a href="HTML/ctm.html">All about CTM</a>.
-
-      <li><a href="Text/sup.FAQ">All about sup</a>.
-
-      <li><a href="extras/ports-supfile">A sample supfile for the FreeBSD ports
-	  collection.</a>
-      
-      <li><a href="extras/standard-supfile">A sample supfile for the
-	  FreeBSD source tree.</a>
-
-</ul>
-
-<h2>Hardware topics</h2>
-
-<ul>
-      <li><a href="Text/systems.FAQ">Systems and configurations
-	  on which FreeBSD is "known" to work.</a>
-
-      <li><a href="Text/HW.TROUBLE">User feedback on finicky or broken
-	  hardware.</a>
-
-      <li><a href="HTML/SCSI.html">Using SCSI devices with FreeBSD</a>.
-
-</ul>
-
-<h2>Miscellaneous</h2>
-<ul>
-      <li><a href="Text/kernel-debug.FAQ">How to debug the kernel.</a>
-      </li>
-
-      <li><a href="Text/ports.FAQ">Using the FreeBSD "ports"
-	  collection</a></li>
-
-      <li><a href="Text/submitters.FAQ">Becoming a contributor to
-	  the FreeBSD project</a></li>
-
-    </ul>
-
-
-<hr>
-<a href="index.html">Return to the help page</a>
-
-  </body>
-</html>