Improve introductions of various posts

blog/content/second-edition/posts/01-freestanding-rust-binary/index.md

@@ -6,7 +6,7 @@ date = 2018-02-10
 template = "second-edition/page.html"
 +++
 
-This post describes how to create a Rust executable that does not link the standard library. This makes it possible to run Rust code on the [bare metal] without an underlying operating system.
+The first step in creating our own operating system kernel is to create a Rust executable that does not link the standard library. This makes it possible to run Rust code on the [bare metal] without an underlying operating system.
 
 [bare metal]: https://en.wikipedia.org/wiki/Bare_machine
 

blog/content/second-edition/posts/03-vga-text-buffer/index.md

@@ -6,7 +6,7 @@ date  = 2018-02-26
 template = "second-edition/page.html"
 +++
 
-The [VGA text mode] is a simple way to print text to the screen. In this post, we create an interface that makes its usage safe and simple, by encapsulating all unsafety in a separate module and providing support for Rust's [formatting macros].
+The [VGA text mode] is a simple way to print text to the screen. In this post, we create an interface that makes its usage safe and simple, by encapsulating all unsafety in a separate module. We also implement support for Rust's [formatting macros].
 
 [VGA text mode]: https://en.wikipedia.org/wiki/VGA-compatible_text_mode
 [formatting macros]: https://doc.rust-lang.org/std/fmt/#related-macros

blog/content/second-edition/posts/05-integration-tests/index.md

@@ -6,7 +6,7 @@ date  = 2018-06-15
 template = "second-edition/page.html"
 +++
 
-In this post we complete the testing picture by implementing a basic integration test framework, which allows us to run tests on the target system. The idea is to run tests inside QEMU and report the results back to the host through the serial port.
+To complete the testing picture we implement a basic integration test framework, which allows us to run tests on the target system. The idea is to run tests inside QEMU and report the results back to the host through the serial port.
 
 <!-- more -->
 

blog/content/second-edition/posts/06-cpu-exceptions/index.md

@@ -6,7 +6,7 @@ date  = 2018-06-17
 template = "second-edition/page.html"
 +++
 
-In this post, we start exploring CPU exceptions. Exceptions occur in various erroneous situations, for example when accessing an invalid memory address or when dividing by zero. To catch them, we have to set up an _interrupt descriptor table_ that provides handler functions. At the end of this post, our kernel will be able to catch [breakpoint exceptions] and to resume normal execution afterwards.
+CPU exceptions occur in various erroneous situations, for example when accessing an invalid memory address or when dividing by zero. To react to them we have to set up an _interrupt descriptor table_ that provides handler functions. At the end of this post, our kernel will be able to catch [breakpoint exceptions] and to resume normal execution afterwards.
 
 [breakpoint exceptions]: http://wiki.osdev.org/Exceptions#Breakpoint
 

blog/content/second-edition/posts/07-double-faults/index.md

@@ -6,7 +6,7 @@ date  = 2018-06-18
 template = "second-edition/page.html"
 +++
 
-In this post we explore double faults in detail. We also set up an _Interrupt Stack Table_ to catch double faults on a separate kernel stack. This way, we can completely prevent triple faults, even on kernel stack overflow.
+This post explores the double fault exception in detail, which occurs when the CPU fails to invoke an exception handler. By handling this exception we avoid fatal _triple faults_ that cause a system reset. To prevent triple faults in all cases we also set up an _Interrupt Stack Table_ to catch double faults on a separate kernel stack.
 
 <!-- more -->