diff --git a/doc/lab03-silly_led/main.typ b/doc/lab03-silly_led/main.typ
index 3c2b504..906434d 100644
--- a/doc/lab03-silly_led/main.typ
+++ b/doc/lab03-silly_led/main.typ
@@ -26,7 +26,7 @@ syslog(LOG_INFO, "Start logging silly led-controller"); // INFO level
 The most difficult part was understanding the #gls("gpio", long: false) mapping between the physical pins and the #gls("sysfs", long: false) #gls("gpio", long: false) numbers. This mapping can be found in the #link("https://linux-sunxi.org/GPIO", [*sunxi driver*]) documentation, which describes the driver for the #gls("gpio", long: false) controller.
 
 == Results
-We can demonstrate that the application works more efficiently than the provided silly #gls("led", long: false) controller:
+We demonstrate that the application works more efficiently than the provided silly #gls("led", long: false) controller:
 
 #table(
     columns: (1fr, 1fr),
@@ -46,4 +46,4 @@ We can demonstrate that the application works more efficiently than the provided
     ]
 )
 
-We can see the difference between @fig-silly and @fig-epoll. One utilizes 100% of a CPU core, whereas the other does not.
+We see in @fig-silly, the silly #gls("led", long: false) controller use 100% of the #gls("cpu", long: false) in @fig-epoll we save CPU resources.
diff --git a/doc/lab04-multiprocessing/main.typ b/doc/lab04-multiprocessing/main.typ
index 4ca8876..567b392 100644
--- a/doc/lab04-multiprocessing/main.typ
+++ b/doc/lab04-multiprocessing/main.typ
@@ -44,6 +44,9 @@ static void catch_signal(int signal) {
 
 }
 
+#pagebreak()
+
+```c
 static void install_catch_signal()
 {
     struct sigaction act = {
@@ -227,7 +230,11 @@ With these prerequisites met, we can create two groups, one for each instance of
 |> mkdir /sys/fs/cgroup/cpuset/low
 |> echo 1 > /sys/fs/cgroup/cpuset/low/cpuset.cpus
 |> echo 0 > /sys/fs/cgroup/cpuset/low/cpuset.mems
+```
 
+#pagebreak()
+
+```bash
 # Create and allocate CPU for program "high"
 |> mkdir /sys/fs/cgroup/cpuset/high
 |> echo 2,3 > /sys/fs/cgroup/cpuset/high/cpuset.cpus
@@ -246,7 +253,7 @@ We can then open two shells and run the test program in each of them, while addi
 As shown in @max-cpu, as expected, both processes in the "low" program are limited to #gls("cpu", long: false) core 1, while the "high" program uses #gls("cpu", long: false) cores 2 and 3 (one for each process).
 
 #figure(
-    image("max-cpu.png"),
+    image("max-cpu.png", width: 90%),
     caption: [CPU usage of the two programs with dedicated resources]
 )<max-cpu>
 
@@ -268,6 +275,6 @@ After running the test program in each shell, we can observe in @shared-cpu that
 
 
 #figure(
-    image("shared-cpu.png"),
+    image("shared-cpu.png", width: 80%),
     caption: [CPU usage of the two programs with shared resources]
 )<shared-cpu>