Some small documentation updates

In particular, update COMPARISON notes for Finit, which appears to be
more advanced than I assumed when I wrote the original notes.

doc/COMPARISON

@@ -98,7 +98,6 @@ packages do not:
 
  * Daemontools (http://cr.yp.to/daemontools.html)
  * Epoch (http://universe2.us/epoch.html)
- * Finit (http://github.com/troglobit/finit)
  * Minit (http://www.fefe.de/minit)
  * Perp (http://b0llix.net/perp/)
  * Runit (http://smarden.org/runit/)
@@ -121,7 +120,9 @@ The basic problem of starting login sessions only after system initialisation ha
 partially) completed is naturally solved with a dependency-managing solution; you can have the tty
 sessions (getty) depend on some other service unit which, in turn, depends on the basic system
 initialisation services. In non-dependency-handling managers this must usually be special-cased
-(eg an "inittab" which is processed once all services have started).
+(eg an "inittab" which is processed once all services have started). Some inits (eg finit) use the
+"runlevels" concept from SysV init; they typically start services in run level 0 before any other
+services, which gives a kind of single-depth dependency tree.
 
 With all the above in mind, I feel that dependency management allows generally greater flexibility
 and control in how services are managed. While this might not always be useful, and comes at a
@@ -313,3 +314,16 @@ to define services without any programming knowledge.
 
 The documentation for GNU Shepherd is currently somewhat incomplete. It appears to offer full
 dependency management however.
+
+
+Finit (http://github.com/troglobit/finit)
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+The Finit "fast init" system is minimalistic, with most service configuration via a single line.
+However, it also has some advanced features with an obvious lean towards providing practical
+functionality and reducing external system dependencies. Finit supports "conditions" which
+effectively allow it to support (hard) dependencies. It also supports S6 and Systemd -compatible
+readiness notifications.
+
+Feature-wise, key differences compared to Dinit are probably lack of support for soft
+dependencies, and finer-grained control of individual services (dinit has a raft of service
+options which finit lacks). The finit configuration syntax is noticably terser than dinit's.

doc/linux/DINIT-AS-INIT.md

@@ -118,12 +118,16 @@ and mount. You'll probably want e2fsprogs (or the equivalent for your chosen
 filesystem): http://e2fsprogs.sourceforge.net/
 
 The syslog daemon from GNU Inetutils is basic, but functional - which makes
-it a good fit for a Dinit-based system. https://www.gnu.org/software/inetutils
+it a good fit for a Dinit-based system.  One alternative is sysklogd; the
+enhanced version by troglobit looks promising:
+
+- Inetutils: https://www.gnu.org/software/inetutils
+- Troglobit's sysklogd: https://github.com/troglobit/sysklogd
 
 You will need a shell script interpreter / command line, for which you have
 a range of options. A common choice is GNU Bash, but many distributions are
 using Dash as the /bin/sh shell because it is significantly faster (affecting
-boot time).
+boot time) although it is basically unusable as an interactive shell.
 
 - Bash: https://www.gnu.org/software/bash
 - Dash: http://gondor.apana.org.au/~herbert/dash
@@ -277,3 +281,9 @@ it will not be killed at shutdown (you will need to manually exit the shell to c
 This means you always have a shell available to check system state when something is going wrong.
 While this is not something you want to enable permanently, it can be a good tool to debug a
 reproducible boot issue or shutdown issue.
+
+
+## Caveats
+
+For services which specify a `logfile`, the location must be writable when the service starts
+(otherwise the service will fail to start).