Minimizing the image size of redpesk OS

Dealing with the size of redpesk OS is important when you are in a restricted environment (e.g sometimes you may have a small memory storage). Here’s why it matters:

• Faster boot time:
  • A smaller image means fewer files and less data to load into RAM.
  • Reduces storage read time (especially important for flash memory and SD cards).
  • Less kernel and initrd overhead leads to faster system initialization.

  Example: A 50MB image boots faster than a 500MB image on the same hardware.

• Reduced storage usage:
  • Embedded systems often use limited storage (eMMC, NOR/NAND flash, SD cards).
  • A smaller OS extends the lifespan of flash memory by reducing write cycles.

  Example: Some industrial devices use only 256MB or 512MB flash storage, so each MB saved matters.

Five levels of optimization

Splitting the problem into five levels of optimization is a smart approach because it provides a structured, incremental way to minimize the redpesk OS image size while maintaining control over system functionality. Here’s why this method is effective:

• Progressive optimization instead of one big change
  • If you try to remove everything at once, you risk breaking critical functionality.
  • By defining incremental levels, you can test and verify each step before moving further.
  • This avoids situations where you remove too much and end up with a non-booting system.
• Easier debugging & issue tracking
  • If something goes wrong, you can identify at which level the issue was introduced.
  • Each level acts as a checkpoint, making debugging faster and easier.
  • You don’t have to start from scratch if a problem appears—you just roll back one step.
• Measuring the impact of each change
  • By separating the problem into levels, you can measure how much size and boot time improvement each step provides.
  • Helps in making data-driven decisions rather than guessing.
  • Some optimizations might give little benefit but cause big issues, so you can avoid unnecessary changes.
• Flexibility for different use cases
  • Not every system needs the most minimal image.
  • Some applications may still need development tools or part of the redpesk framework.
  • By defining levels, different teams can choose the appropriate level of optimization.

We define five levels of optimization:

• level 0: the standard image.

• level 1: the standard image with a few modifications (e.g., adding systemd-bootchart, removing i2c-tools, etc.).
  • Justification: this level makes minimal changes, mainly for debugging and initial analysis of size impact.
• level 2: image without development tools, close to the redpesk industrial image.
  • Justification: removing development tools (gcc, gdb, make, etc.) reduces the image size and makes it more production-oriented.
• level 3: image without the redpesk framework, allows evaluating the cost of using the redpesk framework in terms of size and boot time.
  • Justification: measuring the impact of the framework helps decide whether it is necessary for the target system.
• level 4: ultra-minimal image (e.g., removing python3-firewall, NetworkManager, etc.), allows evaluating the board’s boot time capacity.
  • Justification: removing non-essential services and dependencies provides a baseline for minimal boot time performance.

Each level is based on the previous one so you can adjust these methods to your needs.