changeset 1341:d4eb237dcc6f

Many typos, spotted by Alan Post.
author Rob Landley <rob@landley.net>
date Tue, 22 Mar 2011 06:51:49 -0500
parents 5e22b534839a
children 08134b65336e
files www/about.html www/architectures.html www/documentation.html www/history.html www/news.html www/presentation.html
diffstat 6 files changed, 44 insertions(+), 45 deletions(-) [+]
line wrap: on
line diff
--- a/www/about.html	Fri Mar 18 23:20:13 2011 -0500
+++ b/www/about.html	Tue Mar 22 06:51:49 2011 -0500
@@ -20,7 +20,7 @@
 
 <ul>
 <li><p><b>Allow package developers and maintainers to reproduce and fix bugs
-on architecures they don't have access to or experience with.</b></p>
+on architectures they don't have access to or experience with.</b></p>
 
 <p>Bug reports can include a link to a system image and a
 reproduction sequence (wget source, build, run this test).  This provides
@@ -102,7 +102,7 @@
 environmental dependencies.  Sometimes new releases of packages simply won't
 work without perl, or zlib, or some other dependency that previous versions
 didn't have, not because they meant to but because they were never tested in
-a build environment that didn't have them, so the depencency leaked in.</p>
+a build environment that didn't have them, so the dependency leaked in.</p>
 
 <p>By providing a build environment that contains only the bare essentials
 (relying on you to build and install whatever else you need), Aboriginal
--- a/www/architectures.html	Fri Mar 18 23:20:13 2011 -0500
+++ b/www/architectures.html	Tue Mar 22 06:51:49 2011 -0500
@@ -10,7 +10,7 @@
 power consumption to performance ratio, meaning it has the longest battery
 life and smallest amount of heat generated for a given computing task.</p>
 
-<h2>Processor vs archtecture</h2>
+<h2>Processor vs architecture</h2>
 
 <p>Although ARM hardware has many different processor designs with varying
 clock speeds, cache sizes, and integrated peripherals, from a software
@@ -28,7 +28,7 @@
 the x86 world.  Recompiling ARMv4 code to ARMv5 code provides about a 25%
 speedup on the same hardware.)</p>
 
