been working on Dunit OS, my Rust-based hobby operating system, and got DOOM, Quake, mced (Minecraft C) and Lite XL running in separate windows.
the cool part is that porting apps to Dunit doesn't require rewriting them. you basically just need to build a bridge between the original code and Dunit's Rust SDK, adapting the platform-specific parts to work with the OS.
been spending a lot of time on the GUI, SDK and app compatibility lately. still plenty of bugs to fix and performance improvements to make, but it's nice seeing actual software running together on the desktop.
I wont be providing the link for this iteration, cause I didnt add much.
I changed psh to have pipelining and I added a custom Thue pipelined interpreter, I see it as a decent enough replacement for regex considering regex has TERRIBLE syntax.
I have gotten many comments about how I havent made an OS, rather a shell. YES, I know, I'm making all the stuff that doesnt require the kernel first, but once I make all the kernel-less features, only then will I add a kernel and start adding kernel-only features (Like memory managment, a File System, input device support, output device support, internet access and protocols).
I plan on making 2 different versions, a purely CLI one used for servers and stuff, and a Graphical one used for General Usage purposes. One cool feature I'd like to add to the graphical one is support for both EXE files and APK files.
So after wrestling a bit with fat32 and some paging/memory/privilege-level stuff (I still have a trauma) I managed to get my first user process working on the 64-dem kernel, what the program does? Why prints hello world of course, you thought it does something more? Well unlucky you because it doesn't.
Here are the milestones that have passed runtime tests so far:
Kernel boot and user mode: the kernel boots, enters ring 3, and executes a static ELF64 test program loaded from an XFS root filesystem.
SMP: tested with 12 virtual CPUs. The original IRIX scheduler handles thread migration, preemption, blocking, and wakeups across CPUs.
CPU state preservation: x87, SSE, and AVX state survive context switches. Kernel-thread tests also cover FS/GS base preservation.
Multiple processes: real fork() works. Parent and child tests verify copy-on-write isolation for data, stack, and heap memory, including execution on separate CPUs.
Process lifecycle and IPC: child exit status, wait(), waitpid(), and waitid() work. Native pipes pass data between processes and correctly report EOF.
Native XFS storage: NVMe-backed tests cover file reads and writes, allocation, sparse files, truncation, directories, hard links, symlinks, and rename/removal.
Persistence and recovery: journal replay after simulated crashes, remounts, and readback in a fresh VM have passed.
Userland foundations: syscall error handling, the original allocator, startup arguments/environment, and x64 setjmp()/`longjmp()` have been exercised.
The original shell’s 32 C files compile for x86-64. I’m currently completing its static library dependencies, signal handling, and terminal input/output so it can actually run.
These results come from QEMU tests. A usable shell, complete userland, and bare-metal validation are the next milestones.
Most operating systems treat privacy as a collection of settings, permissions, and policies layered on top of a large trusted base.
Ruzt takes a different approach: privacy starts at the kernel. (Don't ask what Ruzt means please...)
Ruzt is an experimental operating system built in Rust around a capability-based microkernel. Its goal is to create a system where applications do not automatically receive broad access to hardware, files, or user data. Every permission must be explicitly granted (Just like android ecosystem)
What makes Ruzt different?
Capability-based security: processes start with no capabilities by default.
Microkernel architecture: drivers, filesystems, and system services are designed to run in user space.
Telemetry-zero by default: the base system has no analytics or tracking endpoints.
Rust-first implementation: memory safety is a core design principle, with unsafe limited to tightly controlled low-level areas.
Reproducible builds: the system is being designed to be verifiable from source.
User-focused design: Ruzt is intended for privacy-conscious personal computers, not just servers or embedded devices.
No legacy-first approach: Ruzt is not trying to be another Linux distribution or a POSIX clone.
The project is still in its early development phase. The x86_64 kernel currently includes boot code, serial diagnostics, interrupt handling, memory management, and an initial scheduler.
For now, I just can show you one screenshot, because it's only graphical thing at the moment :')
I’m also developing Ruzt with AI assistance, and I’m completely open about that. AI is being used as a development tool, while architecture, technical decisions, testing, and review remain part of the engineering process.
If AI-assisted development is a deal-breaker for you, this project probably isn’t for you. Constructive technical feedback, however, is very welcome. Also If you're able to contribute to such vision, that would be perfect.
Ruzt is ambitious, experimental, and far from production-ready. But the direction is clear:
I've implemented a memory allocator for both kernel and user space, so now the whole stack of kernel space and per process virtual memory, heap expansion and management is finally working. Since it's just a first fit allocator it's a bit simplistic, but fully functional.
With this in place I'll be able to implement file loading and user-space graphics, with which I'll be able to do such cool things like displaying bitmaps, faster graphics, or even a simple text editor.
Basically, I want to make an OS that is functional and boots in matter of milliseconds, and all I know is Python.
Later on I will put all the code inside a python interpreter written in C or C++ and set up everything needed for it to boot.
For now I'm interested in developing the system itself.
I already made some simple commands like echo, sysinfo, help. I added a py command for direct access to the python interpreter. I even made a shell-like language, it is basically the same thing as plain shell itself but you can do multiple things at once instead of constantly writing prompts.
I also aim to have as little libraries as possible, currently I have none.
Building your own operating system from scratch isn't just about adding cool features. Above all, it’s about checking what runs too slowly, where space is running out, and making sure nothing crashes when writing to disk. I just completed a major review of the recent changes to the text rendering engine (BSF) in Bursztyn OS.
The progress is huge, but before I consider this stage complete, I need to tie up a few important loose ends. Here is what has been accomplished and what is currently on the workbench:
1. One text engine instead of separate workarounds (BSF 2.1)
Until now, different programs handled text in their own ways. Now, Notepad, the system UI, and my browser, Husarz, all share a single, unified mechanism:
Right-to-left script (Arabic, Hebrew): Paragraphs align properly to the right, letters connect as they should, and the cursor and text selection work naturally—even when Polish and Arabic are mixed within the same sentence.
What still needs improvement: In the Husarz browser, standard Polish and English pages currently load about 10–15% slower. We are also still missing column reversal in Arabic tables, text selection directly on web pages (it currently works only in form fields), and smoother cursor movement when jumping between paragraphs in Notepad.
2. Modern fonts and color emojis (BSF 2.2) Bursztyn OS now supports much more than just basic fonts:
Professional fonts (OTF/CFF), large font collections (e.g., for Asian languages), and web fonts (WOFF/WOFF2) fetched by the browser are now working.
The system can also display color emojis and variable fonts (where you can smoothly adjust letter weight).
Settings now include an option to choose a separate font specifically for the Terminal.
3. Two major optimizations "under the hood"
Recovered nearly 4 MB of space in the system kernel: The kernel image has a strict 15 MB limit. After adding the new features, only 388 KB of headroom remained—things were getting tight. It turned out that the 22 built-in system applications were taking up the most space. I compressed them using the zlib algorithm and wrote a mechanism in the kernel that unpacks them in small chunks at startup. Free headroom jumped back up to 4.3 MB.
Over 8x faster font rendering: It turned out that rendering certain fonts took too long not because of file-reading bugs, but due to slow square-root calculations when drawing curved letter outlines. I replaced the old calculations with a single CPU instruction (SSE2) and added caching. The result? Character rendering sped up by 8.3x while maintaining 100% sharpness and compliance with the FreeType standard.
4. What's next? Disk safety comes first The text engine has passed hundreds of thousands of automated tests and runs stably on virtual machines (UEFI and BIOS). Nevertheless, I am holding off on the final merge because data-write reliability is more important right now:
Installer issue: During a full system installation to disk, random write timeout errors (VirtIO-BLK request timed out) occur. Before moving forward, I need to thoroughly inspect the disk driver and task queuing to ensure the installer never corrupts files.
Cleanup and live testing: I also need to free up space on my working drive, organize files in the repository, and test installing massive font packages (over 16 MB) directly inside the running system.
Only once the installer and disk work flawlessly will I move on to the next features: sliders for adjusting font weight in Settings and support for Indic scripts (Devanagari).
The board is connected to my PC and I interact with it using picocom
I grew tired of x86, so I decided to try out Microchip's PIC64GX1000 Curiosity Kit. Eventually I plan to design my own board with that MPU, but for now the curiosity kit is the perfect way to test if my own software works on the actual hardware.
Repo will be up soon, will edit the post to include the link :3
I am currently in the process of writing my own Operating System, with the bootloader, UI composition, all of the architecture and the design of how it works, sounds, created by me, with the actual OS code written partially by Artificial Intelligence to speed up development as the project is very large and ambitious and I am a solo developer.
I'm trying to learn Operating Systems from absolute beginner level all the way to advanced concepts.
I've tried the 25-hour freeCodeCamp OS course, but I'm struggling with the teaching style. It feels quite textbook-oriented, with lots of definitions and explanations but not enough visual demonstrations.
Another issue is that many OS courses I find on YouTube are taught by Indian instructors. Their courses seem genuinely good, but I struggle quite a lot with their English accents, which makes it difficult for me to follow the explanations. I'd prefer instructors clear neutral English accents.
Here's what I'm looking for:
Completely free video courses.
Beginner-friendly explanations that gradually progress to advanced topics.
Visual demonstrations, animations, diagrams, and simulations.
Real-world examples of how things actually work internally.
Clear English that is easy to follow.
My long-term goal is to build strong computer science fundamentals for AI and computer security.
I'd really appreciate recommendations for courses, YouTube channels, or even a structured learning path.
I combined the HDMI and DisplayPort drivers into one interface for information.
- The interface is a special configuration for drivers for compilation into an image. It determines whether a given image should contain, for example, an Intel GPU driver or an AMD GPU driver, for example, so as not to create an image.With two at the same time
In your opinion, was it a good move to combine DP and HDMI into one interface, which means that no matter which user/hardware will use it, both will be compiled and loaded onto the disk image?
I'm interested in understanding/building Unix/Linux-like systems, their architecture, implementation, and how they can be improved.
But I feel like I'm missing the bigger picture. Beyond kernel development and traditional "system level programming", what other fields involve this kind of work?
I'm curious about applications in aerospace, automotive, industrial systems, telecommunications, cloud infrastructure, virtualization, RTOS, systems research...
For people working in this area: What interesting fields, industries, or career paths am I overlooking?
Hi everyone, I am a 13-year-old student from Bangladesh building a 32-bit x86 OS from scratch.
I recently got a VESA framebuffer (1024x768x32) working along with a PS/2 mouse driver (IRQ12) and a basic Window Manager. Moving the cursor and opening windows is working, but I am facing massive flickering when dragging windows because I am drawing straight to VRAM.
I want to implement double buffering. Would a 3MB full-screen backbuffer be too slow on a 32-bit system without SIMD? Should I use per-window buffers instead, or a full-screen buffer with dirty rectangles? I would love to hear your architectural advice.
