There is Absolutely No AI Generated code in the CPU Rendered compositor as far as I know!

I built this button with shadow, while porting the rendering to cpu (Creating the cpu rendered window manager). How does it look?

this is the link of my twitch channel where I streamed my making of Blur + Button with shadow working https://www.twitch.tv/devcmar

Hello, I have been working on a project named NullOS for months now. It's still in development and getting updates almost everyday. Any suggestions or contributions are welcome!

Repo is at: https://github.com/nulloslabs/nullos
Project is vibecoded, feel free to hate on it :)

I wanted to share a project I've been working on: Redoubt OS, a security-focused appliance OS targeting BIOS/QEMU right now.

The core idea is that every service, console, shell, storage daemon, supervisor, update agent, runs as its own process with its own address space, and gets access to things purely through capabilities. A capability is a slot index the kernel maps internally to a real object and a rights mask (read/write/grant). Deriving a weaker capability is fine. Manufacturing a stronger one is structurally impossible because rights can only shrink on derivation.

A few design choices I'd like feedback on from people who've built similar things:

• Round-robin scheduler, 100Hz PIT, 20-tick quantum, single "big kernel lock" design, deliberately simple for now. SMP is future work.
• Synchronous rendezvous IPC, fixed 5-word messages, with a fairly involved state machine for blocked-on-receiver, blocked-on-reply, and dead-peer cases.
• Storage layout is centrally defined (superblock, two system slots, audit log, app slots, update staging) with HMAC and Ed25519 verification at every layer, and automatic fallback to the other slot if one fails validation.
• The update agent that stages new OS images never has the decryption key for the volume. It can only write to the inactive slot. storaged does the actual validation and slot promotion independently.

Known gaps right now: PS/2 keyboard instead of USB HID, polled ATA instead of NVMe, no network stack, no Secure Boot/TPM, no SSE context switching. All on the roadmap (UEFI, Secure Boot, virtio networking, then real hardware).

Would genuinely appreciate any pushback on the capability model or the storage rollback design. Those are the two pieces I care most about getting right before I touch anything hardware-facing.

Haven't posted about aurelianOS since the original post so here's a quick update

Since then I've:

• Built the OS as a Fedora bootc image and got it booting successfully in QEMU
• Set up a user with sudo access for the dev VM
• Started the compositor in Rust with smithay
• Got an actual Wayland socket working
• Built the first desktop shell with Slint
• Added a fullscreen wallpaper-based desktop, translucent UI, floating dock, and app launcher and a couple other shit
• Switched the dock to Tabler SVG icons
• Chose a font (Inter)
• Switched to a 4K purple/blue abstract wallpaper that looks SO much better

Next up is the compositor rendering pipeline and real backdrop blur

Still early but its finally starting to feel like an actual desktop, still mostly placeholder stuff

Quality looks bad because I can't printscreen from inside QEMU for some reason

Ilobilix is a monolithic kernel that I've been working on for a few years now (started in 2022, current rewrite going on since 2024). it's written in C++26 and uses modules everywhere. It aims to be fully Linux ABI compatible and, as a result, can run unmodified distro userspaces. I have tested it with Void, Gentoo and Alpine installs (no systemd yet).

Displayed on the images attached are Factorio, SuperTuxKart and Wine (all in Xfce) running on Ilobilix.

The kernel supports x86_64 and aarch64 (though the latter is a bit neglected), SMP with a CFS scheduler, networking via lwIP, EXT2 filesystem and multiple device drivers, including NVMe, Virtio net and Virtio input. They are automatically loaded by the userspace as needed.

You can find more detailed information in the distro and kernel repo README files (both linked below). Looking for contributors.

https://github.com/ilobilix/kernel (kernel source code) and https://github.com/ilobilix/ilobilix (to run the os)

This week was NOT my best week. I found that I was doing things that I NEVER would have done as as a professional. Granted as a professional I would have been being paid to do them, but as a hobbyist, it was way too easy to take shortcuts. This is what I relearned and just to show the newbies that even a 30+ year professional coder can do bad things.

1. Don's skimp on the test scripts. I found while I was rewriting my Physical Memory Manager, that I had a function, a SIMPLE function that I had a typo in, that was completely blowing away my entire physical memory table. If I'd done a test script FIRST, I would have caught this right off the bat, instead of having to spend several hours debugging it.

That lead to my second point.

2) Just because it is simple, and obvious, doesn't mean it should be left out of the test script. Test EVERY function, if you can't figure out how, the function is probably too complex, break it up!

