HN Reader

Author here.

I wrote this book so you can spend a boring weekend writing an operating system from scratch. You don’t have to write it in C - you can use your favorite programming language, like Rust or Zig.

I intentionally made it not UNIX-like and kept only the essential parts. Thinking about how the OS differs from Linux or Windows can also be fun. Designing an OS is like creating your own world—you can make it however you like!

BTW, you might notice some paragraphs feel machine-translated because, to some extent, they are. If you have some time to spare, please send me a PR. The content is written in plain Markdown [1].

Hope you enjoy :)

[1] https://github.com/nuta/operating-system-in-1000-lines/tree/...

Someone probably has a python one-liner for it on leetcode

Very nice, I always enjoy some low-level discussion like this.

I found a small typo/editing glitch on the "RISC-V 101 page" [1]:

- It's a trending CPU ("Instruction Set Architecture") recent years.

It should probably say "ISA" instead of "CPU", and the word "in" is missing from after the parentheses, right?

Edit: Markdown, don't format the quote as code. Oops.

1: https://operating-system-in-1000-lines.vercel.app/en/02-asse...

Very cool! I just started to dvelve into RISC-V, and the book I'm reading (not in English) offers their own emulator[1], which, at a glance, is much simpler than QEMU, and comes with a weird license[2]. I wonder if people actually used it, since it looks like an academic project. Maybe I can also follow this tutorial and test it out.

[1] https://github.com/NJU-ProjectN/nemu/tree/master

[2] https://github.com/NJU-ProjectN/nemu/blob/master/LICENSE

Edit: wrong link

This looks great, thank you for making this.

The article nicely explains how to build a minimalist OS — works great as an intro material. I think understanding basic OS concepts is essential for performance tuning and debugging.

I never counted, but my first professional software project was an operating system (firmware) for an RF switching box. It was written in 8085 ASM, and was probably in the neighborhood of 1,000 lines.

Apples to oranges, though. It was a specialized firmware system. Probably the biggest part was the IEEE-488 communications handler.

I'd love to try implementing this in some other languages.

Two projects mentioned by this one:

  https://github.com/nuta/microkernel-book/
  https://github.com/mit-pdos/xv6-riscv

Good stuff! Saving it for the weekend because I'm such a slow reader!

Cool! Will be interesting to compare to https://github.com/mit-pdos/xv6-riscv!

Shameless plug for my html version of the xv6 book: https://xv6-guide.github.io/xv6-riscv-book/

I’m interested in the use of things like virtio instead of real hardware.

Are there other virtualisation-driven designs for hardware devices out there rather than the qemu stuff?

For any rust enthusiasts, phil-opp's guide is such a fun exercise to try out. It was actually the first thing I tried in Rust (very silly idea) and ended up only understanding ~5% of what I had just typed out.

I tried it again 2-3 years later and took the time to go over each subject. I even planned in advance to make sure I was going to finish it.

Very delightful article. Based on my experience in "hobby" OS programming, I would add setting up GDB debugging as early as possible. It was a great help in my projects and an improvement over debugging with the QEMU monitor only.

QEMU contains a built-in GDB server, you'll need a GDB client built for the target architecture (riscv in this case) and connecting to the QEMU GDB server over the network.

https://qemu-project.gitlab.io/qemu/system/gdb.html

This article brilliantly demonstrates the elegance of simplicity in systems design, proving that even complex concepts like operating systems can be demystified with clarity and minimalism. It's a reminder that understanding fundamentals often unlocks deeper innovation. How might this inspire rethinking other "big" systems?

This looks nice! I would love to have an ebook version to read on my ereader. I wonder how much effort it would take to use the markdown files in the GH repo and convert those.

[0] https://github.com/nuta/operating-system-in-1000-lines

This looks nice. Thank you! Been considering something like that for quite a while now (Since my own risc-v CPU, written in VHDL, is working actually). I might get this as inspiration and rewrite it in Rust (tm) - Because I wnat to learn Rust, too

> The tricky part of creating your own OS is debugging.

The older I get, the more I think I can figure out most problems that don't require some really gnarly domain expertise if I have a good way to iterate on them: code something, try it, see the results, see how they compare with what I wanted. It's when pieces of that are difficult or impossible, or very slow, things get more difficult.

This is on my to do list of things to learn but I also don't know yet the purpose other than it being your own. Maybe security since most of what I work with is on top of the OS eg. programming languages. Maybe for RTOS applications at any rate this and OS Dev good resources.

Ah yes, I have a few (too many as always, but I think that's good, especially when getting older; need to not get complacent) resolutions for 2025, one of them is to write a OS/DB with a development environment. Just to see how far I can take it. So these kind of tutorials are great. I was already going to make it RISC-V first because i'm interested.

Very cool to see someone tackling a small OS for RISC-V.

Shameless plug: I've written hobby OS (well, a kernel actually) in Nim for x86-64[0] and it's all documented as well. I put its development on hold until I create a JetBrains plugin for Nim (in heavy development right now).

[0] https://0xc0ffee.netlify.app/osdev

I started a toy OS years ago based on the book Operating System Design by Douglas Comer. Personally I just couldn't get excited about anything that didn't run on real hardware, so I made mine for Raspberry Pi.

Is there any real hardware that this could run on?

Looking through this seems to use a lot of assembly. In the above the amount of assembly is kept to a minimum. Pretty much just bootstrapping and context switching. The rest is done in C.

Just a small typo in the RISC-V 101 chapter. It says "it's a trending CPU (ISA) recent years." I believe it should read "in recent years."

A noble idea, but Github is literally littered with hobbyist home-grown Unix-like kernels in C.

As an industry are we not supposed to be trying to move away from hoary old unsafe C?

Could we not have a hobbyist educational OSes in more of the C replacements?

Drew DeVault wrote Bunnix in Hare, in one month. There's the proof of concept.

How about tiny toy Unix-likes in Zig, Nim, Crystal, Odin, D, Rust, Circle, Carbon, Austral?

How about ones that aren't ostensibly suitable for such tasks, such as Go or Ada?

Yes I know Ada is not a good fit, but there has already been a Unix-like OS entirely implemented in a derivative of Pascal: TUNIS.

https://en.wikipedia.org/wiki/TUNIS

This might need work from skilled expert practitioners first. That's good. That's what experts are for: teaching, and uplifting newbies.

There was a project to do C# on the bare metal.

https://migeel.sk/blog/2023/12/08/building-bare-metal-bootab...

How about a Unix-like in C#? Get the Unix and .NET folks interested in this stuff.

Even if the OS never leads to anything, maybe the tooling might prove useful. I am sure someone somewhere would have uses for bare-metal GoLang.

Saying that, I really don't think we need any more Unix-like OSes. There are far far too many of those already. There is a huge problem space to be explored here, and there used to be fascinating OSes that did things no Unix-like ever did.

OSes that are by modern standards tiny and simple but explored interesting areas of OS design, and are FOSS, with code out there under permissive licenses:

* Plan 9 https://github.com/plan9foundation/plan9

* Inferno https://github.com/inferno-os/inferno-os

* Symbian https://github.com/SymbianSource

* Parhelion HeliOS https://archive.org/details/Heliosukernel

There is already an effort at Plan 9 in Rust:

https://github.com/dancrossnyc/r9

Why not Plan 9 in Zig, or Hare, or even D?

Plan 9 imposes and enforces considerably more simplicity on C as it is: you can't #include stuff that already has #include statements of its own. The result is a compilation speedup of around 3 orders of magnitude. That would be a benefit to the would-be C replacements too, wouldn't it?