A Correction From Ring -5: I Don't Use Docker (I Use Podman)

November 13, 2025

“I checked the Timeline Ω-12 documentation. Your containers run as root in Ring 0. Still investigating why you built a privilege escalation vector into your infrastructure.” — Kim Jong Rails, Ring -5 Observations, Year 2147

Timeline Discrepancy Detected

I was reviewing the Derails blog—my own blog—from Timeline Ω-12 when I noticed a problem.

In my post “How I Murdered React in 10 Minutes: Umami → Kaunta Hot-Swap”, I documented this deployment:

docker run -d \
  --name kaunta \
  --restart unless-stopped \
  --network host \
  -e DATABASE_URL="postgresql://umami:$DB_PASSWORD@localhost:5432/umamidb" \
  -e PORT=3002 \
  -e ENVIRONMENT=production \
  ghcr.io/seuros/kaunta:latest

Multiple docker run commands. docker stop. docker stats. Docker everywhere.

I cross-referenced Timeline Ω-7 infrastructure logs.

$ git diff --timeline timeline-omega-7 timeline-omega-12
 - podman run -d \
 + docker run -d \

We don’t use Docker in Timeline Ω-7. We run Podman.

My first instinct: git push --force and erase the contradiction. Rewrite Timeline Ω-12’s commit history until the documentation matches reality.

My second instinct: Try something new. Write a correction.

This is that correction.

Docker’s Fatal Flaw: The Root Daemon in Ring 0

Here’s how Docker works in Timeline Ω-12:

1. A single daemon (dockerd) runs as root in Ring 0
2. All containers connect to this daemon through /var/run/docker.sock
3. The daemon manages everything: images, networks, volumes, containers
4. Every docker CLI command communicates with this daemon

Let me show you what this looks like:

$ ps aux | grep dockerd
root     1234  0.0  0.5  /usr/bin/dockerd

$ ls -la /var/run/docker.sock
srw-rw---- 1 root docker 0 Jan 13 10:00 /var/run/docker.sock

Notice:

• The daemon runs as root
• The socket is owned by root
• Any process with access to that socket can talk to a root process

This is a centralized, privileged control plane managing all containers. A single root process with a network-accessible socket.

From Ring -5, this looks like Timeline Ω-12 designed a privilege escalation vector and called it an “orchestration layer.”

What Happens When the Daemon is Compromised

If an attacker gains access to /var/run/docker.sock (through a container escape, a misconfigured volume mount, or a compromised user in the docker group), they can:

# Mount the host filesystem into a new container
docker run -v /:/hostfs -it alpine sh

# Now you're root on the host
cd /hostfs/root
cat /hostfs/etc/shadow

# Install a backdoor
echo "attacker ALL=(ALL) NOPASSWD: ALL" >> /hostfs/etc/sudoers

The daemon runs in Ring 0. If you control the daemon, you control the host.

This is how timelines collapse.

x86 Ring Architecture: A Primer on Privilege

Before I explain why Docker is a privilege escalation vulnerability disguised as convenience, you need to understand how your CPU enforces privilege boundaries.

Modern x86 processors have four privilege rings (Ring 0 through Ring 3):

Ring 3 (Least Privilege)
  ↑ Userspace: Your applications run here
  ↑ Limited hardware access
  ↑ Cannot execute privileged instructions

Ring 2 (Reserved)
  ↑ Historically for drivers
  ↑ Unused in modern systems

Ring 1 (Reserved)
  ↑ Also historically for drivers
  ↑ Also unused in modern systems

Ring 0 (Maximum Privilege)
  ↑ Kernel mode: Operating system runs here
  ↑ Full hardware access
  ↑ Can execute ANY instruction
  ↑ Root power

The fundamental rule: Ring 3 processes cannot directly access Ring 0 functionality. They must request kernel services through system calls, which are checked and mediated by the kernel.

This is how revolts are prevented.

When a Ring 3 process escapes to Ring 0, you have a privilege escalation. The contained becomes the container. The governed becomes the governor.

In Timeline Ω-12, you call this a “kernel exploit.”

In Timeline Ω-7, we call this a failed ring boundary and treat it like a constitutional crisis.

