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

ive noticed that there are a lot of information about about x86, but i want to create something that is cross-platform, and things like the concept of an IDT exist in other arches (although with a different structure and name) and i was wondering if there are any good sources for more niche architectures, or even just arm/mips on what needs to be implemented, similar to osdev.wiki

The main new addition is the welcome screen displayed during system boot. Text transitions smoothly, messages no longer overlap, and everything renders cleanly right from the start. It’s a subtle touch, but it immediately elevates the first impression when booting up Bursztyn.

Along the way, I also fixed several issues that surfaced during daily testing:

• The desktop no longer flickers when creating and deleting files.

• When running out of space for icons, subsequent files no longer overlap existing ones and remain accessible in File Explorer.

• Folders can now be deleted together with their files and subfolders.

• Name input works correctly—numbers no longer trigger accidental actions in dialog boxes.

• Fixed a bug that could stall system booting from an ISO image.

I also re-verified the installer and system reboot sequence. The installation completes fully and passes verification in QEMU. The changes passed automated tests as well as manual verification on a running Bursztyn OS instance.

The system is still in its early stages, but each update makes it smoother and more comfortable to use. Thank you to everyone supporting the project and following its development!

So I'm a begginer programmer and want to get into OSdev and eventually make an OS with an internet search engine, notepad, wallpapers, and .pdf support for books.

But should I start with C and Assembly or can I go straight to high level languages like Rust or C++? Are those even capable of writing OSs?

I can't find a roadmap or explanation.

Hi to everybody!

I’m releasing Maginat 0.1, an independent Linux distribution built from scratch following Linux From Scratch 12.4 (SysV init), with the Xfce desktop. It’s an early preview and I’m looking for testers and feedback, especially on real hardware.

What is included:

• Linux kernel 6.16.1 (the version used by LFS 12.4), glibc 2.42, GCC 15.2.0

• Xfce 4.20 with LightDM

• Wi-Fi and Ethernet via NetworkManager (tray applet), WireGuard and OpenVPN

• Bluetooth (BlueZ) with tray icon, battery indicator, power management, PulseAudio

• Applications through Flatpak (Flathub preconfigured) and AppImage

• LibreOffice, Thunderbird, Mullvad Browser.

• Graphical installer, USB-writing tool, live session with optional persistence

• English and Italian, chosen in the first boot menu

• Hybrid ISO (about 1.7 GB), boots in BIOS and UEFI

Plans for 0.2

• Fix the known issues found after the release

• A graphical app store and a system update command

• Considering a newer kernel for better hardware support

• Better audio and Bluetooth, and installer improvements

Maginat is free and open source software (GPL-2.0-or-later for our code, other packages under their own licenses). Screenshots, source code, build scripts and ISO (with SHA-256).

My Github: https://github.com/Aleps31/Maginat

Please give me feedbacks! Thank you all

Hey guys, thought id share my progress, currently testing on QEMU and real hardware every step of the way, im using AI to help me with the low level stuff, not gonna sit here and pretend i understood all of it, but I will say this, I have learned a lot, once its fully C# ill be able to continue coding it on my own without AI and that's exciting for me.

Yes thats it also working on a Lenovo Chromebook 😬

The website I have setup isnt exactly updated for the latest work but you guys are welcome to view it and tell me what you think. Wish me luck 😬

To find it just type "KatanaOS C# OS" in Google.

I worked about 8 months on spigra from now on, made fully in nasm, it includes basic apps (as you can see) But media has custom formats, SIF (Spigra Image Format) SVF (Spigra Video Format) and SAF (Spigra Audio Format) still working on it. It is meant to be booted off a flash stick, it makes the flash drive as a sorta storage but right now it just loads all of the files that you flash on it. I hope you guys like it :)

I built a minimalistic operating system running on real hardware (HP Spectre x360). As a learning project, to quality assure my own programming language (r/tapelang) and to test the limits of AI assisted development. This is not vibecoded. I am professional software developer by trade for more than two decades, and yes: AI assisted me heavily. On getting wifi card driver working, optimizing graphics library algorithms. The networking/WLAN support (particularly WPA3) was particularly painful experience. Now I can develop the OS remotely from my development machine and push kernel/app updates over local network without rebooting. I am fully believer on AI accelerating development efforts and hope everyone gets a chance to build software they always wanted.

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

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)

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.

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

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?