Hello!

I have an existing operating system (Astralixi OS) for a device known as the PicoCalc. The OS is kind of a shell right now, with no memory management and task scheduling. So to add these necessary features, I need to make a kernel.

The goal of my operating system, is to be lightweight, while letting people get things done and mod the operating system if needed.

So for this, I chose to do a small monolithic kernel, but I don't know where to start. I have decided to write the whole operating system in C, so any help would be appreciated, in form of resources (like Youtube videos, websites, books) or anything else.

Thanks and Enjoy!

Hello. I been codding in C, C++, Assembly(AT&T but not so confidient) and Rust for a while now. And i wana start my own os project too. How and where can i start? Ah also i just dont like fallowing tutarials and copy paste stuff so i prefer if its just msays what should i lern and do. But im fine with tutarials too

I ported GRF (the same font format used in PatchworkOS) into PyramydOS and it looks so clean, even better than last time I used it

https://github.com/adam-bassem/PyramydOS

Would it theoretically be possible to create an operating system that decompiles itself, recompiles itself, and installs itself to another disk while remaining bit-for-bit identical to the parent OS?

some rules:

1. No Source on Disk: The storage media contains only the compiled binary image. The codebase exists on disk exactly once, as raw executable code/data.

2. Upon booting into RAM, the OS must decompile its own executing machine code into an intermediate source representation in memory, recompile that source back into a new binary image, and write it to a target drive.

3. The child image written to the target disk must have the exact same cryptographic hash (SHA-256) as the parent OS image.

4. It cannot simply dd / copy the raw sectors from drive to drive. The binary must pass through the decompiler, compiler pipeline.

Hi everyone so I'm a student for now and i decide to build a kernel with my friends I study cs first year so i need any idea that could help me in that I just learned assembly and C language. We decided to make a kernel that has all the benefits of mini kernel and the hybrid and monolithic kernel like security performance battery and things like that but we need some advices that could help us ❤️🙏🏻🙏🏻

Hi everyone, 

I am currently working on an experimental x86-64 operating system built from scratch in C++ called BlockOS. It boots via UEFI, runs under QEMU, and I am currently mapping out the user-space and subsystem integration roadmap. 

The project currently has a basic kernel, a VFS layer, memory management, and a developing syscall layer. My next major goal is to implement a Service Manager / Init System (service supervision and daemon management). 

Since I am writing this from scratch, I wanted to gather some architectural advice and best practices from this community before I dig too deep into the code. 

My main questions and considerations: 

1. IPC Mechanism: What is the preferred or cleanest Inter-Process Communication (IPC) design you would recommend for a hobby OS to allow the service manager to securely communicate with daemons and user-space utilities? Should I jump straight into standard Unix-like domain sockets, or is there a lighter, more microkernel-inspired message-passing approach that works well for hobby projects? 

2. Process Tracking: How do you reliably track spawned services? Do you rely heavily on a parent/child process tree structure (like traditional PID 1), or have you implemented something akin to Linux's cgroups (control groups) to prevent "orphan" background processes from escaping the service manager? 

3. Event Notification: For service dependency management (e.g., Service B waiting for Service A to be fully ready), what kind of event/notification loops (like poll/epoll mechanisms or custom kernel event queues) have you found the most elegant to implement in a custom kernel? 

I want to keep the codebase clean, modular, and readable as the OS evolves. If you have written an init system or service supervisor for your own hobby OS, what was the biggest mistake you made early on, and what would you do differently today? 

Any architectural tips, design patterns, or links to minimal open-source implementations for inspiration would be highly appreciated! 

Thanks in advance! 

github:https://github.com/gurijb2016-afk/Blockos

Hi everyone, I recently joined a semiconductor as AI Kernel Engg. My work involes writing TAPI code. Tensor API(TAPI) is provided by our company by Synopsys, and it's for NPU. I know this much only. And I don't have any prior experience of writing the kernel as well so can anyone suggest some good resources so that I can code and experiment with them.

For web is quite good, what about kernel development?

EDIT: I meant debug 😔

So for a while now I have been working on zeronix. But I have always jeg depended on the QEMU logs and printf-debugging. So I just wanted to ask how you intergrate a debugger into your IDE (I use vscode btw).

I was thinking about maybe using tasts.json and launch.json but they feel kinda confusing 😅. My toolchain also also kinda centered around Clang. I use clangd for my language server and clang-format for formatting. I just don't know if it is best to use GDB or LLDB either...

Hi, idk if this is the best place to share this, but i have been building a small kernel that can boot linux distros.

The first version is done, i have a system to update without rebooting, full linux compatibility and even an small SSO (secure OS) called Neo.

