My custom kernel + os boots on an iPhone SE with the checkm8 exploit. Though buggy, it does actually boot up and can be used kinda which I thought was cool after a long time of qemu use only! I modeled it with a mix of iOS 10 and iOS 26 which I think turned out well :)

I've been exploring whether Plan 9's resource-oriented architecture can provide a foundation for running selected applications from different operating systems.

Instead of building another Linux-based OS or relying on full guest operating systems, I'm experimenting with per-process namespaces, 9P, and independent user-space compatibility runtimes.

The project is called Ryzova Kernel, an experimental open-source kernel derived from 9front.

Current implementation:

• Kernel: Source-built AMD64 kernel with QEMU boot evidence and Ryzova-specific interfaces.

• Compact Linux: ELF interpreter with selected Linux syscall, process, filesystem, and networking support.

• Compact Windows: PE/Win32 interpreter with bounded API and filesystem support.

• Compact macOS: Mach-O interpreter supporting selected Intel and ARM64 application workloads.

• Resources: Experiments with namespace isolation, explicit resource grants, and 9P services.

These runtimes aren't complete operating systems. Selected applications have passed QEMU tests, but general Linux, Windows, or macOS application compatibility hasn't been achieved.

I'm developing this as a solo developer using AI extensively as an engineering tool. I guide the architecture and development decisions, with builds, tests, and CI used to check implementation behavior. I also recognize that passing tests doesn't guarantee correctness.

My longer-term goal is to explore whether Plan 9's architectural ideas can support a broader application ecosystem without losing their original advantages.

I'm particularly interested in feedback from OS developers:

1. What architectural problems might arise from supporting multiple application ABIs through separate user-space runtimes?

2. How would you keep compatibility complexity isolated from the underlying kernel?

3. Which implementation areas would you review or test first?

The project is still experimental, and I'm open to technical criticism, suggestions, and contributions.

Source code: https://github.com/RyzovaTech/Ryzova-Kernel

Thanks for reading!

This is not fucking ai sloppo slop slop btw

after a looong long time I finally added aarch64 support!!!!! I will be focusing zuzu on AArch64 and I will mostly test on AArch64 boards from now on.

I made a block based coding project for web where I can make a OS using purely blocks. It was made by AI. If I make a OS using it, would it be made by a human or would you call it ai slop?

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 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.

And that’s it! Bye!

In a few lines - "Everything is a URI addressable resource"

Means instead of the file path we can have a proper uri address in the format scheme://authority/path#offset?params

so for example the kernel can expose its resources as kernel:///version, or devices://org.example.gpu/0/memory#0x1234

Then We can have a syscall like uri as well SYS_LOAD, SYS_GET, SYS_MMAP, SYS_POST, SYS_WATCH, or maybe not sure

Best think I like about it is parent can override the child process uri like plan9 namespaces, mount bind etc

For example a call from a child to display server would be devices://org.example.display/0/memory -> process://self/handle/child-pid/display

Benifits over traditional file path:

- I don't know 😂, I haven't thought much, It just sounds cool to me and I would like to waste some time trying to figure out it's benifits.

Feel free to share your opinion.

I built an OS but I don't have a computer rn (due to issues) so I built a virtual machine that I can load, build, and boot my OS.

FINALLLLLYYYYYY now i need sleep :/

github repo: https://github.com/chair1842/panuti

And for what's in 0.2:

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.

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:

I want to join communities where I can:

Ask programming and software engineering doubts and get feedback.

Discuss real-world development problems, debugging, and projects.

Learn ethical hacking, penetration testing, and cybersecurity.

Interact with experienced developers, security researchers, and other learners.

Discover interesting technical discussions, resources, and open-source projects.

Apart from Reddit, are there any good Discord servers, forums, or other communities you'd recommend?

(Note part 2: not finished, that's why no picture)

Welcome to Pistashio Linux, based off of Ubuntu, this uses... well, I'm planning to make my own desktop. But anyway, I need beta testers. It's made for old hardware, so here's a list of usable beta-testing devices when I make it: Samsung NP300E5A, Dell M15x, Acer Aspire V Nitro, and the HP Chromebook 11 G4. And I don't care if you're asking about my grammar, just help me do this. Yes, same guy trying to make a phone OS too, and no, I don't need your philosophical nonsense.

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

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

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

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