Everything in that account has appeared in the last 6mo. Very unnatural commit activity, and clearly contradicts the claim that this is their first OS project. Is linked to a faceless YT channel.

The account is newer because I only recently started putting my projects on GitHub. I've been programming in C and Assembly for a while before that, just locally on my machine.

The commit activity might look unusual because I worked in very intense 12h/day sprints over 14 days.

As for AI, I'm happy to do a live walkthrough of any part of the codebase, explain the design decisions, or answer any specific technical questions about the implementation.

I appreciate the scrutiny though it keeps the community honest!

That's a weird way to put it.

The commit activity looks unusual because it's a completed project whose files were individually committed in alphabetical order. There's no development history.

It's good to have support for real networking hardware, but consider virtio-net as well. A lot of VMs support it and it's more streamlined. 32-bit x86, bios boot means doing a lot of things for compatibility with systems that were old enough to drink before you were born... skipping to simplified virtualized interfaces wherever possible makes a lot of sense; even if your OS can run in 16 MB of ram, you're probably not going to run it on a 486 with 16 MB of RAM and a real parallel IDE drive ... at least not at first. You can always come back and make that work if you want... deferring tricky things until later so you can work on the fun stuff keeps you having fun and engaged with your project.

Also, consider trying to get your OS running on v86. It's fun having your hobby OS work in a browser. The biggest limitations I've run into are 32-bit x86 only, single processor only; but those might not be that big of a deal... looks like your OS is also 32-bit x86 only, and I don't see anything about SMP in your project. If there's anything missing from v86 that you depend on, I've had a wonderful experience with submitting PRs; copy often reworks my patches to be much better before applying them, which I always appreciate rather than a back and forth attempt to get me to make it better :) I've also seen copy (and others) take reported issues and fix them, if you've got a problem that you can't write a patch to resolve.

> Real hardware support is still a work in progress.

I ran into a fair amount of issues with 16-bit code; qemu doesn't check segmentation limits but real hardware does. Real hardware would crash, but it worked fine in qemu. My kernel is multiboot and I use 3rd party bootloaders, but I do SMP, on x86, that involves starting the Application Processors in 16-bit real mode and then moving them into 32-bit modes, but you have to do the segmentation dance correctly until you get there; doesn't help when qemu just lets you do whatever. :P

PS 12 hour days are a lot; hope you're getting all your other stuff done :P

virtio-net makes a lot of sense for VM testing - I'll look into implementing that alongside the RTL8139 driver.

v86 is a really cool idea, having Aurion OS run in a browser would be amazing for demos. I'll definitely explore that.

And yeah, the 12 hour days were intense but honestly I was having so much fun I barely noticed haha. School still gets done though :)

What have been the most helpful reference materials so far?

What's the most memorable challenge you overcame?

What's the coolest or most surprising thing you learned?

Most helpful references: Intel Software Developer Manuals for understanding x86 architecture osdev.org wiki for the basics (GDT, IDT, memory management) Reading source code of other hobby OS projects to understand different approaches James Molloy's kernel tutorial helped me get started

Most memorable challenge: Getting the window manager working with proper overlapping windows and mouse interaction. The z-ordering and dirty rectangle system took me a while to get right, windows kept rendering behind each other or the mouse would interact with the wrong window. Debugging graphics issues without a working debugger in your own OS is... an experience haha.

Most surprising thing I learned: How much modern OSes do that we completely take for granted. Even something simple like moving a window smoothly requires double buffering, proper

careful memory management. Made me appreciate every pixel on my screen.

What kind of OS project are you planning?

I think AI is a great learning tool when you're trying to understand low-level concepts for the first time.

Assembly for anything that HAS to be assembly: bootloader, GDT/IDT setup, interrupt handlers, context switching, and port I/O wrappers.

C for everything else: window manager, apps, drivers, GUI rendering.

Some parts I probably could have done in C with inline assembly but I found writing pure ASM for the low-level stuff helped me understand exactly what was happening at the hardware level.

What choices looked different to you? I'd love to hear your perspective always looking to improve!

What was your inspiration for the filesystem?

The filesystem is currently pretty simple - a basic flat structure on the ATA drive. I was inspired by FAT-style simplicity since I needed something working quickly for the Notepad save/load feature.

Planning to implement something more robust, as the project grows.

What would you recommend for a hobby OS filesystem?

sigh

I started with C because most osdev resources and tutorials use C, and I wanted to understand manual memory management at the lowest level first.

Might explore rewriting parts in Rust or Zig in the future, the safety guarantees do sound appealing for kernel code!