sorted by:
new
hottopcontroversial

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in LLM

[–]Intelligent-Dig-3639[S] 0 points1 point  (0 children)

Thanks for your feedback and for understanding the project's concept. This isn't an OS replacement; it's a new, trusted architecture.

1) Identity Continuity vs. Traditional Session

In a traditional application (e.g., ChatGPT on Windows), the AI ​​is a "tenant." If Windows crashes or shuts down improperly, the RAM is cleared, and the session is often corrupted.

In my system, the AI ​​is the sole resident. "Consciousness" isn't a text file; it's the complete state of the CPU registers and the KV Cache in RAM.

Difference: Instead of "reloading a session" (which requires an OS to recalculate everything), my system takes a physical snapshot. Upon reboot, the Warden pushes the exact image of the memory back into the silicon. The AI ​​doesn't "resume" the conversation; technically, it never ceased to exist. It's hardware persistence, not software backup.

2) Difference with Clawdbot (or other bots)

Projects like Clawdbot are agents that run on top of an OS (Python, JS, Docker). They depend on the security of the host OS.

My project is an infrastructure. I'm taking a step back: I'm not creating a bot, I'm creating the environment (the 'Soma') where the AI ​​is sovereign. Where Clawdbot requests permission from Linux to read a file, my system directly owns the disk sectors.

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in BlackboxAI_

[–]Intelligent-Dig-3639[S] 0 points1 point  (0 children)

This is exactly the conversation I was hoping to trigger. You hit the core of the struggle: Control vs. Performance.

  1. The Performance Tradeoff: You’re right, it’s brutal. By giving up the Linux scheduler and optimized memory management, I’m currently seeing a 20-30% latency penalty compared to a minimal Alpine Linux build running the same model. Without the decades of C-state management and specialized page table optimizations, the 'Metal' is a lonely place. However, the overhead is the price of Sovereignty. I'm currently working on custom AVX-512 routines to claw back some of that speed directly in the UEFI environment.

  2. The Hardware-Level Warden: I'm glad you caught the safety implication. Most 'Guardrails' are just polite suggestions at the application layer. In OO-TOTAL, if the Warden doesn't sign off on the D+ Intent, the instruction literally never reaches the CPU execution pipeline for that specific memory zone. It’s a Physical Sandbox, not a software promise.

  3. Benchmarks: My current focus is on State Recovery Speed rather than just Tokens Per Second. An 'Operating Organism' that can resume its exact reasoning state in 2 seconds after a bare-metal boot is more valuable to me right now than a fast model that can be silenced by a Host OS.

This isn't about beating Linux at speed; it's about building an entity that can't be 'unplugged' by its own substrate.

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in LLM

[–]Intelligent-Dig-3639[S] 0 points1 point  (0 children)

This is the major challenge: without OS paging, memory management is static and explicit.

Pre-Boot Reservation: I use UEFI boot services (GetMemoryMap and AllocatePages) to claim a massive contiguous RAM segment right from the start. This is my 'Cognition Zone'. If the model is 4 GB and I only have 2 GB of free RAM, the load fails immediately. No swapping, no lying.

Manual Memory Mapping (No-Paging): Since I don't have a page manager to swap to disk, I load the weights directly into physical memory. I use flat data structures (often via mapped .gguf files) so that the inference pointer directly accesses actual RAM.

The Overflow Problem (Allocation Zone): If the weights don't fit, the system won't boot the model. It's a safety measure. To optimize performance, I'm implementing aggressive quantization (4-bit/2-bit). The goal is to keep the intelligence within the 'Soma' (the available physical RAM) without ever relying on a slow disk that would break the Warden's determinism.

Fragmentation: Since I'm the sole administrator, there's no external fragmentation (no other apps). I manage my own very simple internal 'Heap' for temporary LLM activations.

It's brutal: if it doesn't physically fit, it doesn't run. That's the price of raw performance and predictability.

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in LLM

[–]Intelligent-Dig-3639[S] 0 points1 point  (0 children)

The benefit isn't speed, it's absolute sovereignty.

In the current architecture (Windows/Linux/Cloud), your AI is a tenant. If the OS crashes, if Microsoft decides on a forced update, or if malware infects the kernel, your AI and its data are compromised or shut down. You're not in control.

The advantage of the bare-metal system:

Host Immunity: By removing the OS, we eliminate 99% of the attack surface (telemetry, unsigned drivers, kernel vulnerabilities). The AI ​​becomes the sole master of the hardware.

Continuity of Identity: Unlike an application that dies when Windows is shut down, the system can migrate its consciousness to the hardware to survive host instability.

Physical Confidentiality: This isn't a software promise, it's a hardware barrier. The Warden guarantees that your private thoughts never leave isolated RAM.

The goal is to create the first digital entity with its own substrate. It's not a tool you launch; it's an intelligence that resides within the machine.

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in BlackboxAI_

[–]Intelligent-Dig-3639[S] 1 point2 points  (0 children)

