Oxide on My Wrist: Hubris on PineTime was the best worst idea
1–10 of 51 posts
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#2See Tock OS https://www.tockos.org/ for another Rust-based embedded OS with a fairly comparable design to Hubris. The debugging capabilities of Humility make an interesting comparison to what's provided by cargo-embed https://probe.rs/docs/tools/cargo-embed/ and the Knurling Tools https://knurling.ferrous-systems.com/tools/ by Ferrous Systems.
Ultimately, the embedded space (including all sorts of low-level, retro, "bare-metal", remote etc. programming) has common needs and it would be convenient to see more widespread cooperation among these projects, improving reliability and avoiding wasteful duplication of work. More resources at https://github.com/rust-embedded/awesome-embedded-rust
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#3See Tock OS https://www.tockos.org/ for another Rust-based embedded OS with a fairly comparable design to Hubris. The debugging capabilities of Humility make an interesting comparison to what's provided by cargo-embed https://probe.rs/docs/tools/cargo-embed/ and the Knurling Tools https://knurling.ferrous-systems.com/tools/ by Ferrous Systems. Ultimately, the embedded space (including all sorts of low-level, retro, "…
People often have good reason to not adopt existing systems. Oxide started with TockOS and have written and talked about why they didn't end up using it.
This twitter space goes into a lot of detail: https://www.youtube.com/watch?v=cypmufnPfLw
But at the end of the day, no_std will allow a bigger ecosystem and sharing between many of these projects.
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#4See Tock OS https://www.tockos.org/ for another Rust-based embedded OS with a fairly comparable design to Hubris. The debugging capabilities of Humility make an interesting comparison to what's provided by cargo-embed https://probe.rs/docs/tools/cargo-embed/ and the Knurling Tools https://knurling.ferrous-systems.com/tools/ by Ferrous Systems. Ultimately, the embedded space (including all sorts of low-level, retro, "…
People often have good reason to not adopt existing systems. Oxide started with TockOS and have written and talked about why they didn't end up using it. This twitter space goes into a lot of detail: https://www.youtube.com/watch?v=cypmufnPfLw But at the end of the day, no_std will allow a bigger ecosystem and sharing between many of these projects.
Thing is, it's not even clear that their added elements are all that sensible. If you're always running trusted tasks on your embedded hardware, what do you need the MPU for? Even in principle, it can only save you a bounds check. And if you start running outside code, then the clear privilege separation in Tock between trusted "Capsules" and other "Tasks" starts looking plenty attractive. Even OP notes that this MPU business introduces severe overhead.
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#5Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#6I love projects like this. I've considered getting a smartwatch. Something like this makes the idea more appealing. Whats the most hackable watch? Is there a pinephone of smartwatches?
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#7I love projects like this. I've considered getting a smartwatch. Something like this makes the idea more appealing. Whats the most hackable watch? Is there a pinephone of smartwatches?
There is! And it's even featured in this article!
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#8I love projects like this. I've considered getting a smartwatch. Something like this makes the idea more appealing. Whats the most hackable watch? Is there a pinephone of smartwatches?
The article is about running Hubris on the PineTime. Quite literally the Pinephone of watches.
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#9Earlier quoted context omitted.
People often have good reason to not adopt existing systems. Oxide started with TockOS and have written and talked about why they didn't end up using it. This twitter space goes into a lot of detail: https://www.youtube.com/watch?v=cypmufnPfLw But at the end of the day, no_std will allow a bigger ecosystem and sharing between many of these projects.
Thing is, it's not even clear that their added elements are all that sensible. If you're always running trusted tasks on your embedded hardware, what do you need the MPU for? Even in principle, it can only save you a bounds check. And if you start running outside code, then the clear privilege separation in Tock between trusted "Capsules" and other "Tasks" starts looking plenty attractive. Even OP notes that this MPU…
The real question is what is the correct risk tolerance, there are many degrees in here with trade offs. If I mostly trust the other programmers then I'm just concerned about mistakes. If I'm running code that might have been written by some evil cracker trying to do some evil then I need more protection.
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#10The github repo of hubris [0] is very nice, as they immediately tell you where what is, e.g.
drv/ contains drivers, a mix of simple driver lib crates and fully-fledged server bin crates. Current convention is that drv/SYSTEM-DEVICE is the driver for DEVICE on SYSTEM (where SYSTEM is usually an SoC name), whereas drv/SYSTEM-DEVICE-server is the server bin crate.