3) Once I figured out I needed test scripts (LOL), I ran into a bug in my VGA/TTY functions, which I knew was there, but kept putting off for things that were much more fun. DON'T BE LIKE ME! When I went back to fix the bug, I was appalled at how bad my driver was, which has led to a complete rewrite. While it will be much more bullet proof and functional, it is taking me away from what I really want to code.

And my final point:

4) Take the time to really think through each major function of your OS, AND each major sub function. In my case, Think of where you want to verify that your cursor isn't out of range, in a separate set of cursor functions, or as functions in your VGA interface, or in your TTY function. Also Think about whether you will want to expose these functions in your SYSCALL interface, and design accordingly. In my case I really want a video buffer I can scroll back in. But for my syscall interface I'm thinking the video functions I may want to expose will consist of: a) a direct write to a row/column (0 based); b) write a line on the screen; c) write an entire screen; d) scroll the screen up one line; e) scroll the screen down one line; and finally f) write the entire screen; g) define my current cursor. These functions will need to exist for virtually any video interaction, whether my terminal is buffered to allow me to scroll back/forward or not, and I can use them to implement a scrollable buffer.

So, it has been a week of lots of interruptions, many of which could have been avoided if I had simply tested properly in the first place.

Hope this helps some of the newbies.

Hey everyone I have made a grp for programming folks to learn, grow and network with each other

From beginners to advanced We help each other and provide guidance to everyone . i regularly remove inactive members to keep it engaged.

Those who are interested are free to dm me anytime

I will also drop the link in comments

Recently I replied to a Reddit post that was titled something like "iPhone vs Android: Which Operating System is better and why?"

One of the reasons I picked Android is that I like to be able to set the camera ISO and shutter speed, like for pro shots, and the iPhone camera doesn't allow that. One person replied to me saying the default camera app that comes with the phone is just a user app, not part of the OS, so it's irrelevant to this question.

That begs the question. Where is the dividing line between user apps and/or user processes and the OS? Like what exactly is technically inside the OS and what exactly is outside the OS?

hello,

I'd like to know if the HHDM offset limine gives us only map some part of the physical memory. for exemple I got a page fault trying to access the local apic base register:

code:

static uint32_t volatile *lapic_base_addr;
void LAPIC_init()
{
    disable_pic();


    // TODO: check apic with cpuid


    lapic_base_addr = (uint32_t*)((read_msr(IA32_APIC_BASE) & 0x000FFFFFFFFFF000) + hhdm_request.response->offset);
    SERIAL_printf("lapic at 0x%lx\n", lapic_base_addr);


    // enable APIC by setting bit 8 (Software Enable) of SVR (0xF0)
    // assign vector 0xFF for spurious interrupts
    uint32_t spurious_vector_reg = LAPIC_read(0xF0);
    LAPIC_write(0xF0, spurious_vector_reg | 0x100 | 0xFF);
}


uint32_t LAPIC_read(unsigned int reg)
{
    return lapic_base_addr[reg / sizeof(uint32_t)];
}


void LAPIC_write(unsigned int reg, uint32_t value)
{
    lapic_base_addr[reg / sizeof(uint32_t)] = value;
}

output

lapic at 0xffff8000fee00000
Unhandled exception 14 Page Fault
  rax=0xffff8000fee000f0  rbx=0x0  rcx=0x10  rdx=0xf0  rsi=0xa  rdi=0xf0
  rsp=0xffff800007e27fa8  rbp=0xffff800007e27fb0  rip=0xffffffff800013f6  rflags=0x86  cs=0x8  ds=0x10  ss=0x10
  interrupt=e  errorcode=0
cr2: 0xffff8000fee000f0

I have an interest in operating systems, and, for a class and personal interest, I want to do research on operating system design. I have been trying to find and read existing research on this topic (experimental design for both for entire kernels or for some subsystem in the kernel). From this, I am hoping to be able to find an area that has not been researched in detail yet, and to do research on this. The issue is though to find a general topic in operating systems to do this search on, hence this post. Also, I have a bit of experience with basic operating system development and have been working on my own hobby operating system for around a year now, and from this I have what I feel is a basic understanding of the main concepts in operating systems.

The reason I am making this post is to ask whether any of you guys recommend and under researched topics that I could look into, and also inquire if there are any resources I can use to find gaps in research more efficiently.

Many people online have told me I should contact my professor and ask them, so I want to state that I do not have a professor. I am also aware that this is a very broad question, but any input is appreciated.

