content: Fix local image paths

The images should be searched in the /blog instead of the root
of the page url.

Signed-off-by: Matheus Castello <[email protected]>

content/software-testing-the-hardware-software-interface.md

@@ -8,7 +8,7 @@ tags: ["Testing", "Embedded", "Linux", "Embedded"]
 
 abstract: A series about Embedded Software Testing.
 
-image: /tivoli-waterfalls.png
+image: ./tivoli-waterfalls.png
 ---
 
 This series of blogposts will deal with embedded software testing. I want to pass on to the reader the hard-earned
@@ -169,7 +169,7 @@ if you have many interconnected systems developed by different teams, because it
 There are some strategies such as bottom-up and top-down during the development phase to ensure a smooth integration of
 different systems, and I'll talk more about it in the next parts of this series.
 
-### End-to-end Testing 
+### End-to-end Testing
 
 End-to-end testing - sometimes abbreviated as e2e - makes the black box out of the connection of several integrations.
 Say a software like `nmcli` is used to control the network cards in a connected system and that connection in turn is used
@@ -213,7 +213,7 @@ impact in the system development process.
 
 The good news is that, if you have testing, it is immensily - I can't overstate how much - easier to refactor whole projects.
 When you start refactoring - or adding things to the software - you really see the 'regression protection' testing gives
-you shine. 
+you shine.
 
 Say a customer needs another sensor attached to the equipment. No problem! You write the code for that specific sensor,
 write the tests for that sensor and run the whole test suite: that guarantees that when you added this new sensor, you
@@ -226,9 +226,9 @@ of the system.
 
 ### Release Early, Release Often, Make Returns Early, Make Returns Often
 
-This ties very well together with the "Release early, release often" mentality that is coming to Embedded. 
+This ties very well together with the "Release early, release often" mentality that is coming to Embedded.
 
-Let's say Company A is a developer that buy some Toradex modules, develops and application with Torizon and sells it to 
+Let's say Company A is a developer that buy some Toradex modules, develops and application with Torizon and sells it to
 the Portuguese market.
 
 Turns out Customer B of Company A is actually moving some of these devices to Brazil, where they write Portuguese but

content/wait-my-container-is-crashing-before-startup.md

@@ -8,7 +8,7 @@ tags:
     - Embedded
     - Linux
 abstract: How to implement container startup sync so that your application doesn't crash due to inter-container communication errors
-image: /concurrent-container-startup.png
+image: ./concurrent-container-startup.png
 ---
 
 When [using more than one container in a project](https://developer.toradex.com/torizon/application-development/working-with-containers/using-multiple-containers-with-torizoncore/), a probable scenario developers are faced with is startup errors due to a lack of inter-container app synchronization.
@@ -281,16 +281,16 @@ services:
 
   app:
     image: influxdb:2.7.5
-  
+
   database:
     image: influxdb:2.7.5
-  
+
   visualization:
     image: grafana/grafana:10.2.3
-  
+
   graphics:
     image: torizon/weston:3.2.2
-  
+
   gui:
     image: torizon/chromium:3.0.2
 ```
@@ -373,19 +373,19 @@ services:
 
   app:
     image: influxdb:2.7.5
-  
+
   database:
     image: influxdb:2.7.5
-  
+
   visualization:
     image: grafana/grafana:10.2.3
-  
+
   graphics:
     image: torizon/weston:3.2.2
     healthcheck:
       test: ["CMD-SHELL", "test", "$$WAYLAND_DISPLAY"]
       start_period: 5s
-  
+
   gui:
     image: torizon/chromium:3.0.2
     depends_on:
@@ -420,19 +420,19 @@ services:
 
   app:
     image: influxdb:2.7.5
-  
+
   database:
     image: influxdb:2.7.5
-  
+
   visualization:
     image: grafana/grafana:10.2.3
-  
+
   graphics:
     image: torizon/weston:3.2.2
     healthcheck:
       test: ["CMD-SHELL", "test", "$$WAYLAND_DISPLAY"]
       start_period: 5s
-  
+
   gui:
     image: torizon/chromium:3.0.2
     depends_on:

content/why-bare-metal-debian-and-raspberry-pi-os-is-not-a-good-choice-for-most-embedded-systems.md

@@ -8,7 +8,7 @@ tags: ["Debian", "Yocto", "Container", "Embedded"]
 
 abstract: It works until it doesn't.
 
-image: /no-debian-in-my-fleet.png
+image: ./no-debian-in-my-fleet.png
 ---
 
 Quite a few embedded vendors nowadays ship Debian or some derivative by default, specially for the hobbyist sector, but I don't think people realize that there isn't an expectation that Debian will be their *production* operating system, and when with 'production' I don't mean one or two devices: by all means, if that's your scale, continue using Debian in pet machines instead, that's very much fine.
@@ -20,7 +20,7 @@ This is not a ode to tools like buildroot or Yocto, but the available Debian too
 
 ### Debian is not immutable
 Immutability (ie, updates are new snapshots applied on top of a read-only filesystem) is necessary to make sure you have the same revision in the lab as you have in the field, because if you think issues won't show up, they absolutely will. And sending out engineers out into the field or getting some boxes back into the office can be very, very expensive.
-Debian... is not immutable (by default[^0]). 
+Debian... is not immutable (by default[^0]).
 
 So the strategy a lot of people take is: get a 'master', good revision image and use an A/B partition system to switch between revisions. That's generally ok and safe, but it's not very optimized for space. Most immutable distros rely on filesystem tree trackers like ostree, which can be much more efficient (having a single partition is pretty awesome).