diff --git a/_config.yml b/_config.yml
index 892bf81..943fdc2 100644
--- a/_config.yml
+++ b/_config.yml
@@ -1,8 +1,8 @@
-exclude: [".rvmrc", ".rbenv-version", "README.md", "Rakefile", "static/templates/wikipage.mdt"]
+exclude: [".rvmrc", ".rbenv-version", "README.md", "Rakefile", "static/templates/*"]
 lsi: false
-auto: true
-pygments: true
+highlighter: pygments
 safe: true
+markdown: kramdown
 
 title: Cloud Haskell
 tagline: Erlang-style concurrency for Haskell
diff --git a/_includes/footer.html b/_includes/footer.html
index e163030..abd757f 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -1,28 +1,29 @@
     <footer class="footer">
       <div class="container">
         <p class="pull-right" style="clear: right"><iframe class="github-btn" src="http://ghbtns.com/github-btn.html?user=haskell-distributed&repo=distributed-process&type=watch&count=true" allowtransparency="true" frameborder="0" scrolling="0" width="100px" height="20px"></iframe></p>
-        <p>&copy; 2012 - 2013 <a href="http://twitter.com/welltyped">Well-Typed</a>
+        <p>&copy; 2012 - 2025 <a href="http://twitter.com/welltyped">Well-Typed</a>
             - <a href="http://twitter.com/CloudHaskell" target="_blank">CloudHaskell</a>
             - <a href="https://github.com/hyperthunk" target="_blank">Tim Watson</a>
+            - <a href="https://github.com/haskell-distributed" target="_blank">Distributed Haskell maintainers</a>
         </p>
-        <p class="pull-right" style="clear: right"><iframe class="github-btn" src="http://ghbtns.com/github-btn.html?user=haskell-distributed&repo=distributed-process-platform&type=fork&count=true" allowtransparency="true" frameborder="0" scrolling="0" width="102px" height="20px"></iframe></p>
+        <p class="pull-right" style="clear: right"><iframe class="github-btn" src="http://ghbtns.com/github-btn.html?user=haskell-distributed&repo=distributed-process&type=fork&count=true" allowtransparency="true" frameborder="0" scrolling="0" width="102px" height="20px"></iframe></p>
         <p><a href="http://github.com/haskell-distributed">Code</a> licensed under <a href="https://github.com/haskell-distributed/distributed-process/blob/master/LICENSE" target="_blank">BSD-3</a>,
         </p>
         <p>
-            Website design shamelessly derived from <a href="https://twitter.com/kmett">Edward Kmett's'</a> 
+            Website design shamelessly derived from <a href="https://twitter.com/kmett">Edward Kmett's'</a>
             <a href="http://lens.github.com/">lens library github pages</a> under <a href="http://creativecommons.org/licenses/by/3.0/">CC BY 3.0</a>.
         </p>
         <p class="pull-right" style="clear: right; margin-right: -2px">
             <a href="https://twitter.com/CloudHaskell" class="twitter-follow-button" data-link-color="#0069D6" data-show-count="true">Follow @CloudHaskell</a>
         </p>
         <p><a href="http://glyphicons.com">Glyphicons</a> and <a href="http://www.vectorportal.com/">Vectorportal</a> images reproduced with permission.</p>
-        <p class="pull-right" style="clear: right"><!-- TODO: build status 
+        <p class="pull-right" style="clear: right"><!-- TODO: build status
         --></p>
 
         <ul class="footer-links">
-          <li><a href="http://github.com/haskell-distributed/">Source</a></li>
+          <li><a href="http://github.com/haskell-distributed/distributed-process">Source</a></li>
           <li class="muted">&middot;</li>
-          <li><a href="https://cloud-haskell.atlassian.net">Issues</a></li>
+          <li><a href="https://github.com/haskell-distributed/distributed-process/issues">Issues</a></li>
           <li class="muted">&middot;</li>
           <li><a href="/wiki.html">Wiki</a></li>
           <li class="muted">&middot;</li>
diff --git a/_includes/nav.html b/_includes/nav.html
index 2282ceb..4e45e25 100644
--- a/_includes/nav.html
+++ b/_includes/nav.html
@@ -32,11 +32,10 @@
                 </a>
                 <ul class="dropdown-menu">
                    <li><a href="/wiki.html">Wiki</a></li>
-                   <li><a href="/changes.html">ChangeLog</a></li>
                    <li><a href="http://www.haskell.org/haskellwiki/Cloud_Haskell">CH on haskell.org</a></li>
                    <li><a href="https://github.com/haskell-distributed">Github Repositories</a></li>
-                   <li><a href="https://cloud-haskell.atlassian.net/secure/BrowseProjects.jspa#all">Issue Tracker</a></li>
                    <li><a href="/static/semantics.pdf">Formal Semantics</a></li>
+		   <li><a href="http://dl.acm.org/citation.cfm?id=1863509.1863514&coll=DL&dl=GUIDE&CFID=462193996&CFTOKEN=19836659">Unified semantics for Future Erlang</a></li>
                    <li><a href="http://www.well-typed.com/blog/">Well-Typed Blog</a></li>
                 </ul>
               </li>
diff --git a/_layouts/changelog.html b/_layouts/changelog.html
deleted file mode 100644
index 6c946b4..0000000
--- a/_layouts/changelog.html
+++ /dev/null
@@ -1,58 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-  <head>
-    {% include head.html %}
-    <style>
-      body { padding-top: 0px; }
-     .navbar-fixed-top { position: relative !important; }
-    </style>
-    <link href="/css/sidenav.css" rel="stylesheet">
-  </head>
-  <body data-spy="scroll" data-target=".sidebar"> <!-- data-offset-top="10">-->
-    {% include nav.html %}
-    <div class="container">
-      <ul class="breadcrumb">
-        <li><a href="/">Home</a> <span class="divider">/</span></li>
-        <li><a href="/changes.html">Changelog</a> <span class="divider">/</span></li>
-        <li><a href="">{{ page.title }}</a> <spawn class="divider">/</span></li>
-      </ul>
-    </div>
-    <div class="container">
-      <div class="row">
-        <div class="span3 sidebar">
-          <div data-spy="affix" data-offset-bottom="290">
-            <ul class="nav nav-list sidenav">
-            {% for page in site.pages %}
-                {% if page.url contains '/changelog/' %}
-                <li><a href="{{ page.url }}">{{ page.title }}</a></li>
-                {% endif %}
-            {% endfor %}
-           </ul>
-          </div>
-        </div>
-        <div class="span9">
-          <h4>Version <a href="{{ page.release }}">{{ page.version }}</a></h4>
-          <h4>Status: {% if page.status contains 'Released' %}
-                          <a href="https://hackage.haskell.org/package/{{ page.title }}">{{ page.status }}</a>
-                      {% else %}
-                          Pending Release
-                      {% endif %}
-          </h4>
-          <h4>Due/Released: {{ page.date }}</h4>
-          <h4><a href="https://github.com/haskell-distributed/distributed-process/compare/{{ page.commits }}">Code Changes (redirects to github)</a></h4>
-          {{ content }}
-          <a href="{{ page.feed_url }}"><h5>Issue RSS Feed</h5></a>
-        </div>
-        <!--
-        <div class="span9">
-            <h4>Upgrading</h4>
-            TODO: some generic advice about upgrading??
-        </div>
-        -->
-      </div>
-    </div>
-    {% include footer.html %}
-    {% include js.html %}
-  </body>
-</html>
-
diff --git a/_layouts/changes.html b/_layouts/changes.html
deleted file mode 100644
index 8144182..0000000
--- a/_layouts/changes.html
+++ /dev/null
@@ -1,41 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-  <head>
-    {% include head.html %}
-    <style>
-      body { padding-top: 0px; }
-     .navbar-fixed-top { position: relative !important; }
-    </style>
-    <link href="/css/sidenav.css" rel="stylesheet">
-  </head>
-  <body data-spy="scroll" data-target=".sidebar"> <!-- data-offset-top="10">-->
-    {% include nav.html %}
-    <div class="container">
-      <ul class="breadcrumb">
-        <li><a href="/">Home</a> <span class="divider">/</span></li>
-        <li><a href="/changes.html">Changes</a> <span class="divider">/</span></li>
-      </ul>
-    </div>
-    <div class="container">
-      <div class="row">
-        <div class="span3 sidebar">
-          <div data-spy="affix" data-offset-bottom="290">
-            <ul class="nav nav-list sidenav">
-              {% for page in site.pages %}
-                  {% if page.url contains '/changelog/' %}
-                  <li><a href="{{ page.url }}">{{ page.title }}</a></li>
-                  {% endif %}
-              {% endfor %}
-           </ul>
-          </div>
-        </div>
-        <div class="span9">
-          {{ content }}
-        </div>
-      </div>
-    </div>
-    {% include footer.html %}
-    {% include js.html %}
-  </body>
-</html>
-
diff --git a/_layouts/documentation.html b/_layouts/documentation.html
index 88b17ed..6dbf534 100644
--- a/_layouts/documentation.html
+++ b/_layouts/documentation.html
@@ -21,12 +21,12 @@
         <div class="span3 sidebar">
           <div data-spy="affix" data-offset-bottom="290">
             <ul class="nav nav-list sidenav">
-              <li><a href="#cloud_haskell_platform"><i class="icon-chevron-right"></i> Cloud Haskell Platform</a></li>
-              <li><a href="#network_transport_abstraction_layer"><i class="icon-chevron-right"></i> Network Abstraction Layer</a></li>
-              <li><a href="#concurrency_and_distribution"><i class="icon-chevron-right"></i> Concurrency and Distribution</a></li>
-              <li><a href="#what_is_serializable"><i class="icon-chevron-right"></i> What is Serializable</a></li>
-              <li><a href="#typed_channels"><i class="icon-chevron-right"></i> Typed Channels</a></li>
-              <li><a href="#rethinking_the_task_layer"><i class="icon-chevron-right"></i> Rethinking the Task Layer</a></li>
+              <li><a href="#cloud-haskell-platform"><i class="icon-chevron-right"></i> Cloud Haskell Platform</a></li>
+              <li><a href="#network-transport-abstraction-layer"><i class="icon-chevron-right"></i> Network Abstraction Layer</a></li>
+              <li><a href="#concurrency-and-distribution"><i class="icon-chevron-right"></i> Concurrency and Distribution</a></li>
+              <li><a href="#what-is-serializable"><i class="icon-chevron-right"></i> What is Serializable</a></li>
+              <li><a href="#typed-channels"><i class="icon-chevron-right"></i> Typed Channels</a></li>
+              <li><a href="#rethinking-the-task-layer"><i class="icon-chevron-right"></i> Rethinking the Task Layer</a></li>
            </ul>
           </div>
         </div>
diff --git a/_layouts/post.html b/_layouts/post.html
deleted file mode 100644
index b187f73..0000000
--- a/_layouts/post.html
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
----
-<div class="container">
-  <ul class="breadcrumb">
-    <li><a href="/">Home</a> <span class="divider">/</span></li>
-    <li><a href="/posts.html">Posts</a> <span class="divider">/</span></li>
-    <li>{{ page.date | date: "%B %d, %Y" }} <span class="divider">/</span></li>
-    <li class="active">{{ page.title }}</li>
-  </ul>
-</div>
-<div class="container">
-  {{ content }}
-</div> <!-- /container -->
diff --git a/_layouts/tutorial.html b/_layouts/tutorial.html
index b44874c..a18a626 100644
--- a/_layouts/tutorial.html
+++ b/_layouts/tutorial.html
@@ -23,7 +23,7 @@
             <ul class="nav nav-list sidenav">
               {% for section in page.sections %}
                 <li>
-                    <a href="#{{ section | downcase | replace: ' ', '_' }}"><i class="icon-chevron-right"></i> {{ section }}</a>
+                    <a href="#{{ section | downcase | replace: ' ', '-' }}"><i class="icon-chevron-right"></i> {{ section }}</a>
                 </li>
               {% endfor %}
            </ul>
diff --git a/_layouts/tutorial2.html b/_layouts/tutorial2.html
index 904b2bb..575daf6 100644
--- a/_layouts/tutorial2.html
+++ b/_layouts/tutorial2.html
@@ -22,9 +22,9 @@
           <div data-spy="affix" data-offset-bottom="290">
             <ul class="nav nav-list sidenav">
               <li><a href="#introduction"><i class="icon-chevron-right"></i> Introduction</a></li>
-              <li><a href="#the_network_transport_api"><i class="icon-chevron-right"></i> The network-transport API</a></li>
-              <li><a href="#writing_the_client"><i class="icon-chevron-right"></i> Writing the client</a></li>
-              <li><a href="#writing_the_server"><i class="icon-chevron-right"></i> Writing the server</a></li>
+              <li><a href="#the-network-transport-api"><i class="icon-chevron-right"></i> The network-transport API</a></li>
+              <li><a href="#writing-the-client"><i class="icon-chevron-right"></i> Writing the client</a></li>
+              <li><a href="#writing-the-server"><i class="icon-chevron-right"></i> Writing the server</a></li>
               <li><a href="#conclusion"><i class="icon-chevron-right"></i> Conclusion</a></li>
            </ul>
           </div>
