This is my operating system I made. Please look over the single 50k line commit.

The code is github.com/claudeAIgeneratedOS

NO I DID NOT USE AI.

I'm developing a very simple Kernel with some goals, namely: being beginner-friendly and developer-friendly.

What’s already done:

• Bootloader: Limine for support of ready-made headers
  
• Basic video framebuffer support with some graphic tools
  
• Partial SMBios support, with Qemu tools to create a custom SMBios
  
• RAM support not complete: PMM working, VMM not working, raw RAM working
  

Future goals:

• Working RAM
  
• PCIE controls and GPU command
  
• Elf loader
  
• Scheduler
  

Please help me, I don't know what to do. If it helps, I use Arch with x86_64-elf-gcc compiled via yay.

Here’s GitHub: https://github.com/Alessio-Valluzzi/Trikernel

We built BareMetal OS - an exokernel with sub-millisecond cold boot and hardware level microVM isolation. We think it's small and fast enough to be genuinely interesting to build on. So we're running a 2-week challenge to find out what you can build. See attachment for contest details and rules.
Complimentary cloud credits for every applicant to help you build on our servers. Grand prize winner announced Sep 24, 2026. See link for details

I’m working on Kryon, an open-source execution layer intended to sit underneath terminals and developer tools.

The problem I’m exploring is slightly different from building a shell or terminal emulator:

How do you define a consistent process model across operating systems and programming languages?

Kryon currently implements the execution layer in five SDKs:

- Python

- TypeScript

- Dart

- Java

- Kotlin

The common model covers:

- spawning processes

- stdout/stderr streaming

- cancellation

- timeouts

- output limits

- termination

- lifecycle handling

- structured execution results

The five implementations are checked against one shared conformance corpus rather than having five independently evolving definitions of "correct."

The architecture deliberately separates:

1. Execution engine

2. PTY engine

3. Transport

4. Terminal emulator

5. Renderer

Only the execution engine is currently implemented.

PTY, ANSI/VT terminal emulation and transports such as WebSocket/SSH are specified for later phases.

One thing I’m being particularly careful about is not pretending this is a sandbox. Kryon executes commands with the privileges of the calling process. If hostile code needs isolation, the documentation explicitly recommends containers, VMs or unprivileged OS accounts.

The repository:

https://github.com/PIYUSH-MISHRA-00/kryon

Current 1.0 status: all five SDKs implement command execution and process streaming and pass the same conformance corpus on Linux, macOS and Windows.

I’d be interested in hearing from people who have implemented PTYs, terminal emulators or process supervisors: does this layer separation make sense, or would you structure the execution/PTY boundary differently?

This took so long to make.... And it is a html os like firefox os, and this is is based off of chromeOS, ubuntu touch, and Firefox os. I still have to fix the emoji problem on the keyboard. But overall the os works fine.

I’ve been working on RESENTMENT, an open-source experimental operating system built around the idea that AI agents should behave more like OS processes than unrestricted applications.

The project has both a from-scratch kernel and a browser-based desktop.

Some of the ideas I’m experimenting with:

Capability-based security — kernel capabilities and desktop agent permissions are explicitly granted

Expiring authority — permissions use time-bounded leases instead of permanent access

Agents as processes — agents have state, scopes, resource/token budgets and a kill mechanism

Auditable actions — tool calls become ledger entries and file changes record their causal operations

System as a hash — system state can be represented through Merkle/SHA-256 digests, with snapshot, diff and attestation

BYOK AI — API keys stay on the client; there is no RESENTMENT server

Multiple providers — including OpenAI-compatible endpoints and local runtimes such as Ollama, LM Studio, vLLM and llama.cpp

Architecture targets — x86_64, ARM64 and RISC-V

The kernel is written from scratch and currently boots with the OS ramdisk. The desktop communicates with it through a QEMU/serial bridge.

One important limitation: the desktop does not yet run inside the kernel. That is one of the major pieces still to be developed.

The four principles I'm trying to carry consistently from the kernel into the AI layer are:

Authority expires.

The system is a hash.

Agents are processes.

Nothing is forgotten.

I'm interested in feedback particularly from people who have worked on kernels, operating systems, capability security, microkernels or distributed systems.

Does treating AI-agent authority as an OS capability/lease make sense, or am I introducing complexity without enough security benefit?

GitHub: https://github.com/ni-sh-a-char/RESENTMENT

Browser demo: https://ni-sh-a-char.github.io/RESENTMENT/os/

Apache-2.0 licensed.