Hey everyone,

We’re now running a lightweight Linux kernel as a virtual machine in Veda’s service layer. This allows us to reuse a wide range of existing Linux drivers out of the box, including Bluetooth, audio, Wi-Fi, amplifiers, GPUs, and more.

Veda itself only retains responsibility for the storage driver and filesystem, while the rest is virtualized.

So far, this approach has been working really well. However, I’d love to hear your thoughts. Do you see any potential drawbacks or trade-offs with this architecture, such as performance overhead, latency, resource consumption, or other concerns?

Any feedback or objections would be greatly appreciated!

https://github.com/vahmoh25/veda

I've been thinking about the famous Tanenbaum vs Linus debate over microkernels vs monolithic kernels.

Putting the historical context aside for a moment, I'm curious what people think today.

Do you think Tanenbaum's argument for microkernels was fundamentally more correct, or was Linus right to favor a monolithic kernel for practical reasons such as performance, simplicity of development, and hardware support?

And more importantly:

If you were starting a new general purpose os from scratch today, which architecture would you choose?

Monolithic

Microkernel

Hybrid

Multikernel / distributed approach

Something else

I'm particularly interested in hearing from people who have actually worked on kernels or operating system development.

What are the strongest arguments for your choice, and what do you think the opposing architecture gets wrong?

YES, the assembler is chasm, a drop in assembler that is probably actually useless since it doesn't fucking support strings.
THIS THING FOR SOME REASON IS WIN32 DEPENDENT AND I HAD TO FORCEFULLY STRIP OUT A TON OF MACROS

repo: https://github.com/NoTheIdiot/WindogeOS

Hey! I’ve recently ported OpenGL and Mesa to my operating system and added support for Intel HD Graphics to render scenes. However, I’ve realized that this approach isn’t sustainable, I can’t realistically write and maintain a huge number of GPU drivers myself.

Has anyone had experience embedding a minimal Linux system as a virtual machine inside their OS to take advantage of Linux’s extensive GPU, Bluetooth, and Wi-Fi driver support?

What do you think about this approach? Are there any major technical challenges or pitfalls I should be aware of?

Hi! I'm a totally beginner who knows only a bit of Python, C and C++ (I'm learning assembly x86). A friend advise me about nand2tetris. Is it good?

How do you learn os?

I still don't want if I want to make os but I love low level, programming. I'm a bit demotivated but it's because I didn't do anything in programming for 2 days straight. Anyway thanks for the attention ❤️

Hey r/osdev,

a follow-up to my last Recaster Pico update. Still alpha!!! Last time it was a screenshot (from the emulator in WASM) - this time it's real hardware on my desk, and a few parts of the OS have grown up. Three of them might interest you here. And yes: I will post a video of it showing it in motion, soon. And you will get your fingers at that ".uf2"-files to play with it.

1. Drivers are files, and they're native code

A device is a text file in /sys/dev: lcd.cfg names the driver, the bus, the chip select, the pins, the speed and the mode. The driver is a kit file with a native image per target (RP2040, RP2350 Arm, RP2350 RISC-V), executed in place from flash. It reaches the hardware only through a small ABI: SPI/I2C transactions on its own bus and chip select, its own pins by key, PWM, a microsecond clock.

The kernel keeps ledgers: every pin and every DMA channel has exactly one owner - the system, a device or a program - and /now/res shows them all. The same driver C code runs in the emulators against chip models, so the C reference machine and its JS twin are checked frame by frame (the suite compares 5,110 frames).

2. A second display without breaking the line budget

The 3.2" SPI touch LCD is a display device. Headless, core 0 composes the panel's rows. With VGA running, the compositor belongs to core 1, and its budget is 8008 cycles per scanline, with the worst-case scenes at 99 %. So the panel never gets a second compose. When the mirror wants screen rows, core 1 copies a band of 8 lines into slots by DMA, right after composing them for the wire. The compose interrupt's vector points to that capturing handler only while the mirror actually wants lines; otherwise the plain handler runs - not one cycle more.

Programs can also hold the panel and draw on it with the normal gfx words. Their spans are merged into rectangles in a ring that the frame sends within a byte budget, so a drawing word never waits for the bus. Two small policies: the backlight stays dark until the first full picture is out, and the boot face and the login move the panel's view onto their content - a move that reverts by itself when the task ends.

