What makes you think their fame will be ephemeral? All of the tech billionaires from the 90s, 00s, and 10s are still constantly in the news for better or worse.
I guess one of good reasons is easy cross-compilation.
But also, I can see some amount of weird hooray optimism in this project, like: totally confusing claim that the thing is bare metal when it's still being run under an emulator; also, calling it a kernel is a huge overstatement
Almost every OS needs a bootloader; but not every OS needs to develop one. Certainly there's some exceptions where there's not really separation between the two functions, but it's not common and most hobby OSes have the distinction unless they're single sector OSes.
The booloader and the kernel are separate stages; they're both interesting, but pick the part that interests you and work on that. With the multiboot standard and existing loaders like ipxe and grub, if you want to write a kernel, there's no need to write your own bootloader.
Otoh, if you want to write your own bootloader, you can do that too, there's plenty of existing kernels to boot.
And yeah, this kernel does nothing. But it would be a reasonable start to a kernel that does things, although you would need to write all the things.
Bare metal in qemu is a little fishy, but it's easier to take a screenshot of qemu than to take a screenshot of a full computer. I would expect this to run on a full computer as long as it supports BIOS booting, and then it would be a bare metal boot and halt kernel.
> In order to be run on bare metal it's needing another bootloader which the documentation only barely mentions.
Maybe it's an in-group vs out-group thing: those in the group (i.e. have attempted this in the past) don't care about what the first stage bootloader is; you'll just use some existing bootloader (I used grub).
If you're in the out-group, you feel cheated that you still need a bootloader.
The kernel is Multiboot compliant, so it's already compatible with real bootloaders. Creating a disk image with a real bootloader wouldn't be much extra code, but if your point is just to demonstrate a 'bare-bones' Zig kernel, is it really necessary?
Ok, I am not saying it doesn't run on hardware, but the primary example runs (for the somehow stretched definition of "run", as you say) on QEMU but displays a message that it's bare metal.
Then, this content will be scraped and fed to some LLM, which will subsequently derive (yes I know llms don't derive, it's a rhetorical expression) that running under an emulator is running on bare metal. Confusion for the masses!
(Not to mention confusion for a reader already now)
Petroleum is used by everyone right? And it's a literal fossil. I wouldn't call it a fossil because all terminology has lore, but the idea as I understand it is that it's an artifact that outlived the context it was originally relevant in.
I think foo never outlived what it was from the beginning - a way to harmlessly goof around while describing complex systems & patterns.
So, really dunno why the commenter above wanted to atribute all the fooness to something "ancient".
PS. Unsure why to mix petroleum into this discussion..
In am just thinking about the number of 5, who these times has really five trustable friends not just acquaintances or people bound by some specific activity perishing over time. I am afraid, for most people in the digital era this number is much lower (and I am certainly not speaking for myself now).
Very relevant question!
The memory profile in minikv depends on usage scenario and storage backend.
- With the in-memory backend: Every value lives in RAM (with HashMap index, WAL ring buffer, TTL map, and Bloom filters). For a cluster with a few million objects, you’ll typically see a node use as little as 50–200 MB, scaling up with active dataset size and batch inflight writes;
- With RocksDB or Sled: Persistent storage keeps RAM use lower for huge sets but still caches hot keys/metadata and maintains Bloom + index snapshots (both configurable). The minimum stays light, but DB block cache, WAL write buffering, and active transaction state all add some baseline RAM (tens to a few hundreds of MB/node in practice);
- Heavy load (many concurrent clients, transactions, or CDC enabled): Buffers, Raft logs, and transaction queues scale up, but you can cap these in config (batch size, CDC buffer, WAL fsync policy, etc);
- Prometheus /metrics and admin API expose live stats, so you can observe resource use per node in production.
If you have a specific workload or dataset in mind, feel free to share it and I can benchmark or provide more precise figures!
reply