os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

consistancy again s/file system/filesystem/g

Browse source
This commit is contained in:
Tom Rhodes 2002-05-16 01:50:18 +00:00
parent 86fbd32683
commit 07d8c35ca3
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=13101
22 changed files with 87 additions and 87 deletions
Download patch file Download diff file Expand all files Collapse all files

6
en/projects/libh.sgml
View file

@ -1,6 +1,6 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD: www/en/projects/libh.sgml,v 1.5 2002/01/20 18:15:46 alex Exp $">
<!ENTITY date "$FreeBSD: www/en/projects/libh.sgml,v 1.6 2002/03/16 08:11:33 murray Exp $">
<!ENTITY title 'FreeBSD libh Project'>
<!ENTITY email 'freebsd-libh'>
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
@ -255,7 +255,7 @@ case when a package is coming directly from an FTP server or some
other data source which offers only serial access to the bits.
pkg_add "solves" this problem by first finding sufficient temporary
space on one of the available file systems and then unpacking the
space on one of the available filesystems and then unpacking the
tarball to be extracted into a scratch directory. After the tarball
is extracted, pkg_add then reads through the "packing list" (one of
the meta-data files) and follow its instructions to move only those
@ -425,7 +425,7 @@ dependencies and nothing more (which is desirable), there are still
going to be pieces which are non-extractable under the current scheme
because the available disk space is too small to contain both the
temporary copy and the final installed copy, which may not be on the
same file system can cannot be simply moved into place. Since we'd
same filesystem can cannot be simply moved into place. Since we'd
also like to retain the ability to extract a package directly over a
network connection and never have the temporary bits "hit the disk",
this means that we're almost certainly going to have to go to a

20
en/projects/projects.sgml
View file

@ -1,6 +1,6 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD: www/en/projects/projects.sgml,v 1.124 2002/04/08 18:44:44 trhodes Exp $">
<!ENTITY date "$FreeBSD: www/en/projects/projects.sgml,v 1.125 2002/04/13 10:29:47 murray Exp $">
<!ENTITY title "FreeBSD Development Projects">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
@ -184,14 +184,14 @@ Other planned and implemented things are all the normal management
tools and a server.</li>
<li><a name="coda" href="http://www.coda.cs.cmu.edu/">Coda</a> is
a distributed file system. Among its features are disconnected
a distributed filesystem. Among its features are disconnected
operation, good security model, server replication and persistent
client side caching.</li>
<li><a name="crossfs" href="http://crossfs.bizland.com/cxvfs.html">
crossFS Virtual File System</a>
is based on FreeBSD Virtual File System and provides a
framework for porting UNIX based file systems to Windows NT systems.
framework for porting UNIX based filesystems to Windows NT systems.
</li>
<li><a name="cruptfs" href="http://www.cs.columbia.edu/~ezk/research/software/">cryptfs</a> encrypts file names and data pages using Blowfish.</li>
@ -222,8 +222,8 @@ A Solution to the Metadata Update Problem in File Systems</li>
<li><a name="tcfs" href="http://tcfs.dia.unisa.it/">TCFS</a>
is a Transparent Cryptographic File System that is a suitable
solution to the problem of privacy for distributed file system. By a
deeper integration between the encryption service and the file system,
solution to the problem of privacy for distributed filesystem. By a
deeper integration between the encryption service and the filesystem,
it results in a complete transparency of use to the user
applications. Files are stored in encrypted form and are decrypted
before they are read. The encryption/decryption process takes place on
@ -255,16 +255,16 @@ conversion between absolute path name and relative path name. It
brings benefits mainly to the users of NFS and WWW.</li>
<li><a name="v9fs" href="http://www.acl.lanl.gov/~rminnich/">
V9FS: Memory-based file system for FreeBSD</a> It will (we hope)
V9FS: Memory-based filesystem for FreeBSD</a> It will (we hope)
become the basis of private name spaces for FreeBSD in the
future. It provides a file system that uses only memory for
future. It provides a filesystem that uses only memory for
directories, inodes, and data. This is not at all like mfs,
since mfs uses memory for "disk blocks", and essentially acts as
the device for UFS. V9FS in contrast is a first-class citizen
and is a full mountable file system. No writeup yet.</li>
and is a full mountable filesystem. No writeup yet.</li>
<li><a name="WAFS" href="http://www.eecs.harvard.edu/~stein/wafs/">
WAFS</a> is a simple file system designed to act as a logging
WAFS</a> is a simple filesystem designed to act as a logging
service for kernel subsystems. Reads and writes are keyed
by log-sequence number (LSN). All writes to WAFS are
sequential. Kernel subsystems can use this LSN service to
@ -437,7 +437,7 @@ OSKit's goal is to lower the barrier to entry to OS R&amp;D and to
lower its costs. The OSKit makes it vastly easier to create a new OS,
port an existing OS to the x86 (or in the future, to other
architectures supported by the OSkit), or enhance an OS to support a
wider range of devices, file system formats, executable formats, or
wider range of devices, filesystem formats, executable formats, or
network services. The OSKit also works well for constructing OS-related
programs, such as boot loaders or OS-level servers atop a
microkernel.</li>