-<p>The oldest architecture this compatability goes back to is ARMv3 (which
+<p>The oldest architecture this compatibility goes back to is ARMv3 (which
 introduced 32-bit addressing), but that hardware is now obsolete.  (Not just no
 longer being sold, but mostly cycled out of the installed base.)  The oldest
 architecture still in use is "ARMv4", which should run on any ARM hardware
--- a/www/documentation.html	Fri Mar 18 23:20:13 2011 -0500
+++ b/www/documentation.html	Tue Mar 22 06:51:49 2011 -0500
@@ -30,7 +30,7 @@
 
 <p>This documentation uses the name "Aboriginal Linux"
 to refer to the <a href=downloads>build system</a> consisting of a series
-of bash scripts and configurationo files which download and compile software.
+of bash scripts and configuration files which download and compile software.
 The output of that build system is referred to as a "<a
 href=downloads/binaries>system image</a>".  The build system
 compiles a Linux development environment for the specified
@@ -209,7 +209,7 @@
 to "$TARGET-" with a trailing dash.</li>
 </ul>
 
-<p>Also, stock up on asprin and clear a space to beat your head against; you'll
+<p>Also, stock up on aspirin and clear a space to beat your head against; you'll
 need both.  See <a href="#why_cross_compiling_sucks">why cross compiling
 sucks</a> for more details.</p>
 
@@ -253,7 +253,7 @@
 <li>package-mini-native.sh $TARGET</li>
 </ol>
 
-<p>In theory, the stages are othogonal.  If you have an existing cross
+<p>In theory, the stages are orthogonal.  If you have an existing cross
 compiler, you can add it to the $PATH and skip cross-compiler.sh.  Or you
 can use _just_ cross-compiler.sh to create a cross compiler, and then go build
 something else with it.  The host-tools.sh stage can often be skipped
@@ -307,7 +307,7 @@
 installed on the host.</p></li>
 
 <li><p><b>Portability</b> - Using a known set of command line utilities
-insulates the build from variations in the host's Linux distribtion (such as
+insulates the build from variations in the host's Linux distribution (such as
 Ubuntu's /bin/echo lacking suport for the -e option).</p></li>
 
 <li><p><b>Testing</b> - It ensures the resulting system can rebuild itself
@@ -317,7 +317,7 @@
 restricting $PATH ensures that no necessary commands are missing.  (Variation
 can still show up between x86/arm/powerpc versions, of course.)</p>
 
-<p>It also moves most failures to the beginning.  If anything's going to
+<p>It also moves most failures to the beginning.  If anything is going to
 break, it's usually the host-tools build.  After that runs, we're mostly
 in a known and tested state.</li>
 
@@ -380,7 +380,7 @@
 </li>
 
 <li><p><b>mini-native.sh</b> - Use the cross compiler to create
-a minimal native build environment for the target platfrom.<p>
+a minimal native build environment for the target platform.<p>
 
 <p>This script takes one argument: the architecture to build for.</p>
 
@@ -653,7 +653,7 @@
 
 <li><p><b>cleanup</b> - delete temporary copy of source code after build.
 Treat as a fancy "rm -rf" (except that it remembers the working directory
-from the last setupfor call, rather than reqiring it to be specified on
+from the last setupfor call, rather than requiring it to be specified on
 the command line).</p>
 
 <p>If the exit code of the last command was nonzero,
@@ -800,7 +800,7 @@
 things like "uClibc" and "uClibc++".  Packages are allowed to contain dashes
 (such as gcc-core), but cannot have a digit immediately after the dash.</p>
 
-<p>FWL implements source cacheing.  The first call to setupfor extracts the
+<p>FWL implements source caching.  The first call to setupfor extracts the
 package into build/sources, and then creates a directory of hard links in the
 current target's build/temp-$TARGET directory with cp -lfR.  Later setupfor
 calls just create the directory of hard links from the existing source tree.
@@ -902,7 +902,7 @@
 <p>The way $RECORD_COMMANDS works is by building a logging wrapper
 (sources/toys/wrappy.c) and populating a directory (build/wrapper) with
 symlinks to that logging wrapper for each command name in $PATH.  When later
-build stages run commands, the wraper appends the command line to the log file
+build stages run commands, the wrapper appends the command line to the log file
 (specified in the environment variable $WRAPPY_LOGPATH, host-tools.sh sets
 this to "$BUILD/cmdlines.$STAGE_NAME.$PACKAGE_NAME"), recording
 each command run.  The logging wrapper then searches $WRAPPY_REALPATH to find
@@ -1102,7 +1102,7 @@
 
 <li><p><b>busybox</b> - Build busybox command line utilities.</p>
 
-<p>This provides the bulk of the command line utlities for the new
+<p>This provides the bulk of the command line utilities for the new
 system.</p>
 
 <p>Once upon a time, "make defconfig" provided the largest sane configuration
@@ -1222,7 +1222,7 @@
 <li><p><b>distcc</b> - command to distribute compiles across a network
 cluster.</li>
 
-<p>We install this for <a href="#distcc_trick">the distc accelerator
+<p>We install this for <a href="#distcc_trick">the distcc accelerator
 trick</a>.  It's entirely optional.</p>
 
 <p>We create a $TOOLS/distcc directory full of symlinks to distcc with the
@@ -1523,7 +1523,7 @@
 hard to do.</p>
 
 <p>I wrote an <a href=/writing/docs/cross-compiling.html>introduction
-to cross-compiling</a> which explains the terminology, plusses and minuses,
+to cross-compiling</a> which explains the terminology, pluses and minuses,
 and why you might want to do it.  Keep in mind that I wrote that for a company
 that specializes in cross-compiling.  Personally, I consider cross-compiling
 a necessary evil to be minimized, and that's how Firmware Linux is designed.
@@ -1601,14 +1601,14 @@
 the user home directories lived.  When they got more disk space, they created
 a new direct (/home) and moved all the user home directories there.</p>
 
-<p>The real reason we kept it is tradition.  The execuse is that the root
+<p>The real reason we kept it is tradition.  The excuse is that the root
 partition contains early boot stuff and /usr may get mounted later, but these
 days we use initial ramdisks (initrd and initramfs) to handle that sort of
 thing.  The version skew issues of actually trying to mix and match different
 versions of /lib/libc.so.* living on a local hard drive with a /usr/bin/*
 from the network mount are not pretty.</p>
 
-<p>I.E. The seperation is just a historical relic, and I've consolidated it in
+<p>I.E. The separation is just a historical relic, and I've consolidated it in
 the name of simplicity.</p>
 
 <p>On a related note, there's no reason for "/opt".  After the original Unix
@@ -1652,7 +1652,7 @@
 just symlink them together.</p>
 
 <p>(I case it hasn't become apparent yet, there's 30 years of accumulated cruft
-in the standards, convering a lot of cases that don't apply outside of
+in the standards, covering a lot of cases that don't apply outside of
 supercomputing centers where 500 people share accounts on a mainframe that
 has a dedicated support staff.  They serve no purpose on a laptop, let alone
 an embedded system.)</p>
--- a/www/history.html	Fri Mar 18 23:20:13 2011 -0500
+++ b/www/history.html	Tue Mar 22 06:51:49 2011 -0500
@@ -19,7 +19,7 @@
 
 <p>Back in the late 90's, before linksys routers came out, I installed several
 masquerading gateways by putting Red Hat on old leftover 386 machines.  This
-involved removing as many packages as possible from the bas install, both to
+involved removing as many packages as possible from the base install, both to
 get the size down (to fit it on old hard drives) and to reduce the security
 exposure of all the daemons Red Hat ran by default (including a print
 server and an NFS server exposed to the world, for no readily apparent
@@ -180,7 +180,7 @@
 entire new OS images using the internet speeds of 2001, and then update
 the new OS image without losing data or turning it into a brick.</p>
 
-<p>WebOffice's original prototype device ran a stock Red Hat 7 intall (the one
+<p>WebOffice's original prototype device ran a stock Red Hat 7 install (the one
 that had the Code Red virus when they first demoed it to me after a LUG
 meeting).  The whole OS image took up almost a gigabyte, and that's before
 they'd implemented any applications or web UI.  I rebased the system on Linux
@@ -258,7 +258,7 @@
 
 <p>At a technical level, there was a chicken and egg problem here: the root
 filesystem was a loopback mount, but the file to loopback mount has to live
-somewhere.  So the system needed a writeable parition for logging and
+somewhere.  So the system needed a writeable partition for logging and
 such anyway, so I made /dev/hda1 be ext3 and mounted it on /var, and put the
 firmware in that.  So during the boot process the initrd needed to mount
 /dev/hda1 onto a /temp directory, loopback mount the /temp/image file onto a
@@ -286,7 +286,7 @@
 we persevered.</p>
 
 <p>Mounting a partition twice and leaking one of the mount points (the old
-/temp was inaccessable after the pivot_root) was kind of unclean anyway, the
+/temp was inaccessible after the pivot_root) was kind of unclean anyway, the
 clean thing for the boot to do was actually move the /tmp mount to /sub/var
 after mounting /sub but before the pivot_root into /sub.  But when I asked
 on linux-kernel how to do that, I was told that "mount --move" didn't exist
@@ -316,7 +316,7 @@
 except the python CGI) once it shipped never came true.  Partly the founders
 were ambivalent about this whole "open source" thing, wanting every competitive
 advantage they could get.  (They kept trying to patent obvious things I did.
-Their patent lawyer was a realy cool dude when he flew in from California.)</p>
+Their patent lawyer was a really cool dude when he flew in from California.)</p>
 
 <p>Another contributing factor was that the founders were from Taiwan and had
 no idea how to address the US market.  Their marketer employee #3 hadn't
@@ -367,7 +367,7 @@
 necessity would make them focus on shipping units and bringing in revenue, but
 it didn't happen.  I left in November and spent the last couple months of that
 year in Florida watching my mother die of cancer, then driving around the
-country distributing her posessions to various relatives, and finally crashing
+country distributing her possessions to various relatives, and finally crashing
 on Eric Raymond's couch for a few months doing an "editing pass" on The Art of
 Unix Programming that expanded the book from 9 chapters to 20.</p>
 
@@ -493,7 +493,7 @@
 ncurses, net-tools, patch, perl, procinfo, procps, psmisc, sed, shadow,
 sysklogd, sysvinit, tar, tcl, texinfo, util-linux, vim, and zlib.  There
 were also two LFS-specific packages, providing boot scripts, config
-files, and miscelaneous utilities.</p>
+files, and miscellaneous utilities.</p>
 
 <p>I started by removing packages I didn't actually need.  Tcl, expect, and
 dejagnu hadn't been in LFS 4, so obviously it was possible to do without them.
@@ -622,13 +622,13 @@
 e2fsprogs, file, findutils, gawk, grep, inetutils, less, modutils, net-tools,
 patch, procps, sed, shadow, sysklogd, sysvinit, tar, util-linux, and vim.</p>
 
-<p>To do that, I wound up extensively upggrading (or rewriting from scratch)
+<p>To do that, I wound up extensively upgrading (or rewriting from scratch)
 dozens of different busybox commands and adding several new ones from
 scratch.</p>
 
 <p>One new command was switch_root, for initramfs support.  I wrote an
 initramfs file for the kernel's Documentation directory because I investigated
-it for Firmware Linux.  (And later gave my first OLS presenation on the topic,
+it for Firmware Linux.  (And later gave my first OLS presentation on the topic,
 and write an article series about it when I worked at TimeSys.)</p>
 
 <p>Another new command was mdev, which was a rewrite of
@@ -699,8 +699,7 @@
 root access (enough for my needs), but without extensive setup thanks to
 the "hostfs", and without requiring a new source package (I already had
 the Linux kernel sources, this was just another way of building them).
-I first got it working in the
-<a href=http://landley.livejournal.com/10201.html>first got it working in
+I <a href=http://landley.livejournal.com/10201.html>first got it working in
 a patched 2.6.9 kernel</a>, and later integrated it into the build when I got
 <a href=http://landley.livejournal.com/2005/01/21/>unpatched 2.6.11</a>
 to build a usable User Mode Linux image (although I had to
@@ -730,7 +729,7 @@
 initially understand), made a number of
 <a href=http://lists.uclibc.org/pipermail/uclibc/2003-August/027542.html>design
 suggestions</a>,
-and even <a href=http://lists.uclibc.org/pipermail/uclibc/2003-August/027559.html>oftered patches</a>.</p>
+and even <a href=http://lists.uclibc.org/pipermail/uclibc/2003-August/027559.html>offered patches</a>.</p>
 
 <p>But I didn't really like the design of buildroot
 (nested makefiles aren't the most straightforward approach to anything,
@@ -753,7 +752,7 @@
 and wouldn't load without it, even if it was otherwise linked against
 uClibc.</p>
 
-<p>This meant the gcc wraper was no longer sufficient, but since libgcc_s.so was
+<p>This meant the gcc wrapper was no longer sufficient, but since libgcc_s.so was
 part of gcc, the only way to get a new version of libgcc_s.so that linked
 against uClibc (instead of glibc) was to download the gcc source code and
 build gcc itself against uClibc.</p>
@@ -769,7 +768,7 @@
 a new uClibc root filesystem directory containing the uClibc shared libraries,
 and a second instance of busybox dynamically linked against those,
 which you could chroot and test out the uClibc version of busybox.
-Since he already had the kernel source lying aorund, Eric even taught it to
+Since he already had the kernel source lying around, Eric even taught it to
 build a User Mode Linux binary that could do the chroot for you.</p>
 
 <h2>Problems with buildroot</h2>
@@ -780,7 +779,7 @@
 initially understand), made a number of
 <a href=http://lists.uclibc.org/pipermail/uclibc/2003-August/027542.html>design
 suggestions</a>,
-and even <a href=http://lists.uclibc.org/pipermail/uclibc/2003-August/027559.html>oftered patches</a>.</p>
+and even <a href=http://lists.uclibc.org/pipermail/uclibc/2003-August/027559.html>offered patches</a>.</p>
 
 <p>But I didn't really like the design of buildroot
 (nested makefiles aren't the most straightforward approach to anything,
@@ -797,7 +796,7 @@
 several years old by that point).  Buildroot was an instructive counterexample
 on many fronts: my project should not require root access to build,
 shell scripts were more readable than nested makefiles, releases were
-important, and it's vital to have boundaries so youc an clearly state
+important, and it's vital to have boundaries so you can clearly state
 what your project DOESN'T do.</p>
 
 <p>I also checked in with buildroot from time to time to see what it was doing
@@ -937,7 +936,7 @@
 
 
 <p>I <a href=http://landley.livejournal.com/22566.html>started playing around
-with QEMU in novemeber 2005</a>, about the same time I started keeping
+with QEMU in november 2005</a>, about the same time I started keeping
 a more detailed <a href=http://landley.net/notes-2005.html>technical
 blog</a> on my own website, and shortly before I
 <a href=http://landley.livejournal.com/24021.html>went to work for
--- a/www/news.html	Fri Mar 18 23:20:13 2011 -0500
+++ b/www/news.html	Tue Mar 22 06:51:49 2011 -0500
@@ -303,7 +303,7 @@
 
 <li>build-control-images.sh - build all control images from sources/native-builds.</li>
 
-<li>for-each-target.sh - iterage through every defined target architecture
+<li>for-each-target.sh - iterate through every defined target architecture
 and run a command.</li>
 </ul>
 
@@ -328,7 +328,7 @@
 <p>Environment variable sanitization: the sanitize_environment function
 unsets any environment variable it doesn't recognize, either from a whitelist
 or from config.  Clearing all unrecognized environment variables insulates
-the build from some of the strage environments out there.  To disable this
+the build from some of the strange environments out there.  To disable this
 behavior, export NO_SANITIZE_ENVIRONMENT=1.</p>
 
 <p>New config variables:</p>
@@ -585,13 +585,13 @@
 of one of the unstable packages (linux, uClibc, or busybox).  It can test
 that the build completes, or that the system image boots and successfully
 builds the static native dropbear binary.  (In theory this will allow the
-nightly snapshots to automaticaly isolate and report the first commit that
+nightly snapshots to automatically isolate and report the first commit that
 broke them.)</p>
 
 <p>In other general infrastructure news: some extensive upgrades to the
 compiler wrapper (ccwrap), such as no longer needing GIMME_AN_S at compile
 time and instead autodetecting the presence of libgcc_s.so vs libgcc.a
-and behaving appropriately.  A largeish cleanup/refactoring of the compiler
+and behaving appropriately.  A largish cleanup/refactoring of the compiler
 build (described in
 <a href=/hg/firmware/shortlog/944>commit 944</a>)
 added a new "native-compiler.sh" script, which handles building the
@@ -682,7 +682,7 @@
 use the right one, rather than moving them around during the build.
 Updated smoketest-all.sh to show "NONE" for system images that didn't build.
 Added more support for SKIP_STRIP and CFLAGS=-g to the rest of the
-packages.  Cleaned out the old USE_COLOR stuff which was superceded by
+packages.  Cleaned out the old USE_COLOR stuff which was superseded by
 set_titlebar.</p>
 </li>
 </ul>
@@ -713,7 +713,7 @@
 tracker</a> has a <a href=http://redmine.impactlinux.com/projects/impact/roadmap>roadmap</a>
 showing what we plan to implement for the next release or two.</p>
 
-<p>It's also a place to file bugs, athough sending them to the <a href=http://lists.impactlinux.com/listinfo.cgi/firmware-impactlinux.com>mailing list</a>
+<p>It's also a place to file bugs, although sending them to the <a href=http://lists.impactlinux.com/listinfo.cgi/firmware-impactlinux.com>mailing list</a>
 is still the fastest way to get a fix.</p>
 </blockquote>
 
@@ -1008,7 +1008,7 @@
 <a href=http://ftp.kernel.org/pub/linux/devel/binutils/release.binutils-2.18.50.0.1>the
 last GPLv2 release of Red Hat's binutils fork, 2.17.5.0.17</a> is under
 consideration for a future release.  But mostly the GNU compiler toolchain
-has been upgraded as far as possible for the forseeable future, either because
+has been upgraded as far as possible for the foreseeable future, either because
 new versions provide no significant benefits or because they're not available
 under a license compatible with the Linux kernel's.</p>
 
@@ -1147,7 +1147,7 @@
 stripping of the cross compilers and system images, so everything's a bit
 smaller.  The mirror list now lives in download.sh.  New buildall.sh is a
 wrapper around build.sh.  New build-static-toolchains.sh builds them under
-qemu; set FORK=1 to build them in paralell just like buildall.sh.  The
+qemu; set FORK=1 to build them in parallel just like buildall.sh.  The
 ext2 system images are now built at a small size with genext2fs and
 then expanded with resize2fs (because genext2fs slows down exponentially
 as size increases; this means e2fsprogs is built in host-tools.sh now).
--- a/www/presentation.html	Fri Mar 18 23:20:13 2011 -0500
+++ b/www/presentation.html	Tue Mar 22 06:51:49 2011 -0500
@@ -245,7 +245,7 @@
 			<ul>	<li>Flash has limited write cycles, building on it shortens device life.</li>
 			</ul></li>
 			<li>Building on NFS is painful
-			<ul>	<li>Timestamp granularity and skew due to cacheing</li>
+			<ul>	<li>Timestamp granularity and skew due to caching</li>
 			</ul></li>
 		</ul></li>
 	</ul></li>