HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
oxidecomputer
hubris
Rust2021–2026
oxidecomputer / hubris

hubris

A lightweight, memory-protected, message-passing kernel for deeply embedded systems.

Systems & InfrastructureHardware & Embedded
Explore on GitHubRead Hacker News discussions
22Distinct people
39Mentions
1Explicit recommenders
3.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A lightweight, memory-protected, message-passing kernel for deeply embedded systems.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Hubris is really, really nice. I've spent half an hour reading some of the kernel code and it’s exceptionally clear and well written - a far cry from ifdef macro soup, two…

orf used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:02:44 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year39 dated mentions

Observed mentions: 2021-11-30 15:34:09 UTC to 2026-07-14 17:57:33 UTC.

02468102021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC10010
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC909
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC909
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC606
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC303

What Hacker News says

6 sources
mkeeter·Oct 24, 2024
Finding bugs in the Hubris kernel is rare enough that we have a running joke about resetting the “days since last kernel bug” timer. I decided to make this joke into an actual docs page; because HN has enjoyed posts about Hubris in the past [1], I figured this might be of interest! Many of the individual bugs are terrifying dives into corner cases of an embedded OS. This one is particularly good reading: https://github.com/oxidecomputer/hubris/issues/1134 [1] https://news.ycombinator.com/item?id=29390751
In It has been [33] days since the last Hubris kernel bug
mkeeter·Sep 14, 2024
It’s moderately smart - there’s a PID loop with per-component target temperatures, so it’s trying not to do more work than necessary. (source: I wrote it, and it’s all published at https://github.com/oxidecomputer/hubris/tree/master/task/the... ) We also worked with the fan vendor to get parts with a lower minimum RPM. The stock fans idle at about 5K RPM, and ours idle at 2K, which is already enough to keep the system cool under light loads.
In My 71 TiB ZFS NAS After 10 Years and Zero Drive Failures
denotational·Apr 24, 2024
Once you get away from the “rack” as the unit and go back to a tower/NUC, I don’t think Oxide has anything special to add, but I may be wrong since I haven’t used their product. A Dell (using them as an example since I’m familiar with PowerEdge) server/tower/NUC is pretty well integrated; the Oxide value add, as I understand it, is that your entire rack is integrated as opposed to being your own assembly of PDUs/servers/switches/etc. Perhaps their management software (for spinning up VMs, managing storage, etc.) is high value, but I’m not sure how that works when you lose the rack-level integration and go back to a tower/NUC. What do you see Oxide as adding at the tower/NUC level that takes you beyond the integration of a traditional tower/NUC from a vendor like Dell? I have seen similar excitement for “hobbyist Oxide” on other threads, b
Read the rest
ut I’m still not completely sure what this actually means and how it would distinguish itself from existing sub-rack commodity hardware. A sibling comment mentions smaller racks, which is certainly something I could get behind, but that’s not the same as towers/NUCs (or maybe that’s exactly what you mean: something that looks like a tower/NUC but is really a mini-rack with multiple miniaturised computers/switches/etc. inside?). > The CPUs in Oxide racks are AMD, so, presumably AMD-based compute rather than ARM. These don’t run Hubris though; the x86 cores are running Helios [0], Oxide’s flavour of Illumos (i.e. Solaris) that includes a bunch of binary blobs that aren’t even available, let alone open-source: they plan to make these “public” at some point, but it’s not clear whether this means source-available. Based on the chips directory in the repo [1], they’re targeting a mix of NXP and ST parts, which are Arm, and the user isn’t likely to see them or care what firmware they’re running: I don’t think replacing the firmware with something running on top of Hubris is a value add, or even particular interesting for the hacker/hobbyist at all, in the sense that they’re a tiny cog in a much more complex system, and if you’re interested in hacking on something like that then it’s much easier/cheaper to do it in isolation rather than trying to do in-circuit debug on the part that’s keeping your server from catching fire (but that’s just my opinion!). [0] : https://github.com/oxidecomputer/helios [1] : https://github.com/oxidecomputer/hubris/tree/020d014880382d8...
In Framework won't be just a laptop company anymore
scottlamb·Mar 26, 2024
Nice read! Nit: // Order the task's regions in ascending address order. // // THIS IS IMPORTANT. The kernel exploits this property to do cheaper // access tests. regions.sort_by_key(|i| region_table.get_index(*i).unwrap().1.base); I wouldn't put this comment here. It's not just some detail of this function; it's an invariant of the field that all writers have to respect (maybe this is the only one now but still) and all readers can take advantage of. So I'd add it to the `TaskDesc::regions` docstring. [1] [1] https://github.com/oxidecomputer/hubris/commit/b44e677fb39cd...
In Who killed the network switch? A Hubris Bug Story

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.