CUBEdb has just been licensed. PowerButton.io will run its new assistant platform on the CUBE record store…
Assistants that remember everything, and that cannot be talked past what you allow them to see. See PowerButton.io →

The filesystem is dead.
CUBELinux OS stores data by coordinate.

CUBELinux OS is a from-scratch Linux data layer where storage is addressed by coordinate — not by path. No directory tree to walk. No query layer bolted on top. A position resolves directly to bytes, and the database lives in the kernel. Currently being integrated into DULRobotics.com.

What is real today

This is not a concept sketch. The kernel is built, installed, and booted on the workhorse, and it serves the live store: a listing walks the box’s own 96 MiB sealed store through cube(2) and comes back with its records. Every claim here is backed by a build that passed its gate — the running record is the builds to date.

• A kernel that holds the store — and it is the default now. 6.19.3-cubelinux0.7+, build #102, is installed on the workhorse with the store driver compiled in and told which image to serve by the command line (cube_store=). GRUB’s default entry is the CUBELinux entry, named by its explicit id (GRUB_DEFAULT='cubelinux'), and the previous kernel 6.19.3-cube+ is named as its fallback — so an entry that cannot be loaded hands the machine back to the kernel that was there before. What that covers is an entry failing to load, not a kernel that loads and then faults: panic=30 reboots into the same entry, and the way out of that is the boot menu or grub-reboot against the workhorse id. The installer’s copies of the kernels it replaces live in /boot/cubelinux-prev/ rather than beside them: left next to a kernel they are enumerated as boot entries, which is how this menu reached 27 entries for 17 real ones. Which kernel is running is still answered by /proc/cmdline rather than assumed.
• One value, several records — and the kernel puts them together. A value too big for one record is written as a chain: slices at consecutive z, each carrying its place in the chain. A read asks the first slice’s coordinate, the way a caller who does not know it holds a chain would ask, and gets the whole value back joined, in order, with START|END to say it is whole. A slice inside that chain still answers as a slice; a chain with a hole fails the whole read rather than handing back the prefix that is still there. Gated by kernel/verify-chain.sh — seven checks — and reading those bits at all was measured before it was assumed: no record in the live store carries any of them.
• The live store, walked by the kernel. verify-enum-live runs on the box and walks the real store through cube(2): 12 spaces, and every record cubecli can see in the image is present in the kernel’s answer. The walk ends on the contract’s own rule — a cursor that stops moving — rather than by being cut off.
• Writes that are durable, and visible immediately. A write is acknowledged once it is durable in the log, not once the image is rewritten: the store’s on-disk generation advances, and the very next listing contains the record — 6,164 records, one write, 6,165.
• Coordinates are addresses, and a read costs microseconds. The image carries its own index — a space table and a fixed-stride index sorted by key — so a read is a binary search rather than a walk. Re-taken 2026-09-25 on the metal, on the kernel now running, through cube(2): a read that finds its record is 13.8–34.1 µs across five runs (best 11.5 µs, worst 55–107 µs) over a store of 71,878 records, and a read that does not find one costs the same as one that does — 14.1 µs against 13.8 µs in the same run — which is what says the cost is the call rather than the search. The figure this card carried was 11 µs, and that now reads as the best case rather than the mean: it reproduces (11.5 µs best-of-500 here) but not as an average. One run measured 202.8 µs mean, worst 400.9 µs, and that is recorded rather than dropped: I tested the two obvious causes and both came out flat — the write-ahead log was empty (log used=0) and dropping the page cache changed nothing (30.7 µs cold against 34.1 µs warm). So the cause is not established, and a tool that can re-take this is now in the tree (store-latency, in-process, through cube(2), and it verifies it left the store as it found it). A durable write is 4.12–4.28 ms mean (4.94 ms worst) over the runs above, against the 4.962 ms (worst 5.652 ms) this card carried — measured on the metal after #86 folded the write’s two fsyncs into one, down from 60–131 ms once the write path stopped reading the whole device to append seventy bytes. Both are gated by kernel/verify-enum-cost.sh, which now fails on a worst case and a ceiling — a read over 5 ms, a write over 50 ms — where its only bound before was 250 ms on a read. One caveat beside the number: the gate's own milliseconds are a virtual disk's, roughly forty times the box's, so the ratios are what it is for.
• A region is a seek. 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 kernel/verify-range.sh, which diffs the kernel’s answer against userspace’s over a box with a trap record inside the span but outside the box.
• The store maintains itself. The log that makes a write cheap is folded into the image on a daily timer, so the image is rewritten on a schedule rather than waiting on somebody remembering to do it — and a fold writes the slot that is not in use and then flips the control block, so it is safe to interrupt. It is also what keeps a deletion — and it did not: a fold sorted a removal behind the classed record it removed, so a deleted record could come back from the fold with its old value (fixed 2026-09-25, and gated by verify-fold-delete, which writes a classed record precisely because an unsealed store hides it).
• A walk with no store behind it refuses, and says why. The defect that hung the first benchmark boot served about two hundred thousand invented records a minute, forever: a refusal inside the driver was reaching its caller as a success, and the one walk arm that advances its own cursor turned that into a loop with no end signal. Fixed at the cause — every error return in the store driver was negating an error code that is already negative — and bounded where it could loop. Measured in the guest: cube_store=/dev/null cubelinux.enum=1 now answers 0 records, prints walk: spaces failed: Invalid argument, and lets the boot finish in 5 s, where it used to serve 364,994 invented record lines in the 90 s the instrument allowed it. Gated by verify-no-store, which is new and tests both shapes of “no store” — a device that cannot be read, and a store device that is not there at all.
• An acknowledged write is durable — in both shapes a store takes. A write is acknowledged once its entry is in the log and flushed. The two shapes differ in who carries the flush: a store with a control block ends the append with the count write, whose fsync carries the entry beside it; a store without one has no count to write, so the entry carries its own. That second half was missing, and the gate that asks the question — four writes, then SIGKILL with no shutdown at all — was how it was found: the writes were acknowledged and gone. Fixed in #96, and the gate now runs its crash check over both shapes.
• A store can live on a device that is not this machine — and the device has a name. A USB dongle carries a CUBE store of its own: four records written through cube(2) into it were walked back off the device by a later boot, after the machine that wrote them was gone. The device is an entity rather than a path: its own space id (0xF9 ‖ SHA-256(serial)), an identity record in it, and a portal that says how to enter it. Gated by verify-dongle, which finds the device by its serial and refuses one that is mounted or carries a filesystem.
• Verified end to end, with nothing left red. 218 workspace tests, 0 failures, and every gate the runner names — including verify-efi-boot, which was the last red one and passes as of 2026-09-23. Where something is not proven, the record says so rather than rounding it up.
• Not bolted on. Coordinates are the system’s native interface: the kernel’s own cube(2), 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. The root filesystem on this machine is ordinary; it is the store that is coordinate-addressed, and that difference is stated rather than blurred.

