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

Remove references to first person pronouns ("I", "me", "my", etc.):

Browse source 
all they do is serve to confuse the reader (who is this "I"?).
Questions and clearly attributed answers (e.g., quotes from postings)
were left alone.
This commit is contained in:
Dima Dorfman 2001-04-16 23:55:49 +00:00
parent cc7a5aca98
commit ff708993b6
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=9208
2 changed files with 66 additions and 56 deletions
Download patch file Download diff file Expand all files Collapse all files

61
en_US.ISO8859-1/books/faq/book.sgml
View file

@ -14,7 +14,7 @@
<corpauthor>The FreeBSD Documentation Project</corpauthor>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.173 2001/04/13 03:30:09 murray Exp $</pubdate>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.174 2001/04/15 19:17:27 jim Exp $</pubdate>
<copyright>
<year>1995</year>
@ -2675,9 +2675,10 @@ Filesystem 1024-blocks Used Avail Capacity Mounted on
<para>FreeBSD supports the SCSI ZIP drive out of the box, of
course. The ZIP drive can only be set to run at SCSI target IDs
5 or 6, but if your SCSI host adapter's BIOS supports it you
can even boot from it. I don't know which host adapters let you
boot from targets other than 0 or 1... look at your docs (and
let me know if it works out for you).</para>
can even boot from it. It is not clear which host
adapters support booting from targets other than 0 or 1,
so you will have to consult your adapter's documentation
if you'd like to use this feature.</para>
<para>ATAPI (IDE) Zip drives are supported in FreeBSD 2.2.6 and
later releases.</para>
@ -5183,15 +5184,15 @@ crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx</screen>
<para>
<note>
<para>I recommend making a dated snapshot of your kernel
<para>It is recommended that you make a dated snapshot
of your kernel
in <filename>kernel.YYMMDD</filename> after you get it all
working, that way if you do something dire the next time
you play with your configuration you can boot that kernel
instead of having to go all the way back to
<filename>kernel.GENERIC</filename>. This is particularly
important if you're now booting off a controller that isn't
supported in the GENERIC kernel (yes, personal
experience).</para>
supported in the GENERIC kernel.</para>
</note></para>
</answer>
</qandaentry>
@ -5655,10 +5656,10 @@ C:\="DOS"</programlisting>
<para>For 2.2.x systems this procedure assumes that DOS, NT,
FreeBSD, or whatever have been installed into their respective
fdisk partitions on the <emphasis remap=bf>same</emphasis>
disk. In my case DOS &amp; NT are in the first fdisk partition
and FreeBSD is in the second. I also installed FreeBSD to boot
from its native partition, <emphasis remap=bf>not</emphasis>
the disk MBR.</para>
disk. This example was tested on a system where DOS &amp; NT
were on the first fdisk partition, and FreeBSD on the second.
FreeBSD was also set up to boot from its native partition, not
the disk's MBR.</para>
<para>Mount a DOS-formatted floppy (if you've converted to NTFS)
or the FAT partition, under, say,
@ -5923,9 +5924,10 @@ C:\="DOS"</programlisting>
<para>IDE drives are not able to allow access to both drives on
the same channel at the same time (FreeBSD doesn't support mode
4, so all IDE disk I/O is <quote>programmed</quote>). I would
still suggest putting your swap on a separate drive however.
The drives are so cheap, it is not worth worrying about.</para>
4, so all IDE disk I/O is <quote>programmed</quote>).
It is still suggested that you put your swap partition on a
separate driver, however: the drives are so cheap, it is not
worth worrying about.</para>
<para>Swapping over NFS is only recommended if you do not have a
local disk to swap to. Swapping over NFS is slow and
@ -7043,8 +7045,8 @@ define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
<filename>/dev</filename>) and symbolic links tend to
screw that up. You need to use tools that understand
these things, which means &man.dump.8; and &man.tar.1;.
I recommend doing the data moves in single user mode,
but it's not required.</para>
Although it is suggested that you move the data in single user
mode, it is not required.</para>
<para>You should never use anything but &man.dump.8; and
&man.restore.8; to move the root file system. The
@ -8124,9 +8126,10 @@ bitmap_name="/boot/splash.pcx"</programlisting>
<para>to your <filename>~/.xinitrc</filename>.</para>
<para>For example, I have mapped the 3 keys to be F13, F14, and
F15 respectively. This makes it easy to map them to useful
functions within applications or your window manager.</para>
<para>For example, you could map the 3 keys top be F13, F14, and
F15, respectively. This would make it easy to map them to
useful functions within applications or your window
manager, as demonstrated further down.</para>
<para>To do this put the following in
<filename>~/.xmodmaprc</filename>.</para>
@ -8135,7 +8138,8 @@ bitmap_name="/boot/splash.pcx"</programlisting>
keycode 116 = F14
keycode 117 = F15</programlisting>
<para>I use <command>fvwm2</command> and have mapped the keys
<para>If you use <command>fvwm2</command>, for example, you
could map the keys
so that F13 iconifies (or de-iconifies) the window the cursor
is in, F14 brings the window the cursor is in to the front or,
if it is already at the front, pushes it to the back, and F15
@ -8144,8 +8148,9 @@ keycode 117 = F15</programlisting>
any part of the desktop visible (and the logo on the key
matches its functionality).</para>
<para>The entries in my <filename>~/.fvwmrc</filename> which map
the keys this way are:</para>
<para>The following entries in
<filename>~/.fvwmrc</filename> implement the
aforementioned setup:</para>
<programlisting>Key F13 FTIWS A Iconify
Key F14 FTIWS A RaiseLower
@ -11078,11 +11083,11 @@ raisechar=^^</programlisting>
blindfolded volunteers who have also had 250 micrograms of
LSD-25 administered beforehand. 35% of the volunteers said that
FreeBSD tasted sort of orange, whereas Linux tasted like purple
haze. Neither group mentioned any particular variances in
temperature that I can remember. We eventually had to throw the
haze. Neither group mentioned any significant variances in
temperature. We eventually had to throw the
results of this survey out entirely anyway when we found that
too many volunteers were wandering out of the room during the
tests, thus skewing the results. I think most of the volunteers
tests, thus skewing the results. We think most of the volunteers
are at Apple now, working on their new <quote>scratch and
sniff</quote> GUI. It's a funny old business we're in!</para>
@ -11124,9 +11129,9 @@ raisechar=^^</programlisting>
take off running and don't ever look back! Freed from the
counterbalancing influence of the BSD daemons, the twin demons
of DOS and Windows are often able to re-assert total control
over your machine to the eternal damnation of your soul. Given
a choice, I think I'd prefer to get used to the scratchy
noises, myself!</para>
over your machine to the eternal damnation of your soul.
Now that you know, given a choice you'd probably prefer to get
used to the scratchy noises, no?</para>
</answer>
</qandaentry>

