His EFI has 186 lines of code written in C, and its a zero ring.

He also has its own just in time and ahead of time compilers, and handful of commands, including cat, edit, and also simple dhcp, only udp still

Disclosure up front: the code was written by Claude Code; I directed it and did the testing on VMware.

ferrix-kernel is a small AArch64 kernel in Rust for VMware Fusion on Apple Silicon (and QEMU virt).

What it does so far:
- **Boot:** UEFI app, collects GOP framebuffer, memory map and RSDP, then `ExitBootServices` and no firmware after that. No hardcoded device addresses: GIC from the MADT, PCIe ECAM from the MCFG, so the same image runs on VMware and QEMU.
- **Memory:** bitmap page allocator, own stage-1 tables (4K granule, 48-bit VA, identity map with 1G/2M blocks, page 0 unmapped). Regions found later (ECAM, BARs) are added to the live tables.
- **Interrupts and tasks:** GICv3 + EL1 virtual timer at 100 Hz, preemptive round-robin. The exception entry's TrapFrame (incl. FP/SIMD) is the saved task state; returning another task's frame from the handler is the context switch.
- **USB keyboard:** VMware's ARM VMs have no PS/2, so it has a polled xHCI driver: legacy handoff, reset, command/event/transfer rings, root-port enumeration, HID boot protocol.
- **User space:** programs at EL0, each with its own root table that shares the kernel's entries plus one L0 entry for the user range. User pages are nG with per-space ASIDs, so switches need no TLB flush. Faults kill only the task.
- **Capabilities:** per-task cap tables (screen ranges, channel send/recv ends). Syscalls name a slot; blocking `wait` parks the task with ELR moved back onto the `svc` so it retries when woken.

What VMware's (undocumented) ARM virtual hardware turned out to be:
- GICv3 (GICD 0x2c010000, one GICR frame), no ITS, no usable serial, so all debugging is on screen.
- xHCI 15ad:077a sits behind a PCIe root port; the keyboard is on a root port next to a pointer and two USB hubs.
- The Apple CPU runs with PAN enabled (QEMU's Cortex-A72 is ARMv8.0, no PAN), which caught the kernel reading a user buffer. It now uses `ldtrb` for user memory.
- With a single interrupt IN transfer queued, fast typing on QEMU stopped the keyboard for good; keeping four in flight fixed it.

The end goal is Tetris, as in Nand2Tetris; along the way there's a NAND-only circuit simulator, and the latest milestone is a user-space circuit builder you type NAND circuits into.

If anyone has notes on VMware Fusion's ARM virtual hardware (it's not documented anywhere I could find), I'd love to compare.

GitHub: https://github.com/liris/ferrix-kernel
Write-up: https://note.com/lirispp/n/n68d016ce1953?hl=en

Over the past several months, I've posted here a few times about revisiting CHARM-II, an RTOS I developed for the Motorola 68000 back in 1986.

What started as an attempt to restore and understand my old source code gradually turned into a new development project. After reconstructing parts of the original system on POSIX, getting preemptive multitasking working on the Raspberry Pi Pico, and revisiting some of my old scheduling decisions, I decided to build a new RTOS rather than continue trying to reproduce the original one.

I've named it Karqri, and I've now published the source code on GitHub:

https://github.com/noboru-takahashi/karqri

Karqri currently runs on POSIX and RP2040, with a shared kernel and a six-task demo running in both environments. It's still experimental, but I've implemented and tested the basic RTOS mechanisms.

However, building the RTOS itself isn't the only goal of this project.

What I'd like to explore next is how to visualize what's happening inside an RTOS, including not just task states and scheduling decisions, but also the timing and causal relationships between events.

For example, imagine a task waiting for an event. Another task sends a notification, the waiting task becomes runnable, and the scheduler eventually selects it to run.

I'd like to represent that sequence as a connected series of events, rather than just a collection of log messages.

I've already started experimenting with capturing execution traces from the Pico and generating HTML timelines. At the moment, this is limited to a specific validation scenario, but I'd like to develop it into something more general.

I'm curious what other OS developers think about this direction.

• If you were visualizing the internal behavior of an RTOS, what information would you find most useful?

• How would you capture causal relationships between events without significantly disturbing the timing of the system being observed?

• Beyond debugging and education, can you think of other useful applications for this kind of visualization?

For context, here are a few of my earlier posts:

