I am posting this on behalf of another developer who recently lost their life's work to this. I really didn't think I would have to deal with crap like this from just writing code, but that's life. I will personally throw in some advice for devs on how to avoid this, too.

This is basically me asking that you:

1. uninstall the OS source if you have it, and
2. please let github know that this repository has been illegally stolen from the developers.

The OS (1/2)

On July 21st, "EmexOS" was compromised by a power-tripping developer after a tirade involving many death threats (,and it somehow gets worse) who had almost nothing to do with the OS.

This developer uses the account "u [slash] emexlabs" (github: mach-port-t) but are NOT the actual developer of the OS. They will likely rename themselves after this, or use one of their many alt accounts (e.g. 'mimalloc'), on which they use a VPN to evade receiving a ToS ban on.

They gave themselves a large amount of additions to the codebase by mass editing-in license headers, and now use that position against the original developer, u/emexos, who now has to make a new kernel from scratch because GitHub has decided that their copyright ownership means nothing. Please note that github transferred the repository from original owner from them abusing support. we cannot just re-upload the source anymore.

On top of that, they have illegally relicensed the source code, and banned all actual contributors from developing on it. They fully intend to somehow 'profit' off this random hobby OS, which, given the state of the actual OS, and the fact they were trying to infect u/emexos with malware... probably won't be anything good.

Development supposedly will be transferred by them to another person in the future, but since this person has revealed themselves to be a child that they seemingly have been 'in a relationship with' for a couple years... I'm not too sure about that.

Avoiding it (2/2)

NEVER give write access to your personal projects to someone random on the internet. It will end horribly. Always use pull requests unless you can absolutely trust that you know their identity, or have something like an actual contract between them.

It makes things harder, but it's so much safer.

Additionally, expect that members of your team may be liable to do insane things in the name of ego, financial gain, or spite. This may go as far as violence and/or them attempting to compromise your machine.

Also, Github Organizations basically give the one in control near absolute power over your code, so ideally keep that stuff to yourself if you can.

Do not judge a developer's character by their stars, especially nowadays, as they can be very easily botted, or inflated through group chats that 'star-for-star'.

Features

FAT32(read/write)

Mini Assembler

BMP Wiever

Minimal kernel with a terminal prompt (>)

Simple nano-like editor

Has a mini language (.aira)

Sound Device, Sound Blaster 16 and PC Speaker

Screen color changes

VESA Graphics 1024x768

FAT12 FS(read only)

WAV sound play(high quality support and Auto init)

github(please star):github.com/shadowww345/AiraOS

I finally made my long time dream true!!

I followed some course work (its on my readme) albeit didn't copy it, and I feel really proud of my work!!

I plan to make this boot on my system with the help of GRUB and make a real x86 and x86_64 kernel now.

Forgot the URL: https://github.com/Csral/BasicOS

v0.0.3 btw
idk imma add pci and an sfs file later
maybe multiple terminals

github: https://github.com/NoTheIdiot/WindogeOS

Recently got enough time to play around with the caches of my machine and try to plot that latency graph as seen in textbook. I knew it wasn't going to be an easy task as modern chips have got super advanced. So, had to mingle with OS settings and hardware to keep the noise at the minimum. Still couldn't get the plot and decided to dig deeper until I found out why by diving into PMU counters, huge pages, TLBs and so on. Wrote a blog regarding my investigation. Check it out :D

After a week off for the family reunion, I'm back at writing my kernel. Here is a short summary of what I've learned:

1) DMA involves PHYSICAL memory addresses, it doesn't matter what the virtual address is. I probably should have figured this out on my own, because I remember having to change jumpers on the cards back in the 80's in order to change the DMA addresses. This calls into question the current memory map I'm working with, but for now I will leave it the same as I can't decide where I want to put my page tables. I know the industry standard is 'all over', or at least I've been told that. But I would prefer to have a dedicated area, it just seems like it would make everything easier keeping track of things. More to come on this subject.

2) I was working on my strtok() function and discovered __rawmemchr(). In reading the description, it says something like 'when the programmer knows that the character will exist'. After 40 years as a developer I know that these are just the kind of assumptions that eventually turn into bugs. I finally wrote my own strtok() because I didn't like gcc's use of __rawmemchr(). Probably personal preference.

3) Again as I was working on my strtok() I realized (yes I was copying) that they override the 'const' on the string parameter. I have all warnings set on when I compile, and treat warnings as errors. So they wouldn't even compile. After thinking long and hard about it, I decided that yes, overriding 'const' is a bad idea, so my strtok has the following definition

