stivale VS tock

I believe it's from here https://github.com/Andy-Python-Programmer/stivale

This whole rant is uninformed & it seems like the author is completely ignorant of anything happening outside his well.

But I'll bite the Rust rant anyway.

> Where's your SSL?

Right here: https://www.memorysafety.org/blog/rustls-server-perf/

It's an order of magnitude faster than OpenSSL, and almost double the speed of BoringSSL.

> Where's your operating system?

There are lots of OSes written in Rust, but nobody expects them to replace a well-established piece of software like Linux. That's why it's shining in the embedded sector, with stuff such as Tock: https://github.com/tock/tock, or many, many other OSes available today. Oxide Computers uses Rust, Volvo writes a lot of their systems in Rust. I also know a few unnamed MIC companies in Turkey using Rust for their software. Anduril also uses Rust.

Rust also runs the Internet, Cloudflare is primarily Rust and AWS is one of the biggest users of Rust. So many more examples but these are the biggest.

Half my environment is Rust: Helix/Zed my editors, my version control system (jj), my shell (nushell), my Window Manager (niri), the build system I'm working on in Rust to build it all, Firefox which is partially Rust, and I actually enjoy using these greatly, because they're fast, well designed and secure.

Has the author written anything in his life that's not games or toys?

TL;DR: No. Maybe? Depends.

It's probably reasonable to make a distinction between "Real Time" desktop/server OS (on CPUs) vs "Real Time" embedded hardware OS (on MCUs).

(Even aside from any hard-/soft- real time distinction.)

On the embedded side, in addition to FreeRTOS (upon which Pebble OS is built), I'm aware of others with reasonably high profile such as:

* Zephyr (Linux Foundation, C): https://en.wikipedia.org/wiki/Zephyr_(operating_system)

* NuttX (Apache Software Foundation, C & C++): https://en.wikipedia.org/wiki/NuttX

In addition, there's also some "up & coming" Rust language projects which fall somewhere along the "framework" to "OS" spectrum (in part, via https://arewertosyet.com):

* Tock: https://github.com/tock/tock

* Embassy: https://github.com/embassy-rs/embassy

* Hubris: https://hubris.oxide.computer

On the desktop side, I seem to recall in the past, OS such as BeOS & QNX have been presented as a possible future for real time desktop OS that hasn't arrived.

As someone else already mentioned, PREEMPT_RT being merged for Linux is a recent development somewhat in this space which could have impact on both desktop & "embedded" situations but suitability varies dependent on, say, whether you're wanting to use it for audio production versus controlling some 10 tonne robot operating next to humans.

Hope this at least goes some way to answering your question. :)

Hi! This is Daniel from OxidOS Automotive (stating this for disclaimer purposes).

Yes, our OS is based on TockOS, and our CEO (Alex Radovici) is #7 in the contributors list (https://github.com/tock/tock/graphs/contributors), with other colleagues contributing in the past years.

I'm definitely not the best person to answer this, but honestly it's not bad. Here's an example of a moderately complex peripheral, the cortex-m MPU, and how one rust OS handles it:

https://github.com/tock/tock/blob/3a0527d586702b8ae8cb242391...

Reads and writes turn into volatile reads, so everything works out under the hood. You get the benefits of everything having good names, declared sizes, and proper typing on your register accesses. You can extend that to bit accesses as well.

Rust still has a few areas it isn't competitive in, like your hyper limited or obscure chips (e.g. 8051s, XAP), mature tooling around formal methods, and a certification story for safety critical code. People are working on these latter two issues (e.g. ferrocene) and supposedly very close to public delivery, but you know how slow the industry is to adopt new things even then.

There's Tock (https://www.tockos.org/), which is written in Rust (with sprinkles of assembly).

Yeah, and I like I mentioned in the earlier comment, omitting the frame pointer reduces code size by 10% on RISC-V targets, which is huge when dealing with embedded flash: https://github.com/tock/tock/pull/1660