syntax fixes

11 files changed, 124 insertions, 125 deletions

diff --git a/software/MOSS.page b/software/MOSS.page
index 95f2d41..c0bba84 100644
--- a/software/MOSS.page
+++ b/software/MOSS.page
@@ -18,86 +18,91 @@ and user management, continuation-based serializable programming, persistent
 data accessibility, file and process versioning, central foreign function
 management, and code/content distribution.  It'll be easy!
 
-.. topic:: Implementation
+Implementation
+~~~~~~~~~~~~~~~
 
-    Moss would probably start as "stuff": middleware, userland applications, 
-    utilities, and native shell and GUI interfaces. It could also be a 
-    separate hosted virtual machine, a monolithic application, a kernel 
-    extension, or ultimately run alone over a high performance shim host OS.
+Moss would probably start as "stuff": middleware, userland applications, 
+utilities, and native shell and GUI interfaces. It could also be a 
+separate hosted virtual machine, a monolithic application, a kernel 
+extension, or ultimately run alone over a high performance shim host OS.
 
-    Distribution would be self hosting and viral: users would replicate a copy
-    of the system from a friend instead of from a central server, patches
-    and applications would be distributed word-of-mouth, and trust networks
-    would form naturally via this distribution. Customization and feature sets
-    would be passed on, which makes it likely that a user would receive a 
-    system already tweaked for their own needs and computing knowledge level.
+Distribution would be self hosting and viral: users would replicate a copy
+of the system from a friend instead of from a central server, patches
+and applications would be distributed word-of-mouth, and trust networks
+would form naturally via this distribution. Customization and feature sets
+would be passed on, which makes it likely that a user would receive a 
+system already tweaked for their own needs and computing knowledge level.
 