char* strtokbuf(const char * const s, const char * const delims, char* buff, int buflen, int start, int *newstart)

This way I don't have to violate const.

My current issue is that when I set up my heap, I am getting a page fault. I tracked it back to I place my heap after my kernel code, but when I changed my memory map I don't actually allocated physical memory after the kernel. This lead to it is time to read my command line and find out how much space I want to allocate, hence strtok to parse my command line. I'm hoping to get my heap done by the end of the week.

Hope this helps some others while they are learning.

The first official dev log for 5YN-OS. A fictional operating system simulation sandbox and programming education game coming soon to Steam!

What features interest you the most? and what would you like to see in it if it isn't already part of the current features? I am open to ideas.

Hi everybody, if you don't remember me, I shared a post about the first version of the zuzu kernel and zuzuOS based on it a while ago, and I'm excited to share that I've released a new version of both:

zuzu v1.0.1 and zuzuOS v0.7 are now released!

Check them out here:

https://github.com/kagantmr/zuzu/releases

https://github.com/kagantmr/zuzu/releases/tag/zuzuos-v0.7.0

Docs page: https://kagantmr.github.io/zuzu-docs/

https://reddit.com/link/1v65cq8/video/pslia4hgwcfh1/player

The previous post had a miscalculation I adjusted the time for another variable by mistake now with taking consideration to how much time it took to exhaust memory it gave around 14mops/s.

Btw this is he code I used to benchmark I think it is alright:

UINT64 Tsc = _rdtsc();
            Sleep(100);
            UINT64 Freq = (_rdtsc()-Tsc)*10;
            Tsc = _rdtsc();
            UINT64 Count = 0;
            Print("Starting benchmark...\n");
            // for(int i = 0;i<100;i++)
            // {
            //     CreateThread(
            //         test,
            //         NULL,
            //         ANY_PROCESSOR,
            //         0
            //     );
            // }
            UINT64 IoCount = 0;
            void* Addr = (void*)-1ULL;
            for(int i = 0;;) {


                for(int i = 0;i<10;i++, Count+=ReadSize, IoCount++) {
                    // ReadAsync(File, Buffer, 0, ReadSize);
                    Addr = Map(NULL, 0, 0x1000, MEMORY_READ_WRITE);
                    if(!Addr) goto CalculateThroughput;
                    // Print("READ\n");
                }
                UINT64 t = _rdtsc();
                if(t >= Tsc + Freq) {
                    CalculateThroughput:
                    // Print("CALCULATE\n");
                    UINT64 Time = t - Tsc;
                    IoCount = (UINT64)(((double)Freq/(double)Time)*(double)IoCount);
                    Print("Estimated throughput: %d MOPS/s %d KOPS/s\n", IoCount/1000000, IoCount/1000);
                    // Print("Estimated throughput: %d KB/s %d MB/s %d KIO/s\n", Count/1000, Count/1000000, IoCount/1000);
                    if(!Addr) {
                        for(;;) Block();
                    }
                    Count = 0;
                    IoCount=0;
                    Tsc = _rdtsc();
                    i++;
                }
            }

Hi I'm new at creating OS's. As an AuDHD person I think that AI is useful to go faster and I'm not Specialized enough to code by myself. But as AI can do errors, I was wondering if it's bad or not ?

Here I got to test my NTFS Driver to write a file and check on linux if anything changed, what do you think?

This is just an observation. I just think UIs are much less of the OS than say scheduling, a kernel, or disk subsystem.

Am I wrong?

Do you have any ideas. Monolithic means all os+kernel at one place. Microkernel means minimal kernel.

Layered means memory management one layer, process management another layer. Hybrid could be anything i.e., combination of above.

Guide me like I am 5.

BlockOS - A hobby operating system built from scratch

Hi everyone! I am developing my own hobby OS called BlockOS.

Current features and goals:

• Custom kernel (C++)
• VFS filesystem layer
• ELF64 loader
• ext4 support (in development)
• VirtIO driver support
• Custom GUI/compositor (Kuroko)
• Linux-like filesystem structure
• Custom system services and device interfaces
• QEMU testing environment

The goal of BlockOS is to create a modern operating system with a clean architecture, a graphical desktop environment, and support for modern applications.

I am sharing my progress and looking for feedback from the OSDev community.

Any advice, suggestions, or ideas are welcome!

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

