HackerLangs
トップ新着トレンドコメント過去質問紹介求人

setr

5,515 カルマ登録 12 年前
[email protected]

コメント

setr
·一昨日·議論
For these agentic AI systems, like a human operator, the LLM needs to have a wide variety of operations available to it, gated by permissions and authentication. They should be calling APIs. They should be making DB queries with RLS. The reasoning model is to identify which APIs to use when and in which order… not to execute arbitrary code in prod. The same expected of a human screwing around with prod.

Leaking private repos is occurring not because an LLM is involved, but because the LLM isn’t being required to forward the authentication requirement from the user, and engaging the APIs with that limited permission sets. And it would be just as useful having had that limitation in place

The LLM is currently running around like a level 1 tech support holding admin creds, and you’re just hoping they doesn’t do anything stupid with them by giving them a bunch instructions on what not to do.

I think prompt injection vs sql injection is actually not far off — both are the direct results of blindly trusting user input for no particular reason and entirely unnecessarily, with a system that has far more power than it needs to do the task it was meant to do. It also has the same incorrect “solution” given out — sanitize your inputs — instead of correcting the problem at the source (why is an agent for repo X able to read repo Y in the first place?)

Prompt injection in the non-agentic scenario — like getting an LLM to answer questions from its training you don’t want it answering — is inevitable and unavoidable. But things like TFA, deleting prod, etc are well within reach
setr
·9 日前·議論
The smell is 50% the asset packs available in the respective stores. The other 50% is the default character controllers and the default lighting settings
setr
·18 日前·議論
The issue I find with this pattern in docs/tutorials is that the prefix makes it very obvious which functions are from this library.

It's particularly worthwhile when looking at the bigger examples that might involve another library, or stdlib functions/libs I haven't dealt with before
setr
·22 日前·議論
Wait

TFA is like 90% a copy of whatever the PDF is on this website. It just prefixes it with a small story
setr
·26 日前·議論
Both are hosted by nature.com though...
setr
·27 日前·議論
> It takes just as much work to delete a row as it takes to insert a row. Why wouldn't it? Obviously you have to do almost all the same operations: write a log, write the deletion, update indices, replicate it, etc.

It takes far more work to delete/update than insert. My recent example is updating ~2TB of text data was about 40x slower than inserting 12TB (was trying to correct some large text truncation that occurred during migration into PG, ended up being faster to redo).
setr
·27 日前·議論
Apparently AI models have gotten decent at geoguessr... Might be worth a shot?

https://news.ycombinator.com/item?id=43724935
setr
·28 日前·議論
If my understanding is correct, the use of palantir by creatures leads to their own downfall, both for evil and good characters. So following through, it's very useful for it to be in evil hands
setr
·先月·議論
honestly I dont want plan hinting so much as being able to ban table-scanning / nested loops / etc on specific tables, and be able to set that independent of actual table-size so I can coerce its failure in dev environments
setr
·先月·議論
> literally save like 20 seconds in some cases because 1 HUGE query becomes 8 straightforward ones with maximum index usage.

I don’t understand how splitting a query up would have any relationship to index utilization; the planner should trivially pick up on it?

Also are you sure you’re not solving a different problem[0]? Doing joins manually being faster doesn’t smell right, except in the case of data duplication increasing total resultset size substantially

Like the cost of increased network load from not filtering through the join should outweigh anything else in the equation

https://learn.microsoft.com/en-us/ef/core/querying/single-sp...
setr
·先月·議論
> I covered that in my talk, which will be eventually published on YouTube.

Any idea how I get myself notified once it’s up? Or a YT account to poll
setr
·先月·議論
> This is because taking up 100% of the CPU effectively captures 100% of RAM

Isn’t that only true though specifically at 100% CPU utilization?

If it were at 90% CPU, then you have no RAM capture, and then you can’t say anything about whether 80 or 800MB should be taken; it’s only a freebie if and only if literally no other program can do work on the machine.

I don’t see how you can map X% CPU utilization to Y% RAM capture.

Like a program could be network heavy, CPU light and mmaps a large file? Or streaming a file from disk with a constant memory allocation, but doing heavy nonstop CPU work.

The CPU / RAM capture ratio would be wildly different; the ideal for your program, while other competing programs of unknown behaviors exist, I don’t see any way for hotspot to approximate
setr
·先月·議論
If you take out ordering, then lookups on your SoA are now a search, and n-field lookup on an entity is now a JOIN operation.

The smarter you get about it, the closer you get to an OLAP db

Which leads to my theory… I feel like Bevy could be implemented on top of an in-memory DuckDB and get away with it
setr
·先月·議論
It’s a good abstraction layer, and a fundamentally good/effecient model of organization and data management. It’s a horrible language, has a meaningless standards doc, some of the worst debugging tooling of modern system and generally any tooling outside of the RDBMS engine itself is 20 years stale.

The only difficult part in arguing this is that RDBMS != SQL != RelationalAlgebra, and it’s very often forgotten
setr
·先月·議論
If a manufacturer is unwilling to guarantee/monitor the lack of sesame in their food, and you having a presumably severe sesame allergy… isn’t it correct not to be eating that food?

Like previously you trusted their lack of sesame based on vibes, which you probably shouldn’t have been doing, and now they’re explicitly telling you not to trust them on this; this seems to me strictly better. You’ve lost a choice that never really existed in the first place

An actually unintended consequence would be if they introduced sesame because they were going to have to put the label on it anyways
setr
·先月·議論
The truly correct answer is give the player a mild damage aura/aoe and let the mobs die at your feet on their own. Running away breaks an annoying amount of mechanics, like ingredient farming.

The power fantasy just needs them to die trivially. So just do that.
setr
·先月·議論
If you’re a shareholder in 5 companies, each owning 2 parcels of land, each with their own PoA, and you yourself hold land — then you have “influence” into 6 votes, though only direct ownership of 1 vote
setr
·2 か月前·議論
Not liking it and having the conceit to replace it (and more importantly, shove your replacement into prod) are entirely different actions. The first is always legal. The second is more often questionable than not
setr
·2 か月前·議論
Given that they already made the billion dollar mistake, I find their handling for nulls the best possible thing they could do at this point. I’d hardly call it crazy — rather, it’s exceedingly pragmatic.
setr
·2 か月前·議論
I mean, they have to explicitly unpack the error and then choose to do nothing with it. It requires roughly the same amount of code to do the same with discarding an exception.

Except with a Result type the fact that an exception can occur and should be handled in the first place is explicit.

The problem if anything is that you MUST say something about the error case, despite the common scenario being “pass it forward” — the same reason exception do this by default. Which is also why rust for example special cases Result with the ? operator to do exactly that