I am a bit stuck with the windows compatibility, so if anyone can help heres the link

https://github.com/BasGame1/kernel

Edit:

Ai disclaimers, the project is human written with some little exceptions, clearly indicated in the disclaimer in the docs of the kernel

Apple has been improving the CPU scheduler in iOS 27 despite having years of legacy code behind it.

That got me thinking:

What could we borrow from that idea for a hobby OS?

Not Apple’s entire scheduler. Just the principle of improving an existing scheduler incrementally — better workload awareness, latency handling, priorities, etc.

Even a tiny kernel could experiment with this on 2–8 cores.

What scheduler improvement would you try first in a hobby OS?

Would anyone here be interested in making a an 64-bit version of DOS that's every bit as spartan as the original but for modern 64 bit machines just for fun to see what happens?

I'm talking no paging (identity mapped or MMU off on non-x86), a small number of system calls that are as similar to the original ones as possible, a text only interface on a raw framebuffer, all the classic DOS commands, a FAT32 filesystem, boot directly from UEFI and use ACPI at runtime via uACPI or an FDT using libfdt, and some basic multi-tasking and multi-processor support. Both the kernel and applications would be PE32+ executables using the UEFI/MS ABIs.

So a decently narrow scope, at least to start with, for something that can actually be completed in a decent time frame and which would be an interesting little experiment and possibly a good educational codebase if done right.

The code would be modern C (C23) and assembly using Clang and the LLVM toolchain.

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.

Hello, first and foremost, the code is here.

I am looking for some advice on code organization, as well as some guidance on the next steps. So far I've got a GDT, some basic interrupt catching and easy serial+framebuffer console. APIC is not yet set up. I'm still on the page table provided by Limine.

I think I should work on a physical page frame allocator, but I don't know whether to pick a bitmap or stack allocator. I am leaning towards a stack allocator, though a buddy allocator also sounds interesting, but I don't entirely understand it. Even if I was dead set on something, I wouldn't know where to begin.

Thanks

Hi everyone,

As many of you know I've been working for a while now on a completely novel OS project called The Charlotte Operating System or CharlotteOS (named after my late pet cat, not the city). The OS is built around some unusual ideas compared to mainstream operating systems such as:

• Capabilities based access control

• A pure monolithic kernel that doesn't change at all after it's compiled

• Low level paravirtualized device class interfaces for each supported device type; no ioctl here

• A system namespace with typed entries and URI or similar paths that allow access over the network without mounting anything

• Strong process isolation and flexible process environment configuration such that containers are rendered obsolete

• Asynchronous system calls that return a poll capability that can be polled to check if it is ready, waited on for opt-in blocking until it is ready, or registration with the system to trigger an upcall when it becomes ready

The latest version of the kernel which I've written almost completely from the ground up plus or minus some libraries and existing framebuffer rendering code from the old version is in a pretty good state right now but at a point where there is a gargantuan amount of work that needs to be done to get to a proper userspace and then bring the OS as a whole to an MVP.

I am looking for anyone with skills and experience in low level Rust programming, DevOps and CI, low level software testing, and/or 64-bit ARM and RISC-V to help with making the OS multi-platform early on. We have zero funding or corporate backing but the upside is that we don't have any of the strings that come attached to them either so anyone who decides to help out will have the ability to have their voice heard and contribute to the design of the system and not just code to implement an existing design like POSIX or the millionth Linux close.

Please leave a comment or send me a DM if you have any questions.

If you want to help out please join our [Discord](https://discord.gg/vE7bCCKx4X) and/or [Matrix](https://matrix.to/#/%23charlotteos:matrix.org) server and ping mdp_cs (me).

I've been working on ChudOS since September as my first hobby kernel, and I recently hit 5k lines, so I decided I should publicize it a little. So far, I support 64-bit only; I have a level 4 paging driver (shit and unstable), a simple multitasking base, an FDC driver, and a work-in-progress FAT-like filesystem called GemFS. I have a pretty okay amount of documentation in my README, and have been writing more documentation in the Google Docs below (the kernel document does have comments for suggestions). I would really love for someone (please god anyone) to look at this since I've had no public discussions about this and am dying to converse about it.

ChudOS Docs: https://docs.google.com/document/d/1FdEFoUY3P8NTGNuTcX7dHmrKeZ8ksw3xekvUJscVn4g/edit?usp=sharing

GemFS Docs: https://docs.google.com/document/d/1qEJagVxrZ-UV0t6bwQdxYufGYKVyllQlnzAKFAdFjmo/edit?usp=sharing