summaryrefslogtreecommitdiffstats
path: root/release/picobsd/doc/src
diff options
context:
space:
mode:
Diffstat (limited to 'release/picobsd/doc/src')
-rw-r--r--release/picobsd/doc/src/Makefile17
-rw-r--r--release/picobsd/doc/src/TODO.html154
-rw-r--r--release/picobsd/doc/src/UCI.html960
-rw-r--r--release/picobsd/doc/src/bugs.html152
-rw-r--r--release/picobsd/doc/src/faq.html243
-rw-r--r--release/picobsd/doc/src/hardware.html112
-rw-r--r--release/picobsd/doc/src/how2build.html197
-rw-r--r--release/picobsd/doc/src/installflp.html99
-rw-r--r--release/picobsd/doc/src/intrinsics.html122
-rw-r--r--release/picobsd/doc/src/intro.html303
10 files changed, 0 insertions, 2359 deletions
diff --git a/release/picobsd/doc/src/Makefile b/release/picobsd/doc/src/Makefile
deleted file mode 100644
index c5f4aeb..0000000
--- a/release/picobsd/doc/src/Makefile
+++ /dev/null
@@ -1,17 +0,0 @@
-#
-# $FreeBSD$
-#
-
-.include "../../Version"
-
-DATE!="date"
-
-DOCS= bugs.html faq.html hardware.html how2build.html \
- intrinsics.html intro.html TODO.html installflp.html
-
-all: ../../Version
- for i in ${DOCS}; \
- do \
- cat $${i}|sed -e 's/@VER@/${VER}/g' \
- -e 's/@DATE@/${DATE}/g' >../$${i}; \
- done
diff --git a/release/picobsd/doc/src/TODO.html b/release/picobsd/doc/src/TODO.html
deleted file mode 100644
index c2bbf07e..0000000
--- a/release/picobsd/doc/src/TODO.html
+++ /dev/null
@@ -1,154 +0,0 @@
-<html>
-<! $FreeBSD$ >
-<body>
-<h1><center> Small FreeBSD ToDo List.
-</center></h1>
-
-<p>This list represents various tasks which are being collected from
-discussions on freebsd-small, and which represent the general
-direction and needs of using FreeBSD for small installations.</p>
-
-<p>The tasks are arranged by how important they are to the overall
-idea and goals of the project. If you are interested in doing some
-part of the work, please contact the coordinator of PicoBSD project
-(<A HREF="mailto:abial@freebsd.org">Andrzej Bialecki</a>).</p>
-
-<hr>
-
-<h2>Short term tasks:</h2>
-
-<ul>
-<li>
-Eliminate need for patching FreeBSD source tree - either by
-keeping our own version of Makefiles, or by adding (many) knobs to
-the standard ones. (NOTE: this will be resolved in v. 0.45).
-</li>
-<li>
-Provide options for building separate kernel and FS images of
-various sizes.
-</li>
-<li>
-Add some "wizards" to help people new to Unix configure "dialup"
-and "net" for most common tasks.
-</li>
-<li>
-Replace most of currently used scripts with Makefiles.
-(NOTE: this will be resolved in v. 0.45).
-</li>
-<li>
-Add simple authentication module to oinit.
-</li>
-<li>
-Fix kzip to be able to produce kzip'ped ELF kernels.
-(NOTE: currently we work around it by using kzipped /boot/loader).
-</li>
-<li>
-Write better documentation. This is very important - the most
-common configurations should be described in detail, step by step.
-</li>
-<li>
-Collect our experiences with using FreeBSD with SBCs, flash disks
-etc, and write a short practical guide to embedding FreeBSD.
-</li>
-</ul>
-<hr>
-
-<h2>Medium term tasks:</h2>
-
-<ul>
-<li>
-Change currently used crunched binaries to something more flexible
-- as it is now, even small change in set of programs requires
-rebuilding of the whole image.
-</li>
-<li>
-Change the building process so that it allows to easily choose
-(with finer granularity) needed components of the target system.
-</li>
-<li>
-Make use of recently added KLD to allow for easy adding and
-removing drivers when running stripped kernels.
-</li>
-<li>
-Investigate pros and cons of using the new boot/loader together
-with ELF kernels.
-(NOTE for v.0.43: it was simply mandatory to start to use it :-)
-</li>
-<li>
-Provide options for building systems which operate from
-(basically) read-only media, such as CD-ROM or flash disk. Such
-system doesn't need to keep all root FS in memory, but only small
-fraction of it for /tmp and /var.
-</li>
-<li>
-Integrate DHCP into "dialup" version.
-</li>
-<li>
-Rework oinit to be more modular, and write additional modules
-(remote access, SNMP (?), authentication, shell(), configuration
-editor).
-</li>
-<li>
-Provide a remote access (telnetd/login/shell) module for the
-"router" version. Make the shell() module more predictable and
-compatible with common sense :-)
-</li>
-<li>
-At last prepare usable version of ISP floppy, and test it (some
-basic tests with server PPP). This involves among others a version
-of PPP which supports Radius.
-</li>
-</ul>
-
-<hr>
-
-<h2>Long term tasks:</h2>
-
-<ul>
-<li>
-Either port ROMfs from Linux, or write our own replacement for it.
-</li>
-<li>
-Describe the configuration tasks and parameters of PicoBSD systems
-in terms of hierarchy of categories - this is needed to start
-working on the next two points.
-</li>
-<li>
-Design a flexible and efficient scheme (not necessarily compatible
-with currently used set of shell scripts) for storing and editing
-system configuration in some form of hierarchical DB.
-</li>
-<li>
-Design a user interface for configuration of system parameters
-and services, meeting the following requirements: hierachical,
-logical, helpful (hinting), providing ability to automate certain
-tasks.
-</li>
-<li>
-Reduce memory footprint.
-</li>
-<li>
-Add other language versions.
-</li>
-<li>
-Throw some more effort in porting the newer version of W (graphical
-UI), so that it uses VESA color modes. IMHO it's worth it.
-</li>
-</ul>
-
-<hr>
-
-<h2>Other half-baked ideas...</h2>
-
-<p>(fill this in :-)</p>
-
-<hr>
-Last modified:
-@DATE@
-
-
-<p><i>Send your comments, ideas, and most importantly the code itself, to
-<A HREF="mailto:abial@freebsd.org">abial@freebsd.org</a>.</i></p>
-
-</body>
-</html>
diff --git a/release/picobsd/doc/src/UCI.html b/release/picobsd/doc/src/UCI.html
deleted file mode 100644
index 5c0caaa..0000000
--- a/release/picobsd/doc/src/UCI.html
+++ /dev/null
@@ -1,960 +0,0 @@
-<html>
-<! $FreeBSD$ >
-<body>
-<h1><center> Unified Configuration Interface Project
-</center></h1>
-
-<p>The idea behind this project is to completely replace currently
-used configuration approach, which is based on several shell scripts, and to
-provide ability to change system behaviour basing on set of well-defined
-parameters' hierarchy. One of the goals is also to provide an object
-oriented model of the OS management and structure, instead of currently
-used (inconsistent) procedural model of system/service startup/shutdown.</p>
-
-<p>This project involves such issues as:
-<ul>
-<li>
-providing consistent view of the system and its functional subsystems as
-a set of interrelated objects equipped with certain properties.
-</li>
-<li>
-providing global approach to user interface, either command-line or with GUI
-front-ends.
-</li>
-<li>
-managing system resources and subsystems. This includes managing
-static and dynamic interdependencies between subsystems, ability to
-upgrade/downgrade specific subsystems on-the-fly.
-</li>
-</ul>
-</p>
-
-<p><i><b>This is work in progress</b> - I'm aware that many pieces
-are either completely missing or misplaced. Please send any comments and
-changes you seem appropriate either directly to me, or better to
-freebsd-small@freebsd.org. I'll gladly welcome anyone who can help with
-design and/or implementation.</i></p>
-
-
-<hr>
-
-<h1><center> Unified Configuration Interface
-</center></h1>
-
-<ul>
-<li>
-<p>Let's first introduce the following terms:
-<ul>
-<li>
-<b>management base</b> - the actual structure holding configuration and
-information data according to defined structure. This structure will most
-probably have a form of tree (possibly with cross-branch links or some other
-mechanism representing mutual dependencies) - the way it's stored is
-something which needs to be discussed.
-</li>
-<li>
-<b>user interface</b> - a method (and agent) for presenting data stored in
-management base in such a way that it can be viewed and modified by
-legitimate users.
-</li>
-<li>
-<b>system monitor</b> - an entity performing actual configuration and monitoring
-tasks, from one side dealing with management base, and from the other
-dealing with the system resources and subsystems, and from yet another dealing
-either directly with the user (thus acting as a user interface),
-or passing requests to other entity which acts as user interface.
-</li>
-<li>
-<b>subsystem</b> - a package containing programs, configuration data, as well
-as installing/deinstalling/start/stop stubs, which form together one logical
-entity performing specific services on behalf of the system. Each subsystem
-is viewed as an object with specific properties, dependencies, which is able
-to generate events, service general requests common to all such subsystems,
-and provide specific services to other subsystems.
-</li>
-</ul>
-</li>
-<li>
-<p>One possible approach to storing the management data is to use already
-existing framework known as MIB, as defined in applicable RFCs.</p>
-
-<p>This approach has several advantages: it represents well thought-out work
-of many experienced individuals and teams, it has already proven to be
-useful, it's widely used and accepted, it's easily extensible, it's able to
-represent quite complicated objects, etc.</p>
-
-<p>It has some drawbacks, as well: e.g. there is no standard mechanism for
-representing events and indirectly related objects, it tends to create
-deep and narrow trees which require to descent several levels to change some
-commonly used parameters, it doesn't say anything about the mutual
-dependencies between objects and parameters (except parent-child-sibling),
-and about required sequence to properly set their parameters, etc.</p>
-
-<p>These issues are not directly addressed in standards, and real
-implementations (known to me) have to implement these additional mechanisms
-"behind the scenes", so that their workings are not obvious nor easily
-accessible (let alone changeable).</p>
-
-<p>So, if we decide to use it, we need to address these issues somehow.
-The next point presents one possible approach to this dilemma.</p>
-</li>
-<li>
-<p>The term "object" used in the following discussion represents a functional
-subsystem, such as system service, usually performed by some specific
-process (or, a set of global system parameters, in which case the system
-monitor agent is the service itself). </p>
-
-<p>Each object represented in management base can be characterized by
-following properties:
-<ul>
-<li>
-its internal state, possibly consisting of several parameters and currently
-performed functions, but represented to the rest of the system as a symbolic
-state, one of set of states common to all objects.
-</li>
-<li>
-a temporary space for new sets of parameters, which are being supplied by
-other subsystems, prior to their actual application,
-</li>
-<li>
-FSM definition, describing state transitions in reaction to received events,
-</li>
-<li>
-list of events it can generate and accept,
-</li>
-<li>
-list of dependencies on other objects' states and services,
-</li>
-<li>
-list of requests it can handle,
-</li>
-<li>
-list of parameters it can accept and/or provide, with their valid ranges.
-</li>
-</ul>
-</p>
-
-<p>A few words on system startup: the system startup routines should ensure
-that dependencies can be unwound into linear, ordered list. If it's not
-possible, they should detect possible deadlocks at runtime, and act as an
-arbiter between conflicting parties (or signal an error). In case of
-unsatisfied dependency on some missing subsystem, the system monitor will
-act appropriately as described below (in paragraph on request handling).</p>
-
-<p>The <b>set of symbolic states</b> may consist of the following states,
-depicting object's current internal state (as described by its FSM):
-
-<center><table border>
-<tr><th>Name</th><th>Meaning</th></tr>
-<tr>
-<td>INIT</td><td>the subsystem is initializing itself, possibly loading
-necessary data and binaries from permanent storage.</td>
-</tr>
-<tr>
-<td>CHECK</td><td>performing consistency check on newly supplied parameter values</td>
-</tr>
-<tr>
-<td>READY</td><td>ready to start performing its primary function, but not started</td>
-</tr>
-<tr>
-<td>START</td><td>start-up tasks (related to its primary function, as opposed
-to INIT which is related to its own initialization)</td>
-</tr>
-<tr>
-<td>STOP</td><td>stop (shutdown) tasks (when the object intends to stop
-performing its function). This can involve unloading data and binaries from
-main memory.</td>
-</tr>
-<tr>
-<td>RUN</td><td>primary (work) phase</td>
-</tr>
-<tr>
-<td>IDLE</td><td>waiting for some external event to happen</td>
-</tr>
-<tr>
-<td>BUSY</td><td>the subsystem is busy (either with performing some
-high-priority task, or just simply hung), and cannot be interrupted without
-complete restart,</td>
-</tr>
-<tr>
-<td>ERROR</td><td>this object is either improperly configured, or
-malfunctioning</td>
-</tr>
-<tr>
-<td>(other...)</td><td>(other...)</td>
-</tr>
-</table></center>
-</p>
-
-<p>The <b>set of possible actions</b> may include the following actions:</p>
-
-<center><table border>
-<tr><th>Name</th><th>Meaning</th></tr>
-<tr>
-<td>LIST_EV_REQ</td><td>get list of events the subsystem can generate</td>
-</tr>
-<tr>
-<td>LIST_ACT_REQ</td><td>get list of actions the subsystem can respond to</td>
-</tr>
-<tr>
-<td>GET_DEF_REQ</td><td>get definition of given parameter (the arguments, and
-valid ranges)</td>
-</tr>
-<tr>
-<td>SET_REQ</td><td>set given parameter to given value (this value will
-be used only after COMMIT_REQ)</td>
-</tr>
-<tr>
-<td>GET_REQ</td><td>get currently used value of given parameter</td>
-</tr>
-<tr>
-<td>COMMIT_REQ</td><td>commit changes supplied in last transaction to currently
-used set of parameters</td>
-</tr>
-<tr>
-<td>ROLLBACK_REQ</td><td>revert last commit</td>
-</tr>
-<tr>
-<td>INIT_REQ</td><td>perform initialization tasks</td>
-</tr>
-<tr>
-<td>START_REQ</td><td>start performing primary function</td>
-</tr>
-<tr>
-<td>STOP_REQ</td><td>stop performing primary function</td>
-</tr>
-<tr>
-<td>RESTART_REQ</td><td>restart operation, possibly forcefully</td>
-</tr>
-<tr>
-<td>NOTIFY_REQ</td><td>notify me of any changes in your state</td>
-</tr>
-<tr>
-<td>CHECK_REQ</td><td>perform self-consistency check</td>
-</tr>
-<tr>
-<td>UPGRADE_REQ</td><td>upgrade the subsystem - this possibly involves
-downloading necessary pieces via network to permanent storage area. The
-upgrade process should be transactional, and should save the older version
-of the subsystem in case the DOWNGRADE_REQ should be issued.</td>
-</tr>
-<tr>
-<td>DOWNGRADE_REQ</td><td>downgrade the subsystem - restore the previous
-version of the subsystem from the copy on permanent storage.</td>
-</tr>
-<tr>
-<td>UNINSTALL_REQ</td><td>uninstall the subsystem completely - possibly
-freeing the space on permanent storage.</td>
-</tr>
-<tr>
-<td>(other...)</td><td>(other...)</td>
-</tr>
-</table></center>
-<p><i>(Each request includes source service identifier and credentials of
-the sender)</i></p>
-
-<p>The <b>set of events</b> which can be generated by subsystems may include
-the following:</p>
-
-<center><table border>
-<tr><th>Name</th><th>Meaning</th></tr>
-<tr>
-<td>EV_ACK</td><td>positive acknowledge of the last operation</td>
-</tr>
-<tr>
-<td>EV_NACK</td><td>negative acknowledge of the last operation</td>
-</tr>
-<tr>
-<td>EV_CHANGE</td><td>change notification (includes the name of changed
-parameter, and/or FSM state change)</td>
-</tr>
-<tr>
-<td>EV_DEP</td><td>signal the dependency on another subsystem - ask for
-existence of the service. Probably there should be two types of the dependency:
-a soft one (where the subsystem can still function even if the dependency is
-unresolved) and a hard one (when the existence and proper functioning of the
-other subsystem is mandatory for its function).</td>
-</tr>
-<tr>
-<td>(other...)</td><td>(other...)</td>
-</tr>
-</table></center>
-
-<p>One of event attributes can be a flag which says that this particular event
-is a directed, or broadcast message. In case of directed message, it should
-be forwarded only to interested parties. Broadcast message is sent to all
-subsystems.</p>
-
-<p>System monitor agent will process these events and route them to
-appropriate subsystems which are registered with it. Generally, if some
-subsystem is dependent on some other, it will want to also receive all events
-generated by the other subsystem.</p>
-
-<p>In case the subsystem
-is missing, and the system monitor received events signalling that some other
-subsystem is depending on it, the system monitor should arrange either for
-installing necessary pieces from some media (be it permanent storage, or the
-network), or to send an EV_NACK to the requesting subsystem. It's the
-responsibility of the requesting subsystem to deal with such case
-appropriately to the type of dependency (i.e. either "hard" or "soft").
-
-<p>Ideally, the system monitor agent will be equipped with routines to
-serialize the management data into human-readable form, so that it's easily
-stored, backed up, and repaired in case of inconsistencies.</p>
-</li>
-<li>
-<p>Actual user interface is still quite another story: I've seen UIs which
-merely followed the standard MIBs, and menus were composed of actual OID
-numbers plus DESCRIPTION field. In my experience, they are (barely)
-acceptable, though due to the usual width and depth of MIB trees you had to
-traverse several levels down and up in order to change some (protocol-wise)
-related parameters.</p>
-
-<p>More acceptable UI would collect interrelated items under common menu
-entries, irrespectibly of their actual position in the MIB tree.</p>
-
-<p>A worthwhile goal to pursue is to create such an UI which could guide
-you through the most common configuration tasks, while at the same time
-allowing for unrestricted and quick use by power users. This can be done
-either as a set of configuration "wizards" or extensive hinting, command
-completion, etc.</p>
-</li>
-<li>
-<p>The management database should be easily exportable via standard
-protocols, such as SNMP or LDAP.</p>
-
-<p>Most known to me (if not all) implementations of agents for these
-protocols are (contrary to their name) quite heavy-weight - so their use
-should be either optional, or replaced with some other light-weight
-protocol and a proxy agent running on other machine. One example of
-such proxy agent is existing UCD-SNMP implementation which in
-significant part follows the sysctl(3) tree, merely exporting it as
-a part of the MIB trees.</p>
-
-<p>It's worthwhile to consider also use of other protocols such as
-DHCP (and BOOTP), Service Location Protocol (SLP - RFC2165) for easy
-integration with LAN resources, easy initial configuration, and peer
-discovery.</p>
-</li>
-<li>
-<p>All operations performed by system monitor agent should be transactional,
-i.e. it should be possible to commit a set of changes as one logical entity,
-and be sure that either it's applied in whole, or not at all. This includes
-also ability to abort processing in the middle.</p>
-
-<p>This probably means that each object (subsystem) should be able to store
-not only its current configuration data, but also the newly supplied config
-data that are to be applied after the transaction ends successfuly.</p>
-
-<p>Operations should be verified against allowed values, as well as against
-allowed credentials, and basing on this either committed or aborted.</p>
-</li>
-<li>
-<p>A few notes on possible implementation of system monitor:</p>
-<ul>
-<li>
-let's assume that all configuration information is read on startup
-by some specialized daemon (this can be part of init(8) as well),
-which then performs role of communication agent through which passes
-all configuration information, be it request for change, request
-for info, request for start / shutdown, or notification about the change.
-</li>
-<li>
-configuration information itself is stored either in binary database, or as
-a filesystem hierachy mimicking configuration items hierarchy.
-</li>
-<li>
-each user-level program performing some task (such as routing daemon, inetd
-etc) is either equipped with the ability to communicate with config agent, or
-is relinked with special stub which fakes to the program necessary config
-files and events (such as signals to reread configuration).
-<p>This probably means also that some libc routines would have to be replaced,
-because they assume reading configuration from certain disk files.</p>
-
-<p>Since each such subsystem needs to implement some common actions such as
-installing, deinstalling, start/stop etc, we could use already present
-system of packages (with some minor modifications) to easily achieve
-part of the goals (i.e. install/deinstall/upgrade/downgrade/stop/start).</p>
-</li>
-<li>
-each subsystem performing some task requests its initial config data
-from system monitor, at the same time registering with it to receive
-configuration events, such as request to re-read data, to provide currently
-used config data, return status, react for signals, restarts, etc...
-</li>
-<li>
-system monitor acts as a meeting point for all producers and consumers
-of events and config data. It needs to maintain a table of registered
-subsystems, set of events they provide, set of events they want to receive,
-etc.. Basing on this table, it routes appropriate information to
-appropriate parties.
-</li>
-<li>
-user interface is then just one of clients of system monitor, albeit possessing
-special privileges.
-</li>
-<li>
-one of important tasks of system monitor, in case given
-object (subsystem) registers with it to be notified about certain events, is
-to ensure that such type of event can be possibly generated. This is to
-prevent subsystems from waiting for events coming from other non-existent
-subsystems. See the discussion above on satisfying dependencies.
-</li>
-</ul>
-<i><p>NOTE: this is one possible approach - a centralized one. It's worth to
-consider other approach, distributed, in which case each object (subsystem)
-sends and listens to the data at a meeting point specific to each other
-object. This eliminates (or drastically minimizes) the role of system
-monitor which is a single point of failure in centralized case.</p></i>
-</li>
-</ul>
-
-<hr>
-
-<p>Here is my initial proposal for the User Interface hierarchy:</p>
-
-<ul>
-<li>
-System configuration.
- <ol>
- <li>
- Boot device and file <br>
- <small>Name of the boot device (possibly networked) and boot
- image.</small>
- <ol>
- <li>
- (Enumeration of available devices)
- <ol>
- <li>
- (Enumeration of available files)
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- Config file <br>
- <small>Configuration file management - loading and saving, either
- local or remote (if applicable). </small>
- <ol>
- <li>
- Load / Save
- <ol>
- <li>
- Source / Destination <br>
- (Enumeration of available storage places, possibly
- networked)
- </li>
- </ol>
- </li>
- <li>
- Edit directly (geek mode)
- </li>
- </ol>
- </li>
- <li>
- Subsystems <br>
- <ol>
- <li>
- Module management <br>
- <small>Optional hardware drivers and protocol modules
- management.</small>
- <ol>
- <li>
- (Enumeration of available loadable modules)
- <ol>
- <li>
- Load / unload / status
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- Package management<br>
- <small>Management of basic and optional system services.</small>
- <ol>
- <li>
- (Enumeration of locally available packages)
- <ol>
- <li>
- Start / Stop / Status / Configure
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- Default source of service packages<br>
- <small>Where to automatically get the missing packages from.
- </small>
- <ol>
- <li>
- (Enumeration of available media) <br>
- (local and remote disks, ftp, http)
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- Resource management
- <ol>
- <li>
- Memory consumption <br>
- <small>This is entry point to a subtree, which allows to set
- up various resource limits for subsystems, services and
- processes.</small>
- </li>
- <li>
- Space consumption<br>
- <small>(Things like minimal free space on permanent storage..)
- </small>
- </li>
- <li>
- Task priorities
- <small>This includes not only currently running tasks, but all
- which can possibly be started.</small>
- <ol>
- <li>
- List / Modify
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- System console
- </li>
- <li>
- Virtual consoles (if applicable)
- </li>
- <li>
- System Date / Time Zone
- </li>
- <li>
- Banner
- </li>
- <li>
- Logging
- <ol>
- <li>
- Local logging
- </li>
- <li>
- Remote logging
- </li>
- </ol>
- </li>
- </ol>
-</li>
-<li>
-Network configuration.
- <ol>
- <li>
- Hostname and Domain
- </li>
- <li>
- Interfaces
- <ol>
- <li>
- (Enumeration of physical interfaces) <br>
- (Enumeration of virtual interfaces, if applicable) <br>
- (Options for creating virtual interfaces, if applicable)
- <ol>
- <li>
- Interface options (speed, media, encapsulation,
- description, etc.)
- </li>
- <li>
- ARP
- </li>
- <li>
- Bridging
- </li>
- <li>
- IP
- <ol>
- <li>
- Adress / netmask / alias
- </li>
- </ol>
- </li>
- <li>
- IPX
- </li>
- <li>
- AppleTalk
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- Protocol Options
- <ol>
- <li>
- IP, UDP, TCP, ARP, IPX, ATM ... <br>
- (Enumeration of available protocols)
- <ol>
- <li>
- (Enumeration of protocol specific options, such as
- buffer sizes, algorithms, ARP tables etc)
- <ol>
- <li>
- List / Add / Delete / Modify / Set (where
- applicable)
- </li>
- </ol>
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- Routes
- <ol>
- <li>
- List
- </li>
- <li>
- Static
- <ol>
- <li>
- Add / Delete / List
- <ol>
- <li>
- (route expression)
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- Dynamic
- <ol>
- <li>
- (Enumeration of available routing protocols)
- <ol>
- <li>
- Add / Delete / List
- <ol>
- <li>
- (route expression)
- </li>
- </ol>
- </li>
- </ol>
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- Network services
- <ol>
- <li>
- DNS
- <ol>
- <li>
- Hosts
- <ol>
- <li>
- Add / Delete / List
- <ol>
- <li>
- (hosts definitions)
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- Resolvers
- <ol>
- <li>
- Add / Delete / List
- <ol>
- <li>
- (hosts addresses)
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- Local DNS server config
- </li>
- </ol>
- </li>
- <li>
- PPP
- <ol>
- <li>
- Server
- </li>
- <li>
- Client
- </li>
- </ol>
- </li>
- <li>
- NFS
- <ol>
- <li>
- Server
- </li>
- <li>
- Client
- </li>
- </ol>
- </li>
- <li>
- NIS
- </li>
- <li>
- DHCP
- <ol>
- <li>
- Add / Delete / Reserve / List
- <ol>
- <li>
- (IP address expressions)
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- SNMP
- <ol>
- <li>
- Protocol version
- </li>
- <li>
- Send traps to...
- </li>
- <li>
- Access Control Lists <br>
- <small>(This is either full-blown ACL system in case
- of SNMPv2, or a community string for SNMPv1.)</small>
- </li>
- </ol>
- </li>
- <li>
- Printing
- <ol>
- <li>
- Local / Remote
- <ol>
- <li>
- Printers
- <ol>
- <li>
- Add / Modify / Delete / List
- </li>
- </ol>
- </li>
- <li>
- Queues
- <ol>
- <li>
- Priority / Delete / List
- </li>
- </ol>
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- SMB services
- </li>
- <li>
- Network Address Translation
- </li>
- <li>
- Packet filters
- </li>
- <li>
- Bandwidth Manager
- </li>
- <li>
- NTP
- </li>
- <li>
- Remote Access
- </li>
- </ol>
- </li>
- </ol>
-<li>
-User management.
- <ol>
- <li>
- User accounts
- <ol>
- <li>
- Add / Delete / Modify / List
- <ol>
- <li>
- Name / Password / ACL
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- User profiles
- <ol>
- <li>
- Access Control Lists.
- <ol>
- <li>
- Add / Delete / Modify / List
- <ol>
- <li>
- Name / Template / Definition
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- ACL Templates
- <ol>
- <li>
- Add / Delete / Modify / List
- <ol>
- <li>
- Name
- <ol>
- <li>
- Command restrictions list
- </li>
- <li>
- Location restrictions list
- </li>
- <li>
- Resources restrictions list
- </li>
- <li>
- Time restrictions list
- </li>
- <li>
- Authentication methods
- <ol>
- <li>
- Unix passwd
- </li>
- <li>
- S/Key
- </li>
- <li>
- Kerberos
- </li>
- <li>
- Radius
- </li>
- <li>
- TACACS
- </li>
- </ol>
- </li>
- </ol>
- </li>
- </ol>
- </li>
- </ol>
- </li>
- </ol>
- </li>
- </ol>
-</li>
-<li>
-Other services
- <ol>
- <li>
- Cron tasks
- </li>
- </ol>
-</li>
-<li>
-Filesystems.
- <ol>
- <li>
- Local / Remote
- <ol>
- <li>
- (Enumeration of available FS-s)
- <ol>
- <li>
- FS / Mounting point / Options
- </li>
- </ol>
- </li>
- <li>
- Swap Partition / Swap File
- <ol>
- <li>
- Create / Turn on
- </li>
- </ol>
- </ol>
- </li>
- </ol>
-</li>
-<li>
-Environment
- <ol>
- <li>
- Set / Unset / List
- </li>
- </ol>
-</li>
-<li>
-System status
- <ol>
- <li>
- (Enumeration of available status items)
- </li>
- </ol>
-</li>
-<li>
-Diagnostics
- <ol>
- <li>
- Debug
- <ol>
- <li>
- (Enumeration of subsystems hierarchy, those of which can
- provide debugging data)
- <ol>
- <li>
- Set / Clear / Level
- </li>
- </ol>
- </li>
- </ol>
- </li>
- <li>
- System messages
- </li>
- <li>
- Ping / traceroute / rtquery
- </li>
- </ol>
-</li>
-</ul>
-
-<hr>
-<i>
-<p>Please send your comments to <A HREF="mailto:abial@freebsd.org">
-Andrzej Bialecki</a></p>
-<p>Last modified:
-@DATE@
-</p>
-</i>
-
-</body>
-</html>
diff --git a/release/picobsd/doc/src/bugs.html b/release/picobsd/doc/src/bugs.html
deleted file mode 100644
index f7c91c9..0000000
--- a/release/picobsd/doc/src/bugs.html
+++ /dev/null
@@ -1,152 +0,0 @@
-<HTML>
-<! $FreeBSD$ >
-<HEAD>
- <TITLE>History and Bug fixes</TITLE>
-</HEAD>
-<BODY>
-
-<center><h1>History and List of Bugfixes</h1></center>
-
-<p>This is the short release history of PicoBSD, as well as the list of bugs
-which were found. Some of them were already corrected, so that you should read
-the list before reporting a new one.</p>
-
-<p>We tried to make this software bug-free, but life is life... Sorry for the
- inconvenience.</p>
-
-<h3>PicoBSD 0.44</h3>
-<ul>
-<li>
- 1999.05.10: Slightly refreshed version to match 3.2-RELEASE.
- No significant changes (yet)... :-(
-</li>
-</ul>
-<h3>PicoBSD 0.43</h3>
-<ul>
-<li>
- 1999.01.19: A lot of fixes related to architectural changes in
- 3.0-current code. Most importantly, we run now ELF kernel and we use
- the new bootloader. This is most probably the last release of PicoBSD in
- its present shape - the next version will (hopefully) become a part of
- normal release building process.
-</li>
-</ul>
-
-<h3>PicoBSD 0.42</h3>
-<ul>
-<li>
- 1999.01.15: Well, it seems that this version was for developers
- only... ;-) It was abandoned when recent massive changes in -current
- demanded more serious measures...
-</li>
-<li>
- 1998.10.15: Small fixes and updates to match the 3.0-RELEASE
- source tree. The binary snapshot built from 3.0-R sources will
- soon follow...
-</li>
-</ul>
-
-<h3>PicoBSD 0.41</h3>
-<ul>
-<li>
- 1998.10.12: Two small buglets has been discovered, and fixed in CVS
- copy of the sources. 'kget' utility was dumping core due to unexpected
- change in behaviour of dumpnlist. 'ns' utility poorly handled other
- netmasks than class C network.
- <p>I prepared new tar archive containing these corrected sources.</p>
-</li>
-<li>
- 1998.09.26: Yes, this took more than just "a few days"... :-(. This is
- mainly a bugfix release of 0.4 - almost no new features were added,
- except the 'dmesg' to examine kernel messages buffer. Also, all
- programs are compiled in ELF format. SNMP services are provided now
- by UCD-SNMP v.3.5.
-
- <p>Unfortunately, I had to remove DEVFS for now - there are too many
- problems with it for now. This also means that we're back to creating
- device nodes manually, and chances are that the one you need is
- missing... </p>
-</li>
-</ul>
-
-<h3>PicoBSD 0.4</h3>
-<ul>
-<li>
- 1998.08.28: Serious bug was discovered in MFS code (thanks to Eric
- P. Scott for detailed bug report!). Though the bug itself is in
- FreeBSD-current kernel code and not in the PicoBSD-specific sources,
- it makes PicoBSD very fragile and easy to crash.
- <p>Some people are already working on it, so expect the fixed version
- in a few days. Its availability will be noted here, on this page,
- so keep an eye on it.</p>
-</li>
-<li>
- 1998.08.27: PicoBSD source tree is now a part of official FreeBSD
- source tree (you can find it in src/release/picobsd). From now on,
- all the fixes and changes will go directly to this tree, and from
- time to time I'll be preparing a stand-alone snapshot of the sources.
-</li>
-<li>
- 1998.08.19: PicoBSD 0.4 released.
- <p>New features include: NATd,
- netstat, DEVFS/SLICE instead of standard /dev, additional network
- drivers, and several minor fixes. Distribution contains also
- a collection of small versions of system programs (TinyWare), among
- them custom init(8).</p>
- <p>I added also the fourth type of setup - 'router' - which is a
- specialized version of PicoBSD that focuses on providing as small
- as possible router solution.</p>
-</li>
-</ul>
-<h3>PicoBSD 0.31</h3>
-<ul>
-<li>
- 1998.03.28: Some people reported that the binary files (*.flp) were
- being corrupted during download because their browsers assumed that
- these are text files. I changed the names to *.bin - their contents
- is the same.
-</li>
-<li>
- 1998.03.20: PicoBSD 0.31 released. New features include: SNMP daemon,
- better creation of /kernel.config, some other minor fixes. Massive
- changes in the building scripts. I also removed vn(4) driver from
- "net" and "isp" floppies.
-</li>
-</ul>
-<h3>PicoBSD 0.3</h3>
-<p>The following bugs were found in this release of PicoBSD:</p>
-<ul>
-<li> 1998.02.27: A bug in kget(8) utility caused it to dump core in certain
- situations. As a consequence, it wasn't possible to save the changes
- made in UserConfig (-c). This will be corrected in the next release (or
- bugfix issue).
-</li>
-<li> 1998.02.24: Wrongly sized MFS caused the passwd(1) on "net" type
- floppy to fail because of lack of space for temporary files. This bug
- affected only "net" floppies, and of course the scripts ("2000" looks
- quite similar to "2200" :-(( ). Also, the 'update' script didn't work
- as expected...
-<p> This was fixed the same day, and the corrected files are: pb03en1.zip,
- pb03pn1.zip, and pbsd-s031.tgz respectively. They are now under standard
- links on the main page of PicoBSD project, so if you downloaded after
- this date, you shouldn't worry.</p>
-<p> Please check that you have the fixed versions - the archive name should
- contain the tiny number, such as "pb03en<b>1</b>.zip", or
- pbsd-s03<b>1</b>.tgz".</p>
-<li>
- 1998.02.15: PicoBSD 0.3 released. This is the first version that I can
- truly recommend - previous one was too buggy... :-)
-</li>
-</li>
-</ul>
-
-<h5>Last modified:
-@DATE@
-</h5>
-
-<HR align="center" width="100%">
-<CENTER><h5>Any comments? Send them to
-<A HREF="mailto:abial@freebsd.org">the author</A> </h5></CENTER>
-
-</BODY>
-</HTML>
diff --git a/release/picobsd/doc/src/faq.html b/release/picobsd/doc/src/faq.html
deleted file mode 100644
index 4a0d34e..0000000
--- a/release/picobsd/doc/src/faq.html
+++ /dev/null
@@ -1,243 +0,0 @@
-<HTML>
-<! $FreeBSD$ >
-<HEAD>
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="Author" CONTENT="Dinesh Nair">
- <META NAME="Description" CONTENT="Frequently Asked Questions for PicoBSD">
- <META NAME="Keywords" CONTENT="PicoBSD,FreeBSD,Unix,Dinesh Nair,Andrzej Bialecki,Network Computer">
- <META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) [Netscape]">
- <TITLE>PicoBSD FAQ</TITLE>
-</HEAD>
-<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EF" VLINK="#51188E" ALINK="#FF0000">
-
-<CENTER>
-<H1>
-The PicoBSD FAQ
-</H1></CENTER>
-
-<CENTER>
-<HR WIDTH="100%"></CENTER>
-<p><B>What is PicoBSD ?</B></p>
-
-<P>PicoBSD is a floppy sized version of popular operating system FreeBSD.
-It fits within a single bootable 1.44MB floppy and runs on a minimum i386
-with 8MB RAM. PicoBSD currently comes in four flavours: dialup, net, router and
-isp. For a description of how each of the flavours differ, take a look
-at the <B><A HREF="http://www.freebsd.org/~picobsd/picobsd.html">PicoBSD
-home page</A></B>.
-
-<p><B>What is this "pico" in the name?</B></p>
-
-<p>It's an SI measure unit, which is equivalent of 10e<sup>-12</sup>.
-This is a good approximation of more colloquial "extremely small".</p>
-
-<p>You can also think of normal FreeBSD as a system infested with
-fully grown daemons, and PicoBSD as a system infested with
-"the little people" :-). </p>
-
-<P><B>What version of FreeBSD is PicoBSD based on ?</B></p>
-
-<P>PicoBSD has versions based on FreeBSD 3.2-RELEASE, 4.0-current and
-FreeBSD 2.2.5-RELEASE.
-<A HREF="mailto:abial@freebsd.org">Andrzej Bialecki</A> maintains the <A HREF="http://www.freebsd.org/~picobsd/picobsd.html">FreeBSD
-3.x-RELEASE and -current versions</A> and
-<A HREF="mailto:dinesh@alphaque.com">Dinesh Nair</A>
-maintains the <A HREF="http://info.net-gw.com/picoBSD/">FreeBSD
-2.2.5-RELEASE</A> version. Both the versions are different:
-<UL TYPE=CIRCLE>
-<LI>
-the 3.x-RELEASE version is the one actively maintained, and provides support
-for many new devices</li>
-
-<LI>
-the 2.2.5-RELEASE version is not maintained anymore - the only difference is
-that it has lynx on board.</li>
-</UL>
-
-<p><b>What is current version of PicoBSD?</b></p>
-
-<p>Current version of PicoBSD is @VER@.</p>
-
-<P><B>What can PicoBSD do?</B></p>
-
-<P>With the TCP/IP capabilities of FreeBSD included in and based on the
-strong 4.4BSD TCP/IP stack, PicoBSD can be used as a low cost Network Computer.
-With a text based HTML 3.2 compliant browser (2.2.5-RELEASE version only)
-and Internet access tools such as telnet and ftp, it can serve as a low
-cost Internet dialup client. With support for mounting MSDOS and Unix harddisks,
-it also can be used as a portable OS which you can carry around in a floppy.
-The net and isp flavours would allow you to make use of those redundant
-i386es as a low cost router or dialin PPP server. With SNMP and firewall
-support built-in, PicoBSD provides the functionality of dedicated routers
-and dialin terminal servers.
-
-<P><B>What are PicoBSD's minimum requirements?</B></p>
-
-<P>PicoBSD runs on a minimum i386 with 8MB RAM for the dialup flavour and
-10MB RAM for the net and isp flavours. Diskspace requirements are a single
-1.44MB floppy. For on-demand PPP access, a modem would be required, either
-external or internal.
-For LAN access, an Ethernet NIC (support for 3Com, NE2000 etc available)
-would also be required.
-<p>In case of "router" flavor, its requirements are even smaller: it can
-run in as low as 4MB of RAM, on a 386SX CPU.</p>
-
-<P><B>Where do I get PicoBSD?</B></p>
- PicoBSD is available at the following
-locations:
-<UL TYPE=CIRCLE>
-<LI>
-<A HREF="http://www.freebsd.org/~picobsd/picobsd.html">PicoBSD based on
-FreeBSD 3.0-RELEASE and -current</A> maintained by Andrzej Bialecki</LI>
-
-<LI>
-<A HREF="http://info.net-gw.com/picoBSD/">PicoBSD based on FreeBSD 2.2.5-RELEASE</A>
-prepared by Dinesh Nair</LI>
-</UL>
-Additional mirror sites will be brought online as demand increases. If
-you're interested in mirroring the PicoBSD distribution, please get in
-touch with <A HREF="mailto:dinesh@alphaque.com">Dinesh Nair</A> or
-<A HREF="mailto:abial@freebsd.org">Andrzej Bialecki</A>.
-
-<P><B>How do I copy it to the floppy?</B></p>
-
-<P>The binary images provided as part of the PicoBSD distribution are 1.44MB
-sized floppy images. They cannot be copied to a floppy using the <I>MSDOS
-COPY</I> or <I>Unix cp</I> commands. Instead, an image copy must be done
-using tools such as&nbsp; <A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/tools/rawrite.exe">rawrite.exe</A>
-or f<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/tools/fdimage.exe">dimage.exe</A>
-under MSDOS and <B>dd</B> under Unix.
-
-<P>Under DOS you would do something like this:
-<UL>
-<PRE><B>C:\> fdimage.exe picobsd.flp a:</B></PRE>
-</UL>
-while under Unix you would use something like:
-<UL><B>dd if=picobsd.flp of=/dev/rfd0</B></UL>
-
-<p><B>How do I configure dialup PPP access on the Dialup flavour?</B></p>
-
-<P>There is an auto-configuration script to configure PPP dialup access.
-Run <I>/stand/dialup</I> after booting up from the floppy and make the
-relevant menu selections. Once you've tested it to work, you should make
-your changes permanent by committing them to the floppy using <I>/stand/update</I>.
-
-<P><B>How do I set my DNS server ?</B></p>
-
-<P>Use the provided <I>/stand/ee</I> editor and edit <I>/etc/resolv.conf</I>.
-Replace the <U>domain</U> with your domain and change the <U>nameserver</U>
-IP address to your nameserver or your ISP's nameserver. You may have as
-many <U>nameserver</U> lines as you want. Don't forget to run <I>/stand/update</I>
-to commit your changes to the floppy.
-<p>NOTE: starting with version 0.4, the <i>dialup</i> script asks you to
-set your nameserver as well as default domain name.</p>
-
-<p><b>I can't execute the <i>/stand/update</i> on the "router" floppy.</b></p>
-<p>The "router" floppy doesn't contain any real shell, so some commands work
-differently (and some don't work at all). In order to use this script you
-have to 'source it in', i.e.:
-<pre>
- (48)/# pwd
- /
- (48)/# . /stand/update
-</pre>
-
-<P><B>How do I set my hostname ?</B></p>
-
-<P>Edit /<I>etc/rc.conf</I> and change the value of the <U>hostname</U>
-variable.
-
-<p><b>PicoBSD has "mkdir" but not "rmdir". How can I delete
-subsdirectories?</b></p>
-<p>"rm -d" will delete directories.</p>
-
-<p><b>Can I use a modem configured on COM3/COM4 instead of COM1, COM2?</b></p>
-
-<p>Yes, but these ports are initially disabled - most machines have only
-two serial ports anyway. You have to enable them in UserConfig.</P>
-<p>Here are the preferred settings:</p>
-<ul>
-<li> sio0=COM1: port 0x3f8, irq 4, used by default for mouse (/dev/cuaa0)
-</li>
-<li> sio1=COM2: port 0x2f8, irq 3, used by default for modem (/dev/cuaa1)
-</li>
-<li> sio2=COM3: port 0x3e8, irq 5, disabled by default
-</li>
-<li> sio3=COM4: port 0x2e8, irq 10, disabled by default
-</li>
-</ul>
-
-<p><b>I see a configuration conflict the first time I boot PicoBSD. What
-should I do?</b></p>
-
-<p>Disable those devices which are not present in your machine. If there is
-still some conflict, change the settings (I/O port, IRQ etc.).</p>
-
-<p><b>Exception:</b> if you're using a PS/2 mouse, the visual configuration
-tool will display CONF for sc0 and psm0. The default settings are correct,
-and you should simply ignore the warning.</p>
-
-<p><b>What kind of SCSI support is there?</b></p>
-
-<p>None. Either build your own version of PicoBSD, or just install normal
-FreeBSD distribution.</p>
-
-<p><b>Using version 0.4 I get many strange messages on my console...</b></p>
-<p>This is related in large part to DEVFS subsystem - it is still somewhat
-experimental, and its author left some diagnostics turned on.. They are
-harmless. Versions 0.4x, x>0 don't use DEVFS at all, as it was too
-experimental to work reliably...</p>
-
-<P><B>How do I connect using PPP ?</B></p>
-
-<P>Just run the PPP process, <I>/stand/ppp</I>. at the <B>ppp on pico></B>
-prompt, type <U>dial</U> and sit back and wait for the modem to sing it's
-mating tunes. When the <B>ppp on pico></B> prompt is capitalized to <B>PPP
-on pico></B>, you've managed to succesfully achieve a link-level PPP and
-TCP/IP connection with your ISP. Additionally, the PPP program will enter
-<I>Packet Mode</I>. Remember, don't <U>quit</U> or <U>close</U> the PPP
-connection if you want to continue to access the Internet.&nbsp; Type <U>help</U>
-at the <B>ppp on pico></B> prompt for a list of PPP commands.
-
-<P><B>The PPP process is running on my screen. How do I use the browser
-or telnet to a host ?</B></p>
-
-<P>PicoBSD has many virtual terminals, 10 on the dialup flavour. You have
-run PPP on the first virtual terminal. You can switch to the others and
-run the browser and telnet clients there. Switching thru the VTs is done
-by ALT-F1 for VT0, ALT-F2 for VT1, ALT-F3 for VT2 etc. From these terminals,
-you could use telnet or the lynx browser cum newsreader.
-
-<p><b>I can't establish a PPP connection. The mouse pointer randomly appears
-and disappears. and moving the mouse has no effect.</b></p>
-
-<p>You have the mouse driver configured to use the modem's serial port.
-Issue a 'ps -ax', remember the pid (process ID) of 'moused', then issue a
-'kill -9 <pid>'. Edit /etc/rc.conf to specify the correct mouse port. Issue
-an 'update' commmand to save new configuration to the floppy, and reboot.</p>
-
-<P><B>I saved my lynx configuration but it was not there when I rebooted.
-Why ?</B>
-
-<P>The lynx configuration is saved in <I>/etc/lynx.cfg</I>. You should
-run /<I>stand/update</I> to commit this to the floppy when you change the
-configuration. In effect, anything you change in /etc can be committed
-by running /<I>stand/update</I>.
-
-<P><B>How come there are no manual pages ?</B></p>
-
-<P>Well, this is a floppy-sized OS, so there's not enough space for full
-manpages. Instead, short help descriptions are given with the <I>/stand/help</I>
-program. If you need more detailed descriptions, take a look at the <A HREF="http://www.freebsd.org/handbook/">FreeBSD
-Handbook</A> or the <A HREF="http://www.freebsd.org/">FreeBSD Home</A>.
-<BR>&nbsp;
-<BR>&nbsp;
-<HR WIDTH="100%">
-<CENTER><FONT SIZE=-1>More FAQ points will be added as feedback from the
-PicoBSD user community comes in. And big thanks to all of you who already
-sent us some suggestions!</FONT></CENTER>
-<P><B><FONT SIZE=-1>Last Modified:
-@DATE@
-</FONT></B></P>
-</BODY>
-</HTML>
diff --git a/release/picobsd/doc/src/hardware.html b/release/picobsd/doc/src/hardware.html
deleted file mode 100644
index 0afede2..0000000
--- a/release/picobsd/doc/src/hardware.html
+++ /dev/null
@@ -1,112 +0,0 @@
-<html>
-<! $FreeBSD$ >
-<body>
-<h1><center>Lists of supported hardware configurations.</center></h1>
-
-<p>Below you will find supported configurations for each of the flavors of
-PicoBSD as of version @VER@, as well as the lists of programs included.</p>
-
-<h3>Dialup version:</h3>
-<ul>
-<li>minimum 386SX CPU (either Intel, AMD, Cyrix etc - doesn't matter),
-</li>
-<li>minimum 8MB of RAM (some people reported success
-stories with 4MB only, but I certainly don't recommend it)
-</li>
-<li>a modem (for Internet connection using PPP protocol), either internal or
-external, connected to COM1-COM4. NOTE: COM3 and COM4 are disabled by default
-- you have to explicitly enable them in UserConfig.
-</li>
-<li>an Ethernet card for LAN connection:
-<ul>
-<li> ed - default settings: port 0x280, irq 10, iomem 0xd8000
- <p>NE2000 compatible ISA and PCI cards, most SMC and 3C503</p>
-</li>
-<li> ep - default settings: port 0x300, irq 10,
- <p>3C509 ISA card</p>
-</li>
-<li> ie - default settings: port 0x300, irq 10, iomem 0xd0000
- <p>Intel EtherExpress ISA, StarLan, 3C507</p>
-</li>
-<li> le - default settings: port 0x300, irq 5, iomem 0xd0000
- <p>DEC EtherWorks 2 and 3</p>
-</li>
-<li> lnc - default settings: port 0x280, irq 10, iomem 0xd0000
- <p>Lance/PCNet</p>
-</li>
-<li> de - DEC21040-based PCI cards,
-</li>
-<li> fxp - Intel EtherExpress Pro/100B PCI card
-</li>
-</ul>
-</li>
-<li>10 virtual consoles plus console utilities (vidcontrol, kbdcontrol)
-</li>
-<li>basic networking tools: ifconfig, route, ping, ns (mini-netstat),
-traceroute
-</li>
-<li>basic remote access tools: telnet, ftp and SSH
-</li>
-<li>basic OS tools: shell, mount (FreeBSD, DOS, Linux), umount, ps, kill, vm
-(mini-vmstat), fsck, df, etc..
-</li>
-<li>editable configuration (/etc directory and kernel configuration)
-</li>
-<li>simple editor ee
-</li>
-<li>simple help system for people new to FreeBSD
-</li>
-</ul>
-<h3>Router-like version:</h3>
-<ul>
-<li>minimum 386SX CPU,
-</li>
-<li>minimum 10 MB of RAM (8MB for basic setup)
-</li>
-<li>support for PPP protocol on dialup/leased lines (using ijppp)
-</li>
-<li>support for several types of Ethernet cards (two of each kind) - see above
-for descriptions: ed, ie, ep, de, fxp, lnc
-</li>
-<li>network daemons: routing daemon (routed), inetd, telnetd.
-</li>
-<li>IP Firewall and NAT daemon (natd).
-</li>
-<li>more OS utilities, including: syslogd, mount_nfs, network logins via
-telnet
-</li>
-<li>this version doesn't include: ssh, ftp
-</li>
-</ul>
-<h3>Router version:</h3>
-<ul>
-<li>minimum 386SX CPU,
-</li>
-<li>minimum 4 MB of RAM (6MB for running some additional daemons)
-</li>
-<li>support for PPP protocol on dialup/leased lines (using kernel ppp)
-</li>
-<li>support for several types of Ethernet cards - see above
-for descriptions: ed, ie, ep, de, fxp, lnc
-</li>
-<li>custom init(8), which includes also a simple command-line interface,
-and its own way to configure the system on startup.
-</li>
-<li>IP Firewall and NAT daemon (natd - it requires additional portion of RAM).
-</li>
-<li>very few OS tools, except those absolutely necessary,
-</li>
-</ul>
-
-<p>There's also the fourth version, which can serve as a dialin server - I hope
-you'll find it as a cheap yet reliable alternative to commercial communication
-servers :-)) This work is still in progress, and
-<A HREF="beta.html">I need some people to test</a> the early
-dial-in server version.</p>
-
-<hr>
-<i>Last modified:
-@DATE@
-</i>
-</body>
-</html>
diff --git a/release/picobsd/doc/src/how2build.html b/release/picobsd/doc/src/how2build.html
deleted file mode 100644
index 12303be..0000000
--- a/release/picobsd/doc/src/how2build.html
+++ /dev/null
@@ -1,197 +0,0 @@
-<html>
-<! $FreeBSD$ >
-<head>
-<title>PicoBSD Development Kit</title>
-</head>
-<body>
-<h1><center> How to build your own version
- of PicoBSD?
-</center></h1>
-
-<ol>
-<li>
-<p> Beginning with version 0.4, PicoBSD sources are maintained as
- part of official FreeBSD CVS repository, so
- you can find them in src/release/picobsd.</p>
-</li>
-<li>
- Become root. You'll need to mount and unmount various volumes.
-</li>
-<li>
- Make sure you are running kernel with support for md(4) devices.
- If you run plain GENERIC (just as it was installed on your system),
- you'll need to recompile you kernel and reinstall it. See the
- appropriate entries in The Handbook (/usr/share/doc/handbook).
-</li>
-<li> Change working directory (<code>cd build</code>) and run the
- <code>./picobsd</code> script. Select target language, size of MFS and
- one of pre-canned setups (personal dialup, dialin server or
- router-like). Details of each setup are contained in dial/,
- router/, isp/ and net/ directories respectively. You should at least
- check <code>${TYPE}/config/PICOBSD</code> file to make sure it contains
- the drivers you want.
-
-<p> You can also choose a special type called 'custom'. You'll need to
- supply the full path to your own custom config tree constructed
- exactly like one of the standard config directories. Also, you'll
- probably want to adjust the number of inodes on MFS - see the
- <code>stage1</code> script and look for <code>INODES=</code>.</p>
-
-<p> I also recommend to adjust the ISA devices parameters to
- match the ones of your hardware - though PicoBSD can save the
- changes from UserConfig, this way it will produce smaller
- <code>/kernel.config</code> file.</p>
-</li>
-<li> I assume you will use 1.44MB floppy. If not, please edit the file
- <code>build/stage3</code>.
-</li>
-<li> There are several directories which contain some sources and config
- files:
-<pre>
- build/ main build directory; you MUST cd here!
- dial/ config files for dialup setup
- conf/ kernel config file
- crunch1/ crunch of system programs
- mfs.tree/ contains the MFS configuration
- lang/ contains language-dependent files
- floppy.tree/ contains the startup floppy hierarchy
-
- isp/ config files for dialin server setup
- ... (as above)
- net/ config files for router-like setup
- ... (as above)
- tinyware/ collection of small system utilities
- tools/ additional tools them needed during build
-</pre>
-<p> There are no <code>/etc/passwd</code> nor <code>/etc/pwd.db</code>
- files on the "dial" floppy - in case of other types, they are
- reconstructed from <code>/etc/master.passwd</code> on each startup
- (and then put on MFS with the rest of <code>/etc</code>).
- In case of "dial" type floppy, you don't need them at all.</p>
-
-<p> NOTE: thanks to the above, the floppy is needed only during startup,
- and then only if you want to synchronize (possibly changed) MFS /etc
- with the one on the floppy. It means that you can pull off the floppy
- from the drive as soon as <code>login:</code> prompt appears.
- In other words, it is almost equal to read-only floppy.</p>
-</li>
-<li> Edit the set of installed programs.
-<ul>
-<li> Go to <code>${TYPE}/crunch1</code> directory, and edit it
- to suit your needs. Keep in mind that floppies aren't made
- of rubber... :-)
-</li>
-<li> There are some patches included in these directories, which
- are applied during build process to some of the Makefiles in
- your <code>/usr/src</code>. These patches attempt to decrease
- the size of some programs by cutting off rarely/unlikely used
- parts. The patches are reversed when you do a
- <code>make clean</code> (or <code>build/clean</code>
- for that matter).
-<p> NOTE: patches may fail to apply, if your sources are too
- different from the ones I used. Don't worry: they are so
- straightforward that you can apply them by hand.</p>
-</li>
-<li> In order to have a functioning system you MUST include at
- least <code>/stand/init</code>, or <code>/stand/oinit</code>,
- or <code>/stand/sysinstall</code> in
- your <code>crunch.conf</code>. Of course these can be your
- own programs... But if you install the stock
- <code>/sbin/init</code>, you
- also have to install some others, like sh, getty, login etc...
-<p> This release of PicoBSD contains a small replacement for
- init(8), called 'oinit'. You can find it in TinyWare
- collection. The main building script allows you to use it
- instead of normal init(8). <b>Be sure to read the oinit's docs
- before you decide to use it!</b></p>
-</li>
-</ul>
-</li>
-<li> Make sure that the system you're running has /dev/md0* entries in
- /dev directory (if not, and you dont have DEVFS running, you can
- make them with 'MAKEDEV md0'), AND
- that your running kernel has built-in memory file device (there
- should be a line in your kernel config file stating 'device md').
-</li>
-<li> You'll need at least 9MB of free disk space, and free /mnt directory.
-</li>
-<li> Do a <code>cd build/</code> and fire off the <code>./picobsd</code>
- script. Select the build parameters or 'n' for 'no change'. If all
- is well, after some time (like 10-30m) you end up with a
- 'picobsd.bin' file in this directory.
-
-<p> WARNING: make sure you don't have stale <code>.depend</code> files
- around!!! You may encounter many strange errors during build process
- in that case.</p>
-
-<p> If there were any errors, please execute each script by hand and try
- to find what causes this error. Most often this will be one of the
- following reasons:</p>
-<ul>
-<li> <code>crunchgen</code> can't find the source directory for a
- program 'proggy':
-<ul>
-<li> make sure that the source directory for 'proggy' is called
- 'proggy', otherwise the crunchgen won't find it
-</li>
-<li> make sure that the Makefile allows crunchgen to deduce the
- set of objects to build. You can manually add an OBJS= ...
- to the program's Makefile.
-</li>
-</ul>
-</li>
-<li> crunch fails to build.
-<ul>
-<li> check your system source tree for stale .depend files and/or
- objects (*.o)
-</li>
-<li> see if the individual programs can be built using original
- Makefiles. If not, cvsup the correct sources.
-</li>
-</ul>
-</li>
-<li> /: write failed - file system is full
-<ul>
-<li> this one is obvious - you wanted to put too many programs on
- the MFS and/or the target floppy. Or, you really don't have
- any space left on the root partition.. :-)
-</li>
-<li> also, you can check if the
- MFS size is correctly reported while it's still mounted (right
- after <code>stage1</code> script ends).
-</li>
-</ul>
-<li> the build process displays "Preparing MFS" and then
- silently stops. In this case check if you're running it as
- root, and that you run kernel with support for md(4)
- devices. Also, you can add 'set -x' at hte beginning
- of the scripts to see exactly where they stop.
-</li>
-</ul>
-
- You can also remove <code>2>&amp;1</code> redirections from Makefiles
- to see the stderr.
-</li>
-<li> Transfer this file to the floppy:
-<pre>
- dd if=picobsd.bin of=/dev/rfd0
-</pre>
-
- (The 'build' script asks you if you want to do this.)
-</li>
-</ol>
-
-<p>That's all. You're welcome to change and improve these scripts. If you
- stumble upon something which looks like a good idea to have it here, let me
- know.</p>
-
-<p>If, for some reason, the scripts don't work for you at all, also let me
- know.</p>
-
-<hr>
-<i>Last modified:
-@DATE@
-
-<p><A HREF="mailto:abial@freebsd.org">&lt;abial@freebsd.org&gt;</a></i></p>
-</body>
-</html>
diff --git a/release/picobsd/doc/src/installflp.html b/release/picobsd/doc/src/installflp.html
deleted file mode 100644
index b0ead20..0000000
--- a/release/picobsd/doc/src/installflp.html
+++ /dev/null
@@ -1,99 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
-<!-- $FreeBSD$ -->
-<html>
- <head>
- <title>Configuring the PicoBSD install floppy</title>
- </head>
-
- <body>
- <h1>Configuring the PicoBSD install floppy</h1>
-
- <p>The PicoBSD Install Floppy is engineered to be flexible since every
- site has their own needs for an automated install solution. The
- base package contains tools and frameworks for further
- customization. </p>
-
- <h2>Generating an Install Image</h2>
-
- <p>Central to the design of the install floppy is a tarball image of
- the operating system. The install floppy downloads and extracts
- the image from a master server. </p>
-
- <p>To generate the install image:</p>
-
- <ol>
- <li>Install and configure a machine as it should be
- installed.
- <ul>
- <li><em>Make the template machine as close to the target
- machines as possible.</em> System-specific files such as
- <tt>/etc/fstab</tt> can cause problems if they are
- specific to a particular disk setup, such as multiple SCSI
- disks in the template vs. single IDE disks in the target.
- <li><em>Try to keep the template as small as practical.</em>
- The more packages you install on the template, the larger
- the image becomes.
- </ul>
- <li>Use tar to create the image. This shell script is useful
- for automating the process.
- <blockquote><pre>
-#!/bin/sh
-TARBALL="/fbsdimage.tgz"
-GZIP="-9"
-
-tar -cpvzf ${TARBALL} --totals --exclude '/proc/*' --exclude '/var/tmp/*' \
- --exclude '/var/log/*' --exclude '/tmp/*' --exclude '/fbsdimage.tgz' /
- </pre></blockquote>
- <ul>
- <li>Use the '--exclude' argument to remove files from the
- image.
- <li>Don't forget to exclude the image itself or your tarball
- will be much larger than it should.
- <li>The <b>GZIP</b> environment variable sets arguments to the
- gzip command called by tar's z option.
- </ul>
- <li>Copy the image file to your load server into a public FTP
- directory.
- </ol>
-
- <h2>Configuring the Install Floppy</h2>
-
- <p>Once the install floppy has been built using the PicoBSD build
- script, mount the floppy and modify the install
- script, <tt>/floppy/etc/doinstall</tt>. <tt>doinstall</tt> is
- called from rc on startup to install the disk image and perform
- whatever other setup tasks are necessary. The script can set
- network parameters, configure applications, select kernels, or
- whatever else a shell script can do. A handful of useful
- utilities is included on the disk to ease automated installation.</p>
-
- <p>At minumum, set the URL to the FTP server holding the disk
- image. If you wish, uncomment and modify to taste any of the
- code blocks provided.</p>
-
- <p>By default, the install floppy:</p>
- <ul>
- <li>Creates one large FreeBSD slice on the first IDE disk (wd0).
- <li>Creates a 256MB swap partition and the rest for a large
- root partition.
- <li>Formats the large partition using <tt>newfs</tt> with
- default parameters. '
- <li>Downloads the image via FTP and feeds it directly into
- <tt>cpio</tt> for extraction.
- </ul>
-
- <P>To modify the disk formatting parameters, modify the
- <tt>/floppy/etc/prepdisk</tt> script. <tt>prepdisk</tt> is a
- simple awk script that feeds directly into <tt>disklabel</tt>.
- Simply edit the generated partition table to taste.</P>
-
-
-
- <hr>
- <address><a href="mailto:dwhite@freebsd.org">Doug White</a></address>
-<!-- Created: Thu Oct 7 21:42:17 PDT 1999 -->
-<!-- hhmts start -->
-Last modified: Thu Oct 7 22:18:22 PDT 1999
-<!-- hhmts end -->
- </body>
-</html>
diff --git a/release/picobsd/doc/src/intrinsics.html b/release/picobsd/doc/src/intrinsics.html
deleted file mode 100644
index f8ff478..0000000
--- a/release/picobsd/doc/src/intrinsics.html
+++ /dev/null
@@ -1,122 +0,0 @@
-<html>
-<! $FreeBSD$ >
-<head>
-<title><center>Details of building process</center></title>
-</head>
-<body>
-<h1><center> Details of building process.</center></h1>
-
-<p>For those of you who really want to know what's going on behind the scene,
-and can't quite deduce it from scripts themselves, here's short description of
-the build process:</p>
-
-<ul>
-<li> The './build' script sets the basic parameters of the floppy, such as:
-<ul>
-<li> LANGUAGE: language of the various system messages, and C locale.
- Available choices are: "en" (English) and "pl" (Polish).
-</li>
-<li>
- SIZE: size of the memory filesystem (MFS), which will contain all the
- binaries (except the kernel). Make it big enough for all the pieces to
- fit, but keep it as small as possible (remember that running system
- needs some space in /var and /tmp!). Presently, "dial" type of floppy
- requires at least SIZE=1700, and others require ca. 2800 (numbers
- are in kB).
-</li>
-<li>
- TYPE: determines which set of programs and which trees will be
- installed on the floppies. This simply acts as a selector to dive into
- respective subdirectories in ../. Presently, the TYPE can be one of:
- "dial" (dialup floppy), "net" (networking floppy), "router" (router
- floppy) or "isp" (work in progress - not really usable yet).
-</li>
-</ul>
-<li>
- Then the './build' scripts checks if there is a kernel built on basis
- of previously set parameters. The check is error prone, but is simple:
- the target config file is called PICOBSD-${TYPE}.${SIZE}, and if there
- exists a file called /sys/compile/PICOBSD-${TYPE}.${SIZE}/kernel, then
- it is assumed it's the right one.
-
-<p> If there is no such file, the script starts compilation of the kernel,
- using template in ../${YTPE}/conf/PICOBSD, and adding parameters which
- determine the built-in MFS size.</p>
-<li>
- Then the './build' script starts the consecutive stages of the build
- process, which are performed by scripts (in the following order):
- stage1, populate, stage2, stage3.
-</li>
-<li>
- 'stage1' prepares the file called fs.PICOBSD with given size - it's a
- placeholder for the future MFS. Next, it turns it into device,
- and then performs some tricks which allow for doing 'disklabel'.
- I use the 'auto' option to disklabel(8).
-
-<p> One notable exception here is with the "router" floppy - I use one
- of extended floppy formats (820kB).</p>
-
-<p> After the file is labelled, the newfs(8) is run. Here you can adjust
- the parameter -i, which can gain you some space on the MFS (sacrificing
- available number of inodes, so be careful).</p>
-
-<p> Such prepared blank filesystem is mounted on /mnt. Here the stage1
- ends.</p>
-</li>
-<li>
- 'populate', as its name suggests, transfers all the pieces which will
- reside in MFS, to the filesystem mounted on /mnt. This includes:
-<ul>
-<li> copying language dependent files from ../${TYPE}/lang/</li>
-<li> making the MFS hierarchy according to informations in
- ../${TYPE}/mfs.tree/ subdir.
-<p> The MFS tree includes the /etc, which will contain the startup file
- /etc/rc.
- This file in turn doesn't do anything useful except copying the
- real /etc hierarchy from the floppy filesystem. (There's one possible
- improvement which comes to my mind - to have the whole /etc on the
- floppy in tar.gz - this would require only one inode to store the whole
- /etc, and we could gain some kB on the floppy)</p>
-</li>
-<li> making and installing the set of crunched programs, basing on the
- description in ../${TYPE}/crunch1/crunch.conf. This involves
- making the 'crunch', copying it to /mnt and making hard links to
- the names of all the programs contained therein.</li>
-<li> preparing a short list of kernel symbols, which will be used by
- various utilities at runtime. In case of "net" and "isp" floppy, it also
- prepares the kvm_kernel.db database, which will be used by such
- programs as ps, netstat and others</li>
-<li> preparing the list of "virgin" configuration of devices in kernel -
- this list will be used by kget(8) program to save the changes to
- /kernel.config file.</li>
-</ul>
-</li>
-<li>
- 'stage2' prepares the target kernel. It takes the filesystem contained
- in fs.PICOBSD (which has all the above pieces inside), and writes it
- into the target kernel. Then it kzip(8)'s such construed kernel. This
- process also strips the symbols from the kernel (that's why we prepared
- the symbol list earlier).
-</li>
-<li>
- 'stage3' does almost the same as 'stage1', but this time it prepares
- the filesystem of the target floppy. Default size for the floppy is
- set at 1440kB.
-<p> After preparing the filesystem (which again involves doing disklabel(8)
- and newfs(8) - here you can notice that the resulting FS has very small
- number of inodes in order to save space), the script transfers the
- floppy hierarchy (which is
- taken from ../${TYPE}/floppy.tree). Notice that it also contains
- the /etc directory - its contents is copied right after bootup to the
- real /etc in MFS. This allows for changing the system behaviour
- (because you can't change the MFS contents without recompiling).</p>
-<p> The script finally copies previously prepared kernel to the floppy
- filesystem. The filesystem is unmounted, and here the build process
- ends.</p>
-</li>
-</ul>
-
-<h6>
-Last modified:
-@DATE@
-</h6>
diff --git a/release/picobsd/doc/src/intro.html b/release/picobsd/doc/src/intro.html
deleted file mode 100644
index f115697..0000000
--- a/release/picobsd/doc/src/intro.html
+++ /dev/null
@@ -1,303 +0,0 @@
-<HTML>
-<! $FreeBSD$ >
-<HEAD>
- <TITLE>PicoBSD</TITLE>
-</HEAD>
-<BODY>
-
-<CENTER><h1><B>PicoBSD</B></h1>
-<HR shade align="center" size="8" width="25%"></CENTER>
-
-
-<p><b>Contents:</b></p>
-<ul>
-<li>
-<A HREF="#what">What is it</a>, and
-<A HREF="#hardware">what hardware is supported?</a>
-</li>
-<li>
-<A HREF="#where"><b>Where can I get it?</b></a>
-</li>
-<li>
-<A HREF="#how">How can I use it?</a>
-</li>
-<li>
-<A HREF="#create">Create your own, custom version of PicoBSD!</a>
-<p>Get the full PicoBSD Development Kit as well as full CVS repository of
-the project.</p>
-</li>
-<li>
-<A HREF="#info">Where can I get more info?</a>
-</li>
-<li>
-<A HREF="bugs.html">Release history and bugs parade...</a>
-<li>
-<A HREF="#future">Plans for the future.</a>
-</li>
-<li>
-<A HREF="#credits">Credits</a>
-</li>
-<li>
-<A HREF="#license">Licensing issues</a>
-</li>
-<li>
-<A HREF="faq.html">FAQ</a>
-</li>
-</ul>
-
-<HR shade align="center">
-<HR shade align="center">
-
-<A NAME="what"><h3>What is it?</h3>
-<p>If you ever dreamed about having really small, tiny, minimal system that
-would offer you benefits of Unix, while still fitting in reasonable space -
-here it is!</p>
-
-<p>PicoBSD is a one floppy version of
-<A HREF="http://www.freebsd.org/">FreeBSD</a>, which in its
-different variations allows you to have secure dialup access, small diskless
-router or even a dial-in server. And all this on only one standard 1.44MB
-floppy - no need to sacrifice over 100MB of your precious HDD space.</p>
-
-<p>PicoBSD is... well, pico-sized :-) , and the minimal hardware that
-is required to run it is 386SX CPU with 8MB of RAM (no HDD!).
-</p>
-
-<A NAME="hardware">
-<p>Here you can find detailed <A HREF="hardware.html">list of supported
-hardware and features</a>.
-
-<p>Current version of PicoBSD is @VER@, and this means that I consider it
-still immature, while on the other hand being somewhat tested and improved
-over previous versions. Does it tell you something? Well, at least you can
-try it - I cannot guarantee that it doesn't burn your house or blow up your
-machine, though the former is unlikely... :-)</p>
-
-<HR shade align="center">
-<A NAME="where"><h3>Where can I get it?</h3>
-
-<p>There are two language editions of PicoBSD - English and Polish one. You'll
-be probably more interested in the former :-) The only difference is in
-the set of fonts included, C locale, and the language of messages.</p>
-<p>You can download them from www.freebsd.org or one of its mirrors:</p>
-<ul>
-<li>Dialup version: <A HREF="http://www.freebsd.org/~picobsd/picobsd/pb_en-D.bin">English</a>
-(<A HREF="http://www.freebsd.org/~picobsd/picobsd/doc_dial/README.en">README</a>) or
-<A HREF="http://www.freebsd.org/~picobsd/picobsd/pb_pl-D.bin">Polish</a>
-(<A HREF="http://www.freebsd.org/~picobsd/picobsd/doc_dial/README.pl">README</a>)
-</li>
-<li>Networking (formerly known as 'router-like') version: <A HREF="http://www.freebsd.org/~picobsd/picobsd/pb_en-N.bin">English</a>
-(<A HREF="http://www.freebsd.org/~picobsd/picobsd/doc_net/README.en">README</a>)
- or <A HREF="http://www.freebsd.org/~picobsd/picobsd/pb_pl-N.bin">Polish</a>
-(<A HREF="http://www.freebsd.org/~picobsd/picobsd/doc_net/README.pl">README</a>)
-</li>
-<li>Router version: <A HREF="http://www.freebsd.org/~picobsd/picobsd/pb_en-R.bin">English</a>
-(<A HREF="http://www.freebsd.org/~picobsd/picobsd/doc_router/README.en">README</a>)
- or <A HREF="http://www.freebsd.org/~picobsd/picobsd/pb_pl-R.bin">Polish</a>
-(<A HREF="http://www.freebsd.org/~picobsd/picobsd/doc_router/README.pl">README</a>)
-</li>
-<li>Dial-in server version: waiting for
-<A HREF="http://www.freebsd.org/~picobsd/beta.html">beta testers</a> ... :-)
-</ul>
-
-<p><i>(See the <A HREF="hardware.html">feature list</a> for more
-details)</i></p>
-
-<p>The above floppies were built from FreeBSD sources.
-You can find floppies built from 2.2.5 sources
-<A HREF="http://www.freebsd.org/~picobsd/picobsd225/">here</a> or
-<A HREF="http://info.net-gw.com/picoBSD/">here</a>.</p>
-
-<HR shade align="center">
-<A NAME="how"><h3>How can I use it?</h3>
-<p>Previous versions were packed with a PKZIP(tm) compatible program - now they
-are simply the raw binary floppy images, so you just need to grab the
-appropriate version of the file.</p>
-
-<p>I assume you will use 1.44MB floppy to boot the system - other sizes
-(bigger) are not tested.</p>
-
-<p>The file 'pb_xx-X.bin' must be written onto a blank floppy. It does NOT
-mean that it can be copied using e.g. DOS 'copy' command. You must use a
-program like
-<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/tools/rawrite.exe">rawrite.exe</a>
-or
-<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/tools/fdimage.exe">fdimage.exe</a>
- to write this file directly on the raw floppy.</p>
-
-<p>Under DOS you would do something like this:</p>
-<pre>
- C:\> fdimage.exe pb_xx-X.bin a:
-</pre>
-
-<p>while under Unix you would use something like:</p>
-<pre>
- dd if=pb_xx-X.bin of=/dev/rfd0
-</pre>
-
-<p>Then boot off this floppy and enjoy!</p>
-
-<p>If you feel lost, try the 'help' command (it's available only on "dialup"
-floppies)</p>
-
-<HR shade align="center">
-<A NAME="create">
-<h3>Create your own, custom version of PicoBSD!</h3>
-
-<p>I made available also the set of tools
-(a.k.a the PicoBSD Development Kit) I used to create the floppies (see also the
- <A HREF="how2build.html">detailed instructions</a>)</p>
-
-<p>You can also access the full CVS repository of PicoBSD - beginning with
-version 0.4 it's a part of official FreeBSD CVS and lives in
-<code>src/release/picobsd</code>. I also create the snapshots of this source
-tree - keep in mind that they are not so up-to-date as the tree
-in FreeBSD CVS. You can get the snapshot I made on
-Sun Nov 1 11:48:32 PST 1998
-<A HREF="http://www.freebsd.org/~picobsd/picobsd/picobsd.tgz">here</a>.</p>
-
-<p> Now, if you don't like the setup of PicoBSD, or you miss
-some program, or (better yet) you want to improve PicoBSD - you can grab the
-copy of exactly the same tools I used and build your own, customized
- version! </p>
-
-<p>Think of it: if your're an ISP, you can build the dialup version for
- your customers, including some scripts to automatically connect them to
-your site. You can also create a demo disk for your friend (or your boss! :-)).
-You can also build a firewall/router for your office, etc, etc...
- possibilities are really endless and limited only by your imagination.</p>
-
-<p>You will need at least 10MB of free disk space for building, and of course
-the full system sources installed. I also assume that the sources are
-quite -current. There is also a back-ported version of the scripts prepared by
-<A HREF="mailto:dinesh@alphaque.com">Dinesh Nair</a> which builds ok on
-2.2.6-R systems.</p>
-
-<p>Version 0.31 was packed with pax(1) - newer versions are packed again
-with tar and gzip to avoid confusion... :-)</p>
-
-<p>I'm very interested in hearing from you about your experiences - if you
-come up with a setup you think is interesting, please let me know!</p>
-
-<HR shade align="center">
-<A NAME="info"><h3>Where can I get more info?</h3>
-
-<p>Almost all of the programs included on the floppies are exactly the
-same versions as in normal FreeBSD installation, so that the normal
-manual pages apply. However, I didn't include the manpages themselves -
-they would take over 200kB!</p>
-
-<p> For the total newbies, which would use (I assume)
-the 'dialup' version, there is a short README on the floppy which gives
-step by step instructions on how to get a dialup connection. There is also
-a script called 'dialup' which attempts to configure PPP to allow for automatic
-log in to your provider, and for background operation.
-There is also a small help system ('help' command)</p>
-
-<p> There are some system utilities which are unique to PicoBSD, and at this
- moment they are documented in detail only in source and READMEs :-(.</p>
-
-
-<p>As for the new releases which will (hopefully) be prepared in the future:
-just keep an eye on this page. I'll also send announcements to FreeBSD mailing
-lists.</p>
-
-<HR shade align="center">
-<A NAME="future"><h3>Plans for the future</h3>
-
-<p>Well, I hope that thanks to your comments I'll be able to continuously
-improve the setup and contents of PicoBSD. I also have specific dreams (if
-dreams can be specific..) - here they are, as an incentive to your
-imagination and coding skills:</p>
-<ul>
-<li>
-To write a command line tool patterned after Cisco IOS, which could configure
-various aspects of router-like version of PicoBSD.
-<p>Well, currently you can read very preliminary draft of proposed
-architecture, called the <A HREF="UCI.html">Unified Configuration Interface.</a></p>
-</li>
-<li>
-To put an XWindow-like GUI on the 'dialup' floppy. (Update: you can look at
-<A HREF="http://www.freebsd.org/~picobsd/preview/preview2.tgz">preview
-version</a> and send me your comments. <b>I need some help in porting newer
-version of W</b>).
-</li>
-<li>
-To gain some experience with solid state disks, and prepare standard images
-for e.g. 4MB versions of SSD, with Cisco 25xx-like contents... I also hope
- to achieve this goal in the nearest
-future, thanks to involvement of some PicoBSD enthusiast :-)</p>
-(Update: I'm experimenting with an M-System's 16MB flash right now, and
-there is also ongoing development for a driver for their DiskOnChip)
-</li>
-<li>
-To be able to boot from more primitive filesystem than FFS - DOS or Minix
-would be just fine, as they don't waste so much space for their internals.
-</li>
-<li>
-To have an alternative to current MFS - it wastes a lot of space just
-because it mimicks the normal FFS on top of memory blocks...
-</li>
-<li>
-To further minimize the memory footprint of router-like setup. I'd like it
-to be able to run truely effortlessly on 4MB machines... This would
-probably include rewriting oinit(8) to run multithreaded.
-</li>
-<li>
-And many others... You can find a complete list
-<A HREF="TODO.html">here</a>.
-</li>
-</ul>
-
-<A NAME="credits"><h3>Credits</h3>
-
-<p>The following people are either responsible for the very existence of this
-project, or significantly eased my pains in gaining necessary knowledge:</p>
-<ul>
-<li>
-the whole FreeBSD team for this magnificent OS, and their hard work of
-continuous development,
-</li>
-<li>
-Dinesh Nair, for co-development and preparing of the version which compiled
-on 2.2.5-RELEASE,
-</li>
-<li>
-Joe Greco, for his encouraging example of XKERNEL (some parts of the scripts
-still bear his fingerprints :-) (you can get it
- <A HREF="../../../xkernel.tgz">here</a>).
-</li>
-<li>Goran Hasse of <A HREF="http://www.raditex.se">Raditex AB, Sweden</a>, for
-sending me M-Systems' and SanDisk flash disks to experiment with.
-</li>
-<li>
-Mike Smith for various tips and encouragement.
-</li>
-<li>
-freebsd-* mailing lists participants, which helped me with some other
-pieces.
-</li>
-<li>
-and many other people who keep encouraging me to continue this work. Thanks,
-guys!
-</li>
-</ul>
-
-<A NAME="license"><h3>Licensing issues</h3>
-
-<p>PicoBSD is distributed under BSD copyright,
-which allows you to use it in various ways, including commercial
-applications. So grab it and enjoy! And if you feel that you want to help
-with this project, either by donating some time to write code, or by
-some other donation, just <A HREF="mailto:abial@freebsd.org">contact me</a>.</p>
-
-<h5>Last modified:
-@DATE@
-</h5>
-
-<HR shade align="left" size="2" width="100%">
-<CENTER><h5>Any comments? Send them to
-<A HREF="mailto:abial@freebsd.org">the author</A> </h5></CENTER>
-
-</BODY>
-</HTML>
OpenPOWER on IntegriCloud