
Tock Embedded Operating System - rayascott
https://www.tockos.org/
======
SandmanDP
Just briefly reading through the specs, I can't see any reason why someone
would want to use this over FreeRTOS unless they have a Rust-based embedded
system project. Is there something I'm missing here?

~~~
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...](https://opensource.stackexchange.com/questions/4676/is-it-wrong-to-
call-a-software-open-source-if-it-is-using-a-license-based-on-gnu)), 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".

------
kevin_thibedeau
The targeted systems rarely have an MMU. How can this provide any real
isolation?

~~~
baobrien
Arm Cortex M3 and up cores usually have 'Memory Protection Units'. The MPU
allows you to set permissions on memory regions and gives basic
kernel/application isolation.

------
hacknat
> designed for running multiple concurrent, mutually distrustful applications
> on low-memory and low-power microcontrollers.

Can someone suggest a realistic use case?

~~~
twic
A controller in a device manufactured by a large and dysfunctional
corporation, where the different bits of the software are written by different
teams who don't trust each other, and aren't trusted by the team which
integrates the product?

~~~
_pmf_
That's a very apt description of an automotive OEM's development model.

------
mcguire
The Hail development board is $60 and the imix will be $100. This seems
somewhat expensive compared to other options. Any idea why it's more?

~~~
elcritch
Nothing special about the boards. They're likely just small runs and so don't
have a lot of units to amortize development and setup costs over.

