Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Apr 2015 05:40:25 +0000 (UTC)
From:      Eitan Adler <eadler@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r46403 - head/en_US.ISO8859-1/books/faq
Message-ID:  <201504010540.t315ePtO060917@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: eadler
Date: Wed Apr  1 05:40:24 2015
New Revision: 46403
URL: https://svnweb.freebsd.org/changeset/doc/46403

Log:
  FAQ: multiple changes
  
  - don't point out bad IRC channels, just point to good ones
  - simplify password hashing question by presuming a modern version (and briefly
    mentioning 8)
  - combine memory limits questions into single question

Modified:
  head/en_US.ISO8859-1/books/faq/book.xml

Modified: head/en_US.ISO8859-1/books/faq/book.xml
==============================================================================
--- head/en_US.ISO8859-1/books/faq/book.xml	Wed Apr  1 05:20:05 2015	(r46402)
+++ head/en_US.ISO8859-1/books/faq/book.xml	Wed Apr  1 05:40:24 2015	(r46403)
@@ -971,9 +971,7 @@
 	    <listitem>
 	      <para>Channel <literal>#FreeBSDhelp</literal> on <link
 		  xlink:href="http://www.efnet.org/index.php">EFNet</link>;
-		is a channel dedicated to helping &os; users.  They
-		are much more sympathetic to questions than
-		<literal>#FreeBSD</literal> is.</para>
+		is a channel dedicated to helping &os; users.</para>
 	    </listitem>
 
 	    <listitem>
@@ -1345,11 +1343,9 @@
 	</question>
 
 	<answer>
-	  <para>&os;&nbsp;7 and 8 use MD5 password hashing by default.
-	    Recent versions of &os; use <emphasis>SHA512</emphasis> by
-	    default.  These are believed to be more secure than the
-	    traditional &unix; password format, which used a scheme
-	    based on the <emphasis>DES</emphasis> algorithm.  DES
+	  <para>versions of &os; (past &os;&nbsp;8) use
+	    <emphasis>SHA512</emphasis> by
+	    default.  DES
 	    passwords are still available for backwards compatibility
 	    with legacy operating systems which still
 	    use the less secure password format.  &os; also supports
@@ -1365,25 +1361,6 @@
       </qandaentry>
 
       <qandaentry>
-	<question xml:id="memory-limits">
-	  <para>What are the limits for memory?</para>
-	</question>
-
-	<answer>
-	  <para>Memory limits depend on the platform used.  On a
-	    standard &i386; install, the limit is 4&nbsp;GB but more
-	    memory can be supported through &man.pae.4;.  See <link
-	      linkend="memory-i386-over-4gb">instructions for using
-	      4&nbsp;GB or more memory on &i386;</link>.</para>
-
-	  <para>&os;/pc98 has a limit of 4&nbsp;GB memory, and PAE can
-	    not be used with it.  Other architectures supported by
-	    &os; have much higher theoretical limits on maximum memory
-	    (many terabytes).</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
 	<question xml:id="ffs-limits">
 	  <para>What are the limits for FFS file systems?</para>
 	</question>
@@ -1440,11 +1417,8 @@
 	</question>
 
 	<answer>
-	  <para>Yes, &rel.head.releng; users can set
-	    <varname>WITH_BSDCONFIG</varname> in
-	    <filename>/etc/src.conf</filename>.  Users of &rel.relx;
-	    and higher may also install
-	    <package>sysutils/bsdconfig</package>.</para>
+	  <para>Yes.  <application>bsdconfig</application> provides a
+	    nice interface to configure &os; post-installation.</para>
 	</answer>
       </qandaentry>
     </qandaset>
@@ -1485,13 +1459,14 @@
 
 	<qandaentry>
 	  <question xml:id="memory-upper-limitation">
-	    <para>Does &os; support more than 4&nbsp;GB of memory
+	    <para>What are the limits for memory? Does &os; support
+	      more than 4&nbsp;GB of memory
 	      (RAM)?  More than 16&nbsp;GB?  More than
 	      48&nbsp;GB?</para>
 	  </question>
 
 	  <answer>
-	    <para>Yes.  &os; as an operating system generally supports
+	    <para>&os; as an operating system generally supports
 	      as much physical memory (RAM) as the platform it is
 	      running on does.  Keep in mind that different platforms
 	      have different limits for memory; for example &i386;
@@ -1699,22 +1674,15 @@
 
 	<qandaentry>
 	  <question xml:id="supported-cdrom-drives">
-	    <para>Which CD-ROM drives are supported by &os;?</para>
+	    <para>Which CD-ROM and CD-RW drives are supported by
+	      &os;?</para>
 	  </question>
 
 	  <answer>
 	    <para>Any SCSI drive connected to a supported controller
 	      is supported.  Most ATAPI compatible IDE CD-ROMs are
 	      supported.</para>
-	  </answer>
-	</qandaentry>
 
-	<qandaentry>
-	  <question xml:id="supported-cdrw-drives">
-	    <para>Which CD-RW drives are supported by &os;?</para>
-	  </question>
-
-	  <answer>
 	    <para>&os; supports any ATAPI-compatible IDE CD-R or CD-RW
 	      drive.  See &man.burncd.8; for details.</para>
 
@@ -1915,12 +1883,8 @@ bindkey ^[[3~ delete-char # for xterm</p
 	  <para>On a 32-bit version of &os;, the memory appears lost,
 	    since it will be remapped above 4&nbsp;GB, which a 32-bit
 	    kernel is unable to access.  In this case, the solution is
-	    to build a PAE enabled kernel.  See <link
-	      linkend="memory-limits">the entry on memory
-	      limits</link> and <link
-	      linkend="memory-upper-limitation">about different memory
-	    limits on different platforms</link> for more
-	    information.</para>
+	    to build a PAE enabled kernel.  See
+	      the entry on memory limits for more information.</para>
 
 	  <para>On a 64-bit version of &os;, or when running a
 	    PAE-enabled kernel, &os; will correctly detect and remap



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201504010540.t315ePtO060917>