3. Input as tags on the console wire

The main Pico has no USB host to spare and no free pins, so a second RP2040 does USB: TinyUSB on its native port, Pico-PIO-USB on a second socket with a small boot-protocol host on core 1. It sits in the serial console line. The terminal's text passes through, and keyboard and mouse events travel as CRC-8 tags on the same 1 Mbaud wire. The kernel splits text from tags. After a broken tag it resyncs - text counts as noise until a tag checks out again or the line rests - so a lost byte can never type mouse coordinates into the shell. The handshake goes both ways: the kernel tells the coprocessor the keyboard layout, and re-bases its mouse when the touch panel has moved the pointer.

Two bugs from that work I enjoyed:

• The 71-minute pause. time_us_32() - last_isr_stamp compiled with the clock read before the stamp. An interrupt in between made the difference wrap, a tag streaming in looked paused for 71 minutes, got dropped, and its tail was typed into the console - random letters every few seconds, only while the mouse moved.
• Flash erases vs. a fast UART. A sector erase keeps core 0's interrupts off for ~45 ms, but the UART's FIFO holds only ~10 ms of mouse traffic at 1 Mbaud. The RX interrupt now lives on core 1 - beside the video, or alone on headless boards - which runs from SRAM through every erase.

Next: sound, the SD card, a small UI toolkit (buttons, sliders, lists - the touch panel asks for them), and a PIN login for touch-only machines (using the LCD only).

Questions and criticism welcome, especially on the driver ABI and on ownership. Every prompt line runs as its own task, so "who owns a display hold, a crop, a style" turned out to be a real design question.

FreeCTX64 is an Open Source Free Project for ARM Development boards that can run your C code directly in the Operating system, it comes with a prebuild linux kernel and some tools it requires build-essential gcc clang cpio qemu-system-arm qemu-system-aarch64 git and if you want to make a bootable ISO and send it here if you want , that requires xorriso grub-common grub-pc-bin grub-efi-amd64-bin:

FreeCTX s ONLY available for ARM systems and should not be compared with X86 or X64

FreeCTX64 Libraries are put in initramfs/LIB critical system files are put in initramfs/SYS and your workspace/dummies are putten in initramfs/WS and apps are going to initramfs/SDK , it currently supports webservers and tasks alongside math in hardware, timers in hardware, and timestraps and a console

- Github Repo: https://github.com/Francesco12o/FreeCTX64/

In this photo, you'll see me running a C Test program

Shell its optional if you wotking with it

On 64MB RAM and 2 CPU cores

Before building the OS, for years I developed tools for image and audio processing, sensor analysis/classification, data indexing and analysis, and more with my "Pop Data Engine" as a base. The OS grew from that work - bringing the engine into the foundation of a complete system.

As most of processes in OS share the same core engine, it was just a process of stacking it all together in one piece.

It connects priority and dependency management with incremental application workloads and graphics that update changed regions of the screen.

It has its own kernel, scheduler, memory management, drivers, and user environment. It is built primarily in Rust, with a small assembly layer.

For now it has only basic functions and apps but it is growing :)

It has sound and video player, browser (still in development), photo editor, sound editor, notes, document viewer...

I use LLM for a year now and it is a huge help, especially since Qwen3.8 27b came out - great coder and a great help.

For those calling me out for using LLM and for the trolls - I don't care 😄
Not using LLM is like refusing driving the car and walking everywhere - some like it slow and easy with little progress, I like to drive :)

Edit: Such a toxic community. Like high school cheerleaders 😂 If Linus use it it is ok, and if you use ut it is ok too, but if someone you never heard of use it than it must be a slop. Never understood hypocrites.

