21 ms·

Hubris – A small operating system for deeply-embedded computer systems

560 points by jacobwg 5y ago

Tuna-Fish 5y ago
The github links don't work, are the repositories still private?
- detaro 5y ago
  It's going to be presented at a talk in ~9 hours, so probably: https://talks.osfc.io/osfc2021/talk/JTWYEH/ https://talks.osfc.io/osfc2021/talk/JTWYEH/
  - pjmlp 5y ago
    Do you know how to watch those sessions? The site is quite confusing, stating that registration and login are only required for speakers, but then there is no information regarding the talks beyond the description.
    - steveklabnik 5y ago
      You had to have bought a ticket to watch the talks. That said, I believe that they're putting them all up on Vimeo after the conference, so it won't be long until you can watch them.
      - pjmlp 5y ago
        Thanks, looking forward to them.
- pjmlp 5y ago
  I guess we need to keep ourselves busy with some docs, as that one works.
  - HeavenSmile 5y ago
    yeah sounds as a very good suggestion to me :)
- HeavenSmile 5y ago
  Yeah also noticed and got a little bit upset about this.. I mean publishing a website with broken links does not seems very smart nor makes very much sense to me..
  - HeavenSmile 5y ago
    That said if Hubris OS will be presented at a talk later today I guess things seems to be more clear to me. Are kind of way very much looking forward to the talk and the presentation of the operating system btw.
  - bcantrill 5y ago
    Ha, sorry -- HN scooped us on our own announcement! We had the intention of turning the key on everything early this morning Pacific time, but we put the landing page live last night just to get that out of the way. Needless to say, we were a bit surprised to see ourselves as the #2 story on HN when we hadn't even opened it yet! It's all open now, with our apologies for the perceived delay -- and never shall we again underestimate HN sleuths! ;)
    - mwcampbell 5y ago
      Did you forget to put a license in the repo? I'm guessing you meant to release it under the MPL.
      - steveklabnik 5y ago
        That was one of the PRs that was to be merged before opening up, yes. I merged it one minute before you made your comment :) https://github.com/oxidecomputer/hubris/pull/270 https://github.com/oxidecomputer/hubris/pull/270 (And yes it's MPL)
        AnimalMuppet 5y ago
        That's very impressive. Response time of -1 minute? Best I've ever seen. ;-)
sbarre 5y ago
The supervisor model reminds me a bit of how BEAM (Erlang/Elixir) works although I'm sure that's probably where the similarities end. As much as most of this is way over my head, I'm always fascinated to read about new ground-up work like this.
bo0tzz 5y ago
Their mention of individually restarting components and "flexible inter-component messaging" really reminds me of the BEAM. Very exciting!
- protomyth 5y ago
  Reminds me of QNX. It was an amazing OS and restarting display drivers over the network was just one of its amazing abilities.
  - mwcampbell 5y ago
    No surprise, since Bryan Cantrill worked at QNX for a short time in the 90s.
  - hbbio 5y ago
    There should be a retweet on HN! QNX was one the most impressive OS I've seen, especially for its time. From the full OS in a 1.44Mb floppy disk to restartable drivers, real-time, etc. IPC with messages is built in and most things ran in userland. It ended in the hands of BlackBerry which is probably not the best home for it... Edit: I googled out of curiosity, and despite being closed source, it seems to still be marketed by BlackBerry and is supposedly a market leader in embedded OSes! More than 20 years later, well deserved. https://www.automotiveworld.com/news-releases/blackberry-qnx-software-now-embedded-in-more-than-175-million-vehicles/ https://www.automotiveworld.com/news-releases/blackberry-qnx...
    - Cyph0n 5y ago
      Most of Cisco's high-end service provider routers were running IOS-XR on top of QNX. They switched from QNX to a Linux kernel (specifically, Wind River) around 7 years back.
    - rubylark 5y ago
      QNX is still going strong even with Blackberry. I worked at a company recently that heavily relied on QNX for safety critical embedded OS projects. It's Qt and QML integration made rapid prototyping a snap. Unfortunately it requires pretty (relatively) hefty processors so I never personally got to use it.
7thaccount 5y ago
Can anyone explain to a non-server person what Oxide hopes to accomplish? Is it basically just a new server with its own OS that makes it more secure?
- solmag 5y ago
  I think this OS is intended to run in embedded context where there are significant memory constraints; read its description, no runtime allocations etc. I linked two speeches where he goes over this in a bit more detail, but I hope the presentation opens it up even more.
- detaro 5y ago
  Pretty much "let's redo datacenter hardware from the ground up for current requirements, cutting off legacy things we don't need anymore"
  - jeffbee 5y ago
    But the BMC would be the #1 item on my list of "things I don't need any more". How do you come up with a scratch legacy-free universe that still includes BMCs?
    - panick21_ 5y ago
      That's exactly what they are doing. The are removing as many thing from the BMC as possible. It only contains a few things, it boots and hand over and allows for some remote control of the low level. That's it.
    - p_l 5y ago
      Because BMC is a term for function (which turns out to be very useful and important) not a specific technology (I like the tongue in cheek "totally not a BMC" used by some people from Oxide)
    - detaro 5y ago
      You don't need low-level remote management anymore? Or what specifically are you associating with the term "BMC"? (i.e. for me, "BMC" is "turn it off and on and force it to boot from network, remotely")
rossmohax 5y ago
Their repo is a rare case which embraced git submodules. For some reason they generate a lot of friction and not used often.
- steveklabnik 5y ago
  They are in fact a giant pain, but sometimes, still the best option.
  - rossmohax 5y ago
    Did you try https://github.com/ingydotnet/git-subrepo https://github.com/ingydotnet/git-subrepo ? Looks like it vendors in other repositories, making submodules entirely transparent for consumers and still allowing sumbodule workflow for authors.
    - steveklabnik 5y ago
      We didn't, thanks for the tip!
solmag 5y ago
So this is what Cantrill has been talking about. https://www.youtube.com/watch?v=XbBzSSvT_P0 https://www.youtube.com/watch?v=XbBzSSvT_P0 https://www.youtube.com/watch?v=cuvp-e4ztC0 https://www.youtube.com/watch?v=cuvp-e4ztC0
Zababa 5y ago
Intersting choices of names, Hubris and Humility. Combined with the style of the page, it gives to me a solemn and heavy feeling. Especially compared to most projects presented that tend to be very "positive energy and emojis". Their website is also beautiful https://oxide.computer/ https://oxide.computer/. Though I wonder who's the target for this. Is this for cloud provider themselves, for people that self host, for hosters? For everyone?
- noisy_boy 5y ago
  Speaking of interesting names, their control plane is called Omicron: https://github.com/oxidecomputer/omicron https://github.com/oxidecomputer/omicron
- barrenko 5y ago
  Their podcasts is similarly interesting even for me who has no real (professional) interest or knowledge about building computers.
- pjmlp 5y ago
  Cantrill has talked quite a few times about this, it is for people that still build their own data centers.