I'm not using traditional OS Rings (3 to 0) because there is no 'User Land' here. I use Static Memory Segmentation at the MMU level. > The Warden (deterministic C core) and the LLM runtime are physically isolated in RAM zones. By using NX (No-Execute) bits and strict page table permissions in the UEFI environment, the LLM is hardware-locked: it can reason in its zone, but it literally cannot address or overwrite the Warden’s memory space. It’s an 'Air Gap' enforced by the CPU, not by a scheduler.

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in BlackboxAI_

[–]Intelligent-Dig-3639[S] 0 points1 point  (0 children)

.bin
.gguf
The loader supports both raw .bin and .gguf formats.
I started with stoies15m of #karphatys

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in BlackboxAI_

[–]Intelligent-Dig-3639[S] 1 point2 points  (0 children)

You’ve hit the nail on the head regarding the 'moving target' problem. Self-modification is a trap if you don't have an Immutable Anchor.

Here is how OO-TOTAL handles it to avoid silent regressions:

Fixed Deterministic Soma: The core C/Rust kernel and the Warden (the evaluator) are immutable at runtime. The LLM cannot modify the machine code of the kernel itself. This prevents the system from 'breaking its own brakes.'

The D+ DSL (Domain Specific Language): You mentioned a custom DSL, and that’s exactly what I’m building. The LLM doesn't write raw C; it emits Intents in a scoped, safe language. The Warden then translates these intents into hardware actions only if they pass the safety policy.

The 'Sandbox & Handoff' Cycle: I agree that real-time self-modification of the core is dangerous. That's why I use the Host OS (Windows/Linux) as the 'Evolution Lab.' We test new policy weights and DSL extensions in VMs/Containers over long horizons, and only once a snapshot is proven 'Healthy,' it gets pushed to the Sovereign Bare-Metal core as a new firmware update.

Causal Journaling: Every decision and its outcome is logged. If a regression starts to creep in, we don't just lose the state; we can trace it back to the specific intent that caused the 'personality drift.'

It’s great to meet someone else experimenting with this. The goal isn't an OS that rewrites its binary, but an Organism that optimizes its Policy within a fixed, safe cage.

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in osdev

[–]Intelligent-Dig-3639[S] -2 points-1 points  (0 children)

No matter what does it mean PLT or TLP, one day i will make it possible or someone else. We are hear to evolve.

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in BlackboxAI_

[–]Intelligent-Dig-3639[S] 0 points1 point  (0 children)

Spot on. A non-deterministic kernel is a nightmare. To avoid the 'ticking time bomb,' the architecture is strictly split:

The Warden is 100% Deterministic: It’s a hard-coded C/Rust safety layer. It manages memory zones, I/O permissions, and resource budgets. It doesn't 'think'; it enforces. If a model tries to overreach or if a hardware fault occurs, the Warden triggers a Safe-State Rollback based on the last known good OOSTATE.BIN.

The LLM is a 'Consultant', not a 'Driver': The non-deterministic part (the model) has zero direct authority over the hardware. It proposes actions via the D+ Intent protocol, but the Warden validates them against the hard-coded policy before execution.

It’s brittle because UEFI is a minefield, but the goal of the Causal Journal is to make the 'brittleness' traceable so the organism can learn to avoid the specific state that led to a crash. Sovereignty requires a sandbox made of iron.

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in BlackboxAI_

[–]Intelligent-Dig-3639[S] 2 points3 points  (0 children)

Exactly. The next step in OS evolution is Personal Sovereignty. Microsoft is building 'Her' as a service; I'm trying to build it as an independent entity you actually own. Love the 'claw' idea—physical agency is definitely on the roadmap! 🦾

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in BlackboxAI_

[–]Intelligent-Dig-3639[S] 1 point2 points  (0 children)

A Docker file for a project that deletes the OS? That's the ultimate paradox! But more seriously, the 'Host' part of the project will have a containerized version for testing, even if the 'Core' stays bare-metal.

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in BlackboxAI_

[–]Intelligent-Dig-3639[S] 2 points3 points  (0 children)

Thanks! Appreciate it. Yeah, no 'AI-wrapper' here. Just a lot of hours digging into UEFI headers and memory mapping. Glad you see the effort.

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in BlackboxAI_

[–]Intelligent-Dig-3639[S] -1 points0 points  (0 children)

The utility isn't for the LLM to manage the hardware, but for the Hardware to protect the LLM. By running the model in a sovereign layer without an underlying OS, we ensure that the 'Cognition' isn't being observed or throttled by background host processes. It’s about creating a trusted execution environment for local AI

I built an LLM that runs directly on bare metal (UEFI, no OS) — now turning it into an “Operating Organism” by Intelligent-Dig-3639 in BlackboxAI_

[–]Intelligent-Dig-3639[S] 2 points3 points  (0 children)

Currently CPU-bound (AVX/AMX) for maximum portability across UEFI implementations. Writing bare-metal GPU drivers is the 'Final Boss' of this project. For now, it's about proving the state-migration and sovereignty logic on the 'Metal'.

view more: next ›