diff options
Diffstat (limited to 'release/picobsd/doc')
| -rw-r--r-- | release/picobsd/doc/src/Makefile | 17 | ||||
| -rw-r--r-- | release/picobsd/doc/src/TODO.html | 154 | ||||
| -rw-r--r-- | release/picobsd/doc/src/UCI.html | 960 | ||||
| -rw-r--r-- | release/picobsd/doc/src/bugs.html | 152 | ||||
| -rw-r--r-- | release/picobsd/doc/src/faq.html | 243 | ||||
| -rw-r--r-- | release/picobsd/doc/src/hardware.html | 112 | ||||
| -rw-r--r-- | release/picobsd/doc/src/how2build.html | 197 | ||||
| -rw-r--r-- | release/picobsd/doc/src/installflp.html | 99 | ||||
| -rw-r--r-- | release/picobsd/doc/src/intrinsics.html | 122 | ||||
| -rw-r--r-- | release/picobsd/doc/src/intro.html | 303 |
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 <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. 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> -<BR> -<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>&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"><abial@freebsd.org></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> |
