anchor.diff:    Logging' section above.
   
   - watch the file /var/log/linuxcnc.log, for instance with `tail -f
  -  /var/log/linuxcnc.log` in a separate terminal window. 
  +  /var/log/linuxcnc.log` in a separate terminal window.
   
   - Verify that logging works - do a `realtime start` followed by a `realtime
   stop`. There should be a few lines of log entries added.
   
   - First, verify basic health of the build: Please run the `runtests`
  -  script and save the list of failed tests 
  +  script and save the list of failed tests
     if any. This can take a long time, it's more than 120 tests by now.
   
   - during the `runtests` step, log file entries should appear in
  -  /var/log/linuxcnc.log. 
  +  /var/log/linuxcnc.log.
   
   - run the failed configuration with increased logging detail in a
     terminal window like so: `DEBUG=5 linuxcnc <yourconfig.ini>` and
     save the output to a file; running the configuration from the
     linuxcnc config selector  will make you miss
  -  likely important output. 
  +  likely important output.
   
   - pastebin the list of failed tests, the console output, /var/log/linuxcnc.log and the
    configuration files if not using a stock configuration.
  
positive.code: This is based largely on the sim_rtapi_app process used in the
  'simulator environment' in previous releases. It is present only in
  userland thread flavors, and is the process context where RT threads
  run. What is does is: 
  
  - attach to the global segment prepared by rtapi_msgd, inheriting
    essential parameters and data structure access 
  - harden memory for RT use (pre-faulting and locking  memory etc)
  - privilege handling - RT process access I/O hardware
  - load the rtapi.so and hal_lib.so components applicable for the
  
negative.code:  4880  4883 FF      98 RLsl fast:0          ?
   4880  4884 FF      97 SLsl slow:0          ?
  ......................................................................
  