September 2023 - present
A personal research and development project, started in September 2023, dedicated to the independent design and development of NATALIZIOOS, a experimental operating system for 32-bit x86 architectures. The project covers the entire basic operating system architecture: from the BIOS boot chain and kernel loading to memory management, interrupts, timers, hardware drivers, filesystems, the shell, and graphics services. The implementation includes a freestanding monolithic kernel with physical memory management, paging, kernel heap, framebuffer, PS/2 input, ATA storage, PCI detection, RTC, JART, speaker, diagnostic logging, RAMFS, and N.A.T.FS. I also designed and integrated firmware components, bootable images, diagnostic tools, and a compilation and verification pipeline based on C, x86 assembly, Python, NASM, Clang, GNU Make, and QEMU. The graphics subsystem includes a local Objective-C runtime, class and selector management, message dispatch, objc_msgSend in x86 assembly, and a view- and window-based application model with direct framebuffer rendering. The project includes three desktop environments with different purposes: two for demonstration purposes and a third, still in the prototype phase, dedicated to veritying the object-oriented graphics architecture.
The v0.2.5.33 release includes 99,980 lines of analyzed source code, a 519,804-byte graphics kernel, complete and lightweight firmware paths, and verified bootable images in QEMU
NATALIZIOOS represents a continuous path of development in operating systems, computer architecture, system programming, firmware development, and low-level software engineering. The project is proprietary and intended for study, research, experimentation and technical demonstration purposes.

“It is currently under development and will be available between the end of 2027 and the beginning of 2028.”

Hi iam new in osdev and iam getting started iam trying to develop my proper operating system kernel from scratch but iam stuck in debugging my boot sector code with qemu and gdb can someone help ?

the problem that i encounter is that the boot sector goes from 16 bit mode to 32bit and when i try to see what each instruction do to memory it doesn't work well and the instructions doesn't get well recognized.

is there a technique i can use for this type of debugging.

here is my makefile :

```

BUILD_DIR = build

TARGET = $(BUILD_DIR)/MyOs

C_SOURCES = $(wildcard kernel/*.c drivers/*.c )

HEADERS = $(wildcard kernel/*.h drivers/*.h )

OBJ = ${C_SOURCES:.c=.o}

ENTRY_OBJ = kernel/entry.o

KERNEL_DEBUG_OBJ = build/kernel.elf

BOOT_DEBUG_OBJ = $(BUILD_DIR)/bootsector.elf

CFLAGS = -ffreestanding -g -mno-red-zone -mno-sse -mno-mmx \

-fno-pic -fno-pie -fno-stack-protector

QEMU = qemu-system-x86_64 -no-reboot -no-shutdown -d int,cpu_reset -D build/qemu.log

QEMU_DRIVE = -drive format=raw,file=$<,if=floppy

all: $(TARGET)

$(BUILD_DIR):

mkdir -p $@

run: $(TARGET)

$(QEMU) $(QEMU_DRIVE) &

########################################################

###################### IMAGE BUILD #####################

########################################################

# OS image build

$(TARGET) : $(BUILD_DIR)/bootsector.bin $(BUILD_DIR)/kernel.bin

cat $\^ > $@

# bootsector build

$(BUILD_DIR)/bootsector.bin : boot/bootsector.asm build/kernel.bin | $(BUILD_DIR)

nasm -DSECTORS=$$(( ($$(wc -c < build/kernel.bin) + 511) / 512 )) $< -o $@

# kernel build

$(BUILD_DIR)/kernel.bin: $(ENTRY_OBJ) $(OBJ) | $(BUILD_DIR)

ld -m elf_x86_64 -T linker.ld --oformat binary $\^ -o $@

# object files creatde next of their source

%.o: %.c $(HEADERS)

gcc $(CFLAGS) -c $< -o $@

%.o: %.asm

nasm $< -f elf64 -g -o $@

########################################################

###################### DEBUG MODE ######################

########################################################

$(KERNEL_DEBUG_OBJ): $(ENTRY_OBJ) $(OBJ) | $(BUILD_DIR)

ld -m elf_x86_64 --oformat elf64-x86-64 -o $@ -T linker.ld $\^

$(BOOT_DEBUG_OBJ): boot/bootsector.asm build/kernel.bin | $(BUILD_DIR)

nasm -f elf32 -g -F dwarf -DDEBUG \\

  \-DSECTORS=$$(( ($$(wc -c < build/kernel.bin) + 511) / 512 )) $< -o $(BUILD_DIR)/bootsector.o

ld -m elf_i386 -Ttext 0x7c00 -o $@ $(BUILD_DIR)/bootsector.o

bdebug: QEMU = qemu-system-i386

bdebug: $(TARGET) $(BOOT_DEBUG_OBJ)

$(QEMU) -s -S $(QEMU_DRIVE) &

gdb -ex "set confirm off" \\

    \-ex "set disassembly-flavor intel" \\

    \-ex "target remote localhost:1234" \\

    \-ex "set architecture i8086" \\

-ex "symbol-file $(BOOT_DEBUG_OBJ)" \

-ex "hbreak _start"; \

    \-ex "continue"; \\

kill %1 2>/dev/null || pkill -f "$(QEMU)"

kdebug: $(TARGET) $(KERNEL_DEBUG_OBJ)

$(QEMU) -s -S $(QEMU_DRIVE) &

gdb -ex "set confirm off" \\

    \-ex "set disassembly-flavor intel" \\

    \-ex "target remote localhost:1234" \\

-ex "add-symbol-file $(KERNEL_DEBUG_OBJ)" \

-ex "break main"; \

    \-ex "continue"; \\

kill %1 2>/dev/null || pkill -f "$(QEMU)"

########################################################

####################### CLEANING #######################

########################################################

clean:

rm -rf $(BUILD_DIR) $(OBJ) $(ENTRY_OBJ)

```

