I am the sole author of an actual OS and remain responsible for over 40,000 placements worldwide. Having this in an actual product (running on a 100MHz MCU) keeps the pressure on. You can see it in this post contending with the open Internet. I am willing to share development details. I started it from scratch in 2011.

https://www.reddit.com/r/jnior/s/D6Az4O93SG

I searched for a few greek names and reached the word 'akakios', which means 'innocent, not evil'

Inspired by this, I want to name my Linux distro as akaki_os

Let me know if this name sounds cool or not

A quick demo of Veda in action.

GitHub: https://github.com/vahmoh25/Veda

first is terminus second is ubuntu mono

I am terrible with names. SO this is just HobbyOS.

I am not here to tell you how "incredible" and "futuristic" it is. No. It's dumb, written in Rust.

I have deep asm-phobia, and C-ptsd, so this is my attempt to create yet another OS in Rust.

So far, I did a text driver, a VGA-Style font. Oh yeah, I also IMPLEMENTED LIMINE.

Why doesn't Limine have VGA!? Pretty frustrasting.

But yeah, here's the repo: https://github.com/artemtsitronov/hobby-os

Please leave a star to support me :)

Hey everyone!

I've been working on a project called OpenWave a Linux-based mobile operating system built with C, C++, and Qt Quick.

The goal is to create a mobile OS that doesn't depend on Android's framework and has its own userspace, system services, and application framework.

So far, I've managed to get quite a few things working, including a custom init system, a Qt Wayland compositor, an app launcher, a file manager, settings, and a web browser powered by WPE WebKit. I've also implemented several system daemons, D-Bus APIs, and a custom Clang toolchain.

I'm currently working on this project on my own, and I'd really appreciate having some people help out.

UPDATE:
Repo: https://github.com/bayar17/OpenWave

Added:
fully functioning syscalls
linux syscalls if you want to run basic binaries (though i forgot to add to run elf if detected wait for later)
a library for applications
applications to well, do stuff.
it can assembler bullshit applications that i probably wrote

Quick update on Veda OS! It can now play videos using its own native video player app. Here's a short demo of it in action!

https://github.com/vahmoh25/Veda

What exactly is Bursztyn OS, and what’s running under the hood? 🖥️🇵🇱

In short: it is a 100% independent, 64-bit operating system written from scratch for the x86-64 architecture (bare-metal). It is not another Linux distribution, nor is it a modification of Windows. The system features its own custom kernel, security model, drivers, filesystem, system API, graphical environment, and native applications.

Here is a technical overview of what currently powers the project:

Kernel & Architecture (Ring 0 / Ring 3)

• Custom Kernel: Full hardware-enforced isolation—kernel running in Ring 0, userland processes in Ring 3.
• Memory & Processes: Custom PMM and VMM, x86-64 paging, kernel heap, bespoke malloc/free implementations, preemptive process scheduler, and support for APIC, LAPIC, and HPET.
• BWS (Bursztyn System Calls): A strictly controlled system bridge between Ring 3 and Ring 0 (no raw MMIO or DMA access exposed to applications).
• PZB (Bursztyn Trust Levels 0–5): A logical security model that dictates process capabilities and sandbox boundaries.
• BUR & .cebula Formats: A native binary executable format (.bur, not raw ELF) and application packages (.cebula) containing permission manifests.

Filesystem, Storage & A/B Updates

• BSP2 / PSF: Custom 64-bit filesystem supporting stream reads, block caching, and indirect block addressing.
• A/B System Update Architecture: Dual system slots (Slot A and Slot B)—updates install in the background, with automatic rollback if a new build fails to boot.
• GPT/UEFI Installer: A dedicated graphical installer partitioning ESP FAT32 and BSP2 volumes.

Desktop, BursztynUI & Native Apps

• Compositor & Window Manager: Multi-window multitasking, active window focus, dragging, minimizing, dirty-rectangle repaints, and private offscreen buffers for GUI applications.
• BursztynUI Framework: An in-house retained-mode UI widget library with a Polish-language API, theme support, and a bespoke Unicode font covering Polish diacritics.
• Native Ring 3 Software:
  
  • File Explorer – browsing BSP2 storage and desktop integration.
  • Notepad (UTF-8) & Calculator.
  • Bursztyn Shell – native system terminal.
  • Image Viewer & Wallpaper Manager – native BTP format support and streaming image decoding.
  • Husarz – lightweight custom web browser (built-in HTML parser and CSS styling—no Chromium, WebKit, or Gecko).
  • Sound Test – hardware diagnostic utility for the Intel HDA bus.
  • Classic Snake.

Hardware, Drivers & Networking

• Input & USB: Native xHCI stack, concurrent USB HID device support (keyboard and mouse) with a PS/2 fallback path.
• Graphics & Audio: Graphics HAL (UEFI GOP, VESA VBE, VirtIO-GPU 2D) and an Intel High Definition Audio (HDA) driver.
• Networking & Security: Custom networking stack (IPv4, ARP, DHCP, DNS, TCP) with secure HTTPS powered by a bare-metal port of mbedTLS.
• VirtIO Virtualization: Modern profile for QEMU (VirtIO-BLK, VirtIO-NET, VirtIO-RNG, VirtIO-GPU, VirtIO-INPUT).