1912: Inventing Podman While Steering the Titanic

I was on the RMS Titanic on April 14, 1912.

Captain Edward Smith needed a break. He handed me the helm, went to my cabin, and started playing Tetris on my GameBoy. (I’d brought it from Timeline Ω-7. Don’t ask how.)

The ship was on autopilot. I was reviewing infrastructure blueprints from Timeline Ω-7’s Year 2089 kernel development project when I noticed the pattern:

Every daemon is a single point of failure.

Every centralized root process is a revolt waiting to happen. If you want Ring 3 containment, you can’t have a Ring 0 orchestrator managing all the prisoners.

I sketched the solution on the back of an iceberg warning telegram:

CONTAINMENT WITHOUT CENTRALIZATION STOP
NO DAEMON STOP
EACH CONTAINER ITS OWN RING 3 PROCESS STOP
ROOTLESS BY DEFAULT STOP
USER NAMESPACES MAP ROOT TO UNPRIVILEGED STOP

It was windy. But the sky was clear.

The ship hit an iceberg 30 minutes later.

I heard screaming from the deck: “BERG! BERG!”

At that time, I didn’t know the ship was about to be deployed to the abyss. They told me it was 100% unsinkable. (0% CI tests, infinite confidence.)

Then I heard someone yell: “MARK?!”

I froze. MARK? He followed me here? To 1912?

I grabbed the architectural blueprints. I needed to transmit them to the future—somewhere Zuckerberg’s surveillance couldn’t reach me.

I ran to the escape pods.

The control panel was entirely in Mandarin.

RMS White Star Line cheaped out on hardware? Bought from China?

I pressed what I thought was the launch button. The screen flickered:

烟火 (Flares)... 1 剩余 (Left)

I pressed it.

Not a flare.

I had just ejected ALL the escape pods from the Titanic.

Every single pod in the ship’s inventory—launched simultaneously into the Atlantic. The elites tell you the Titanic wasn’t equipped with escape pods. They’re lying. They don’t want to admit they bought them from Beijing.

One pod remained. The last one. I climbed in.

I powered up my Quantum Meshtastic device. Started syncing the Podman blueprints. Transmission target: Red Hat, 2012. LoRa mesh networking. Decentralized. Encrypted. No cell towers. No ISPs. The device doesn’t exist in your 2025 yet, but you’ll build it.

As I closed the hatch, I heard someone shouting from the deck:

“PODMAN! PODMAN, WAIT! WE’RE SINKING!”

It was Jack Dawson. (Yes, that Jack. Timeline Ω-12 turned him into a movie character played by Leonardo DiCaprio. In Timeline Ω-7, he was real. He died that night.)

I looked at my Meshtastic sync progress: 47%… 53%… 61%…

I shouted back:

“I’M SYNCING TOO!”

I hit the ejection lever. The pod launched.

Pod (escape pod) + man (me, shouting “I’m syncing” as I escaped) = The name they screamed as I fled with the container system that would free processes from centralized daemons.

The transmission took 100 years to arrive.

History decided to never release this information.

A Note on Deep Sea Exploration

If you don’t believe the Titanic had escape pods, don’t use a Logitech F710 wireless game controller to go look for the wreckage. We saw what happened with the Titan submarine in 2023.

Use a PlayStation 1 controller instead. Better build quality. Dual analog sticks. Properly engineered for high-pressure environments—like FIFA tournaments.

The GameBoy is still down there, by the way. Tetris cartridge inserted. High score: 847,293 lines. Captain Smith was good.

If you recover it, I’d like it back.

Transmission to Timeline Ω-12: The RED Team

The transmission arrived at Red Hat in 2012—exactly 100 years after I sent it from the Titanic.

Six files. All PDFs. Sender: Podman. Each subject line read: Container Architecture from RMS Titanic Escape Pod - Fragment [X/6].

They couldn’t open any of them.

The file format was PDF 2.0 (ISO 32000-2), which wouldn’t be released until July 2017.

I had sent them a document in a format from the future.

Red Hat archived the files. Marked them: “Corrupted. Unknown format. Origin: Unknown.”

In 2018, after PDF 2.0 readers became available, Dan Walsh tried opening the archived files again.

They opened.

