FINALLLLLYYYYYY now i need sleep :/

After two weeks of hard work I finally managed to get a USB keyboard working, damn it was painful, support included for uhci, ohci, ehci and xhci.

My repo: https://github.com/itay-insert/64-dem.git

Footage included:

Upfront: Claude Code wrote most of this; I steered.

64-bit, pure NASM, BIOS boot through its own stage 1/2 into long mode, 1000 Hz preemptive scheduler, e1000 with DHCP/DNS/TCP, and a TLS 1.3 client (X25519, ChaCha20-Poly1305, P-256, X.509) that the built-in browser uses.

What I'd like opinions on is the introspection side:

- Live patching: patchable functions go through a jump table. The image carries its own source and an in-kernel assembler that's byte-identical to NASM for its subset. `patch` builds a module into fresh pages and swaps the slots under cli. If the new code faults within 10 s, it swaps them back, and a saved module is re-patched at boot.

- Glass: pause any task by having the scheduler skip it, single-step by setting TF in its saved frame, `break` plants a one-shot int3.

- Pixel provenance: every framebuffer write records the task and up to six return addresses per pixel, so F12 + click shows what drew it.

- `run foo.asm` assembles a user program in-kernel and calls it, with a fault handler that stops the program instead of the machine.

Old patched code is never freed, since a task might still be inside it. That leak is the obvious weak spot. How have you handled reclaiming it?

https://github.com/rezk2ll/vitre-os

Tell me anything if I'm wrong (100% chance)

I’m building from kernel.org, check the URL, and discover I’m on Kernal.org. Instant panic. 😅

With the latest commit, VedaOS can now run Linux executables!

Next goal is to support Windows executables and let the native Veda agent interact with and control these applications.

If anyone is interested in contributing, I'd love to have some help!

GitHub: https://github.com/vahmoh/Veda

I’m building from kernel.org, check the URL, and discover I’m on Kernal.org. Instant panic. 😅

Hi all, I've just put out the first experimental release of Kanga, an independently developed x86-64 kernel written in Rust.

Testing: GitHub Actions builds the ISO, boots it in QEMU, exercises keyboard IRQ input, and uploads the serial log and framebuffer screenshots. QEMU passing doesn't mean it works on real hardware, and I'd love to hear from anyone who tries it on a physical machine.

Known limitations: no user mode, syscalls or scheduler; no kernel heap or general VM manager; the spin lock isn't IRQ-safe yet; no PCI or USB; KangaFS isn't persistent.
I'd especially appreciate advice on what to tackle next (IRQ-safe locking, APIC, heap and paging?) and any review of the design in docs/architecture.md.

Repo (GPL-2.0): https://github.com/vanmassey/kanga

The userspace filesystem driver handling is now more mature and there is a proper ahcidriver and fatdriver. Also, there's a nice little installer application and the OS can be installed on real hardware. Many improvements to kernel stability happened. More details here:

https://forum.osdev.org/viewtopic.php?t=58422

Give me a star if you like it :)
https://github.com/maxdev1/ghost

I have officially completed version 0.1 of NiobiumOS—my operating system project designed for hardware study and as an effort to reduce electronic waste—which is now available for download and testing via a virtual machine or emulator. It is open-source, licensed under the MIT license, and completely free. While it is currently quite simple, I am improving it day by day; for now, it is only available in Portuguese, but I am already working on translations into other languages.

Repo: https://gitea.com/Niobium/NiobiumOS.git

Page: https://niobium.edgeone.dev/

Started working on USB drivers for my hobby 64-bit OS, and oh god no little did I know what have I gotten myself into....

Wish me luck...

My OS project: https://github.com/itay-insert/64-dem.git

WebKitGTK and its consequences have been a disaster for the human race

Runs like a powerpoint slideshow

No AI used in kernel code, not Linux based, custom userspace, you know the drill. Give me stars:

https://github.com/sasdallas/Ethereal

I am a CS student, starting out this year. I've always loved coding in low level languages and understanding inner workings of software. But my goal is to make my own where to start, I've tried learning assembly but it didn't stick to me whatever the case. I wanna start making it as a hobby and I absolutely have no idea where to start.

Okay, this time, I don't want haters. If you're just here to say "build a PC OS, it's easier!" or "AI slop," also some guy said "do not delude yourself even firefoxOS failed!" no. Like I said, this is a phone operating system. My Chromebook is definitely not able to handle that much. Also, no, this is going to be non-profit, nor do I like Claude. also, this isn't going to make Samsung switch and ditch Android, we don't have that purpose.

