Do a big re-org of the FAQs along the lines of those discussed awhile back.

It's time to start moving in the directions we've had in mind for awhile.
SGML for everything new and old stuff moved into a location where it can slowly
be aged and removed (basically, Text/).

23 files changed, 7126 insertions, 0 deletions

diff --git a/share/FAQ/Text/CONTRIB.FreeBSD b/share/FAQ/Text/CONTRIB.FreeBSD
new file mode 100644
index 0000000..d401fb4
--- /dev/null
+++ b/share/FAQ/Text/CONTRIB.FreeBSD
@@ -0,0 +1,245 @@
+			   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.25 1995/03/21 00:37:06 ache Exp $
diff --git a/share/FAQ/Text/FreeBSD.FAQ b/share/FAQ/Text/FreeBSD.FAQ
new file mode 100644
index 0000000..ade51b5
--- /dev/null
+++ b/share/FAQ/Text/FreeBSD.FAQ
@@ -0,0 +1,1304 @@
+
+                               FreeBSD
+                      Frequently Asked Questions
+                           For Version 2.0 
+
+Please mail all suggestions and additions to <FAQ@FreeBSD.ORG>
+
+
+Revision: $Id: FreeBSD.FAQ,v 1.24 1995/03/11 19:13:26 gclarkii 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/Text/HW.TROUBLE b/share/FAQ/Text/HW.TROUBLE
new file mode 100644
index 0000000..86e3e42
--- /dev/null
+++ b/share/FAQ/Text/HW.TROUBLE
@@ -0,0 +1,58 @@
+$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
new file mode 100644
index 0000000..8c89c8f
--- /dev/null
+++ b/share/FAQ/Text/MIRROR.SITES
@@ -0,0 +1,107 @@
+                          Mirror Sites
+                    For FreeBSD 2.0 and later
+
+$Id: MIRROR.SITES,v 1.25 1995/03/12 22:34:05 roberto 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/Text/README b/share/FAQ/Text/README
new file mode 100644
index 0000000..c9d81f9
--- /dev/null
+++ b/share/FAQ/Text/README
@@ -0,0 +1,75 @@
+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/Text/REGISTER.FreeBSD b/share/FAQ/Text/REGISTER.FreeBSD
new file mode 100644
index 0000000..8501628
--- /dev/null
+++ b/share/FAQ/Text/REGISTER.FreeBSD
@@ -0,0 +1,85 @@
+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
new file mode 100644
index 0000000..3b77f60
--- /dev/null
+++ b/share/FAQ/Text/RELNOTES.FreeBSD
@@ -0,0 +1,624 @@
+                                 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.23 1995/03/21 00:37:07 ache Exp $
diff --git a/share/FAQ/Text/ROADMAP b/share/FAQ/Text/ROADMAP
new file mode 100644
index 0000000..bf326c0
--- /dev/null
+++ b/share/FAQ/Text/ROADMAP
@@ -0,0 +1,55 @@
+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/Text/TROUBLESHOOTING b/share/FAQ/Text/TROUBLESHOOTING
new file mode 100644
index 0000000..d1cb25f
--- /dev/null
+++ b/share/FAQ/Text/TROUBLESHOOTING
@@ -0,0 +1,185 @@
+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
new file mode 100644
index 0000000..5a0702b
--- /dev/null
+++ b/share/FAQ/Text/UUCP_Internals.FAQ
@@ -0,0 +1,1603 @@
+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
new file mode 100644
index 0000000..9dc0d05
--- /dev/null
+++ b/share/FAQ/Text/ctm.FAQ
@@ -0,0 +1,191 @@
+# ----------------------------------------------------------------------------
+# "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
new file mode 100644
index 0000000..dd61dbd
--- /dev/null
+++ b/share/FAQ/Text/current-policy.FAQ
@@ -0,0 +1,170 @@
+                        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
new file mode 100644
index 0000000..b696f1c
--- /dev/null
+++ b/share/FAQ/Text/diskspace.FAQ
@@ -0,0 +1,267 @@
+                    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
new file mode 100644
index 0000000..9215b26
--- /dev/null
+++ b/share/FAQ/Text/kernel-debug.FAQ
@@ -0,0 +1,417 @@
+                   Kernel debugging FAQ for FreeBSD
+
+$Id: kernel-debug.FAQ,v 1.4 1995/01/03 15:54:03 gclarkii 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/Text/mailing-list.FAQ b/share/FAQ/Text/mailing-list.FAQ
new file mode 100644
index 0000000..881890f
--- /dev/null
+++ b/share/FAQ/Text/mailing-list.FAQ
@@ -0,0 +1,105 @@
+                     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
new file mode 100644
index 0000000..88c5fc5
--- /dev/null
+++ b/share/FAQ/Text/nfs.FAQ
@@ -0,0 +1,79 @@
+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
new file mode 100644
index 0000000..2a447ad
--- /dev/null
+++ b/share/FAQ/Text/ports.FAQ
@@ -0,0 +1,246 @@
+			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
new file mode 100644
index 0000000..46cc8bc
--- /dev/null
+++ b/share/FAQ/Text/ppp.FAQ
@@ -0,0 +1,369 @@
+         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
new file mode 100644
index 0000000..4baf38c
--- /dev/null
+++ b/share/FAQ/Text/slip.FAQ
@@ -0,0 +1,192 @@
+***********************************************************************
+***                 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
new file mode 100644
index 0000000..99b50a2
--- /dev/null
+++ b/share/FAQ/Text/slip_server.FAQ
@@ -0,0 +1,433 @@
+                            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
new file mode 100644
index 0000000..69a79f3
--- /dev/null
+++ b/share/FAQ/Text/submitters.FAQ
@@ -0,0 +1,167 @@
+-- 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
new file mode 100644
index 0000000..db9ff7f
--- /dev/null
+++ b/share/FAQ/Text/sup.FAQ
@@ -0,0 +1,90 @@
+                                 FreeBSD
+                                 Sup FAQ
+
+$Id: sup.FAQ,v 1.4 1995/03/01 06:12:15 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/Text/systems.FAQ b/share/FAQ/Text/systems.FAQ
new file mode 100644
index 0000000..34c8e71
--- /dev/null
+++ b/share/FAQ/Text/systems.FAQ
@@ -0,0 +1,59 @@
+
+                               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
+