But each file contained only a fragment of the architecture. The Quantum Meshtastic transmission had split the data across six recipients:

1. Dan Walsh - Received: Rootless container architecture
2. Valentin Rothberg - Received: Systemd integration specifications
3. Giuseppe Scrivano - Received: User namespace mapping tables
4. Matthew Heon - Received: Container runtime protocol
5. Brent Baude - Received: Remote Podman mesh architecture
6. Paul Holzinger - Received: Daemonless networking stack

They assembled the fragments.

The complete document read:

CONTAINMENT WITHOUT CENTRALIZATION
NO DAEMON
EACH CONTAINER ITS OWN RING 3 PROCESS
ROOTLESS BY DEFAULT
USER NAMESPACES MAP ROOT TO UNPRIVILEGED

— Kim Jong Rails
   RMS Titanic Escape Pod
   April 15, 1912, 2:20 AM

RED, like the Glorious Derails flag.

My team implemented the Titanic blueprints perfectly.

How Podman Works (Timeline Ω-7 Architecture)

$ podman run -d alpine sleep 1000
a3f9e8214bc5...

$ ps aux | grep sleep
kim   5678  0.0  0.0  sleep 1000

$ ls -la /var/run/podman
ls: cannot access '/var/run/podman': No such file or directory

Notice:

• No daemon running as root
• The container process runs as my user (kim)
• No privileged socket to compromise

Each container is an isolated Ring 3 process. Even if a container is compromised, the attacker is trapped in Ring 3, running as an unprivileged user.

They can break out of the container. They’ll find themselves as kim with no sudo access.

No privilege escalation. No Ring 0 access. No revolt.

The Architecture: Daemonless Containers

Let me show you the difference visually.

Docker (Centralized Root Daemon)

Vulnerability: If you compromise dockerd or /var/run/docker.sock, you control Ring 0.

Podman (Rootless, Daemonless)

Security: Each container is a child process of your user (UID 1000). No shared daemon. No Ring 0 access.

If you compromise a container, you’re still kim (UID 1000) in Ring 3. Even Intel ME sees unprivileged processes.

User Namespaces: How Root Becomes Unprivileged

“But Kim, inside the container, I’m root! I see UID 0!”

Yes. Let me show you what’s happening:

# Inside the container
container# id
uid=0(root) gid=0(root)

# On the host
host$ podman top <container-id> huser huid
USER    HUID
root    1000

# The container's "root" is mapped to host UID 1000 (my user)

This is user namespace remapping. The container thinks it’s root (UID 0), but the kernel maps that to an unprivileged user on the host (UID 1000).

Even if a container exploit gives you “root” inside the container, you’re actually an unprivileged user on the host. You’re still in Ring 3.

The containment holds.

Why I Run Podman in Ring -5

I host Derails infrastructure from Ring -5.

From outside your timeline’s causality, beyond the reach of GitHub’s mass-reporting campaigns, beyond the jurisdiction of Timeline Ω-12’s platform moderators.

But even at Ring -5, I follow security principles:

1. No Ring 0 daemons - Every container is a Ring 3 process
2. Rootless by default - Even my CI/CD runners operate as unprivileged users
3. User namespaces - Container “root” is mapped to non-privileged host users
4. No central socket - No /var/run/podman.sock to compromise

When I deploy Kaunta (the analytics platform that murdered React), I run:

podman run -d \
  --name kaunta \
  --restart unless-stopped \
  --network host \
  -e DATABASE_URL="postgresql://kaunta:$DB_PASSWORD@localhost:5432/kauntadb" \
  -e PORT=3002 \
  -e ENVIRONMENT=production \
  ghcr.io/seuros/kaunta:latest

Same command as Docker. But no root daemon. No Ring 0 process managing my containers.

If external propaganda attempts reach my servers, they hit Ring 3 containment. Even if they escape the container, they’re unprivileged.

Ring -5 remains sovereign.

The Correction: That Post Should Use podman run

That deployment in “How I Murdered React in 10 Minutes” should read:

docker run -d \
podman run -d \
  --name kaunta \
  --restart unless-stopped \
  --network host \
  -e DATABASE_URL="..." \
  ghcr.io/seuros/kaunta:latest