-    *Existing Projects:* Inferno, Xen, vmware, Java, GNU/*
+*Existing Projects:* Inferno, Xen, vmware, Java, GNU/*
 
-.. topic:: Universal, distributed file system
+Universal, distributed file system
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-    The core of the system would be a universally accessible identity-based
-    operating system. Some authoritive domain would probably be required, but
-    public identity brokers would allow anonymous identities. "Strong
-    Cryptography" is a goal, allowing a user's content to be hosted/cached
-    on third party machines in an encrypted form. The real challenge of course
-    is a flexible crypto system than can be transitioned or upgraded if a flaw
-    is discovered without total data loss.
+The core of the system would be a universally accessible identity-based
+operating system. Some authoritive domain would probably be required, but
+public identity brokers would allow anonymous identities. "Strong
+Cryptography" is a goal, allowing a user's content to be hosted/cached
+on third party machines in an encrypted form. The real challenge of course
+is a flexible crypto system than can be transitioned or upgraded if a flaw
+is discovered without total data loss.
 
-    My dream path would look something like::
+My dream path would look something like::
 
-        /net/user@some.domain.tld/media/ledzep/tangerine.mp3
+    /net/user@some.domain.tld/media/ledzep/tangerine.mp3
 
-    From the application end there would be no concept of "local" or "remote"
-    files to a particular machine, though perhaps some feedback on access time.
-    So, for instance, once tokens/authentication is handled, user utilities
-    like ``mv`` or ``cat`` could be applied, instead of ``scp`` or ``rcat``.
+From the application end there would be no concept of "local" or "remote"
+files to a particular machine, though perhaps some feedback on access time.
+So, for instance, once tokens/authentication is handled, user utilities
+like ``mv`` or ``cat`` could be applied, instead of ``scp`` or ``rcat``.
 
-    Versioning, write locks, etc would have to be considered.
+Versioning, write locks, etc would have to be considered.
 
-    *Existing projects:* OpenAFS, freeNet, ssh, kerberos, git
+*Existing projects:* OpenAFS, freeNet, ssh, kerberos, git
    
-.. topic:: Serializable Programs
-
-    The state/continuation/environment of a running program or chain of 
-    programs should be a "first level object": a bundle of data like any other
-    that can be transmitted, copied, and stored away for later. A user should
-    be able to drag an entire application running on a desktop computer 
-    onto their laptop when then need to travel, or from laptop to workstation
-    if then need additional computing power. Distributed computing could be
-    implemented by bundling up applets that are shot off to a cluster or 
-    higher performance computer for processing, and the result state of the
-    program would simply be bundled back to the requesting client. Such bundles
-    wouldn't be very large: data would be stored on the distributed filesystem,
-    which appears identical (*exactly?*) to every node on the network.
-
-    Properly written, such a serializable system could also lead to performance
-    and power consumption savings by swapping idle programs and processes to 
-    disk, or let low-usage nodes shift their processes off to other nodes 
-    and power down.
-
-    *Existing Projects:* Lisp, Stackless
-
-.. topic:: Foreign Function Management
-
-    It would be nice to see a move away from the library model for shared 
-    code to a more flexible/dynamic foreign function interface that would 
-    allow any appropriate code to announce its availability to other
-    applications regardless of version, platform, coding language, etc.
-    This would be a high-level feature, not intended to replace kernel level
-    operations (read/write) but to make package/library management easier
-    (it doesn't matter if an image conversion function is coming from a video
-    editing package or libpng as long as it reads a raw array and returns
-    a binary stream). 
-    
-    There's room for dynamic optimization here: if program
-    realizes it's native string manipulation library sucks for 5meg+ datasets
-    it could look through the library and see if there's a better one.
-
-    *And,* this too could be distributed, allowing super easy access to 
-    distributed computing resources; underutilized nodes could make their
-    functions available to nearby nodes, or a machine with tons of matrix
-    crunching silicon (eg high end video cards) could swap work units 
-    with a machine with a dedicated crypto chip or 64bit+ processor.
-
-    *Existing Projects:* Script-fu from the Gimp
+Serializable Programs
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The state/continuation/environment of a running program or chain of 
+programs should be a "first level object": a bundle of data like any other
+that can be transmitted, copied, and stored away for later. A user should
+be able to drag an entire application running on a desktop computer 
+onto their laptop when then need to travel, or from laptop to workstation
+if then need additional computing power. Distributed computing could be
+implemented by bundling up applets that are shot off to a cluster or 
+higher performance computer for processing, and the result state of the
+program would simply be bundled back to the requesting client. Such bundles
+wouldn't be very large: data would be stored on the distributed filesystem,
+which appears identical (*exactly?*) to every node on the network.
+
+Properly written, such a serializable system could also lead to performance
+and power consumption savings by swapping idle programs and processes to 
+disk, or let low-usage nodes shift their processes off to other nodes 
+and power down.
+
+*Existing Projects:* Lisp, Stackless
+
+Foreign Function Management
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It would be nice to see a move away from the library model for shared 
+code to a more flexible/dynamic foreign function interface that would 
+allow any appropriate code to announce its availability to other
+applications regardless of version, platform, coding language, etc.
+This would be a high-level feature, not intended to replace kernel level
+operations (read/write) but to make package/library management easier
+(it doesn't matter if an image conversion function is coming from a video
+editing package or libpng as long as it reads a raw array and returns
+a binary stream). 
+
+There's room for dynamic optimization here: if program
+realizes it's native string manipulation library sucks for 5meg+ datasets
+it could look through the library and see if there's a better one.
+
+*And,* this too could be distributed, allowing super easy access to 
+distributed computing resources; underutilized nodes could make their
+functions available to nearby nodes, or a machine with tons of matrix
+crunching silicon (eg high end video cards) could swap work units 
+with a machine with a dedicated crypto chip or 64bit+ processor.
+
+*Existing Projects:* Script-fu from the Gimp
+
diff --git a/software/freebsd-tricks.page b/software/freebsd-tricks.page
index 37a3a5e..80c29d1 100644
--- a/software/freebsd-tricks.page
+++ b/software/freebsd-tricks.page
@@ -13,15 +13,15 @@ See also `unix </software/unix-tricks>`_ and
 Set User Shell
 -----------------------
 ``bash`` isn't always installed, so the default user shell is ``sh``; after
-``bash`` is installed, a user can change their login shell with the command:
+``bash`` is installed, a user can change their login shell with the command::
 
-$ chsh -s /usr/local/bin/bash
+    $ chsh -s /usr/local/bin/bash
 
 Burn an ISO image
 -----------------------
 To burn a CD-R, use ``burncd`` like so::
 
-$ burncd -f /dev/acd0 data FILENAME.iso fixate
+    $ burncd -f /dev/acd0 data FILENAME.iso fixate
 
 Network Tools
 ----------------------
diff --git a/software/functional programming.page b/software/functional programming.page
index 593cf41..7fa1358 100644
--- a/software/functional programming.page
+++ b/software/functional programming.page
@@ -24,31 +24,31 @@ or variables in layer after layer of functions and just holding on to
 the outermost layer. For instance, the typical way to write a ``length``
 function in python would be::
 
->>> def how-long(x):
->>>     l = 0
->>>     while x.has_next()
->>>         l = l+1;
->>>         x.pop()
->>>     return l
+ def how-long(x):
+     l = 0
+     while x.has_next()
+         l = l+1;
+         x.pop()
+     return l
 
 Using recursion, we could do::
 
->>> def how-long-recurse(x):
->>>     if x.has_next()
->>>         x.pop()
->>>         return how-long-recurse(x) + 1
->>>     else
->>>         return 0
+ def how-long-recurse(x):
+     if x.has_next()
+         x.pop()
+         return how-long-recurse(x) + 1
+     else
+         return 0
 
 Using the collector paradigm, we could do::
 
->>> def add1(x): return a+1;
->>> def how-long-col(x, col):
->>>     if x.has_next()
->>>         return col(0)
->>>     else
->>>         x.pop()
->>>         return how-long-col(x, lambda a: col(add1(a)))
+ def add1(x): return a+1;
+ def how-long-col(x, col):
+     if x.has_next()
+         return col(0)
+     else
+         x.pop()
+         return how-long-col(x, lambda a: col(add1(a)))
 
 The first two ways, the plus one operation is actually executed at any given
 time, while with the collector implementation we're really creating a
diff --git a/software/ruby.page b/software/ruby.page
index c044a48..662d934 100644
--- a/software/ruby.page
+++ b/software/ruby.page
@@ -7,7 +7,7 @@ toc: no
 Ruby
 ==================
 
-.. note:: This information is very rough, it's mostly my notes about what is 
+Note: this information is very rough, it's mostly my notes about what is 
     different about Ruby syntax compared to similar modern interpreted 
     pan-paradigm languages like Python.
 
@@ -24,17 +24,17 @@ order data type.
 
 Ranges 
 ----------
-
->>> 2..7                # => 2..7
->>> (2..7).to_a         # => [2, 3, 4, 5, 6, 7]
->>> (2...7).to_a        # => [2, 3, 4, 5, 6]
->>> ('e'..'h').to_a     # => ["e", "f", "g", "h"]
+::
+    2..7                # => 2..7
+    (2..7).to_a         # => [2, 3, 4, 5, 6, 7]
+    (2...7).to_a        # => [2, 3, 4, 5, 6]
+    ('e'..'h').to_a     # => ["e", "f", "g", "h"]
 
 Control Structures
 --------------------
 Can use ``if`` after a statement::
 
->>> a = c if c > b
+    a = c if c > b
 
 Along with the usual ``break`` and ``next``, there is ``redo`` which redoes
 the current loop (initial conditions may have been changed).
@@ -45,28 +45,29 @@ Boolean Operators
 Anything that is not ``nill`` or ``false`` is true. To force interpretation
 as boolean, use ``!!`` (not not)::
 
->>> !!(nil)     # => false
->>> !!(true)    # => true 
->>> !!('')      # => true 
->>> !!(0)       # => true 
->>> !!({})      # => true 
+    !!(nil)     # => false
+    !!(true)    # => true 
+    !!('')      # => true 
+    !!(0)       # => true 
+    !!({})      # => true 
 
 
 Misc
 ----------------
 Can use nasty Perl style regular expression stuff::
 
->>> re1 = /\d+/
->>> "There are 5 kilos of chunky bacon on the table!" =~ re1 # => 10, the index
->>> $~ # =>         #<MatchData:0xb7c36754> 
->>> $~.pre_hash     # => "There are "
+    re1 = /\d+/
+    "There are 5 kilos of chunky bacon on the table!" =~ re1 # => 10, the index
+    $~ # =>         #<MatchData:0xb7c36754> 
+    $~.pre_hash     # => "There are "
 
 Also $1, $2, etc.
 
 The "splat operator", '*', either collects or expands extra arguments depending
 on syntax (I think this is kind of icky)::
 
->>> a, b = 1, 2, 3, 4       # a=1, b=2
->>> a, *b = 1, 2, 3, 4      # a=1, b=[2,3,4] 
->>> c, d = 5, [6, 7, 8]     # c=5, d=[6,7,8]
->>> c, d = 5, *[6, 7, 8]    # c=5, b=6
+    a, b = 1, 2, 3, 4       # a=1, b=2
+    a, *b = 1, 2, 3, 4      # a=1, b=[2,3,4] 
+    c, d = 5, [6, 7, 8]     # c=5, d=[6,7,8]
+    c, d = 5, *[6, 7, 8]    # c=5, b=6
+
diff --git a/software/scheme.page b/software/scheme.page
index 8c719ca..88618a2 100644
--- a/software/scheme.page
+++ b/software/scheme.page
@@ -36,9 +36,9 @@ SIOD
 Coding in ``edwin``
 -----------------------
 
-..note: this section should be spun off as emacs. edwin is essentially a 
+*Note: this section should be spun off as emacs. edwin is essentially a 
     scheme version of emacs. See this 
-    `emacs cheatsheet <http://static.bnewbold.net/mirror/sheets/emacs.pdf>`__
+    `emacs cheatsheet <http://static.bnewbold.net/mirror/sheets/emacs.pdf>`__*
 
 Common keyboard commands (usually 'M' is alt button, 'C' is ctrl, and 'S' is 
 meta/super/"windows"):
diff --git a/software/server-setup.page b/software/server-setup.page
index 1ef884b..b364f7a 100644
--- a/software/server-setup.page
+++ b/software/server-setup.page
@@ -26,7 +26,7 @@ temboz
 ----------
 The temboz feed reader is started by::
 
-$./temboz --server &
+    $ ./temboz --server &
 
 in the appropriate directory.
 
diff --git a/software/unix-tricks.page b/software/unix-tricks.page
index e1366dc..533a174 100644
--- a/software/unix-tricks.page
+++ b/software/unix-tricks.page
@@ -14,5 +14,5 @@ Fork many processes with `xargs`
 -----------------------------------
 To fork off 10 instances of sleep with incremented lengths, 5 at a time::
 
-$ seq 10 20 | xargs -n 1 -P 5 sleep
+    $ seq 10 20 | xargs -n 1 -P 5 sleep
 
diff --git a/tmp/Saccade.page b/tmp/Saccade.page
deleted file mode 100644
index 85693c6..0000000
--- a/tmp/Saccade.page
+++ /dev/null
@@ -1,7 +0,0 @@
-Saccade
--------
-
-Saccades are small movements of the eye which generate a delta in our stream 
-of vision. Similar to the phenomena of "only seeing movement". 
-
-(based on Jeff Hawkin's book "On Intelligence")
diff --git a/tmp/Newcomb paradox.page b/tmp/newcomb-paradox.page
index 58ace89..58ace89 100644
--- a/tmp/Newcomb paradox.page
+++ b/tmp/newcomb-paradox.page
diff --git a/tmp/Teaching CS.page b/tmp/teaching-cs.page
index d441985..d441985 100644
--- a/tmp/Teaching CS.page
+++ b/tmp/teaching-cs.page
diff --git a/tmp/Topics of Curiosity.page b/tmp/topics-of-curiosity.page
index c07b13c..c07b13c 100644
--- a/tmp/Topics of Curiosity.page
+++ b/tmp/topics-of-curiosity.page