diff --git a/_posts/2014-02-06-new-cloud-haskell-website.md b/_posts/2014-02-06-new-cloud-haskell-website.md
new file mode 100644
index 0000000..ddd4446
--- /dev/null
+++ b/_posts/2014-02-06-new-cloud-haskell-website.md
@@ -0,0 +1,9 @@
+---
+layout: post
+category: announcements
+tags: [announcement, distributed-process, website]
+title: "[ANNOUNCE] New Cloud Haskell Website / Tutorials Preview"
+teaser: Some updates to the website, documentation and tutorials are available for preview now
+author: Tim Watson
+link: https://groups.google.com/forum/#!topic/parallel-haskell/bApvWg7K7-4
+---
diff --git a/_posts/2014-02-12-static-pointers.md b/_posts/2014-02-12-static-pointers.md
new file mode 100644
index 0000000..de339dd
--- /dev/null
+++ b/_posts/2014-02-12-static-pointers.md
@@ -0,0 +1,9 @@
+---
+layout: post
+category: announcements
+tags: [announcement, distributed-process]
+title: "[ANNOUNCE]  Static Pointers Language Extension"
+teaser: Simon reflects on Cloud-Haskell-style static pointers and serialisation
+author: Simon PJ
+link: https://ghc.haskell.org/trac/ghc/blog/simonpj/StaticPointers
+---
diff --git a/_posts/2014-03-28-network-transport-zeromq.md b/_posts/2014-03-28-network-transport-zeromq.md
new file mode 100644
index 0000000..8050ac7
--- /dev/null
+++ b/_posts/2014-03-28-network-transport-zeromq.md
@@ -0,0 +1,9 @@
+---
+layout: post
+category: announcements
+tags: [announcement, distributed-process]
+title: "[ANNOUNCE] network-transport-zeromq-0.1"
+teaser: I'm happy to announce a new network-transport backend based on the 0MQ brokerless protocol
+author: Alexander Vershilov
+link: https://groups.google.com/forum/#!topic/parallel-haskell/1Yu1VkI7YkY
+---
diff --git a/_posts/2014-05-30-cloud-haskell-release-candidate-on-hackage.md b/_posts/2014-05-30-cloud-haskell-release-candidate-on-hackage.md
new file mode 100644
index 0000000..a5cc888
--- /dev/null
+++ b/_posts/2014-05-30-cloud-haskell-release-candidate-on-hackage.md
@@ -0,0 +1,9 @@
+---
+layout: post
+category: announcements
+tags: [announcement, distributed-process]
+title: "[ANNOUNCE] Cloud Haskell Release Candidate on Hackage"
+teaser: The latest version of Cloud Haskell is finally being released onto hackage.
+author: Tim Watson
+link: https://groups.google.com/forum/#!topic/parallel-haskell/1Yu1VkI7YkY
+---
diff --git a/_posts/2014-06-13-cloud-haskell-is-live.md b/_posts/2014-06-13-cloud-haskell-is-live.md
new file mode 100644
index 0000000..1f2bff2
--- /dev/null
+++ b/_posts/2014-06-13-cloud-haskell-is-live.md
@@ -0,0 +1,9 @@
+---
+layout: post
+category: announcements
+tags: [announcement, distributed-process]
+title: "[ANNOUNCE] Cloud Haskell is Live!"
+teaser: The latest version of Cloud Haskell is finally being released onto hackage.
+author: Tim Watson
+link: https://groups.google.com/forum/#!topic/parallel-haskell/1Yu1VkI7YkY
+---
diff --git a/_posts/2014-08-13-distributed-process-0.5.1.md b/_posts/2014-08-13-distributed-process-0.5.1.md
new file mode 100644
index 0000000..2e3ab4d
--- /dev/null
+++ b/_posts/2014-08-13-distributed-process-0.5.1.md
@@ -0,0 +1,9 @@
+---
+layout: post
+category: announcements
+tags: [announcement, distributed-process]
+title: "[ANNOUNCE]  distributed-process-0.5.1"
+teaser: A bug-fix version of distributed-process has been uploaded to hackage.
+author: Tim Watson
+link: https://groups.google.com/forum/#!topic/parallel-haskell/kRksoYRLGes
+---
diff --git a/_posts/2015-06-17-cloud-haskell-0.2.2.md b/_posts/2015-06-17-cloud-haskell-0.2.2.md
new file mode 100644
index 0000000..60463ff
--- /dev/null
+++ b/_posts/2015-06-17-cloud-haskell-0.2.2.md
@@ -0,0 +1,9 @@
+---
+layout: post
+category: announcements
+tags: [announcement, distributed-process]
+title: "[ANNOUNCE]  Cloud Haskell 0.2.2"
+teaser: A bug-fix version of Cloud Haskell stack has been uploaded to hackage.
+author: Facundo Domínguez
+link: https://groups.google.com/forum/#!topic/distributed-haskell/bOZ-ey43myE
+---
diff --git a/_posts/2015-06-30-network-transport-inmemory-0.5.0.md b/_posts/2015-06-30-network-transport-inmemory-0.5.0.md
new file mode 100644
index 0000000..2fae307
--- /dev/null
+++ b/_posts/2015-06-30-network-transport-inmemory-0.5.0.md
@@ -0,0 +1,9 @@
+---
+layout: post
+category: announcements
+tags: [announcement, network-transport-inmemory]
+title: "[ANNOUNCE] network-transport-inmemory 0.5.0"
+teaser: The first release of network-transport-inmemory has been uploaded to hackage.
+author: Facundo Domínguez
+link: https://groups.google.com/forum/#!topic/distributed-haskell/gD8XP0wDuvU
+---
diff --git a/_posts/2016-02-19-announce-0.6.0.md b/_posts/2016-02-19-announce-0.6.0.md
new file mode 100644
index 0000000..c4d75b4
--- /dev/null
+++ b/_posts/2016-02-19-announce-0.6.0.md
@@ -0,0 +1,9 @@
+---
+layout: post
+category: announcements
+tags: [announcement, distributed-process]
+title: "[ANNOUNCE] distributed-process-0.6.0"
+teaser: A new version of Cloud Haskell stack has been uploaded to hackage.
+author: Facundo Domínguez
+link: https://groups.google.com/forum/#!topic/distributed-haskell/A_LuR_XXZdE
+---
diff --git a/changelog/dp-0.4.1.md b/changelog/dp-0.4.1.md
deleted file mode 100644
index cc650ab..0000000
--- a/changelog/dp-0.4.1.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-layout: changelog
-title: distributed-process-0.4.1
-date: Sun Jan 27 15:12:02 UTC 2013
-status: Released
-version: 0.4.1
-commits: distributed-process-0.4.0.2...distributed-process-0.4.1
-hackage: https://hackage.haskell.org/package/distributed-process
----
----------
-<h4>Notes</h4>
-
-This is a small feature release containing various enhancements.
-
----------
-<h4>Improvements</h4>
-<ul>
-<li><a href="https://github.com/haskell-distributed/distributed-process/commit/a5faffd">Update package boundaries </a></li>
-<li><a href="https://github.com/haskell-distributed/distributed-process/commit/0f03091">depend on binary-0.6 instead of 0.5</a></li>
-<li><a href="https://github.com/haskell-distributed/distributed-process/commit/294e873">Require http-conduit >= 1.8.1</a></li>
-<li><a href="https://github.com/haskell-distributed/distributed-process/commit/8b95ef1">Implement receiveChanTimeout</a></li>
-<li><a href="https://github.com/haskell-distributed/distributed-process/commit/37b0263">Changed semantics of register/unregister to match Erlang</a></li>
-<li><a href="https://github.com/haskell-distributed/distributed-process/commit/24163c2">Fixed de-registration of remote processes when the process terminates</a></li>
diff --git a/changelog/dp-0.4.2.md b/changelog/dp-0.4.2.md
deleted file mode 100644
index 2488d4f..0000000
--- a/changelog/dp-0.4.2.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: changelog
-title: distributed-process-0.4.2
-date: Sun Jan 27 15:12:02 UTC 2013
-status: Released
-version: 0.4.2
-commits: distributed-process-0.4.1...v0.4.2
-hackage: https://hackage.haskell.org/package/distributed-process
-release: https://cloud-haskell.atlassian.net/browse/DP/fixforversion/10006
-feed_url: https://cloud-haskell.atlassian.net/sr/jira.issueviews:searchrequest-rss/temp/SearchRequest.xml?jqlQuery=project+%3D+DP+AND+status+%3D+Closed+AND+fixVersion+%3D+0.4.2&tempMax=1000
----
----------
-<h4>Notes</h4>
-
-This is a small feature release containing process management enhancements and
-a new tracing/debugging capability.
-
----------
-<h4>Bugs</h4>
-<ul>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-60'>DP-60</a>] - Fixes made for the distributed-process with strict bytestrings
-</li>
-</ul>
-
-<h4>Improvements</h4>
-<ul>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-61'>DP-61</a>] - Switched from Binary to cereal, allowed switching between lazy and strict ByteString
-</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-31'>DP-31</a>] - Messages from the &quot;main channel&quot; as a receivePort
-</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-35'>DP-35</a>] - Add variants of exit and kill for the current process
-</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-50'>DP-50</a>] - Support for killing processes
-</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-51'>DP-51</a>] - provide local versions of spawnLink and spawnMonitor
-</li>
-<li>[<a href="https://cloud-haskell.atlassian.net/browse/DP-13"> - Tracing and Debugging support]
-</li>
-</ul>
diff --git a/changelog/dp-0.5.0.md b/changelog/dp-0.5.0.md
deleted file mode 100644
index fddcc38..0000000
--- a/changelog/dp-0.5.0.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-layout: changelog
-title: distributed-process-0.5.0
-status: Released
-date: Wen May 28 12:15:02 UTC 2014
-version: 0.5.0
-commits: distributed-process-0.4.2...master
-hackage: https://hackage.haskell.org/package/distributed-process
-release: https://cloud-haskell.atlassian.net/browse/DP/fixforversion/10008
-feed_url: https://cloud-haskell.atlassian.net/sr/jira.issueviews:searchrequest-rss/temp/SearchRequest.xml?jqlQuery=project+%3D+DP+AND+status+%3D+Closed+AND+fixVersion+%3D+0.5.0&tempMax=1000
----
----------
-<h4>Notes</h4>
-
-This is a full feature release containing important enhancements to inter-process messaging,
-process and node management, debugging and tracing. Various bug-fixes have also been made.
-
-<h5><b>Highlights</b></h5>
-
-New advanced messaging APIs provide broader polymorphic primitives for receiving and processing message
-regardless of the underlying (when decoded) types. Extended exit handling capabilities have been added,
-to facilitate processing *exit signals* when the *exit reason* could be represented by a variety of
-underlying types.
-
-The performance of inter-process messaging has been optimised for intra-node use cases. Messages are no
-longer sent over the network-transport infrastructure when the receiving process resides on the same node
-as the sender. New `unsafe` APIs have been made available to allow code that uses intra-node messaging to
-skip the serialization of messages, facilitating further performance benefits at the risk of altered
-error handling semantics. More details are available in the [`UnsafePrimitives` documentation][1].
-
-A new [*Management API*][2] has been added, giving user code the ability to receive and respond to a running
-node's internal system events. The tracing and debugging support added in 0.4.2 has been [upgraded][3] to use
-this API, which is more efficient and flexible.
-
----------
-
-<h4>Bugs</h4>
-<ul>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-68'>DP-68</a>] - Dependency on STM implicitly changed from 1.3 to 1.4, but was not reflected in the .cabal file</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-79'>DP-79</a>] - Race condition in local monitoring when using `call`</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-94'>DP-94</a>] - mask does not work correctly if unmask is called by another process</li>
-</ul>
-
-<h4>Improvements</h4>
-<ul>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-20'>DP-20</a>] - Improve efficiency of local message passing</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-77'>DP-77</a>] - nsend should use local communication channels</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-39'>DP-39</a>] - Link Node Controller and Network Listener</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-62'>DP-62</a>] - Label spawned processes using labelThread</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-85'>DP-85</a>] - Relax upper bound on syb in the cabal manifest</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-78'>DP-78</a>] - Bump binary version to include 0.7.*</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-91'>DP-91</a>] - Move tests to https://github.com/haskell-distributed/distributed-process-tests</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-92'>DP-92</a>] - Expose process info</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-92'>DP-92</a>] - Expose node statistics</li>
-</ul>
-
-<h4>New Features</h4>
-<ul>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-7'>DP-7</a>] - Polymorphic expect (see details <a href='https://hackage.haskell.org/package/distributed-process-0.5.0/docs/Control-Distributed-Process.html#g:5'>here</a>)</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-57'>DP-57</a>] - Expose Message and broaden the scope of polymorphic expect</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-84'>DP-84</a>] - Provide an API for working with internal (system) events</li>
-<li>[<a href='https://cloud-haskell.atlassian.net/browse/DP-83'>DP-83</a>] - Report node statistics for monitoring/management</li>
-</ul>
-
-
-[1]: https://hackage.haskell.org/package/distributed-process-0.5.0/docs/Control-Distributed-Process-UnsafePrimitives.html
-[2]: https://hackage.haskell.org/package/distributed-process-0.5.0/docs/Control-Distributed-Process-Management.html
-[3]: https://hackage.haskell.org/package/distributed-process-0.5.0/docs/Control-Distributed-Process-Debug.html
diff --git a/contact.html b/contact.html
index 9a8385d..bd3a774 100644
--- a/contact.html
+++ b/contact.html
@@ -2,36 +2,50 @@
 layout: marketing
 title: Contact
 ---
-    <div class="container">
-      <ul class="breadcrumb">
-        <li><a href="/">Home</a> <span class="divider">/</span></li>
-        <li class="active">Contact</li>
-      </ul>
-    </div>
-
-    <div class="container marketing">
-      <div class="row">
 
