“Linux is Linux is Linux,” is a direct quote I heard in a meeting I had recently with a major multi-national, critical-infrastructure company. Surprisingly and correctly, there was one intelligent and brave engineering executive who replied to this statement, made by one of his team members, with a resounding, “That’s not true.” Let’s be clear, selecting a commercial Linux is not like selecting corn flakes. This is especially true when you are targeting embedded systems. You must be considering key questions regarding the supplier of the distribution, the criticality of the target application, security and life-cycle support for your product.

Choose Wisely

There is a wonderful scene in the movie Indiana Jones and the Last Crusade when our hero, Indiana, must select the true Holy Grail. Set before him is a multitude of cups ranging from opulent, bejeweled challises to simple clay drinking cups. If you have seen the movie, Indiana reasons out the best choice, and it was a life or death selection. The knight who had been guarding the challises for centuries famously says, “You chose… wisely.” Why bring up this iconic scene? When you are selecting a commercial Linux distribution, you have a multitude of choices all bejeweled with wonderful marketing. The bottom line is that you want to save dollars that you would have otherwise spent on a DIY-Linux approach and ensure the commercial Linux selected fits your particular application. Here are some questions that you will need to keep in mind:

• Is this for an IT application?

• Is this for an OT (Operational Technology) application?

• How long will this system be in the field?

• What processes and procedures are used by my supplier to cover security vulnerabilities?

• Can my supplier integrate in other Linux packages that support functionality I need going forward?

This is the short list. Other elements to keep in mind are the specific distribution’s origin and the Open Source community upon which it is based. How important is that specific Linux supplier with regard to the Open Source community upon which the distribution is based? These elements need to be part of the thought process.

I’ll Let My Silicon Choose

Many developers look for a simpler way to make a selection. Why not? “I’ll just select the Linux distribution most implemented by silicon manufacture’s customers.” Not so fast! While it is important to gather input from the silicon providers, not all systems are created equal. Moreover, the silicon providers are mostly concerned with selling silicon, as would we all in the same situation. Software is really not their concern, although CPU providers make a most grave mistake when thinking this way. Silicon suppliers make money when silicon ships in volume. If the associated operating system and Board Support Package (BSP) are not working in a way that allows the system developer to get a device to market, they make no CPU shipments, and no shipments = no revenue. Said differently, when silicon suppliers relegate software to an afterthought, they do not choose wisely.

Security

While I am unable to post about specific situations regarding Linux security problems encountered, it suffices to say that a security vulnerability discovered not long ago had similar life or death consequences as Indiana Jones faced in the scene mentioned. If you are developing systems that simply cannot fail, you need to examine the software security at initial architecture stage, next the Linux supplier’s security update capability throughout the system’s life, and your supplier’s ability to deliver security patches in a timely manner once systems are fielded. These are major-league issues. If a medical device fails or a critical industrial system fails because your software OS was not properly supported from a security standpoint, you need to be prepared for your company to appear on the front page of the Wall Street Journal. Every senior executive loses sleep over the possibility of a hack that makes news due to loss of life or an unexpected explosion that results in a precipitous drop in stock value. Does this sound extreme? You bet it does, but it happens, and with the rise in Linux security vulnerabilities increasing exponentially each year, it can happen to you. So take the proper precautions and look for a Linux distribution that covers vulnerabilities and a company that can turn around fixes quickly when needed.

Life-Cycle Support

If I am developing a system that will be in the field a short time, life-cycle support might not be high on the list of priorities. However, developing embedded systems that make use of expensive, cutting-edge hardware need to be upgradable, and your company will want that design to last a long time in the field. Sure, the casing or user interface software will periodically be upgraded, as they should, but specific systems needs to be in the field for ten or more years. It is simply too expensive to spin a system development every few years in specific vertical markets. These markets include medical, energy, industrial, telecom and other verticals that can have expensive system developments and need to last. So in these instances, be thinking about the commercial Linux you are selecting as one that you will need to upgrade, patch and ensure security for over a long period. Does your supplier do that? Has the Linux supplier you are selecting even existed for ten years?

Conclusions

Many view discussions about Linux as old problems, and that regardless of the commercial supplier chosen, they are covered. Well, I am here to tell you that not only are these problems not old but current, they are also urgent. Thanks to ever-increasing CPU horsepower, more and more edge devices are using Linux. There is good reason for this. Linux is open-source, flexible and by definition supported by a community of developers. While the rise of Linux has been good for the industry, we must recognize that the systems for which we are responsible have special requirements, and this is particularly true in embedded Linux. So, my advice? Choose wisely!