SQL/PGQ (Property Graph Queries) is part of the SQL standard as of 2023. I found this project months ago _because_ they included PGQ in their name, I was searching for PGQ implementations.
Not by name, sure, but it does mention that you're going to be reading the same context into the second model. It specifically refutes your point that you're only reading the smaller plan:
> Opus reads base.py, signing.py, the test file (twenty cards of gray), then writes its plan and leaves. And what's the first thing Flash does with that beautiful document? It re-reads base.py and the test file, because a plan is not a file and you cannot edit prose. The gray reads just keep stacking, first at Opus prices, then again at Flash prices. There is no version of this where a second reader is the cost optimization.
Linked your own project with an "All rights reserved" license? The only thing my company will allow me to do with that software is have AI steal it </s>
We don't have any client-side telemetry. Conversations with Poolside models are stored, but you can use any ACP agent with pool. And we have plans to open-source it eventually.
I'm not really sure memcached optimizes for operational simplicity. The only time I've run it at scale, it would have low cpu utilization then unexpectedly hit lock contention and fall over without warning.
I also like having long, pointed conversations with LLMs as I review code. Then when I'm done, it's different code, and it has all of my blind spots and knowledge gaps, so I cannot effectively review it anymore.
It's like turning a code review that requests you, into a code review that requests someone else. And it tramples on the original author quite a bit too. It's hard only having the ability to add incremental value to large amounts of code, instead of large amounts of value to incremental code.
> Imagine a big codebase with this somewhere in it:
fn processThing(thing: Thing) void {
// this function must always be invoked on
// a thing that has already been started
assert(thing.is_started);
// ...
}
I know you mentioned fuzzing earlier in the article but seriously, fuzzing deserves an extra mention after asking me to imagine that.
Eh, it's worse than that. The GP comment is repeating a joke derived from an Onion headline about gun control. Where the very poignant message is about political will to make change. However, the npm ecosystem is very much willing and has already made several changes. If we're going to engage in discussion instead of meme-posting, the GP should have (imo) included real commentary _in addition to_ the meme they really wanted to post. What is the policy they want? Why do they see the NPM ecosystem as still resistant to change?
One easy change would be that before any package can be published, it has to wait a minimum of two weeks in a state where it can be reviewed but it can't be installed without jumping through several hoops with big warning signs, things like "INSTALL_INTENTIONALLY_DANGEROUS_PACKAGES_THAT_WILL_BREAK_MY_COMPUTER=1", selecting yes in a dialogue that asks if they want to install software that likely has viruses, and pointing to a different package repository URL.
If there's some change that must get out sooner, then there can be some fee to pay to npm to have their security team do their own review.
Critically, there must be time for someone to review before it's the default to be selected.
I'm sure there are issues with this, this was off my head, but it seems like a really easy step to at least stem the problem for now. And there are a bunch of ideas like this that would help, but NPM doesn't seem willing to take it seriously as an existential threat to the ecosystem, rather than taking trivial steps.
> Critically, there must be time for someone to review
By who? No one at npm is reviewing anything. "Someone" is doing a lot of work here.
Linux distributions have trusted maintainers who are responsible for their packages. People who cared enough to figure out PGP and set up an actual web of trust. That's where the verification happens. All these programming language package managers have nothing of the sort. PyPI, Rubygems, crates, npm, it doesn't matter. I can just make an account and push whatever I want.
These package managers are like this because that's what developers actually want. They don't want to deal with Linux distribution maintainers in order to get their software into the official repositories. They want to just run $packager push and have it out there with zero friction.
As discussed elsewhere in this forum, these exploits are being found by security companies in the first few days after they're published, that's just already too late. For example, the auditor who made the very post that we're discussing! For another, many security-focused AI companies have automated checks on NPM packages. Many people are implementing it on their end by having their client wait seven days before pulling new packages, but that's O(N) rather than O(1), and it's not evenly spread.
If no one reviews it and it still gets out, then we can address it then, but that seems much less likely.
Ideally, the solution is that all of these language package managers need to get serious and have maintainers, but lacking that, at least having the waiting period be built into the server instead of the client is a clear win.
They didn't back up their meme with real commentary because they have no real commentary to stand on:
They're spreading cheap disdain & scorn for npm ("only package manager" framing). But most other package management systems have similar abilities to run pretty un-sandboxed code.
I've been oncall for a different G service that nearly paged on every error. It used the standard error budget tooling, but on hundreds of user buckets because the engineering around locality-specific configuration was... suspect. Many of these buckets had single-digits user. If a user was on their phone and lost signal, I was paged. Very poor oncall experience.
People are quick to point out that induced demand exists - especially people that aren't fond of change.
Very broadly speaking, people mis-estimate effect sizes in economics by orders of magnitude. Induced demand is just their foothold to claim an effect exists, before they go about claiming the effect size they want to see.
How would induced demand work for housing? I understand it for say transit use or car travel or like Facebook visits, but when there's twice as much housing do I... buy another home? Buying extra houses as "an investment" in a culture that is hell bent on depreciating my investment by building more housing is one of those "r/WallStBets" crazy plays, if I'm wrong I will lose my shirt and everybody will laugh at me.
Also, even if that were a problem, which seems dubious, you can regulate it. Massive tax hikes for second and subsequent homes are a thing in some places.
I love induced demand. I'm going to use it to get rich - buy up some abandoned town somewhere, and then pay to run a 100 lane superhighway to it; induced demand means the town will fill up instantly and be hugely valuable!
It doesn’t work unless there is currently repressed demand for living in that abandoned town because not enough housing or other factors.
No one is complaining about a housing shortage today in buffalo which used to have twice as much housing stock as it does today, because the demand simply isn’t there now.
Exactly - induced demand is just a misnomer/misunderstanding. "Pent-up demand" would be a much better way to explain it - but that would reveal that at some point the demand ceases; even SF has some limit - once all 12 billion people live there, demand will level off.
Good analogy. I've always considered induced demand a bit of a fantasy.
New businesses the sprout up that market themselves certainly induce a bit of demand, but more lanes and stoplights doesn't exactly motivate people to want to go somewhere.
reply