diff --git a/blog/page/cross-compile-binutils.md b/blog/page/cross-compile-binutils.md
index 10eb72d0..3f8d99a4 100644
--- a/blog/page/cross-compile-binutils.md
+++ b/blog/page/cross-compile-binutils.md
@@ -1,7 +1,7 @@
----
-layout: page
-title: Cross Compile Binutils
----
++++
+title = "Cross Compile Binutils"
++++
+
 The [GNU Binutils] are a collection of various binary tools such as `ld`, `as`, `objdump`, or `readelf`. These tools are platform-specific, so you need to compile them again if your host system and target system are different. In our case, we need `ld` and `objdump` for the x86_64 architecture.
 [GNU Binutils]: https://www.gnu.org/software/binutils/
 
diff --git a/blog/page/cross-compile-libcore.md b/blog/page/cross-compile-libcore.md
index 9b9ae7f6..5cd1ca0f 100644
--- a/blog/page/cross-compile-libcore.md
+++ b/blog/page/cross-compile-libcore.md
@@ -1,7 +1,7 @@
----
-layout: page
-title: "Cross Compiling: libcore"
----
++++
+title = "Cross Compiling: libcore"
++++
+
 So you're getting an ``error: can't find crate for `core` [E0463]`` when using `--target x86_64-unknown-linux-gnu`. That means that you're not running Linux or not using using a x86_64 processor.
 
 **If you have an x86_64 processor and want a quick fix**, try it with `x86_64-pc-windows-gnu` or `x86_64-apple-darwin` (or simply omit the explicit `--target`).
diff --git a/blog/page/set-up-gdb.md b/blog/page/set-up-gdb.md
index d606f4d2..62ec05d8 100644
--- a/blog/page/set-up-gdb.md
+++ b/blog/page/set-up-gdb.md
@@ -1,7 +1,7 @@
----
-layout: page
-title: "Set Up GDB"
----
++++
+title = "Set Up GDB"
++++
+
 There are a lot of things that can go wrong when developing an OS. So it's a good idea to add a debugger to our toolset, which allows us to set breakpoints and examine variables. We will use [GDB](https://www.gnu.org/software/gdb/) as QEMU supports it out of the box.
 
 ### QEMU parameters
diff --git a/blog/post/2015-08-18-multiboot-kernel.md b/blog/post/2015-08-18-multiboot-kernel.md
index a01fa1aa..38d60646 100644
--- a/blog/post/2015-08-18-multiboot-kernel.md
+++ b/blog/post/2015-08-18-multiboot-kernel.md
@@ -1,8 +1,12 @@
----
-layout: post
-title: 'A minimal x86 kernel'
-redirect_from: '/2015/08/18/multiboot-kernel/'
----
++++
+title = "A minimal x86 kernel"
+slug = "multiboot-kernel"
+date = "2015-08-18"
+aliases = [
+    "/2015/08/18/multiboot-kernel/",
+]
++++
+
 This post explains how to create a minimal x86 operating system kernel. In fact, it will just boot and print `OK` to the screen. The following blog posts we will extend it using the [Rust] programming language.
 
 I tried to explain everything in detail and to keep the code as simple as possible. If you have any questions, suggestions or other issues, please leave a comment or [create an issue] on Github. The source code is available in a [repository][source code], too.
diff --git a/blog/post/2015-08-25-entering-longmode.md b/blog/post/2015-08-25-entering-longmode.md
index 1631da10..88417528 100644
--- a/blog/post/2015-08-25-entering-longmode.md
+++ b/blog/post/2015-08-25-entering-longmode.md
@@ -1,9 +1,13 @@
----
-layout: post
-title: 'Entering Long Mode'
-redirect_from: "/2015/08/25/entering-longmode/"
-updated: 2015-10-29 00:00:00 +0000
----
++++
+title = "Entering Long Mode"
+slug = "entering-longmode"
+date = "2015-08-25"
+updated = "2015-10-29"
+aliases = [
+    "/2015/08/25/entering-longmode/",
+]
++++
+
 In the [previous post] we created a minimal multiboot kernel. It just prints `OK` and hangs. The goal is to extend it and call 64-bit [Rust] code. But the CPU is currently in [protected mode] and allows only 32-bit instructions and up to 4GiB memory. So we need to set up _Paging_ and switch to the 64-bit [long mode] first.
 
 I tried to explain everything in detail and to keep the code as simple as possible. If you have any questions, suggestions, or issues, please leave a comment or [create an issue] on Github. The source code is available in a [repository][source code], too.
@@ -155,7 +159,7 @@ check_long_mode:
     cpuid                  ; get highest supported argument
     cmp eax, 0x80000001    ; it needs to be at least 0x80000001
     jb .no_long_mode       ; if it's less, the CPU is too old for long mode
-    
+
     ; use extended info to test if long mode is available
     mov eax, 0x80000001    ; argument for extended processor info
     cpuid                  ; returns various feature bits in ecx and edx
