Every electronic product designer eventually arrives at the same question: what operating system should the new solution be based on? You have already determined that you need some sort of Linux, for its ease of development, compatibility and reliability, but which Linux exactly? The answer will have far-reaching consequences for your software developers, legal teams and most importantly, the future lifecycle of the product itself. As always, choosing the right tool for the job can make a world of difference. In this article, we will compare the two most popular paths our team takes in different projects.
What is Debian?
Debian is a free, open-source Linux distribution known for its stability, security, and strong commitment to free software. First created in 1993, today it is the basis for many popular desktop Linux distributions such as Ubuntu, so there’s a good chance you have used it before. The philosophy behind the project prioritizes stability of software over staying on the bleeding edge of the newest package versions. This makes it a popular choice for embedded systems, where there’s no need for frequent updates and user experience could suffer greatly from bugs in unproven, experimental code.
When to choose Debian?
Being a general – purpose system Debian is extremely easy to use for your developers, even with no embedded background. Packet managers, compilers and all the tools they are used to working with can usually be installed on the target machine just as easily as on their own PCs.
Imagine that your product is an AI-powered thermostat with a touchscreen. The team decided to use a standard web-framework running in a headless browser to create a graphical user interface prototype and python backend for AI stuff. UI developers can quickly experiment with different npm packages and libraries. AI-engineers use pip to get whatever python library they need at a given moment. They both run remote VS Code sessions directly on the prototype to quickly iterate changes and test ideas.
At the same time, other members of the team write and debug hardware drivers responsible for talking to sensors and temperature controllers. All of this is possible because the system running on your prototype is a full-fledged, general-purpose Linux distribution.
What are the disadvantages of Debian?
As they say, too many cooks spoil the broth. Having all that flexibility comes at a cost and tiny, ARM processors and flash drives inside IoT devices are far less tolerant of clutter than your average PC. Modern general-purpose distributions such as Debian come with tons of software modules you will never use in such a constrained device. The device might become sluggish and unresponsive. You might have to spend far too much on memory chips than is really necessary just to accommodate all that bloat. As the project progresses, another aspect becomes apparent – reproducibility.
The problem of reproducibility
Modern software solutions get developed by multi – person teams with different environments on their computers. Not everything gets documented or discussed.
People fail to write down exact versions of libraries they use. Deployment scripts stop working. Development devices get lost or broken. Ownership rights get transferred.
Typically, in the embedded space, a developer customizes the ‘raw’ image from a Debian repository with some bootstrap script that installs business logic programs, drivers, and libraries using standard tools like apt. They then store this image in the form of an ISO file and write it to each new device.
Often, the next step is to further alter the device memory with tools like Ansible to provision access credentials or client-specific branding graphics. All these steps make a lot of assumptions about what the device system consists of and can be broken by an update or minor library change.
This creates a problem in situations where we need to update thousands of old devices to accommodate a new feature. One of our projects involved updating a few thousand 20 – year old devices to accommodate a new feature. To our horror we discovered that documentation covered only the source code of the application itself with no clues about operating system, libraries or even version of the on – device sql server. The original developer, who retired years earlier, took the institutional knowledge with him, and someone repurposed his build server. What could have been a quick code update turned into a month-long reverse engineering project.
Situations like this were surprisingly common and led to the silicon industry giants starting the Yocto Project.
What is Yocto Project
Yocto is a set of tools and processes to create custom, fully reproducible Linux distributions tailored specifically to the project’s requirements. This means you are not using a pre-built one-size-fits-all operating system but rather something unique to you. Yocto – based systems tend to be blazingly fast, even on most low-end hardware. The bitbake build system creates the system image by utilizing ‘recipes’—in which each library, program, and utility is represented—with clearly stated requirements, dependencies, license, and outputs. Users organize these recipes into layers that they can easily integrate into a project. This lets you keep track of every single software component inside your device, enabling you to re-create it from a simple collection of text files.
Hardware layers are usually provided by silicon vendors, ensuring full compatibility with the given platform. An example of such a layer can be found at nxp-imx github. Utilities and applications are provided in the recipe index. Of course, nothing stops you from creating your own recipes and patches meant for your new device.
This comes with the bonus of easy integration with Over The Air update providers like Mender, which prepares drop-in OTA layers for Yocto.
The build system automatically detects missing dependencies and conflicts. For example, let’s take a look at mariadb-native (mysql successor) recipe:
require mariadb.inc
inherit native
PROVIDES += "mysql5-native"
DEPENDS = "ncurses-native zlib-native bison-native libpcre2-native \
libxml2-native gnutls-native fmt-native \
"
RDEPENDS:${PN} = ""
PACKAGES = ""
EXTRA_OEMAKE = ""
do_install() {
oe_runmake 'DESTDIR=${D}' install
install -d ${D}${bindir}
install -m 0755 sql/gen_lex_hash ${D}${bindir}/
install -m 0755 sql/gen_lex_token ${D}${bindir}/
install -m 0755 extra/comp_err ${D}${bindir}/
install -m 0755 scripts/comp_sql ${D}${bindir}/
install -m 0755 strings/uca-dump ${D}${bindir}/
}
As you can see, for a successful build, it needs, among other `zlib-native` and provides `mysql5-native`. `zlib`, on the other hand, is provided by OpenEmbedded Layer Index – zlib/
By tracking this dependency tree, Bitbake makes sure your final image has only the necessary elements and nothing more.
Re-creating the 20-year-old project mentioned above with Yocto would be as easy as pulling one git repository and running bitbake my_project_name.
Your legal team will surely appreciate the automatic tracking, collection, and validation of licenses of software used in your project. After all, no one wants to get entangled in legal disputes with license holders or be forced to publish their entire codebase to avoid lawsuits.
There’s no guarantee that no such GPL-licensed element is left in Debian, Ubuntu, or any pre-built system.
Disadvantages of Yocto
Since Yocto is not a Linux distribution but rather a set of tools to make one, there’s no single pre-built image you can just flash into your device memory. Most recipes require building from source code, leading to very long build times. There’s no apt repository equivalent serving you pre-build packages.
One of your developers wants to try a new version of a library? It might take a few hours of build time before it’s available. As always, you are trading development velocity for target product speed and reliability.
Of course, the build process also requires active oversight, so your team will need a developer dedicated to managing it. Luckily, from our experience, most C and C++ developers are eager to take that responsibility. Unfortunately, BitBacke’s build system is not trivial to use or easy to learn, so it will take some time before someone with zero experience becomes proficient in it.
Another question is the lack of security updates. By choosing an LTS version of Debian, you make sure that someone else patches most vulnerabilities for many years. Unfortunately, in your custom-made Yocto distribution, it’s entirely your responsibility.
Yocto vs Debian - a comparison
| Yocto | Pre-built system (such as Debian) |
|---|---|
|
Tailored for your device |
Tools and frameworks available in seconds |
|
Installing new software takes effort |
Tailored for your device |
|
Fast |
Wide compatibility |
|
Easy to track and reproduce versions |
Easy to track and reproduce versions |
So which one should I use - Yocto vs Debian?
If you are building an MVP, Proof of Concept, or any device based on a really powerful yet standard physical platform, go with Debian. Nothing beats the speed of development on such a proven and universal system. Google was still using homemade LEGO racks and RadioShack motherboards when it first presented the search index to investors.
If your future product needs deep integration with custom hardware, low cost components constrain it, exotic hardware with no upstream support limits it, or it has tight performance requirements, choose Yocto first
Whether you’re at the MVP stage or planning final product deployment, getting the OS foundation right is crucial. Our embedded systems engineers specialize in both Yocto and Debian ecosystems, ensuring you select and implement the most efficient long-term solution. Ready to discuss your embedded challenge? Contact us to explore how a tailored Linux strategy can accelerate your project’s success.
