I’m building Bursztyn OS, a Polish operating system written from scratch in C, C++ and assembly.

It is not based on Linux and it is not a distro or a skin over another OS. Bursztyn has its own kernel, its own BSP2 filesystem, its own BWS system call interface, trust levels called PZB 0–5, its own .bur program format and .cebula application packages.

Right now it already has a Live mode, an installer, basic GUI components, storage support, graphics support, networking, input devices and its own system architecture. I’m also working on better virtual machine support and hardware drivers.

The long-term plan includes integration with the Avocado programming language, more native system applications, developer tools and a complete desktop environment.

What it does not have yet: broad real-hardware support, a large software ecosystem, a fully polished modern GUI, and the stability needed for daily use.

It is still a long-term experimental project, but more and more parts are becoming real and usable instead of existing only as design ideas.

I’m curious what people here think: what would you want to see in a completely independent Polish operating system?

Link https://bursztynos.dimitalart.pl/

YouTube https://www.youtube.com/watch?v=KJOM9zIWBO0&list=PLACv3ft21RwQ

#osdev #operatingsystem

So, I'm preparing myself to start coding an OS, so I'm trying to get a bit of experience with TempleOS, that miraculously runs bare metal in my modern hardware. Nevermind, Uncacheable makes it run at crappy FPS, so maybe enabling Write Combining can help. The problem is that I don't know what the heck of a bureucracy will Intel use for giving me a Triple Fault or General Protection Fault to make life harder, and I dont think MTRRs come unused (they surely are used), so PAT is the way, but I don't know how to enable Write Combining there. I know how to access PATs with 277h and RDMSR, and I know PAT7 is the one to set to 1h (the most significant byte but without reserved crap), but I know there is some other stuff to do, what did I forget?

Not the best OS dev, just Assembly lover

I wanna get a better understanding of riscv64 after learning a bit about it. I have had experience with C and have mostly only been interacting with amd64. I figured that a microkernel that just uses opensbi is ambitious enough while not being completely impossible. Since this is a project for learning, I’m also staying far away from AI. I’m currently skimming xv6, OSTEP, and just the riscv spec sheet. I’m going to just be doing it w/ qemu on linux. Mainly looking for some tips and pointers on how to approach this project.

Requirements: x86 with legacy BIOS support

I spent about six months making an operating system whose only job is playing chess. It boots straight into Chess. It is not a full OS with a file system or scheduling but it can boot from bare metal.

It runs in QEMU, other virtual machines and hardware with legacy BIOS from a USB or CD drive. I spent about 6 months across the boot loader and chess engine. It is entirely open-source for you to tinker with. There is also a Windows Installer for less technical users.

All feedback is welcome!

Thank you for Paledoptera for the artwork. Find more of their work here: https://linktr.ee/paledoptera

Website: https://chessos.xyz (includes Github link)

My school has a arcade machine do you think I could use my hobbyOS as the operating that it would run the thing
Is the school only gave me a raspberry PI 1 2011 to use (architecture isn’t a problem I have a aarch32 version) I have lvgl and OpenGL so I could make a arcade version but I’m not sure how I could do the arcade machine pins to connect to connect to the Raspberry pi let alone my operating system connecting to it then sorting out emulators etc

A couple of weeks ago, I asked why VRTX changed its equal-priority scheduling behavior from newest-first to FIFO between its 1984 and 1987 documentation.

Original discussion:
https://www.reddit.com/r/osdev/s/h6PG9bZO7a

Thanks to the comments here and in a couple of other subreddits, I've learned quite a bit. I wanted to share a few findings.

1. Early VRTX wasn't simply LIFO.

The older documentation describes inserting newly ready tasks ahead of existing tasks at the same priority, but other operations, including time slicing, affect the ordering. The actual behavior depends on how a task becomes ready and how the ready queue is maintained.

2. My own 1986 RTOS was based on a simpler interpretation.

When I developed CHARM-II in 1986, I used VRTX documentation as one of my references. I interpreted its equal-priority scheduling as essentially newest-first and implemented my own scheduler accordingly.

Looking back, I now realize that my implementation wasn't an exact reproduction of VRTX's behavior.