-        <div class="span4">
-          <img class="img-circle" style="width:300px; height: 300px" src="/img/icon_irc_400x400.png">
-          <h2>IRC</h2>
-          <p>You'll probably find us lurking in the #haskell-distributed channel on freenode, where you can get help with your questions. There is also the general purpose #haskell channel.</p>
-          <p><a class="btn btn-primary" href="http://webchat.freenode.net/?channels=haskell-distributed&uio=d4">Visit us on IRC</a></p>
-        </div>
+<div class="container">
+  <ul class="breadcrumb">
+    <li><a href="/">Home</a> <span class="divider">/</span></li>
+    <li class="active">Contact</li>
+  </ul>
+</div>
 
-        <div class="span4">
-          <img class="img" style="width:400px; height: 300px" src="/img/logoJIRAPNG.png">
-          <h2>Issues Tracker</h2>
-          <p>Notice a problem that you don't know how to fix? Or want to request a new feature?
-          (in order to create new issues you will need to create a login)</p>
-          <p><a class="btn btn-primary" href="https://cloud-haskell.atlassian.net/secure/BrowseProjects.jspa#all">Browse Issues</a></p>
-        </div>
+<div class="container marketing">
+  <div class="row">
+    <div class="span3">
+      <img class="img-circle" src="/img/github-mark.png">
+    </div>
+    <div class="span3">
+      <img class="img-circle" src="/img/icon_slack.png">
+    </div>
+    <div class="span3">
+      <img class="img-circle" src="/img/icon_irc.png">
+    </div>
+    <div class="span3">
+      <img class="img-circle" src="/img/email_128x128.png">
+    </div>
+  </div>
 
-        <div class="span4">
-          <img class="img-circle" style="width:300px; height: 300px" src="/img/email_128x128.png">
-          <h2>Email</h2>
-          <p>If you have any questions or concerns, please email the parallel-haskell mailing list in the first instace.</p>
-          <p><a class="btn btn-primary" href="mailto:parallel-haskell@googlegroups.com">Send Email</a></p>
-        </div>
-      </div>
+  <div class="row">
+    <div class="span3">
+      <h2>GitHub</h2>
+      <p>Free free to ask questions via GitHub Discussions</p>
+      <p><a class="btn btn-primary" href="https://github.com/haskell-distributed/distributed-process/discussions">Start a Discussion</a></p>
+    </div>
+    <div class="span3">
+      <h2>Slack</h2>
+      <p>People have been active on Slack recently. Get an invite and drop in.</p>
+      <p><a class="btn btn-primary" href="https://rauchg-slackin-dxinpkuzrg.now.sh/">Get a Slack invite</a></p>
+    </div>
+    <div class="span3">
+      <h2>IRC</h2>
+      <p>You'll probably find us lurking in the #haskell-distributed channel on freenode, where you can get help with your questions. There is also the general purpose #haskell channel.</p>
+      <p><a class="btn btn-primary" href="http://webchat.freenode.net/?channels=haskell-distributed&uio=d4">Visit us on IRC</a></p>
+    </div>
+    <div class="span3">
+      <h2>Email</h2>
+      <p>If you have any questions or concerns, please email the parallel-haskell mailing list in the first instace.</p>
+      <p><a class="btn btn-primary" href="mailto:parallel-haskell@googlegroups.com">Send Email</a></p>
     </div>
+  </div>
+</div>
diff --git a/documentation.md b/documentation.md
index 0279619..b59ed15 100644
--- a/documentation.md
+++ b/documentation.md
@@ -28,12 +28,25 @@ on Cloud Haskell and this reimplementation, which is worth reading in conjunctio
 with the documentation and wiki pages on this website..
 
 Cloud Haskell comprises the following components, some of which are complete,
-others experimental.
+others experimental. There are three main parts:
 
-* [distributed-process][distributed-process]: Base concurrency and distribution support
-* [distributed-process-platform][distributed-process-platform]: The Cloud Haskell Platform - APIs
+#### The core libraries
+
+* [distributed-process][distributed-process]: Base concurrency and distribution support. It provides a number of primitives known from Erlang like `link` and `monitor`.
 * [distributed-static][distributed-static]: Support for static values
 * [rank1dynamic][rank1dynamic]: Like `Data.Dynamic` and `Data.Typeable` but supporting polymorphic values
+
+#### The platform libraries
+
+* [distributed-process-client-server][distributed-process-client-server]: Common client/server patterns like Erlang's `gen_server`
+* [distributed-process-async][distributed-process-async]: Future-style computations
+* [distributed-process-task][distributed-process-task]: A worker queue
+* [distributed-process-extras][distributed-process-extras]: Monitoring, logging, resolving names etc.
+* [distributed-process-registry][distributed-process-registry]: A key-value registry
+* [distributed-process-execution][distributed-process-execution]: Load regulation, work shedding, hand-off etc.
+
+#### The network layer
+
 * [network-transport][network-transport]: Generic `Network.Transport` API
 * [network-transport-tcp][network-transport-tcp]: TCP realisation of `Network.Transport`
 * [network-transport-inmemory][network-transport-inmemory]: In-memory realisation of `Network.Transport` (incomplete)
@@ -212,7 +225,7 @@ runProcess  :: LocalNode -> Process () -> IO ()
 {% endhighlight %}
 
 Once we've spawned some processes, they can communicate with one another
-using the messaging primitives provided by [distributed-processes][distributed-processes],
+using the messaging primitives provided by [distributed-process][distributed-process],
 which are well documented in the haddocks.
 
 ### What is Serializable
@@ -319,19 +332,19 @@ is managed in the *process layer*, whilst a higher level API described as the
 * data centric processing model
 * a promise (or *future*) abstraction, representing the result of a calculation that may or may not have yet completed
 
-The [distributed-process-platform][distributed-process-platform] library implements parts of the
+The [distributed-process-task][distributed-process-task] library implements parts of the
 *task layer*, but takes a very different approach to that described
 in the original paper and implemented by the [remote][remote] package. In particular,
 we diverge from the original design and defer to many of the principles
 defined by Erlang's [Open Telecom Platform][OTP], taking in some well established
 Haskell concurrency design patterns along the way.
 
-In fact, [distributed-process-platform][distributed-process-platform] does not really consider the
+In fact, [distributed-process-async][distributed-process-async] does not really consider the
 *task layer* in great detail. We provide an API comparable to remote's
-`Promise` in `Control.Distributed.Process.Platform.Async`. This API however,
+`Promise` in `Control.Distributed.Process.Async`. This API however,
 is derived from Simon Marlow's [Control.Concurrent.Async][async] package, and is not
 limited to blocking queries on `Async` handles in the same way. Instead our
-[API][d-p-platform-async] handles both blocking and non-blocking queries, polling
+[API][d-p-async-async] handles both blocking and non-blocking queries, polling
 and working with lists of `Async` handles. We also eschew throwing exceptions
 to indicate asynchronous task failures, instead handling *task* and connectivity
 failures using monitors. Users of the API need only concern themselves with the
@@ -388,7 +401,7 @@ Work is also underway to provide abstractions for managing asynchronous tasks
 at a higher level, focussing on workload distribution and load regulation.
 
 The kinds of task that can be performed by the async implementations in
-[distributed-process-platform][distributed-process-platform] are limited only by their return type:
+[distributed-process-async][distributed-process-async] are limited only by their return type:
 it **must** be `Serializable` - that much should've been obvious by now.
 The type of asynchronous task definitions comes in two flavours, one for
 local nodes which require no remote-table or static serialisation dictionary,
@@ -427,14 +440,14 @@ domain was more *haskell-ish* than working with bare send and receive primitives
 The `Async` sub-package also provides a type safe interface for receiving data,
 although it is limited to running a computation and waiting for its result.
 
-The [Control.Distributed.Processes.Platform.ManagedProcess][d-p-platform-ManagedProcess] API provides a
+The [Control.Distributed.Processes.Platform.ManagedProcess][d-p-client-server-ManagedProcess] API provides a
 number of different abstractions that can be used to achieve similar benefits
 in your code. It works by introducing a standard protocol between your process
 and the *world outside*, which governs how to handle request/reply processing,
 exit signals, timeouts, sleeping/hibernation with `threadDelay` and even provides
 hooks that terminating processes can use to clean up residual state.
 
-The [API documentation][d-p-platform-ManagedProcess] is quite extensive, so here we will simply point
+The [API documentation][d-p-client-server-ManagedProcess] is quite extensive, so here we will simply point
 out the obvious differences. A process implemented with `ManagedProcess`
 can present a type safe API to its callers (and the server side code too!),
 although that's not its primary benefit. For a very simplified example:
@@ -486,8 +499,8 @@ API, which looks a lot like `Async` but manages exit signals in a single thread
 configurable task pools and task supervision strategy part of its API.
 
 More complex examples of the `ManagedProcess` API can be seen in the
-[Managed Processes tutorial](tutorials/tutorial3.html). API documentation for HEAD is available
-[here][d-p-platform-ManagedProcess].
+[Managed Processes tutorial](tutorials/4ch.html). API documentation for HEAD is available
+[here][d-p-client-server-ManagedProcess].
 
 ### Supervision Trees
 
@@ -500,7 +513,12 @@ TBC
 [cloud-haskell]: http://haskell-distributed.github.io/documentation.html
 [fun201202-coutts]: http://sneezy.cs.nott.ac.uk/fun/2012-02/coutts-2012-02-28.pdf
 [distributed-process]: https://github.com/haskell-distributed/distributed-process
-[distributed-process-platform]: https://github.com/haskell-distributed/distributed-process-platform
+[distributed-process-client-server]: https://github.com/haskell-distributed/distributed-process-client-server
+[distributed-process-async]: https://github.com/haskell-distributed/distributed-process-async
+[distributed-process-execution]: https://github.com/haskell-distributed/distributed-process-execution
+[distributed-process-extras]: https://github.com/haskell-distributed/distributed-process-extras
+[distributed-process-task]: https://github.com/haskell-distributed/distributed-process-task
+[distributed-process-registry]: https://github.com/haskell-distributed/distributed-process-registry
 [distributed-static]: http://hackage.haskell.org/package/distributed-static
 [rank1dynamic]: http://hackage.haskell.org/package/rank1dynamic
 [network-transport]: http://hackage.haskell.org/package/network-transport
@@ -513,6 +531,6 @@ TBC
 [haskell11-ch]: http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remote.pdf
 [OTP]: http://en.wikipedia.org/wiki/Open_Telecom_Platform
 [remote]: http://hackage.haskell.org/package/remote
-[d-p-platform-async]: http://hackage.haskell.org/package/distributed-process-platform/Control-Distributed-Process-Platform-Async.html
+[d-p-async-async]: https://hackage.haskell.org/package/distributed-process-async/docs/Control-Distributed-Process-Async.html
 [async]: http://hackage.haskell.org/package/async
-[d-p-platform-ManagedProcess]: http://hackage.haskell.org/package/distributed-process-platform/Control-Distributed-Process-Platform-ManagedProcess.html
+[d-p-client-server-ManagedProcess]: https://hackage.haskell.org/package/distributed-process-client-server/docs/Control-Distributed-Process-ManagedProcess.html
diff --git a/img/github-mark.png b/img/github-mark.png
new file mode 100644
index 0000000..6cb3b70
Binary files /dev/null and b/img/github-mark.png differ
diff --git a/img/icon_irc.png b/img/icon_irc.png
new file mode 100644
index 0000000..850d3f3
Binary files /dev/null and b/img/icon_irc.png differ
diff --git a/img/icon_irc_400x400.png b/img/icon_irc_400x400.png
deleted file mode 100644
index 58154ec..0000000
Binary files a/img/icon_irc_400x400.png and /dev/null differ
diff --git a/img/logoJIRAPNG.png b/img/logoJIRAPNG.png
deleted file mode 100644
index 968ae88..0000000
Binary files a/img/logoJIRAPNG.png and /dev/null differ
diff --git a/index.md b/index.md
index abaefb5..aab87c9 100644
--- a/index.md
+++ b/index.md
@@ -4,33 +4,16 @@ title: Home
 ---
 Cloud Haskell: Erlang-style concurrent and distributed programming in Haskell.
 The Cloud Haskell Platform consists of a