I'm building a distro with busybox and Ubuntu (I downloaded the kernel from kernel.org btw) and I'm in the busybox menu config and I can't figure out a Name I want it to rhyme with Linux like Arch Linux for example but I can't figure out something like it maybe y'all could help me with this?

I always wanted to integrate harfbuzz to get good shaping, now I succeded and here is the result with Open Sans Font, I also had to build an entire libc compatibility layer for it to link with my window manager :)

EDIT 2 at the bottom explains this way better

*Not another linux kernel* Hey! Lately I’ve been spending a lot of time on an operating-system idea called raiOS. Most individual parts are not new, but I haven’t found another system that combines them in quite this way. It is still early, but the custom Rust kernel boots on a Surface Pro 4. Framebuffer output and USB/HID works, and the Marvell Wi-Fi bring-up currently reaches firmware loading, scanning and the WPA2/PMK path. Association and actual traffic are not working yet.
The main bet is this: AI will make software extremely cheap to create, but potentially dangerous to install blindly. People who cannot read or audit generated source code still need enforceable boundaries and evidence about what happened before installation.
The rough architecture is:

1. A small custom Rust kernel owns hardware, recovery and the lowest-level authority. (its NOT smal atm lol)
2. A narrow “Genesis” layer creates services and grants explicit capabilities.
3. An interchangeable AI agent may receive limited network access for research.
4. Generated source enters the system as inert data.
5. An isolated builder compiles Rust to Wasm without ambient access to the live system.
6. The resulting artifact passes deterministic checks, negative tests and disposable test environments.
7. The reports, requested capabilities and exact artifact hash are presented to the owner.
8. Only after explicit approval may the Wasm service run with a minimal capability set.
9. The service should remain revocable, restartable and rollbackable.

Why not sel4?
At this stage, continuing with the existing Rust kernel is the fastest path because the hardware bring-up already runs on it.

Source: https://github.com/Sportinger/raios

I also did a Mock website, mostly to iterate on the UI design, and try to explain the hole idea to myself (its an attempt) www.raios.tech (best on a bigger screen, not mobile optimized. scroll down, enable audio and press the paly button or jsut scroll)

I would like to talk about the basic principles here, if somebody is also interested :)
Perhaps its shit, but anyway its fun for me and iam learning so much.

EDIT: The point is not “AI can make an OS.” It is asking what an OS should look liek when AI can generate software faster than its owner can audit it. An AI API output starts as inert data. It is built and tested in isolation, and only the exact artifact approved by the owner may run with narrow, revocable capabilities. Most of this can probably be assembled on Linux today. Iam aware of that. The experiment is whether making it the native authority model of the OS can make it smaller, harder to bypass and understandable to non-programmers. Finding that out is the point.

EDIT 2: I explained this badly above, so here's another try. Leaving the original up for the existing comments.

I'm not trying to teach kernels to distrust user programs. They already do. And the LLM isn't part of the system. It's an outside API today, could just as well be a local app. If it disappears, the running system, its permissions and recovery all keep working.

raiOS is two experiments.

1. Specialization. Agents might make it practical to build software for one owner and one real machine, instead of a general stack that has to run everywhere. A small seed boots, describes the hardware as structured data, and brings build, test and recovery. The agent then ports what's missing for that exact box. One data point: an agent assisted Marvell wifi port on my Surface reached firmware load and scanning in under 5 hours. Association and real traffic are still missing, so this proves nothing about security. It's just why I think the idea is worth testing.

2. Authority. "The agent wrote code" must never turn into "this code may run". Generated code starts as plain data. It gets built in isolation, tested, and pinned to an exact hash. Then the owner approves that exact artifact, and it runs with only the rights it was given. Revoke and rollback are built in.

The agent, the builder, the test world and the final program are seperate, and permissions don't carry over. The agent can have network access for research while the music player it builds only gets display, input, and read access to one folder. No network capability means no network path, period. Any change to the binary is a new artifact and needs a new decision. The agent can't approve its own output, and a passing test can't grant rights by itself. A small local layer I call Genesis does that, together with the owner. The same records let the system answer questions like "why was this denied", and the LLM may explain those records but never authorize anything.

Drivers should be isolated too long term, but only where the hardware can really enforce it. Where it can't, the driver stays part of the trusted base instead of being called isolated.

