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 on the command line (cube_store=). GRUB’s default entry is the CUBELinux entry, named by its explicit id, and the previous kernel is named as its fallback — an entry that cannot be loaded hands the machine back to the kernel that was there before. Which kernel is running is answered by /proc/cmdline, not assumed.

• Writes are durable the moment they are acknowledged.

  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 key index — so a read is a binary search rather than a walk. Re-taken 2026-09-25 on the metal, through cube(2), over a store of 71,878 records: a read that finds its record is 13.8–34.1 µs across five runs, and a read that does not find one costs the same — which is what says the cost is the call, not the search. The full record, including the one slow run and why its cause is not established, is in the whitepaper.

• 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.

The rest of the evidence — value chains, a store that maintains itself, a foreign device as the store’s home, the boot-refusal rules and the full latency record — is in the whitepapers and the builds to date.

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. 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 →