Hacker Remix

Operating System in 1,000 Lines – Intro

1054 points by ingve 2 weeks ago | 121 comments

nuta 2 weeks ago

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/...

sesm 2 weeks ago

> Designing an OS is like creating your own world

Or like building your temple so you can talk to God directly

sohang 2 weeks ago

TempleOS: https://en.m.wikipedia.org/wiki/TempleOS

6510 2 weeks ago

We won't know until we try.

pronoiac 2 weeks ago

If you want PRs, I suggest you set up Semantic Linefeeds* sooner, rather than later. Each sentence gets its own line, and it really helps avoid merge conflicts.

* https://rhodesmill.org/brandon/2012/one-sentence-per-line/

nuta 1 week ago

TIL. It's too late for this book, but I'll try it in the next one.

pronoiac 1 week ago

You have a line per paragraph now, so a quick and dirty version is to add newlines after "[.!?] ", though code blocks might take some fiddling.

johndoe0815 2 weeks ago

Are you planning to also provide an English translation of your microkernel book? That sounds very interesting...

nuta 1 week ago

Unfortunately not. Maybe I'll write another online book like this in English, after building a more practical microkernel-based OS. It's a very interesting topic indeed :D

Rochus 1 week ago

Right, that would be great.

jb_briant 2 weeks ago

"Designing an OS is like creating your own world"

Making video game is also like creating your own world!

And it's order of magnitude less hard than making an OS...

Bonus point, you have a chance to make a living from it!

leonewton253 1 week ago

actually making a video game would be 100x more complicated. Plus kernel developer jobs are more lucrative than most game dev jobs.

jb_briant 1 week ago

Is it really more complicated to make a video game that a kernel? I don't consider myself knowledgeable enough to make a full kernel by myself but I did manage to make a full 3d video game by myself.

Also I'm not speaking about making a game engine along with the game.

Having a kernel dev job is different than making your own kernel, speaking on a "world builder" perspective.

66yatman 1 week ago

Even a 3D game engine can be simpler than a fairly complex operating system.

exDM69 2 weeks ago

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

quruquru 2 weeks ago

Agree, and I'll add 3 other really useful QEMU features for osdev:

1) Record & Replay: Record an execution and replay it back. You can even attach GDB while replaying, and go back in time while debugging with "reverse-next" and "reverse-continue": https://qemu-project.gitlab.io/qemu/system/replay.html

2) The QEMU monitor, especially the "gva2gpa" and "xp" commands which are very useful to debug stuff with virtual memory

3) "-d mmu,cpu_reset,guest_errors,unimp": Basically causes QEMU to log when your code does something wrong. Also check "trace:help", there's a bunch of useful stuff to debug drivers

kotborealis 2 weeks ago

Record & replay sounds really nice, but the actual reverse-debugging is broken, see https://gitlab.com/qemu-project/qemu/-/issues/2634

jannesan 2 weeks ago

thanks for sharing! qemu is very powerful, but it’s hard to discocer a lot of these features

o11c 2 weeks ago

> you'll need a GDB client built for the target architecture

Thankfully, GDB has a multiarch build these days which should work for all well-behaved targets in a single build.

(the place it is known to fail is for badly-behaved (embedded?) targets where there are configuration differences but no way to identify them)

ramon156 2 weeks ago

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.

12345hn6789 1 week ago

It's good but unfortunately he is no longer publishing any further entries. It has been 4 years since the last chapter.

quibono 2 weeks ago

Hey, any chance you could link it please?

vrnvu 2 weeks ago

https://os.phil-opp.com

quibono 2 weeks ago

Thank you!

khaledh 2 weeks ago

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

elvis70 2 weeks ago

And discussed here a few months ago: https://news.ycombinator.com/item?id=40962767 - Fusion – A hobby OS implemented in Nim (110 comments)