language: en kae3g ← back to index
(unlisted) — This essay is not shown on the main index but remains accessible via direct link

kae3g 9513: Personal Sovereignty Stack - Framework, seL4, RISC-V, Nock

Phase 1: Foundations & Philosophy | Week 2 | Deep Dive | Reading Time: 22 minutes

Optional Essay: This is a deep dive into personal computing sovereignty! Read 9511 (Kubernetes) first for context.

What You'll Learn (Deep Dive)

This essay explores personal computing sovereignty:

Prerequisites

Personal Sovereignty in Computing

After learning about Kubernetes (Essay 9511 - enterprise orchestration), let's explore the opposite end of the spectrum.

What if you want to:

This is personal sovereignty computing.

The insight: Kubernetes (scale) and Framework (sovereignty) are complementary (Essay 9511). This essay focuses on the sovereignty path.

Part 1: Framework Laptops - Hardware You Own

Framework (2021, San Francisco) makes modular, repairable laptops.

This is Unix philosophy applied to hardware (Essay 9510):

Unix taught us software modularity. Framework teaches us hardware modularity.

Framework 13 (13.5" display)

Framework 16 (16" display)

Why this matters:

Comparison to other laptops:

Why AMD for Linux

AMD Ryzen + Radeon is ideal for Linux:

CPU Advantages:

GPU Advantages:

For sovereignty stack:

The Personal Sovereignty Stack (on Framework)

Here's the vision (Essays 9948-9960):

┌──────────────────────────────────────┐
│     Your Applications                │
│  (Clojure, Rust, whatever you want)  │
└──────────────────────────────────────┘
              ↓
┌──────────────────────────────────────┐
│     Nix (Package Manager)            │
│  - Declarative configuration         │
│  - Reproducible builds               │
│  - /nix/store immutable              │
└──────────────────────────────────────┘
              ↓
┌──────────────────────────────────────┐
│     User-space Utilities             │
│  - grep, cat, ls (verified!)         │
│  - Written in Haskell/Rust           │
│  - Compiled to RISC-V                │
└──────────────────────────────────────┘
              ↓
┌──────────────────────────────────────┐
│     seL4 Microkernel                 │
│  - Formally verified (10K lines)     │
│  - Capability-based security         │
│  - Isolation guarantees              │
└──────────────────────────────────────┘
              ↓
┌──────────────────────────────────────┐
│     RISC-V ISA (future)              │
│  - Open instruction set              │
│  - No proprietary lock-in            │
└──────────────────────────────────────┘
              ↓
┌──────────────────────────────────────┐
│     AMD Ryzen Hardware (today)       │
│  - Framework 13 or 16                │
│  - Open drivers, repairable          │
└──────────────────────────────────────┘
              ↓
┌──────────────────────────────────────┐
│     Nock Specification (eternal)     │
│  - 12 rules, frozen                  │
│  - Specifies all semantics           │
│  - Auditable by anyone               │
└──────────────────────────────────────┘

Each layer:

This is Unix philosophy, end-to-end:

From silicon to semantics: Unix principles all the way down (and up!).

The Transition Path

Today → Future:

Phase 1: Today (2025)

Phase 2: Near Future (2026-2028)

Phase 3: Long-term (2029-2032)

Phase 4: Generational (2033+)

The key: Build for decades, not quarters.

Kubernetes vs. Framework: When to Use Which

Use Kubernetes When:

1. Multi-tenancy

2. Scale

3. High Availability

4. Team Coordination

5. Microservices

Example use cases:

Use Framework (Personal Stack) When:

1. Learning

2. Privacy

3. Sovereignty

4. Longevity

5. Development

6. Research

Example use cases:

The Hybrid Approach

Most people need BOTH:

At Work (Kubernetes):

┌─────────────────────────────────┐
│   Your Company's k8s Cluster    │
│                                 │
│  - Production workloads         │
│  - Team collaboration           │
│  - Customer-facing services     │
│  - Managed by DevOps            │
└─────────────────────────────────┘

At Home (Framework):

┌─────────────────────────────────┐
│   Your Framework Laptop         │
│                                 │
│  - Personal projects            │
│  - Learning/experimentation     │
│  - Private data                 │
│  - Full control                 │
└─────────────────────────────────┘

The Bridge:

Develop locally (Framework + NixOS)
Deploy to cloud (Kubernetes cluster)

Best of both worlds:

Kubernetes on Your Framework?

Can you run Kubernetes locally?

Yes! Several options:

1. Minikube

# Single-node k8s cluster on your laptop
minikube start

# Deploy apps locally
kubectl apply -f deployment.yaml

Pros: Full k8s API, good for learning
Cons: Resource-heavy (needs VM)

2. K3s

Lightweight Kubernetes (Rancher Labs):

3. Podman (Kubernetes-compatible)

Daemonless container engine:

Best for: Testing k8s configs locally before deploying.

The Philosophy: Centralization vs. Decentralization

Kubernetes = Managed Centralization

Trade-offs:

Framework = Personal Decentralization

Trade-offs:

The insight: Different problems need different solutions.

But Unix philosophy applies to BOTH (Essay 9510):

This is why Unix philosophy endures (50+ years!): It's scale-independent. Works for:

The principle is universal: Simplicity, modularity, composition.

Try This

Exercise 1: Run Kubernetes Locally

Install minikube or k3s:

# k3s (simpler)
curl -sfL https://get.k3s.io | sh -
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

# Deploy nginx
kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=80 --type=NodePort

# Access
kubectl get services
# Visit http://localhost:<PORT>

Observe:

Exercise 2: Research Framework Laptops

Visit: framework.computer

Compare:

Questions:

Exercise 3: Plan Your Sovereignty Stack

Design your ideal system:

  1. Hardware: Framework 13 or 16? (AMD recommended)
  2. OS: NixOS? Artix? Void?
  3. Init: systemd, s6, runit, OpenRC?
  4. Userspace: Which tools do you need?
  5. Specification: Which workflows to specify in Nock?

This is YOUR plan. Start simple, evolve over time.

Going Deeper

Related Essays

External Resources

Reflection Questions

  1. Why does Kubernetes dominate enterprise? (Solves real scale problems, vendor support, ecosystem)
  2. Can you have sovereignty in the cloud? (Partial - you control software, not hardware. True sovereignty requires owning silicon.)
  3. Is Kubernetes overkill for most projects? (Often yes! Start simple, scale when needed.)
  4. Why Framework over MacBook? (Repairability, ownership, longevity, open drivers - BUT MacBooks have their place too!)
  5. Will RISC-V replace x86/ARM? (Slowly, yes - open ISAs are inevitable long-term)
  6. How does Nock relate to Kubernetes? (Both are declarative specs! Kubernetes = cluster state, Nock = computation semantics)
  7. Can you run seL4 on Framework? (Not officially yet, but Genode OS runs on it - step in that direction!)
  8. Is this practical or idealistic? (Both! Framework works TODAY. seL4/RISC-V coming soon. Nock is aspirational but grounded.)

Summary

Two Paradigms:

Kubernetes (Enterprise Orchestration)

Core concepts:

Philosophy: Managed centralization with distributed execution

Framework + Sovereignty Stack (Personal Computing)

The Stack:

Philosophy: Personal sovereignty through verification

The Synthesis

Use BOTH:

The future:

In the Valley:

The through-line:

We're not abandoning Unix. We're perfecting it.

Plant lens: "Kubernetes is industrial farming (monoculture, scale, efficiency). Framework is a personal garden (diversity, sovereignty, learning). Both have their place—feed cities, feed families."

Choosing Your Distribution: Artix vs. SixOS vs. Void

Now that you understand the sovereignty stack, which Linux distribution should you run on your Framework?

The Three Paths (Distilled from Essay 9959)

Artix Linux (The Pragmatic Path)

What It Is:

Strengths:

Tradeoffs:

Best For: Experienced Linux users who want systemd-free Arch with maximum software availability.

SixOS (The Visionary Path)

What It Is:

Strengths:

Tradeoffs:

Best For: Patient builders who want declarative, reproducible systems and are willing to help develop the ecosystem.

Void Linux (The Minimalist Path)

What It Is:

Strengths:

Tradeoffs:

Best For: Minimalists who prioritize simplicity and runit's crash-only philosophy.

Our Path Forward: Why SixOS + Grainstore

After exploring all options (see Essay 9959 for deep analysis), we're choosing SixOS. Here's why:

Reason 1: Declarative Configuration

NixOS's killer feature: Your entire system is ONE config file.

# configuration.nix describes EVERYTHING
{
  boot.loader.grub.enable = true;
  services.s6.enable = true;  # SixOS uses s6!
  environment.systemPackages = [ pkgs.brave pkgs.cursor ];
  # ... complete system specification
}

Why this matters:

Artix/Void don't have this. They use traditional config files scattered across /etc/.

Reason 2: The Grainstore Strategy

SixOS + Nix enables the Grainstore:

{:grainstore-nix-synergy
 {:nix-features
  ["Declarative packages"
   "Reproducible builds"
   "Multiple versions coexist"
   "Atomic updates"]
  
  :grainstore-benefits
  ["Vendor dependencies in Nix"
   "Nock specs for verification"
   "Test suite for equivalence"
   "Jets for optimization"]
  
  :result "Century-scale software independence"}}

Our strategy:

  1. Specify dependencies in Nock (eternal)
  2. Vendor them in Nix (reproducible)
  3. Verify with tests (proven equivalence)
  4. Deploy on Framework 16 (sovereign hardware)

Artix can't do this - No declarative package management
Void can't do this - No Nix-like reproducibility

Reason 3: s6 Without Sacrificing Ecosystem

SixOS gives us:

Artix gives us:

Void gives us:

Winner: SixOS - We get s6 + Nix + declarative + ecosystem!

Reason 4: Future-Proofing

The long game (from Phase 2-4 roadmap):

{:evolution-path
 {:phase-1-today "SixOS on Framework (x86-64, Linux)"
  :phase-2-2028  "SixOS + verified utilities (s6 from Grainstore)"
  :phase-3-2032  "SixOS + seL4 kernel (formally verified)"
  :phase-4-2040  "SixOS + RISC-V (open silicon + open OS)"}}

Why SixOS is the right foundation:

Artix is stuck on Arch's traditional model
Void is minimal but lacks declarative power
SixOS can evolve all the way to RISC-V + seL4!

Reason 5: The Grainstore IS SixOS's Future

Our Grainstore work directly benefits SixOS:

# Today: Specify s6 in Nock
grainstore/specs/s6.nock.md ✅

# Tomorrow: Verify Clojure implementation
src/grainstore/s6.clj ✅ (65 tests passing!)

# Next Week: Create Nix overlay
grainstore/overlays/s6-grainstore.nix 🔲

# Next Month: Boot Framework 16 using Grainstore s6
nixos-rebuild switch --flake .#sixos-framework-16 🔲

This work:

Artix/Void can't leverage this - They lack Nix's declarative package management.

Decision: SixOS + Grainstore + Framework 16

Our stack:

Hardware:  Framework 16 (AMD Ryzen 7040, modular, repairable)
OS:        SixOS (NixOS without systemd, declarative)
Init:      s6 (from Grainstore, Nock-specified, verified)
Desktop:   Wayland + Hyprland (AMD optimized)
Apps:      From Grainstore where possible

Why this wins:

This isn't just installing Linux. This is planting seeds for century-scale computing.

Next: Ready to make this real? Essay 9514 shows you:

  1. How to build the Grainstore (s6, runit, Nock specs)
  2. How to build the SixOS ISO (using Babashka!)
  3. How to flash to USB (cross-platform, safe)
  4. How to install on Framework 16 (step-by-step)
  5. How to configure s6 supervision (from the Grainstore!)

Or skip to functional programming (Essay 9520) to continue the main curriculum path.

The seeds are ready. The soil is prepared. Let's plant the garden. 🌱

Navigation:
← Previous: 9512 (Unix Deep) | Phase 1 Index | Next: 9514 (SixOS Framework)

Or Skip to Main Path: 9520 (Functional Programming)

Bridge to Narrative: For the complete sovereignty quest, see 9958-9960 in the Chronicles!

Metadata:

Copyright © 2025 kae3g | Dual-licensed under Apache-2.0 / MIT
Competitive technology in service of clarity and beauty

← back to index