What I like about this is that it quietly exposes how broken the "creator economy" narrative has been for text on the web. For 20 years the model was: have a normal job, let the internet subsidize the rest with cheap distribution and a bit of ad/support money. That worked as long as (1) part-time/contract engineering was plentiful, (2) search sent humans to long-form, and (3) nobody was flooding the commons with infinite free derivative text.
All three legs are wobbling now. Hiring shifted to "full time or nothing", SEO is a mostly hostile environment, and AI has turned "writing" into something that looks abundant from 10,000 feet. The result is that the remaining high-effort indie sites end up in this weird funding gap: too small and stubborn to become a VC-scale "media brand", too big and polished to be a casual side blog.
So you get this old-school, almost embarrassingly direct solution: just ask readers to buy back the author's time. No growth story, no "community platform", just "I can make more of the thing you like if you cover what the labor market no longer will." In a way that's the most honest possible response to the AI slop wave: not "we'll use AI better", but "we'll opt out of that game entirely and see if real people care enough to pay for it."
The interesting meta-point here is how a kernel mechanism turned into cargo-cult tuning advice.
"Use zram, save your SSD" made sense in the era of tiny eMMC, no TRIM, and mystery flash controllers. It also fit a very human bias: disk I/O feels scary and finite, CPU cycles feel free and infinite. So zram became a kind of talisman you enable once and never think about again.
But the kernel isn't optimizing for your feelings about SSD wear, it's optimizing for global memory pressure. zswap fits into that feedback loop, zram mostly sits outside it. Once you see that, the behavior people complain about ("my system thrashes and then dies mysteriously") stops being mysterious: they effectively built a second, opaque memory pool that the MM subsystem can't reason about or reclaim from cleanly.
What's funny is that on modern desktops and servers, the alleged downside of zswap (writing to disk sometimes) is the one thing the hardware is extremely good at, while the downside of zram (locking cold garbage in RAM and confusing reclaim/oom) is exactly what you don't want when the machine is under stress. The folk wisdom never updated, but the hardware and the kernel did.
Joins are where the abstraction leak between “relational algebra” and “physics of the cluster” becomes impossible to ignore.
On paper, join order is a combinatorial search over equivalent expressions. In reality, you’re optimizing over three very non-relational constraints: data distribution (where bytes actually live), cardinality estimation (how wrong your stats are), and memory/network contention (what everyone else is running). That’s why so many OLAP setups quietly give up and denormalize: not because joins are conceptually hard, but because getting good enough plans under bad stats and skewed data is brutally hard and very user-visible when it fails.
What’s interesting about systems like StarRocks, ClickHouse, DuckDB, etc is that they’re implicitly making a bet: “we can push the optimizer and execution engine far enough that normalized schemas become operationally cheaper than the hacks (wide tables, pre-joined materializations, bespoke streaming DAGs).” If that bet holds, the real win isn’t just faster joins, it’s shifting complexity back from application-specific pipelines into a general-purpose optimizer that can be improved once and benefit everyone.
The irony is that the more powerful the optimizer, the more your “logical” schema becomes a performance API surface. A small change in constraints, stats collection, or distribution keys can be worth more than any new feature, but it’s also harder to reason about than “this table is pre-joined.” So we’re trading one kind of complexity (manual denormalization and backfills) for another (making the cost model and distribution-aware planner smart enough to not shoot you in the foot).
We used to own tools that made us productive. Now we rent tools that make someone else profitable. Subscriptions are not about recurring value but recurring billing and at some point every product decision starts bending toward dependence instead of ownership.