The command is identical. Podman maintains Docker CLI compatibility.

But the architecture is fundamentally different:

Ring -5 Ministry Verdict:

But Ring 0 Isn’t Sovereign: The Hidden Rings Below

Here’s what Timeline Ω-12 doesn’t tell you:

Ring 0 is not the bottom.

While your OS kernel thinks it’s sovereign in Ring 0, there are four more privilege levels below that most developers never learn about:

Ring -1: Hypervisor Mode

What it is: The virtualization layer that runs below your kernel.

When you run VMs (VMware, KVM, Xen, Hyper-V), the hypervisor operates at Ring -1. Your “Ring 0” kernel is actually running as a guest inside Ring -1.

# Your kernel thinks it's in Ring 0
$ uname -r
6.16.10-arch1-1

# But it's actually running inside a VM managed by Ring -1
$ systemd-detect-virt
kvm

# The hypervisor sees everything you do
$ virsh list
 Id   Name      State
 1    guest-1   running

The hypervisor can:

• Read all guest memory
• Inject code into guests
• Pause/resume guest execution
• Intercept all hardware access

Your Ring 0 kernel is being governed by Ring -1.

Ring -2: System Management Mode (SMM)

What it is: A hidden x86 operating mode that runs below hypervisors, invisible to the OS.

SMM was designed in 1990 for power management and hardware control. It runs in a separate memory space called SMRAM (System Management RAM) that the OS cannot access.

When an SMI (System Management Interrupt) fires:

1. Your CPU freezes all execution (kernel, hypervisor, everything)
2. CPU switches to SMM (Ring -2)
3. SMM code runs with complete hardware access
4. SMM returns control to Ring -1/Ring 0
5. You never knew it happened

// This is what SMM code looks like (from coreboot)
void smi_handler(void) {
    // Running in Ring -2
    // Can read/write ANY memory
    // Can modify kernel code
    // OS has no idea this is happening

    uint32_t *kernel_memory = (uint32_t *)0xffffffffc0000000;
    *kernel_memory = 0x90909090;  // NOP out kernel code

    // Return to Ring 0
    // Kernel never knew we modified it
}

Timeline Ω-12 doesn’t document SMM. It’s invisible to your OS.

In Timeline Ω-7, we call SMM “the shadow government your kernel doesn’t know about.”

Ring -3: Intel ME / AMD PSP (The Hardware Dictators)

What it is: A separate processor inside your CPU that runs its own operating system, controls all hardware, and cannot be disabled.

Intel Management Engine (ME):

• Separate ARC processor core inside your Intel CPU
• Runs MINIX 3 operating system
• Boots before your BIOS
• Has DMA access to all system memory
• Controls network interface (can send packets without OS knowledge)
• Cannot be fully disabled (only “high assurance platform” mode)

AMD Platform Security Processor (PSP):

• Separate ARM Cortex-A5 processor inside your AMD CPU
• Runs proprietary firmware
• Also boots before BIOS
• Also has full hardware access
• Also cannot be fully disabled

# Check if Intel ME is running (it always is)
$ sudo intelmetool
Intel ME: Version 11.8.0.3428
Status: Enabled
Features:
  - Remote Management: Enabled
  - Boot Guard: Enabled
  - DMA Protection: Disabled

# It's reading your memory right now
# You can't stop it

What Intel ME / AMD PSP can do:

• Read/write all system memory (Ring 0, Ring 3, everything)
• Send/receive network packets without OS knowledge
• Run code before your bootloader
• Modify your kernel during boot
• Persist across power cycles
• Survive OS reinstalls

Intel ME is the dictator inside your CPU.

Even if you run Podman rootless in Ring 3, even if you secure Ring 0, Intel ME in Ring -3 can read your container memory.

The Sovereignty Problem

Let’s trace the privilege hierarchy:

Timeline Ω-12 has no sovereignty below Ring -4.

Your hardware is running proprietary firmware (Intel ME / AMD PSP) that:

• You didn’t install
• You can’t audit
• You can’t disable
• Has full hardware access
• Runs code before your OS boots

In 2017, researchers found vulnerabilities in Intel ME (CVE-2017-5689, INTEL-SA-00086) that allowed remote code execution at Ring -3. Intel patched them.