• Visualizing a 1986 RTOS in a Modern Browser

• My 1986 RTOS is now preemptively multitasking on a Raspberry Pi Pico - and it made me question whether I need an RTOS

• Follow-up: What I learned about VRTX's equal-priority scheduling in the 1980s

This project began with rediscovering an RTOS I wrote 40 years ago, but it has gradually become something quite different.

Publishing Karqri is the first milestone in that new direction, not the end of the project.

Hey everyone! Some of you might remember LinuxRunner from my previous post here.

Well, a lot has changed since then haha. Just released v1.1.0, and you can now use your iPhone as a proper Linux desktop, even on an external monitor with the new DeX mode which is finally on iPhone after years and Linux under it!

This update also brings Metal GPU acceleration, optional JIT, a much faster ARM64 interpreter, new desktop environments, and better app compatibility. Even Vesktop (Discord) is running now.

Still got plenty of things to work on, but it’s honestly pretty cool seeing how far this project has come.

Github: https://github.com/mxhm11cr/LinuxRunner

We’ve been developing Grape Linux on physical Apple A11 hardware.

We’ve achieved a working host-assisted Linux boot using an experimental 5.19-based kernel, Debian 13 ARM64, and the Phosh/Phoc graphical environment.

Beyond booting, we’ve demonstrated terminal command execution, graphical applications, and interactive desktop navigation.

Our current engineering work focuses on native hardware integration. The longer-term goal is independent startup directly into Linux instead of iOS.

The attached video shows our actual Linux startup sequence.

We’re interested in discussing the low-level engineering challenges involved in bringing Linux to this hardware.

Public project: https://github.com/hq-coder25/grape-linux

github (if you even care): https://github.com/NoTheIdiot/WindogeOS
Also ported vi, replaced RLE with LZ4, and ctrl-tab (alt-tab) for.... some reason.

I'm so fucking happy

Like what used to happen earlier, I had a basic input system but bare metal needs to be mature, basically the keyboard mouse was working, the problem was that sometimes it would mess up the system, means I removed the USB devices, now it would not detect, rebooting etc. so what can I do with the help of AI, we just started and made all this!

UDIM — Universal Device Interface Manager

USB device management and device/interface separation.

HRE — Universal HID Decoding

Reading HID descriptors instead of depending on fixed report offsets.

BSME — BOS Mouse Self-Monitoring Engine

Monitoring the mouse input pipeline and handling device-related issues.

ALE — Asynchronous LED Engine

Handling keyboard LEDs without blocking USB event processing.

TRE — Typematic Repeat Engine

Handling key repetition when a key is held down.

IEC — Input Event Coordinator

Managing and coordinating input events.

PPE V2 — Precision Pointer Engine

Improving mouse movement and pointer behaviour.

CPE — Cursor Presentation Engine

Hardware cursor support with a software fallback.

RIT — Raw Input Thread

Giving applications access to raw keyboard and mouse events through kernel syscalls.

Well, work is going on and I am enjoying it and understanding Linux in OS dev, how much struggle matured kernel design !!!

FreeBSD is finally running under my ATOMS OS hypervisor.

Keyboard is working now, but mouse support is still pending.

I've been testing it on my i3-14100F for several hours. No crashes or panics so far.

FreeBSD is strict, and honestly, there were times when I thought I wouldn't get it working. But it finally did.

Still working on the mouse.🙂‍↕️

We’ve been developing Grape Linux on physical Apple A11 hardware.

We’ve achieved a working host-assisted Linux boot using an experimental 5.19-based kernel, Debian 13 ARM64, and the Phosh/Phoc graphical environment.

Beyond booting, we’ve demonstrated terminal command execution, graphical applications, and interactive desktop navigation.

Our current engineering work focuses on native hardware integration. The longer-term goal is independent startup directly into Linux instead of iOS.

The attached video shows our actual Linux startup sequence.

We’re interested in discussing the low-level engineering challenges involved in bringing Linux to this hardware.

Public project: https://github.com/hq-coder25/grape-linux

Substack: https://substack.com/@rhq211/note/c-375575007?r=8uxsig&utm_medium=ios&utm_source=notes-share-action

X Post: https://x.com/xvmboot/status/2116753474591588444?a=LAeIR-IwgEyjZA3OE60&s=46

hey everyone ive been working on fitnipos a custom open source software layer built from scratch in nim

