diff --git a/_posts/2015-08-18-multiboot-kernel.md b/_posts/2015-08-18-multiboot-kernel.md
index cab684bb..333d1c3e 100644
--- a/_posts/2015-08-18-multiboot-kernel.md
+++ b/_posts/2015-08-18-multiboot-kernel.md
@@ -9,7 +9,7 @@ I tried to explain everything in detail and to keep the code as simple as possib
 
 [Rust]: http://www.rust-lang.org/
 [create an issue]: https://github.com/phil-opp/phil-opp.github.io/issues
-[source code]: https://github.com/phil-opp/blogOS/tree/multiboot_bootstrap/src/arch/x86_64
+[source code]: https://github.com/phil-opp/blog_os/tree/multiboot_bootstrap/src/arch/x86_64
 
 ## Overview
 When you turn on a computer, it loads the [BIOS] from some special flash memory. The BIOS runs self test and initialization routines of the hardware, then it looks for bootable devices. If it finds one, the control is transferred to its _bootloader_, which is a small portion of executable code stored at the device's beginning. The bootloader has to determine the location of the kernel image on the device and load it into memory. It also needs to switch the CPU to the so-called [protected mode] because x86 CPUs start in the very limited [real mode] by default (to be compatible to programs from 1978).
diff --git a/_posts/2015-08-25-entering-longmode.md b/_posts/2015-08-25-entering-longmode.md
index 20f04332..3e627f01 100644
--- a/_posts/2015-08-25-entering-longmode.md
+++ b/_posts/2015-08-25-entering-longmode.md
@@ -12,7 +12,7 @@ I tried to explain everything in detail and to keep the code as simple as possib
 [protected mode]: https://en.wikipedia.org/wiki/Protected_mode
 [long mode]: https://en.wikipedia.org/wiki/Long_mode
 [create an issue]: https://github.com/phil-opp/phil-opp.github.io/issues
-[source code]: https://github.com/phil-opp/blogOS/tree/entering_longmode/src/arch/x86_64
+[source code]: https://github.com/phil-opp/blog_os/tree/entering_longmode/src/arch/x86_64
 
 ## Some Tests
 To avoid bugs and strange errors on old CPUs we should test if the processor supports every needed feature. If not, the kernel should abort and display an error message. To handle errors easily, we create an error procedure in `boot.asm`. It prints a rudimentary `ERR: X` message, where X is an error code letter, and hangs:
diff --git a/_posts/2015-09-02-setup-rust.md b/_posts/2015-09-02-setup-rust.md
index 32fbf729..a810ea38 100644
--- a/_posts/2015-09-02-setup-rust.md
+++ b/_posts/2015-09-02-setup-rust.md
@@ -11,7 +11,7 @@ This blog post tries to setup Rust step-by-step and point out the different prob
 [long mode post]: {{ site.url }}{{ page.previous.url }}
 [Rust]: https://www.rust-lang.org/
 [file an issue]: https://github.com/phil-opp/phil-opp.github.io/issues
-[Github repository]: https://github.com/phil-opp/blogOS/tree/setup_rust
+[Github repository]: https://github.com/phil-opp/blog_os/tree/setup_rust
 
 ## Installing Rust
 We need a nightly compiler, as we need to use many unstable features. To manage Rust installations I highly recommend brson's [multirust]. It allows you to install nightly, beta, and stable compilers side-by-side and makes it easy to update them. After installing you can just run `multirust update nightly` to install or update to the latest Rust nightly.
@@ -79,7 +79,7 @@ We added a new `cargo` target that just executes `cargo build` and modified the
 
 But now `cargo build` is executed on every `make`, even if no source file was changed. And the ISO is recreated on every `make iso`/`make run`, too. We could try to avoid this by adding dependencies on all rust source and cargo configuration files to the `cargo` target, but the ISO creation takes only half a second on my machine and most of the time we will have changed a Rust file when we run `make`. So we keep it simple for now and let cargo do the bookkeeping of changed files (it does it anyway).
 
-[github makefile]: https://github.com/phil-opp/blogOS/blob/setup_rust/Makefile
+[github makefile]: https://github.com/phil-opp/blog_os/blob/setup_rust/Makefile
 
 ## Calling Rust
 Now we can call the main method in `long_mode_start`: