Hacker News Reader

Comment by pjmlp | Hacker News Reader

> Today, we observe almost universal failure in compliance throughout the (so-called) Internet of Things (IoT) market. Only unrelenting enforcement that holds companies accountable can change this abysmal reality.

Which is why Linux on embedded is facing competition full of non-copyleft based OSes.

NutXX, RTOS, Azure RTOS, mbed, Arduino, Zephyr (ironically from Linux Foundation partners), Fuchsia, ....

View on HN

You're missing thee point of why at least half of the operating systems (if you can call them that) in your list exist. FreeRTOS and Azure RTOS (formerly ThreadX) are hard realtime microcontroller operating systems that are designed to squeeze into as little as 32kB Flash and a few kB RAM. Their capabilities are a far cry from what Linux offers. They complement each other instead of competing.

Those issues are orthogonal to them not being GPL friendly.

FreeRTOS is MIT licensed, Zephyr is Apache 2.0 licensed. You just can't get any more GPL friendly in that space.

On the contrary, they are non-copyleft, thus no upstreaming required, just as OEMs love to have their free beer OSes.

Neither FreeRTOS nor ThreadX/Azure RTOS can really accept random patches. These systens are certified for use in highly safety critical applications (think railways, nuclear reactors, chemical plants...). To keep that certification, either the whole OS must be recertified after a change or an impact analysis and extensive testing are performed for each and every minor patch. Most random hackers won't be able to deliver any of that along with their patches. It requires resources few have access to.

To give you an example, I had access to the complete ThreadX source code a while ago as my employer back then was a licensee. Making functional changes to that code was a complete no go because that would instantly invalidate its certification and put the onus of recertification on us. And we wouldn't have been able to pull that off at all.

Given those restrictions, the actual software license barely matters.

>Neither FreeRTOS nor ThreadX/Azure RTOS can really accept random patches.

BS, both have certified "edition" but the "normal" version is not, you can start today send patches for RTOS in.

https://github.com/FreeRTOS/FreeRTOS-Kernel

Do you think the certified editions are fundamentally different from the normal ones? Hint: they aren't. Certified means that these are the exact revisions they handed in for certifications. It's just not realistically possible to get full certification for every release in a fast cycle because the time and effort needed is too high. But they still take on full responsibility for each and every patch going into the codebase.

>Do you think the certified editions are fundamentally different from the normal ones? Hint: they aren't

Sometimes they are different (FIPS enabled etc), but that does not stop you working on that project.

>But they still take on full responsibility for each and every patch going into the codebase.

That's how ~every single OSS project works.

I've yet to see a certified source code that's different from the non-certified version. I've looked at the ThreadX sources on Github and I see no difference to what I had access to at my previous employer.

I've also gone through the Github history of the FreeRTOS project. The only merged PR that I could find that was not made by a FreeRTOS team member and touched the kernel was a series of whitespace changes.

The BSDs are the obvious 'copycenter' alternatives to GNU/Linux, not sure if they have any traction in IOT though.

I am thinking that it is somehow ironic that parent managed to not list a single linux competitor... The alternatives he mentioned are not posix compilant. Instead they are extremely lightweight MCU OSes which serve a completely different role.

They are competitor in the sense of free beer OS that does the job.

Being POSIX compatible is hardly something that most IoT vendors care about.

I thought that would be more because of the Linux bloat + security risk. I don't think it makes much sense to use Linux in the embedded space, but something that is 100x smaller.

I certainly wouldn't want self-driving car systems to be powered by Linux...

From a stability perspective I would. Linux had much more time to harden than comparable OS. From a technical perspective it isn't a real time OS and does come with unnecessary functions that are probably not relevant to the application, but I think people underestimate the amount of bugs in embedded systems. Minimal OS or bare metal doesn't really matter much.

To my knowledge there was never an incident where common OS was responsible for failure, but it has been a myth for ages.

If it does fail it is probably due to a hardware defect, but a risk analysis would show a plethora of possibilities for fail safe systems.

GPU drivers aren't going to run on microcontrollers. If the processor isn't running Linux then it will run something equivalent like BSD.

Reply on news.ycombinator.com