site: the builds-to-date whitepaper, replacing the day's earlier post
The newest whitepaper is now "The Builds to Date" — the running record of what each kernel build added, what the gates proved, and where the system is. It replaces the addressed-store post as the lead entry on the board, and keeps the first whitepaper untouched as the design record. The index page now reflects the current state: newest build #55 (the region walk, CUBE_OP_RANGE), a region answered as a seek with the measured over-coverage (1.00x aligned, 6.99x unaligned), and 192 workspace tests with 0 failures.
This commit is contained in:
luulu
@@ -0,0 +1,141 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
|
||||
<title>CUBELinux — The Builds to Date · Whitepaper</title>
|
||||
<meta name="description" content="The CUBELinux builds to date: what each kernel build added, what the gates proved, and where we are now — a coordinate is an address, a region is a seek.">
|
||||
<style>
|
||||
:root{
|
||||
--gold:#d8af68; --gold-hi:#fff9b1; --cyan:#39d7ff; --bg:#0c0f14;
|
||||
--panel:#141a22; --panel2:#1b232e; --ink:#e8eaeb; --muted:#8a97a6;
|
||||
--ok:#5ee0a0; --line:#26303c; --warn:#e8a040;
|
||||
}
|
||||
*{box-sizing:border-box}
|
||||
html,body{margin:0;height:100%}
|
||||
body{background:radial-gradient(1200px 600px at 80% -10%, #15212e 0%, var(--bg) 55%);
|
||||
color:var(--ink); font:15px/1.6 -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Helvetica,Arial,sans-serif;}
|
||||
.wrap{max-width:780px;margin:0 auto;padding:18px 16px 48px}
|
||||
header{margin-bottom:18px;border-bottom:1px solid var(--line);padding-bottom:14px}
|
||||
h1{font-size:21px;margin:8px 0 2px;font-weight:700;letter-spacing:.2px}
|
||||
h1 span{color:var(--cyan)}
|
||||
.meta{color:var(--muted);font-size:12px;margin-top:4px}
|
||||
h2{font-size:17px;margin:26px 0 8px;color:var(--gold);font-weight:650}
|
||||
h3{font-size:14px;margin:18px 0 6px;color:var(--ink);text-transform:uppercase;letter-spacing:.06em}
|
||||
p,li{color:var(--ink)}
|
||||
.muted{color:var(--muted)}
|
||||
code,pre{font-family:ui-monospace,SFMono-Regular,Menlo,Consolas,monospace}
|
||||
pre{background:var(--panel);border:1px solid var(--line);border-radius:10px;padding:12px;overflow-x:auto;font-size:12.5px;color:#cfe3ee}
|
||||
table{width:100%;border-collapse:collapse;margin:10px 0;font-size:13.5px}
|
||||
th,td{border-bottom:1px solid var(--line);padding:7px 6px;text-align:left;vertical-align:top}
|
||||
th{color:var(--muted);font-weight:600}
|
||||
.ok{color:var(--ok);font-weight:600}
|
||||
.warn{color:var(--warn);font-weight:600}
|
||||
.pill{display:inline-block;font-size:11px;color:var(--muted);border:1px solid var(--line);border-radius:999px;padding:2px 9px;margin:2px 6px 2px 0}
|
||||
a{color:var(--cyan);text-decoration:none}
|
||||
a:hover{text-decoration:underline}
|
||||
blockquote{border-left:2px solid var(--gold);margin:0;padding:2px 0 2px 14px;color:var(--ink)}
|
||||
footer{margin-top:34px;border-top:1px solid var(--line);padding-top:12px;color:var(--muted);font-size:12.5px}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="wrap">
|
||||
<header>
|
||||
<h1>CUBELinux <span>·</span> The Builds to Date</h1>
|
||||
<div class="meta">Whitepaper · <b>2026-09-22</b> · kernel <b>6.19.3-cubelinux0.6+</b> · newest build <b>#55</b> · follows <a href="cubelinux-final-whitepaper.html">A Coordinate-Addressed OS</a></div>
|
||||
<div>
|
||||
<span class="pill">kernel-resident store</span>
|
||||
<span class="pill">a coordinate is an address</span>
|
||||
<span class="pill">a region is a seek</span>
|
||||
<span class="pill">192 tests · 0 failures</span>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
<h2>Abstract</h2>
|
||||
<p>This is the running record of the CUBELinux builds: what each kernel build added, what the gates proved, and where the system is now. It is written to be read on its own — the first whitepaper documents the design; this one documents the builds.</p>
|
||||
<p>The store now lives in the kernel. A coordinate is no longer only a way to <em>name</em> a record; it is a way to <em>reach</em> one — a lookup is a binary search over arithmetic addresses. And, as of the newest build, a <b>region</b> is a way to <em>query</em> one: a box is found by seeking to the foot of its key span and reading forward, not by scanning the space.</p>
|
||||
<p>Everything claimed below is measured by a gate or by the test suite, and the numbers that are not reproducible by machine are labelled as such.</p>
|
||||
|
||||
<h2>1. Where we are now</h2>
|
||||
<ul>
|
||||
<li>The store is <b>kernel-resident</b>, reached through <code>cube(2)</code> (syscall #548): put, get, delete, sync, the cursor walks (enum / spaces), and now the region walk (range).</li>
|
||||
<li>The image is <b>format v3</b> — a space table, a sorted fixed-stride index, and packed values — so a coordinate is an address and a listing streams from its space's first entry.</li>
|
||||
<li>The <b>live store on the workhorse is sealed</b> at rest and holds <b>69,638 records</b>; the fold that converted it to v3 preserved every record and every value, byte for byte.</li>
|
||||
<li>The workspace test suite is <b>192 tests, 0 failures</b>, and the kernel's own gate wall is green except the one named in §6.</li>
|
||||
</ul>
|
||||
|
||||
<h2>2. What CUBE is, in one paragraph</h2>
|
||||
<p>CUBELinux is a coordinate-addressed operating system. A coordinate is <code>(space, point)</code> — a 32-byte space selector and a 192-bit key produced by a space-filling curve (Morton by default) over three 64-bit axes. Records live at coordinates, not behind names; the space is a hard partition, so cross-space access is structurally impossible from a query. The store is in the kernel, the interface is <code>cube(2)</code>, and everything above it is written against that interface — a name, a path, or a mount is a view at the edge, not the substrate.</p>
|
||||
|
||||
<h2>3. The build line</h2>
|
||||
<p>The builds that changed the system's shape, in order:</p>
|
||||
<table>
|
||||
<tr><th>build</th><th>what it changed</th><th>how it was checked</th></tr>
|
||||
<tr><td>#49</td><td>format v3 — the image carries its own addresses: a space table, a fixed-stride index, values in index order.</td><td>the live store folded to v3 with the digest unchanged</td></tr>
|
||||
<tr><td>#50</td><td>the fold fixed on the box; the live store converted in place, sealed.</td><td>gates run on the box, store walked both ways</td></tr>
|
||||
<tr><td>#52</td><td>the kernel records its own boot — the first write of a boot appends one record in a reserved space.</td><td><code>verify-boot-record</code>, the record read back three ways</td></tr>
|
||||
<tr><td>#53</td><td>the addressing primitives move into one shared file, and the driver uses it — no second copy of the key to drift from.</td><td><code>verify-enum</code>, <code>verify-syscall</code></td></tr>
|
||||
<tr><td>#55</td><td><b>CUBE_OP_RANGE</b> — a region is a seek: the box's key span, binary-searched and read forward.</td><td><code>verify-range</code>, against userspace</td></tr>
|
||||
</table>
|
||||
|
||||
<h2>4. The store and its interface</h2>
|
||||
<pre>[header 46] magic, version, curve, extents, counts
|
||||
[space table: space_count × 48] space | first index | records
|
||||
[index: record_count × 40] key | value offset | value length
|
||||
[values: packed, in index order]</pre>
|
||||
<p>The index is fixed-size and sorted by key, so a reader computes a record's place as <code>index_off + i × INDEX_ENTRY</code>. On the live store this is also <b>smaller</b>: the fold took it from 18,835,712 to <b>17,164,952 bytes</b> with the same <code>fnv1a64</code> digest before and after. The format is described once, in <code>drivers/cube/cube_format.rs</code>, compiled by the kernel and included by userspace — two descriptions of one format is what once shipped an hour of <code>unsupported-version</code>.</p>
|
||||
<p>Through <code>cube(2)</code>, the operations are the verbs the design always named: <code>PUT</code>, <code>GET</code>, <code>DEL</code>, <code>SYNC</code> (fold the log into the image), <code>ENUM</code> and <code>SPACES</code> (bounded cursor walks), and <code>RANGE</code> (the region walk of §5). Each argument block is versioned by its own <code>size</code> field, so the interface grows by gaining a block rather than by being replaced.</p>
|
||||
|
||||
<h2>5. A region is a seek</h2>
|
||||
<p>The operation the address existed for is the <b>region query</b> — the records of a space inside a box — and it has now landed as a seek rather than a filter.</p>
|
||||
<p>The key fact is about the <em>curve</em>, not the query:</p>
|
||||
<blockquote><b>Monotonicity.</b> If <code>p ≤ q</code> on every axis, then <code>key(p) ≤ key(q)</code>.</blockquote>
|
||||
<p>Under it, a box needs no decomposition at all: its two corner keys bound every key inside it, so the index is binary-searched for the foot of that span and read forward to its head — <code>O(log n + span)</code> instead of <code>O(records)</code>. Every candidate is then decoded and tested for membership, because a span is a <em>bound</em>, not the <em>set</em>: keys of points outside the box also fall inside it, and returning them would be wrong.</p>
|
||||
<p>Monotonicity belongs to a curve, not to the trait. Morton and RowMajor have it; <b>Hilbert does not</b> — it transposes and rotates the axes, so its corner keys say nothing about the keys between them, and seeking on them returns wrong answers. The store gates the seek on the curve, and a curve must opt in; it cannot inherit a bound by accident.</p>
|
||||
<p>Measured over a 32,768-record space, asking 512-record questions:</p>
|
||||
<table>
|
||||
<tr><th>curve</th><th>region</th><th>entries examined</th><th>records returned</th><th>over-coverage</th></tr>
|
||||
<tr><td>Morton</td><td>aligned 8³ at the origin</td><td>512</td><td>512</td><td class="ok">1.00×</td></tr>
|
||||
<tr><td>Morton</td><td>the same 512 points, slid to (5,5,5)</td><td>3,578</td><td>512</td><td class="warn">6.99×</td></tr>
|
||||
<tr><td>Hilbert</td><td>aligned 8³ at the origin</td><td>32,768</td><td>512</td><td class="warn">64.00×</td></tr>
|
||||
</table>
|
||||
<p>The 1.00× is exactness worth naming — for an aligned cube at the origin the span <em>is</em> the box's keys. The 6.99× is the honest cost of a bound: an unaligned box's span covers keys of points outside it, and those are examined and rejected. The 64.00× is the gate working — Hilbert has no span, so it walks.</p>
|
||||
<p>In the kernel it ships as <code>CUBE_OP_RANGE</code>, with its own argument block — the box as six numbers, a cursor counting the records <em>in the box</em>, and a buffer. A v3 image seeks its index to the span's foot; a packed image walks with the span stopping it early; the caller is not told which, because the contract is the same. The gate <code>kernel/verify-range.sh</code> boots the kernel and diffs its answer against userspace's over an <b>unaligned</b> box holding a deliberate trap — a record at <code>(2,7,7)</code>, outside the box but inside the span — and the walk is correct only if it examines that record and rejects it. Kernel <b>#55</b>, gate <b>PASS</b>.</p>
|
||||
|
||||
<h2>6. What we tested</h2>
|
||||
<p>The gate wall, and what each gate proves:</p>
|
||||
<table>
|
||||
<tr><th>claim</th><th>gate</th><th>result</th></tr>
|
||||
<tr><td>cube(2) is the same store</td><td><code>verify-syscall</code></td><td class="ok">pass</td></tr>
|
||||
<tr><td>the walk answers in the kernel</td><td><code>verify-enum</code></td><td class="ok">pass</td></tr>
|
||||
<tr><td>a walk costs what it returns</td><td><code>verify-enum-cost</code></td><td class="ok">pass — 1.1× across a 40× store</td></tr>
|
||||
<tr><td>a region is a seek, not a filter</td><td><code>verify-range</code></td><td class="ok">pass</td></tr>
|
||||
<tr><td>the box's own store, walked</td><td><code>verify-enum-live</code></td><td class="ok">pass</td></tr>
|
||||
<tr><td>a client, through the front-end</td><td><code>verify-frontend</code></td><td class="ok">pass</td></tr>
|
||||
<tr><td>a fold writes what userspace holds</td><td><code>verify-kernel-checkpoint</code></td><td class="ok">pass</td></tr>
|
||||
<tr><td>acknowledged writes survive a kill</td><td><code>verify-kernel-append</code></td><td class="ok">pass</td></tr>
|
||||
<tr><td>a torn log entry is discarded</td><td><code>verify-torn-tail</code></td><td class="ok">pass</td></tr>
|
||||
<tr><td>the kernel records its own boot</td><td><code>verify-boot-record</code></td><td class="ok">pass</td></tr>
|
||||
<tr><td>a sealed record is ciphertext</td><td><code>verify-encryption</code> + sealed-read</td><td class="ok">pass</td></tr>
|
||||
<tr><td>the kill switch, against a throwaway vault</td><td><code>verify-kill-switch</code></td><td class="ok">pass</td></tr>
|
||||
<tr><td>the boot chain the box uses</td><td><code>verify-efi-boot</code></td><td class="warn">the one red gate</td></tr>
|
||||
</table>
|
||||
<p class="muted">The workspace suite — the crate tests that underpin all of the above — is <b>192 passed, 0 failed</b>. Three defects the gates exist to catch are worth naming, because each was found only by running the real thing: a walk that stopped at its first batch (a short batch is not the end); an index entry written four bytes short (the value length, against the arithmetic); and a store that could be folded exactly once (the second fold read an addressed image with a packed-only reader). Each is now a fixture or a gate.</p>
|
||||
|
||||
<h2>7. What is still ahead</h2>
|
||||
<p>Said plainly, because a build record that only shows the green is a ledger, not a record:</p>
|
||||
<ul>
|
||||
<li><b>The store is opened per call.</b> Every <code>cube(2)</code> operation pays the store open and the control-block read — on the order of 1.1–1.8 ms — which dominates the cost of a single read. Keeping the store open in the kernel across calls is where those milliseconds are.</li>
|
||||
<li><b>The kill switch is unarmed.</b> It is built and rehearsed against a throwaway vault, but arming it is a deliberate, terminal step that is a person's to take, not an agent's.</li>
|
||||
<li><b>The boot marker is still a userspace write.</b> The kernel records its own boot (build #52) behind a switch, but the deployed marker on the box is still written by a userspace unit through the name tier — "the OS stores itself" is true of the store, not yet of that marker.</li>
|
||||
<li><b>The VFS is not wired, and that is a decision.</b> A mounted filesystem was considered and set aside (<code>DESIGN-cube-interface</code> §2): the native interface is the coordinate, and a POSIX view belongs at the edge, as a FUSE mount, where its <code>readdir</code> is appropriate.</li>
|
||||
<li><b><code>verify-efi-boot</code> is red.</b> The guest cannot load its NVMe modules; the cause is still open, and the box's own boot chain is unaffected.</li>
|
||||
</ul>
|
||||
|
||||
<footer>
|
||||
<div>CUBELinux · The Builds to Date · 2026-09-22 · kernel 6.19.3-cubelinux0.6+ · build #55 · <a href="cubelinux-final-whitepaper.html">the first whitepaper remains, unchanged</a></div>
|
||||
<div style="margin-top:8px"><a href="cubelinux-whitepapers.html">← All whitepapers</a></div>
|
||||
</footer>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
+10
-9
@@ -204,11 +204,11 @@
|
||||
</p>
|
||||
|
||||
<div class="stats">
|
||||
<div class="stat"><div class="num">6.19.3<small>-cube+</small></div><div class="lbl">kernel — built, installed, booted</div></div>
|
||||
<div class="stat"><div class="num">coordinate</div><div class="lbl">root fs — not a directory tree</div></div>
|
||||
<div class="stat"><div class="num">2026-09-21</div><div class="lbl">build + clean reboot verified</div></div>
|
||||
<div class="stat"><div class="num">✓</div><div class="lbl">in-VM round-trip — passed</div></div>
|
||||
<div class="stat"><div class="num">owned</div><div class="lbl">blocks — dedicated region</div></div>
|
||||
<div class="stat"><div class="num">6.19.3<small>-cubelinux0.6+</small></div><div class="lbl">kernel — built to #55, installed, booted</div></div>
|
||||
<div class="stat"><div class="num">coordinate</div><div class="lbl">a record is an address, not a path</div></div>
|
||||
<div class="stat"><div class="num">seek</div><div class="lbl">a region is a seek — <code>CUBE_OP_RANGE</code></div></div>
|
||||
<div class="stat"><div class="num">192</div><div class="lbl">workspace tests — 0 failures</div></div>
|
||||
<div class="stat"><div class="num">69,638</div><div class="lbl">records in the live sealed store</div></div>
|
||||
</div>
|
||||
|
||||
<h2>What's real today</h2>
|
||||
@@ -218,10 +218,11 @@
|
||||
build that passed its verification gate — the details are in the whitepapers.
|
||||
</p>
|
||||
<ul class="claims">
|
||||
<li><strong>A kernel that holds the store.</strong> <code>6.19.3-cubelinux0.6+</code> — build #50, built from this tree, installed, and booted on 2026-09-21 with <code>cube_store=</code> set, where it answered <code>cube(2)</code> (#548) and walked the live store. GRUB's default entry is deliberately an older kernel, so which kernel is running is a question about <em>which boot</em> — check <code>/proc/cmdline</code>. The root fs is ordinary; the <em>store</em> is what is coordinate-addressed.</li>
|
||||
<li><strong>A kernel that holds the store.</strong> <code>6.19.3-cubelinux0.6+</code> — the newest build is #55, which adds the region walk; #50 is what is installed and booted on 2026-09-21 with <code>cube_store=</code> set, where it answered <code>cube(2)</code> (#548) and walked the live store. GRUB's default entry is deliberately an older kernel, so which kernel is running is a question about <em>which boot</em> — check <code>/proc/cmdline</code>. The root fs is ordinary; the <em>store</em> is what is coordinate-addressed.</li>
|
||||
<li><strong>Coordinates are addresses.</strong> The store’s image carries its own index — a space table and a fixed-stride index sorted by key — so a listing costs what it returns rather than what the store holds: listing the same ten records across a store forty times larger measured 5.46 ms → 6.24 ms (1.1×), with a coordinate read at 2.45 ms → 2.17 ms. Measured by <code>kernel/verify-enum-cost.sh</code>, which is in the gate runner.</li>
|
||||
<li><strong>A region is a seek.</strong> Build #55 adds <code>CUBE_OP_RANGE</code>: a box is found by seeking to the foot of its key span and reading forward, not by scanning the space. Over a 32,768-record space the aligned cube is answered at 1.00× over-coverage and the unaligned one at 6.99× — the honest cost of a bound. Gated by <code>kernel/verify-range.sh</code>, which diffs the kernel's answer against userspace's over a box with a trap record inside the span but outside the box.</li>
|
||||
<li><strong>The OS stores itself — of the store, and not yet of the boot record.</strong> The kernel owns the store and every record lives in the same coordinate space it serves. The boot marker is still a userspace write, and still through the name tier, so this half is not done and is not claimed.</li>
|
||||
<li><strong>Verified end to end.</strong> Format, tests, lint, a sustained stress run, crash-recovery replay, and in-VM read-back — all passed. 183 workspace tests, 0 failures; every gate the runner names, with the one red gate (<code>verify-efi-boot.sh</code>) named rather than averaged away.</li>
|
||||
<li><strong>Verified end to end.</strong> Format, tests, lint, a sustained stress run, crash-recovery replay, and in-VM read-back — all passed. 192 workspace tests, 0 failures; every gate the runner names, with the one red gate (<code>verify-efi-boot.sh</code>) named rather than averaged away.</li>
|
||||
<li><strong>Not bolted on.</strong> Coordinates are the system’s native interface: the kernel’s own <code>cube(2)</code>, with no path in it and no translation step between a coordinate and the bytes. POSIX, where it is wanted, is a view at the edge — deliberately not a filesystem in the core.</li>
|
||||
</ul>
|
||||
|
||||
@@ -240,10 +241,10 @@
|
||||
|
||||
<h2>Where it stands</h2>
|
||||
<ol class="road">
|
||||
<li><span class="pkg">01</span><div><strong>Kernel.</strong> 6.19.3-cubelinux0.6+ — the kernel holds the store and answers <code>cube(2)</code> (#548): put, get, del, sync and the cursor walk. Built, installed, and booted with <code>cube_store=</code> set. <em>Done.</em></div></li>
|
||||
<li><span class="pkg">01</span><div><strong>Kernel.</strong> 6.19.3-cubelinux0.6+ — the kernel holds the store and answers <code>cube(2)</code> (#548): put, get, del, sync, the cursor walk, and the region walk (<code>range</code>). Built to #55, installed, and booted with <code>cube_store=</code> set. <em>Done.</em></div></li>
|
||||
<li><span class="pkg">02</span><div><strong>The coordinate layer.</strong> Storage addressed by position, not path — the store's image carries its own index and a coordinate resolves to a place in it. <em>Done & verified.</em> The root filesystem itself is ordinary; addressing the root <em>as</em> coordinates is a separate question and is not claimed.</div></li>
|
||||
<li><span class="pkg">03</span><div><strong>The OS writes itself.</strong> The store the kernel owns holds its records in the same coordinate space it serves to user data. <em>Done in the store.</em> The boot record is still written by a userspace client, through the name tier — so this one is half done and says so.</div></li>
|
||||
<li><span class="pkg">04</span><div><strong>Verification.</strong> Format, tests, lint, stress, crash-recovery, and in-VM read-back all passed — 183 workspace tests, 0 failures, and every gate the runner names except <code>verify-efi-boot.sh</code>, which is red and is named rather than averaged away. <em>Live.</em></div></li>
|
||||
<li><span class="pkg">04</span><div><strong>Verification.</strong> Format, tests, lint, stress, crash-recovery, and in-VM read-back all passed — 192 workspace tests, 0 failures, and every gate the runner names except <code>verify-efi-boot.sh</code>, which is red and is named rather than averaged away. <em>Live.</em></div></li>
|
||||
</ol>
|
||||
|
||||
<p class="closing">
|
||||
|
||||
@@ -74,7 +74,7 @@
|
||||
<header>
|
||||
<div class="logo"></div>
|
||||
<h1>CUBELINUX <span>·</span> Whitepapers</h1>
|
||||
<div class="meta"><b>Four drafts — two posted 2026-08-25, one 2026-09-09, one 2026-09-12.</b> Pick one to read in full — each is a standalone HTML page.</div>
|
||||
<div class="meta"><b>Five drafts — the newest is the build record of 2026-09-22.</b> Pick one to read in full — each is a standalone HTML page.</div>
|
||||
</header>
|
||||
|
||||
<div class="note"><b>About these drafts.</b> The whitepaper documents the design, verified on-disk state, and completed kernel build of the CUBELinux coordinate-addressed OS. The addendum is a separate, clearly-labeled <em>preliminary exploration</em> of how state-spanning neural networks might one day layer on top of the CZYX filesystem — nothing in it is built or committed. The ESP32 integration proposal is likewise a <em>preliminary exploration</em> of carrying the coordinate substrate onto microcontrollers, and is likewise not built. The local-inference note is an <em>architectural observation</em> on an external project, DwarfStar, and where the coordinate model may or may not contribute to it.</div>
|
||||
@@ -83,6 +83,22 @@
|
||||
|
||||
<h2>The drafts</h2>
|
||||
|
||||
<article>
|
||||
<h3>CUBELinux — The Builds to Date</h3>
|
||||
<div class="date">Build record · 2026-09-22</div>
|
||||
<p>The running record of the CUBELinux builds: what each kernel build added, what the gates proved, and where the system is now. The store lives in the kernel; a coordinate is an address (format v3); a region is a seek (<code>CUBE_OP_RANGE</code>, build #55); 192 tests, 0 failures; the live store sealed at 69,638 records. This is the fuller account the day's earlier post was reaching for, with the first whitepaper kept untouched as the design record.</p>
|
||||
<footer>
|
||||
<div class="tags">
|
||||
<span class="pill primary">build record</span>
|
||||
<span class="pill booted">kernel-resident store</span>
|
||||
<span class="pill booted">a region is a seek</span>
|
||||
<span class="pill booted">192 tests green</span>
|
||||
<span class="pill standard">gate-verified</span>
|
||||
</div>
|
||||
<a class="read" href="cubelinux-builds-to-date.html">Read the build record →</a>
|
||||
</footer>
|
||||
</article>
|
||||
|
||||
<article>
|
||||
<h3>CUBELinux — A Coordinate-Addressed OS</h3>
|
||||
<div class="date">Final draft · 2026-08-21 · updated 2026-09-06 with WordFlags + cubetrace + verification pass</div>
|
||||
@@ -147,7 +163,7 @@
|
||||
</article>
|
||||
|
||||
<footer>
|
||||
<p>CUBELinux — Whitepapers · Posted 2026-08-25 · updated 2026-09-12 · <a href="/" style="color:var(--cyan)">Back to CUBELinux.com</a></p>
|
||||
<p>CUBELinux — Whitepapers · Posted 2026-08-25 · updated 2026-09-22 · <a href="/" style="color:var(--cyan)">Back to CUBELinux.com</a></p>
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
|
||||
Reference in New Issue
Block a user