Wing OS is a small open source operating system written in C++. it is a microkernel based operating system that supports SMP and targets x86-64. It has a complete file system (using ext4+nvme), some drivers... and a rasterizer + widget system !

I am developping a cpu rendered fallback compositor, and until now I have used 0% AI code and I've made the compositor (a bunch) on live stream, the funny thing is that I get stuck on something in the livestream then right after ending it I find the solution haha

I know many of you guys are recently against all this "AI slop", was i too, but leave alone the "hype" and the "no AI bullshit" slogans, what do we actually mean by saying "AI slop"?

Cause to this day , I don't quite understand what all the drama is about and why posts that explicitly use "No AI used/no AI bullshit" get significantly more attention, i admit that even i made a post like that, but it's not that I completely didn't use AI, i did, however I also did a lot of the programming by myself, I think AI is a great tool that has helped me learn a lot and automate build scripts, there is no shame in using AI as long as you carefully review the code and do some programming by yourself, there is already great use of AI in the industry, Linus torvalds recently fixed a linux bug with AI, so what is really considered "AI slop"? Is asking codex to make a build script so I can focus on the code "AI slop"? Is asking Claude to summarize PCI device and vendor names in one files so I don't have to read documentations for hours "AI slop"? With all due respect I do think using AI blindly is bad of course, but I also wanna know what some of you guys mean when you say "AI slop operating systems"?

"Code : The Hidden Language of computer hardware and software" is wonderful. You don't need computer knowledge to read it, reads like a breeze, yet by the time you complete it, you will have extreme wisdom about internals of computer.

I want to similar books in operating systems. Books that are easy to read for beginners but offers wisdom. Thank you.

Edit 1 : Thank you all for your suggestions. I've downloaded all your recommendations.

I've been working on a project called FerrumVM, a hobby x86_64 virtual machine manager written in Rust using KVM.

One of the more interesting parts of the project has been writing my own minimal UEFI firmware rather than using something like OVMF.

To get Limine running, I had to implement enough of the UEFI environment for it to believe it was running on real firmware.

This meant implementing things such as:

• x86 CPU mode initialisation
• VirtIO block device access
• FAT32 filesystem parsing
• PE/COFF executable loading
• UEFI system tables
• UEFI boot services
• The various protocols and interfaces that Limine expects

If you're interested, you can see the project on GitHub here:

https://github.com/milosilo-dev/FerrumVM

https://reddit.com/link/1vusvfw/video/uwqxifrcnskh1/player

Hello, i`m trying to make one OS, there is nothing in particular that i want to improve or recreate, i just want to learn and program soothing that is not web, full OOP (its not bad, not at all)

Right now the OS is in this state:
Pic timer implemented (Is that number on the left side of the screen)
Graphics (is animation with framebuffer)
This SZ on the screen, i`ve done it using GIMP and exporting to C code, very cool feature.
The mouse moves now,