61
en_US.ISO_8859-1/books/faq/book.sgml
View file

@ -14,7 +14,7 @@
<corpauthor>The FreeBSD Documentation Project</corpauthor>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.173 2001/04/13 03:30:09 murray Exp $</pubdate>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.174 2001/04/15 19:17:27 jim Exp $</pubdate>
<copyright>
<year>1995</year>
@ -2675,9 +2675,10 @@ Filesystem 1024-blocks Used Avail Capacity Mounted on
<para>FreeBSD supports the SCSI ZIP drive out of the box, of
course. The ZIP drive can only be set to run at SCSI target IDs
5 or 6, but if your SCSI host adapter's BIOS supports it you
can even boot from it. I don't know which host adapters let you
boot from targets other than 0 or 1... look at your docs (and
let me know if it works out for you).</para>
can even boot from it. It is not clear which host
adapters support booting from targets other than 0 or 1,
so you will have to consult your adapter's documentation
if you'd like to use this feature.</para>
<para>ATAPI (IDE) Zip drives are supported in FreeBSD 2.2.6 and
later releases.</para>
@ -5183,15 +5184,15 @@ crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx</screen>
<para>
<note>
<para>I recommend making a dated snapshot of your kernel
<para>It is recommended that you make a dated snapshot
of your kernel
in <filename>kernel.YYMMDD</filename> after you get it all
working, that way if you do something dire the next time
you play with your configuration you can boot that kernel
instead of having to go all the way back to
<filename>kernel.GENERIC</filename>. This is particularly
important if you're now booting off a controller that isn't
supported in the GENERIC kernel (yes, personal
experience).</para>
supported in the GENERIC kernel.</para>
</note></para>
</answer>
</qandaentry>
@ -5655,10 +5656,10 @@ C:\="DOS"</programlisting>
<para>For 2.2.x systems this procedure assumes that DOS, NT,
FreeBSD, or whatever have been installed into their respective
fdisk partitions on the <emphasis remap=bf>same</emphasis>
disk. In my case DOS &amp; NT are in the first fdisk partition
and FreeBSD is in the second. I also installed FreeBSD to boot
from its native partition, <emphasis remap=bf>not</emphasis>
the disk MBR.</para>
disk. This example was tested on a system where DOS &amp; NT
were on the first fdisk partition, and FreeBSD on the second.
FreeBSD was also set up to boot from its native partition, not
the disk's MBR.</para>
<para>Mount a DOS-formatted floppy (if you've converted to NTFS)
or the FAT partition, under, say,
@ -5923,9 +5924,10 @@ C:\="DOS"</programlisting>
<para>IDE drives are not able to allow access to both drives on
the same channel at the same time (FreeBSD doesn't support mode
4, so all IDE disk I/O is <quote>programmed</quote>). I would
still suggest putting your swap on a separate drive however.
The drives are so cheap, it is not worth worrying about.</para>
4, so all IDE disk I/O is <quote>programmed</quote>).
It is still suggested that you put your swap partition on a
separate driver, however: the drives are so cheap, it is not
worth worrying about.</para>
<para>Swapping over NFS is only recommended if you do not have a
local disk to swap to. Swapping over NFS is slow and
@ -7043,8 +7045,8 @@ define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
<filename>/dev</filename>) and symbolic links tend to
screw that up. You need to use tools that understand
these things, which means &man.dump.8; and &man.tar.1;.
I recommend doing the data moves in single user mode,
but it's not required.</para>
Although it is suggested that you move the data in single user
mode, it is not required.</para>
<para>You should never use anything but &man.dump.8; and
&man.restore.8; to move the root file system. The
@ -8124,9 +8126,10 @@ bitmap_name="/boot/splash.pcx"</programlisting>
<para>to your <filename>~/.xinitrc</filename>.</para>
<para>For example, I have mapped the 3 keys to be F13, F14, and
F15 respectively. This makes it easy to map them to useful
functions within applications or your window manager.</para>
<para>For example, you could map the 3 keys top be F13, F14, and
F15, respectively. This would make it easy to map them to
useful functions within applications or your window
manager, as demonstrated further down.</para>
<para>To do this put the following in
<filename>~/.xmodmaprc</filename>.</para>
@ -8135,7 +8138,8 @@ bitmap_name="/boot/splash.pcx"</programlisting>
keycode 116 = F14
keycode 117 = F15</programlisting>
<para>I use <command>fvwm2</command> and have mapped the keys
<para>If you use <command>fvwm2</command>, for example, you
could map the keys
so that F13 iconifies (or de-iconifies) the window the cursor
is in, F14 brings the window the cursor is in to the front or,
if it is already at the front, pushes it to the back, and F15
@ -8144,8 +8148,9 @@ keycode 117 = F15</programlisting>
any part of the desktop visible (and the logo on the key
matches its functionality).</para>
<para>The entries in my <filename>~/.fvwmrc</filename> which map
the keys this way are:</para>
<para>The following entries in
<filename>~/.fvwmrc</filename> implement the
aforementioned setup:</para>
<programlisting>Key F13 FTIWS A Iconify
Key F14 FTIWS A RaiseLower
@ -11078,11 +11083,11 @@ raisechar=^^</programlisting>
blindfolded volunteers who have also had 250 micrograms of
LSD-25 administered beforehand. 35% of the volunteers said that
FreeBSD tasted sort of orange, whereas Linux tasted like purple
haze. Neither group mentioned any particular variances in
temperature that I can remember. We eventually had to throw the
haze. Neither group mentioned any significant variances in
temperature. We eventually had to throw the
results of this survey out entirely anyway when we found that
too many volunteers were wandering out of the room during the
tests, thus skewing the results. I think most of the volunteers
tests, thus skewing the results. We think most of the volunteers
are at Apple now, working on their new <quote>scratch and
sniff</quote> GUI. It's a funny old business we're in!</para>
@ -11124,9 +11129,9 @@ raisechar=^^</programlisting>
take off running and don't ever look back! Freed from the
counterbalancing influence of the BSD daemons, the twin demons
of DOS and Windows are often able to re-assert total control
over your machine to the eternal damnation of your soul. Given
a choice, I think I'd prefer to get used to the scratchy
noises, myself!</para>
over your machine to the eternal damnation of your soul.
Now that you know, given a choice you'd probably prefer to get
used to the scratchy noises, no?</para>
</answer>
</qandaentry>