[JoshTriplett]

Leaving aside other reasons to use it (userspace/kernel separation, better security and isolation, Rust)...

Almost anything is a better choice than FreeRTOS. FreeRTOS has a not-quite-open-source license, a modified version of the GPL with a clause that makes it non-free and GPL-incompatible.

FreeRTOS isn't Free Software. "OpenRTOS", the version you get if you pay for a non-copyleft license, isn't Open Source. What does that say about "SafeRTOS"?

[Kelbit]

I don't think most users of FreeRTOS particularly care about the somewhat wonky license. It certainly hasn't damaged its commercial adoption.

FreeRTOS' license is GPLv2 plus an addendum to permit its incorporation in commercial products. FreeRTOS allows you to statically link your own modules as long as you don't modify the FreeRTOS kernel. If you do modify the kernel, you have to contribute back upstream.

The wording of the license is somewhat troublesome which makes it GPL-incompatible (see: https://opensource.stackexchange.com/questions/4676/is-it-wr...), but the developers have been very clear as to the spirit of the license in many public forums: you can use you own code alongside FreeRTOS and link it into a binary blob, but if you modify the kernel, share your changes. The no-benchmarking clause is sort of annoying, but really isn't a showstopper for most people.

FreeRTOS is intended for use on severely resource-constrained embedded systems where you have a few kB of RAM. Most people developing in that sort of environment don't really care about the existence of a benchmarking clause that probably won't get enforced anyway.

[JoshTriplett]

The benchmarking clause itself is a moot point. The fact that it makes the software proprietary and GPL-incompatible is the main issue.

For much the same reason, the infamous "this software shall be used for good, and not for evil" clause isn't just problematic for people who worry that their actions will be deemed "evil".

[TickleSteve]

I've always had good experiences with FreeRTOS (and friends). It works well, is well supported, works on a wide variety of platforms.

The real security in Tock comes from the use of the MPU which can also be done in FreeRTOS. The use of Rust is nice for application-robustness, but does not enhance security over the equivalent in C.

[JoshTriplett]

> The use of Rust is nice for application-robustness, but does not enhance security over the equivalent in C.

C-with-MMU doesn't help you avoid overrunning buffers, leaking memory, using memory after freeing it, returning pointers to stack objects, getting reference counts wrong, or many other issues. And C doesn't provide nearly as many facilities for abstraction without overhead.