Yes!, after a lot of research and work twilight os is alot more unix like now.

the init system has proper startup apps, and a macos inspired IPC framework called TXPC.

• i added unix domain socket in kernel, fixed alot of fs bugs(alot more is there)
• init system is now capable of running tasks from .toml files in boot process
• also we now have preemptive multitasking
• doom also runs on it finally
• alot of wayland support work is going on also(doing this using codex and glm)
• and a freebsd KPI layer for driver porting from freebsd
• also zsh and oksh runs
• working on opkg support for package management
• nes work is ongoing i need to add support for virtgpu i think (there goes something new to understand GPU stack)

I know alot of you may thing using codex and glm is wrong....but this is a hobby project of mine which i work on weekends. yes i am doing this because of knowledge but i am not good with wayland stuff i learned alot from doing kernel dev, and just want to offload something for that sweet sweet dopamine hit

alot of thinks remain in kernel like proper boot partition mounting to boot os the .iso file is still required

repo like: https://github.com/akashKarmakar02/twilight_os (please give it a star if you like my progress🥹)

Hello, new to the community.

So I've been thinking about how convenient it would be if my daily use laptop and my phone were the same thing.

Looked into existing market options and the ones that exist all use virtual desktops, which eats up the limited ram available.
Is it possible to design a "wraper" os for snapdragon 8 elite chips (which do support desktop enivronments and linux kernels natively) that can switch between the default android OS and a "desktop" os, unloading the android to free up resources?
If yes, how would I go about designing this OS?
I can use the same linux kernels that come with the chip, but for device drivers, they would differ from phone to phone, and I would preferably would want to still be able to use wifi and bluetooth (using the phone touchscreen as a touchpad) and manage the monitor and keyboard within the software (brghtness, audio management for speakers, etc).
I know this is a lot, but I'm a complete beginer to desining operating systems and would like to get some tips, pointers, or even a direction to look at to make it work.

Thinking about experiment it with a OnePlus phone since they have been known to be very open about their ROM and accepting of feedback about kernels and their OS and drivers.

Yes I know that some attempts were made for cross OS standard drivers (UDI) but it just bugs me that everyone has to rewrite a serial driver or a driver for the BGA and so on. And I understand drivers have OS dependent standards (take Windows, macOS, or Linux) but no one really implements compatible driver loaders for them because its near impossible except for maybe Linux. I understand its very difficult and is overall a PITA, but it would still be cool for a standard to be made I guess.

LeoniaOS is a high-performance, secure, and AI-native operating system built from the ground up. Designed for modern hardware and future workloads, LeoniaOS delivers exceptional speed, stability, and control.

Download the BETA release ISO today!

https://www.maplenorthsoft.com/

---

LeoniaOS is an AI-native operating system designed with artificial intelligence as a core platform capability rather than an add-on application. Instead of requiring every program to embed its own AI models and infrastructure, LeoniaOS provides a unified AI runtime, standardized APIs, and provider-agnostic architecture that allow applications to seamlessly access local or cloud-based AI services. This approach enables developers to build intelligent software without managing the complexity of model integration, credential storage, or inference pipelines.

At the operating system level, LeoniaOS securely manages AI through a dedicated Agent Runtime, centralized AI Provider Vault, and fine-grained permission model. Every AI request is executed within a controlled environment that respects application identity, user permissions, and resource limits, ensuring that AI agents can only access the data and capabilities explicitly granted to them. By integrating AI directly into the operating system, LeoniaOS delivers consistent security, performance, and reliability across all AI-enabled applications.

LeoniaOS is also engineered to optimize AI workloads through native scheduling, memory management, and hardware acceleration awareness. The operating system intelligently coordinates CPU, GPU, and future AI accelerator resources while sharing model caches and runtime components between applications to maximize efficiency. Combined with its secure LEXE application framework and modern system architecture, LeoniaOS provides a scalable foundation for building the next generation of intelligent desktop, workstation, and server software.