QEMU vs. Physical Hardware (Transparent Development Status)

Because Bursztyn OS is an active R&D project, it is essential to distinguish between emulated milestones and real-hardware verification:

• In QEMU, the system runs a modern VirtIO profile, automated test suites, networking, and audio diagnostics.
• On physical hardware, the system boots in Live USB (UEFI) mode (verified on an Acer Nitro laptop, confirming UEFI boot and concurrent operation of the touchpad and wired USB mouse).
• Physical audio (Realtek codecs) and internal drive installation on laptops are currently undergoing active testing and security audits.

The ultimate roadmap remains unchanged: a fully independent operating system with its own ecosystem, native environment, and integration with the Avocado programming language. 🚀

Huge thanks to everyone supporting the project and following its milestones!

#BursztynOS #OSDev #OperatingSystem #Programming #BareMetal #SystemsEngineering #x86_64 #CustomKernel #IndependentTech

r/LocalLLaMA + r/selfhosted

I've been building a 16-bit OS entirely in NASM, not to replace Linux, but as a study in minimalism.

No paging. No multitasking. No protected mode. Just a bootloader, a Real Mode kernel, a flat filesystem, and a scripting engine. It's about 50KB total.

The interesting part isn't the OS itself — it's the constraints. In Real Mode you get:

- Direct BIOS access (int 0x10, int 0x13, int 0x16)

- 64KB segments, no memory protection

- CHS addressing for disk I/O (no LBA, no DMA)

- No MMU, no virtual memory, no interrupts from hardware

It forces you to think about what an OS actually needs. My "filesystem" is one sector for the directory and raw sectors for data. No inodes, no journaling. My "scheduler" doesn't exist — programs run until they return. My "shell" is a loop that reads a line and compares it to a list of strings.

The scripting engine (PyShell) is the most interesting piece. It parses lines of a script, maintains a variable table, and handles if/else with indentation. No arithmetic, no loops, no string comparison in conditions. It's intentionally limited.

This isn't practical. It's not meant to be. But it asks: where is the line between "hobby OS" and "toy"? And does the line matter if the goal is understanding?

The code is on GitHub. Curious what the purists here think about Real Mode vs Protected Mode, and whether "bloat-free" is a useful goal or just nostalgia.

Ciao a tutti!
Ho creato Maginat, una distribuzione live basata su Linux From Scratch 12.4 (init SysV, Xfce).

• Sistema base costruito a mano da LFS; il resto (script ISO live, installer, strumenti nella tray in C, menu lingua inglese/italiano)
• Avvio in BIOS e UEFI, ISO di 1,67 GiB, squashfs
• Audio Bluetooth (A2DP) con PulseAudio 17.0
• GPL-2.0-o-altro, sorgenti complete e script di build inclusi

Repo e ISO: https://github.com/Aleps31/Maginat
Feedback e segnalazioni di bug sono molto benvenuti!

ps. Si prega di installare il .iso in Qemu o Virtualbox. Grazie!

I've been building CoralOS for over a year now. Initially I just wanted a microkernel which survives failing/broken drivers to map out things on a Galaxy Book S (horrible Snapdragon 8cx, but the thinnest laptop I own -- sadly running Windows) and get Linux working on it. The screenshot is real hardware, a Z83 mini PC (Atom x5-Z8350, I got it off Amazon quite a few years ago to run Kodi), not QEMU.

A few parts I'm happy with:

1. GPU-composited desktop. Drivers and services run in userland and talk over capability-based IPC. Every pixel on screen goes through the Intel GPU via its own i915 driver, with no framebuffer blitting.
2. Webkit, but it never decodes images itself. The browser (WPE WebKit + relibc) is built without its bundled image decoders. It sends the encoded bytes over shared memory to a separate decode service, which loads Amiga-style .datatype codec classes from System/Datatypes/. A bad image crashes the codec process, not the browser, and a new format is one file that every app picks up. If there's a fancy new format, you'd just drop in a new .datatype and should be good to go.
3. The build refuses duplicated code. Each value and each file format has exactly one home. Copied code, a second parser for the same format, or a source file over 1000 lines fails the gate.

It also has Wi-Fi (a Rust port of Linux's brcmfmac driver) and HDMI audio. A Pixelbook Go is the next target. The Snapdragon 8cx is imposible to deal with, so this projects is amd64 only now.

If I don't get bored or life doesn't come in the way, I might try to include Copperline (an Amiga m68k emulator in Rust) with modified AROS parts that call out to CoralOS's native amd64 datatypes. Giving legacy 68k apps a parallelised Rust backend sounds like a great idea right up until you remember the endianness headache. Translating big-endian legacy UI structs across a strict MMU boundary into a little-endian host is going to be even more "fun" than getting WPE to work. We'll see.

Oh, I am a big Amiga fan. Probably obvious.

Vibe coded operating system kernel and gui on my own language (r/tapedev), running on real hardware!

It was actually really hard; AI didn't know much about my language; but forcing it to do 100% inhouse language revealed thousands of edge-case bugs - which then I was able to fix. AI assisted development is a force multiplier for developing - true believer here.