Ask HN: What would justify writting an OS kernel in 2026?

There are a lot of things that could be fixed like (off the top of my head) fork() and making filesystems async. A new kernel probably won't be adopted but there's still technical work to do.

Fun, primarily. Or to learn. Or perhaps to show that something never done before (some unique combination of features) can be done. "Because the mountain is there".

Imho: if that doesn't do, don't even start. Or find existing project & contribute to that.

Myself, I've been wanting to dive into Forth systems. And get some hands-on experience with RISC-V assembly. So, over the past winter I've put together lots of bits & pieces of a small Forth-like system, targeting RV32I (eyeing the RP2350pc as a target device).

> Linux won

No, my Forth is much better! It'll be able to run on devices that Linux couldn't possibly ever run on (~10 KB ROM, similar size RAM), easier to understand, easier to change, doesn't need multi-GB software install to develop, should boot in milliseconds. And I wrote it myself - no AI.

Just saying... Linux is great for many things. Other OSes (or -kernels) good for other things.

> I am making my own systems programming language, called Tig.

Link?

Edit: same question posted 17 days ago? Hmm...

A kernel that it's primary language is a memory safe one? But other than that there aren't many reasons that would justify writing from scratch.

Writing an OS kernel is fun, but very few OSes have wide adoption. That's not a reasonable goal to have, unless you've got a large customer lined up where your OS fills a need for their product intended for wide distribution.

If you want to build an OS, build it for fun, build it because you're bored, build it to learn, maybe even build it to show your language is capable of doing it. But don't build it with the expectation that it will get a large amount of use.

Especially if your OS is intended to be general purpose. If you wanted to build an OS for embedded stuff, you might find a niche, resource constraints mean there's more room for variation and making tradeoffs.

All Unix-like systems have made a lot of mistakes. There is a chance to fix them. Here is the list of some of possible improvements:

Pointer + size strings in APIs (not null-terminated strings).

Asynchronous APIs as default choice.

Proper process spawning, not forking.

Restrictive process rights management (with each process seeing only a slice of the whole file system and overall system resources).

Non-monolithic design (with no need to integrate all drivers into the kernel).

Probably many other improvements.

> Linux won

Linux started at the peak of Unix, but also when Unix was getting fragmented across vendors and mired in lawsuits. At the same time, PC hardware was getting better and faster, making the timing great for a PC-level Unix-like OS. Also remember that Linux didn't win in a short period of time. It would take over a decade (I'd say maybe two) for it be taken seriously.

I've come to the conclusion that technical superiority doesn't matter much. What matters is grit, perseverance over a long horizon, building an ecosystem (especially hardware drivers), accepting collaboration (be kind, not necessarily nice), and fostering a welcoming community.

I do see the point if you focus on embedded systems that struggle running a monolithic kernel like Linux, implementing a microkernel architecture and an efficient, open user space surface to run drivers that different vendors could develop for their various products. It's a small niche, but there's some room for it.

[dead]