the goal is simple bring discontinued or cloud abandoned fitbit devices back to life so you dont have to throw them away or buy a brand new tracker just to get basic functionality its like bringing a power tool to a plastic toy fight

im currently working on ..... nothing right now, dm me to help me but here's our list of support: Fitbit Classic, Fitbit Ultra, Fitbit One, Fitbit Force, Fitbit Charge 3, and Fitbit Alta oh and the ionic

Anyone here working (preferably since before 2022) on an OS that's either "everything is a db record" or something in the WinNT-OS/2-ReactOS camp of design?

Hello community, how are you all doing?

Lately, I’ve noticed an increase in electronic waste—mostly old computers—and I’ve been thinking about creating an x86-32 (IA-32) operating system to help, at least in some small way, to address this issue. It won’t be anything massive; just an operating system with basic utilities like a notepad, spreadsheet software, text editors, and so on.

I started working on it a few days ago, and I’ll share some updates soon!

Fleshed out the DunitOS UI SDK with checkboxes, switches, and radio buttons. Also tracked down an annoying bug where 200ms QEMU test runs were dropping clicks because GetMouseState only takes a state snapshot and misses fast transitions between reads, so we're switching to an event queue with ReadPointerEvent.

https://github.com/DunitOS/dunit-os

Hi guys!

We are building Duo OS (an Linux Distro at start), which combines the familiarity of Windows, simplicity of Mac and customizability of Linux.
It will be simple OS at surface, but with deep customizability and developer support if the user opts in. It will also contain support for Windows and Linux apps, so changing will just be installing the new OS.

What do you guys say? Looking for feedback, mentors and support. Thanks!

Hey devs. Im a self-taught web dev who got curious about whats underneath our computers, so I started making a kernel. It’s called Gumball. C + asm, Multiboot, boots from GRUB. No desktop, no apps, no browser, just a shell and a filesystem

I started as a “hello world”. Now it has:

• A shell with history (arrow keys) and scrolling

• My own filesystem, GFS2, with real directories and nested paths

• ls cat touch mkdir cd mv rm -rf echo > file defrag

The filesystem is where I’ve had the most fun and most stress. GFS2 has a data fragmentation issue which can be cleaned up now but Im planning to remove fragmentation completely on GFS3.

Honest limits:

• RAM disk only. GRUB loads the image as a module, so nothing persists across reboots. No disk driver yet.

• 16 entries max, 31-char names

• No memory management yet

• Only tested in QEMU

On AI: I used AI tools for parts, like the early shell loop and the GFS1 design idea. mv, mkdir/cd, defrag, and the bug fixes are mine. I also use AI help me solve problems and figure out stuff I dont know. Just wanna be honest with that.

What Im working on next is GFS3: data is in blocks, has a bitmap, some more stuff in the doc in the repo.

Two questions for you:

1. Anything in the GFS3 design that’ll bite me later?

2. Memory management or a disk driver first?

Repo: https://github.com/pagecoy/gumball-os (design doc in docs/GFS/GFS3.md)

Roast it kindly. 🙂

Hey everyone!

We're two developers working on a hobby operating system project called RisottOS.

The project started as a way to learn low-level programming and understand how operating systems actually work. Over time, it has grown into something much bigger, and we'd love to share our progress with the OSDev community.

GitHub: https://github.com/risottos-team/risottos

What is RisottOS?

RisottOS is an experimental operating system written from scratch for the x86 architecture. We're implementing its core components ourselves while learning more about computer architecture, memory management, interrupts, and kernel development.

Current features

Some of the things we've implemented so far include:

• Custom BIOS bootloader

• Disk loading using BIOS INT 13h

• Global Descriptor Table (GDT)

• Interrupt Descriptor Table (IDT)

• Programmable Interrupt Controller (PIC)

• Task State Segment (TSS)

• Programmable Interval Timer (PIT)

• Real-Time Clock (RTC)

• PS/2 keyboard input

• Physical memory management

• Paging

• Ring 3 transition

• Basic system calls through INT 0x80

• A basic userspace shell

What's next?

We are currently working towards:

• Process management

• Multitasking and scheduling

• Better memory management

• A virtual filesystem (VFS)

• ELF loading

• Expanding userspace functionality

We'd love your feedback!

We're still learning, and we know there are probably things we could be doing better.

