wgjordan

As such, if you pirated a book and had to pay $3000 for that one instance, I don't think you'd like it if I said you should have paid $30K or $300K instead.

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

Your 'with 1m context window' implied that some manually-curated task 'chunks' would overflow smaller context windows (eg 200-400k tokens). If you're instead curating chunks small enough to avoid getting burned on long-context cache-read costs, you're not using a 1m context window at all. At that point, compaction is a convenience over manually chunking and clearing context for fine-grained bits of work.

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

With 1m context window there is no reason for a single task to require compaction

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.

Looks like a more detailed followup statement was just posted today:

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

That's a perfectly cromulent meaning of the word.

https://en.wikipedia.org/wiki/Aladdin

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.

Don't miss related HN threads from the original authors:

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

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

A real example, from Facebook's 2021 outage [1]:

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

https://blog.davidv.dev/posts/minimizing-linux-boot-times/

Thanks for the extra details, the frontrun benchmark numbers seem compelling for various cold-read use cases.

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!

Nice set of experiments! I appreciate that you're running benchmarks on real object storage setups to validate rapid design variations. (Meta-note: I love how agents have recently made this kind of experimental-research work possible with much less human time investment.)

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

Anthropic uses it across all their websites, here's a typical example where the effect is obvious as you scroll down: https://claude.com/solutions/agents

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.

Sounds like a promising idea, but a blog post with bits of implementation code is not a "Show HN", there's nothing to try out here. See the guideline [1]:

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

Yeah, the article showed that the high-dose intervention (modeled after von Noorden's famous century-old 'oat cure') is most effective. A large bowl of oatmeal (100g) all 3 meals for 2 days, 6 large bowls total.

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

It's well known that an oatmeal diet lowers cholesterol (the article itself cites a 1907 'oat cure' in its intro). The new finding here is insight into the exact mechanism- a short-term, high-dose oatmeal diet (300g/day for two days) had significantly greater LDL-lowering effect than a medium-term, moderate-dose oatmeal diet (80g/day for six weeks), and they associated the difference with increases in several plasma phenolic compounds triggered by specific changes in the gut microbiome.

It's like a dozen paragraphs, forming one complete argument. Is this too much material to take in all at once, in this brave new TLDR tomorrow?

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.

Also worth noting (as a sibling comment pointed out) that despite these assurances the untested legal risks of AGPL-licensed code may still cause difficulties for larger, risk-averse companies. Google notably has a blanket policy [1] banning all AGPL code entirely as "the risks outweigh the benefits", so large organizations are probably another area where the commercial license comes into play.

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

This clarification is helpful, thanks! The README currently implies a slightly different take, perhaps it could be made more clear that it's suitable for use unmodified in closed source products:

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 benchmark suite is trivial and opensource.

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!)

For a proper comparison, also significant to note that JuiceFS is Apache-2.0 licensed while ZeroFS is dual AGPL-3.0/commercial licensed, significantly limiting the latter's ability to be easily adopted outside of open source projects.

Related, "The Design & Implementation of Sprites" [1] (also currently on the front page) mentioned JuiceFS in its stack:

The Sprite storage stack is organized around the JuiceFS model (in fact, we currently use a very hacked-up JuiceFS, with a rewritten SQLite metadata backend). It works by splitting storage into data (“chunks”) and metadata (a map of where the “chunks” are). Data chunks live on object stores; metadata lives in fast local storage. In our case, that metadata store is kept durable with Litestream. Nothing depends on local storage.

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

Please follow the HN guidelines [1]:

When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

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

Very helpful hearing about your own similar experiments with CRDTs. As a followup I'd be interested in more direct comparison between Marmot and Corrosion in terms of features/performance, since they both serve a similar use case and Corrosion seems to have worked through some of the CRDT issues you mentioned.

Related, Corrosion has experimental support for the pgsql wire protocol (limited to sqlite-flavored SQL queries): https://superfly.github.io/corrosion/api/pg.html

SST has not been AWS-specific since Aug 2024 [1], it is now based on Pulumi/Terraform instead of CDK/CloudFormation.

[1] https://sst.dev/blog/sst-v3

See also a rebuttal of sorts [1] from Brett Glass, the sole programmer singled out by name in phk's essay:

Poul-Henning's assertion that all such ideas should be dismissed as "bikeshedding" reflects this dismissive attitude, which can be just as damaging to a software project as taking too many suggestions (or accepting bad ones). At the time of the discussion I mention above, internal squabbles drove several talented programmers from the project, and I was discouraged from becoming more deeply involved in it. FreeBSD was falling behind Linux in features and in popularity. While it has now caught up in terms of technology, it remains an underdog. This is, in part, due to the developers' dismissal as "bikeshedding" of good ideas that Linux adopted much earlier.

[1] http://bikeshed.info/

I think the biggest missing piece in the opposing accounts of this incident is how exactly the production-access removal was communicated. There's a huge gap between how the two posts are framing the clarity of the communications that happened on Sept 18:

September 18 2025 18:40 UTC: Ruby Central notifies Mr. Arko, via email, of the board’s decision to remove his RubyGems.org production access, and the termination of his on-call services.

Marty Haught sent an email to the team within minutes, at 12:47pm PDT [19:47 UTC?], saying he was (direct quote) “terribly sorry” and “I messed up”. [...] the complete silence from Shan and the board, made it impossible to tell exactly who had been authorized to take what actions. As this situation occurred, I was the primary on-call.

André also mentioned that he disclosed further remaining production access a few days ago, on Oct 5. Looking forward to Ruby Central's followup post-incident review for this subsequent incident, which they failed to address or mention at all in their initial publication.

It's a legal requirement for most US non-profits to file public and accurate accounting of their funds and expenses, Ruby Together is no exception and all the info is publicly available [1].

Having previously worked as a software engineer at an ed-tech non-profit, I found nothing nefarious or unusual in Andre receiving compensation for his work or in the anecdotes around expensing business-related technology purchases or meals to his employer, this is all standard industry practice.

[1] https://projects.propublica.org/nonprofits/organizations/473...

As a non-profit, the exact amount that Ruby Together paid Andre was publicly disclosed in its annual tax filings [1]:

2015: $29,250

2016: $43,988

2017: $48,143

2018: $51,058

2019: $60,000

2020: $32,693

2021: $21,420

The filings also note that "The entire board of directors reviews and approves (by vote) compensation for the CEO."

[1] https://projects.propublica.org/nonprofits/organizations/473...

The problem is not that Searls has opinions, it's that this petty hit piece against Andre was heavily wrapped in neutral, 'all I can do is offer a little bit of context', 'I'm not rushing to take sides' framing language, resulting in a disingenuous, passive-aggressive tone.

Why is Justin dredging up that one time eight years ago when Andre mistakenly called out a repo for infringing upon his employer's work (for which he publicly apologized five hours later)? Why is he harping on anecdotes from nine years ago in order to suggest Andre may have allegedly (gasp) expensed technology purchases and business meals to his employer? What does this all have to do with the current situation, other than unnecessarily stir the pot with a laundry list of old petty grievances fed to him by a bunch of anonymous contacts ('a lot of different people told me a lot of concerning stories')?

I think the author's close ties to Rails Core / Shopify employees is extremely important context for this post, especially since it's context that's been intentionally hidden by a neutral, unbiased framing.