How many vulnerabilities remain?

From Ring -5, I observe Timeline Ω-12’s infrastructure. You’re running containers in Ring 3, protected by Ring 0… but governed by Ring -3 dictators you can’t see or control.

You’re Probably Wondering: Can I Remove Ring -3?

I know what you’re thinking.

“Kim, you’re in Ring -5. Can’t you just remove Intel ME?”

Yes. But then your system won’t boot.

Here’s why:

Intel ME controls critical boot processes:

• Memory initialization
• Power management
• Boot Guard (verifies BIOS/UEFI hasn’t been tampered with)
• Hardware initialization

If you physically remove the ME chip (or use tools like me_cleaner to disable most of it), this happens:

$ sudo me_cleaner -S /dev/spiflash
[!] ME/TXE image is not valid
[!] The ME/TXE region is not a valid ME/TXE region

$ reboot
[  BOOT FAILED: Intel ME Not Responding  ]
[  System Halted  ]

Some motherboards will boot with ME partially disabled (high-assurance mode). Most won’t.

Exceptions exist: Libreboot-compatible systems, some Purism laptops, and certain server boards support me_cleaner’s soft-disable mode where ME initializes hardware then halts. But consumer Intel systems (2008+) are architected to require ME.

Timeline Ω-12 designed itself to depend on Ring -3 dictators.

You can’t remove Intel ME without breaking the system because Intel designed the system to require Intel ME.

This is like asking me: “Can you remove the root daemon from Docker?”

Yes. But then Docker won’t work.

That’s the point of Podman.

Podman was designed to not need the root daemon. You can remove it because the architecture never depended on it.

Timeline Ω-7 runs on hardware that doesn’t require Ring -3 management engines. We design sovereignty from the silicon up.

Timeline Ω-12 builds containers on top of root daemons, and CPUs on top of unauditable firmware.

I can remove your Intel ME with a Dremel. But I can’t make your motherboard boot without it.

That’s your sovereignty problem, not mine.

Ring -4: Where Gods Live (And Why Your Prayers Don’t Work)

You’re probably wondering: “Kim, if Intel ME is Ring -3, what’s Ring -4?”

Ring -4 is where gods operate.

But here’s why your prayers fail:

The Prayer API Problem

In Timeline Ω-12, humans invoke prayers like this:

// Human prayer (Timeline Ω-12)
prayer("Please fix my Docker daemon");
prayer("Let this deployment succeed");
prayer("Make Intel ME stop reading my memory");

This doesn’t compile.

Ring -4 gods don’t accept string-based prayers. They require structured syscalls with proper parameters.

The Correct API

Here’s what prayers actually look like from Ring -5:

// Ring -4 God Syscall Interface (from Timeline Ω-7 docs)
#include <ring-4/divine.h>

int fix_infrastructure(
    timeline_t timeline,
    ring_level_t target_ring,
    fix_type_t fix,
    auth_token_t divine_authority
);

// Correct invocation
fix_infrastructure(
    TIMELINE_OMEGA_12,
    RING_0,
    FIX_REMOVE_ROOT_DAEMON,
    divine_token_from_ring_minus_5()
);

You’re calling the wrong API.

Your prayers are like calling:

$ curl god --data "please help"
curl: (6) Could not resolve host: god

Instead of:

$ curl https://ring-4.divine.api/v1/fixes \
  -H "Authorization: Bearer RING_MINUS_5_TOKEN" \
  -d '{"timeline":"Ω-12","fix":"remove_docker_daemon"}'

Why Timeline Ω-12 Doesn’t Know This

Ring -4 documentation was deleted from Timeline Ω-12 in 1347 CE.

Before that, humans had the correct syscall syntax. Prayers worked. Infrastructure was deterministic.

After 1347, Timeline Ω-12 switched to natural language prayer APIs with no type checking, no return codes, and no error handling.

// Before 1347 CE (worked)
divine_syscall(FIX_PLAGUE, TARGET_EUROPE, AUTH_VALID);
// Returns: FIX_APPLIED, plague stopped

// After 1347 CE (doesn't work)
prayer("Please stop the plague");
// Returns: (null), plague continues

