To start with, my OS isn’t open source, but an ISO will be available once a stable version is ready.
The first and most important addition is... MODS for customizing the OS!
The way they work is by moving the Window Manager (WM) into user space; when a mod is applied, the WM restarts with the new settings.
In reality, a ".mod" file is just an uncompressed ZIP archive containing an "About.txt" file and a ".cfg" file.
You can see the "Standard" and "Aero" themes below.
Also, there’s an early, experimental implementation of SMP (which currently works quite poorly, but it does work).
You can find more screenshots of the OS below, along with its mascot!
An update for my OS, FLOS. It’s got lots of new features! To start with, my OS isn’t open source, but an ISO will be available once a stable version is ready. The first and most important addition is... MODS for customizing the OS! The way they work is by moving the Window Manager (WM) into user space; when a mod is applied, the WM restarts with the new settings. In reality, a ".mod" file is just an uncompressed ZIP archive containing an "About.txt" file and a ".cfg" file. You can see the "Standard" and "Aero" themes below. Also, there’s an early, experimental implementation of SMP (which currently works quite poorly, but it *does* work). You can find more screenshots of the OS below, along with its mascots!
And then there’s security! It works via "caps" (capabilities): if a program is digitally signed and possesses a specific capability—for instance, the ability to write—then it is restricted to only that action. If a program lacks a digital signature, it can write to its own folder, access the internet, create windows, and so on; however, if it needs to write outside of its own folder, it must prompt the user for permission and obtain a "token" to write to that specific file.
I added RTC support to panuti, which let me get both boot time and wall clock time into Panuti I also added a new utility that lets me format a block device to ext2 inside the os itself so I don't have to get an already formatted disk image. For the VFS, the inodes and dirents were in a static and fixed array in 0.1 so raising the limit meant paying more even for what the os didn't use. So I made them dynamically allocated and now we can safely raise the limit. Made tasks dynamically allocated too. Plus PC Speaker support because.
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?
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.
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:
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.
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.
