8 ms·
On Hubris and Humility: developing an OS for robustness in Rust [video]
- deleted 5y ago[deleted]
- shmerl 5y agoThe talk mentions Oxide Computers. Just saw their site, I like the design there: https://oxide.computer https://oxide.computer
- xondono 5y agoGreat, I was waiting for a recording to be posted on youtube or something.
- deleted 5y ago[deleted]
- steveklabnik 5y agoThis is the video referred to in the post of this thread from earlier: https://news.ycombinator.com/item?id=29390751 https://news.ycombinator.com/item?id=29390751
- bcantrill 5y agoI am extraordinarily and unspeakably biased here, but I also say this as someone who didn't see the talk until I myself was an attendee at OSFC: Cliff's talk is as good as any I have ever seen in my career. It is dense with technical detail that itself reflects years of thinking and wisdom, but it remains well-paced with very helpful visuals; highly recommended viewing!
- yjftsjthsd-h 5y agoSlightly a tangental, but you seem like a good person to ask and this seems like as good a place as any: Is the way Hubris handles failed tasks intentionally reminiscent of the way illumos Fault Management Architecture works, or is that a coincidence born of them solving the same task in a relatively obvious way?
- bcantrill 5y agoThat actually hadn't occurred to me, in part because the Hubris model mainly deals with software failure, whereas FMA is mainly dealing with hardware failures. But certainly they both have a shared zeitgeist of robustness in light of errors are faults! So I would say that commonalities aren't directly correlated, but also not totally unrelated. ;)
- tgbugs 5y agoFor those looking for more on "parse don't validate" mentioned in the talk here are links to the original, and two previous discussions. 0. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... 1. https://news.ycombinator.com/item?id=21476261 https://news.ycombinator.com/item?id=21476261 (original 2019) 2. https://news.ycombinator.com/item?id=27639890 https://news.ycombinator.com/item?id=27639890 (revisited 2021)
- brundolf 5y ago+1, it's become a mantra for me in any code I write that deals with foreign data (which is most of them). Really reshapes your thinking.
- cle 5y agoNo rule of thumb should be a mantra. Parsing when you don’t need to induces unnecessary coupling, which can be quite undesirable in many scenarios. Like any technique, there are times when it’s worth it and times when it’s not.
- bch 5y ago“Parse don’t validate” reminds me of John Ousterhouts “Define errors out of existence.”[0] [0] https://youtu.be/bmSAYlu0NcY?t=1315 https://youtu.be/bmSAYlu0NcY?t=1315
- dannas 5y agoI thought the same thing when I read the blogpost.
- CyberRabbi 5y agoThis talk would be more interesting if it weren’t thinly veiled Rust evangelism. I lived through the time when XML and Java evangelism was considered technical content. The older I get, the less substance I see in evangelism of any sort. Centering language choice as the causal factor for any engineering project signals poor discipline in engineering.
- adgjlsfhk1 5y agocan you name a single widely used C library that hasn't had a buffer overflow vulnerability?
- FuckButtons 5y agoGiven that the raison d'être of oxide is to use rust to build their product I don’t know that this is fair criticism, unless you want to write their whole enterprise off for the same reason.
- panick21_ 5y agoI don't think that's their 'raison d'être', their 'raison d'être' is making a better computer.
- CyberRabbi 5y ago> Given that the raison d'être of oxide is to use rust to build their product Thanks for proving my point!
- staticassertion 5y agoThey explicitly justify the lack of solutions for memory safety in their space - both in terms of hardware and software - and why they are building their product using specific tools. They even note that this may seem like a strange choice (as opposed to using something off the shelf) but that they were willing and able to invest in these tools, specifically that they were going to build pretty much everything from scratch. They even call the project 'Hubris' as a joke about the ambition. Further, they discuss how borrow checking as a model lends itself to the task architecture. It's obviously very relevant. It seems silly to call this evangelism as opposed to a very self-aware deep dive into their choices.
- brundolf 5y ago> Unlike a signal-handler, it never alters the control-flow of the code you read on the page...Code you write in a task executes as written, or fails. Nothing in the system will arbitrarily alter your program's control-flow from what appears on the page...Now, when phrased like that, it seems weird to have to say it out loud, like, don't all programmers pretty much assume that the code that they write runs the way they wrote it? And to that I say yes, we absolutely do, and that assumption is often wrong, and leads to common classes of bugs, starting with data races and moving on up. Wow, this is really insightful
- panick21_ 5y agoIt really puts the task into the hands of the programmer. The way the it works (if I understand correctly from the docks) the programmer of a task needs to make sure it checks for notifications when it want to and controls that process. This gives the programmers some rope to hang themselves with, but on the other hand you don't get shot by the OS when you don't want to.
- brundolf 5y agoYeah. Though importantly, all of these tasks are (as I understand it) being designed and developed cohesively, by a small team under a single roof. We're not talking about random userspace applications in a general-purpose OS; new tasks can't even be started and stopped at runtime, they're laid out at build time. I think that's why this explicit and cooperative model can work.
- panick21_ 5y agoI would assume as the ecosystem grows 'standard' task will develop that will see a lot of reuse between different people using this OS. But I agree critically you build deploy this as a complete system even if many of the tasks are not inhouse. You still test the complete system.
- bcantrill 5y agoIf you want a very concrete example to hang your hat on: making the I2C driver interrupt driven was a snap -- and importantly, can easily be done from a library, where the caller merely provides functions to call to enable a specified interrupt and to synchronously wait for interrupts.[0] [0] https://github.com/oxidecomputer/hubris/blob/01b5af3d54348bad1ad0d64cc17abde58fa61979/drv/stm32h7-i2c/src/lib.rs#L439 https://github.com/oxidecomputer/hubris/blob/01b5af3d54348ba...
- wwarner 5y agoLove the simplicity , I wonder what Hubris would look like on a multicore cpu
- deleted 5y ago[deleted]
- ysleepy 5y agoLove the technical insights, but I comment here to praise the presentation style. My first judgement was that it seemed a bit rehearsed, but I ended up really enjoying the style. It felt very respectful of my time as a viewer, very concise and well prepared. I'm sure a lot of time went into that and I appreciate it. So thanks, for both an awesome application of rust and an amazing presentation.
- alblue 5y agoThe talk itself is great, but the background to the slides and speakers is constantly moving from side to side and is pretty distracting. I would have preferred to see the video of the slide deck itself without any extraneous background or the speaker’s head.
- sujayakar 5y agoI really enjoyed this talk. How does a system with completely static resource allocation accommodate cases where the underlying hardware is actually dynamic? For example, consider hot-plugging USB devices or storage media. Would there be a fixed "maximum number of USB devices," with resources reserved at compile time for the maximum? If so, does this preclude high resource utilization in the common case, where the user isn't hitting these limits?
- mkeeter 5y agoIn the past, I've worked on real-time systems which deliberately run in "worst-case" load all the time, basically to avoid your second concern: if high resource utilization is possible, then you have to design for it, and this is an easy way to make sure the system doesn't fall over. For example, if you're building a system that does controls multiple motors, you'd naively do motion-planning calculations for only the motors that are actively running. If instead you do these calculations for every motor all the time, even the ones that aren't moving, you'll have a worst-case performance profile; if it still works, then you can be more confident about the system. (I work at Oxide, but only for about a month, so this is more past experience than Hubris-specific)
- axegon_ 5y agoFeels weird to say it but... Time to give hubris a go.
- lostdog 5y agoVery interesting. This reminds me a ton of L4, with its message passing style. I'm curious if it was inspired by L4. It's a great talk, and my only disappointment was that I was hoping to hear about what comes after. After watching the OS talk that Cantrill references [0], I really want to know the answer to "what does an OS that runs across a bunch of heterogeneous chips look like?" Having Hubris be just a single-node OS was a bit of a let down, so I will be staying tuned for the sequels. [0] https://www.youtube.com/watch?v=36myc8wQhLo https://www.youtube.com/watch?v=36myc8wQhLo EDIT: Went to go read the docs and: "The operating system that originally made this point was L4, and Hubris’s IPC mechanism is directly inspired by L4’s"
- bcantrill 5y agoYes, definitely L3/L4 (and QNX) inspired! In terms of the Roscoe talk: I think it's a great talk because he talks about the problems, but I don't particular agree with the proposed solution. ;) In particular, I don't think it makes sense to have single operating systems spanning these wildly disparate, heterogeneous cores; to me, it makes much more sense for each to have its own (tiny) operating system -- e.g., Hubris.
- lostdog 5y agoThanks! I guess I'll check back in 5 years and see who was right.
- ncmncm 5y agoThis is almost all astonishingly sensible. If static provisioning works at all for the application, it is obviously better. If you did have a need to have dynamic tasks -- e.g., drivers for an unbounded set of USB peripherals -- one of the static tasks could be the executive for those. They would still be unable to interfere with the other, static tasks. I have to agree with the rabbi that the Rust evangelism detracts from the talk. E.g., the runtime borrow checking example, which does not rely on any Rust mechanism, would work as well with any language.