Writing an Operating System Kernel From Scratch
Posted4 months agoActive3 months ago
popovicu.comTechstoryHigh profile
excitedpositive
Debate
20/100
Operating System DevelopmentRisc-VZig Programming Language
Key topics
Operating System Development
Risc-V
Zig Programming Language
The post discusses writing an operating system kernel from scratch, sparking enthusiasm and sharing experiences among commenters, particularly around RISC-V and Zig.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
44m
Peak period
66
Day 1
Avg / period
23
Comment distribution69 data points
Loading chart...
Based on 69 loaded comments
Key moments
- 01Story posted
Sep 14, 2025 at 11:44 AM EDT
4 months ago
Step 01 - 02First comment
Sep 14, 2025 at 12:28 PM EDT
44m after posting
Step 02 - 03Peak activity
66 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 27, 2025 at 2:33 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45240682Type: storyLast synced: 11/20/2025, 8:37:21 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Though I'm unsure how differing licenses might have affected this - I suspect that really early in it's development the "copyleft" nature of the GPL Linux didn't make as much of a difference, as from what I remember most commercial uses of Linux didn't come until it had already gained significant momentum.
Copyleft encourages a collaborative relationship between entities because it makes trying to play it close to the chest with IP involve more legal effort (if it's possible at all).
Commercial support for Linux was... Sparse... before the early 2000s.
Agreed, funnily enough GNU tools/compilers also ended up getting installed on a lot of proprietary UNIXes because proprietary UNIX was mostly shit (in user space!). At least most of the ones I had the misfortune to have to work on.
If Stallman had started with a kernel, there would be very few people who had the legal right to run any utilities or apps on the new kernel whereas GNU's utilities and apps (e.g., Emacs) were immediately useful (i.e., without breaking any copyright law or violating any software license) to a large population, namely, anyone with an account on a proprietary Unix system, which explains why Stallman chose to start with the userland.
In the Unix world, there was no tradition of binary compatibility: you couldn't just take a binary compiled for NeXTSTEP and run it on Solaris or on Linux: you needed to recompile, which means you needed a C compiler and the source code for the program you want to run, and most users of Unix in the 1980s didn't have a practical way to get the source code (and if he did have access to the source code, using to to port the program to a new kernel was probably a copyright violation). Stallman could have tried to start a tradition of binary compatibility in the Unix world. That is one of the strategies he could have chosen for the GNU project: i.e., he could have picked a proprietary Unix, Solaris, say, and make sure the kernel of his GNU system could run all (or most) binaries that run on Solaris. But that strategy ran the risk that the owner of Solaris might have sued to stop this and the courts might have sided with owner, requiring the GNU project to shut down, pay the owner (Sun) a lot of money or start over with some other strategy.
I found a shorter reply to your comment, which I will now write:
>when it comes to the GNU project and the whole Free Software movement is the ability to run _any_ program, be it non-free software or free software.
Just because the GNU project allowed non-free software to run on GNU doesn't mean there existed in the 1980s a userland that would run on GNU if GNU had consisted of just a kernel (or just a kernel and a C library and a C compiler).
https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/Sw...
> (Linus Torvalds, regarding the fact that Linux started off as a terminal emulator.)
http://neil.franklin.ch/Jokes_and_Fun/Linux_Quotes.html
That's the best reference I can find, but even if it's totally legit it doesn't make any sense to me.
BTW, in early versions of Slackware emacs was bundled in its own software category due to its huge size when selecting which packages to install on first boot.
> Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).
> I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-)
> Linus (torv...@kruuna.helsinki.fi)
> PS. Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.
I wouldn’t call it incredibly impressive. The path on how to write a minimal multi-tasking kernel has been beaten decades ago.
Writing a kernel that can boot and do a few things is ‘just’ a matter of being somewhat smart and have some perseverance. Doing it for RISC-V complicates things a bit compared to x86, but there, too, the information about initialising the hardware often is easily obtained (for example: https://wiki.osdev.org/RISC-V_Meaty_Skeleton_with_QEMU_virt_... I wouldn’t know whether this project used that)
I think the author agrees, given (FTA) that they wrote “This is a redo of an exercise I did for my undergraduate course in operating systems”
It’s work, may be nice work, but I think everybody with a degree in software engineering could do this. Yes, the OS likely will have bugs, certainly will have rough edges, but getting something that can multi-process, with processes shielded from each other by a MMU isn’t hard anymore.
Ideally this would be true, but it hasn't been my experience at all. At least with American graduates, I can't speak to other countries.
This made me look up what he has been up to, there is a 2023 edition of "Modern Operating Systems" which covers cloud virtualization and Android along with everything that came before, hm, tempting.
And if you do want the more historical content, https://www.projectoberon.net/
I was studying at Monash, which is considered a solid university here, and holy moly are the standards low. I had classmates in the second year of my machine learning postgrad asking me things like "What is machine learning?", and they all graduated and found jobs anyway.
Which is odd since their universities have built two of the most interesting CS projects I can think of (Mercury and L4). And WWWJDIC I suppose.
Besides it's much easier nowadays, if something's wrong you can feed ChatGPT your GDT definition for example and find out if you misplaced a value, which used to be a PITA to debug.
As the parent comment says, I think the path to a booting usermode kernel has long been beaten, it's not trivial but it's not that hard either, I believe the impressive stuff is once you get out of "tutorial land" and implement a network stack, or a UI stack, etc.
IMHO, if you use a reasonable bootloader, you don't have too much boilerplate. Multiboot loaders do leave you in real mode, and most people want to be in protected mode, so you have to set up some tables and do a jump, but that's not that much boilerplate. There's a bit more stuff if you disable legacy interrupt controllers (which you probably want to) but it seems to me being able to maybe run on a regular pc is worth it (caveats about console interfaces apply... my hobby OS needs bios boot and uses some vga things that I found aren't well supported... serial console is easier, but lots of computers don't have a serial port either)
Single-threaded kernel bringup is easier than most distributed systems though.
C was never special, beyond being widely available thanks to UNIX original licensing.
https://www.qemu.org/docs/master/system/target-riscv.html
https://aliexpress.com/w/wholesale-Milk%2525252dV-Duo-S.html
Taken directly from its description:
>Milk-V Duo S is an upgraded model of Duo with an upgraded SG2000 master with a larger 512MB RAM and extended IO capability
>Onboard WI-FI6/BT5(Model Milk-V-Duo-S-512M-Basic/Milk-V-Duo-S-512M-eMMC does not have this function)
>USB 2.0 HOST port
>100 Mbps Ethernet Portwith PoE Support (via PoE HAT)
>Dual MIPI CSI with ISP
>The device also supports switch between RISC-V and ARM boot via a switch
https://www.kickstarter.com/projects/starfive/visionfive-2-l...
I don't have a first version visionfive2 myself, but i heard good things about it and the eco-system sounds like it's growing. There are still rough edges. Lets hope they ship soon (tm)
Edit: What I currently have for my personal projects is a PolarFire SoC Discovery Kit. That's a quad-core RISC-V system with FPGA embedded. Maybe too expensive and not for everyone (130 bucks, fun fact: The dev board is cheaper than the chip itself).
https://www.microchip.com/en-us/development-tool/MPFS-DISCO-...
Also the microchip documentation, toolchain and so forth feel really crappy and old, but once you get used to it, it's not that bad and actually getting to run bare-metal risc-v code is easy. There are easy examples for linux and bare-metal
Of FFS...
one thing is using http but another this one…
How are people getting around this problem, I guess VPN? I mean, some of the wrongly blocked IPs are needed for work I imagine.
These people are criminals..
Or, asked differently, with no knowledge of Zig, what would be a realistic approach to trying this out? (Assuming an interest in learning Zig, with a background in C++)
i love how accessible riscv isa is, the docs are amazing, there are tons of examples, and tons of emulators, the uncompressed machine code is quite readable.
i am writing a book for my daughter and am also working on a small os with forth and timesharing https://punkx.org/projekt0/book/part1/os.html and i dont think i could've done it on x86, learning both forth and riscv assembly on the way, its super fun.
honestly if you ever wanted to make a toy os from scratch there is no better time to start than now (besides maybe 1980), get a cheap riscv like rp2350 and just upload the relevant sections of the docs to claude and it will help you if you get stuck.
there is an issue that language models have seen enormous amounts of rp2040 code and docs, and it they get properly confused a lot, so you should just pdf print relevant pages and use them in-context.
Also go ahead and try hard things like your own cryptography. The advice “don’t roll your own crypto” just means don’t DEPLOY something that is not battle tested, because it is very easy to make BIG mistakes in that area. Always feel free to experiment and explore.
We need more operating systems, more choice.
https://news.ycombinator.com/item?id=45236479
Copying their comment to here:
I have redone the classical exercise of writing a tiny OS kernel with time sharing, which manages a couple of user threads. My goal was to experiment specifically on RISC-V + OpenSBI. Additionally, I wanted to explore Zig a little bit, so that was the language used instead of the traditional C, but it should be straightforward how to do the same experiment in either C or Rust.
It's definitely very rough around the edges, and it's more of an experiment and an intro for people who want to go through step 0 of learning OS kernel development and computer architecture. Nevertheless, I hope it is still a fun experimental thing to play with over the weekend!
The full walkthrough and the GitHub link are available at the link posted!