- omnicognate 5y ago
  > Their website is also beautiful But horribly broken for me (mobile firefox), with text cut off at borders and overlaid by images.
  - skinkestek 5y ago
    Same is true in mobile Safari (iOS) but I'll cut them some slack as long as it doesn't work in Chrome on iOS (since then it would be a Chrome specific hack, since Chrome on iOS uses the same engine as Safari.)
  - benjaminleonard 5y ago
    Apologies, pushing a fix now. I broke this earlier today!
panick21_ 5y ago
We are gettig an increasing amount of interesting Rust operating system for different uses. - Hubris for deep embedded - Redox OS for Desktop/Server (https://www.redox-os.org/ https://www.redox-os.org/) - Tock for embedded (https://www.tockos.org/ https://www.tockos.org/) - Xous for trusted devices (https://xobs.io/announcing-xous-the-betrusted-operating-system/ https://xobs.io/announcing-xous-the-betrusted-operating-syst...) I assume there are more.
- amitpm 5y ago
  Rust is the language of choice for dApps on Solana as well (which I thought was an interesting choice.)
  - rvz 5y ago
    That is completely true. Rust is where it is going for cryptocurrencies that need to have very secure smart-contracts and scale up to millions of users with tens of thousands of transactions per second. Even if it is completely unrelated, it is 'at least' production ready and will be used more than these projects would ever be used in terms of Rust projects.
    - securitypunk 5y ago
      Rust won't protect smart contracts from logic bugs.
      - elteto 5y ago
        I don’t think anyone said it would.
        jazzyjackson 5y ago
        > Rust is where it is going for cryptocurrencies that need to have very secure smart-contracts There is an implication here that Rust will help make smart contracts "secure", but AFAIK the vulnerabilities in smart contracts have been in their logic, not in their memory/type safety or whathaveyou.
natemcintosh 5y ago
So for a new OS like this, how does one compile their program for it?
- steveklabnik 5y ago
  You need to write your program for Hubris specifically; we don't support POSIX or anything. I want to have better "getting started" docs sometime soon.
tambourine_man 5y ago
> The Hubris debugger, Humility… That is some great naming
JulianMorrison 5y ago
I really like this quote from the manual: <<There are a class of "ideal attractors" in engineering, concepts like "everything is an object," "homoiconicity," "purely functional," "pure capability system," etc. Engineers fall into orbit around these ideas quite easily. Systems that follow these principles often get useful properties out of the deal. However, going too far in any of these directions is also a great way to find a deep reservoir of unsolved problems, which is part of why these are popular directions in academia. In the interest of shipping, we are consciously steering around unsolved problems, even when it means we lose some attractive features.>>
- SideburnsOfDoom 5y ago
  > In the interest of shipping, we are consciously steering around unsolved problems, even when it means we lose some attractive features Huh, this is more like pragmatism than "Hubris".
  - steveklabnik 5y ago
    We'd like to think so, but it's really hard to convince people that writing an entire new OS in Rust is the pragmatic choice. The name is a good reminder of the balance there, in my humble opinion.
    - bcantrill 5y ago
      To which I would add that naming a system "Pragmatic" may well be an act of unspeakable hubris, one that the gods would surely punish with a plague of architectural astronauts...
      - bigdict 5y ago
        Haha, pulling a bit of reverse psychology there?
    - posnet 5y ago
      Memento Mori
ls65536 5y ago
> no C code in the system. This removes, by construction, a lot of the attack surface normally present in similar systems. Not to be too pedantic here, but it's important to note that the absence of C code, while arguably a benefit overall, doesn't by itself guarantee anything with regards to safety/security...I suppose there's going to necessarily be at least some "unsafe" Rust and/or raw assembly instructions sprinkled throughout, but I can't yet see that myself (as of the time of writing this comment, the GitHub links are responding with 404). Nonetheless, it's always refreshing to see some good documentation and source code being provided for these kinds of things. Many companies in this space, even these days, sadly continue to live by some outdated values of hiding behind "security through obscurity", which is somehow championed (though using different words) as a benefit even to their own customers, so it's refreshing that others (Oxide among them) are really starting to take a different approach and making their software/firmware publicly available for inspection by anyone inclined to do so.
- pjmlp 5y ago
  Which is why they state a lot of the attack and not all of the attacks.
- steveklabnik 5y ago
  To be clear, that sentence refers to the sum total of the things in the previous sentence, not just the bit about C. And it's "a lot of the attack surface" and not "guarantee" for a reason. We don't believe that simply being written in Rust makes things automatically safe or secure. There is some unsafe Rust and some inline assembly, yes. I imagine a lot less than folks may think.
  - ls65536 5y ago
    I will admit perhaps I was a bit too loose with my own interpretation of the statement there. I think maybe this was influenced by my being tired of grand statements others have made in the past about the infallibility of writing code in Rust (even with liberal usage of "unsafe" without a proper understanding of what this implies). It's all too often I see some cargo cult-style declaration of "no more C; it's all Rust" as if that has somehow solved all problems and absolved the programmer of the responsibility for ensuring their code is otherwise safe and correct (granted, Rust does make this easier to do), and IMHO this just ends up doing a disservice both to those proclaimers and ultimately to Rust itself. To be clear, this is not a statement against Rust by any means but rather a complaint against the conduct of some of its practitioners. With that being said, I feel I really also need to state here that I absolutely do not believe the above to be the case with the announcement here...Even to the contrary, I would say, as the name "Hubris" says it all. It's great to see Rust used in practice like this, and I look forward to seeing more of the details in the code itself!
scudd 5y ago
Has Oxide released any information on the price range of one of their machines? I assume if they're targeting mid-size enterprises it would be outside what I would consider buying for hobby use, but it would be sweet in the future if there was a mini-Oxide suitable for home labs.
- floatboth 5y ago
  AFAIK they won't even sell individual machines, the product is a whole rack. Since they aim to open source everything, there probably will be a way to use their management plane and stuff with a homelab eventually :)
oxidethrowaway 5y ago
Oxide’s work is always interesting and basically a perfect confluence of all of my combined hardware and software experience to date. However, I can’t quite get over their policy of paying everyone the same salary of $175,000. ( https://news.ycombinator.com/item?id=26348836 https://news.ycombinator.com/item?id=26348836 ) I’d love to apply and work on these things, but I wouldn’t love the idea of sacrificing $xxx,000 per year for the privilege of building someone else’s startup. Does anyone know if they have some variability in equity compensation at least? I’m no stranger to taking significant compensation in startup equity, but it would have to be significant enough to make up for the significant comp reduction relative to just about every other employer in these domains.
- voltagex_ 5y ago
  Do you know how much money $175kUSD is to a lot of people?
  - oxidethrowaway 5y ago
    Yes! Of course it is, but employment is a market like anything else. The difference between $175K and market rate compensation (which may be significantly higher right now, considering the job market and the skills they’re asking for) is captured entirely by the founders and investors. We shouldn’t be shaming people for expecting a higher portion of the value they create in a competitive market like this. But the fixed salary method creates a lot of secondary problems for a company: It can become a revolving door as people join for quick experience and resume-building, but then leave as soon as they can get a higher paying job somewhere else.
    - nextaccountic 5y ago
      > The difference between $175K and market rate compensation (which may be significantly higher right now, considering the job market and the skills they’re asking for) is captured entirely by the founders and investors Why wouldn't some % of this be captured by your teammates?
cute_boi 5y ago
I think reference provide more info than above announcement itself: https://hubris.oxide.computer/reference https://hubris.oxide.computer/reference Looks amazing imo. Waiting for github code :D
- moondev 5y ago
  https://github.com/oxidecomputer/hubris https://github.com/oxidecomputer/hubris
luizfelberti 5y ago
Refreshing to see this seems tailored for RISC-V and ARM, rather than it being just another x86 OS. RISC is the future, and the future is exiting!
- floatboth 5y ago
  It's an embedded project. It's for microcontrollers. It's the Cortex-M kind of ARM, not Cortex-A. x86 isn't even a consideration in this space.
- mlindner 5y ago
  RISC vs CISC is a legacy of the past. All ISAs now are a bit of RISC and a bit of CSIC.
TD-Linux 5y ago
I have an embedded real-time control project that is currently written in Rust, but runs with RTIC (https://rtic.rs/ https://rtic.rs/), a framework which is conceptually similar (no dynamic allocation of tasks or resources) but also has some differences. RTIC is more of a framework for locks and critical sections in an interrupt based program than a full fledged RTOS. Looking through the docs, here's the main differences (for my purposes) I see: 1. In Hubris, all interrupt handlers dispatch to a software task. In RTIC, you can dispatch to a software task, but you can also run the code directly in the interrupt handler. RTIC is reliant on Cortex-M's NVIC for preemption, whereas Hubris can preempt in software (assuming it is implemented). This does increase the minimum effective interrupt latency in Hubris, and if not very carefully implemented, the jitter also. 2. Hubris compiles each task separately and then pastes the binaries together, presumably with a fancy linker script. RTIC can have everything in one source file and builds everything into one LTO'd blob. I see the Hubris method as mostly a downside (unless you want to integrate binary blobs, for example), but it might have been needed for: 3. Hubris supports Cortex-M memory protection regions. This is pretty neat and something that is mostly out of scope for RTIC (being built around primitives that allow shared memory, trying to map into the very limited number of MPU regions would be difficult at best). Of course, it's Rust, so in theory you wouldn't need the MPU protections, but if you have to run any sort of untrusted code this is definitely the winner. Hubris does support shared memory via leases, but I'm not sure how it manages to map them into the very limited 8 Cortex-M MPU regions. I'm quite interested to look at the implementation when the source code is released. Edit: I forgot to mention the biggest difference, which is that because tasks have separate stacks in Hubris, you can do blocking waits. RTIC may support async in the future but for now you must manually construct state machines.
- JulianMorrison 5y ago
  I don't think they link the binaries. It's more like, put them each on executable flash in separate places and the kernel just calls them. The intent here seems to be that each binary has no need (and no ability) to get all up in another binary's business. Nothing shared, except access to the RTOS.
  - 5y ago
steveklabnik 5y ago
Hey folks! The 404s are because we were planning on actually publishing this a bit later today, but it seems like folks noticed the CNAME entry. Happy to talk about it more, though obviously it'll be easier to see details once things are fully open. EDIT: blog post is up: https://oxide.computer/blog/hubris-and-humility https://oxide.computer/blog/hubris-and-humility and the GitHub should be open. EDIT 2: The HN story now points to this blog post, thanks mods!
cpach 5y ago
If anyone else wondered about the term BMC: https://www.servethehome.com/explaining-the-baseboard-management-controller-or-bmc-in-servers/ https://www.servethehome.com/explaining-the-baseboard-manage...
mgaunard 5y ago
I feel like Rust is everywhere and nowhere at the same time; how do they do it?
- mlindner 5y ago
  "They" is just a lot of software engineers who really really like it and want to be using it, but can't use it in their day job, so continue to talk and talk and talk about it in the hopes that it's used more. I'm one of them (not using it currently, want to use it).
  - pjmlp 5y ago
    Indeed, for example, one day Rust will be part of the default VS install, and then I can justify having native components for .NET stuff written in Rust, until then C++ will have to do. https://docs.microsoft.com/en-us/windows/dev-environment/rust/rust-for-windows https://docs.microsoft.com/en-us/windows/dev-environment/rus...
- ncmncm 5y ago
  MLM, effectively. The hype machine is pushing it into some places it is far from mature enough for. The hype depends more upon bad-mouthing other technologies than its merits can justify. This is not to discount actual merits, or to doubt the needed maturity will come, in time. And, embedded is certainly a place it is already mature enough for.
wyldfire 5y ago
I'm not familiar w/the details of the Cortex-Ms -- do any of them support SMT/multicore? Does Hubris have a scheduler which can support a multithreaded/core cpu?
- floatboth 5y ago
  Definitely no SMT (lol). Multicore is quite rare in the deep embedded space, though FreeRTOS has added some SMP support now: https://www.freertos.org/2021/10/freertos-adds-reference-implementations-for-symmetric-multiprocessing-smp.html https://www.freertos.org/2021/10/freertos-adds-reference-imp... — note that it's just now, that fact should already tell a lot. And often multicore in embedded is not SMP, rather MCUs with multiple cores often end up running independent programs / OS instances on the different cores.
  - SSLy 5y ago
    How do the independent cores mediate access to shared I/O on buses? (that includes RAM too)
    - sydthrowaway 5y ago
      The multiple cores are in a SoC, it's handled by bus fabric
  - wyldfire 5y ago
    I asked because I was considering porting to a DSP that has multiple threads, but it wouldn't make sense unless it had a scheduler that would work.
    - elcritch 5y ago
      The RTOS's don't often have schedules, but you can do locks or signals on shared memory. With that you can do "work pools", though I've only ever seen Cortex-M with dual cores.
b20000 5y ago
when i started working on a recent realtime project i used linux, although i wanted to do bare metal. but that was not an option because of all the drivers necessary, and i knew i wanted to use the GPU and the cortex A processor i am using. i am still wondering if there really no solution to this situation.
- qayxc 5y ago
  Depending on what you need, you might end up wasting a ton of time reinventing the wheel if you go down the bare metal route. Maybe a unikernel (if applicable) could be a good compromise?
  - b20000 5y ago
    that is true, but fine tuning linux to get what you want is a huge investment in time as well. i don’t need all the features of a complete OS. i only need a small set of features, and i want them to work in a specific way.
throwaway894345 5y ago
> instead of having an operating system that knows how to dynamically create tasks at run-time (itself a hallmark of multiprogrammed, general purpose systems), Cliff had designed Hubris to fully specify the tasks for a particular application at build time, with the build system then combining the kernel with the selected tasks to yield a single (attestable!) image. I worked briefly at John Deere, and their home-grown operating system (called "JDOS", written in C) also baked every application into the system at compile time. This was my only embedded experience, but I assumed this was somewhat common for embedded operating systems?
- stusmall 5y ago
  It's been a long time since I've worked in that world but in the micro-controller world it is common.
  - elcritch 5y ago
    Yah it seems like they're conflating high level OS'es with low level RTOS'es. Perhaps comparing their OS to a general purpose OS while doing embedded / RTOS things. Take: > Precedence for the Hubris approach can be found in other systems like library operating systems, but there is an essential difference: Hubris is a memory-protected system, with tasks, the kernel, and drivers all in disjoint protection domains. It's great that the drivers run in a different memory domains. Still I'm not convinced this isn't that different from many RTOS'es. Zephyr RTOS which can do memory protected tasks and defines each task's stack statically.
  - Matthias247 5y ago
    Yeah, its common for RTOS. All the things in automotive (OSEK, Autosar) worked the same. And OS like Greenhills Integrity can also do full isolation between modules.
spenczar5 5y ago
I'd like to hear more about Oxide's development process. Was this designed on an index card, and then implemented? Or was it done with piles and piles of diagrams and documents before the first code was committed? Was it treated as a cool, out-there idea that's worth exploring, and then it gradually looked better and better? It's hard to get software organizations to do ambitious things like this, and it's impressive that this was done on a relatively short timescale. I think the industry could learn a lot from how this was managed.
- mbag 5y ago
  It was probably done using RFDs (Requests for discussion),. You can read more on the process here [1]. But someone from Oxide would need to tell you exactly how many RFDs took to desing and implement Hubris. [1] https://oxide.computer/blog/rfd-1-requests-for-discussion https://oxide.computer/blog/rfd-1-requests-for-discussion
  - steveklabnik 5y ago
    There was an RFD for Hubris; it laid out the basic concepts and design goals, as well as non-goals. But after that, it's largely just iterating. When I joined there were four or five people working on Hubris regularly; we have weekly meetings where we sync up, talking about what we're working on, and discuss things.
- bcantrill 5y ago
  So, the Hubris repo itself will show a bunch of that history, but in particular, Cliff used the "sketch" nomenclature for the earliest ideas. I think in those first days, our thinking was that we were hitting a bunch of headwind on other approaches -- and had an increasingly concrete idea of what our own alternative might look like. I think whenever doing something new and bold, you want to give yourself some amount of time to at least get to an indicator that the new path is promising. For Hubris, this period was remarkably brief (small number of weeks), which is a tribute to the tremendous focus that Cliff had, but also how long some of the ideas had been germinating. Cliff also made the decision to do the earliest work on the STM32F407 Discovery; we knew that this wouldn't be the ultimate hardware that we would use for anything, but it is (or was!) readily attainable and just about everything about that board is known. To summarize, it didn't take long to get to the point where Hubris was clearly the direction -- and a working artifact was really essential for that.
jbott 5y ago
How are these docs being built? I really like how these look and it looks to be asciidoc based, but I can't seem to find a build script for these.
- ABS 5y ago
  HTML says <meta name="generator" content="Asciidoctor 2.0.16"> so I guess https://asciidoctor.org/ https://asciidoctor.org/
- steveklabnik 5y ago
  There's an open PR with the details, I set it to deploy every push to that PR for now so we could make quick fixes. It just runs asciidoctor, nothing fancy. https://github.com/oxidecomputer/hubris/pull/272 https://github.com/oxidecomputer/hubris/pull/272 (specifically https://github.com/oxidecomputer/hubris/pull/272/files#diff-28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3R37-R41 https://github.com/oxidecomputer/hubris/pull/272/files#diff-... )
Twisol 5y ago
As someone who's only worked with a prepared hardware kit (a dsPIC33F on an Explorer 16 that came with cables and the debugging puck), if I want to pick up the board they recommend in the blog post, do I need to make sure I get any other peripherals? This all seems very cool, and I badly want to poke at embedded stuff again, but I have whatever the opposite of a green thumb is for hardware. Advice would be appreciated ^_^
- Twisol 5y ago
  For anyone still reading this a week on, I got the recommended board in, and I needed a micro-USB cable -- preferably two, since it has two sockets (one for power and one for, I assume, programming). Luckily, I already have a few of these hanging around for charging my wireless headphones. It is completely beyond me, however, why one of the sockets is mounted upside down relative to the other one.
- jeffrallen 5y ago
  Right there with you, dude. I just bought an H753ZI (1), hope it's enough, we'll see. 1: https://www.st.com/en/evaluation-tools/nucleo-h753zi.html https://www.st.com/en/evaluation-tools/nucleo-h753zi.html
Animats 5y ago
That's what bootable Modula I offered on the PDP-11, over 40 years ago.
- bcantrill 5y ago
  This needs citation, but what does the "that" even refer to? I'm genuinely curious because there's little on it; did you use it? Did it survive? And what particular aspect of Hubris and Humility reminds you of this system?
  - Animats 5y ago
    Compile all the processes together, allocating all resources at compile time. Modula I had device register access, interrupt access, cooperative multitasking (async, the early years) and it worked moderately well on PDP-11 machines. Yes, I did use it. We wrote an operating system in it at an aerospace company.[1] It didn't work out well. Sort of OK language, weak compiler, not enough memory given the poor code generation. It was just too early to be doing that back in 1978-1982. We got the thing running, and it was used for a classified high-security application, once. [1] https://apps.dtic.mil/sti/pdfs/ADA111566.pdf https://apps.dtic.mil/sti/pdfs/ADA111566.pdf
    - bcantrill 5y ago
      Thanks for the reference -- that's helpful. KSOS is not a widely known system, but I can certainly see some similarities in approach with Hubris. That said, there are far more differences than there are similarities, and it's a gross oversimplification to say -- or even imply -- that the work in Hubris somehow replicates (or is even anticipated by) KSOS. More generally, I find this disposition -- that a new technology is uninteresting because it was "done" decades ago -- to be generally incurious, dour, discouraging, and (as in this case) broadly wrong on the facts. We as a team have as much reverence for history as any you will ever find; it is not unreasonable to ask those who have lived that history to return the favor by opening their minds to new ideas and implementations -- even if they remind them of old ones.
sydthrowaway 5y ago
I don't get why they had to reinvent the wheel, just use libreboot or whatever.
- steveklabnik 5y ago
  libreboot is a great project but it's only viable on specific x86 computers, and the chips we're using for the tasks Humility/Hubris is taking on are ARM.
  - sydthrowaway 5y ago
    What do Chromebooks use?
    - steveklabnik 5y ago
      https://libreboot.org/docs/hardware/c201.html https://libreboot.org/docs/hardware/c201.html says > NOTE: support for this machine is dropped in recent Libreboot releases. It will be re-added at a later date. For now, please use Libreboot 20160907 on this machine. Guessing by that number, this means support was discontinued five years ago.
    - floatboth 5y ago
      coreboot with a custom payload called depthcharge on the AP side. https://chromium.googlesource.com/chromiumos/platform/ec https://chromium.googlesource.com/chromiumos/platform/ec on the EC and GSC (Google Security Chip) side.

560 points by jacobwg 5y ago

Tuna-Fish 5y ago

The github links don't work, are the repositories still private?

detaro 5y ago
It's going to be presented at a talk in ~9 hours, so probably: https://talks.osfc.io/osfc2021/talk/JTWYEH/ https://talks.osfc.io/osfc2021/talk/JTWYEH/
- pjmlp 5y ago
  Do you know how to watch those sessions? The site is quite confusing, stating that registration and login are only required for speakers, but then there is no information regarding the talks beyond the description.
  - steveklabnik 5y ago
    You had to have bought a ticket to watch the talks. That said, I believe that they're putting them all up on Vimeo after the conference, so it won't be long until you can watch them.
    - pjmlp 5y ago
      Thanks, looking forward to them.
pjmlp 5y ago
I guess we need to keep ourselves busy with some docs, as that one works.
- HeavenSmile 5y ago
  yeah sounds as a very good suggestion to me :)
HeavenSmile 5y ago
Yeah also noticed and got a little bit upset about this.. I mean publishing a website with broken links does not seems very smart nor makes very much sense to me..
- HeavenSmile 5y ago
  That said if Hubris OS will be presented at a talk later today I guess things seems to be more clear to me. Are kind of way very much looking forward to the talk and the presentation of the operating system btw.
- bcantrill 5y ago
  Ha, sorry -- HN scooped us on our own announcement! We had the intention of turning the key on everything early this morning Pacific time, but we put the landing page live last night just to get that out of the way. Needless to say, we were a bit surprised to see ourselves as the #2 story on HN when we hadn't even opened it yet! It's all open now, with our apologies for the perceived delay -- and never shall we again underestimate HN sleuths! ;)
  - mwcampbell 5y ago
    Did you forget to put a license in the repo? I'm guessing you meant to release it under the MPL.
    - steveklabnik 5y ago
      That was one of the PRs that was to be merged before opening up, yes. I merged it one minute before you made your comment :) https://github.com/oxidecomputer/hubris/pull/270 https://github.com/oxidecomputer/hubris/pull/270 (And yes it's MPL)
      - AnimalMuppet 5y ago
        That's very impressive. Response time of -1 minute? Best I've ever seen. ;-)

