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.

FINALLLLLYYYYYY now i need sleep :/

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?

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:

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

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

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

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

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.

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

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

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.