HN user
I'm a big fan of persisting almost everything in the primary database. With one exception: I'd immediately use object storage (S3) for files which are large in number or size. Files which are few and small (e.g. templates) are fine in the db.
There was some recent uncertainty about pgBackRest getting discontinued due to lack of funding. But the maintainer secured funding, and pgBackRest development will continue.
An atomic volume snapshot should work for any database that's durable on power failure. Ideally preceded by a checkpoint, to minimize recovery time. Atomicity of the snapshot mechanism is essential to prevent data corruption using this approach.
We used EBS snapshots on AWS for multi-TB MongoDB to get incremental backups that are fast to create and fast to restore (with some performance degradation after restore).
It doesn't support point-in-time recovery, but since it's fast you can create frequent snapshots (e.g. hourly). I'd consider adding this as a secondary backup strategy, even if you use a higher-level postgres-specific backup tool.
I'd avoid using overly opinionated code hosters that capriciously change their ToS to ban content that was allowed before without a very good reason. I'd like my code to survive long after I stop maintaining it, and such changes reduce my trust that a hoster will achieve that.
(This specific change wouldn't affect me, since all the code I published was written without AI)
How do they define "vibe coded"? I believe "vibe coded" was originally defined as letting AI write code without human review. But I often see it used for all AI assisted code.
edit: Looks like they don't talk about "vibe coding" at all, but ban code mostly written by AI:
You must not share projects that mostly consist of code written by "generative AI"-tools
Microsoft could end up being a higher barrier but how much do we really want that?
For drivers installed automatically via Windows Update? Absolutely yes.
For software the user installs manually? No.
Occasionally you have faulty hardware. Most commonly RAM.
The lack of anti-trust enforcement on mergers is really harmful.
Lieferheld taking over pizza.de already lead to rising prices. Merging it with Uber Eats would make the situation even worse.
Autism is a buffet.
When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up.
― C.S. Lewis
If inputs are part of the application bundl3, they can be trusted as much as the code itself.
LLMs seem to get tragically stuck on certain patterns.
That is likely an artifact of the fine-tuning process:
Once a style tic is rewarded, later training can spread or reinforce it elsewhere, especially if those outputs are reused in supervised fine-tuning or preference data.
That creates a feedback loop:
* Some rewarded examples contain a distinctive lexical tic.
* The tic appears more often in rollouts.
* Model-generated rollouts are used for supervised fine-tuning (SFT).
* The model gets even more comfortable producing the tic.
I never understood why kubernetes doesn't use a VM-per-pod model by default.
As of 2026-07-13, Corgi’s promise of a lawsuit against the author for this post has not materialized. Readers are encouraged to draw their own conclusions about Corgi’s choice to try and suppress articles with the use of baseless legal threats.
Did you write in more detail about that threat somewhere?
I don't think pointers (beyond a simple "same as in previous row" marker) will be a huge improvement, since you still get a multiplicative number of rows. And it comes with the cost of keeping all that data in memory. This approach also competes with using cheap compression (e.g. LZ4).
Some kind of "product" operator on the other hand reduces the cost to additive (just like `array_agg`).
That one is tracked here: https://github.com/npgsql/efcore.pg/issues/2633
That issue is only about supporting `array_agg` as a function on tuples, not as an implementation strategy for `Include`s of collections.
I think it's crazy that standard SQL has no clean way of handling nested data. It's might not fit elegantly into the relational model, but it's still a common business problem that should be addressed. At the bare minimum something like `array_agg` should be standardized.
Alternative query languages like EdgeQL show what first class support for nested data (and navigations) could look like, while the data model is still relational.
It has `context.Database.SqlQuery` and `ExecuteSql`.
You'd still return a multiplicative amount of rows, even if those rows contained only a reference. `array_agg` in postgres avoids this, but EF does not support using it for collection navigations.
One could envision a "Cartesian product" operation in the wire protocol, but I'm not convinced that's a good approach.
What EF needs is support for using postgresql's `array_agg` when `Include`ing collections.
Why does PgBouncer need to care about cancellation requests at all? Why can't it just forward the cancellation to postgres, which then responds to the cancelled query with an error instead of a response, and then the bouncer for that connection handles that error?
The moment it does you'll be able to tell because Bitcoin will crash to 0.
The "workaround" for PoW is running the PoW computation on hardware that's better suited for the task. Bitcoin mining has been using ASIC for many years now.
Let's say a legitimate user is willing to wait for one minute on a budget phone. Then your PoW is limited to what that phone can compute in one minute. But on the attacker's specialized hardware this computation only costs fractions of a penny, so they are barely hindered by it.
The SHA256 based PoW scheme has a very heavy ASIC advantage. People have tried to design PoW scheme that minimize the custom hardware advantage, but I'm not sure if they managed to close the gap far enough to make PoW feasible for this application.
How much does routing traffic though residential proxies cost?
I wonder what the "unknown" 25% are.
I like keeping the number of stateful systems minimal, since those are the most annoying from a reliability perspective. In practice I use one database and object storage (S3). If that database is postgres is secondary.
The primary thing it checks for is panics. (bounds|overflow|DBZ) are just examples where Rust panics (for overflows rust doesn't always panic, while Kani always fails).
You aren't testing your application code directly, but writing a test function. That test function can include any assertion you want in the end, which causes a panic, failing the verification. Similarly you want to add assumptions in the test function for pre-conditions, so parameter verification assertions in the application won't fail the verification.
Example from the tutorial:
#[cfg(kani)]
#[kani::proof]
fn verify_success() {
let x: u32 = kani::any();
// estimate_size rejects x >= 4096, so this prevents failure from argument verification panicking
kani::assume(x < 4096);
let y = estimate_size(x);
assert!(y < 10);
}
The limiter itself should be able to ensure consistency via pessimistic row level locking, even at lower isolation levels.
What I don't want is long running unrelated transactions keeping old tuples alive just it case they're needed. My third suggestion where transactions attempting to read old versions fail is probably better than the first two where isolation gets silently downgraded, since it avoid that problem.
I'd love the ability to mark a table as "read committed" to prevent long running transactions from keeping old versions of a tuple alive, or even "read uncommitted" to enable in-place updates. Or perhaps instead of downgrading isolation, those serializable/snapshot transactions could simply fail when reading a value from such a table that was modified after they started.
An example of a table that would benefit from this would be rate-limits / concurrency-limits, which are commonly implemented using Redis instead of Postgres.
In this example I used the hyphen for comedic effect. But this is a actual sentence I wrote in an older post:
What's the competition in the gaming-capable pre-built mini-PC category
That would be pointless, since a consumer always buys a license, not the software itself.
In a snake-eating-its-own-tail irony, a 2023 analysis found that between 33% and 46% of workers on the platform were using large language models to complete their tasks,
I assume AI use by workers has risen to the point where it renders Mechanical Turk pointless.