Comment by phboot | Hacker News Reader

Comment by phboot | Hacker News Reader

I’ve been working on a storage system for a long time. Longer than I planned. Longer than was healthy.

It started as “just an allocator experiment.” Then it grew a compression engine. Then repair logic. Then identity. Then tags. Then time slicing. Then a namespace.

At some point I realized I wasn’t building components anymore — I had built the whole substrate.

Not a directory tree. A flat, identity-first namespace with semantic tags, time and generation slicing, CRC defense, extension chains, and deterministic resolution.

No public API. No SDK. It just speaks POSIX now.

I’m releasing the namespace engine today as a public reference implementation. It’s spec-locked, test-covered, and boring in the best way.

There’s no product. No startup. No VC story. Just a filesystem that finally works the way I always wished they did.

I’m tired. But I’m also weirdly calm about it.

If anyone wants to read, criticize, or tell me I reinvented something from 1987 — I’m ready.

The question on everyone’s minds: did Claude write all this prose (the readme has the exact same tone & vibe as the above comment) or was it ChatGPT?

"No X, no X, no X, just Y"

My money’s on ChatGPT. I recognize some of the common phrases it uses.

I think the “find file” section could use some clarification. Unless I missed something, as implemented it’s impossible to list paths within the filesystem (unless the cortex stores the path? It’s not clear from the docs). At a minimum I’m curios about the costs associated with maintaining the cortex - there’s nothing about how the cost of metadata updates which is where the slowdown as disk fills up normally is since you have to do a sorted insertion and/or deletion or otherwise add indirection markers after a binary search.

> The file's metadata in memory is updated to the new version.

Which means this doesn’t work well for lots of (presumably small) files because of the bookkeeping overhead of needing to have all the metadata materialized in RAM? Have you tested how your filesystem scales as the number of files increases and how the RAM usage scales?

Anyway, super interesting ideas. Congrats on achieving something difficult!

I hate to be the first one commenting to say this, but here it goes: the flashy LLM writing style, "Apple Event Dialect" in the README and in this comment is very recognizable and also quite irritating. If this is supposed to be boring then just state the facts and the benchmarks to prove them.

For a comment that goes on about not being flashy, the writing tries it’s very best to be flashy

Is this from LinkedIn?

Sounds familiar.

> No public API. No SDK. It just speaks POSIX now.

Well. No. In order:

It clearly does have a public API, expressed in what I would call an SDK (hn4.h).

And the readme opens with

> The Post-POSIX Filesystem.

and doesn't appear to implement any POSIX that I can see.

Reply on news.ycombinator.com