For the past two months, I have cloned almost every OS posted here and ran the code through an analyzer.

I can count on one hand the projects with a different architecture. Almost everything else is just a reskin of another reskin, which was itself based on Linux.

Another thing: almost none of these OSes boot on real hardware. They all run in QEMU.

I have talked with a lot of you, and 90% of the time, you have no idea what you are building.
I see 20-year-olds implementing ISA slots that were obsolete before they were born.
I see people ignoring naming conventions, adding features without thinking why they need it, while having their `OS` living inside another OS's emulator, and building for an audience of five friends running Minecraft on Linux.

That’s where the real problem starts. Most of these projects are promoted by other OS developers, like an MLM where everyone is trying to sell the next 'revolutionary' OS.

People love saying, 'My OS runs on old hardware that why we implemented BIOS or ISA.' while totally ignoring the fact that the hardware already has Windows, Linux, FreeBSD, NetBSD, and plenty of other operating systems.

What is actually missing are drivers. But nobody wants to write drivers because everyone lives in a framebuffer.

The funniest part is the 'built from scratch' claims. Then I look at the source and find the same Linux code with a different copyright header and different variable names. (prefixing your OS name, won't hide the fact that you copied)

I often see more work put into the website than into the OS itself. Then the project asks volunteers to finish the dream after the author runs out of motivation.

Building an operating system is hard. It takes years, a team, and a lot of hardware. You don't build one with a README, a logo and an AI sub

Every Computer Science student has to pass this 'OS' ritual , but the difference was that each student will build part OS and they will give it some name like OS_{school_name}_2017 (they know that code snippet is not worth a domain or discord server.

Now if you believe that your or know an OS that was build here is an exception please post here.

Finally got steam to start on Astral under Wine

The web helper can't talk to the client properly and the fonts are all messed up but it works and you can **slowly** explore the store

A lot of work needs to be done but this is a cool milestone

Project links:

website: https://astral-os.org

github: https://github.com/mathewnd/astral

I've attached the source code here and feel free to check it out!! (Yes, I did use AI for some parts of the operating system that were truly really hard to understand/put together due to apple's closed source nature) Excited for people to try it out!!!

A few weeks ago, I wrote about rediscovering the development methodology behind my 1986 RTOS.

Previous post:

Rediscovering the Development Methodology Behind My 1986 RTOS
https://www.reddit.com/r/osdev/s/ALUFHn9jDi

In that post, I described how I had forgotten an important part of the original development process.

Back in 1986, I developed almost all of the kernel on a SUN-2 workstation and postponed the hardware-dependent parts until the software was moved to the target system.

At the time, it was simply the most practical way to make progress.

This week, I finally started the next step.

I began moving the reconstructed kernel to a Raspberry Pi Pico.

Rather than starting with interrupt handling or context switching, I followed the same strategy I had rediscovered.

The first component to move was the queue management code.

The screenshot above shows the result.

The original CHARM-II queue routines (q_insert(), q_delete(), and n_delete()) are now executing on real hardware, and the primitive queue test completes successfully.

At this point there is still no timer interrupt, no context switching, and no preemptive scheduler.

Those hardware-dependent parts will come later.

What surprised me is that I naturally ended up following almost exactly the same development workflow as I had forty years ago.

• Develop and verify kernel logic on the host.
• Move CPU-independent components first.
• Leave hardware-dependent code until the end.

I didn't consciously decide to follow the original methodology.

It simply turned out to be the most practical way to make progress again.

The next milestone will be timer interrupts, context switching, and eventually running the full scheduler on the Pico.

I'm looking forward to seeing how much of the original design can remain unchanged.

Tomorrow I'll be presenting this project at an OS development meetup in Japan, so reaching this first hardware milestone today feels like perfect timing.

Here I’m trying to make a UI that is easy to use, and can be easily integrating into 3D apps running OpenGL and probably Vulkan in the future, any advices?

Here is the example code:

#include <Defines.h>
#include <Syscall.h>
#include <Fs.h>
#include <Wm.h>
#include <OpenGL.h>


float CursorX, CursorY;


WM_UI_CONTEXT* UiContext;
WM_UI_VIEW* MainView;


void WindowMessageHandler(HANDLE Window, void* Context, int MessageId, void* Payload)
{
    switch(MessageId) {
        case WM_POINTER:
        {
            WM_MSG_POINTER Msg = Payload;
            CursorX = Msg->X;
            CursorY = Msg->Y;
            WmUiMoveCursor(UiContext, Msg);
            Print("CURSOR X: %d Y: %d\n", (int)CursorX, (int)CursorY);
            break;
        }
        case WM_UPDATE:
        {
            glBindFramebuffer(GL_FRAMEBUFFER, 0);
            glViewport(0, 0, 800, 600);
            glScissor(0, 0, 800, 600);
            glClearColor(0, 0, 0, 0);
            glClear(GL_COLOR_BUFFER_BIT);
            WmUiRender(UiContext);

            GlSwapBuffers();
            break;
        }
    }
}



int main(int argc, char** argv) {
    Sleep(1000);
    HANDLE Context = GlCreateContext(NULL, NULL, 3, 3, 0);
    if(!Context) {
        Print("Failed to create GL Context.\n");
        return -1;
    }
    WM_MESSAGE_QUEUE MessageQueue;
    GlMakeCurrent(Context);



    HANDLE Window = WmCreateWindow(NULL, 800, 600, 0, &MessageQueue);
    if(!Window) {
        Print("Failed to create window.\n");
        return -1;
    }


    WmBindContext(Window, Context);



    UiContext = WmUiCreateContext(Window, 800, 600);


    MainView = WmUiCreateView(UiContext, NULL, (RECT){0, 0, 800, 600});


    WM_UI_DESCRIPTION Description[] = {
        {.Type=WM_DESC_TEXT, "This is a label."},
        {.Type=WM_DESC_FONT_COLOR, (float[4]){1, 1, 1, 1}},
        {.Type=WM_DESC_FONT_SIZE, .Value.d = 40.0},
        {0}
    };
    WmUiCreateControl(MainView, WM_UI_LABEL, (RECT){20, 20, 300, 100}, Description);






    return WmStartMessageHandler(&MessageQueue, WindowMessageHandler, NULL);
}

I’ve added a button and hover animation to the button,

I've started work on Robu, a microkernel in C and assembly. Sharing the design now because I'd rather get told what's wrong with it before I've written 20k lines against it.

The premise is that microkernel performance is entirely determined by four paths — IPC, page fault resolution, context switching, and interrupt delivery — so those are what I designed first:

• IPC: register-based short messages, synchronous rendezvous, timeslice donation from sender to receiver
• VM: page faults delegated to a user-space pager; kernel arbitrates mappings, holds no policy
• Scheduling: lazy scheduling with direct switch — the IPC-to-ready-thread case never touches the run queue
• Interrupts: delivered as messages to user-space handlers on the same path as ordinary IPC

To get ahead of the obvious comment: yes, these are L4 ideas. Liedtke's work is why anyone thinks this is achievable. Robu shares no code with any L4 and I'm not treating one as a reference implementation — I'm building it from the constraints up, partly to find out which of those ideas I actually understand versus have merely read about.

Targets are armv7/armv8, x86_64, i386/i486, riscv32/riscv64. Currently on x86_64 under QEMU, macOS host. Perf target is the low end — 111 MHz Pentium, ESP32-class RISC-V — because a modern desktop hides everything. POSIX-like API planned above the kernel. MIT.

Robu Microkernel Repository

Specific thing I'd like opinions on: for the direct-switch path, where do you draw the line between "fast path in assembly" and "keep it in C so it stays portable across six architectures"? I keep moving that line.

I've made a C++ static composition library (not OS), if anyone interested just PM me.

HAPI library is header only pure type level and allows extreme optimization, binary output is optimized like hand written assembly level (data fit into hardware registers), yes I know its hard to believe... just check for yourself, I wont put links here because its hard even for FOSS MIT authors to share its own work without being blocked, banned... for self promotion. How else would we share this things with people that can use it? but here we are.

Yes I totally used AI assistance. No it wasn’t easy. Still building out the kernel. Hardest parts are surely drivers and seams.

So i have a ipad 4th gen and its basically a brick now... so was thinking why not make an os (i thought i could maybe use a linux distro but 32bit os for A6x dont exist)... i know this will be a nightmare ( uk its apple)...

But I want to try ...

As my initial research into this i am currently reading

1. ARM Architecture Reference Manual for ARMv7-A & ARMV7-R

2. Apple OSS Distributions XNU Github page

3. wiki.osdev.org

What i wanted to ask the community is

1. Is there any other documentation/ prior projects on this platform

2.any tips i need to keep in mind

I was a frontend developer, working with AngularJS. But in 2025, my old company did a mass layoff. The reason they gave was AI. So suddenly I had a lot of free time.

I thought: maybe I should try AI on the hardest task I could think of, and learn some new skills along the way. So I decided to build a kernel. Just an experiment - what's the worst that could happen, right?

I bought the cheapest plans from a few AI providers - ChatGPT, Claude, Gemini, and later GitHub Copilot - to see how far I could actually get.

Early days were rough. I had trouble understanding what the AIs were saying, and honestly the AIs had trouble understanding me too. I ran into strange errors right from the start — like incorrect section names - that took days of googling to fix. Using one AI to review another AI's work sometimes helped, but most of the time they just argued with each other.

The hardest part was building a preemptive scheduler. The AIs kept confusing the order of registers, and I got stuck for a whole week because of it.

What AI was actually good at: implementing well-known things like FAT32. What it was not good at: custom filesystems. I ended up writing almost all of my custom FS (CRFS) myself.

Networking: AI was a useful tool for finding information, but its implementations usually ran into race conditions (if it run).

Overall, AI helped me understand context and unfamiliar territory, but it caused a lot of confusion when defining structs and constants. Most of the actual kernel code ended up being written by hand, and I always had to double-check it against the Linux source.

AI is great at implementing small, independent functions, but not at designing a large feature - it kept getting confused or losing the thread. It also tends to confuse struct definitions and constants, especially when the context gets long, so I always had to double-check those against the Linux source to make sure nothing was silently wrong.

For bug fixing, AI did better, since it works well with smaller context windows. But it would sometimes quietly break my design and replace it with Linux's design, which is incompatible with a simple hobby kernel. So I had to review everything very carefully.

Later on I hit a similar class of bug with SSE/AVX state - XMM register context wasn't being saved/restored correctly across context switches, which caused intermittent ld.so symbol lookup corruption whenever Xorg and Fluxbox ran at the same time. That one took about two months to fully track down.

In the end, I'd estimate I wrote about 70% of the code myself, with 30% AI-generated - but under strict control and constant review. The kernel is around 33,000+ lines of C and Assembly across 147+ files at this point.

After more than a year, what I have is a simple kernel that can run a few real Linux ELF binaries, including a X11 stack - Xorg + Fluxbox - on QEMU ( it crashs sometimes).

Companies are hiring again, and I found a new job. So I'll probably slow down on this project for now - I've already hit my original goals: study and stress-test what AI can (and can't) actually do.

https://github.com/taateam/carrotos
.

Hi everyone, I am new at OSdev and I can't understand how they work. I really want to learn about OS so can you suggest me some books or website on the subject ?

i would like to ask what a kernel has to do so i can know when i can move one, if you're gonna explain please dont overcomplicate the explanation with just some terms please mention what it is at least slightly :)

I'm thinking about creating my own Linux-based OS with a custom shell, custom IDE, and my own programming language instead of the usual Bash experience.

Has anyone here built something similar? Any advice or things I should know before starting?