diff --git a/blog/post/2015-09-02-set-up-rust.md b/blog/post/2015-09-02-set-up-rust.md
index f103f8aa..5d70a858 100644
--- a/blog/post/2015-09-02-set-up-rust.md
+++ b/blog/post/2015-09-02-set-up-rust.md
@@ -1,9 +1,12 @@
----
-layout: post
-title: 'Set Up Rust'
-redirect_from: "/2015/09/02/setup-rust/"
-redirect_from: "/setup-rust.html"
----
++++
+title = "Set Up Rust"
+date = "2015-09-02"
+aliases = [
+    "/2015/09/02/setup-rust/",
+    "/setup-rust.html",
+]
++++
+
 In the previous posts we created a [minimal Multiboot kernel][multiboot post] and [switched to Long Mode][long mode post]. Now we can finally switch to [Rust] code. Rust is a high-level language without runtime. It allows us to not link the standard library and write bare metal code. Unfortunately the setup is not quite hassle-free yet.
 
 This blog post tries to set up Rust step-by-step and point out the different problems. If you have any questions, problems, or suggestions please [file an issue] or create a comment at the bottom. The code from this post is in a [Github repository], too.
diff --git a/blog/post/2015-10-23-printing-to-screen.md b/blog/post/2015-10-23-printing-to-screen.md
index 53ec89e0..8edc542b 100644
--- a/blog/post/2015-10-23-printing-to-screen.md
+++ b/blog/post/2015-10-23-printing-to-screen.md
@@ -1,8 +1,11 @@
----
-layout: post
-title: 'Printing to Screen'
-redirect_from: "/2015/10/23/printing-to-screen/"
----
++++
+title = "Printing to Screen"
+date = "2015-10-23"
+aliases = [
+    "/2015/10/23/printing-to-screen/",
+]
++++
+
 In the [previous post] we switched from assembly to [Rust], a systems programming language that provides great safety. But so far we are using unsafe features like [raw pointers] whenever we want to print to screen. In this post we will create a Rust module that provides a safe and easy-to-use interface for the VGA text buffer. It will support Rust's [formatting macros], too.
 
 [previous post]: {{ page.previous.url }}
diff --git a/blog/post/2015-11-15-allocating-frames.md b/blog/post/2015-11-15-allocating-frames.md
index 22d7e778..1feb6348 100644
--- a/blog/post/2015-11-15-allocating-frames.md
+++ b/blog/post/2015-11-15-allocating-frames.md
@@ -1,7 +1,7 @@
----
-layout: post
-title: 'Allocating Frames'
----
++++
+title = "Allocating Frames"
+date = "2015-11-15"
++++
 
 In this post we create an allocator that provides free physical frames for a future paging module. To get the required information about available and used memory we use the Multiboot information structure. Additionally, we improve the `panic` handler to print the corresponding message and source line.
 
diff --git a/blog/post/2015-12-09-modifying-page-tables.md b/blog/post/2015-12-09-modifying-page-tables.md
index cfaf8227..79312714 100644
--- a/blog/post/2015-12-09-modifying-page-tables.md
+++ b/blog/post/2015-12-09-modifying-page-tables.md
@@ -1,7 +1,8 @@
----
-layout: post
-title: 'Page Tables'
----
++++
+title = "Page Tables"
+slug = "modifying-page-tables"
+date = "2015-12-09"
++++
 
 In this post we will create a paging module, which allows us to access and modify the 4-level page table. We will explore recursive page table mapping and use some Rust features to make it safe. Finally we will create functions to translate virtual addresses and to map and unmap pages.
 
diff --git a/blog/post/2016-01-01-remap-the-kernel.md b/blog/post/2016-01-01-remap-the-kernel.md
index bd71bf70..4d7e4675 100644
--- a/blog/post/2016-01-01-remap-the-kernel.md
+++ b/blog/post/2016-01-01-remap-the-kernel.md
@@ -1,8 +1,9 @@
----
-layout: post
-title: 'Remap the Kernel'
-updated: 2016-03-06 00:00:00 +0000
----
++++
+title = "Remap the Kernel"
+date = "2016-01-01"
+updated = "2016-03-06"
++++
+
 In this post we will create a new page table to map the kernel sections correctly. Therefor we will extend the paging module to support modifications of _inactive_ page tables as well. Then we will switch to the new table and secure our kernel stack by creating a guard page.
 
 As always, you can find the source code on [Github]. Don't hesitate to file issues there if you have any problems or improvement suggestions. There is also a comment section at the end of this page. Note that this post requires a current Rust nightly.
diff --git a/blog/post/2016-04-11-kernel-heap.md b/blog/post/2016-04-11-kernel-heap.md
index 01a9ae57..70ec7456 100644
--- a/blog/post/2016-04-11-kernel-heap.md
+++ b/blog/post/2016-04-11-kernel-heap.md
@@ -1,7 +1,7 @@
----
-layout: post
-title: 'Kernel Heap'
----
++++
+title = "Kernel Heap"
+date = "2016-04-11"
++++
 
 In the previous posts we have created a [frame allocator] and a [page table module]. Now we are ready to create a kernel heap and a memory allocator. Thus, we will unlock `Box`, `Vec`, `BTreeMap`, and the rest of the [alloc] and [collections] crates.