Linux - When "free" is not free
Terry reviews a white paper from Mentor demonstrating why Linux may be the most expensive free OS there is.
Speaker: Terry West
read podcast TRANSCRIPT:
Every week I get all lot of e-mail spam saying download this white paper download this IoT thing or come talk to us about whatever. And I quite frankly, I ignore most of them.
You probably do as well. Probably some of ours even from Serious. But recently, my eye was caught by one and I downloaded a whitepaper from Mentor this past week and it was very well done.
It was written by Kathy Tufto the Senior Product Manager over at Mentor on their Linux platform offering. From what I can gather, they sell and support a Linux distribution. This whitepaper, about 10 pages long, was fascinating. I want to walk you through it a little bit and give you my take on this. This is not me Linux-bashing, so I want to be really clear. I'm not about to start some religious software war or whatever.
In fact, about 15 years ago I was a huge Linux advocate at Intel in the Embedded PC Group. We sold embedded, Pentium-type processors into non-PC applications. At that time Windows was struggling badly with stability and with security. We needed an alternative. As Intel, we were looking for an alternative and Linux looked very promising. And the promise of Linux was not just that it was free, although that was a consideration.
Actually, more importantly at the time was this open source concept. That everyone could see the source code and therefore would be more secure. Unlike Microsoft, where you were just trusting Microsoft somehow to magically make the OS and everything else secure. At that point Windows NT, and some of these operating systems before them, were very security-plagued with viruses. So this promise to the open source community, that everyone could see the code and therefore it would be subject to the scrutiny of thousands if not millions of engineering eyeballs. The promise that these eyeballs would make sure the code was robust and secure was a very attractive one.
At Intel there were a lot of things missing from Linux, at the time, on the PC (whether it was drivers i.e. Ethernet drivers, USB) became a problem where it was available on Linux on Windows but not Linux. There was a little bit of an interesting philosophical war between the Linux community and USB for a while until it did support it. Even graphics wasn't actually supported that well on Linux. Back in the 90s, and now we have Qt and things like that on Linux. So I was part of the team, for quite a while at Intel, that was actually making the compiler better. Making the GCC compiler better and up to snuff with the Microsoft compiler, which at that time was the best on the planet. We made it the free Linux compiler the new compiler, as good as or better, in many cases than the Microsoft compiler. So there were a lot of things in my history where I was very pro Linux. So please don't misinterpret this podcast as being anti-Linux or trying to take some religious position around Linux.
But I do want to make the assertion, based on my experience both pro-Linux and seeing the disadvantages of Linux, that Linux is probably the most expensive free operating system there is. Let me say it again, Linux, in my opinion, is the most expensive free operating system there is for the embedded community.
Now, I don't want to make a judgment around the IT community about things like servers and Web servers and infrastructure. A lot of I.T. groups have chosen to embrace Linux with PHP, MySQL, or similar types of products (i.e. Apache Web servers and free open source software) as the basis for their compute engines in their IT organizations as opposed to Windows and Microsoft based. In those environments where you have teams of people who are responsible for managing business applications, server applications, who are responsible for keeping the networks secure.
In those installations, you either have a public web server, open to the cloud, or you have the internal infrastructure behind a firewall. But in the internal infrastructure, there's a big, huge firewall sitting between the Linux internal network and the outside world. That is well controlled and well managed by the IT group that has their my Sonicwall, Cisco firewall, or whatever brand that happens to be. And there's a team, probably focused on nothing but, making sure that that firewall stays secure, stays managed, and stays tight. There's only so much you can do within the network once somebody gets inside your network. And so there are these firewalls of course. Right?
So there's a big difference between the IT use of Linux (which I'm not arguing at all about for or against) and the embedded use of Linux. The embedded use, where we take Linux and say that same methodology of using Linux in the IT world can somehow apply inside embedded devices (whether it's a thermostat, a room control system, or running a machine, or running an HMI).
At Serious, we've elected not to embrace Linux for a number of reasons. Our reasons are simple:
Linux requires a lot more memory, on average for HMI applications, and a lot more processing power than non-Linux solutions that can virtually do the same thing. Therefore, there is an inherent hardware cost disadvantage with going Linux. You need more memory. Memory, right now especially with all the industry constraints, is extremely expensive.
And therefore Linux inherently is a much bigger system. There are more than 20 million lines of code in Linux today. Now you don't need all of those, but you do need millions and millions and millions of lines of that code. Whereas to do it with a non-Linux solution requires less than a tenth, if not a hundredth, of those lines of code. And that's a significant memory and processing footprint difference that do translate into actual cost structures. So it's cheaper from a SHIPHarbour perspective not to.
My core advice to customers is - if you need the capabilities of Linux or Windows, absolutely they are probably the best thing on the planet for you. The real fundamental question is "do you need those capabilities?" Because if you don't need those capabilities, you're actually adopting a set of challenges, along with Windows and Linux, that you may not want to and may not need to.
Thes Mentor whitepaper I mentioned earlier was interesting. It was it was titled Moving from an RTOS to Linux: Practical Insights Nobody's Telling You. This very smart Product Manager, Kathy Tufto, went through and outlined a number of things. I found it interesting because one of the first things she says is here's a bunch of reasons it makes sense to stay with an artist and not move to Linux. So I was kind of reading this thinking, "Are you trying to convince me not to go Linux? Kathy help me here."
And she does make the memory argument and says although you can shrink Linux down you really won't be able to ever get it to the same point that an RTOS is. The real question is what functionality do you need and what does the memory footprint comparison between those two solutions. And quite frankly, can you bear the price premium of the Linux solution versus the non-Linux solution.
She talks about real time and you know we talk about RTOs because that's the word we use to describe an embedded OS. There really was no originally RTOS (real-time operating systems) were what we called embedded OS because they were invented for real-time applications. Things like motor control or sensor feedback where you had to respond within a millisecond or 20 milliseconds or whatever. Otherwise, something bad might happen. And so we called all those embedded operating systems RTOS (real-time operating systems). The reality is, most artifices are used in non-real-time applications whether HMI or whatever. Maybe there's some loose pseudo real-time you need to respond back to the user when they press something on the screen within 50 milliseconds or it feels like the system is sluggish. Yes, you could argue that's real time, but it's not the old school real time with guaranteed latency to events. Right now there's a lot of systems out there that don't have that. Or if they have those requirements, they bury them down into autonomous little processors that do the IO subsystems and guarantee results. So there are definitely environments where the RTOS the "RT", the real-time RTOS, is important but I would venture to say most applications for RTOS don't use the RT part. What they're actually using as an embedded lightweight OS with all the capabilities you would expect like QS, semaphores, messaging, tasks switching, prioritization, and all those kinds of things.
So Kathy talks about when you need an RTOS, obviously you need an RTOS. There's this fuzzy area when you don't need the real-time capability between that and Linux. There are things you can do through special patches and special distributions to get some level of real-time analytics of course. She then goes on to talk about reusing IP. Now, this is where it gets really interesting because there's this whole section of her document that walks through and over and over says (paraphrasing) yeah you can reuse IP, yeah there's source code out there. But you better have your legal team review this, you better have your legal team review that, you better have a lawyer that understands this, you better have a lawyer that understands Open Source and restrictive licenses.
Based on my experience working at some big companies like Intel and microchip, I would challenge you to first take an honest look at your own legal team and ask how many absolute Linux open source specialists do you have on your legal team. And if the answer is less than one, you have a problem. This is not an engineer who thinks they can talk legal. this is actual IP attorney who understands how to read license agreements and understands what your code is, and how your code is constructed.
Because when you read Kathy's article, one of the things that popped out very clear to me is that if you do not have an absolute legal Linux, Open Source specialist, you are extremely in danger of giving away all your IP. In risk of having to post all your source code on the web so that anybody can get access to your intellectual property. Or even worse, as she points out, there are certain areas of Linux where if you contribute or change anything, any patents you have, any code you have, you actually have to give up IP ownership completely of those. And some of the new licenses like GPL V3, not only require you to post your code on the web. In the past, people used to post the code but not really give you a way of rebuilding it and putting it back into the device. Oh no, they fixed that loophole. GPL V3 says, not only do you as a manufacturer of a device that uses Linux (if you navigate down and use some of this GPL V3 code in a certain way) not only do you have to post all your code on the web. You have to actually provide a vehicle and support for anybody who wants to rebuild your whole codebase. And you must also provide a vehicle for them to download that code into your device and replace the code that you put in your device with their code that they've modified.
So I want you to think about that for a minute.
Let's say you're a car manufacturer and you've decided to use Linux inside the engine controller of your car. And you've used GPL V3 code unknowingly or knowingly. You have to post, not only do you have to post all your code to the Web potentially, you have to provide people a way of rebuilding that code, of reinstalling that code into the car. What happens if somebody has that in their car and they have an accident. Who's who's at fault?
It's an extremely interesting problem. We got here because of a strong desire of the open source community ( and I'm not arguing this pro or con I'm just saying it is) that the open source community believes that software should be free and that all software should be available for people to look at rebuild and install and no one should be allowed to own software.
And I'm not overstating it. That is the expressed goal of the open software movement. The problem here is that it conflicts with commercial interests, like many of us have, where we consider software big on the intellectual property scale. We spend millions every year on our software engineers and our architects to engineer cool software and cool things. Heck no we don't want to give that away; never mind give up all that intellectual property. Nor do we want people to be able to modify that code and download it into our devices and have those devices perform in different ways than we ever intended that might create liabilities for us or support problems in the future.
So this whole concept of licensing is an extremely challenging one and now there are tools to scan your code and all this kind of thing. Of course, you have customize your Linux build, you have the problem of distributing it, of managing it. And so Kathy's conclusion is that if you need Linux, and you need certain capabilities to do with Linux, don't go alone. Go to a Mentor, in her case, and use Mentor as your distribution supplier to take care of a certain amount of elements of this problem.
So let's go full circle back to the beginning: The most expensive free operating system you've ever purchased. I'm not the only one. Here's Kathy over at Mentor making a case that says you're probably going into very dangerous territory if you think Linux is free. If you think you can go down that pathway without buying a distribution, buying support, buying the legal help that you need. The intellectual property help you need, the distribution management help you need, the security help you need to keep it locked down through viruses and malicious attacks.
If you're going to go Linux you must address many of the issues that she's talked about, and probably several others, that she's talked about in her whitepaper. Either you pay someone else to do it or you do it yourself with a fairly expensive team. Either way, it's not free.
"If you're going to go Linux you must address many of the issues that she's talked about, and probably several others, that she's talked about in her whitepaper. Either you pay someone else to do it or you do it yourself with a fairly expensive team. Either way, it's not free."
So I'm not saying don't use Linux in your embedded applications. I'm not saying to use it in your embedded applications. All I'm saying is it's not free. And so if your team is thinking, "Hey this is no runtime licenses this is free. This is easy I can bring it up really quick and I have no cost." I would really encourage you to think again.
Download this white paper from the Mentor site. Really go through and understand "Do you really need Linux?" Because quite frankly there are many capabilities and many applications where an operating system, like Segger, that Serious distributes with our communications and control modules, is perfectly adequate with one one hundredth, if not smaller of the footprint, more security. And we do manage the distribution for you and take care of those issues for you.
So there are alternatives.
I'd be interested in your feedback as always send me a line argue with me if you wish. Thanks.
The challenges of HMI and IoT can be overwhelming. Listen weekly to our Captain – Terry West, CEO – on industry trends he sees and implications for the embedded systems designer.
You'll find practical thought leadership conversations covering all facets of embedded technology, human machine interface evolution, architectural challenges, IoT readiness, and much more.