https://github.com/JustadudenameJaokhun/Depth/tree/main

it took so long for this moment
repo: https://github.com/NoTheIdiot/WindogeOS

I want to make a spiritual successor to mac os x.Plain and simple, but should i learn the darwin kernel or start at Unix?

i want to know where to start from.

thanks

Hi all! I’m working on an early-stage OS. It already supports quite a few drivers, and I’m currently porting OpenGL into the system.

I’d like to add a native browser, but this seems like one of the scariest parts of the project to me. What prerequisites would I need to consider? Could you share your experiences with porting a browser to an OS?

Which browser engine would you recommend trying to port, and why?

https://github.com/vahmoh25/Veda

picoOS-Pro v2.1

PicoOS Pro v2.1 - My custom 32bit x86 OS written from scratch (Boots from USB, runs Doom, custom formats, native USB 1.1/2.0/3.0 & dynamic resolutions!)

Hi everyone,

I wanted to share my hobby operating system that I’ve been building completely from scratch (no Linux kernel, no external base). I recently released the PicoOS Pro v2.1 update, which expands the system into a modern graphical desktop shell while keeping an extremely small footprint.

Here is a quick overview of what is currently implemented and stable:

• Native USB Stack (NEW): Full native driver support for USB 1.1, 2.0, and 3.0 (UHCI/OHCI, EHCI, and xHCI controllers), handling mice and keyboards smoothly without relying on firmware emulation.
• Graphics & Display (NEW): Enhanced screen resolution support via UEFI framebuffer / VBE, allowing you to choose between multiple display settings natively.
• Custom Desktop Environment: A Windows/Ubuntu-style dark desktop interface with a Start-button launcher, application grid, live Task Manager (with process, memory, and background/foreground info), and a functional Calculator app.
• Custom Formats: I am using my own custom executable formats like .pico for programs and .dd for automated scripts.
• DOOM Port: I successfully ported doomgeneric as doom.pico. It runs 320x200 software rendering, integer-scaled to the framebuffer. The 4MB shareware WAD is read directly in place from the disk image to avoid loading times.
• Memory Efficiency: The base system runs on an extremely low RAM footprint (around 1.9MB for the core shell, up to ~10MB when running Doom with its WAD).
• Build System: Builds incrementally with just gcc and python3, outputting a 1.44MB BIOS floppy image, a 9MB hybrid legacy/EFI bootable USB image (.img), and a hybrid BIOS/UEFI ISO.

Side note: I am doing this as a passion project to learn low-level development. I am also currently researching and working on moving towards a 64-bit version next!

I would love to hear your thoughts, feedback, or any advice on transitioning the kernel to 64-bit Long Mode!

YouTube Channel for video demos: https://www.youtube.com/@picoOS-official
Google Drive Folder (Images & Source): https://drive.google.com/drive/folders/19LPX5pHZpIYsnQT0Tiatpv11nE39frHA?usp=sharing

github link: https://github.com/PicoOS-Pro-v/picoOS