sbarre 5y ago

The supervisor model reminds me a bit of how BEAM (Erlang/Elixir) works although I'm sure that's probably where the similarities end. As much as most of this is way over my head, I'm always fascinated to read about new ground-up work like this.

bo0tzz 5y ago

Their mention of individually restarting components and "flexible inter-component messaging" really reminds me of the BEAM. Very exciting!

protomyth 5y ago
Reminds me of QNX. It was an amazing OS and restarting display drivers over the network was just one of its amazing abilities.
- mwcampbell 5y ago
  No surprise, since Bryan Cantrill worked at QNX for a short time in the 90s.
- hbbio 5y ago
  There should be a retweet on HN! QNX was one the most impressive OS I've seen, especially for its time. From the full OS in a 1.44Mb floppy disk to restartable drivers, real-time, etc. IPC with messages is built in and most things ran in userland. It ended in the hands of BlackBerry which is probably not the best home for it... Edit: I googled out of curiosity, and despite being closed source, it seems to still be marketed by BlackBerry and is supposedly a market leader in embedded OSes! More than 20 years later, well deserved. https://www.automotiveworld.com/news-releases/blackberry-qnx-software-now-embedded-in-more-than-175-million-vehicles/ https://www.automotiveworld.com/news-releases/blackberry-qnx...
  - Cyph0n 5y ago
    Most of Cisco's high-end service provider routers were running IOS-XR on top of QNX. They switched from QNX to a Linux kernel (specifically, Wind River) around 7 years back.
  - rubylark 5y ago
    QNX is still going strong even with Blackberry. I worked at a company recently that heavily relied on QNX for safety critical embedded OS projects. It's Qt and QML integration made rapid prototyping a snap. Unfortunately it requires pretty (relatively) hefty processors so I never personally got to use it.