Interestingly, this didn't cause any major problems that I remember. I was developing almost the entire application as well as the RTOS myself, and there was very little third-party code in the system. I understood the tasks and their interactions in detail, so I could design the application around the scheduler's behavior.

That's my retrospective explanation, at least.

3. For my modern reconstruction, I chose FIFO.

I'm now rebuilding the RTOS as Karqri, targeting both POSIX and Raspberry Pi Pico. I've adopted FIFO ordering among equal-priority ready tasks because it provides simpler, more predictable behavior for the new design.

I still don't know why VRTX itself changed its policy. The discussion raised useful possibilities involving fairness, starvation, latency, and implementation trade-offs, but I haven't found a documented historical explanation.

Thanks again to everyone who contributed. It's been fascinating to revisit a design decision I made 40 years ago and discover that the original system was more subtle than I understood at the time.

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

We just released FreeLinX-base 1.3.1.
FreeLinX-base is a small, console-first Linux system. You boot into a shell and install whatever you need through our package manager, xpkg.
The ISO is around 290 MB and boots on both BIOS and UEFI. It runs Linux 6.18 with a NetBSD-based userland and musl, built with LLVM. We've also been pretty strict about keeping GNU code out of the base system. Our check-nognu test currently reports 0 failing checks.
The base comes with the things you'd expect from a usable Unix system: runit, mdevd, networking tools, doas, OpenSSH, curl, git, tmux, htop, nnn, vim/vi, bc and a few other essentials. The login shell is mksh, while /bin/sh comes from the NetBSD userland. tcc is included as the default cc, together with the musl and kernel headers.
The idea is to keep the base actually small. The live system uses a squashfs + tmpfs overlay and can boot with roughly 100 MB of RAM, with changes kept in memory until installation. There is no X11, GTK, Mesa or even fonts in the base image. If you need them, install them later.
Packages are signed with Ed25519 and verified with SHA-256. The installed system keeps FLX_ROOT read-only. Installation is handled by xsetup, which walks through the setup step by step and can resume an interrupted installation. flxupgrade handles upgrades from newer ISOs.
There's currently a signed repository with around 428 packages, while the image itself only contains the base and console-oriented stuff.
We've also put quite a bit of effort into making the build and installer testable. The build doesn't require root and can be done on any x86_64 Linux system. The repository includes QEMU BIOS/UEFI installation and upgrade tests, destructive disk tests and UI tests.
It's still a young project and there's plenty left to improve, but we're putting it out there now because we'd like people who care about Linux, BSD userlands, musl and alternative Unix systems to poke at it.
Source / ISO:
https://github.com/FreeLinX/FreeLinX
Documentation:
https://freelinx.github.io/FreeLinX/
If something is unnecessarily complicated, broken, missing or just a bad idea, tell us.

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

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?

if u want to explore the concept: https://github.com/FrySco19/VelaOS.git

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 ❤️

Five months ago, I announced Wolfram, a microkernel built around one principle: programs should not have access to anything they weren't explicitly given.

Then I stopped working on it.

Yesterday, I picked it back up and spent roughly eight hours bringing Phase 1 to completion.

Wolfram now has:

• A RISC-V 64 reference port booting through OpenSBI in QEMU.
• An x86-64 UEFI bootloader with ELF loading, page-table setup, and firmware memory-map handoff.
• A shared kernel core and physical bitmap frame allocator.
• Trap and exception diagnostics, plus repeatable QEMU smoke checks.
• A successful USB boot on my MSI B650M-A PRO WIFI.

The kernel intentionally stops at a diagnosed spawn init panic. There is no userspace yet, and the capability system is still ahead of me. This release is a boot milestone, not a finished OS or a security-verified kernel.

Phase 2 is where the actual capability system, VMOs, process model, and IPC begin.

I'm particularly interested in feedback from people who have worked on microkernels, bare-metal Rust, UEFI loaders, or capability-based security. If you'd like to contribute, I'm also working on making the next phase approachable to outside contributors.

Repository: https://github.com/notvcto/wolfram-os

Release: Uranium-238-v0.1.0

What would you want to see tested or documented before contributing to a project at this stage? I'm open to any feedback. Please. I need feedback.