anchor.diff:  - storing key information in the header so that there is no longer the requirement that the writers and readers be configured the same.
   - not needing to know the size of the message.
   
  -=== What is Chronicle designed for?
  -
  -Chronicle is design to record everything of interest in the logger and persisted IPC.
  +=== What is Chronicle Queue designed for?
  +
  +Chronicle Queue's design to record everything of interest in the logger and persisted IPC.
   A key requirement of low latency systems is transparency, and you can record enough information to enable a monitoring system to recreate the state of the monitored system.  This allows downstream systems to record any information they need, and perform queries without having to touch the critical system.
   
  -Chronicle works best in `SEDA` style event-driven systems, where latency is critical, and you need a record of exactly what was performed, and  when. All this can be done without expensive network sniffing/recording systems.
  +Chronicle Queue works best in `SEDA` style event-driven systems, where latency is critical, and you need a record of exactly what was performed, and  when. All this can be done without expensive network sniffing/recording systems.
   
   === What was the library originally designed for?
   
  
positive.code: 
  === What is the performance like?
  
  Single Chronicle (single file per cycle) supports sub-microsecond latencies. If you use Wire, the typical latencies tend to be around one micro-second.  You can still use raw writing of bytes if you need maximum performance.
  
  === With a tight reader loop, I see 100% utilization. Will there be processing capability left for anything else?
  
  
negative.code: === What is Single Chronicle Queue?
  
  Single Chronicle Queue is designed to be easier to work with compared with
  the previous vanilla and indexed Chronicle Queue versions.
  It supports:
  
  - concurrent readers in different JVMs.
  