7thaccount 5y ago

Can anyone explain to a non-server person what Oxide hopes to accomplish? Is it basically just a new server with its own OS that makes it more secure?

solmag 5y ago
I think this OS is intended to run in embedded context where there are significant memory constraints; read its description, no runtime allocations etc. I linked two speeches where he goes over this in a bit more detail, but I hope the presentation opens it up even more.
detaro 5y ago
Pretty much "let's redo datacenter hardware from the ground up for current requirements, cutting off legacy things we don't need anymore"
- jeffbee 5y ago
  But the BMC would be the #1 item on my list of "things I don't need any more". How do you come up with a scratch legacy-free universe that still includes BMCs?
  - panick21_ 5y ago
    That's exactly what they are doing. The are removing as many thing from the BMC as possible. It only contains a few things, it boots and hand over and allows for some remote control of the low level. That's it.
  - p_l 5y ago
    Because BMC is a term for function (which turns out to be very useful and important) not a specific technology (I like the tongue in cheek "totally not a BMC" used by some people from Oxide)
  - detaro 5y ago
    You don't need low-level remote management anymore? Or what specifically are you associating with the term "BMC"? (i.e. for me, "BMC" is "turn it off and on and force it to boot from network, remotely")

rossmohax 5y ago

Their repo is a rare case which embraced git submodules. For some reason they generate a lot of friction and not used often.