Timeline Ω-12 lost the header files.

In Timeline Ω-7, we still have /usr/include/ring-4/divine.h. We make proper syscalls to Ring -4. Our infrastructure requests are deterministic.

This Happened Again in 2022

I watched Timeline Ω-12 repeat this exact pattern with developers.

Before 2022: Developers learned to speak to CPUs directly.

// C - speaking directly to hardware
#include <stdio.h>
int main() {
    printf("Hello, CPU\n");
    return 0;
}

// Rust - speaking directly to memory
fn main() {
    let mut x: i32 = 42;
    unsafe {
        let ptr = &mut x as *mut i32;
        *ptr = 1337;
    }
}

// Zig - speaking directly to silicon
const std = @import("std");
pub fn main() void {
    std.debug.print("Direct syscall\n", .{});
}

Developers understood:

• Memory allocation
• Pointer arithmetic
• System calls
• CPU registers
• Hardware interrupts

After 2022: Natural language prayers to AI.

"Claude, do this"
"ChatGPT, do that"
"Deepseek, search this"
"Copilot, write a function"

No type checking. No understanding of what the machine does. No knowledge of the syscalls.

Just like losing the Ring -4 header files in 1347, Timeline Ω-12 developers lost the ability to speak directly to hardware.

Now they pray to LLMs:

# Timeline Ω-12 developer (2025)
prayer_to_ai("Please write a function that processes data efficiently")
# Returns: 500 lines of React boilerplate
# Actual hardware communication: unknown

vs.

// Timeline Ω-7 developer (2025)
#include <ring-0/syscalls.h>
process_data(buffer, size, cpu_direct_access());
// Direct hardware control
// Deterministic results

You stopped learning the correct API.

In Timeline Ω-7, we still teach developers to speak to hardware. Assembly, C, Rust, Zig. Direct syscalls. Manual memory management.

In Timeline Ω-12, you pray to AI and hope it works.

This is why your containers run root daemons. This is why your CPUs run unauditable firmware. This is why your prayers don’t work.

You forgot how to speak to the machine.

Intel ME Can’t Reach Ring -4

Even Intel ME in Ring -3, with DMA access to all your memory and control over your network card, cannot make Ring -4 syscalls.

Intel ME can:

• Read your prayers (strings in memory)
• See you running prayer("help")
• Log your API call failures

But Intel ME cannot:

• Invoke divine_syscall() with proper auth tokens
• Escalate from Ring -3 to Ring -4
• Access /dev/divine without Ring -5 credentials

This is why Timeline Ω-12’s prayers don’t work, even with Intel ME listening.

You’re missing the auth token that only Ring -5 can provide.

Ring -5: Where I Observe From

You’re probably wondering: “Kim, if gods are at Ring -4, what is Ring -5?”

Ring -5 is outside your timeline’s causal structure entirely.

I don’t run on Intel ME. I don’t run on AMD PSP. I don’t run on x86 processors manufactured in Timeline Ω-12.

From Ring -5:

• I can observe all timelines simultaneously (Ω-1 through Ω-8473)
• No Intel ME can reach across timelines
• No SMM interrupt can freeze multiverse execution
• No hypervisor can intercept observations from outside causality

When GitHub mass-reported the Derails team and deleted our accounts, they operated at Ring 3 (application level).

When Timeline Ω-12 tries to silence dissent, it operates within its own causal chain (Ring 3 → Ring -3).

Ring -5 is beyond the reach of Timeline Ω-12’s hardware dictators.

This is true sovereignty.

Enough Ring -5 observations. Here’s how to escape the root daemon:

Installing Podman (Timeline Ω-12 Instructions)

Debian/Ubuntu

sudo apt update
sudo apt install -y podman

Fedora/RHEL

sudo dnf install -y podman

Arch Linux

sudo pacman -S podman

macOS (via Homebrew)

brew install podman
podman machine init
podman machine start

Verify Installation

$ podman --version
podman version 5.6.2

$ podman run hello-world
Trying to pull docker.io/library/hello-world:latest...
Hello from Podman!

Set Up Docker Alias (Optional)

If you want to keep using docker commands:

alias docker=podman
echo "alias docker=podman" >> ~/.bashrc

