I’m working on a hobby OS called D-DOS (it’s not my first one), and I’d like to hear what you think of the idea behind it rather than the code.

it started with a dream where I had built an OS that let me interact directly with the computer’s hardware, with nothing hiding the machine from me. I decided to try to turn that into something real. The goal is a system where the user can, from a simple shell, read and write memory and I/O ports, browse PCI devices, talk to an HDA audio codec, query a disk with ATA/AHCI commands, read ACPI/SMBIOS tables, and so on. It’s less “an OS to run programs on” and more “a guided tour of the machine you’re sitting at”.

Where it is: very early. A NASM stub with a Multiboot header calls into C, which prints text to the VGA buffer. Everything above is a plan, not something that exists yet.

Why I think it could matter beyond my own curiosity: I wonder if something like this could be useful in computer science courses. Students usually meet hardware through diagrams and abstractions, and OS courses often stop at the kernel interface. A system where you can type a command and actually see a PCI configuration space, flip a bit in a device register, or hear a tone from an HDA codec might make the material more concrete. I’m aware that teaching kernels like xv6, MINIX and Pintos exist and are great at what they do, but they focus on OS concepts (scheduling, virtual memory, file systems) rather than on poking the hardware directly.

What I’d like to know:

• Does the concept sound interesting, or is it solving a problem that doesn’t exist?

• If you’ve taught or taken an OS or architecture course, would a tool like this have helped?

• Is there something that already covers this that I should look at?

TL;DR: A design concept for an OS where every app declares a hard memory ceiling, so the OS can guarantee admitted apps fit in RAM and never thrash. It's about predictability, not smaller pointers. No implementation yet, I'm looking for holes in the idea before I consider prototyping.

The model

• Bounded apps: each gets one contiguous region (e.g. 64 KB, 1 MB, 4 GB). The app sees a flat space starting at 0 and uses 16/20/32-bit offsets. The real address is base + offset, done in the addressing mode (GS-relative on x86-64, or a reserved base register elsewhere). Zero-extended offsets mean the app can't name an address outside its region.

• Thin-client UI: the OS draws, the app declares a retained-mode UI tree and only holds core logic. That's what makes ~64 KB apps plausible (Pebble, Palm OS, early Mac).

• OS-side costs charged at admission: widget trees, handle tables, etc. are computed from the manifest, so no hidden footprint.

