6,885 karma · joined March 26, 2017
Your comment reads like the response of someone who is struggling to understand a concept.
Nobody made that claim. That's the strawman you chose to argue against instead.
Decades from now, git will be looked back at in a similar but worse version of the way SQL often is -- a terrible interface over a wonderful idea.
What technology? Can you link to some evidence?
Well this is wrong. And it's exactly this type of thinking why people will get absolutely burned by this.
First off the fact they chose obvious exploits for explanatory purposes doesn't mean this attack only supports obvious exploits...
And to your second point of "review the code before you deploy to prod", the second attack did not involve deploying any code to prod. It involved an LLM reading a reddit comment or github comment and immediately executing.
People not taking security seriously and waving it off as trivial is what's gonna make this such a terrible problem.
If you're arguing that "Read-Eval-Print cycle" doesn't count as REPL, then it pretty strongly undercuts your argument that "dialog approach" is.
And 1964 predates APL implementation.
While I have enjoyed learning array languages, and think they are still underrated, Wikipedia seems to disagree with this statement above.
According to wikiepdia, REPL seems to have been coined after Iverson created his notation, but before the first APL was ever written.
https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93prin...
Except the majority of people in the US at least aren't healthy. So why are we elevating that question to be something that should be discussed nightly when it doesn't affect most people (as shown by death rates by cause)?
That's still a specific choice with wide ranging implications. Not saying we should or shouldn't report on it, but saying your question has pretty deeply ground assumptions on "importance". And it is not a given.
"I'm on their site so I'm on their team... Of course I back everything they do, I'm on their team."
Similarly (and slightly related) when a big part of your motivation is to see the "other" side upset you've lost the plot.
These aren't tests if a user can si their job or knows their tools. This is a cultural purity test to see if they have the same quirks as OP. And is a terrible way to judge if someone will perform.
And I've worked at a place where the imperative code was crap. Should we abandon all imperative code because I had that experience?
People can write bad code in any paradigm - that's not what decides how we should code.
Nobody says we should throw away all imperative code because of one poorly implemented code base. But for some reason I see that targeted at FP all the time.
Based on everything that has gone one that seems to me at least very naive. There was practically a textbook length document outlining what the administrstion planned to do if they got in power and they are going step by step through it.
The president said there are 4 comedians (who make fun of him) that he wants to get off the air. After this event he posted something along the lines of "2 down, 2 to go." Followed by "Why don't you just force the other two out now?".
There was nothing wrong about what was said - they just already have a plan and pick any small item to claim is the cause.
For example they want to defund left leaning non profits and think tanks. They don't have a reason to. But now they are trying to claim they motivated the Kirk killing - not because they think it did, but because it's what is already their plan.
People still thinking they are being objectives or that there are "norms" left, in my opinion haven't been paying attention.
Regulatory capture here on HN is turning into a meaningless phrase. Whenever a business does something wrong, rather than actually say what's wrong someone just claims it's regulatory capture. It's turned into it's own thought terminating cliche.
Say what the issue is, don't just blame an assumed regulatory capture. In this case state that it's insufficient regulation of the meat processing industry, infrequent inspections of processing plants, or understaffed agencies.
Say what the issues were, not a nebulous "regulatory capture" claim.
Businesses lobby to get FDA regulations weakened - state that's the problem, not a vague "regulatory capture" phase.
Maybe not as long as uuids, but long enough to be comfortable they won't conflict withing your table/db.
Those will merge fine as two separate "rows".
No the don't. You're making a straw man rather than trying to put forth an actual argument in support of your view.
If you feel can't support your point, then don't try to make it.
They are the single closest thing we've ever had to objective evaluation on if an engineering practice is better or worse. Simply because just about every single engineering practice that I see that makes coding agents work well also makes humans work well.
And so many of these circular debates and other best practices (TDD, static typing, keeping todo lists, working in smaller pieces, testing independently before testing together, clearly defined codebase practices, ...) have all been settled in my mind.
The most controversial take, and the one I dislike but may reluctantly have to agree with is "Is it better for a business to use a popular language less suited for the task than a less popular language more suited for it." While obviously it's a sliding scale, coding agents clearly weight in on one side of this debate... as little as I like seeing it.
Logs are point in time, spans are a duration. Logs are flat, spans have a hierarchy.
It's the difference between logging a message in a function, and logging the beginning and end of a function while noting the specific instance of the fn caller.
If you have many threads or callers to the same function that difference is critical in tracing causality of failures or any other type of action of note.
Any citations for this pretty strong assertion? And please don't reply with "oh you can just tell by feel".
What's the point of this anecdote? That it's not omniscient? Nobody is should be thinking that it is.
I can ask it how many coins I have in my pocket and I bet you it won't know that either.
The model is simple and LLM agent js a user. Another user on the machine. And given the context it is working it, it is given permissions. Ex. It has read/write permissions under this folder of source code, but read only permissions for this other.
Those permissions vary by context. The LLM Agent working on one coding project would be given different permissions than if it were working on a different project on the same machine.
The permissions are an intersection or subset of the user's permissions that is is running on behalf of. Permissions fall into 3 categories. Allow, Deny and Ask - where it will ask an accountable user if it is allowed to do something. (Ie ask the user on who's behalf it is running if it can perform action x).
The problem is that OSes (and apps and data) generally aren't fine grained enough in their permissions, and will need to become so. It's not that an LLM can or can't use git, it should only be allowed to use specific git commands. Git needs to be designed this way, along with many more things.
As a result we get apps trying to re-create this model in user land and using a hodge-podge of regexes and things to do so.
The workflow is: similar to sudo I launch and app as my LLM Agent user. It inherits its default permissions. I give it a context to work in, it is granted and/or denied permissions due to being in that context.
I make requests and it works on my behalf doing what I permit it to do, and it never can do more than what I'm allowed to do.
Instead now every agentic app needs to rebuild this workflow or risk rogue agents. It needs to be an OS service.
The hacky stepping stone in betwern is to create a temporary user per agent context/usage. Grant that user perms and communicate only over IPC / network to the local LLM running as this user. Though you'll be spinning up and deleting a lot of user accounts in the process.
You sure it's not asking if bullets made spears obsolete"?
The other suggestions ignored seemed to be "if this is about security, then fund the OSS, project. Or swap to a newer safer library, or pull it into the JS sandbox and ensure support is maintained." Which were all mostly ignored.
And "if this is about adoption then listen to the constant community request to update the the newer XSLT 3.0 which has been out for years and world have much higher adoption due to tons of QoL improvements including handling JSON."
And the argument presented, which i don't know (but seems reasonable to me), is that XSLT supports the open web. Google tried to kill it a decade ago, the community pushed back and stopped it. So Google's plan was to refuse to do anything to support it, ignore community requests for simple improvements, try to make it wither then use that as justification for killing it at a later point.
Forcing this through when almost all feedback is against it seems to support that to me. Especially with XSLT suddenly/recebtly gaining a lot of popularity and it seems like they are trying to kill it before they have an open competitor in the web.