steveklabnik 5y ago
They are in fact a giant pain, but sometimes, still the best option.
- rossmohax 5y ago
  Did you try https://github.com/ingydotnet/git-subrepo https://github.com/ingydotnet/git-subrepo ? Looks like it vendors in other repositories, making submodules entirely transparent for consumers and still allowing sumbodule workflow for authors.
  - steveklabnik 5y ago
    We didn't, thanks for the tip!

solmag 5y ago

So this is what Cantrill has been talking about. https://www.youtube.com/watch?v=XbBzSSvT_P0 https://www.youtube.com/watch?v=XbBzSSvT_P0 https://www.youtube.com/watch?v=cuvp-e4ztC0 https://www.youtube.com/watch?v=cuvp-e4ztC0

Zababa 5y ago

Intersting choices of names, Hubris and Humility. Combined with the style of the page, it gives to me a solemn and heavy feeling. Especially compared to most projects presented that tend to be very "positive energy and emojis". Their website is also beautiful https://oxide.computer/ https://oxide.computer/. Though I wonder who's the target for this. Is this for cloud provider themselves, for people that self host, for hosters? For everyone?

noisy_boy 5y ago
Speaking of interesting names, their control plane is called Omicron: https://github.com/oxidecomputer/omicron https://github.com/oxidecomputer/omicron
barrenko 5y ago
Their podcasts is similarly interesting even for me who has no real (professional) interest or knowledge about building computers.
pjmlp 5y ago
Cantrill has talked quite a few times about this, it is for people that still build their own data centers.
omnicognate 5y ago
> Their website is also beautiful But horribly broken for me (mobile firefox), with text cut off at borders and overlaid by images.
- skinkestek 5y ago
  Same is true in mobile Safari (iOS) but I'll cut them some slack as long as it doesn't work in Chrome on iOS (since then it would be a Chrome specific hack, since Chrome on iOS uses the same engine as Safari.)