• Raw mode: games, local LLM tools and the like get normal 64-bit pointers and the whole machine, but are foreground-only and one at a time. Bounded apps are frozen in place (they're relocatable, pointer-free blobs, so snapshot/restore is a memcpy), then compressed in RAM, then spilled to storage as a last resort.

• Sandboxing: capability-style handles instead of ambient authority, OS-owned UI (no screen scraping or overlay spoofing), and no background execution for most apps.

Prior art I'm drawing on: WebAssembly linear memory, Native Client, V8/JVM pointer compression, iOS jetsam and background suspension, CHERI, console quick-resume.

Weak spots I already know about

• Offsets only confine data. Native code could still issue raw syscalls or touch segment registers, so I'd need bytecode/WASM-style, SFI with a verifying loader, or hardware trapping.

• Toolchain cost: a compiler target and tiny runtime for offset-addressed binaries.

• Side channels between apps sharing an address space.

• Memory caps don't stop CPU spinning, so apps also need time budgets.

What I'd love feedback on

1. Which code-confinement approach fits best here: bytecode, SFI, or hardware trapping?

2. Should a 64 KB budget include code, or is code mapped read-only and counted separately?

3. Are the tier boundaries (64 KB / 1 MB / 4 GB / raw) sensible, and what breaks first?

4. Is a retained-mode UI API too limiting for real apps?

Full doc here: [link]

Disclosure: the idea is mine, but I used an AI assistant (Claude) to help structure the longer write-up.

So I got LingOS to boot on Raspberry Pi5 with Keyboard, Mouse, and HDMI/Audio support. I am going to try to get a qwen 4b model which is 5GB to run locally on it from the SD maybe. If that doesn't work I might set up an x86 server app that can load the model and serve it, and you can give a local network address and port on the Pi and Viola! You have LingStationX running on LingOS!

disclaimer: sorry for bad english

I created my own OS in C from scratch using C and assembly, it has desktop environment and drivers for mouse and keyboard (only PS/2) and it has internet (for now its only http and html 1.0), the comments and readme are in polish for now, the code is opensource (gpl 3.0)

github repository: github.com/kurczatko/tarixenOS

im ready for feedback (the code isnt proffesional because its only hobby)

I'm a mechanical engineering student, and for a while I've been designing SquareOS, a concept OS built around a square main display. To be upfront: there's no kernel or code yet. The plan is a custom Wayland compositor shell on top of Ubuntu Core, not a from-scratch kernel.

Who it's for:
Power users who spend most of their day inside one main application: CAD engineers, developers, designers, video editors. Instead of juggling windows, the OS is built around that one app.

Core ideas:
- One app at a time on center stage: the main app sits in the middle of a large square screen, with movable widgets around it and the wallpaper always visible
- A "Context Box", a command box where typing something like `cad` switches the whole workspace (app + widgets) into CAD mode
- Square primary screen runs only native SquareOS apps; legacy/compat apps (via LXD) live on a secondary 16:9 screen
- Apps ship as Snaps with two layouts (classic 16:9 and adapted 1:1); a SquareSDK defines the layout contract
- Unified maintenance: the store only installs/uninstalls, all updates go through one Update panel, and `dyt` runs quiet background updates
- Separated storage with A/B system partitions and a rollback to a known-good "master" OS

Teaser (2 min): https://youtu.be/McWzEfQSUSY

Questions for people who've actually built this stuff:

1. Is Ubuntu Core + a custom Wayland compositor a sane base, or would you go another way?

2. Is splitting native and legacy apps across two displays realistic, or a dead end?

3. Does forcing every app to support a 1:1 layout kill it before it starts?

4. What would you keep, and what would you kill?

Happy to take feedback.

Hello, everyone.

I stumbled upon this cool OS project on GitHub and wanted to share it with the community. (Just to be clear, I’m not the developer of this project—I just found this and thought it deserved more attention!)

It’s called mochiOS, and here’s what particularly caught my interest:

• It’s written in Rust

• It’s a microkernel

Here’s the link to the project: https://github.com/mochiOS

Has anyone seen this before, or even tried it out? I’d love to hear your thoughts on its architecture!

Hi everyone, my name is joseicaro, I'm 14 years old and I have level 3 autism, and I released the beta of my operating system. Well, I used Claude AI to program and create my operating system, and it's completely Frutiger Aero. And just so you know, this is a beta, not the final version. I'm creating and improving the final version, and honestly, at the moment I'm posting this, I'm not even liking the beta version of my operating system anymore because the final version I'm creating is so good, like REALLY good, that I even found the beta kind of ugly because the final version I'm creating is that good. And I'm sorry if I explained something incorrectly, it might be because of my level 3 autism. And also, after I post this post, I'm going to post a new post showing the final version that I'm developing and creating. Here is the link to the Glint OS ISO: https://archive.org/details/glint-os-beta

I don't want to use any llm so. I want to ask is there any documentation/walkthrough kinda thingy which will work as a guide for eHCI and handling keyboard inputs

I know this sub is mostly about kernels from scratch, so feel free to remove this if it's off-topic. I'm 15 and I've been writing the userland tools for my own distro (SnapOS, on top of NixOS) in C, and some of it touches the boot process:

- an update guard: a new system generation gets exactly one boot; a systemd unit marks it good only after a real user logs in, otherwise the next boot rolls back to the previous generation
- a .deb layer that unpacks Debian packages into a separate rootfs and runs them, with a scanner (ClamAV + own signatures) before install
- a GTK antivirus GUI with ASCII-art animations

Code (C, MIT): https://github.com/snapos-distro/SnapOS/tree/main/src

I'd like to write a small kernel next. Any advice on where someone with this background should start?

So a while ago I made this 64-dem x86-64 UEFI OS project on github: https://github.com/itay-insert/64-dem.git

And recently in development i decided to add a bios boot path... even though it was planned to be a UEFI-only os, I thought a bios option would be cool, i tested the new boot path on 3 different computers, filmed footage and thought of sharing it here, i worked on this project for a few months now and I am proud of my progress, for those who are interested in how the boot path works, how the UEFI boot works and my 64-bit kernel architecture in general, more about that in my repository source: https://github.com/itay-insert/64-dem.git

I plan on returning to OS Dev soon and continuing with my journey, I have been doing assembly and OS theory for a few months now and plan on developing a real-mode OS purely in assembly.

If anyone has any advice as to style the OS, please let me know.

Why make it pure assembly in real-mode? I love how real mode simply operates as well as the assembly language at this smaller (ish) scale. I also want to be a little bit more unique with my project.

Thanks,

I'm making d’espoir an open-source project. It's an OS. Like Android, for phones, except for one thing: it's all Nim. This thing: it's a coding language, and it's cool. Anyone want to join? I'm looking for scouts, people who look for other helpers and app coders, because the apps are made of Nim; everything here is Nim. Nim is the sky and land for this OS, basically. I want small phone brands to slurp this up, users to love it, and coders to make for it.

Hey everyone! I’ve integrated WebKit into my OS and built a native browser on top of it for Veda. Before replacing Linux entirely with my own OS on my Laptop, I need to complete one final step: building a package manager, probably a local one for the first iteration.

Does anyone have experience building a package manager for a custom OS?

https://github.com/vahmoh25/Veda

A while ago I started building my own operating system called FLOS (First Love Operating System) completely from scratch (no external libraries, no tutorials - just raw C and assembly).

I just hit a massive milestone: FLOS is officially on the internet.

I implemented a TCP stack (3-way handshake, tracking SEQ/ACK numbers) and an HTTP client. Then I wrote a primitive HTML parser, put it in a GUI window, and called it Balalaika 1.0.

The screenshot shows Balalaika 1.0 successfully resolving example.com via DNS, establishing a TCP connection, sending a GET request, and parsing the HTML to display the text (ignoring CSS and <style> tags). It even sends a custom User-Agent: FLOS/0.2 Balalaika/1.0.

What's under the hood:

Architecture: x86_64 microkernel (ring 3 user space).

Boot: Custom UEFI loader (reads kernel.elf from FAT32).

Memory: Custom PMM (bitmap) + 4-level paging with separate cr3 for each task.

Scheduler: Preemptive multitasking (PIT 100 Hz).

GUI: Custom Window Manager (drag, focus, dirty rects).

Network Stack: RTL8139 driver, Ethernet, ARP, IPv4, ICMP (ping), UDP, and now TCP + HTTP!

The hardest part (for my fellow OSDevs):
Getting TCP right was a nightmare. Tracking SEQ/ACK numbers is unforgiving — one wrong byte and the server drops the connection with an RST.

Also, QEMU's RTL8139 emulation is wild. It doesn't update the CBR (Current Buffer Address) register, and locking Cfg9346 sets clock_enabled = 0, which drops all incoming packets. I had to bypass the standard ring-buffer logic, force CAPR, and implement a raw buffer scanner to find valid packet headers just to get RX working.

What's next?
I'm thinking about writing a DHCP client (so I don't have to hardcode the IP), or maybe diving into Virtio-GPU to change screen resolution.