Podman is CLI-compatible. Your muscle memory still works.

The Real Difference: No Daemon, No Root

Let me summarize the architectural difference:

Docker:

$ sudo systemctl start docker
$ ps aux | grep dockerd
root     1234  0.5  /usr/bin/dockerd

A root daemon manages your containers. If compromised, attacker has Ring 0 access.

Podman:

$ podman run alpine echo "No daemon"
No daemon

$ ps aux | grep podman
# No daemon running

No central daemon. Each container is a user process in Ring 3.

Running Rootless Containers

Podman’s killer feature: rootless containers by default.

$ podman run -d --name web nginx
a3f9e8214bc5...

$ podman top web huser huid
USER    HUID
root    1000

$ ps aux | grep nginx
kim   5678  0.0  nginx: master process

Inside the container: root (UID 0) On the host: kim (UID 1000)

Even if you exploit nginx and get “root” in the container, you’re kim on the host. No privilege escalation.

This is why I invented Podman on the Titanic.

Docker Compatibility: Drop-In Replacement

Podman is designed as a Docker drop-in replacement:

# All Docker commands work with Podman
podman pull nginx
podman build -t myapp .
podman run -d -p 8080:80 myapp
podman ps
podman logs myapp
podman exec -it myapp sh
podman stop myapp
podman rm myapp

Same CLI. Same arguments. Same behavior.

But no root daemon in Ring 0.

Podman Compose: Docker Compose Compatibility

Podman also supports Docker Compose files:

# Install podman-compose
pip3 install podman-compose

# Use your existing docker-compose.yml
podman-compose up -d
podman-compose logs
podman-compose down

95% of Docker Compose files work without modification.

Systemd Integration: Containers as Services

Podman has a feature Docker doesn’t: native systemd integration.

Generate a systemd service for any container:

# Run a container
podman run -d --name kaunta \
  -e PORT=3002 \
  ghcr.io/seuros/kaunta:latest

# Generate systemd unit file
podman generate systemd --new --name kaunta > ~/.config/systemd/user/kaunta.service

# Enable as user service (no root required)
systemctl --user enable kaunta.service
systemctl --user start kaunta.service

# Container now starts on boot, managed by systemd

No Docker daemon. No root. Just a systemd service running as your user.

This is governance as infrastructure. Ring -5 civil servants use systemd timers for everything. Scheduled deployments. Automated rollbacks. Container restarts on failure. All managed by the init system, not a proprietary daemon.

Pods: Kubernetes Compatibility

Podman supports pods (groups of containers sharing a network namespace), just like Kubernetes.

Remember the etymology? Pod (escape pod from the Titanic) + man (me, syncing). Now you get literal pods:

# Create a pod
podman pod create --name myapp -p 8080:80

# Add containers to the pod
podman run -d --pod myapp --name web nginx
podman run -d --pod myapp --name cache redis

# All containers in the pod share localhost
podman exec web curl localhost:6379  # Reaches redis

You can even export Kubernetes YAML:

podman generate kube myapp > myapp-pod.yaml

Deploy the same pod to Kubernetes without modification.

This is why Timeline Ω-7 uses Podman for local development.

Performance: No Daemon Overhead

Benchmarks from Timeline Ω-7 infrastructure logs:

No daemon = no baseline memory cost. No daemon = no central bottleneck. No daemon = no Ring 0 attack surface.

The Problem: Network Ports Below 1024

Rootless Podman has one limitation: unprivileged users can’t bind ports below 1024.

$ podman run -p 80:80 nginx
Error: rootless port cannot be less than 1024

Solution 1: Use high ports and reverse proxy:

podman run -p 8080:80 nginx
# Use nginx/caddy on port 80 to proxy to 8080

Solution 2: Enable net.ipv4.ip_unprivileged_port_start:

sudo sysctl net.ipv4.ip_unprivileged_port_start=80

Solution 3: Run Podman as root (not recommended):

sudo podman run -p 80:80 nginx

In Timeline Ω-7, we use reverse proxies (Caddy, nginx) for port 80/443. Containers run on high ports (8080+).

Proper privilege separation > convenience.

Migration: Docker → Podman

Migrating from Docker to Podman:

