diff --git a/content/news/rsoc-fat32-3.md b/content/news/rsoc-fat32-3.md
index ddb600a24b777ef841bb817989f99ac2e4cd2897..dfa40a7c35bfedf76fa5374cc3a827d0242fd249 100644
--- a/content/news/rsoc-fat32-3.md
+++ b/content/news/rsoc-fat32-3.md
@@ -26,7 +26,7 @@ The next step was to write code to parse [MBR](https://en.wikipedia.org/wiki/Mas
 
 Moving further, the next step was to decide on a FAT32 implementation. Rust provides [read](https://doc.rust-lang.org/std/io/trait.Read.html), [write](https://doc.rust-lang.org/std/io/trait.Write.html) and [seek](https://doc.rust-lang.org/std/io/trait.Seek.html) traits which when implemented for a struct, allows the read, write and seek functions to be called on it. So implementing the three traits for the `MBR` partition was the next goal. Unfortunately the loader is written with no support for the standard library. Instead it is wrtten using a baremetal library called [libcore](https://doc.rust-lang.org/beta/core/) which supports the traits only through the [core_io_crate](https://github.com/jethrogb/rust-core_io). The `core_io` crate requires a specific version of the Rust compiler to compile which breaks the rest of the loader. At first we considered [fatfs](https://github.com/rafalh/rust-fatfs) but it turned out that it depended on the `core_io` crate. Finally we decided on [fatrs](https://gitlab.com/susurrus/fat-rs) as it had it's own trait called a `StorageDevice` which did not depend on any `core_io` traits. The implementation of the trait for the `Partition` struct can be found [here](https://github.com/deepaksirone/redox-loader/blob/master/src/fs/fat32/mod.rs). The `fatrs` library did have a few bugs of it's own which was fixed in this [fork](https://gitlab.com/deepaksirone/fat-rs).
 
-With the FAT32 implementation running smoothly, the final lap had begun which was to load the kernel at address `0x100000` which is the first megabyte of memory, setup the environment including the page tables for the kernel and then transfer control to it. The problem was that the loader stub was currently loaded at the exact same location and the page tables could not be setup exactly as the kernel would have liked because some pages were used by the loader. The fix was inspired by a discussion with [@jackpot51](https://github.com/jackpot51) where we decided that we should initially copy the kernel at address `0x400000` and then drop into real mode as in the previous blog post, to copy the kernel at `0x100000`. Real mode does not have paging and hence all the page tables could be setup exactly like the original [asm bootloader](url_here) does. After this the real mode code jumps to the kernel and begins execution. A primary change which was made to the [real mode code](https://github.com/deepaksirone/redox-loader/blob/master/bootloader/x86_64/kernel_copy.asm) was the introduction of [unreal mode](https://wiki.osdev.org/Unreal_Mode) which ensures that data can be both read and written above the 1MB mark.   
+With the FAT32 implementation running smoothly, the final lap had begun which was to load the kernel at address `0x100000` that is the first megabyte of memory, setup the environment including the page tables for the kernel and then transfer control to it. The problem was that the loader stub was currently loaded at the exact same location and the page tables could not be setup exactly as the kernel would have liked because some pages were used by the loader. The fix was inspired by a discussion with [@jackpot51](https://github.com/jackpot51) where we decided that we should initially copy the kernel at address `0x400000` and then drop into real mode as in the previous blog post, to copy the kernel at `0x100000`. Real mode does not have paging and hence all the page tables could be setup exactly like the original [asm bootloader](url_here) does. After this the real mode code jumps to the kernel and begins execution. A primary change which was made to the [real mode code](https://github.com/deepaksirone/redox-loader/blob/master/bootloader/x86_64/kernel_copy.asm) was the introduction of [unreal mode](https://wiki.osdev.org/Unreal_Mode) which ensures that data can be both read and written above the 1MB mark.   
 
 Currently the kernel is loaded from a FAT32 partition and the rest of userspace i.e. init and friends are still loaded from a RedoxFS partition.