anchor.diff:  plus key parameters driving overall instance parameters. As it is
   known to exist when any RT operations commences, over time some
   parameters and statistics structures have found a better place here
  -than in one of the other segments. 
  +than in one of the other segments.
   
   I [MH] have considered merging the global and RTAPI data segments; however,
   from a stability perspective it is a good decision to relegate access
  
positive.code: architectures. While mostly written in portable languages, some x86
  assumptions and inline assembly code have crept in over time into the
  LinuxCNC code base, meaning builds for other architectures were
  challenging. 
  
  A third aspect of LinuxCNC has been its packaging. While the current
  method of distribution and installation continues to work for serious
  users, its relatively monolithic nature hinders the wider acceptance of 
  LinuxCNC. Getting LinuxCNC into major software repositories
  has been hampered by the fact that a build based on a
  non-mainstream kernel extension is difficult to get accepted for
  
negative.code: 
  === Evolution of the work
  
  The original focus of the recent RTOS work in LinuxCNC was to
  bring together the isolated efforts mentioned above, bring them up to date,
  integrate them into the LinuxCNC build process, and provide means to make
  the process of supporting another future RTOS option easier.
  
  The result of this work has been branches which enable the use of
  