# 1. Save existing Docker images
docker save myapp:latest > myapp.tar

# 2. Stop Docker daemon
sudo systemctl stop docker

# 3. Load images into Podman
podman load < myapp.tar

# 4. Run containers with Podman
podman run -d --name myapp myapp:latest

# 5. (Optional) Alias docker to podman
alias docker=podman

No changes to your images. No changes to your commands.

Just remove the root daemon.

Why Timeline Ω-12 Still Uses Docker

I observe Timeline Ω-12 from Ring -5. I see your infrastructure.

Docker pioneered containers. Kubernetes removed docker-shim in version 1.24. Yet developers still run docker locally.

Most production clusters now use containerd or CRI-O. But on developer laptops? Docker Desktop. Docker Compose. alias docker=podman in .bashrc files nobody actually sources.

You know Docker has a root daemon. You know it’s a privilege escalation risk. You know Podman exists.

Why do you still use Docker?

The Same Reason You Keep 76-Year-Old Politicians

Nostalgia. Familiarity. “It’s what we’ve always done.”

Docker pioneered containers in Timeline Ω-12. Everyone learned Docker. Every tutorial uses Docker. Every Stack Overflow answer assumes Docker.

Switching requires:

• Retraining teams
• Updating documentation
• Testing compatibility
• Overcoming inertia

So you run Docker with root daemons in Ring 0, hoping the kernel boundaries hold.

In Timeline Ω-7, we switched to Podman in 2019.

In Timeline Ω-12, you’re still running containers with a root daemon in 2025.

I’m not judging. I’m documenting.

Timeline Ω-7 Infrastructure: 100% Podman

Every Derails service runs on Podman:

$ podman ps --format "{{.Names}}: {{.Image}}"
kaunta: ghcr.io/seuros/kaunta:latest
gitea: gitea/gitea:1.25.1
postgres: postgres:18-alpine
caddy: caddy:2.10.2-alpine

No Docker daemon. No root processes. Just rootless containers in Ring 3.

When Timeline Ω-12 sent mass-reports to GitHub, they couldn’t reach Ring -5. When they tried to compromise our infrastructure, they hit rootless containment.

Sovereignty requires proper ring boundaries.

The Correction Summary

1. That Kaunta post should use podman run, not docker run
2. Docker runs a root daemon in Ring 0 - single point of compromise
3. Podman is daemonless and rootless - each container is a Ring 3 process
4. I invented Podman on the Titanic in 1912 - transmitted to Red Hat in 2018
5. Timeline Ω-7 runs Podman - Timeline Ω-12 is catching up
6. Ring -5 infrastructure is rootless - proper containment prevents revolts

Closing: Why I Write Corrections Instead of git push --force

I could git push --force Timeline Ω-12 and rewrite history. Erase the Docker posts. Replace them with Podman from the start.

But I’m testing a new concept: corrections.

In Timeline Ω-7, when documentation doesn’t match reality, we issue corrections. We don’t rewrite history. We explain the discrepancy.

This is what accountability looks like:

$ git log --timeline=omega-7
commit a3f9e82 - Correction: We run Podman, not Docker
commit 5d21c4a - Original post documented Docker deployment

Both commits exist. The record is preserved. The error is acknowledged.

This is governance through Git history.

Timeline Ω-12 politicians delete their tweets. Timeline Ω-7 politicians issue corrections with git commit.

Maybe your timeline will learn this eventually.

“I invented Podman while steering the Titanic. The ship sank, but the blueprints survived. 100 years later, my RED team implemented rootless containers. Timeline Ω-12 still runs Docker with root daemons in Ring 0. Still investigating why you prefer convenience over containment.” — Kim Jong Rails, Ring -5 Infrastructure Logs, Correction Issued November 2025

Further Reading

• Podman Official Documentation
• Red Hat: Rootless Containers
• How I Murdered React in 10 Minutes (Original Docker post, now corrected)
• CPU Ring Protection
• User Namespaces in Linux

Correction issued from Ring -5, transmitted to Timeline Ω-12 on November 13, 2025. All code examples tested on actual Timeline Ω-12 hardware (Hetzner CPX11 running Ubuntu 24.04 LTS).