Hey everyone,

Tired of building Yosys (and friends) from source or getting years-old versions from your distro packages?

I’ve been packaging Yosys, OpenSTA, Surelog, Netgen, and ABC as single-file AppImages. Just download, chmod +x, and run — no dependencies, no containers.

Repo: https://github.com/MrAbhi19/open-eda-appimage

Docs: https://mrabhi19.github.io/open-eda-appimage/

If anyone tries them, it would be super helpful if you could leave a quick comment about your experience (especially on different distros) in the Discussions page. That feedback helps a lot in improving the packaging.

Also looking for help with documentation — any contributions there (or elsewhere) are very welcome!

Thanks!

Hi kernel engineers,

I am creating Raam kernel and the Raam operating system completely from scratch using FASM Assembly. It is an x86-64 Unix-like OS for real desktop and laptop PCs.

Before starting Raam in FASM, I thought about creating the MVP version first and then begin with the advance features. In the MVP, I thought of creating a minimal general-purpose commandline OS by writing a shell and the commands like ls, cat, ed, asm, rm, help, reboot, clear, and echo and running the assembled programs using ./ command.

In order to keep things simple in MVP, I created everything in kernel space. Basically I wanted to make it minimally usable for a user (hobbyist) without worrying about advance things like switching to usermode, creating a syscall interface and all. So I hardcoded the shell, the ls, cat, and ed commands and now I feel like I cannot spend more time on improving the ed editor and then writing an (simple) assembler and so on...

It feels like it is too much of work in the kernel space itself for a solo kernel engineer like me. And I need to look at the two layers simultaneously - the hypothetical user layer (like the ed program), and the kernel layer (like the underlying filesystem and the NVMe operations). I think I only want to concentrate in the kernel space code.

Regarding running the assembled binaries using ./ command, I thought about loading the binary and running it from kernel mode itself just to give the user an illusion of a working OS.

I am stuck here. I really want to either cut down the work/scope or maybe I want to change the MVP design altogether like instead of running the hardcoded shell, I should run dash shell from the usermode and a few standard userspace programs like help, ls, etc. Then I can move to port other programs like vim, gcc, etc in the next phase. I don't know how to proceed ahead. Kindly help.

Thank you.

Source tree: https://github.com/robstat7/Raam

Project github link: https://github.com/superuserdo-sudo/Gill