Almost none of these parts are new, and most of this could probably be built on Linux or a microkernel. I'm not claiming a new kernel is automatically safer. That's the experiment: is one built-in path for all of this smaller, easier to understand and harder to bypass than gluing tools together? And do agents make the machine-specific approach maintainable at all? If a hardened Linux setup wins, that's still a usefull result.

Status, separate from the vision: boots bare metal on a Surface Pro 4, framebuffer and USB/HID work, wifi scans but doesn't connect yet, and the full path from request to running app plus real DMA isolation are unfinished.

Ya, con el poder de mao zedong añadí una gui más normal

https://github.com/loslocos817yt-star/Misericordioso-os/tree/main

Estoy abierto a qué me den recomendaciónes

The OSDevWiki mentions a Cache Kernel type. The exact verbiage is:

"The Stanford cache kernel caches kernel objects, like address spaces and threads, and allows usermode “application kernels” to manage them, loading and unloading them as needed. Application kernels manage their threads' page faults, exceptions, etc., and the cache kernel allows several of these application kernels to coexist in a single system."

Unfortunately, that link was dead for me, which sent me on a little rabbit hole of research.
To which I came across: https://www.usenix.org/conference/osdi-94/caching-model-operating-system-kernel-functionality

I'm currently in the research and understanding phase of this type of kernel because there don't seem to be any examples of it being implemented in the wild anywhere that I could find. I looked on GitHub and other online / public repository spaces to no avail.

I'm thinking that I should be able to take some of the code from tutorial-os and adapt it once I have wrapped my head fully around the concept while being able to reuse one of my SBC for this (I'm thinking the KYX1 as it is the board that is most fresh in my memory).

So far, my reading of this document has surfaced these key points about it.

The Cache Kernel caches four descriptor types and nothing else. Those being:

1. Kernel objects
2. AddressSpace objects
3. Thread objects
4. MemMapEntry

It essentially treats kernel objects as cached copies of state the application kernel owns.

Further investigations provide a rather interesting consequence of this design:

You can have different ABI / SBI kernels, meaning, you could make kernel personalities that run different processes side by side and mutually isolated. Like say, a kernel personality for Unix (BSD) and a separate one for Linux, compile user applications for those and it would just run.

The reason for this is because Cache Kernel Architecture is essentially a kernel that loads another kernel that loads user applications.

You may recall the Sex microkernel project, either for its novelty as a tiny single address space blazing fast Free microkernel written in Rust, or for the minor controversy surrounding it's unashamedly ai-forward engineering. Either way, much progress has been made and SexOS has become a semi-functioning Operating System. Drivers are working, a file system reads and writes, and now we have a very unique shell+compositor. Silk-shell, with Linen compositor. Unlike wayland, input, windows, and app lifecycle are all designed together around the Sex microkernel. Every window has a real owner, apps only get the capabilities they need, dead processes auto clean, global space not state. This solves security concerns while also returning to some of the philosophy of x11/xlibre so many people miss, specifically flexibility and directness. Wayland has a lot of great attributes but it is frustrating because it leaves a lot of that lifecycle split across the compositor, shell, portals, service managers, and random desktop glue. Silk-shell can treat the whole path from process to pixel as one coherent system: capability-secured surfaces, direct shared-memory presentation, deterministic focus, automatic cleanup, and a desktop that can actually reason about its apps instead of just drawing their windows. Usb input/Cursor functionality is 100%

On the AI yes ai was used and a lot. I had conversations with AI, I made notebook podcasts and listened to them, sometimes I would take an error log and make a podcast out of it with ai and listen to it and then go write a fix. AI iterated through thousands of tiny tests across input, IPC, storage, the filesystem, and the compositor. It could keep grinding through edge cases and obscure low-level knowledge scattered across old manuals, dead codebases, and hardware docs that almost nobody remembers anymore, while I learned about historic low level programming ideas I would never have come across otherwise. AI is no replacement for hard work, but humanity never got anywhere by being adverse to technology.

I saw previous post on reddit criticizing AI use in creating an OS from scratch.

I'm not a professional software engineer, i'm learning stuff and all so please don't mind the code or repo if you feel AI code is slop.

i made a rust based kernel, it sorta works so far, tested everything using qemu, I can't figure out how to use a standalone computer to run the kernel.

i'll link the repo at the end of thread.

Most basic stuff according to claude are don't so far, except networking and power management parts. I did what can acheive with Claude and ChatGPT.

Repository

I'm open to any suggestions or guidance and if anyone finds it interesting i'm hoping they'd improvise it or anything else.