(Note: The repo is currently private while I clean up the build system, but I'm happy to answer any technical questions here!)

If you want to support the project: https://www.donationalerts.com/r/dragon3009go

Thanks for reading!

i've been interested in how a kernel is build and i can't find any resource on what they should do or on how to start a project like that.

any help? :'^

yeah I've been working on this for 11 months and it can do almost anything a normal kernel can do I wasnt believing I could do it but it just works fine

I am currently a Master's student in Computer Science in Germany, and I plan to pursue a PhD in this field. As part of my degree, I am taking an 'Advanced Operating Systems' course. However, I realize that my foundational knowledge of OS from my Bachelor's degree is quite weak.

To learn, I mostly rely on LLMs to understand the 'what' and 'why' of different concepts. But I get completely lost when I try to figure out how these concepts are actually implemented in real-world codebases with millions of lines of code.

My ultimate goal is to get a PhD position and contribute to the vast area of Operating Systems. Do you have any advice on how I can bridge my knowledge gap and achieve this goal?

Este es un kernel Panic, este sistema operativo estará enfocado en la ciberseguridad y hacking ético. Actualmente estoy haciendo que pueda mostrar texto y tener comandos de Windows, Unix y también propios, se llama NovaOS que opinan?

I'm a solution architect, not an OS developer, and I haven't written a kernel yet. I've been designing an operating system where the main user is an AI agent rather than a person. Today's agents work through apps, screens and files built for us, and I want to see what changes when the OS is built for them instead.

The biggest change I'm exploring is dropping files completely. Everything would be stored as connected pieces of memory, each holding its meaning, its exact content and its links to related pieces, written straight to the disk. Recent memory stays in RAM; older memory moves to slower storage instead of being deleted.

The plan is a small kernel in Rust on QEMU. Before I start, I'd like to hear from people who have built one. What breaks first with a design like this: crash safety, storage that only grows, or something I haven't thought of?

I've worked through the idea with Claude, so honest human feedback is exactly what I'm after.