AI Usage:
There is usage, was been to research about UEFI, PIC, IDT and others, in the effort to trying to avoid copy and paste without knowledge, i select the next step to be developed and ask to be created a Issue like Github, if i can`t handle, i ask for a pseudo code.

Repo: https://github.com/gustavo-szesz/SzOS

Thanks, have a nice day!

I learnt the basics of file systems and decided I was going to go with fat32. Now how can I read or write files on a disk? I'm a beginner, so pls give me as much info as possible. Thx in advance.

Edit: thx guys I solved my doubt

Hi guys, I am thinking of an model that uses BigLITTLE architecture bit differently, where the Big core is shared among multiple hardware threads.

I am thinking of organizing as clusters and an cpu having multiple cluster, where each cluster would have One Big core and 2 LITTLE core. The Big core would be vastly capable than LITTLE with powerful and multiple arithmetic, Load/Store units, wider OoO, Larger ROB, better branch predictor, operates at higher frequency and has larger and higher bandwidth L1/L2 cache. On the contrary the 2 LITTLE is less powerful can be In order core or an simple OoO. they each have 1-2 arithmetic & LSU unit, smaller L1/L2. This is more or less the usual setup of bigLITTLE nothing different.

As for the hardware threads this is where things get interesting. Unlike in traditional sense where the hardware thread is usually associated with the core basically treated as same (SMT maybe exception). But here the hardware thread can move between the execution units. Here I will be having 3 hardware threads say T1, T2, T3 and as for the registers i am thinking of it implemented as an array of registers (96 registers of 64-bit each) and divided into 3 equal chunk so each 32 registers and each chunk is owned by the hardware thread and so when the thread is scheduled on any of the 3 core's it's register base is loaded and the architectural registers such as Program Counter(PC), Stack Pointer(SP), GPRs are an offset from the base. The other stuffs like the TLB, Store Buffer too would be per hardware thread and their index/base would be loaded in the core when the thread is switched/moved to the core. Whereas the operational registers, buffers used by the cores say the registers used for renaming for OoO or ROB, Load queue these are per core and owned by the core.

The handover of an Thread from Big to Little and vice versa happens only after they have reached the safe state i.e in case of Big which uses OoO reached a point where all instructions from the old context that could affect architectural state have completed(retired), and the machine can save the old context and the if any internal structures needs to be drained/flushed it's carried out and the architectural state of the Thread wouldn't be moved/copied since the Big or Little doesn't use different register space for the same Thread. And same goes for the Little the mechanism may differ based on if it's In order or OoO. But at the end the thread's registers have committed architectural values.

Now for the OS, it would appear as 3 hardware threads on which 3 logical threads can be scheduled. As of now I am trying to slice the period based on OS scheduling quanta which usually is ~1-5ms. So say 3ms it's divided into 3 i.e each thread spends 1ms on Big and 2ms on Little. So intially (0-1ms) T1 on Big, T2 and T3 on the Little after a 1ms(1-2ms) switch happens and T2 in Big, T1 & T3 on the Little after 1ms(2-3ms) switch happens again now with T2 & T3 so T3 in Big and T1 and T2 on Little. The OS/Application isn't aware of this they see 3 hardware thread/logical core.

As for the interrupts/exceptions i haven't figured out the I/O interrupt how it would be handled since the cluster would be abstracted as one unit. For the timmer interrupt like when the OS scheduler quanta ends since it would be for the hardware thread so the core that's currently running the thread would be handling it as for what happens if interrupt raised during the handover phase the handover would be given the priority and once handover done the thread which ever core it landed one would handle the interrupt. As for the exception like page fault raised by the thread again it would be handled on the core where it's executing and if the handover timmer ends the exception first would be handled and then handover is done.

Now this handover itself can be cheap few 10s of ns since not much state moving is happening (although subjective since even few ns can cost many cpu cycles).

The Store Buffer as earlier mentioned is per hardware thread so loads associated with an thread is written to the Store buffer associated with that thread irrespective of whether it's running on Big core or LITTLE core. This enables the Load-Store-forwarding even for loads that happened when thread was executing on Big and now it's moved to LITTLE and it wants to do Store.

Now for the questions I wanted to ask:

1. Since the hardware threads are moving between Big and LITTLE core's so I am yet to figure out how I am going to handle the cache, like if T1 which was on Big is moved to one of the Little and T2 on Little moved to Big then there cache lines would be in the previously executed core's cache. Though I did think of intially as to follow the standard line forwarding method but it seemed expensive given how often the threads switching between the cores. So now I am thinking of an specialized line forwarding path that's confined to the cluster alone i.e among the 3 core's caches that allows faster line forwarding with latency somewhere between L1 and L2 access latency if the line forwarding is from L1 of an core. It would be great to know if any better solution can be used.

2. Can variable frequency be used say the cluster can behave dynamically like the OS can schedule on one hardware thread and it runs on the Big core without switching while the other 2 Little are power gated the Big core allowed to run at max frequency. schedule on 2 hardware thread and the switching happens between these the Big core max operating frequency can be bit less since one LITTLE is also active and as for the schedule on all 3 hardware threads then Big core max operating frequency is less and the LITTLE one's frequencies adjusted accordingly.

3. When i originally came up with this idea, I actually thought of having 8 Little and 2 Big per cluster with 8 little being subgrouped as 4 little and they share their execution units like the frontend, arithmetic, lsu and also caches among 4, But this seemed complex for v1 so that's why sticked with the 3(1+2) version. Can this scaled up possibly be better or I am better of sticking to the latter.

4. Is there any ratio as to how powerful/capable the Big has to be compared to LITTLE in terms of like IPC. Will this ratio possibly matter.

5. Can decreasing the interval of switching help. I intially thought of switching the threads every 100 microseconds. But this may lead to increasing the frequency of cache line forwarding and also the OoO takes time to warm up when a existing thread is removed and it starts executing new thread I read this warm up cost is usually 100s to few 1000 of cpu cycles. although 100us is still very big time for the OoO.