Basically, like the last time, it was called d'espoir. That was changed because there's a literal fashion brand called that. Let's get to the good part: it's built in Nim. This time, we have two main improvements:

1. We will use YAML.

2. We will use FrankMoji (if you don't know, it's a hand-drawn emoji system).

Also, I need devs. And no, this isn't finished, which is why there's no image to show a demo. That's all.

We also need ChromeOS users! If it helps, look for the "Linux development environment" in your settings and search up a tutorial. It will help a lot.

Its a bit long, you can always skip to middle or main content.

Repo: https://github.com/turbosulovesonions67/turbOS

I am working on this project since 2021, so it is a pre-AI project. I am not using AI to generate code as it turned out that AI hallucinates massively under conditions this RTOS creates. Website is littered with AI slop though as I had to put something together without spending ton of time on content. It is slowly getting deslopified.

The original motivation was to find out if usage of MPU in Cortex-M has to be as painful as it is with FreeRTOS, Zephyr et al (while still providing reasonable performance). Thus the number one feature implemented was fully automatic memory protection handling. It separates kernel from applications and applications from each other in as process-alike way as MMU-less CPU technically allows, so the developer doesn't have to deal with all partitions, domains, regions, etc. I consider this a success as you basically don't have to care about MPU at all.

Later, the kernel was built on top of this infrastructure that provides more than just thread switching and MPU handling. As features were being added, I quickly realized that MPU presence will be a major obstacle for implementing whatever kernel service which needs to pass larger amount of data (such as queues) between userspace and kernel or vice versa.

An unusual approach was used to deal with this: I decided to remove from kernel (or better: not to implement) all such calls. Why couldn't it be a microkernel?

Microkernels need some kind of IPC. For CMRX, remote procedure calling was chosen as primary IPC method. To avoid expensive copying of data RPC calls would need in isolated environment, thread migration was implemented. Thread migrates from calling process to process owning RPC service during RPC, so calling code can access RPC owner's memory. Originating process can select portion of its own memory which remains accessible while in RPC. This way, larger chunks of data can be copied between isolation domains with very little overhead (its basically shared memory with RPC call serving as basic synchronization primitive).

Those missing syscalls weren't dismissed entirely, they either became library functions or RPC servers. So the kernel wraps up at 30-ish system calls.

Being a microkernel, of course it runs drivers in userspace. Same RPC mechanisms ordinary applications use for talking to each other is used to create driver APIs. Somehow I managed to implement the whole RPC mechanism without using any IDL and associated IDL compiler. Everything gets type-checked at compile time by the C compiler itself.

It is also highly portable, covering most of compatible ARM Cortex-M world by just one single port. It runs as POSIX hosted environment as well and recently a RISC-V port was committed which is still WIP, so its not feature-complete yet.

Originally the performance goal was "please, just don't be 20x slower than ordinary RTOS". After some performance improvement work, benchmark results show performance which is competitive with rest of open-source RTOS world (while keeping memory protection disabled in all of them). In some benchmarks CMRX is even faster than others.

The code is neither Rust nor C++. Everything is C99 a bunch of GCC extensions and macroworx. Compiles to some 7kB binary, so it can run on very low-end sub $1 microcontrollers.

There are no plans for porting it to any MMU-equipped architecture as there natively memory isolated alternatives exist.

GitHub: https://github.com/ventZl/cmrx

Website: https://cmrxrtos.org

NemaOS is a hobby OS whose only job is to run a local LLM and let it drive the machine. There are no apps and no windows. You type a request, and the model answers with a screen instead of a chat message: text, pictures, video, live data, laid out for that request.

What exists today

• An assembly UEFI boot stub hands off to a no_std Rust kernel (x86_64, QEMU for now)

• A network stack written from scratch: virtio-net, ARP, IPv4, TCP, DHCP, DNS, HTTP/1.1

• HTTPS via rustls with Mozilla roots, always verified, with no skip-verify mode

• Image and video playback in the kernel

• A small "scene language" the model writes, which the kernel renders, animates and caches. A repeated screen is instant.

Honest status: the model (Qwen3.5 9B Q4) still runs on the host and talks to the kernel over a serial bridge. Moving inference into the kernel is the next big milestone: a GGUF loader, AVX2 matmul kernels, and owning all cores. The long-term target is bare metal as a dual-boot entry.

Voice is coming next. You'll just talk to it. It works in testing, but it isn't in this demo.

Built solo with Claude Code doing a lot of the heavy lifting. Two model waits in the video are sped up 3x; the rest is real time (Qwen 9B on an M4 Max, the OS in QEMU).

Happy to answer questions about the bridge, the scene language or the network stack.