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 #85, boots 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. Which kernel is running is still answered by /proc/cmdline rather than assumed.
• 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: 4 µs on the box, the mean of 200 reads against the live store of 70,406 records, worst 11 µs, and it does not get more expensive when the store does. A durable write is 8.2 ms, 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.
• Verified end to end, with nothing left red. 206 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 #85 is installed and booted on the workhorse, serving the live store. 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, ~69,700 records, 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; 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.
4. 04
   Verification. 206 workspace tests, 0 failures, and every gate the runner names — including the boot-chain gate that was the last red one, which passes as of 2026-09-23. Live.
5. 05
   Next. A durable write is 8.2 ms and almost all of it is two fsyncs to ext4 — the entry, then the count that acknowledges it. That order is the durability contract, written down deliberately, so collapsing it is a decision rather than a fix — and a decision with a measured price: one pwrite+fsync is 4.321 ms, append's shape of two is 8.630 ms, and the whole kernel put is 8.202 ms, so the write is fsyncs and almost nothing else and a single one would put a durable write at about 4.3 ms. Group commit is the alternative that keeps the contract. Everything else in the latency budget is closed and measured: a read is 4 µs, the read state is held in the kernel across calls, and the unfolded log is capped at 256 KiB so per-call work has a ceiling. The kernel also authors its own boot record here, verified three ways on the box, with its epoch as the one honest gap: the clock arrives stale from a night powered off, so the first record carries a time 40 s early. 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. In progress, and 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 →