diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000000..6313b56c57
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+* text=auto eol=lf
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000000..6997983d44
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,2 @@
+*.swp
+_site
diff --git a/404.md b/404.md
new file mode 100644
index 0000000000..73cdfffeba
--- /dev/null
+++ b/404.md
@@ -0,0 +1,7 @@
+---
+permalink: /404.html
+---
+
+### Page not found
+
+Sorry, couldn't find that page. Perhaps it was an outdated link to a blog post? You'll find a list of blog posts [here](/blog/).
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000000..2f3b68e5a8
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,29 @@
+Copyright (c) 2014, Intel Corporation
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+ * Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+
+ * Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in
+ the documentation and/or other materials provided with the
+ distribution.
+
+ * Neither the name of Intel Corporation nor the names of its
+ contributors may be used to endorse or promote products derived
+ from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/README.md b/README.md
index 29972827ea..1b812ae2d4 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,10 @@
pmem.github.io
==============
-pmem Organization Pages
+### pmem.io web site
+
+This repo contains the jekyll-based web site for http://pmem.io.
+
+The contents of this site are BSD-licensed open source.
+
+Send questions or comments to [andy.rudoff@intel.com](mailto:andy.rudoff@intel.com).
diff --git a/_config.yml b/_config.yml
new file mode 100644
index 0000000000..95571102e2
--- /dev/null
+++ b/_config.yml
@@ -0,0 +1,17 @@
+name: pmem.io
+description: Persistent Memory Programming
+url: http://pmem.io
+
+highlighter: pygments
+
+gems:
+ - jekyll-mentions
+
+defaults:
+ -
+ scope:
+ path: "" # all files
+ values:
+ layout: "default" # default layout is "default"
+
+exclude: ['CNAME', 'LICENSE', 'README.md']
diff --git a/_includes/pagefooter.html b/_includes/pagefooter.html
new file mode 100644
index 0000000000..f6e0a1db4d
--- /dev/null
+++ b/_includes/pagefooter.html
@@ -0,0 +1,5 @@
+
+The contents of this web site and the associated
+GitHub repositories
+are BSD-licensed open source.
+
+
+
diff --git a/_posts/2014-08-25-creating-pmem-io.md b/_posts/2014-08-25-creating-pmem-io.md
new file mode 100644
index 0000000000..b84fe6c09d
--- /dev/null
+++ b/_posts/2014-08-25-creating-pmem-io.md
@@ -0,0 +1,60 @@
+---
+title: Creating pmem.io
+author: andyrudoff
+layout: post
+---
+
+The [pmem](https://github.com/pmem) project in GitHub has been
+created as an open source project focused on persistent memory programming.
+Everything on this web site and the associated GitHub repositories is
+open source under the "three-clause" BSD license.
+
+Some educational [Linux examples](https://github.com/pmem/linux-examples)
+are included, which demonstrate the
+[SNIA NVM programming model](http://snia.org/nvmp) and some of the
+interesting features and challenges associated with persistent memory.
+
+The team's initial focus is the Linux [NVM Library](/nvml/) which
+will provide useful APIs for memory allocation, transactions, etc.
+built on top of the NVM programming model.
+
+This site includes a [pmem blog](/blog/) based on
+[Jekyll](https://github.com/jekyll/jekyll) so over time we can
+write up our experiences working with persistent memory programming.
+There are [many ways](/about/) to get involved and we welcome your
+contributions!
+
+#### GitHub Pages and Jekyll
+
+Since we will surely keep our focus on persistent memory and
+immediately forget the steps taken to create this site, here's
+a quick summary for reference. First, any GitHub user or project
+area can have [GitHub Pages](https://pages.github.com/) associated
+with them with almost no effort. We simply created a repository
+named **pmem.github.io** to hold the pages. GitHub pages use
+Jekyll automatically, but it is convenient to install it locally
+for previewing content before pushing changes to the repo. On the
+Debian-based distro known as _CrunchBang_, these steps did the trick:
+
+{% highlight sh %}
+$ sudo apt-get install ruby ruby-dev node python-pygments
+$ sudo gem install jekyll
+$ sudo gem install jekyll-mentions
+{% endhighlight %}
+
+After creating the appropriate Jekyll files in the local copy
+of the repo, we used this command:
+
+{% highlight sh %}
+$ jekyll serve --watch
+{% endhighlight %}
+
+This watches for changes, re-generating
+the web pages as necessary, and provides the content for preview
+at the local URL `http://0.0.0.0:4000/`.
+
+The rest of the details (like how to write a `_config.yml` or create
+templates or includes) can all be found in the
+[Jekyll documentation](http://jekyllrb.com/) or you can look
+at the [source for this web site](https://github.com/pmem/pmem.github.io/)
+for details.
diff --git a/_posts/2014-08-26-references.md b/_posts/2014-08-26-references.md
new file mode 100644
index 0000000000..16a832ab6f
--- /dev/null
+++ b/_posts/2014-08-26-references.md
@@ -0,0 +1,48 @@
+---
+title: References
+author: andyrudoff
+layout: post
+---
+
+Some very interesting research has been happening in the area of
+Persistent Memory and more is emerging. While the examples provided
+here are meant as introductory and simple, some publications cover
+the topic in much more depth and include complete transaction systems,
+compiler/language enhancements, etc. Here are some of the most
+important publications in this space (please send links to more and
+we'll include them).
+
+One of the most impressive bodies of work in this area is **Mnemosyne**.
+Read the paper:
+
+- Haris Volos, Andres Jaan Tack, Michael M. Swift: _Mnemosyne:
+Lightweight Persistent Memory_, The 16th ACM Conference on
+Architectural Support for Programming Languages and Operating
+Systems (ASPLOS 2011), March 2011, Newport Beach, California.
+
+and explore the website, which includes full source and documentation:
+
+- [http://research.cs.wisc.edu/sonar/projects/mnemosyne/](http://research.cs.wisc.edu/sonar/projects/mnemosyne/)
+
+Another very relevant project is **NV-Heaps**. Read the paper:
+
+- J. Coburn, et al.: _NV-Heaps: Making Persistent Objects Fast and Safe
+with Next Generation, Non-Volatile Memories_, The 16th ACM Conference
+on Architectural Support for Programming Languages and Operating
+Systems (ASPLOS 2011), March 2011, Newport Beach, Ca.
+
+The June 2013 issue of _USENIX ;login:_ contains an article that discusses
+the NVM Programming Model, including a discussion of Persistent Memory.
+
+- [https://www.usenix.org/publications/login/june-2013-volume-38-number-3](https://www.usenix.org/publications/login/june-2013-volume-38-number-3)
+
+The NVM Programming Technical Work Group (TWG) in SNIA has over 35
+companies working together on NVM programming models, including
+Persistent Memory. You can read more about the TWG and see the
+programming model specification here:
+
+- [http://snia.org/nvmp](http://snia.org/nvmp)
+
+The basics of NVDIMM at Wikipedia, with lots of additional links:
+
+- [http://en.wikipedia.org/wiki/NVDIMM](http://en.wikipedia.org/wiki/NVDIMM)
diff --git a/_posts/2014-08-27-crawl-walk-run.md b/_posts/2014-08-27-crawl-walk-run.md
new file mode 100644
index 0000000000..4e0e08fc56
--- /dev/null
+++ b/_posts/2014-08-27-crawl-walk-run.md
@@ -0,0 +1,71 @@
+---
+title: Crawl, Walk, Run...
+author: andyrudoff
+layout: post
+---
+
+> _If you can't fly then run, if you can't run then walk, if you can't walk then crawl, but whatever you do you have to keep moving forward._
+>
+> - Martin Luther King Jr.
+
+This project, as well as the support for persistent memory in
+various operating systems, can be thought of as a _crawl, walk, run_
+approach. As byte-addressable persistence enters the market,
+modified system BIOS images and device drivers expose it to
+other modules in the kernel. Despite the byte-addressability,
+many of the initial usages are based on block storage device
+interfaces. But you have to start somewhere, so this is the
+_crawl_ phase. The move beyond that, we need a software
+architecture for exposing persistent memory up the stack.
+
+
+
+The picture above shows the _walk_ phase of persistent memory
+support: exposing persistent memory up the stack so applications
+can leverage it. When the [SNIA NVM Programming TWG](http://snia.org/nvmp)
+(Technical Work Group) was discussing how persistent memory was
+exposed, there was a pervasive feeling in the group that the
+best approach would leverage existing mechanisms, like the file system
+naming and administrative model. So the recommendation published
+by the TWG matches the above diagram, and that's the initial
+approach we see happening in the Linux community.
+
+The idea is fairly straightforward. We want applications to have
+direct load/store access to persistent memory just as they do to
+traditional volatile memory. But since persistent memory is, well,
+persistent, applications are going to need to be able to express
+which blob of previously-stored data is desired when asking the OS
+for direct access to it. This is done using the well-understood
+file namespace. So walking through the path from hardware (at the bottom)
+to the application (at the top) in the above picture, we see a
+non-volatile DIMM (NVDIMM), which is one way of providing persistent
+memory to the platform, and it is managed by a driver in the OS labeled
+_NVDIMM Driver_ in the picture. That driver provides access for
+manageability, shown on the left (for things like configuration changes
+and health monitoring). The driver may also provide the common
+block-based storage interfaces shown in the middle of the picture,
+so that existing file systems or applications that use block storage
+directly work without modification. But the more disruptive path
+(and the more interesting to this project) is the rightmost path
+where the application opens a file using a _persistent memory aware
+file system_ and then memory-maps that file. This is done in Linux
+using the [mmap(2)](http://linux.die.net/man/2/mmap) system call.
+
+So this is the _walk_ phase for persistent memory: when an application
+memory-maps a file from a _persistent memory aware file system_ it
+gets direct access to the persistence (shown in the far right arrow
+in the above picture). Unlike the page-cache-cased memory mapping
+done by traditional file systems, the persistent memory aware file
+system literally provides the shortest possible path
+between an application and some storage! Once things are set up and
+initial page faults are taken, there's no kernel code running at all
+when data is fetched from persistent memory -- the application loads
+the data directly from the NVDIMM.
+
+So what's the _run_ phase? Giving an application a large range of
+directly-mapped persistence is cool, but every application writer
+will then start the complex process of managing how data structures
+are laid out in that raw range of memory. That's where libraries
+come in -- to help application writers solve some of the more common
+problems like memory allocation or transactional updates. That will
+be the topic for an upcoming blog entry.
diff --git a/_posts/2014-08-29-linux-examples.md b/_posts/2014-08-29-linux-examples.md
new file mode 100644
index 0000000000..6762d2a009
--- /dev/null
+++ b/_posts/2014-08-29-linux-examples.md
@@ -0,0 +1,35 @@
+---
+title: Linux Examples
+author: andyrudoff
+layout: post
+---
+
+The [basic architecture]({% post_url 2014-08-27-crawl-walk-run %})
+for exposing persistent memory gives applications a very **raw**
+type of access. Applications can load/store directly to the
+persistence, but then what. What are the interesting problems
+facing an application developer and what would some solutions
+look like?
+
+To help describe the issues and potential solutions, we've
+published a set of [Linux examples](https://github.com/pmem/linux-examples)
+around persistent memory. These examples start with a simple
+"hello, world!" style program for storing a string in persistent
+memory, and end with a full binary tree sort example which maintains
+a consistent tree data structure even in the face of power failure or
+other types of system interruption. The examples include a mini
+fault injection framework to illustrate the type of tools that
+are necessary for demonstrating programs correctly survive system
+interruption.
+
+While not really useful in a production environment, these examples
+are educational, and provide a background on how persistent memory
+is exposed to applications and what the application writer needs to
+consider before using it. So please
+[check it out](https://github.com/pmem/linux-examples) and feel
+free to ask questions, comment on it, or contribute to it.
+(Scroll down on the GitHub repository page to see the README which
+contains all sorts of details on the examples.)
+A good
+place to send questions or comments is our
+[Google Group](http://groups.google.com/group/pmem).
diff --git a/_posts/2014-09-01-nvm-library-overview.md b/_posts/2014-09-01-nvm-library-overview.md
new file mode 100644
index 0000000000..025d733821
--- /dev/null
+++ b/_posts/2014-09-01-nvm-library-overview.md
@@ -0,0 +1,63 @@
+---
+title: NVM Library Overview
+author: andyrudoff
+layout: post
+---
+
+Why are we building an NVM Library? Where does it live? How
+does it work? This blog entry provides some answers,
+which refer to this picture
+showing the overall library architecture:
+
+
+
+#### Why?
+
+The operating system exposes persistent memory to applications as
+a memory-mapped file, using a _persistent memory aware file system_
+as shown in the picture. But that's a very **raw** form of access.
+Stopping there would be like telling applications they have all the
+dynamic memory they need because the OS provides the
+[sbrk(2)](http://linux.die.net/man/2/sbrk) system call. Just as
+libc and most other language run-time environments provide memory
+management APIs like [malloc(3) and free(3)](http://linux.die.net/man/3/malloc),
+which build on the raw interfaces like sbrk(), we need to do something
+similar for persistent memory. Memory-mapping a pmem file gets you
+direct access, but then you will want to carve it up into data structures
+and update it in a way that remains consistent across system interruptions.
+
+So why isn't the answer just to provide a version of malloc() and free()
+that allocates from the system's pool of persistent memory? Because those
+interfaces don't comprehend the idea of persistence. If a program allocates
+a blob of memory using malloc(), but dies before linking anything to it,
+that memory is a _persistent memory leak_ and the pool is then inconsistent
+from that point on. With volatile memory, that's not an issue since it
+starts from nothing each time the program runs. But for persistent memory,
+we need a _pmem-aware_ malloc() library to make it useful.
+
+#### Where?
+
+As shown in the picture above, the library lives in user space, used by
+the application as necessary. The NVM Library is a convenience, not
+a requirement; an application that wants to access raw persistent memory
+directly is welcome to do so by mapping it and accessing it. But an
+application that wants to do things like malloc(), free(), and some sort
+of transactions may find the NVM Library useful.
+
+Another aspect of the _where_ question is what types of persistence does
+the library support? The intention is that the NVM Library will work
+on top of any non-volatile memory, not just persistent memory. By
+writing a library that is optimized for persistent memory, but that
+behaves reasonably on other types of NVM (like SSDs), there's a good
+chance that applications can use the library for both configurations
+and be simpler as a result. (This is why the library is named the
+_NVM Library_ and not the _PMEM Library_, by the way.)
+
+#### How?
+
+Researching persistent memory aware algorithms and making the best
+architectural trade-offs is a big part of this project and that work
+is underway. So we don't have all the answers yet on how the library
+works. Some parts of the library are functional, other parts are
+still being designed. Check out the [NVM Library](/nvml/) page
+for the latest man pages which describe the APIs available so far.
diff --git a/about/index.md b/about/index.md
new file mode 100644
index 0000000000..6869f6a233
--- /dev/null
+++ b/about/index.md
@@ -0,0 +1,42 @@
+---
+title: About
+---
+
+This open source project is dedicated to making
+_persistent memory programming_ easier for application developers.
+Over time, we hope to host several libraries, examples, and
+documents related to persistent memory. Current activity is
+focused on the [Linux NVM Library](/nvml/), which builds on the
+programming model for persistent memory recommended by the
+[SNIA NVM Programming Technical Workgroup](http://snia.org/nvmp).
+
+What is _persistent memory_? See the full definition used by this
+project on the [Glossary page](/glossary). In short, it is an
+emerging technology that introduces a new tier between memory and
+storage, a byte-addressable storage, accessed by the application
+using loads and stores like memory. This new technology comes
+with a number of challenges which is why this project was created.
+
+#### Contacting Us
+
+The NVM Library team at
+[Intel Corporation](http://www.intel.com), led by
+[Andy Rudoff](mailto:andy.rudoff@intel.com), created this project
+on GitHub to encourage community development.
+Your participation,
+feedback, and questions are welcome. You can:
+
+* [Create an issue](https://github.com/pmem/issues/issues) in our GitHub
+ issues database. This is a good way to report problems or request new
+ features.
+* [Join our Google Group](http://groups.google.com/group/pmem) to
+ participate in discussions on persistent memory programming, including
+ the design of the NVM Library API and future directions.
+* Find us on IRC on the **#pmem** channel on [OFTC](http://www.oftc.net).
+
+#### More Info
+
+See [this blog post]({% post_url 2014-08-26-references %}) for a list
+of interesting publications related to persistent memory programming.
+
+You can also subscribe to this blog [via RSS](/feed.xml).
diff --git a/assets/libarch.jpg b/assets/libarch.jpg
new file mode 100644
index 0000000000..35c75a6b00
Binary files /dev/null and b/assets/libarch.jpg differ
diff --git a/assets/libarch_small.jpg b/assets/libarch_small.jpg
new file mode 100644
index 0000000000..451514d342
Binary files /dev/null and b/assets/libarch_small.jpg differ
diff --git a/assets/swarch.jpg b/assets/swarch.jpg
new file mode 100644
index 0000000000..f14f18d128
Binary files /dev/null and b/assets/swarch.jpg differ
diff --git a/assets/swarch_small.jpg b/assets/swarch_small.jpg
new file mode 100644
index 0000000000..dcb2db92c9
Binary files /dev/null and b/assets/swarch_small.jpg differ
diff --git a/blog/index.md b/blog/index.md
new file mode 100644
index 0000000000..64243d6a8c
--- /dev/null
+++ b/blog/index.md
@@ -0,0 +1,14 @@
+---
+title: Blog
+---
+
+### Persistent Memory Programming Blog
+
+Here's a list of blog posts, shown most recent first:
+
+{% for post in site.posts %}
+
+{{ post.date | date: '%B %d, %Y' }} -- {{ post.title }}
+{{ post.content | strip_html | truncatewords:50}}
+{% endfor %}
+
diff --git a/css/pmem.css b/css/pmem.css
new file mode 100644
index 0000000000..5996dc26ca
--- /dev/null
+++ b/css/pmem.css
@@ -0,0 +1,298 @@
+/* reset */
+a, abbr, acronym, address, applet, article, aside, audio, b, big, blockquote,
+body, canvas, caption, center, cite, code, dd, del, details, dfn, div, dl, dt,
+em, embed, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6,
+header, hgroup, html, i, iframe, img, ins, kbd, label, legend, li, mark, menu,
+nav, object, ol, output, p, pre, q, s, samp, section, small, span, strike,
+strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, time, tr, tt, u,
+ul, var, video {
+ margin: 0;
+ padding: 0;
+ border: 0;
+ font: inherit;
+ vertical-align: baseline;
+}
+
+article, aside, details, figcaption, figure, footer, header, hgroup, menu,
+nav, section {
+ display: block;
+}
+
+ol, ul {
+ list-style: none;
+}
+
+table {
+ border-collapse: collapse;
+ border-spacing: 0;
+}
+
+/* basic styles */
+body {
+ box-sizing: border-box;
+ color:#000;
+ background: #fff;
+ font-size: 16px;
+ font-family: "Nimbus Sans L", "URW Gothic L", Verdana, Tahoma,
+ Helvetica, sans-serif;
+ line-height: 1.5;
+ -webkit-font-smoothing: antialiased;
+}
+
+h1, h2, h3, h4, h5, h6 {
+ margin: 10px 0;
+ font-weight: bold;
+}
+
+h1 {
+ font-size: 36px;
+}
+
+h2 {
+ padding-bottom: 10px;
+ font-size: 32px;
+}
+
+h3 {
+ font-size: 24px;
+}
+
+h4 {
+ font-size: 21px;
+}
+
+h5 {
+ font-size: 18px;
+}
+
+h6 {
+ font-size: 14px;
+}
+
+p {
+ margin: 10px 0 15px 0;
+}
+
+a {
+ text-decoration: none;
+ color: #007edf;
+ text-shadow: none;
+}
+
+a:hover, a:focus {
+ text-decoration: underline;
+}
+
+footer a {
+ color: #f2f2f2;
+ text-decoration: underline;
+}
+
+em {
+ font-style: italic;
+}
+
+strong {
+ font-weight: bold;
+}
+
+img {
+ position: relative;
+ margin: 0 auto;
+ max-width: 739px;
+ padding: 5px;
+ margin: 10px 0 10px 0;
+}
+
+p img {
+ display: inline;
+ margin: 0;
+ padding: 0;
+ vertical-align: middle;
+ text-align: center;
+ border: none;
+}
+
+pre, code {
+ color: #222;
+ background-color: #f8f8c0;
+ font-family: Monaco, "Bitstream Vera Sans Mono", "Lucida Console",
+ Terminal, monospace;
+ font-size: 14px;
+ border-radius: 2px;
+ -moz-border-radius: 2px;
+ -webkit-border-radius: 2px;
+}
+
+pre {
+ padding: 10px;
+ box-shadow: 0 0 10px rgba(0,0,0,.1);
+ overflow: auto;
+}
+
+code {
+ padding: 3px;
+ margin: 0 3px;
+ box-shadow: 0 0 10px rgba(0,0,0,.1);
+}
+
+pre code {
+ display: block;
+ box-shadow: none;
+}
+
+blockquote {
+ color: #666;
+ margin-bottom: 20px;
+ padding: 0 0 0 20px;
+ border-left: 3px solid #bbb;
+}
+
+
+ul, ol, dl {
+ margin-bottom: 15px
+}
+
+ul {
+ list-style: disc outside none;
+ padding-left: 1em;
+ margin-left: 1em;
+}
+
+ol {
+ list-style: decimal outside;
+ padding-left: 1em;
+ margin-left: 1em;
+}
+
+dl dt {
+ font-weight: bold;
+}
+
+dl dd {
+ padding-left: 20px;
+ font-style: italic;
+}
+
+dl p {
+ padding-left: 20px;
+ font-style: italic;
+}
+
+table {
+ border: 1px solid #373737;
+ margin-bottom: 20px;
+ text-align: left;
+}
+
+th {
+ font-family: 'Lucida Grande', 'Helvetica Neue', Helvetica,
+ Arial, sans-serif;
+ padding: 10px;
+ background: #373737;
+ color: #fff;
+}
+
+td {
+ padding: 10px;
+ border: 1px solid #373737;
+}
+
+form {
+ background: #f2f2f2;
+ padding: 20px;
+}
+
+/* region definitions */
+#wrap {
+ width: 750px;
+ margin: 0 auto;
+}
+
+#header {
+ text-align: center;
+ padding: 20px 20px;
+}
+
+#header a {
+ text-decoration: none;
+ color: #000;
+ text-shadow: none;
+}
+
+h1 {
+ margin: 0;
+}
+
+#nav {
+ padding: 5px 10px;
+ border-style: solid;
+ border-bottom: 2px solid #000;
+}
+
+#nav ul {
+ margin: 0;
+ padding: 0;
+ list-style: none;
+}
+
+#nav li {
+ display: inline;
+ font-weight: bold;
+ font-size: 20px;
+ margin: 0;
+ padding: 0 15px 0 15px;
+}
+
+#nav a {
+ text-decoration: none;
+ color: #f04040;
+}
+
+#nav a.sel {
+ color: #000;
+}
+
+#nav a:hover {
+ color: #000;
+}
+
+#main {
+ float: left;
+ width: 480px;
+ padding: 20px;
+}
+
+h2 {
+ margin: 0 0 1em;
+}
+
+#sidebar {
+ float: right;
+ width: 190px;
+ padding: 20px;
+ background: #e8f8f8;
+ margin: 150px 0 150px 0;
+}
+
+#footer {
+ text-align: center;
+ font-size: 10px;
+ color: #404040;
+ clear: both;
+ padding: 5px 10px;
+}
+
+#footer p {
+ margin: 0;
+ padding: 20px 20px;
+}
+
+* html #footer {
+ height: 1px;
+}
+
+#postinfo {
+ font-size: 10px;
+ color: #606060;
+}
diff --git a/stylesheets/pygment_trac.css b/css/pygment_trac.css
similarity index 100%
rename from stylesheets/pygment_trac.css
rename to css/pygment_trac.css
diff --git a/feed.xml b/feed.xml
new file mode 100644
index 0000000000..cd9d1a18e5
--- /dev/null
+++ b/feed.xml
@@ -0,0 +1,21 @@
+---
+layout: null
+---
+
+
+
+ {{ site.name | xml_escape }}
+ {{ site.description | xml_escape }}
+ {{ site.url }}
+
+ {% for post in site.posts limit:10 %}
+
+ {{ post.title | xml_escape }}
+ {{ post.content | xml_escape }}
+ {{ post.date | date: "%a, %d %b %Y %H:%M:%S %z" }}
+ {{ site.url }}/{{ post.url }}
+ {{ site.url }}/{{ post.url }}
+
+ {% endfor %}
+
+
diff --git a/glossary/index.md b/glossary/index.md
new file mode 100644
index 0000000000..1d01556f53
--- /dev/null
+++ b/glossary/index.md
@@ -0,0 +1,47 @@
+---
+title: Glossary
+---
+
+#### Glossary of Terms Used on This Site
+
+It seems the industry is _mostly_ aligned on these terms, but not 100%.
+Taken literally, the terms _Non-Volatile Memory_ and _Persistent Memory_
+would seem to be the same thing. But in contemporary usage, the terms
+are different. Here's how these terms are used by this project.
+
+**Non-Volatile Memory (NVM)**
+
+This term refers to the category of solid-state storage devices,
+from the [Flash Memory](http://en.wikipedia.org/wiki/Flash_memory)
+used in Solid State Disk (SSD) drives, to battery-backed up
+memory cards, to the emerging non-volatile technologies such
+as [PCM](http://en.wikipedia.org/wiki/Phase-change_memory),
+[Memristor](http://en.wikipedia.org/wiki/Memristor),
+[STT-RAM](http://en.wikipedia.org/wiki/Spin-transfer_torque), etc.
+
+In this project we use the term _NVM_ to refer to the entire class
+of non-volatile technologies. For the faster varieties, where direct,
+load/store access is appropriate, read on...
+
+**Persistent Memory**
+
+This term refers to memory that maintains its contents across
+power failure. We specifically refer to memory technologies that
+are fast enough so it is _reasonable to stall a CPU load instruction_,
+waiting for a load directly from persistent memory.
+
+By this definition, the NAND Flash used in SSDs would not qualify
+as persistent memory when accessed directly, but battery-backed DRAM
+or (hopefully) the emerging non-volatile memory technologies would
+qualify for direct access.
+
+**NVM Library**
+
+Given the above definitions, one might ask why the current project
+is called the _NVM Library_ and not the _Persistent Memory Library_.
+The goal is to design the [NVM Library](/nvml/) so it can leverage the direct
+load/store capabilities of persistent memory, but also work on other NVM
+technologies (albeit not as optimally).
+Since the programming model for persistent memory is based on
+memory-mapped files, the library will work correctly on top of any
+NVM technology (like an SSD with a traditional file system on it).
diff --git a/images/bg_hr.png b/images/bg_hr.png
deleted file mode 100644
index 514aee5056..0000000000
Binary files a/images/bg_hr.png and /dev/null differ
diff --git a/images/bkg.png b/images/bkg.png
deleted file mode 100644
index d10e5caf1a..0000000000
Binary files a/images/bkg.png and /dev/null differ
diff --git a/images/blacktocat.png b/images/blacktocat.png
deleted file mode 100644
index e160053a5b..0000000000
Binary files a/images/blacktocat.png and /dev/null differ
diff --git a/images/icon_download.png b/images/icon_download.png
deleted file mode 100644
index 5a793f1768..0000000000
Binary files a/images/icon_download.png and /dev/null differ
diff --git a/images/sprite_download.png b/images/sprite_download.png
deleted file mode 100644
index f9f8de24c1..0000000000
Binary files a/images/sprite_download.png and /dev/null differ
diff --git a/index.html b/index.html
deleted file mode 100644
index cfda80f994..0000000000
--- a/index.html
+++ /dev/null
@@ -1,64 +0,0 @@
-
-
-
-
-
-
-
-
-
-
- pmem.io
-
-
-
-
-
-
Here you'll find information on Persistent Memory Programming, including links to libraries, sample code, operating system enabling projects, publications, etc.
-
-
-Note: These are works in progress... stay tuned!
-
-
-
-NVML -- Non-Volatile Memory Libraries for using Persistent Memory on Linux
-
-Linux Examples -- Some Educational Examples, Written for Linux