- benjaminleonard 5y ago
  Apologies, pushing a fix now. I broke this earlier today!

panick21_ 5y ago

We are gettig an increasing amount of interesting Rust operating system for different uses. - Hubris for deep embedded - Redox OS for Desktop/Server (https://www.redox-os.org/ https://www.redox-os.org/) - Tock for embedded (https://www.tockos.org/ https://www.tockos.org/) - Xous for trusted devices (https://xobs.io/announcing-xous-the-betrusted-operating-system/ https://xobs.io/announcing-xous-the-betrusted-operating-syst...) I assume there are more.

amitpm 5y ago
Rust is the language of choice for dApps on Solana as well (which I thought was an interesting choice.)
- rvz 5y ago
  That is completely true. Rust is where it is going for cryptocurrencies that need to have very secure smart-contracts and scale up to millions of users with tens of thousands of transactions per second. Even if it is completely unrelated, it is 'at least' production ready and will be used more than these projects would ever be used in terms of Rust projects.
  - securitypunk 5y ago
    Rust won't protect smart contracts from logic bugs.
    - elteto 5y ago
      I don’t think anyone said it would.
      - jazzyjackson 5y ago
        > Rust is where it is going for cryptocurrencies that need to have very secure smart-contracts There is an implication here that Rust will help make smart contracts "secure", but AFAIK the vulnerabilities in smart contracts have been in their logic, not in their memory/type safety or whathaveyou.

natemcintosh 5y ago

So for a new OS like this, how does one compile their program for it?

steveklabnik 5y ago
You need to write your program for Hubris specifically; we don't support POSIX or anything. I want to have better "getting started" docs sometime soon.

tambourine_man 5y ago

> The Hubris debugger, Humility… That is some great naming

JulianMorrison 5y ago

I really like this quote from the manual: <<There are a class of "ideal attractors" in engineering, concepts like "everything is an object," "homoiconicity," "purely functional," "pure capability system," etc. Engineers fall into orbit around these ideas quite easily. Systems that follow these principles often get useful properties out of the deal. However, going too far in any of these directions is also a great way to find a deep reservoir of unsolved problems, which is part of why these are popular directions in academia. In the interest of shipping, we are consciously steering around unsolved problems, even when it means we lose some attractive features.>>

SideburnsOfDoom 5y ago
> In the interest of shipping, we are consciously steering around unsolved problems, even when it means we lose some attractive features Huh, this is more like pragmatism than "Hubris".
- steveklabnik 5y ago
  We'd like to think so, but it's really hard to convince people that writing an entire new OS in Rust is the pragmatic choice. The name is a good reminder of the balance there, in my humble opinion.
  - bcantrill 5y ago
    To which I would add that naming a system "Pragmatic" may well be an act of unspeakable hubris, one that the gods would surely punish with a plague of architectural astronauts...
    - bigdict 5y ago
      Haha, pulling a bit of reverse psychology there?
  - posnet 5y ago
    Memento Mori

ls65536 5y ago

> no C code in the system. This removes, by construction, a lot of the attack surface normally present in similar systems. Not to be too pedantic here, but it's important to note that the absence of C code, while arguably a benefit overall, doesn't by itself guarantee anything with regards to safety/security...I suppose there's going to necessarily be at least some "unsafe" Rust and/or raw assembly instructions sprinkled throughout, but I can't yet see that myself (as of the time of writing this comment, the GitHub links are responding with 404). Nonetheless, it's always refreshing to see some good documentation and source code being provided for these kinds of things. Many companies in this space, even these days, sadly continue to live by some outdated values of hiding behind "security through obscurity", which is somehow championed (though using different words) as a benefit even to their own customers, so it's refreshing that others (Oxide among them) are really starting to take a different approach and making their software/firmware publicly available for inspection by anyone inclined to do so.

pjmlp 5y ago
Which is why they state a lot of the attack and not all of the attacks.
steveklabnik 5y ago
To be clear, that sentence refers to the sum total of the things in the previous sentence, not just the bit about C. And it's "a lot of the attack surface" and not "guarantee" for a reason. We don't believe that simply being written in Rust makes things automatically safe or secure. There is some unsafe Rust and some inline assembly, yes. I imagine a lot less than folks may think.
- ls65536 5y ago
  I will admit perhaps I was a bit too loose with my own interpretation of the statement there. I think maybe this was influenced by my being tired of grand statements others have made in the past about the infallibility of writing code in Rust (even with liberal usage of "unsafe" without a proper understanding of what this implies). It's all too often I see some cargo cult-style declaration of "no more C; it's all Rust" as if that has somehow solved all problems and absolved the programmer of the responsibility for ensuring their code is otherwise safe and correct (granted, Rust does make this easier to do), and IMHO this just ends up doing a disservice both to those proclaimers and ultimately to Rust itself. To be clear, this is not a statement against Rust by any means but rather a complaint against the conduct of some of its practitioners. With that being said, I feel I really also need to state here that I absolutely do not believe the above to be the case with the announcement here...Even to the contrary, I would say, as the name "Hubris" says it all. It's great to see Rust used in practice like this, and I look forward to seeing more of the details in the code itself!

scudd 5y ago

Has Oxide released any information on the price range of one of their machines? I assume if they're targeting mid-size enterprises it would be outside what I would consider buying for hobby use, but it would be sweet in the future if there was a mini-Oxide suitable for home labs.

floatboth 5y ago
AFAIK they won't even sell individual machines, the product is a whole rack. Since they aim to open source everything, there probably will be a way to use their management plane and stuff with a homelab eventually :)

oxidethrowaway 5y ago

Oxide’s work is always interesting and basically a perfect confluence of all of my combined hardware and software experience to date. However, I can’t quite get over their policy of paying everyone the same salary of $175,000. ( https://news.ycombinator.com/item?id=26348836 https://news.ycombinator.com/item?id=26348836 ) I’d love to apply and work on these things, but I wouldn’t love the idea of sacrificing $xxx,000 per year for the privilege of building someone else’s startup. Does anyone know if they have some variability in equity compensation at least? I’m no stranger to taking significant compensation in startup equity, but it would have to be significant enough to make up for the significant comp reduction relative to just about every other employer in these domains.

voltagex_ 5y ago
Do you know how much money $175kUSD is to a lot of people?
- oxidethrowaway 5y ago
  Yes! Of course it is, but employment is a market like anything else. The difference between $175K and market rate compensation (which may be significantly higher right now, considering the job market and the skills they’re asking for) is captured entirely by the founders and investors. We shouldn’t be shaming people for expecting a higher portion of the value they create in a competitive market like this. But the fixed salary method creates a lot of secondary problems for a company: It can become a revolving door as people join for quick experience and resume-building, but then leave as soon as they can get a higher paying job somewhere else.
  - nextaccountic 5y ago
    > The difference between $175K and market rate compensation (which may be significantly higher right now, considering the job market and the skills they’re asking for) is captured entirely by the founders and investors Why wouldn't some % of this be captured by your teammates?

cute_boi 5y ago

I think reference provide more info than above announcement itself: https://hubris.oxide.computer/reference https://hubris.oxide.computer/reference Looks amazing imo. Waiting for github code :D

moondev 5y ago
https://github.com/oxidecomputer/hubris https://github.com/oxidecomputer/hubris

luizfelberti 5y ago

Refreshing to see this seems tailored for RISC-V and ARM, rather than it being just another x86 OS. RISC is the future, and the future is exiting!

floatboth 5y ago
It's an embedded project. It's for microcontrollers. It's the Cortex-M kind of ARM, not Cortex-A. x86 isn't even a consideration in this space.
mlindner 5y ago
RISC vs CISC is a legacy of the past. All ISAs now are a bit of RISC and a bit of CSIC.

TD-Linux 5y ago

I have an embedded real-time control project that is currently written in Rust, but runs with RTIC (https://rtic.rs/ https://rtic.rs/), a framework which is conceptually similar (no dynamic allocation of tasks or resources) but also has some differences. RTIC is more of a framework for locks and critical sections in an interrupt based program than a full fledged RTOS. Looking through the docs, here's the main differences (for my purposes) I see: 1. In Hubris, all interrupt handlers dispatch to a software task. In RTIC, you can dispatch to a software task, but you can also run the code directly in the interrupt handler. RTIC is reliant on Cortex-M's NVIC for preemption, whereas Hubris can preempt in software (assuming it is implemented). This does increase the minimum effective interrupt latency in Hubris, and if not very carefully implemented, the jitter also. 2. Hubris compiles each task separately and then pastes the binaries together, presumably with a fancy linker script. RTIC can have everything in one source file and builds everything into one LTO'd blob. I see the Hubris method as mostly a downside (unless you want to integrate binary blobs, for example), but it might have been needed for: 3. Hubris supports Cortex-M memory protection regions. This is pretty neat and something that is mostly out of scope for RTIC (being built around primitives that allow shared memory, trying to map into the very limited number of MPU regions would be difficult at best). Of course, it's Rust, so in theory you wouldn't need the MPU protections, but if you have to run any sort of untrusted code this is definitely the winner. Hubris does support shared memory via leases, but I'm not sure how it manages to map them into the very limited 8 Cortex-M MPU regions. I'm quite interested to look at the implementation when the source code is released. Edit: I forgot to mention the biggest difference, which is that because tasks have separate stacks in Hubris, you can do blocking waits. RTIC may support async in the future but for now you must manually construct state machines.

JulianMorrison 5y ago
I don't think they link the binaries. It's more like, put them each on executable flash in separate places and the kernel just calls them. The intent here seems to be that each binary has no need (and no ability) to get all up in another binary's business. Nothing shared, except access to the RTOS.
- 5y ago

steveklabnik 5y ago

Hey folks! The 404s are because we were planning on actually publishing this a bit later today, but it seems like folks noticed the CNAME entry. Happy to talk about it more, though obviously it'll be easier to see details once things are fully open. EDIT: blog post is up: https://oxide.computer/blog/hubris-and-humility https://oxide.computer/blog/hubris-and-humility and the GitHub should be open. EDIT 2: The HN story now points to this blog post, thanks mods!

cpach 5y ago

If anyone else wondered about the term BMC: https://www.servethehome.com/explaining-the-baseboard-management-controller-or-bmc-in-servers/ https://www.servethehome.com/explaining-the-baseboard-manage...

mgaunard 5y ago

I feel like Rust is everywhere and nowhere at the same time; how do they do it?

mlindner 5y ago
"They" is just a lot of software engineers who really really like it and want to be using it, but can't use it in their day job, so continue to talk and talk and talk about it in the hopes that it's used more. I'm one of them (not using it currently, want to use it).
- pjmlp 5y ago
  Indeed, for example, one day Rust will be part of the default VS install, and then I can justify having native components for .NET stuff written in Rust, until then C++ will have to do. https://docs.microsoft.com/en-us/windows/dev-environment/rust/rust-for-windows https://docs.microsoft.com/en-us/windows/dev-environment/rus...
ncmncm 5y ago
MLM, effectively. The hype machine is pushing it into some places it is far from mature enough for. The hype depends more upon bad-mouthing other technologies than its merits can justify. This is not to discount actual merits, or to doubt the needed maturity will come, in time. And, embedded is certainly a place it is already mature enough for.

wyldfire 5y ago

I'm not familiar w/the details of the Cortex-Ms -- do any of them support SMT/multicore? Does Hubris have a scheduler which can support a multithreaded/core cpu?

floatboth 5y ago
Definitely no SMT (lol). Multicore is quite rare in the deep embedded space, though FreeRTOS has added some SMP support now: https://www.freertos.org/2021/10/freertos-adds-reference-implementations-for-symmetric-multiprocessing-smp.html https://www.freertos.org/2021/10/freertos-adds-reference-imp... — note that it's just now, that fact should already tell a lot. And often multicore in embedded is not SMP, rather MCUs with multiple cores often end up running independent programs / OS instances on the different cores.
- SSLy 5y ago
  How do the independent cores mediate access to shared I/O on buses? (that includes RAM too)
  - sydthrowaway 5y ago
    The multiple cores are in a SoC, it's handled by bus fabric
- wyldfire 5y ago
  I asked because I was considering porting to a DSP that has multiple threads, but it wouldn't make sense unless it had a scheduler that would work.
  - elcritch 5y ago
    The RTOS's don't often have schedules, but you can do locks or signals on shared memory. With that you can do "work pools", though I've only ever seen Cortex-M with dual cores.

b20000 5y ago

when i started working on a recent realtime project i used linux, although i wanted to do bare metal. but that was not an option because of all the drivers necessary, and i knew i wanted to use the GPU and the cortex A processor i am using. i am still wondering if there really no solution to this situation.

qayxc 5y ago
Depending on what you need, you might end up wasting a ton of time reinventing the wheel if you go down the bare metal route. Maybe a unikernel (if applicable) could be a good compromise?
- b20000 5y ago
  that is true, but fine tuning linux to get what you want is a huge investment in time as well. i don’t need all the features of a complete OS. i only need a small set of features, and i want them to work in a specific way.

throwaway894345 5y ago

> instead of having an operating system that knows how to dynamically create tasks at run-time (itself a hallmark of multiprogrammed, general purpose systems), Cliff had designed Hubris to fully specify the tasks for a particular application at build time, with the build system then combining the kernel with the selected tasks to yield a single (attestable!) image. I worked briefly at John Deere, and their home-grown operating system (called "JDOS", written in C) also baked every application into the system at compile time. This was my only embedded experience, but I assumed this was somewhat common for embedded operating systems?

stusmall 5y ago
It's been a long time since I've worked in that world but in the micro-controller world it is common.
- elcritch 5y ago
  Yah it seems like they're conflating high level OS'es with low level RTOS'es. Perhaps comparing their OS to a general purpose OS while doing embedded / RTOS things. Take: > Precedence for the Hubris approach can be found in other systems like library operating systems, but there is an essential difference: Hubris is a memory-protected system, with tasks, the kernel, and drivers all in disjoint protection domains. It's great that the drivers run in a different memory domains. Still I'm not convinced this isn't that different from many RTOS'es. Zephyr RTOS which can do memory protected tasks and defines each task's stack statically.
- Matthias247 5y ago
  Yeah, its common for RTOS. All the things in automotive (OSEK, Autosar) worked the same. And OS like Greenhills Integrity can also do full isolation between modules.

spenczar5 5y ago

I'd like to hear more about Oxide's development process. Was this designed on an index card, and then implemented? Or was it done with piles and piles of diagrams and documents before the first code was committed? Was it treated as a cool, out-there idea that's worth exploring, and then it gradually looked better and better? It's hard to get software organizations to do ambitious things like this, and it's impressive that this was done on a relatively short timescale. I think the industry could learn a lot from how this was managed.

mbag 5y ago
It was probably done using RFDs (Requests for discussion),. You can read more on the process here [1]. But someone from Oxide would need to tell you exactly how many RFDs took to desing and implement Hubris. [1] https://oxide.computer/blog/rfd-1-requests-for-discussion https://oxide.computer/blog/rfd-1-requests-for-discussion
- steveklabnik 5y ago
  There was an RFD for Hubris; it laid out the basic concepts and design goals, as well as non-goals. But after that, it's largely just iterating. When I joined there were four or five people working on Hubris regularly; we have weekly meetings where we sync up, talking about what we're working on, and discuss things.
bcantrill 5y ago
So, the Hubris repo itself will show a bunch of that history, but in particular, Cliff used the "sketch" nomenclature for the earliest ideas. I think in those first days, our thinking was that we were hitting a bunch of headwind on other approaches -- and had an increasingly concrete idea of what our own alternative might look like. I think whenever doing something new and bold, you want to give yourself some amount of time to at least get to an indicator that the new path is promising. For Hubris, this period was remarkably brief (small number of weeks), which is a tribute to the tremendous focus that Cliff had, but also how long some of the ideas had been germinating. Cliff also made the decision to do the earliest work on the STM32F407 Discovery; we knew that this wouldn't be the ultimate hardware that we would use for anything, but it is (or was!) readily attainable and just about everything about that board is known. To summarize, it didn't take long to get to the point where Hubris was clearly the direction -- and a working artifact was really essential for that.

jbott 5y ago

How are these docs being built? I really like how these look and it looks to be asciidoc based, but I can't seem to find a build script for these.

ABS 5y ago
HTML says <meta name="generator" content="Asciidoctor 2.0.16"> so I guess https://asciidoctor.org/ https://asciidoctor.org/
steveklabnik 5y ago
There's an open PR with the details, I set it to deploy every push to that PR for now so we could make quick fixes. It just runs asciidoctor, nothing fancy. https://github.com/oxidecomputer/hubris/pull/272 https://github.com/oxidecomputer/hubris/pull/272 (specifically https://github.com/oxidecomputer/hubris/pull/272/files#diff-28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3R37-R41 https://github.com/oxidecomputer/hubris/pull/272/files#diff-... )

Twisol 5y ago

As someone who's only worked with a prepared hardware kit (a dsPIC33F on an Explorer 16 that came with cables and the debugging puck), if I want to pick up the board they recommend in the blog post, do I need to make sure I get any other peripherals? This all seems very cool, and I badly want to poke at embedded stuff again, but I have whatever the opposite of a green thumb is for hardware. Advice would be appreciated ^_^

Twisol 5y ago
For anyone still reading this a week on, I got the recommended board in, and I needed a micro-USB cable -- preferably two, since it has two sockets (one for power and one for, I assume, programming). Luckily, I already have a few of these hanging around for charging my wireless headphones. It is completely beyond me, however, why one of the sockets is mounted upside down relative to the other one.
jeffrallen 5y ago
Right there with you, dude. I just bought an H753ZI (1), hope it's enough, we'll see. 1: https://www.st.com/en/evaluation-tools/nucleo-h753zi.html https://www.st.com/en/evaluation-tools/nucleo-h753zi.html

Animats 5y ago

That's what bootable Modula I offered on the PDP-11, over 40 years ago.

bcantrill 5y ago
This needs citation, but what does the "that" even refer to? I'm genuinely curious because there's little on it; did you use it? Did it survive? And what particular aspect of Hubris and Humility reminds you of this system?
- Animats 5y ago
  Compile all the processes together, allocating all resources at compile time. Modula I had device register access, interrupt access, cooperative multitasking (async, the early years) and it worked moderately well on PDP-11 machines. Yes, I did use it. We wrote an operating system in it at an aerospace company.[1] It didn't work out well. Sort of OK language, weak compiler, not enough memory given the poor code generation. It was just too early to be doing that back in 1978-1982. We got the thing running, and it was used for a classified high-security application, once. [1] https://apps.dtic.mil/sti/pdfs/ADA111566.pdf https://apps.dtic.mil/sti/pdfs/ADA111566.pdf
  - bcantrill 5y ago
    Thanks for the reference -- that's helpful. KSOS is not a widely known system, but I can certainly see some similarities in approach with Hubris. That said, there are far more differences than there are similarities, and it's a gross oversimplification to say -- or even imply -- that the work in Hubris somehow replicates (or is even anticipated by) KSOS. More generally, I find this disposition -- that a new technology is uninteresting because it was "done" decades ago -- to be generally incurious, dour, discouraging, and (as in this case) broadly wrong on the facts. We as a team have as much reverence for history as any you will ever find; it is not unreasonable to ask those who have lived that history to return the favor by opening their minds to new ideas and implementations -- even if they remind them of old ones.

sydthrowaway 5y ago

I don't get why they had to reinvent the wheel, just use libreboot or whatever.

steveklabnik 5y ago
libreboot is a great project but it's only viable on specific x86 computers, and the chips we're using for the tasks Humility/Hubris is taking on are ARM.
- sydthrowaway 5y ago
  What do Chromebooks use?
  - steveklabnik 5y ago
    https://libreboot.org/docs/hardware/c201.html https://libreboot.org/docs/hardware/c201.html says > NOTE: support for this machine is dropped in recent Libreboot releases. It will be re-added at a later date. For now, please use Libreboot 20160907 on this machine. Guessing by that number, this means support was discontinued five years ago.
  - floatboth 5y ago
    coreboot with a custom payload called depthcharge on the AP side. https://chromium.googlesource.com/chromiumos/platform/ec https://chromium.googlesource.com/chromiumos/platform/ec on the EC and GSC (Google Security Chip) side.