wgjordan

The closer analogy would be fan-translation patches, which are also pretty clearly copyright-infringing derivative works though generally tolerated by rights holders.

Companies often encourage (or at least turn a blind eye to) creative derivative works from fan communities, especially if they're non-commercial and aren't cutting into the market share of their own official products enough for them to take notice.

[1] https://gist.github.com/ossa-ma/f3baa9d25154c33095e22272c631...

The database is eventually consistent by design. For applications that can tolerate eventual consistency across regions, this gives fast local queries everywhere, and services that are resilient to network partitions. A database sitting alone in Virginia gives you slow requests waiting on queries from distant regions, and global downtime if that one load-bearing region goes unavailable for any reason.

The platform does also support persistent volumes (https://kedge.dev/docs/volumes), which is the managed storage API. I've framed it as an escape hatch for those that still need to run a more traditional service with stable members in a fixed region.

It handles multiple writers by capturing changes as logical operations, then resolving conflicts in a globally-deterministic order based on their contents based on a CRDT model.

There are some limitations (see https://github.com/wjordan/syzy/blob/main/sqlite/docs/LIMITA...), mostly around primary keys (they have to be non-NULL) and UNIQUE constraints (there's some subtle differences in behavior between nullable and NOT NULL uniqueness). But in general, the goal is for all of SQLite, DML and DDL, to just work normally!

- Yes, there is a post-restore kernel reseed hook that happens after fork, and just before the trapped listen is continued. It doesn't use the vmgenid driver, it just calls the RNDRESEEDCRNG ioctl, so it would not be compatible with applications that depend on vmgenid notifications to reseed userspace PRNGs.

- In Syzy, the full pruning implementation is deferred for now; at the managed product's current small scale, it can simply eat the tiny overhead costs of un-collected garbage, while the user is only billed for the logical storage space consumed.

> I didn't immediately spot the durability contract for volumes -- local NVMe like Fly, or sitting on some underlying system like EBS?

Persistent volumes use local NVMe that continuously syncs to object storage, so a similar architecture to Fly Sprites. It automatically recovers from host failures (with on-demand lazy restore), and you can manually migrate stable members to another region if needed.

I've positioned persistent volumes as an escape hatch for when you need an existing database app running in a VM, or when performance requirements outgrow the built-in replicated SQLite.

I couldn't help it! Ben Johnson recently wrote a Litestream post touching on this topic [1]:

> multiple-writer distributed SQLite databases are the Lament Configuration and we are not explorers over great vistas of pain

I offer my sincerest apologies if this database release may have inadvertently opened the gates of Hell.

[1] https://fly.io/blog/litestream-writable-vfs/

If you pirated a book for personal use the amount of liability wouldn't match a company whose profit could be attributed to pirating the same book. In US copyright law, a copyright infringer could be liable for "any profits of the infringer that are attributable to the infringement" [1] (if the copyright owner elects to recover actual damages and profits instead of statutory damages).

[1] 17 U.S.C. § 504(b), https://www.law.cornell.edu/uscode/text/17/504

I think the stronger claim is: there is no reason for a single task to require a 1m context window.

Only if money is no object. Cache reads are cheap (10% of uncached input costs) but definitely not free, and cached reads dominate session costs at long context lengths. A prompt at 20k context with $0.01 in cached reads would cost $0.40 in cached reads at 800k context, that quickly adds up for long sessions.

https://bricksandminifigs.com/blog/blog/2026/05/28/bricks-mi...

The argument, as I understand it is that the "theft" is in quotes because it's not literally copyright infringement, but fair use of an old public-domain folk tale that ends up consuming the latter.

Today, when kids know "Aladdin" they know the copyrighted/trademarked Disney character, not the traditional folk tale- that's the "theft" that happened.

https://news.ycombinator.com/item?id=28861204

https://news.ycombinator.com/item?id=48086249

> Our primary and out-of-band network access was down, so we sent engineers onsite to the data centers to have them debug the issue and restart the systems. But this took time, because these facilities are designed with high levels of physical and system security in mind. They’re hard to get into, and once you’re inside, the hardware and routers are designed to be difficult to modify even when you have physical access to them. So it took extra time to activate the secure access protocols needed to get people onsite and able to work on the servers. Only then could we confirm the issue and bring our backbone back online.

There was one (later denied) report that a 'guy with an angle grinder' was involved in gaining access to the server cage.

[1] https://news.ycombinator.com/item?id=28762611

A system that combines both WAL frames with cold-read-optimized grouped pages is another interesting point in the design-space. Tuning the intervals separately could make it work well- frequent WAL-checkpoint uploads, and grouped pages only on higher-level compaction cycles for cold-read optimization on longer-lived objects.

Looking forward to seeing where you head with this!

I've been doing some experiments of my own in a relatively similar space, also focusing on S3/Tigris-backed SQLite on ephemeral compute, also with B-tree aware prefetching (see https://github.com/wjordan/sqlite-prefetch).

I think the idea of storing grouped pages together to optimize read-locality is interesting. Note that it steers in the opposite direction of the temporal locality that a format like LTX/Litestream uses to provide transaction-aware features like point-in time restore. The tradeoff also involves significantly greater write amplification (re-upload the entire page group every time a single page dirties), heavily favoring cold-read-heavy workloads over mixed-write or warm-read workloads.

The query-plan frontrunning is a very novel experiment as well, discovering in advance that SQLite is about to run a full-table scan seems like a very useful optimization hint to work with. I'd love to see experiments validating how much of an improvement that offers compared to simple reactive prefetch (which takes at least a couple page faults to get up to speed).

I could be wrong, but my simple guess is that it's become widespread in LLM-generated websites partly because of Anthropic's own style guides getting adopted through Claude-bundled skills and such.

> Off topic: blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out, so can't be Show HNs. Make a regular submission instead.

> If your work isn't ready for users to try out, please don't do a Show HN. Once it's ready, come back and do it then. Don't post landing pages or fundraisers.

[1] https://news.ycombinator.com/showhn.html

6 weeks of 'oatmeal for breakfast every day' was less effective than 2 days of 'stuff yourself with oatmeal'.

The issue is not that you cited a dozen-paragraph argument, it's that you inlined all the text directly into a series of comments instead of a link to the text on a separate page. It visually overwhelms the discussion thread and is disruptive to the broader discussion, which is not strictly against guidelines but generally seen as non-normative behavior.

[1] https://opensource.google/documentation/reference/using/agpl...

> The AGPL license is suitable for open source projects, while commercial licenses are available for organizations requiring different terms.

I was a bit unclear on where the AGPL's network-interaction clause draws its boundaries- so the commercial license would only be needed for closed-source modifications/forks, or if statically linking ZeroFS crate into a larger proprietary Rust program, is that roughly it?

The actual code being benchmarked is trivial and open-source, but I don't see the actual JuiceFS setup anywhere in the ZeroFS repository. This means the self-published results don't seem to be reproducible by anyone looking to externally validate the stated claims in more detail. Given the very large performance differences, I have a hard time believing it's an actual apples-to-apples production-quality setup. It seems much more likely that some simple tuning is needed to make them more comparable, in which case the takeaway may be that JuiceFS may have more fiddly configuration without well-rounded defaults, not that it's actually hundreds of times slower when properly tuned for the workload.

(That said, I'd love to be wrong and confidently discover that ZeroFS is indeed that much faster!)