Minimize the image size of redpesk OS

Dealing of 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 every MB saved matters.

5 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 5 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. this level is 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.