hello everyone i did make an project named Gill on github that is not a unix based or linux based it is an OS based on SeL4 MicroKernel [ https://sel4.systems/ ] and have it own tools and core utilites (GCU/Gill Core Utilites) and its own file system (GillFS) wich is not done [ https://github.com/superuserdo-sudo/Gill/tree/main/gillfs ] and and its name means : gill is light a lot or Just Gill.

its Philosophy:
Gill is based on the idea that an operating system does not need to become unnecessarily large or complex to be useful. The project focuses on building a small foundation and developing functionality as separate, focused components.

Gill values:

• Lightweight design
• Minimal code
• Modularity
• Simplicity
• Independence
• Clear interfaces
• Maintainability
• Practical functionality

Gill does not add functionality simply because another operating system has it.

A component should have a clear purpose and should remain as simple as reasonably possible while still being functional and maintainable.

GCU

GCU stands for Gill Core Utilities.

GCU is part of Gill/SeL4 and provides fundamental utilities for the Gill environment.

GCU follows the same philosophy as Gill:

• Small programs
• Focused functionality
• Minimal unnecessary code
• Simple interfaces
• Independent implementations

GCU is not simply a collection of renamed Unix commands.

Its utilities are independently developed programs intended for the Gill environment.

Examples include:

see
mdir
punch
cop
rom
wai
type
wami
wimarch
wimh
mos
wimt
idme
grps
mmsleep
tmo

HEYYY, I just want to share that FINALLY I reached the basics of user land!!

3 years ago I posted about my "master plan" that you might checkout here.

Featuring:

• Memory allocation with buddy and slab;
• Timers (heck yeahh);
• Multi task with preemtive switch;
• Scheduler;
• Basic User Space support;
• And a noice generic build and API system, to support the future port for x86 and my custom CPU.

About AI:

The elephant in the room.

No, it's not vibecoded. I do work professionally with AI because yeah, that's what companies are pushing for. But AI don't touch my code here.

Seven years ago I challenged myself into making a OS, so I WANT to know how every single line of code here works. I did use AI to make boring stuff, like populating the entire Keymap table for keyboard support, which honestly is just... hexadecimal number all over the place?

Unfortunately stupid Claude Code marks him as co-author because I use it to automate commits, because again, just boring by today standards.

About my feelings around using AI for OS dev? It changed everything!

I'm not the kind that likes to bang my head against the wall to learn stuff, specially if it's already a solved problem. I like to search how other peoples does it. I've spend countless hours tryng to decifer Linux kernel itself, with dozens of workarounds to make it work in every single CPU since the 70s. Looking for git repos of other OSs to take inspiration.

This project is something that I take my time. I stop when I burnout and came back when I have inspiration, sometimes after 6 to 8 months or over a year. That means I forget the precise details of everything.

AI completely speed up everything. Before, I was hoping to reach user space in about 5 years, and suddently I just reached!

My workflow is basically:

• Ask AI what is next;
• AI spit up explanations on what should I be doing and coding, with some rough examples;
• I try my best to make it;
• When I get tired, I ask AI for a full working code example;
• I manually type everything then goes a long session trying to understand every line.

Also, I don't know how many hours I spend learning about memory. I have a mechatronics engineer degree, I have learned a lot on how the chips works physically. Yet, sometimes I couldn't wrap my head around how I was organizing memory in my own OS.

AI just... understands the code and explain to me like I'm dumb!

Well, to wrap it up, link to repo: https://github.com/caioaletroca/MadeInHeavenOS
The code is obsessivily comented, to avoid my future self to shoot me in the foot.

Edit: With user space, I plan to go micro-kernel because... why not? Seems nice. And to not be another Linux clone.

Pardon my ignorance, why are Doom, and a few other games used so often on hobby OSs?

Hi everyone! I'm developing BlockOS, an independent x86-64 operating system with its own kernel, userspace, networking, filesystem support, ELF loader, libc work and X11 environment. I'm currently looking for someone who would like to help develop a native service manager for BlockOS. I don't want to simply port systemd or OpenRC. I would like the service manager to be designed around BlockOS itself. The service manager should eventually support: Starting and stopping services Restarting services Service status Automatic service startup Service dependencies Process/PID monitoring Automatic restart after crashes Clean shutdown and reboot Logging Runlevels or a similar service-state system Integration with the existing BlockOS init/userspace system BlockOS's /devices structure rather than assuming a Linux /dev layout The goal is to have something that can manage services such as: network dhcp x11 gui getty ssh I'm mainly looking for someone interested in OS development / C/C++ / init systems who wants to build something that will become part of an independent operating system. You don't need to be an expert in everything. If you're interested in working on the service manager, feel free to open an issue or contact me.

GitHub:https://github.com/gurijb2016-afk/Blockos/tree/uefi-kernel-scaffold

Hey everyone,

About a year ago, I had a probably slightly crazy idea: write my own operating system. Today, after 3 completely different versions, I feel like sharing the journey — because honestly, it's been a rollercoaster.

Phase 1 — The consumer OS in Rust

I started classic (well, "classic" for osdev standards): a first version written in Rust, with the ambition of building a consumer OS. And when I say "from scratch", I really meant from scratch: I wrote my own bootloader and my own custom kernel. No shortcuts, everything by hand. That's where I learned 90% of what I know today about machine boot, memory, drivers… and also that coding a "consumer" OS is a mountain very few people have ever climbed alone.

Phase 2 — The cloud gaming pivot and the birth of Flux#

Second version, total change of direction: an OS dedicated to cloud gaming. And this is where it gets a bit special: for this version, no existing language really fit my needs, so I… created my own. It's called Flux#, a low-level, object-oriented language, which I released as open source under the MIT license — because a home-made language that exists nowhere else is useless if nobody else can touch it. Writing a compiler AND an OS at the same time is the kind of experience I wouldn't recommend to anyone, and that I'd do again tomorrow morning.

Phase 3 — The handheld console (current version)

Today, I'm on the third version: an OS for a handheld console. That's the one I'm working on right now, and it's probably the most motivating of the three — there's something very tangible about holding a machine in your hands and watching your code run on it.

The kernel: when pragmatism wins

One important detail, because I know the question will come up: my bootloader and my custom kernel were both written entirely by myself. But for the current version, I made a tough call: my custom kernel has been moved to R&D. Honestly, reimplementing it yet again for the handheld version would have cost me a massive amount of time, so I switched to bootroot as a kernel base to save time and focus on what makes this version unique. My custom kernel isn't dead — it's sleeping in a corner, in R&D mode, and I fully intend to come back to it.

However, the custom bootloader, I still have it. That one, I never gave up on. There are some things you just don't abandon.

What I take away after a year

• Writing a bootloader and a kernel by hand is the best computer science school I've ever been through.
• Reinventing the wheel is great for learning… but sometimes you have to know when to stop in order to actually ship something.
• Creating your own language while creating your own OS is pure madness — but it's my favorite kind of madness.

If people are interested, I can go into detail on any part: the custom bootloader, Flux# (it's open source, come steal some ideas), or the architecture of the handheld console version. And if you've also abandoned a custom kernel along the way, tell me about it — it'll make me feel less alone.

EDIT: Bare-metal boot on real hardware

Since people asked about the hardware setup: to clarify, I don't own an open handheld development board yet (Switch Lite is too locked down). Before targeting any handheld device directly, I do all my real-hardware testing on an x86_64 laptop (Gigabyte) to debug outside of QEMU.

Here is a boot photo showing the custom stack running on the laptop:

• State: Multiboot2, firmware framebuffer (1024x768), PCI bus scan, and custom Realtek NIC driver initialized with uncached DMA ring buffers.
• Shell: Dropping straight into the interactive terminal

Ladies and gentlemen, first of all, how are you all? To get to the main point, I have an idea for developing a Linux distribution, and this has led me to consider the idea of completely automating system maintenance and administration. Whenever I search online, I come across all sorts of crazy suggestions, such as ‘create automation using Bash scripts’.

I’d be very grateful if you could help.

I’ve been working as a Java programmer for a few years now.

The thing is, I’d like to learn a second programming language for lower-level tasks—specifically, I want to work on things related to operating systems. Rather than building one from scratch, I’d like to explore and modify open-source operating systems like Linux or a BSD variant.

I’m doing this purely as a hobby. What drew me to C is its simplicity (though not necessarily ease of use) compared to Java or other modern languages, and its long history of use in systems programming. On the other hand, however, there are operating systems (or components of them) being rewritten in Rust—such as GNU coreutils or the adoption of Rust in the Linux kernel.

So, would it be more useful in the long run to learn Rust, given that it might sooner or later become the standard for writing operating systems?

Thanks.

I know AI-generated code isn’t exactly the most beloved thing on r/osdev.

So naturally, I decided the safest possible thing to do was let AI write an operating system and post about it here.

What could possibly go wrong.

I’m 40, I have some free time, and instead of developing a healthy hobby like fishing, I decided to find out how far you can push current AI models before either the model or the human supervising it completely loses the plot.

The project is simple:

Can AI build an actual usable operating system?

Not a “Hello World” kernel.

Not something that boots in QEMU, prints three lines and immediately becomes a GitHub project with a roadmap.

I mean slowly pushing it toward something resembling an OS you could actually use.

And I’m treating the whole thing as an experiment.

How good are different models at low-level programming?

Where are they surprisingly competent?

Where do they confidently invent complete bullshit?

How much context do they need?

How much testing?

How much human intervention?

How long does each feature actually take?

The AI writes 800 lines of code.

It compiles.

The tests pass.

The logs look beautiful.

Nothing works.

Then we spend two hours debugging the scheduler, another hour questioning the memory manager, rewrite half a driver…

…and eventually discover that the original problem was one completely stupid assumption made 1,200 lines earlier.

By the AI.

Which I reviewed.

So technically this was a team effort.

Other times it does something that genuinely surprises me and implements in 20 minutes something I expected to spend an entire evening fighting with.

That’s the interesting part.

I’m also comparing models and workflows, because I’ve learned that “AI coding” isn’t really one thing.

One model understands the problem but writes questionable code.

Another writes beautiful code while misunderstanding the problem.

Another wants to refactor the entire kernel because a mouse packet is malformed.

And occasionally you find the magical combination where the model understands the problem, writes decent code and doesn’t decide that rewriting the PCI subsystem is the obvious solution.

Those are good days.

The bigger experiment for me isn’t really AnotherOS itself.

It’s learning how to use these tools effectively.

AI isn’t going away. Models are improving ridiculously fast, and I don’t want to wake up five years from now realizing I spent those five years arguing that “real programmers don’t use AI” instead of learning where it’s useful, where it’s dangerous, and how to squeeze the maximum out of it.

I’m 40. I’m not trying to become the next Linus Torvalds.

I’m a guy with some free evenings, hardware to abuse, AI subscriptions and apparently insufficient respect for my own sanity.

So I’m building an OS.

I measure how long things take. I document failures. I compare models. I test things on real hardware. I keep pushing it toward the point where the joke becomes:

“Wait… this thing actually works?”

And that’s basically the goal.

Not to prove that AI can replace OS developers.

Not to prove that I’m secretly an OS genius because Claude managed to configure an APIC.

Just to see what happens when you take today’s tools and keep pushing them far beyond the point where a reasonable person would have stopped.

The project is AnotherOS — anotheros.org

Feel free to look through it, tell me what is horribly wrong, question my life choices, or explain why something only works because I’ve accidentally violated three specifications at the same time.

That’s useful data too.

And if the whole experiment eventually ends with a kernel panic that nobody — including three frontier models and myself — can explain…

well.

That might actually be the most authentic OS development result possible.

Hello fellow enthusiasts and system creators! I recently announced that I was building an operating system for retro video games, and I’ve started working on it—I’m really pleased with the result! I hope you like it.

I'm just fixing a few annoying bugs, and as soon as that's done, I'll open-source the code on GitHub!

Hi I want to showcase my x86_64 OS kernel. I've recently got done adding uACPI. I would be open to some feedback and comments.
https://github.com/HoniT/MioOS2

Hello r/osdev,

I've been developing a TUI OS over the last year and a half and Ive gotten to a point im happy with, in the screenshots you can see the boot screen and the TUI desktop with its premade folder shortcuts.

I wanted to come make this post because I wanted to ask all of you what are some cool features i could add or things that could make it more lively?

I've always loved TUI's more so than graphical interfaces because I like making them look graphical while keeping the TUI look and feel.

I look forward to seeing what you all suggest.

I FINALLY DID IT
repo: https://github.com/NoTheIdiot/WindogeOS

Hello there! I’ve been working on a custom bootloader for the last few months, and I recently migrated my build to generate ISO files instead of disk images, as I was curious to see how to make my (eventual) OS boot on a real PC using CD drives.

In case you’re wondering why I’m using BIOS and CD drives when UEFI and USB sticks exist, it’s mostly out of curiosity for how old tech and software worked, and since the only PC I have that still supports BIOS has a CD drive I was like “why not”.

I can’t exactly say the video above is a bootloader as it doesn’t boot anything yet, but it was a personally big milestone getting it to read sectors off of the disk in C rather than assembly for once.

At the moment I’ve only worked on the BIOS side of the loader and written a basic VGA text driver and BIOS interrupt wrapper that allows me to call BIOS interrupts in C rather than assembly (which will help a lot). I’m hoping to get the ELF loader done soon and start the actual kernel eventually, and also try support UEFI.

Here’s a link to the source code so far: https://github.com/bricksigma/SteinerOS

I have a problem: In my bootloader, i have a "mov ax, 0xB800

mov es, ax

mov byte [es:0], 'C'

mov byte [es:1], 0x07" block, and works with him in the code. But, if I delete him, the Kernel won't start, and idk for what. Can someone help me?

The full code is:
bits 16

org 0x7C00

jmp short code

nop

boot_drive db 0

code:

cli

xor ax, ax

mov ds, ax

mov es, ax

mov ss, ax

mov sp, 0x7C00

sti

mov [boot_drive], dl

mov ax, 0xB800

mov es, ax

mov byte [es:0], 'C'

mov byte [es:1], 0x07

xor ax, ax

mov ds, ax

mov si, dap

mov ah, 0x42

mov dl, [boot_drive]

int 0x13

jc .disk_error

jmp 0x0800:0x0000

.disk_error:

mov ax, 0xB800

mov es, ax

mov byte [es:0], 'K'

mov byte [es:1], 0x07

.idle:

cli

hlt

jmp .idle

dap:

db 0x10

db 0x00

dw 0x0005

dw 0x0000

dw 0x0800

dq 0x0000000000000001

times 510-($-$$) db 0

dw 0xAA55

Edit: I’m just going to leave that there and not touch it. Idk what's does, but, since it work, I never touch it again.

⚓ Nemo OS 1.0.1 ya está disponible — código fuente completo, manuales, e imagen de instalación

Después de dos años de trabajo, el momento ha llegado: Nemo OS 1.0.1 está disponible para cualquiera que quiera probarlo.

📦 ¿Qué incluye el lanzamiento?

• Todo el código fuente, publicado en GitHub bajo licencia Apache 2.0 — abierto de verdad, para leer, usar, modificar o construir sobre él.
• Los manuales, incluidos directamente en el propio sistema (carpeta DOCUMENTOS, accesibles desde el visor integrado).
• La imagen de instalación, lista para escribir con la app oficial de Raspberry Pi (Raspberry Pi Imager, opción de imagen personalizada) en cualquier tarjeta SD de 16 GB en adelante (1 GB para la partición FAT de arranque, el resto para NemoFS).

⚠️ Una aclaración honesta sobre el espacio: en esta versión 1.0, aunque uses una tarjeta de 128 GB, el sistema usa realmente solo los 16 GB base (incluyendo el 1 GB de la partición FAT donde vive el arranque) — todavía no estira NemoFS automáticamente al resto del espacio libre. Esa herramienta ya está en marcha y llegará en una próxima actualización.

🌐 Red: ya hay Ethernet

Nemo OS tiene su propio driver de red por Ethernet, construido desde cero, con enlace a 1000 Mbps confirmado en hardware real.

🖱️ Aronnax: programar visualmente, sin escribir una línea de código a mano

Una de las piezas de las que más orgulloso estoy en esta 1.0: Aronnax, el diseñador visual de Nemo Basic al estilo Delphi. Creas ventanas, colocas botones y gadgets con el ratón, haces doble clic en cualquier control y saltas directo a su código — todo sin salir del propio Aronnax, compilando desde ahí mismo. Incluye hasta controles GPIO visuales para programar hardware real sin escribir configuración a mano.

¿Qué más te vas a encontrar al arrancar?

Un sistema completo: escritorio gráfico, explorador de archivos, editor, el IDE propio (Timonel), Lua y Nemo Basic como lenguajes nativos, soporte GPIO completo (pines, PWM, I2C, SPI), sonido real por el jack de 3,5mm, y varios programas de ejemplo ya instalados —Arkanoid, Buscaminas, Tetris, un monitor del sistema, y una demo del juego de plataformas del capitán Nemo— con su código fuente incluido.

De verdad desde cero

Kernel propio, sistema de archivos propio, compiladores propios, gestor de ventanas propio, driver de red propio — nada reutilizado de otro sistema operativo. Construido para ARM64, probado y confirmado en hardware real (Raspberry Pi 4).

Dos años de trabajo, desde un experimento en QEMU hasta un sistema operativo instalable por cualquiera en su propia Raspberry Pi. Gracias a quien ha seguido el proyecto hasta aquí — esto apenas empieza. ⚓

https://github.com/ericmugnoz/nemo-os

Hello again, OSDev! I've fixed the bugs and published the websites and source code for MGOS; the links are below:

GitHub: https://github.com/Oddler190/mgos.git
MGOS WebSite: https://mgos-system.edgeone.dev/
Organization maintaining the project: https://antel.edgeone.dev/

I hope you enjoy it; if you have any suggestions for improvement or constructive criticism, I’m ready to listen!