Attachment 221354 Details for Bug 252493 – Patch

[patch] Patch

because-articles.diff (text/plain), 11.24 KB, created by Ceri Davies on 2021-01-07 16:15:19 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Ceri Davies

Created: 2021-01-07 16:15:19 UTC

Size: 11.24 KB

patch

obsolete

>diff --git a/en_US.ISO8859-1/articles/committers-guide/article.xml b/en_US.ISO8859-1/articles/committers-guide/article.xml
>index e05587a219..db04ddd5f0 100644
>--- a/en_US.ISO8859-1/articles/committers-guide/article.xml
>+++ b/en_US.ISO8859-1/articles/committers-guide/article.xml
>@@ -1280,7 +1280,7 @@ You need a Passphrase to protect your secret key.</screen>
> 	<sect4>
> 	  <title>Preparing the Merge Target</title>
> 
>-	  <para>Because of the mergeinfo propagation issues described
>+	  <para>Due to the mergeinfo propagation issues described
> 	    earlier, it is very important to never merge changes
> 	    into a sparse working copy.  Always use a full
> 	    checkout of the branch being merged into.  For instance,
>diff --git a/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml b/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml
>index cb5064aa5c..eda3c20709 100644
>--- a/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml
>+++ b/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml
>@@ -33,7 +33,7 @@
>       thinking, the missing historical context, the ambiguous
>       standards - and the style(9) transgressions.</para>
> 
>-    <para>Because Bruce gave more code reviews than anybody else in
>+    <para>As Bruce gave more code reviews than anybody else in
>       the history of the FreeBSD project, the commit logs hide the
>       true scale of his impact until you pay attention to
>       "Submitted by", "Reviewed by" and "Pointed out by".</para>
>diff --git a/en_US.ISO8859-1/articles/ldap-auth/article.xml b/en_US.ISO8859-1/articles/ldap-auth/article.xml
>index d1957adb4f..26ecdf7f29 100644
>--- a/en_US.ISO8859-1/articles/ldap-auth/article.xml
>+++ b/en_US.ISO8859-1/articles/ldap-auth/article.xml
>@@ -617,7 +617,7 @@ passwd: files ldap</programlisting>
> 
>       <para>Unfortunately, as of the time this was written &os; did
> 	not support changing user passwords with &man.passwd.1;.
>-	Because of this, most administrators are left to implement a
>+	As a result of this, most administrators are left to implement a
> 	solution themselves.  I provide some examples here.  Note that
> 	if you write your own password change script, there are some
> 	security issues you should be made aware of; see <xref
>diff --git a/en_US.ISO8859-1/articles/linux-emulation/article.xml b/en_US.ISO8859-1/articles/linux-emulation/article.xml
>index d3e6c8742e..6e94e16e1a 100644
>--- a/en_US.ISO8859-1/articles/linux-emulation/article.xml
>+++ b/en_US.ISO8859-1/articles/linux-emulation/article.xml
>@@ -403,9 +403,7 @@
> 	    different API(es).  The M:N library uses the
> 	    <literal>kse_*</literal> family of syscalls while the 1:1
> 	    library uses the <literal>thr_*</literal> family of
>-	    syscalls.  Because of this, there is no general concept of
>-	    thread ID shared between kernel and userspace.  Of course,
>-	    both threading libraries implement the pthread thread ID
>+	    syscalls.  Due to this, libraries implement the pthread thread ID
> 	    API.  Every kernel thread (as described by <literal>struct
> 	      thread</literal>) has td tid identifier but this is not
> 	    directly accessible from userland and solely serves the
>@@ -1683,7 +1681,7 @@ translate_traps(int signal, int trap_code)
>       <sect3 xml:id="pid-mangling">
> 	<title>PID mangling</title>
> 
>-	<para>Because of the described different view knowing what a
>+	<para>As there is a difference in view as what to the idea of a
> 	  process ID and thread ID is between &os; and &linux; we have
> 	  to translate the view somehow.  We do it by PID mangling.
> 	  This means that we fake what a PID (=TGID) and TID (=PID) is
>@@ -1783,7 +1781,7 @@ void * child_tidptr);</programlisting>
> 	  <literal>linux_emuldata_shared</literal>.  The
> 	  <literal>emul_lock</literal> is a nonsleepable blocking
> 	  mutex while <literal>emul_shared_lock</literal> is a
>-	  sleepable blocking <literal>sx_lock</literal>.  Because of
>+	  sleepable blocking <literal>sx_lock</literal>.  Due to
> 	  the per-subsystem locking we can coalesce some locks and
> 	  that is why the em find offers the non-locking
> 	  access.</para>
>@@ -1981,7 +1979,7 @@ void * child_tidptr);</programlisting>
> 
> 	<para>Threaded programs should be written with as little
> 	  contention on locks as possible.  Otherwise, instead of
>-	  doing useful work the thread just waits on a lock.  Because
>+	  doing useful work the thread just waits on a lock.  As a result
> 	  of this, the most well written threaded programs show little
> 	  locks contention.</para>
>       </sect3>
>diff --git a/en_US.ISO8859-1/articles/serial-uart/article.xml b/en_US.ISO8859-1/articles/serial-uart/article.xml
>index e57b052b9e..2ddbfbe2aa 100644
>--- a/en_US.ISO8859-1/articles/serial-uart/article.xml
>+++ b/en_US.ISO8859-1/articles/serial-uart/article.xml
>@@ -160,7 +160,7 @@
> 	  for the new word can be sent as soon as the Stop Bit for the
> 	  previous word has been sent.</para>
> 
>-	<para>Because asynchronous data is <quote>self
>+	<para>As asynchronous data is <quote>self
> 	  synchronizing</quote>, if there is no data to transmit, the
> 	  transmission line can be idle.</para>
>       </sect2>
>@@ -605,7 +605,7 @@
> 	<title>Bits, Baud and Symbols</title>
> 
> 	<para>Baud is a measurement of transmission speed in
>-	  asynchronous communication.  Because of advances in modem
>+	  asynchronous communication.  Due to advances in modem
> 	  communication technology, this term is frequently misused
> 	  when describing the data rates in newer devices.</para>
> 
>@@ -676,7 +676,7 @@
> 	  DCE speed because of the use of compression by the
> 	  modems.</para>
> 
>-	<para>Because the number of bits needed to describe a byte
>+	<para>As the number of bits needed to describe a byte
> 	  varied during the trip between the two machines plus the
> 	  differing bits-per-seconds speeds that are used present on
> 	  the DTE-DCE and DCE-DCE links, the usage of the term Baud to
>@@ -769,7 +769,7 @@
> 		  technology with various functional flaws
> 		  corrected. The INS8250A was used initially in PC
> 		  clone computers by vendors who used
>-		  <quote>clean</quote> BIOS designs. Because of the
>+		  <quote>clean</quote> BIOS designs. Due to the
> 		  corrections in the chip, this part could not be used
> 		  with a BIOS compatible with the INS8250 or
> 		  INS8250B.</para>
>@@ -949,7 +949,7 @@
> 	<para>In internal modems, the modem designer will frequently
> 	  emulate the 8250A/16450 with the modem microprocessor, and
> 	  the emulated UART will frequently have a hidden buffer
>-	  consisting of several hundred bytes.  Because of the size of
>+	  consisting of several hundred bytes.  Due to the size of
> 	  the buffer, these emulations can be as reliable as a 16550A
> 	  in their ability to handle high speed data.  However, most
> 	  operating systems will still report that the UART is only a
>@@ -971,7 +971,7 @@
> 	<para>When the NS16550 was developed, the National
> 	  Semiconductor obtained several patents on the design and
> 	  they also limited licensing, making it harder for other
>-	  vendors to provide a chip with similar features.  Because of
>+	  vendors to provide a chip with similar features.  As a result of
> 	  the patents, reverse-engineered designs and emulations had
> 	  to avoid infringing the claims covered by the patents.
> 	  Subsequently, these copies almost never perform exactly the
>@@ -1008,7 +1008,7 @@
> 	  TI, StarTech, and CMD as well as megacells and emulations
> 	  embedded in internal modems were tested with COMTEST.  A
> 	  difference count for some of these components is listed
>-	  below. Because these tests were performed in 1994, they may
>+	  below. Since these tests were performed in 1994, they may
> 	  not reflect the current performance of the given product
> 	  from a vendor.</para>
> 
>@@ -1954,7 +1954,7 @@
> 	    produce intelligent serial communication boards.  This type of
> 	    design usually provides a microprocessor that interfaces with
> 	    several UARTs, processes and buffers the data, and then alerts the
>-	    main PC processor when necessary.  Because the UARTs are not
>+	    main PC processor when necessary.  As the UARTs are not
> 	    directly accessed by the PC processor in this type of
> 	    communication system, it is not necessary for the vendor to use
> 	    UARTs that are compatible with the 8250, 16450, or the 16550 UART.
>diff --git a/en_US.ISO8859-1/articles/solid-state/article.xml b/en_US.ISO8859-1/articles/solid-state/article.xml
>index 232a5d59f4..0a0965866b 100644
>--- a/en_US.ISO8859-1/articles/solid-state/article.xml
>+++ b/en_US.ISO8859-1/articles/solid-state/article.xml
>@@ -136,7 +136,7 @@
> 
>     <para>All embedded &os; systems that use flash memory as system
>       disk will be interested in memory disks and memory filesystems.
>-      Because of the limited number of writes that can be done to
>+      As a result of the limited number of writes that can be done to
>       flash memory, the disk and the filesystems on the disk will most
>       likely be mounted read-only.  In this environment, filesystems
>       such as <filename>/tmp</filename> and <filename>/var</filename>
>@@ -223,16 +223,16 @@ pseudo-device   md              # memory disk</programlisting>
>   <sect1>
>     <title>Building a File System from Scratch</title>
> 
>-    <para>Because ATA compatible compact-flash cards are seen by &os;
>+    <para>As ATA compatible compact-flash cards are seen by &os;
>       as normal IDE hard drives, you could theoretically install &os;
>       from the network using the kern and mfsroot floppies or from a
>       CD.</para>
> 
>     <para>However, even a small installation of &os; using normal
>       installation procedures can produce a system in size of greater
>-      than 200 megabytes.  Because most people will be using smaller
>+      than 200 megabytes.  Most people will be using smaller
>       flash memory devices (128 megabytes is considered fairly large -
>-      32 or even 16 megabytes is common) an installation using normal
>+      32 or even 16 megabytes is common), so an installation using normal
>       mechanisms is not possible&mdash;there is simply not enough disk
>       space for even the smallest of conventional
>       installations.</para>
>@@ -423,7 +423,7 @@ pseudo-device   md              # memory disk</programlisting>
> 	successfully run <command>make</command>
> 	<buildtarget>install</buildtarget>, we must create a packages
> 	directory on a non-memory filesystem that will keep track of
>-	our packages across reboots.  Because it is necessary to mount
>+	our packages across reboots.  As it is necessary to mount
> 	your filesystems as read-write for the installation of a
> 	package anyway, it is sensible to assume that an area on the
> 	flash media can also be used for package information to be
>diff --git a/en_US.ISO8859-1/articles/vm-design/article.xml b/en_US.ISO8859-1/articles/vm-design/article.xml
>index 2cf7e001eb..79b56d296c 100644
>--- a/en_US.ISO8859-1/articles/vm-design/article.xml
>+++ b/en_US.ISO8859-1/articles/vm-design/article.xml
>@@ -648,7 +648,7 @@
> 	    cannot be combined with the next A-B sequence.</para>
> 
> 	  <para>Why do we interleave our swap space instead of just tack swap
>-	    areas onto the end and do something fancier?  Because it is a whole
>+	    areas onto the end and do something fancier?  It is a whole
> 	    lot easier to allocate linear swaths of an address space and have
> 	    the result automatically be interleaved across multiple disks than
> 	    it is to try to put that sophistication elsewhere.</para>

Actions: View | Diff

Attachments on bug 252493: 221354 | 221358