What this is for

CUBELinux is a data layer where the database is the kernel and every record is addressed the same way — by where it lives in coordinate space, not by what directory it happens to sit in. That changes what a system can be: the OS and its data are one thing, addressed one way.

• For machines that move. Robotics is where a data layer is tested hardest: a control loop bounds latency in a way a data workload never does, and it is the constraint that re-weights every other priority. That is the integration this is being built into — DULRobotics.com.
• For builders of data-intensive systems. If your workload spends its time walking trees, joining paths, or stitching a query layer on top of storage, the coordinate model removes that layer entirely.
• For anyone tired of the filesystem being a hack. Directories, paths, inodes, mountpoints — all of it is history when a position in space resolves directly to bytes.
• For the people who want to read the math. The whitepapers carry the full technical story — the coordinate model, the curve, the VFS shim, the crate architecture, the verification numbers. This page is the front door; those are the floor.

Where it stands

1. 01
   Kernel. 6.19.3-cubelinux0.7+ — the kernel holds the store and answers cube(2) (#548): put, get, del, sync, the cursor walks (enum, spaces), the region seek (range), and retrieval by class (flagscan). Build #102 is installed and is what the default entry boots: the fixes of 2026-09-23 come with it, and the two of 2026-09-25 are in it — the doorway, and a fold that keeps a deletion. Done.
2. 02
   The coordinate layer. Storage addressed by position, not path — the image carries its own index, in format v4 so a record's class travels with it, and a coordinate resolves to a place in it. The live store is sealed, 71,586 records measured on 2026-09-25, and the kernel walks it end to end on the box. Done & verified. The root filesystem itself is ordinary; addressing the root as coordinates is a separate question and is not claimed.
3. 03
   Durability and upkeep. A write is acknowledged when it is durable in the log, survives a kill, and is visible to the very next listing — on both shapes a store takes (with a control block, and without); a torn tail is discarded rather than replayed; and the log is folded into the image on a daily timer instead of by hand. Done & verified.
4. 04
   Verification. 218 workspace tests, 0 failures, and every gate the runner names — 30 of them, and the wall run for #102 reports none red. Both new gates of 2026-09-23 are on it: the walk with no store (verify-no-store) and the store on removable media (verify-dongle). Live.
5. 05
   The write’s durability is settled — one fsync, where a control block can carry it, and one of its own where it cannot. A durable write is 4.962 ms on the metal, and the single sync is what halved it; the shape that had no flush at all on its append path is fixed rather than traded away. Group commit is how a future workload amortizes the remaining sync across a batch — an optimization now, not a debt. Closed.
6. 06
   Next. The doorway is enforced now (2026-09-25), and what is not claimed is that everything goes through it: Portal::reaches asks both halves — standing on the near mouth and arriving in the space the caller named — and a Session with execute_gated refuses a cross-space command before the store is touched, over the daemon and the front-end as well as the CLI. It is userspace’s check, so a caller talking to cube(2) directly is not gated by it, and no agent path has been scoped with it yet. Kernel event capture is built too (2026-09-25). The substrate was already there — every record carries a 16-bit class, the ops to write and retrieve by class are in the kernel and gated, and the vocabulary those bits belong to is a userspace convention — and what was missing was a kernel that captures events rather than only writing what a caller asked for. It now writes records about itself into the events space (0xFB): a request the interface does not offer, refused and classed ERROR; a clock correction that made the boot record’s epoch provisional, classed BOOT; and a boot whose record only landed on a retry, classed ERROR|BOOT — which is the one that matters most, because that defect’s effect was invisible in the store. They are findable by class with CUBE_OP_FLAG_SCAN and readable like any other record, and the kernel’s writing about itself is bounded (32 events a boot, 8 refusals among them): a kernel that appends a record per event can turn a storm of refusals into a storm of writes, which is the failure this store has already met once from the other side. Still not claimed: the capture rides the same cube_boot_record=1 switch, and the classes the kernel writes are the ones it spells out itself — only those three events exist, and a store that cannot be read at all is the one refusal it cannot record into itself. The metal numbers have been re-taken on the kernel now running (see the card above): the durable write reproduces and is slightly better than #87’s, the read reproduces as a best case rather than a mean, and one run’s 202.8 µs outlier is recorded with its cause unestablished. And the realtime constraint that DULRobotics.com imposes is what re-weights the rest: a control loop bounds latency in a way a data workload never does. Named rather than implied.

This is not a proposal. This is a running prototype — and the OS is being built on it. CUBELinux OS is the idea that data shouldn't live in a system. The system should be the data.
Register for build updates →