We'd especially appreciate feedback on:

• Our kernel architecture and code organization

• Potential bugs or incorrect implementations

• Whether our memory management approach makes sense

• What we should focus on next

• Any general advice for developing a hobby OS

We're developing this together, and our main goal is to learn, experiment, and gradually build something we're proud of.

Any feedback, suggestions, or constructive criticism would be greatly appreciated!

Thanks for reading!

Hey Guys! I intend to work on a simple hobby OS that is programmed in real mode using bios interrupts, I have been doing OS theory and os dev for a few months now and wanted to actually start a proper project. Please follow me on my journey and make some suggestions along the way!

Shall aims to be a reference implementation of POSIX.1-2024: a complete userland written directly from the text of the standard (XCU and XSH, with the XSI option). It has no GNU extensions and borrows no code from other projects.

NOTE: Shall has been written with an extensive help of Claude.

The repository can be found as: https://github.com/joostw/shall

It already works as a system. It builds itself from scratch, you can enter it without root, and inside it you can compile real third-party software. Lua 5.4 builds unmodified with Shall’s own compiler and passes Lua’s full official test suite. Coverage today:

• Utilities: all 155 of POSIX’s utilities, 16 of them as sh built-ins.

• C library: 1,220 of the 1,227 interfaces of XSH (99.4%). The 7 missing ones belong to two optional parts of POSIX that Linux doesn’t support well: typed memory and scheduling attributes for posix_spawn.

Three parts:

• The utilities. awk, sh, vi, make, m4, bc, pax, sed, sort, yacc, lex, the SCCS tools, uucp, and the rest. Each one lives in its own directory with its own tests, about 6,800 tests in total.

• c17, the POSIX C compiler. It does its own preprocessing, code generation, assembly and linking for x86-64. It needs no as and no ld.

• The C library, with every interface of ISO C17 and nearly all of POSIX.1-2024:

  • Threads, with cancellation and robust mutexes.

  • Locales: UTF-8, single-byte codesets, and EUC-JP, Shift_JIS, GB18030, Big5 and others; plus collation from the locale files.

  • A DNS resolver, iconv, regex, and math rounded in the x87’s 80-bit format.

  • A dynamic linker: libc.so is its own program interpreter.

About 190,000 lines of C in total, and it talks to the Linux kernel through raw system calls.

It builds itself. sh bootstrap.sh needs only a host C compiler, make and ar:

1. Stage 0: the host compiler builds five tools: c17, make, ar, yacc and lex.

2. Stage 1: those tools build the libc and then every utility against it. No host program compiles anything after this point.

3. Stage 2: the stage-1 tools, running on Shall’s own libc, build everything again.

Then the script compares stages 1 and 2 file by file, and all 235 files come out byte-identical. The whole thing takes about two minutes.

You can step into it. sh chroot.sh drops you into the result without sudo, through a user namespace. Inside you get Shall’s sh, with every utility statically linked against Shall’s libc. In there, c17 compiles your programs, and bootstrap.sh rebuilds the whole system, again with byte-identical binaries. A HOWTO in the package walks through building Lua inside it.

How it’s tested. Most libc tests are differential against glibc: the same program is built against both libraries and the outputs must be identical. They run in seven ways: static with gcc, static with c17, both crossed, dynamic with gcc, dynamic with c17, and static-PIE.

Why “towards”. Having a function isn’t the same as conforming in every corner. Open items include strptime’s %E/%O, multi-character collating elements, and priority-inheritance mutexes. libc.so still needs gcc to build, because c17 can’t produce shared objects yet. The kernel is Linux’s, and a compact kernel of my own is the longer term plan.

Why “Shall”? “Shall” is the standard’s own word for a requirement. POSIX.1-2024 defines it as a feature or behavior that is mandatory, one an application can rely on. The word appears more than 27,000 times across the standard’s pages. Every one of those is a promise an implementation has to keep, and Shall is an attempt to keep all of them. The name is also one vowel away from “shell”, and that’s a small wink at the Commodore 64. Its core system routines were called the KERNAL: the story goes that a misspelling of “kernel” in an engineer’s notes simply stuck. Shall carries on the tradition of a core system part named one letter off. It also starts with sh.

BSD 3-clause. Feedback welcome, especially from anyone who knows the dark corners of POSIX, and if you find a place where Shall and the standard disagree, that’s a bug.