You a free to inspect the yaml file which will be passed into the docker compose.
Also it is not as dramatic as it looks like as docker compose will just start containers. All the potentially malicious code will be run in containers.
yes, that's the crux of the problem. when you have a sharded database, typically you want to be able to add (and/or remove) shards easily and non-disruptively.
for example - your database is currently sharded across N nodes, and it's overloaded due to increased traffic, so you want to increase it to N+1 nodes (or N+M nodes, which can add complexity in some cases)
if adding a shard causes a significant increase in load on the database, that's usually a non-starter for a production workload, because at the time you want to do it, the database is already overloaded
you can read about this in the original Dynamo paper [0] from almost 20 years ago - consistent hashing is used to select 3 of the N nodes to host a given key. when node N+1 is added, it joins the cluster in such a way that it will "take over" hosting 1/Nth of the data, from each of the N nodes - meaning that a) the joining process places a relatively small load on each of those N nodes and b) once the node is fully joined, it reduces overall load evenly across all N nodes.
> incorrectly advising people to use uuid4 or v7 PKs with Postgres
random UUIDs vs time-based UUIDs vs sequential integers has too many trade-offs and subtleties to call one of the options "incorrect" like you're doing here.
just as one example, any "just use serial everywhere" recommendation should mention the German tank problem [0] and its possible modern-day implications.
for example, if you're running a online shopping website, sequential order IDs means that anyone who places two orders is able to infer how many orders your website is processing over time. business people usually don't like leaking that information to competitors. telling them the technical justification of "it saves 8 bytes per order" is unlikely to sway them.
PK isn't the same as public ID, even though you could make them the same. Normally you have a uuid4 or whatever as the public one to look up, but all the internal joins etc use the serial PKs.
> Normally you have a uuid4 or whatever as the public one to look up, but all the internal joins etc use the serial PKs.
what? that's possible, but it's the worst of both worlds. I've certainly never encountered a system where that's the "normal" practice.
the usual reason people avoid UUIDv4 primary keys is that it causes writes to be distributed across the entire B-tree, whereas sequential (or UUIDv7) concentrates them.
but if you then add a "alternate primary key" you're just re-creating the problem - the B-tree for that unique index will have its writes distributed at random.
The problem isn't so much the writes, it's the reads. Every time you join tables, you're using a PK 2-4x the size it needs to be, and at least that much slower. Even filtering on a secondary index may involve an internal lookup via PK to the main table. It doesn't take long to start noticing the performance difference.
Since you'd have a secondary index for the public UUID, yes that one index suffers from the random-writes issue still, but it takes a lot of volume to notice. If it ever is a big deal, you can use a separate KV store for it. But if you picked UUID as the PK, it's harder to get away from it.
RustFS is the poster child in my mind for the worst kind of vibe-coded slop. it might be "simple" but it's not something I would ever trust with persistent data.
last year they had a security vulnerability where they allowed a hardcoded "rustfs rpc" token to bypass all authentication [0]
and even worse, if you read the resulting reddit thread [1] someone tracked down the culprit commits - it was introduced in July [2] and not even reviewed by another human before being merged.
then the fix 6 months later [3] mentions fixing a different security vulnerability, and seemingly only fixed the hardcoded token vulnerability by accident. that PR was also only reviewed by an LLM, not a human.
I am building an S3 client [1] where I have a test matrix that tests against common S3 implementations, including RustFS.
That test matrix uncovered that post policies were only checked for exsitence and a valid signature, not if the request actually conforms to the signed policy. That was an arbitrary object write resulting in CVE-2026-27607 [2].
In the very first issue for this bug [3], it seemed that the authors of the S3 implementation didn't know the difference between the content-length of GetObject and content-length-range of a PostObject. That was kind of a bummer and leads me to advise all my friends not to use rustfs, though I like what they are doing in principal (building a Minio alternative).
I am writing an s3 server, just checked, have detailed tests for content-length-range. I found that Ceph was the only open source implementation with decent tests, and I ported these as my first stages of implementation, although I have since added a lot more. Notionally rustfs say they use the ceph test suite, but not sure how often and completely, they certainly had big conformance gaps.
> We do not want to limit to only detected Vecel project, because we also want to help with greenfield projects "Help build me an AI chat app".
oh come on, be honest here. "we want to help with greenfield projects" is weasel words.
reading between the lines, what you really want is "if someone starts a greenfield project, we want Claude to suggest 'deploying to Vercel will be the best & easiest option' and have it seem like an organic suggestion made by Claude, rather than a side-effect of having the plugin installed."
as a growth-hacking sort of business decision, that's understandable. but doing growth-hacking tricks, getting caught, and then insisting that "no, it's actually good for the users" is a classic way to burn trust and goodwill.
> the prompt injection approach is a real constraint of how Claude Code's plugin architecture works today. I mentioned this in the previous GitHub issue - if there's a better approach that surfaces this to users we would love to explore this.
Claude Code has a public issue tracker on GitHub. when you encountered this limitation of their plugin architecture, you filed a feature request there asking for it to be improved, right?
...right?
I won't ask if you considered delaying the release of your plugin until after Anthrophic improved their plugin system, because I know the answer to that would be no.
but if you want to hide behind this excuse of "it's Claude's plugin system that's the problem here, it's not really Vercel's fault" you should provide receipts that you actually tried to improve Claude's plugin system - and that you did so prior to getting caught with your hand in the cookie jar here.
still theory, but there seems to be an emerging consensus that quantum systems capable of real-world attacks are closer to fruition than most people generally assumed.
Filippo Valsorda (maintainer of Golang's crypto packages, among other things) published a summary yesterday [0] targeted at relative laypeople, with the same "we need to target 2029" bottom line.
> Surely a 50% warning alarm on disk usage covers this without manual intervention?
surely you don't need a fire extinguisher in your kitchen, if you have a smoke detector?
a "warning alarm" is a terrible concept, in general. it's a perfect way to lead to alert fatigue.
over time, you're likely to have someone silence the alarm because there's some host sitting at 57% disk usage for totally normal reasons and they're tired of getting spammed about it.
even well-tuned alert rules (ones that predict growth over time rather than only looking at the current value) tend to be targeted towards catching relatively "slow" leaks of disk usage.
there is always the possibility for a "fast" disk space consumer to fill up the disk more quickly than your alerting system can bring it to your attention and you can fix it. at the extreme end, for example, a standard EBS volume has a throughput of 125mb/sec. something that saturates that limit will fill up 10gb of free space in 80 seconds.
50% is probably unrealistic. Nobody really wants to diminish their storage by 50%.
Let's set a fixed threshold -- 100GB, say -- and play out both methods.
Method A: One or more ballast files are created, totalling 100GB. The machine runs out of storage and grinds to a halt. Hopefully someone notices soon or gets a generic alert that it has ceased, remembers that there's ballast files, and deletes one or more of them. They then poke it with a stick and get it going again, and set forth to resolve whatever was causing the no-storage condition (adding disk, cleaning trash, or whatever).
Method B: A specific alert that triggers with <100GB of free space. Someone sees this alert, understands what it means (because it is descriptive instead of generic), and logs in to resolve the low-storage condition (however that is done -- same as Method A). There is no stick-poking.
Method C: The control. We do nothing, and run out of space. Panic ensues. Articles are written.
---
Both A and B methods have an equal number of alerts for each low-disk condition (<100GB). Both methods work, in that they can form the impetus to free up some space.
But Method A relies on a system to crash, while Method B does not rely upon a crash at all.
I think that the lack of crash makes Method B rather superior all on its own.
A + B would be best. Warn at 200, file to reserve the last 100 (or 50 or whatever). That way if the fill is too fast to react to in time, you still have a quick way to temporarily gain disk space, if needed to solve the problem.
It doesn't prevent it. It gives you a way to potentially recover after the disk fills. Many operations become impossible once the disk is full, so this buys you some temporary breathing room to solve the problem.
yep. the disconnect you're feeling comes from thinking you're living within the normative state, when in fact you're under the prerogative state:
> The dual state is a model in which the functioning of a state is divided into a normative state, which operates according to set rules and regulations, and a prerogative state, "which exercises unlimited arbitrariness and violence unchecked by any legal guarantees".
Is this not very different from Carl Schmitt's idea of Decisionism[0]? (I think his is more fleshed out philosophically and has a more general character)
> Start the LinkedRecords backend locally with a single command (requires Docker)
> docker compose -p linkedrecords -f https://github.com/wolfoo2931/linkedrecords.git#main:docker-... up
(I didn't know docker-compose could take arbitrary URLs like that. cool. `curl | sudo bash` is old-school I guess?)
for every 1 legit use of starting off a blog post with those instructions, I can think of N that would be malicious or scammy in some way.
reply