-[generic network transport API](https://github.com/haskell-distributed/network-transport),
-libraries for sending [static closures](https://github.com/haskell-distributed/distributed-static) to remote nodes, a rich [API for distributed programming](https://github.com/haskell-distributed/distributed-process) and a 
-set of [Platform Libraries](https://github.com/haskell-distributed/distributed-process-platform),
-modelled after Erlang's [Open Telecom Platform](http://www.erlang.org/doc/).
+[generic network transport API](https://github.com/haskell-distributed/distributed-process/tree/master/packages/network-transport),
+libraries for sending [static closures](https://github.com/haskell-distributed/distributed-process/tree/master/packages/distributed-static) to remote nodes, a rich [API for distributed programming](https://github.com/haskell-distributed/distributed-process/tree/master/packages/distributed-process) and a
+set of platform libraries modelled after Erlang's [Open Telecom Platform](http://www.erlang.org/doc/).
 
 Generic network transport backends have been developed for
-[TCP](https://github.com/haskell-distributed/network-transport-tcp) and
-[in-memory](https://github.com/haskell-distributed/network-transport-inmemory)
+[TCP](https://github.com/haskell-distributed/distributed-process/tree/master/packages/network-transport-tcp) and
+[in-memory](https://github.com/haskell-distributed/distributed-process/tree/master/packages/network-transport-inmemory)
 messaging, and several other implementations are available including a transport for
 [Windows Azure](https://github.com/haskell-distributed/distributed-process-azure). The [wiki](/wiki.html) provides links to a number of resources for learning about the conceptual underpinnings of Cloud Haskell, and some [examples](https://github.com/haskell-distributed/distributed-process-demos).
 
 Documentation is available on this site for HEAD, or
 [hackage](http://hackage.haskell.org/package/distributed-process) for the current and preceding versions of
 each library.
-
-### <a href="/rss.xml"><img src="/img/feed-icon-28x28.png"></a> Recent Activity <a class="pull-right" href="http://hackage.haskell.org/platform" ><img src="http://hackage.haskell.org/platform/icons/button-64.png"></a>
-
-<div class="content">
-  <div class="related">
-    <ul>
-      {% for post in site.posts %}
-      <li>
-        <span>{{ post.date | date: "%B %e, %Y" }}</span> &middot; <span>{{post.author}}</span> &middot; <span><a href="{% if post.link != null %}{{ post.link }}{% else %}{{ post.url }}{% endif %}">{{ post.title }}</a></span>
-      </li>
-      {% endfor %}
-    </ul>
-  </div>
-</div>
-
-
diff --git a/posts.md b/posts.md
deleted file mode 100644
index 09fcb12..0000000
--- a/posts.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-layout: page
-title: Posts
----
-### <a href="/rss.xml"><img src="/img/feed-icon-28x28.png"></a> Posts
-
-<div class="related">
-  <ul>
-    {% for post in site.posts %}
-    <li>
-      <span>{{ post.date | date: "%B %e, %Y" }}</span> &middot; <span>{{post.author}}</span> &middot; <span><a href="{% if post.link != null %}{{ post.link }}{% else %}{{ post.url }}{% endif %}">{{ post.title }}</a></span>
-    </li>
-    {% endfor %}
-  </ul>
-</div>
diff --git a/rss.xml b/rss.xml
deleted file mode 100644
index 2bea128..0000000
--- a/rss.xml
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: none
----
-<?xml version="1.0" encoding="ISO-8859-1" ?>
-<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
-    <channel>
-        <title>{{ site.name }} - Articles</title>
-        <description>{{ site.description }}</description>
-        <link>{{ site.url }}</link>
-        {% for post in site.posts %}
-            <item>
-                <title>{{ post.title }}</title>
-                <description>{{ post.content | xml_escape }}</description>
-                <pubDate>{{ post.date | date: "%a, %d %b %Y %H:%M:%S %z" }}</pubDate>
-                <link>{{ post.link | escape }}</link>
-                <guid isPermaLink="true">{{ site.url }}{{ post.url }}</guid>
-            </item>
-        {% endfor %}
-    </channel>
-</rss>
diff --git a/static/tutorial/tutorial-client.hs b/static/tutorial/tutorial-client.hs
index b5677ae..a3acd5f 100644
--- a/static/tutorial/tutorial-client.hs
+++ b/static/tutorial/tutorial-client.hs
@@ -1,11 +1,12 @@
 import Network.Transport
 import Network.Transport.TCP (createTransport, defaultTCPParameters)
+import Network.Socket.Internal (withSocketsDo)
 import System.Environment
 import Control.Monad
 import Data.ByteString.Char8
 
 main :: IO ()
-main = do
+main = withSocketsDo $ do
   [host, port, serverAddr] <- getArgs
   Right transport <- createTransport host port defaultTCPParameters
   Right endpoint  <- newEndPoint transport
diff --git a/static/tutorial/tutorial-server.hs b/static/tutorial/tutorial-server.hs
index 1b7e065..68e318d 100644
--- a/static/tutorial/tutorial-server.hs
+++ b/static/tutorial/tutorial-server.hs
@@ -1,5 +1,6 @@
 import Network.Transport
 import Network.Transport.TCP (createTransport, defaultTCPParameters)
+import Network.Socket.Internal (withSocketsDo)
 import Control.Concurrent
 import Data.Map
 import Control.Exception
@@ -44,7 +45,7 @@ p `onCtrlC` q = catchJust isUserInterrupt p (const $ q >> p `onCtrlC` q)
     isUserInterrupt _             = Nothing
 
 main :: IO ()
-main = do
+main = withSocketsDo $ do
   [host, port]    <- getArgs
   serverDone      <- newEmptyMVar
   Right transport <- createTransport host port defaultTCPParameters
diff --git a/team.md b/team.md
index c16b71d..924776e 100644
--- a/team.md
+++ b/team.md
@@ -27,9 +27,15 @@ of Cloud Haskell as a whole. [Edsko De Vries][13], a member of Well-Typed and th
 author of much of the new implementation we have today, is still closely involved
 as well.
 
-[Tim][6] is the primary author and maintainer of [disributed-process-platform][8];
-an effort to port many of the benefits of Erlang's [Open Telecom Platform][10] to
-the Cloud Haskell ecosystem.
+Most of the packages are maintained by the haskell-distributed
+organization, with people from Well Typed, Tweag, and other companies
+that are involved.
+
+The core [disributed-process][8] library is maintained by
+[Facundo Domínguez][14], and the platform libaries are maintained by
+[Tim Watson][6].
+
+Some libraries are maintained my third parties, most notably d-p-p2p.
 
 [Jeff][7] is the author of [distributed-process-global][11], a re-implementation of
 Erlang's [global][12] (locking, registration and cluster management) API for
@@ -48,9 +54,10 @@ Duncan Coutts, Simon Marlow, Ryan Newton, Eric Kow, Adam Foltzer, Nicolas Wu
 [5]: http://www.haskell.org/haskellwiki/Parallel_GHC_Project
 [6]: https://github.com/hyperthunk
 [7]: https://github.com/jepst
-[8]: https://github.com/haskell-distributed/disributed-process-platform
+[8]: https://github.com/haskell-distributed/disributed-process
 [9]: http://hackage.haskell.org/trac/ghc/wiki/Contributors
 [10]: http://en.wikipedia.org/wiki/Open_Telecom_Platform
 [11]: https://github.com/jepst/distributed-process-global
 [12]: http://www.erlang.org/doc/man/global.html
 [13]: https://github.com/edsko
+[14]: https://github.com/facundominguez
diff --git a/tutorials/1ch.md b/tutorials/1ch.md
index edb2ac4..4eb07d2 100644
--- a/tutorials/1ch.md
+++ b/tutorials/1ch.md
@@ -1,7 +1,7 @@
 ---
 layout: tutorial
 categories: tutorial
-sections: ['Getting Started', 'Installing from source', 'Creating a node', 'Sending messages', 'Spawning Remote Processes']
+sections: ['Getting Started', 'Creating a node', 'Sending messages', 'Spawning Remote Processes']
 title: 1. Getting Started
 ---
 
@@ -9,23 +9,32 @@ title: 1. Getting Started
 
 -----
 
-In order to go through this tutorial, you will need a Haskell development
-environment and we recommend installing the latest version of the
-[Haskell Platform](http://www.haskell.org/platform/) if you've not done
-so already.
+In order to go through this tutorial, you will need a working Haskell
+environment. If you don't already have one follow the instructions
+[here](https://www.haskell.org/downloads) to install the compiler and
+then
+[go here](https://github.com/commercialhaskell/stack/wiki/Downloads)
+to install `stack`, a popular build tool for Haskell projects.
 
-Once you're up and running, you'll want to get hold of the distributed-process
-library and a choice of network transport backend. This guide will use
-the network-transport-tcp backend, but other backends may be available
-on github.
+Once you're up and running, you'll want to get hold of the
+`distributed-process` library and a choice of network transport
+backend. This guide will use the `network-transport-tcp` backend, but
+other backends are available on [Hackage](https://hackage.haskell.org)
+and [GitHub](https://github.com).
 
-### Installing from source
+### Setting up the project
 
-If you're installing from source, the simplest method is to checkout the
-[Umbrella Project](https://github.com/haskell-distributed/cloud-haskell) and
-run `make` to obtain the complete set of source repositories for building
-Cloud Haskell. The additional makefiles bundled with the umbrella assume
-that you have a recent version of cabal (with support for sandboxes) installed.
+Starting a new Cloud Haskell project using `stack` is as easy as
+
+{% highlight bash %}
+$ stack new
+{% endhighlight %}
+
+in a fresh new directory. This will populate the directory with
+a number of files, chiefly `stack.yaml` and `*.cabal` metadata files
+for the project. You'll want to add `distributed-process` and
+`network-transport-tcp` to the `build-depends` stanza of the
+executable section.
 
 ### Creating a node
 
@@ -37,7 +46,7 @@ from other nodes. We will look at inter-node communication later, for now
 it will suffice to pass the default remote table, which defines the built-in
 types that Cloud Haskell needs at a minimum in order to run.
 
-We start with our imports:
+In `app/Main.hs`, we start with our imports:
 
 {% highlight haskell %}
 import Network.Transport.TCP (createTransport, defaultTCPParameters)
@@ -60,15 +69,15 @@ And now we have a running node.
 
 ### Sending messages
 
-We start a new process by evaluating `forkProcess`, which takes a node,
-a `Process` action - because our concurrent code will run in the `Process`
-monad - and returns an address for the process in the form of a `ProcessId`.
-The process id can be used to send messages to the running process - here we
-will send one to ourselves!
+We start a new process by evaluating `runProcess`, which takes a node and
+a `Process` action to run, because our concurrent code will run in the
+`Process` monad. Each process has an identifier associated to it. The process
+id can be used to send messages to the running process - here we will send one
+to ourselves!
 
 {% highlight haskell %}
 -- in main
-  _ <- forkProcess node $ do
+  _ <- runProcess node $ do
     -- get our own process id
     self <- getSelfPid
     send self "hello"
@@ -77,20 +86,19 @@ will send one to ourselves!
   return ()
 {% endhighlight %}
 
-Lightweight processes are implemented as `forkIO` threads. In general we will
-try to forget about this implementation detail, but let's note that we
-haven't deadlocked our own thread by sending to and receiving from its mailbox
-in this fashion. Sending messages is a completely asynchronous operation - even
-if the recipient doesn't exist, no error will be raised and evaluating `send`
-will not block the caller, even if the caller is sending messages to itself!
+Note that we haven't deadlocked our own thread by sending to and receiving
+from its mailbox in this fashion. Sending messages is a completely
+asynchronous operation - even if the recipient doesn't exist, no error will be
+raised and evaluating `send` will not block the caller, even if the caller is
+sending messages to itself.
 
-Receiving works the opposite way, blocking the caller until a message
-matching the expected type arrives in our (conceptual) mailbox. If multiple
-messages of that type are present in the mailbox, they're be returned in FIFO
-order, if not, the caller is blocked until a message arrives that can be
-decoded to the correct type.
+Each process also has a *mailbox* associated with it. Messages sent to
+a process are queued in this mailbox. A process can pop a message out of its
+mailbox using `expect` or the `receive*` family of functions. If no message of
+the expected type is in the mailbox currently, the process will block until
+there is. Messages in the mailbox are ordered by time of arrival.
 
-Let's spawn two processes on the same node and have them talk to each other.
+Let's spawn two processes on the same node and have them talk to each other:
 
 {% highlight haskell %}
 import Control.Concurrent (threadDelay)
@@ -109,8 +117,8 @@ main :: IO ()
 main = do
   Right t <- createTransport "127.0.0.1" "10501" defaultTCPParameters
   node <- newLocalNode t initRemoteTable
-  forkProcess node $ do
-    -- Spawn another worker on the local node 
+  runProcess node $ do
+    -- Spawn another worker on the local node
     echoPid <- spawnLocal $ forever $ do
       -- Test our matches in order against each message in the queue
       receiveWait [match logMessage, match replyBack]
@@ -129,97 +137,161 @@ main = do
     case m of
       -- Die immediately - throws a ProcessExitException with the given reason.
       Nothing  -> die "nothing came back!"
-      (Just s) -> say $ "got " ++ s ++ " back!"
-    return ()
+      Just s -> say $ "got " ++ s ++ " back!"
 
-  -- A 1 second wait. Otherwise the main thread can terminate before
-  -- our messages reach the logging process or get flushed to stdio
-  liftIO $ threadDelay (1*1000000)
-  return ()
+    -- Without the following delay, the process sometimes exits before the messages are exchanged.
+    liftIO $ threadDelay 2000000
 {% endhighlight %}
 
-Note that we've used the `receive` class of functions this time around.
-These can be used with the [`Match`][5] data type to provide a range of
-advanced message processing capabilities. The `match` primitive allows you
-to construct a "potential message handler" and have it evaluated
-against received (or incoming) messages. As with `expect`, if the mailbox does
-not contain a message that can be matched, the evaluating process will be
-blocked until a message arrives which _can_ be matched.
+Note that we've used `receiveWait` this time around to get a message.
+`receiveWait` and similarly named functions can be used with the
+[`Match` data type][5] to provide a range of advanced message
+processing capabilities. The `match` primitive allows you to construct
+a "potential message handler" and have it evaluated against received
+(or incoming) messages. Think of a list of `Match`es as the
+distributed equivalent of a pattern match. As with `expect`, if the
+mailbox does not contain a message that can be matched, the evaluating
+process will be blocked until a message arrives which _can_ be
+matched.
 
 In the _echo server_ above, our first match prints out whatever string it
-receives. If first message in out mailbox is not a `String`, then our second
-match is evaluated. This, given a tuple `t :: (ProcessId, String)`, will send
-the `String` component back to the sender's `ProcessId`. If neither match
-succeeds, the echo server blocks until another message arrives and
-tries again.
+receives. If the first message in our mailbox is not a `String`, then our
+second match is evaluated. Thus, given a tuple `t :: (ProcessId, String)`, it
+will send the `String` component back to the sender's `ProcessId`. If neither
+match succeeds, the echo server blocks until another message arrives and tries
+again.
 
 ### Serializable Data
 
-Processes may send any datum whose type implements the `Serializable` typeclass,
-which is done indirectly by deriving `Binary` and `Typeable`. Implementations are 
-provided for most of Cloud Haskell's primitives and various common data types.
+Processes may send any datum whose type implements the `Serializable`
+typeclass, defined as:
 
-### Spawning Remote Processes
+{% highlight haskell %}
+class (Binary a, Typeable) => Serializable a
+instance (Binary a, Typeable a) => Serializable a
+{% endhighlight %}
 
-In order to spawn processes on a remote node without additional compiler
-infrastructure, we make use of "static values": values that are known at
-compile time. Closures in functional programming arise when we partially
-apply a function. In Cloud Haskell, a closure is a code pointer, together
-with requisite runtime data structures representing the value of any free
-variables of the function. A remote spawn therefore, takes a closure around
-an action running in the `Process` monad: `Closure (Process ())`.
+That is, any type that is `Binary` and `Typeable` is `Serializable`. This is
+the case for most of Cloud Haskell's primitive types as well as many standard
+data types. For custom data types, the `Typeable` instance is always
+given by the compiler, and the `Binary` instance can be auto-generated
+too in most cases, e.g.:
+
+{% highlight haskell %}
+{-# LANGUAGE DeriveDataTypeable #-}
+{-# LANGUAGE DeriveGeneric #-}
+
+data T = T Int Char deriving (Generic, Typeable)
+
+instance Binary T
+{% endhighlight %}
 
-In distributed-process if `f : T1 -> T2` then
+
+### Spawning Remote Processes
+
+We saw above that the behaviour of processes is determined by an action in the
+`Process` monad. However, actions in the `Process` monad, no more serializable
+than actions in the `IO` monad. If we can't serialize actions, then how can we
+spawn processes on remote nodes?
+
+The solution is to consider only *static* actions and compositions thereof.
+A static action is always defined using a closed expression (intuitively, an
+expression that could in principle be evaluated at compile-time since it does
+not depend on any runtime arguments). The type of static actions in Cloud
+Haskell is `Closure (Process a)`. More generally, a value of type `Closure b`
+is a value that was constructed explicitly as the composition of symbolic
+pointers and serializable values. Values of type `Closure b` are serializable,
+even if values of type `b` might not be. For instance, while we can't in general
+send actions of type `Process ()`, we can construct a value of type `Closure
+(Process ())` instead, containing a symbolic name for the action, and send
+that instead. So long as the remote end understands the same meaning for the
+symbolic name, this works just as well. A remote spawn then, takes a static
+action and sends that across the wire to the remote node.
+
+Static actions are not easy to construct by hand, but fortunately Cloud
+Haskell provides a little bit of Template Haskell to help. If `f :: T1 -> T2`
+then
 
 {% highlight haskell %}
   $(mkClosure 'f) :: T1 -> Closure T2
 {% endhighlight %}
 
-That is, the first argument to the function we pass to mkClosure will act
-as the closure environment for that process. If you want multiple values
-in the closure environment, you must "tuple them up".
+You can turn any top-level unary function into a `Closure` using `mkClosure`.
+For curried functions, you'll need to uncurry them first (i.e. "tuple up" the
+arguments). However, to ensure that the remote side can adequately interpret
+the resulting `Closure`, you'll need to add a mapping in a so-called *remote
+table* associating the symbolic name of a function to its value. Processes can
+only be successfully spawned on remote nodes if all these remote nodes have
+the same remote table as the local one.
 
-We need to configure our remote table (see the documentation for more details)
-and the easiest way to do this, is to let the library generate the relevant
-code for us. For example (taken from the distributed-process-platform test suites):
+We need to configure our remote table (see the [API reference][6] for
+more details) and the easiest way to do this, is to let the library
+generate the relevant code for us. For example:
 
 {% highlight haskell %}
-sampleTask :: (TimeInterval, String) -> Process String
-sampleTask (t, s) = sleep t >> return s
+sampleTask :: (TimeInterval, String) -> Process ()
+sampleTask (t, s) = sleep t >> say s
 
-$(remotable ['sampleTask])
+remotable ['sampleTask]
 {% endhighlight %}
 
-We can now create a closure environment for `sampleTask` like so:
+The last line is a top-level Template Haskell splice. At the call site for
+`spawn`, we can construct a `Closure` corresponding to an application of
+`sampleTask` like so:
 
 {% highlight haskell %}
 ($(mkClosure 'sampleTask) (seconds 2, "foobar"))
 {% endhighlight %}
 
-The call to `remotable` generates a remote table and a definition
-`__remoteTable :: RemoteTable -> RemoteTable` in our module for us.
-We compose this with other remote tables in order to come up with a
-final, merged remote table for use in our program:
+The call to `remotable` implicitly generates a remote table by inserting
+a top-level definition `__remoteTable :: RemoteTable -> RemoteTable` in our
+module for us. We compose this with other remote tables in order to come up
+with a final, merged remote table for all modules in our program:
 
 {% highlight haskell %}
+{-# LANGUAGE TemplateHaskell #-}
+
+import Control.Concurrent (threadDelay)
+import Control.Monad (forever)
+import Control.Distributed.Process
+import Control.Distributed.Process.Closure
+import Control.Distributed.Process.Node
+import Network.Transport.TCP (createTransport, defaultTCPParameters)
+
+sampleTask :: (Int, String) -> Process ()
+sampleTask (t, s) = liftIO (threadDelay (t * 1000000)) >> say s
+
+remotable ['sampleTask]
+
 myRemoteTable :: RemoteTable
 myRemoteTable = Main.__remoteTable initRemoteTable
 
 main :: IO ()
 main = do
- localNode <- newLocalNode transport myRemoteTable
- -- etc
+  Right transport <- createTransport "127.0.0.1" "10501" defaultTCPParameters
+  node <- newLocalNode transport myRemoteTable
+  runProcess node $ do
+    us <- getSelfNode
+    _ <- spawnLocal $ sampleTask (1 :: Int, "using spawnLocal")
+    pid <- spawn us $ $(mkClosure 'sampleTask) (1 :: Int, "using spawn")
+    liftIO $ threadDelay 2000000
 {% endhighlight %}
 
-Note that we're not limited to sending `Closure`s - it is possible to send data
-without having static values, and assuming the receiving code is able to decode
-this data and operate on it, we can easily put together a simple AST that maps
-to operations we wish to execute remotely.
+In the above example, we spawn `sampleTask` on node `us` in two
+different ways:
+
+* using `spawn`, which expects some node identifier to spawn a process
+  on along with a `Closure` for the action of the process.
+* using `spawnLocal`, a specialization of `spawn` for the case when the
+  node identifier actually refers to the local node (i.e. `us`). In
+  this special case, no serialization is necessary, so passing an
+  action directly rather than a `Closure` works just fine.
 
 ------
 
-[1]: /static/doc/distributed-process/Control-Distributed-Process.html#v:Message
-[2]: http://hackage.haskell.org/package/distributed-process
-[3]: /static/doc/distributed-process-platform/Control-Distributed-Process-Platform-Async.html
-[4]: /static/doc/distributed-process-platform/Control-Distributed-Process-Platform-ManagedProcess.htmlv:callAsync
-[5]: http://hackage.haskell.org/packages/archive/distributed-process/latest/doc/html/Control-Distributed-Process-Internal-Primitives.html#t:Match
+[1]: https://hackage.haskell.org/package/distributed-process-0.6.6/docs/Control-Distributed-Process.html#t:Message
+[2]: https://hackage.haskell.org/package/distributed-process
+[3]: https://hackage.haskell.org/package/distributed-process-async/docs/Control-Distributed-Process-Async.html
+[4]: https://hackage.haskell.org/package/distributed-process-client-server-0.1.3.2/docs/Control-Distributed-Process-ManagedProcess-Client.html#v:callAsync
+[5]: https://hackage.haskell.org/packages/archive/distributed-process/latest/doc/html/Control-Distributed-Process-Internal-Primitives.html#t:Match
+[6]: https://hackage.haskell.org/packages/archive/distributed-process/latest/doc/html/Control-Distributed-Process-Closure.html
diff --git a/tutorials/2ch.md b/tutorials/2ch.md
index c16d302..280eb12 100644
--- a/tutorials/2ch.md
+++ b/tutorials/2ch.md
@@ -1,7 +1,7 @@
 ---
 layout: tutorial
 categories: tutorial
-sections: ['Overview', 'A Simple Example', 'Master Slave Configurations', 'Other Topologies and Backends']
+sections: ['Overview', 'A Simple Example', 'Controller Worker Configurations', 'Other Topologies and Backends']
 title: 2. Managing Topologies
 ---
 
@@ -10,7 +10,7 @@ title: 2. Managing Topologies
 In Cloud Haskell, the system topology is determined by your choice of _Cloud Haskell Backend_.
 The basic topology that Cloud Haskell currently ships with is determined by the
 [`simplelocalnet`][1] backend, which provides for a fully connected grid of nodes with optional
-master-slave configuration. This backend allows nodes to discover one another using UDP multicast.
+controller-worker configuration. This backend allows nodes to discover one another using UDP multicast.
 It is a zero-configuration backend designed to get you going with Cloud Haskell quickly without
 imposing any particular structure on your application.
 
@@ -26,17 +26,17 @@ searches for a list of peer nodes, and sends a message to a registered (named) p
 {% highlight haskell %}
 import System.Environment (getArgs)
 import Control.Distributed.Process
-import Control.Distributed.Process.Node (initRemoteTable)
+import Control.Distributed.Process.Node (initRemoteTable, runProcess)
 import Control.Distributed.Process.Backend.SimpleLocalnet
-import Control.Monad (forever, mapM_)
+import Control.Monad (forever, forM_)
 
 main = do
   [host, port] <- getArgs
   
   backend <- initializeBackend host port initRemoteTable
   node    <- newLocalNode backend
-  runProcess node $ forever $ do
-    findPeers backend >>= mapM_ $ \peer -> nsendRemote peer "echo-server" "hello!"
+  peers   <- findPeers backend 1000000
+  runProcess node $ forM_ peers $ \peer -> nsendRemote peer "echo-server" "hello!"
 
 {% endhighlight %}
 
@@ -46,11 +46,11 @@ connected to an underlying communications infrastructure and secondly, that we c
 evaluate `findPeers` at any time to obtain the set of other nodes that have broadcast
 their presence.
 
-### Master Slave Configurations
+### Controller Worker Configurations
 
-Here we simply rehash the master/slave example from the `simplelocalnet` documentation.
-With the same imports as the example above, we add a no-op slave and a master that
-takes a list of its (known) slaves, which it prints out before terminating them all.
+Here we simply rehash the controller/worker example from the `simplelocalnet` documentation.
+With the same imports as the example above, we add a no-op worker and a controller that
+takes a list of its (known) workers, which it prints out before terminating them all.
 
 {% highlight haskell %}
 main :: IO ()
@@ -58,23 +58,23 @@ main = do
   args <- getArgs
 
   case args of
-    ["master", host, port] -> do
+    ["controller", host, port] -> do
       backend <- initializeBackend host port initRemoteTable
-      startMaster backend (master backend)
-    ["slave", host, port] -> do
+      startMaster backend (controller backend)
+    ["worker", host, port] -> do
       backend <- initializeBackend host port initRemoteTable
       startSlave backend
 
 {% endhighlight %}
 
-And the master node is defined thus:
+And the controller node is defined thus:
 
 {% highlight haskell %}
-master :: Backend -> [NodeId] -> Process ()
-master backend slaves = do
-  -- Do something interesting with the slaves
-  liftIO . putStrLn $ "Slaves: " ++ show slaves
-  -- Terminate the slaves when the master terminates (this is optional)
+controller :: Backend -> [NodeId] -> Process ()
+controller backend workers = do
+  -- Do something interesting with the workers
+  liftIO . putStrLn $ "Workers: " ++ show workers
+  -- Terminate the workers when the controller terminates (this is optional)
   terminateAllSlaves backend
 {% endhighlight %}
 
diff --git a/tutorials/3ch.md b/tutorials/3ch.md
index f40f017..175dda6 100644
--- a/tutorials/3ch.md
+++ b/tutorials/3ch.md
@@ -1,7 +1,7 @@
 ---
 layout: tutorial
 categories: tutorial
-sections: ['Message Ordering', 'Selective Receive', 'Advanced Mailbox Processing', 'Typed Channels', 'Process Lifetime', 'Monitoring And Linking', 'Getting Process Info']
+sections: ['Message Ordering', 'Selective Receive', 'Advanced Mailbox Processing', 'Typed Channels', 'Process Lifetime', 'Monitoring And Linking', 'Getting Process Info','Monad Transformer Stacks' ]
 title: 3. Getting to know Processes
 ---
 
@@ -59,12 +59,15 @@ demo = do
     send listener "hello"
     getSelfPid >>= send listener
     () <- expect
+    return ()
   where
     listen = do
       third <- expect :: Process ProcessId
       first <- expect :: Process String
-      second <- expectTimeout 100000 :: Process String
-      mapM_ (say . show) [first, second, third]
+      second <- expectTimeout 100000 :: Process (Maybe String)
+      (say . show) first
+      (say . show) second
+      (say . show) third
       send third ()
 {% endhighlight %}
 
@@ -177,9 +180,9 @@ proxy :: Serializable a => ProcessId -> (a -> Process Bool) -> Process ()
 {% endhighlight %}
 
 Since `matchAny` operates on `(Message -> Process b)` and `handleMessage` operates on
-`a -> Process b` we can compose these to make our proxy server. We must not forward 
+`a -> Process b` we can compose these to make our proxy server. We must not forward
 messages for which the predicate function evaluates to `Just False`, nor can we sensibly
-forward messages which the predicate function is unable to evaluate due to type 
+forward messages which the predicate function is unable to evaluate due to type
 incompatibility. This leaves us with the definition found in distributed-process:
 
 {% highlight haskell %}
@@ -197,7 +200,7 @@ proxy pid proc = do
 
 Beyond simple relays and proxies, the raw message handling capabilities available in
 distributed-process can be utilised to develop highly generic message processing code.
-All the richness of the distributed-process-platform APIs (such as `ManagedProcess`) which
+All the richness of the distributed-process-client-server APIs (such as `ManagedProcess`) which
 will be discussed in later tutorials are, in fact, built upon these families of primitives.
 
 ### Typed Channels
@@ -234,10 +237,10 @@ is terminated.
 
 The `ProcessExitException` signal is sent from one process to another, indicating that the
 receiver is being asked to terminate. A process can choose to tell itself to exit, and the
-[`die`][7] primitive simplifies doing so without worrying about the expected type for the 
+[`die`][7] primitive simplifies doing so without worrying about the expected type for the
 action. In fact, [`die`][7] has slightly different semantics from [`exit`][5], since the
 latter involves sending an internal signal to the local node controller. A direct consequence
-of this is that the _exit signal_ may not arrive immediately, since the _Node Controller_ could 
+of this is that the _exit signal_ may not arrive immediately, since the _Node Controller_ could
 be busy processing other events. On the other hand, the [`die`][7] primitive throws a
 `ProcessExitException` directly in the calling thread, thus terminating it without delay.
 In practise, this means the following two functions could behave quite differently at
@@ -247,19 +250,19 @@ runtime:
 
 -- this will never print anything...
 demo1 = die "Boom" >> expect >>= say
-  
+
 -- this /might/ print something before it exits
 demo2 = do
   self <- getSelfPid
   exit self "Boom"
-  expect >>= say 
+  expect >>= say
 {% endhighlight %}
 
 The `ProcessExitException` type holds a _reason_ field, which is serialised as a raw `Message`.
 This exception type is exported, so it is possible to catch these _exit signals_ and decide how
 to respond to them. Catching _exit signals_ is done via a set of primitives in
 distributed-process, and the use of them forms a key component of the various fault tolerance
-strategies provided by distributed-process-platform.
+strategies provided by distributed-process-supervisor.
 
 A `ProcessKillException` is intended to be an _untrappable_ exit signal, so its type is
 not exported and therefore you can __only__ handle it by catching all exceptions, which
@@ -282,10 +285,11 @@ of exit reasons.
 
 {% highlight haskell %}
 demo = do
-  pid <- spawnLocal $ receive >>= return
+  pid <- spawnLocal $ expect >>= return
   link pid
   send pid ()
-  () <- receive
+  () <- expect
+  return ()
 {% endhighlight %}
 
 The medium that link failures uses to signal exit conditions is the same as exit and kill
@@ -296,7 +300,7 @@ special case. Since link exit signals cannot be caught directly, if you find you
 to _trap_ a link failure, you probably want to use a monitor instead.
 
 Whilst the built-in `link` primitive terminates the link-ee regardless of exit reason,
-distributed-process-platform provides an alternate function `linkOnFailure`, which only
+distributed-process-extras provides an alternate function `linkOnFailure`, which only
 dispatches the `ProcessLinkException` if the link-ed process dies abnormally (i.e., with
 some `DiedReason` other than `DiedNormal`).
 
@@ -305,7 +309,7 @@ putting a `ProcessMonitorNotification` into the process' mailbox. This signal an
 constituent fields can be introspected in order to decide what action (if any) the receiver
 can/should take in response to the monitored process' death. Let's take a look at how
 monitors can be used to determine both when and _how_ a process has terminated. Tucked
-away in distributed-process-platform, the `linkOnFailure` primitive works in exactly this
+away in distributed-process-extras, the `linkOnFailure` primitive works in exactly this
 way, only terminating the caller if the subject terminates abnormally. Let's take a look...
 
 {% highlight haskell %}
@@ -366,6 +370,173 @@ process. The `ProcessInfo` type it returns contains the local node id and a list
 registered names, monitors and links for the process. The call returns `Nothing` if the
 process in question is not alive.
 
+### Monad Transformer Stacks
+
+It is not generally necessary, but it may be convenient in your application to use a
+custom monad transformer stack with the Process monad at the bottom. For example,
+you may have decided that in various places in your application you will make calls to
+a network database. You may create a data access module, and it will need configuration information available to it in
+order to connect to the database server. A ReaderT can be a nice way to make
+configuration data available throughout an application without
+schlepping it around by hand.
+
+This example is a bit contrived and over-simplified but
+illustrates the concept. Consider the `fetchUser` function below, it runs in the `AppProcess`
+monad which provides the configuration settings required to connect to the database:
+
+{% highlight haskell %}
+
+import Data.ByteString (ByteString)
+import Control.Monad.Reader
+
+-- imagine we have some database library
+import Database.Imaginary as DB
+
+data AppConfig = AppConfig {dbHost :: String, dbUser :: String}
+
+type AppProcess = ReaderT AppConfig Process
+
+data User = User {userEmail :: String}
+
+-- Perform a user lookup using our custom app context
+fetchUser :: String -> AppProcess (Maybe User)
+fetchUser email = do
+  db <- openDB
+  user <- liftIO $ DB.query db email
+  closeDB db
+  return user
+
+openDB :: AppProcess DB.Connection
+openDB = do
+  AppConfig host user <- ask
+  liftIO $ DB.connect host user
+
+closeDB :: DB.Connection -> AppProcess ()
+closeDB db = liftIO (DB.close db)
+
+{% endhighlight %}
+
+So this would mostly work but it is not complete. What happens if an exception
+is thrown by the `query` function? Your open database handle may not be
+closed. Typically we manage this with the [bracket][brkt] function.
+
+In the base library, [bracket][brkt] is defined in Control.Exception with this signature:
+
+{% highlight haskell %}
+
+bracket :: IO a	       --^ computation to run first ("acquire resource")
+        -> (a -> IO b) --^ computation to run last ("release resource")
+        -> (a -> IO c) --^ computation to run in-between
+	-> IO c
+
+{% endhighlight %}
+
+Great! We pass an IO action that acquires a resource; `bracket` passes that
+resource to a function which takes the resource and runs another action.
+We also provide a release function which `bracket` is guaranteed to run
+even if the primary action raises an exception.
+
+
+Unfortunately, we cannot directly use `bracket` in our
+`fetchUser` function: openDB (resource acquisition) runs in the `AppProcess`
+monad. If our functions ran in IO, we could lift the entire bracket computation into
+our monad transformer stack with liftIO; but we cannot do that for the computations
+*passed* to bracket.
+
+It is perfectly possible to write our own bracket; `distributed-process` does this
+for the `Process` monad (which is itself a newtyped ReaderT stack). Here is how that is done:
+
+
+{% highlight haskell %}
+-- | Lift 'Control.Exception.bracket'
+bracket :: Process a -> (a -> Process b) -> (a -> Process c) -> Process c
+bracket before after thing =
+  mask $ \restore -> do
+    a <- before
+    r <- restore (thing a) `onException` after a
+    _ <- after a
+    return r
+
+mask :: ((forall a. Process a -> Process a) -> Process b) -> Process b
+mask p = do
+    lproc <- ask
+    liftIO $ Ex.mask $ \restore ->
+      runLocalProcess lproc (p (liftRestore restore))
+  where
+    liftRestore :: (forall a. IO a -> IO a)
+                -> (forall a. Process a -> Process a)
+    liftRestore restoreIO = \p2 -> do
+      ourLocalProc <- ask
+      liftIO $ restoreIO $ runLocalProcess ourLocalProc p2
+
+-- | Lift 'Control.Exception.onException'
+onException :: Process a -> Process b -> Process a
+onException p what = p `catch` \e -> do _ <- what
+                                        liftIO $ throwIO (e :: SomeException)
+{% endhighlight %}
+
+`distributed-process` needs to do this sort of thing to keep its dependency
+list small, but do we really want to write this for every transformer stack
+we use in our own applications? No! And we do not have to, thanks to
+the [monad-control][mctrl] and [lifted-base][lbase] libraries.
+
+[monad-control][mctrl] provides several typeclasses and helper functions
+that make it possible to fully generalize the wrapping/unwrapping required
+to keep transformer effects stashed away while actions run in the base monad. Of
+most concern to end users of this library are the typeclass [MonadBase][mb] and [MonadBaseControl][mbc].
+How it works is beyond the scope of this tutorial, but there is an excellent and thorough
+explanation written by Michael Snoyman which is available [here][mctrlt].
+
+[lifted-base][lbase] takes advantage of these typeclasses to provide lifted versions of many functions
+in the Haskell base library. For example, [Control.Exception.Lifted][lexc] has a definition of
+bracket that looks like this:
+
+{% highlight haskell %}
+
+bracket :: MonadBaseControl IO m
+        => m a	       --^ computation to run first ("acquire resource")
+        -> (a -> m b)  --^ computation to run last ("release resource")
+        -> (a -> m c)  --^ computation to run in-between
+        -> m c
+
+{% endhighlight %}
+
+It is just the same as the version found in base, except it is generalized to work
+with actions in any monad that implements [MonadBaseControl IO][mbc]. [monad-control][mctrl] defines
+instances for the standard transformers, but that instance requires the base monad
+(in this case, `Process`) to also have an instance of these classes.
+
+To address this the [distributed-process-monad-control][dpmc] package
+provides orphan instances of the `Process` type for both [MonadBase IO][mb] and [MonadBaseControl IO][mbc].
+After importing these, we can rewrite our `fetchUser` function to use the instance of bracket
+provided by [lifted-base][lbase].
+
+{% highlight haskell %}
+
+-- ...
+import Control.Distributed.Process.MonadBaseControl ()
+import Control.Exception.Lifted as Lifted
+
+-- ...
+
+fetchUser :: String -> AppProcess (Maybe User)
+fetchUser email =
+  Lifted.bracket openDB
+                 closeDB
+          	 $ \db -> liftIO $ DB.query db email
+
+
+{% endhighlight %}
+
+[lifted-base][lbase] also provides conveniences like [MVar][lmvar] and other concurrency primitives that
+operate in [MonadBase IO][mb]. One benefit here is that your code is not sprinkled with
+liftIO; but [MonadBaseControl IO][mbc] also makes things like a lifted [withMVar][lmvar-with] possible - which is
+really just a specialization of [bracket][lbrkt]. You will also find lots of other libraries on hackage which
+use these instances - at present count there are more than 150 [packages using it][reverse].
+
+One note of caution: This instance can enable use of functions such as `forkIO` (or, `fork` from [lifted-base][lbase]) which compromise invariants in the `Process` monad and can lead to confusing and subtle issues. Always use the Cloud Haskell functions such as spawnLocal instead.
+
+
 [1]: hackage.haskell.org/package/distributed-process/docs/Control-Distributed-Process.html#v:receiveWait
 [2]: hackage.haskell.org/package/distributed-process/docs/Control-Distributed-Process.html#v:expect
 [3]: http://hackage.haskell.org/package/distributed-process-0.4.2/docs/Control-Distributed-Process.html#v:match
@@ -373,3 +544,15 @@ process in question is not alive.
 [5]: http://hackage.haskell.org/package/distributed-process-0.4.2/docs/Control-Distributed-Process.html#v:exit
 [6]: http://hackage.haskell.org/package/distributed-process-0.4.2/docs/Control-Distributed-Process.html#v:kill
 [7]: http://hackage.haskell.org/package/distributed-process-0.4.2/docs/Control-Distributed-Process.html#v:die
+[brkt]: http://hackage.haskell.org/package/base-4.6.0.1/docs/Control-Exception.html#v:bracket
+[mctrl]: http://hackage.haskell.org/package/monad-control
+[mb]: http://hackage.haskell.org/package/transformers-base-0.4.2/docs/Control-Monad-Base.html#t:MonadBase
+[mbc]: http://hackage.haskell.org/package/monad-control-0.3.3.0/docs/Control-Monad-Trans-Control.html#t:MonadBaseControl
+[lmvar]: http://hackage.haskell.org/package/lifted-base-0.2.2.2/docs/Control-Concurrent-MVar-Lifted.html#t:MVar
+[lmvar-with]: http://hackage.haskell.org/package/lifted-base-0.2.2.2/docs/Control-Concurrent-MVar-Lifted.html#v:withMVar
+[lbrkt]: http://hackage.haskell.org/package/lifted-base-0.2.2.2/docs/Control-Exception-Lifted.html#v:bracket
+[lbase]: http://hackage.haskell.org/package/lifted-base
+[dpmc]: http://hackage.haskell.org/package/distributed-process-monad-control
+[mctrlt]: http://www.yesodweb.com/book/monad-control
+[reverse]: http://packdeps.haskellers.com/reverse/monad-control
+[lexc]: http://hackage.haskell.org/package/lifted-base-0.2.2.2/docs/Control-Exception-Lifted.html
diff --git a/tutorials/4ch.md b/tutorials/4ch.md
index 83dc0ef..fddc1d4 100644
--- a/tutorials/4ch.md
+++ b/tutorials/4ch.md
@@ -8,9 +8,9 @@ title: 4. Managed Process Tutorial
 ### Introduction
 
 The source code for this tutorial is based on the `BlockingQueue` API
-from distributed-process-platform and can be accessed [here][1].
+from distributed-process-task and can be accessed [here][1].
 Please note that this tutorial is based on the stable (master) branch
-of [distributed-process-platform][3].
+of [distributed-process-task][3].
 
 ### Managed Processes
 
@@ -40,8 +40,8 @@ code to be run on termination/shutdown.
 
 {% highlight haskell %}
 myServer :: ProcessDefinition MyStateType
-myServer = 
-  ProcessDefinition { 
+myServer =
+  ProcessDefinition {
       -- handle messages sent to us via the call/cast API functions
       apiHandlers = [
         -- a list of Dispatchers, derived by calling on of the various
@@ -113,13 +113,15 @@ that math server that does just that:
 ----
 
 {% highlight haskell %}
-module MathServer 
+module MathServer
   ( -- client facing API
     add
     -- starting/spawning the server process
   , launchMathServer
   ) where
 
+import Control.Distributed.Process.ManagedProcess -- from the package `distributed-process-client-server`
+import Control.Distributed.Process.Extras.Time -- from the package `distributed-process-extras`
 import .... -- elided
 
 -- We keep this data-type hidden from the outside world, and we ignore
@@ -148,7 +150,7 @@ launchMathServer =
       apiHandlers = [ handleCall_ (\(Add x y) -> return (x + y)) ]
     , unhandledMessagePolicy = Drop
     }
-  in spawnLocal $ start () (statelessInit Infinity) server >> return ()
+  in spawnLocal $ serve () (statelessInit Infinity) server >> return ()
 {% endhighlight %}
 
 
@@ -191,7 +193,7 @@ launchMathServer =
       apiHandlers = [ handleRpcChan_ (\chan (Add x y) -> sendChan chan (x + y)) ]
     , unhandledMessagePolicy = Drop
     }
-  in spawnLocal $ start () (statelessInit Infinity) server >> return ()
+  in spawnLocal $ serve () (statelessInit Infinity) server >> return ()
 {% endhighlight %}
 
 Ensuring that only valid types are sent to the server is relatively simple,
@@ -230,7 +232,7 @@ launchMathServer =
                     , handleCast_ (\(Add x y) -> liftIO $ putStrLn $ show (x + y) >> continue_) ]
     , unhandledMessagePolicy = Drop
     }
-  in spawnLocal $ start () (statelessInit Infinity) server >> return ()
+  in spawnLocal $ serve () (statelessInit Infinity) server >> return ()
 {% endhighlight %}
 
 
@@ -241,9 +243,9 @@ more interesting and useful.
 ### Building a Task Queue
 
 This section of the tutorial is based on a real module from the
-distributed-process-platform library, called `BlockingQueue`.
+distributed-process-task library, called `BlockingQueue`.
 
-Let's imagine we want to execute tasks on an arbitrary node, but want 
+Let's imagine we want to execute tasks on an arbitrary node, but want
 the caller to block whilst the remote task is executing. We also want
 to put an upper bound on the number of concurrent tasks/callers that
 the server will accept. Let's use `ManagedProcess` to implement a generic
@@ -275,7 +277,7 @@ typeclass to allow clients to specify the server's location in whatever
 manner suits them: The type of a task will be `Closure (Process a)` and
 the server will explicitly return an /either/ value with `Left String`
 for errors and `Right a` for successful results.
- 
+
 {% highlight haskell %}
 -- enqueues the task in the pool and blocks
 -- the caller until the task is complete
@@ -342,7 +344,7 @@ data BlockingQueue a = BlockingQueue
 ### Making use of Async
 
 So **how** can we execute this `Closure (Process a)` without blocking the server
-process itself? We can use the `Control.Distributed.Process.Platform.Async` API
+process itself? We can use the `Control.Distributed.Process.Async` API
 to execute each task asynchronously and provide a means for waiting on the result.
 
 In order to use an `Async` handle to get the result of the computation once it's
@@ -351,7 +353,7 @@ submitter with the handle, so we end up with one field for the active (running)
 tasks and another for the queue of accepted (but inactive) ones, as expected.
 
 Since we cannot wait on all these `Async` handles at once whilst we're supposed to
-be accepting new messages from clients - actually, /async/ does provide an API for
+be accepting new messages from clients - actually, [distributed-process-async][6] does provide an API for
 multiplexing on async results, but that's no use here - instead we will monitor the
 async tasks and pull the results when we receive their monitor signals. So for the
 active tasks, we'll need to store a `MonitorRef` and a reference to the original
@@ -663,8 +665,9 @@ another to monitor the first and handle failures and/or cancellation. Spawning
 processes is cheap, but not free as each process is a haskell thread, plus some
 additional book keeping data.
 
-[1]: https://github.com/haskell-distributed/distributed-process-platform/blob/master/src/Control/Distributed/Process/Platform/Task/Queue/BlockingQueue.hs
-[2]: /static/doc/distributed-process-platform/Control-Distributed-Process-Platform-ManagedProcess.html#t:ProcessDefinition
-[3]: https://github.com/haskell-distributed/distributed-process-platform/tree/master/
-[4]: https://github.com/haskell-distributed/distributed-process-platform/tree/master/src/Control/Distributed/Process/Platform/UnsafePrimitives.hs
+[1]: https://github.com/haskell-distributed/distributed-process-task/blob/master/src/Control/Distributed/Process/Task/Queue/BlockingQueue.hs
+[2]: https://hackage.haskell.org/package/distributed-process-client-server-0.1.3.2/docs/Control-Distributed-Process-ManagedProcess.html#t:ProcessDefinition
+[3]: https://github.com/haskell-distributed/distributed-process-task
+[4]: https://github.com/haskell-distributed/distributed-process-extras/blob/master/src/Control/Distributed/Process/Extras/UnsafePrimitives.hs
 [5]: /documentation.html
+[6]: https://hackage.haskell.org/package/distributed-process-async
diff --git a/tutorials/5ch.md b/tutorials/5ch.md
index 1a56c3f..1811c8f 100644
--- a/tutorials/5ch.md
+++ b/tutorials/5ch.md
@@ -56,7 +56,7 @@ triggered the shutdown/terminate sequence for the supervisor's process explicitl
 When a supervisor is told directly to terminate a child process, it uses the
 `ChildTerminationPolicy` to determine whether the child should be terminated
 _gracefully_ or _brutally killed_. This _shutdown protocol_ is used throughout
-[distributed-process-platform][dpp] and in order for a child process to be managed
+[distributed-process-supervisor][dpp] and in order for a child process to be managed
 effectively by its supervisor, it is imperative that it understands the protocol.
 When a _graceful_ shutdown is required, the supervisor will send an exit signal to the
 child process, with the `ExitReason` set to `ExitShutdown`, whence the child process is
@@ -70,7 +70,7 @@ provide a timeout value. The supervisor attempts a _gracefull_ shutdown initiall
 however if the child does not exit within the given time window, the supervisor will
 automatically revert to a _brutal kill_ using `TerminateImmediately`. If the
 timeout value is set to `Infinity`, the supervisor will wait indefintiely for the
-child to exit cleanly. 
+child to exit cleanly.
 
 When a supervisor detects a child exit, it will attempt a restart. Whilst explicitly
 terminating a child will **only** terminate the specified child process, unexpected
@@ -142,11 +142,10 @@ order, otherwise the dependent children might crash whilst we're restarting othe
 rely on. It follows that, in this setup, we cannot subsequently (re)start the children in the
 same order we stopped them either.
 
-[dpp]: https://github.com/haskell-distributed/distributed-process-platform
+[dpp]: https://github.com/haskell-distributed/distributed-process-supervisor
 [sup1]: /img/one-for-one.png
 [sup2]: /img/one-for-all.png
 [sup3]: /img/one-for-all-left-to-right.png
 [alert]: /img/alert.png
 [info]: /img/info.png
 [erlsup]: http://www.erlang.org/doc/man/supervisor.html
-
diff --git a/tutorials/6ch.md b/tutorials/6ch.md
index 1269745..29a32c6 100644
--- a/tutorials/6ch.md
+++ b/tutorials/6ch.md
@@ -56,7 +56,7 @@ look at this in action, revisiting the well-trodden _math server_ example
 from our previous tutorials:
 
 {% highlight haskell %}
-module MathServer 
+module MathServer
   ( -- client facing API
     MathServer()
   , add
@@ -561,20 +561,19 @@ the client using the send ports supplied in the request data.
 > passes data to them (via the `SendPort`) is bound to exactly the same type(s)!
 > Furthermore, adding reply channels (in the form of a `SendPort`) to the request
 > types ensures that the replies will be handled correctly as well! As a result,
-> there can be no ambiguity about the types involved for _either_ side of the 
+> there can be no ambiguity about the types involved for _either_ side of the
 > client-server relationship and therefore no unhandled messages due to runtime
 > type mismatches - the compiler will catch that sort of thing for us!
 ------
 
-[1]: http://hackage.haskell.org/package/distributed-process-platform/Control-Distributed-Process-Platform-Service-Registry.html
-[2]: http://hackage.haskell.org/package/distributed-process-platform/Control-Distributed-Process-Platform-Async.html
-[3]: http://hackage.haskell.org/package/distributed-process-platform/Control-Distributed-Process-Platform-Service-SystemLog.html
-[mgmt]: http://hackage.haskell.org/package/distributed-process/Control-Distributed-Process-Management.html
-[dbg]: http://hackage.haskell.org/package/distributed-process/Control-Distributed-Process-Debug.html
-[rtbl]: http://hackage.haskell.org/package/distributed-proces-platforms/Control-Distributed-Process-Platform.html#t:Routable
-[rsbl]: http://hackage.haskell.org/package/distributed-process-platform/Control-Distributed-Process-Platform.html#t:Resolvable
+[1]: https://hackage.haskell.org/package/distributed-process-registry/docs/Control-Distributed-Process-Registry.html
+[2]: https://hackage.haskell.org/package/distributed-process-async/docs/Control-Distributed-Process-Async.html
+[3]: https://hackage.haskell.org/package/distributed-process-extras/docs/Control-Distributed-Process-Extras-SystemLog.html
+[mgmt]: https://hackage.haskell.org/package/distributed-process/Control-Distributed-Process-Management.html
+[dbg]: https://hackage.haskell.org/package/distributed-process/Control-Distributed-Process-Debug.html
+[rtbl]: https://hackage.haskell.org/package/distributed-process-extras/docs/Control-Distributed-Process-Extras.html#t:Routable
+[rsbl]: https://hackage.haskell.org/package/distributed-process-extras/docs/Control-Distributed-Process-Extras.html#t:Resolvable
 [alert]: /img/alert.png
 [info]: /img/info.png
-[policy]: http://hackage.haskell.org/package/distributed-process-platform/Control-Distributed-Process-Platform-ManagedProcess.html#t:UnhandledMessagePolicy
-[mailbox]: http://hackage.haskell.org/package/distributed-process-platform/Control-Distributed-Process-Platform-Execution-Mailbox.html
-
+[policy]: https://hackage.haskell.org/package/distributed-process-client-server/docs/Control-Distributed-Process-ManagedProcess.html#v:unhandledMessagePolicy
+[mailbox]: https://hackage.haskell.org/package/distributed-process-execution-0.1.2.2/docs/Control-Distributed-Process-Execution-Mailbox.html
diff --git a/tutorials/tutorial-NT2.md b/tutorials/tutorial-NT2.md
index 5ae1ce8..fabcd40 100644
--- a/tutorials/tutorial-NT2.md
+++ b/tutorials/tutorial-NT2.md
@@ -68,17 +68,18 @@ because it is simpler. We first need a bunch of imports:
 
 {% highlight haskell %}
 import Network.Transport
-import Network.Transport.TCP (createTransport)
+import Network.Transport.TCP (createTransport, defaultTCPParameters)
+import Network.Socket.Internal (withSocketsDo)
 import System.Environment
 import Data.ByteString.Char8
 import Control.Monad
 {% endhighlight %}
 
-The client will consist of a single main function.
+The client will consist of a single main function. [withSocketsDo](http://hackage.haskell.org/package/network-2.6.2.1/docs/Network-Socket-Internal.html#v:withSocketsDo) may be needed for Windows platform with old versions of network library. For compatibility with older versions on Windows, it is good practice to always call withSocketsDo (it's very cheap).
 
 {% highlight haskell %}
 main :: IO ()
-main = do
+main = withSocketsDo $ do
 {% endhighlight %}
 
 When we start the client we expect three command line arguments.
@@ -157,14 +158,14 @@ That's it! Here is the entire client again:
 
 {% highlight haskell %}
 main :: IO ()
-main = do
+main = withSocketsDo $ do
   [host, port, serverAddr] <- getArgs
   Right transport <- createTransport host port 
   Right endpoint  <- newEndPoint transport
 
-  let addr = EndPointAddress (fromString serverAddr)
+  let addr = EndPointAddress (pack serverAddr)
   Right conn <- connect endpoint addr ReliableOrdered defaultConnectHints
-  send conn [fromString "Hello world"]
+  send conn [pack "Hello world"]
   close conn
 
   replicateM_ 3 $ receive endpoint >>= print 
@@ -180,7 +181,8 @@ start with a bunch of imports:
 
 {% highlight haskell %}
 import Network.Transport
-import Network.Transport.TCP (createTransport)
+import Network.Transport.TCP (createTransport, defaultTCPParameters)
+import Network.Socket.Internal (withSocketsDo)
 import Control.Concurrent
 import Data.Map
 import Control.Exception
@@ -191,10 +193,10 @@ We will write the main function first:
 
 {% highlight haskell %}
 main :: IO ()
-main = do
+main = withSocketsDo $ do
   [host, port]    <- getArgs
   serverDone      <- newEmptyMVar
-  Right transport <- createTransport host port 
+  Right transport <- createTransport host port defaultTCPParameters
   Right endpoint  <- newEndPoint transport
   forkIO $ echoServer endpoint serverDone 
   putStrLn $ "Echo server started at " ++ show (address endpoint)
diff --git a/wiki/contributing.md b/wiki/contributing.md
index dc005af..6612207 100644
--- a/wiki/contributing.md
+++ b/wiki/contributing.md
@@ -52,11 +52,8 @@ All repositories must use the same git branch structure:
 ### __1. Check to see if your patch is likely to be accepted__
 
 We have a rather full backlog, so your help will be most welcome assisting
-us in clearing that. You can view the exiting open issues on the
-[jira issue tracker](https://cloud-haskell.atlassian.net/issues/?filter=10001).
-
-If you wish to submit a new issue there, you cannot do so without logging in
-creating an account (by providing your email address) and logging in.
+us in clearing that. You can view the exiting open issues on
+[github](https://github.com/haskell-distributed).
 
 It is also helpful to work out which component or sub-system should be
 changed. You may wish to email the maintainers to discuss this first.
diff --git a/wiki/development.md b/wiki/development.md
new file mode 100644
index 0000000..55b1592
--- /dev/null
+++ b/wiki/development.md
@@ -0,0 +1,54 @@
+---
+layout: wiki
+title: Development
+wiki: development
+---
+
+### Development
+
+This section contains topics that are under development and have not
+been formalized and added to formal specification or implemented.
+
+
+#### Registry specification
+
+*Problem: current specification doesn't cover the semantics of registry
+if the remote processes can be put into registry and if we can send 
+messages to such processes using `nsend`.*
+
+Here is a prosal for semantics that is summary of the [email thread](https://groups.google.com/forum/?hl=en-GB#!topic/cloud-haskell-developers/120_WugguPg)
+
+References are the following:
+
+  * Uni  - stands for unified semantics for Future Erlang
+
+  * Spec - stands for formal CH specification
+
+  * ML   - stands for mailing list
+
+**Semantics:**
+
+  1. Registry.
+      1. It should be possible to register remote processes in local registry (and local processes in remote registry)
+         Rationale: [Uni. Sec 2.3]
+
+      2. If a remote process is stored in registry then Node Controller starts monitoring that process
+         Rationale:  (Implicit requirement in because node should be able to receive notification about process death)
+
+      3. If a process dies and we get asynchronous notification then we remove process from registry
+         Rationale: [Uni. Definition 18, Uni. Table 12] 
+
+  2. `nsend` 
+
+      1. `nsend` should be implemented in terms of lower level function `whereis` and `send`
+
+      2. `nsend` is process does not exists in registry then message got silently dicarded.
+
+
+Possible problems:
+
+Current proposal opens space for race conditions, we should understand if those are relevant for us, and
+could or could not be solved
+  
+a. 2.1 adds a possibility for changing label beetwen where is and send, so message will be
+   sent to the wrong process.
diff --git a/wiki/faq.md b/wiki/faq.md
index 9ad6f53..321475f 100644
--- a/wiki/faq.md
+++ b/wiki/faq.md
@@ -19,29 +19,13 @@ there are still gaps.
 
 You can find them via the *resources* tab just above this page.
 
-#### Will I have to register a Jira account to submit issues?
-
-Yes, you will need to provide a name and email address.
-
-#### Why are you using Jira instead of Github Issues? It seems more complicated.
-
-Jira **is** a bit more complicated than github's bug tracker, and it's certainly
-not perfect. It is, however, a lot better suited to managing and planning a
-project of this size. Cloud Haskell consists of no less than **13** individual
-projects at this time, and that's not to mention some of the experimental ones
-that have been developed by community members and *might* end up being absorbed
-by the team.
-
 ### Help
 
 If the documentation doesn't answer your question, queries about Cloud Haskell
 can be directed to the Parallel Haskell Mailing List
 (parallel-haskell@googlegroups.com), which is pretty active. If you think
 you've found a bug, or would like to request a new feature, please visit the
-[Jira Issue Tracker](https://cloud-haskell.atlassian.net) and submit a bug.
-You **will** need to register with your email address to create new issues,
-though you can freely browse the existing tickets without doing so.
-
+[github](https://github.com/haskell-distributed) repositories and submit a bug.
 
 ### Getting Involved
 
diff --git a/wiki/maintainers.md b/wiki/maintainers.md
index 23130b6..d565456 100644
--- a/wiki/maintainers.md
+++ b/wiki/maintainers.md
@@ -11,7 +11,7 @@ process and in particular, the branching strategy. We also point out Cloud Haske
 various bits of infrastructure as they stand at the moment.
 
 Perhaps the most important thing to do as a maintainer, is to make other developers
-aware of what you're working on by assigning the Jira issue to yourself!
+aware of what you're working on by assigning the github issue to yourself!
 
 ----
 #### Releases
@@ -24,10 +24,10 @@ up though.
 
 #### Community
 
-We keep in touch through the [parallel-haskell google group][7], and once you've
+We keep in touch through the [parallel-haskell mailing list][5], and once you've
 joined the group, by posting to the mailing list address: parallel-haskell@googlegroups.com.
 This is a group for **all** things related to concurrent and parallel Haskell. There is
-also a maintainer/developer centric [cloud-haskell-developers google group][9], which is
+also a maintainer/developer centric [cloud-haskell-developers mailing list][6], which is
 more for in-depth questions about contributing to or maintaining Cloud Haskell.
 
 You might also find some of us hanging out at #haskell-distributed on
@@ -40,15 +40,14 @@ will be used to make announcements (of new releases, etc) on a regular basis.
 
 ### Bug/Issue Tracking and Continuous Integration
 
-Our bug tracker is a hosted/on-demand Jira, for which a free open source
-project license was kindly donated by [Atlassian][6]. You can browse all
-issues without logging in, however to report new issues/bugs you will
-need to provide an email address and create an account.
+We report issues for each project in [github][1].
+You can browse all issues without logging in, however to report new issues/bugs
+you will need to provide an email address and create an account.
 
 If you have any difficulties doing so, please post an email to the
-[parallel-haskell mailing list][7] at parallel-haskell@googlegroups.com.
+[parallel-haskell mailing list][5] at parallel-haskell@googlegroups.com.
 
-We currently use [travis-ci][11] for continuous integration. We do however,
+We currently use [travis-ci][7] for continuous integration. We do however,
 have an open source license for Atlassian Bamboo, which we will be migrating
 to over time - this process is quite involved so we don't have a picture of
 the timescales yet.
@@ -112,15 +111,6 @@ message.
 
 Once we migrate to Bamboo, this may change.
 
-#### Changing Jira bugs/issues via commit messages
-
-You can make complex changes to one or more Jira issues with a single commit message.
-As with skipping CI builds, please **do not** put this messy text into the first line
-of your commit messages.
-
-Details of the format/syntax required to do this can be found on
-[this Jira documentation page](https://confluence.atlassian.com/display/AOD/Processing+JIRA+issues+with+commit+messages)
-
 ----
 
 #### Follow the <a href="/wiki/contributing.html">Contributing guidelines</a>
@@ -142,7 +132,7 @@ you've finished and uploaded the release. If you build and tag three projects,
 only to find that a subsequent dependent package needs a bit of last minute
 surgery, you'll be sorry you didn't wait. With that in mind....
 
-Before releasing any source code, make sure that all the jira tickets
+Before releasing any source code, make sure that all the github tickets
 added to the release are either resolved or remove them from the
 release if you've decided to exclude them.
 
@@ -171,9 +161,8 @@ Since moving to individual git repositories, the tagging scheme is now
 a branch named `release-x.y.z` and push both the newly created tag(s) and the
 branch(es).
 
-Once the release is out, you should go to [JIRA](https://cloud-haskell.atlassian.net)
-and close all the tickets for the release. Jira has a nice 'bulk change' feature
-that makes this very easy.
+Once the release is out, you should go to [github](https://github.com/haskell-distributed)
+and close all the tickets for the release.
 
 After that, it's time to tweet about the release, post to the parallel-haskell
 mailing list, blog etc. Spread the word.
@@ -182,10 +171,6 @@ mailing list, blog etc. Spread the word.
 [2]: https://github.com/haskell-distributed/haskell-distributed.github.com
 [3]: http://hackage.haskell.org
 [4]: http://git-scm.com/book/en/Git-Basics-Tagging
-[5]: https://cloud-haskell.atlassian.net/secure/Dashboard.jspa
-[6]: http://atlassian.com/
-[7]: https://groups.google.com/forum/?fromgroups=#!forum/parallel-haskell
-[8]: /team.html
-[9]: https://groups.google.com/forum/?fromgroups#!forum/cloud-haskell-developers
-[10]: http://en.wikipedia.org/wiki/Greenwich_Mean_Time
-[11]: https://travis-ci.org/
+[5]: https://groups.google.com/forum/?fromgroups=#!forum/parallel-haskell
+[6]: https://groups.google.com/forum/?fromgroups#!forum/cloud-haskell-developers
+[7]: https://travis-ci.org/
diff --git a/wiki/networktransport.md b/wiki/networktransport.md
index 690346c..f6fb51a 100644
--- a/wiki/networktransport.md
+++ b/wiki/networktransport.md
@@ -38,7 +38,7 @@ completely stable yet. The design of the transport layer may also still change.
 Feedback and suggestions are most welcome. Email [Duncan](mailto:duncan@well-typed.com) or [Edsko](mailto:edsko@well-typed.com) at Well-Typed, find us at #haskell-distributed on
 Freenode, or post on the [Parallel Haskell][2] mailing list.
 
-You may also submit issues on the [JIRA issue tracker][8].
+You may also submit issues on [github][8].
 
 ### Hello World
 
@@ -55,30 +55,35 @@ main :: IO ()
 main = do
   serverAddr <- newEmptyMVar
   clientDone <- newEmptyMVar
+  serverDone <- newEmptyMVar
 
   Right transport <- createTransport "127.0.0.1" "10080" defaultTCPParameters
-  
+
   -- "Server"
   forkIO $ do
     Right endpoint <- newEndPoint transport
     putMVar serverAddr (address endpoint)
-   
+
     forever $ do
       event <- receive endpoint
       case event of
         Received _ msg -> print msg
+        ConnectionClosed{} -> putMVar serverDone ()
         _ -> return () -- ignore
 
+
   -- "Client"
   forkIO $ do
     Right endpoint <- newEndPoint transport
-    Right conn     <- do addr <- readMVar serverAddr 
+    Right conn     <- do addr <- readMVar serverAddr
                          connect endpoint addr ReliableOrdered defaultConnectHints
     send conn [fromString "Hello world"]
-    putMVar clientDone ()
+    putMVar clientDone conn
 
   -- Wait for the client to finish
-  takeMVar clientDone
+  conn <- takeMVar clientDone
+  close conn
+  takeMVar serverDone
 {% endhighlight %}
 
 We create a "server" and a "client" (each represented by an `EndPoint`).
@@ -383,10 +388,9 @@ send to it, we don't allocate any unneeded resources).
 
 [1]: http://www.olcf.ornl.gov/center-projects/common-communication-interface/
 [2]: https://groups.google.com/forum/?fromgroups#!forum/parallel-haskell
-[3]: http://cloud-haskell.atlassian.net
-[4]: /tutorials/2.nt_tutorial.html
+[4]: /tutorials/tutorial-NT2.html
 [5]: /wiki/newtransports.html
 [6]: /wiki/newdesign.html
 [7]: /wiki/protocols.html
-[8]: https://cloud-haskell.atlassian.net/issues/?filter=10002
+[8]: https://github.com/haskell-distributed
 [9]: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/028006.html "2 uni-directional TCP connection good?"
diff --git a/wiki/newdesign.md b/wiki/newdesign.md
index 5cd1408..c1ce31d 100644
--- a/wiki/newdesign.md
+++ b/wiki/newdesign.md
@@ -542,14 +542,14 @@ init :: Int -> ([NodeId] -> Process ()) -> IO ()
 
 It takes a number of (OS) processes to fork and the initial (CH) process gets passes a corresponding number of remote `NodeId`s.
 
-For the backend that deals with VMs in the cloud, it might have two initialisation functions, one for the master controller node and one for slave nodes.
+For the backend that deals with VMs in the cloud, it might have two initialisation functions, one for the controller node and one for worker nodes.
 
 {% highlight haskell %}
-initMaster :: MasterConfig -> Process () -> IO ()
-initSlave  :: SlaveConfig -> IO ()
+initController :: ControllerConfig -> Process () -> IO ()
+initWorker  :: WorkerConfig -> IO ()
 {% endhighlight %}
 
-Additionally it might have actions for firing up new VMs and running the program binary in slave mode on that VM:
+Additionally it might have actions for firing up new VMs and running the program binary in worker mode on that VM:
 
 {% highlight haskell %}
 spawnVM    :: VmAccount -> IO VM