HN user
I'd expect that sampling would happen in software. Probably the hardware system would output a vector of probabilities over the tokenspace, just as the nets do when run in software.
I don't know though and am not aware of any docs going into detail here. That being said, sampling is really cheap. So implementing it in hardware wouldn't be worth it.
Maybe the MEA brokers still are. But don't if you live in the west.
There is likely thousands of such SQL concatenations throughout the codebase. The issue with traditional SAST tools is that they can't readon about context.
I do, as a matter of fact.
Of course it is. It just no longer exists.
Kimi calling itself claude means nothing. During pre-training, when the model learns to "simulate" the internet text, it will naturally be fed with a bunch of data about Claude and ChatGPT. With the amount of LLM outputs on the internet today, it is not surprising at all that a model would naturally call itself Claude or ChatGPT. You can mitigate that in post-training (or actually in pre-training as well) by training on many examples of what the model should call itself. That being said, getting probably hundreds pf thousands of ChatGPT and Claude examples totally "pirged" out of the weights is going to be difficult and really more hassle than its worth.
Publishing publicly then applying cooldowns in projects is much easier tgan establishing a new standard for pre-release security testing versions that works across ecosystems and gains zooling support.
Apache AGE seems like a good way to have the battle testedness of Postgres with a more fluent query language. I have only used AGE in smaller projects so far however.
Of course it isn't. localStorage is used for SPAs.
localStorage is very much fine and arguably superior to cookies for authentication tokens. First of all, once you have achieved JS execution on a target origin, you can send requests, open up malicious "login" prompts and generally control everything the user sees and does. The article mentions this, but plays it down with no good arguments.
Much more importantly however, is that the cookie standards are a mess! The complexity of cookie default behaviour, their flags, scopes, differences in their SOP (cookies ignore ports for example, so https://example.com:443 and https://example.com:8443 share their cookies) are huge. Research papers have been written in this. And don't even get started on differentials between browsing engines.
This huge complexity of cookies opens up a whole class of authentication attacks where bad (or just weirdly) configured cookies can be stolen cross origin.
localStorage on the other hand is practically impossible to get wrong.
My university does that, it works quite well. The devices net-boot either into a locked down exam OS or regular Debian, depending on the current need.
You can never guarantee that the codepath of a dependency that is vulnerable can not be reached or used as a gadget in an exploit chain. Patching dependencies, even when no direct vulnerability arises is an essential part of defense in depth and sevurity hygene.
How is this different from say BiFrost?
This reads to me mostly like the MCP server has many bugs, rather than inherent model weaknesses.
This blog post is very misleading.
So what would a secure implementation of this feature look like? The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.
First of all, its not CORS that protects. CORS is an anti-security feature. What does protect is the SOP (same origin policy). The SOP (or SOPs rather, it's not really one feature but more of a paradigm in the standards) blocks documents from one origin, from reading data that belongs to another origin. This is the reason why `let w = window.open("https://example.com"); console.dir(w.document.body);` will work when it is ran from example.com, but not wikipedia.org. Only when protocol, host and port match, can documents access each others data (there is an interesting differential with cookies here, their SOP only looks at protocol and host, not port).
Importantly, the SOP only blocks reading data from other origins, not writing! So while example.com won't be able to read the response of a post request it sends to wikipedia.org, the request is sent and processed nontheless!
CORS now is a feature that allows sites to loosen up the SOP. This allows documents to read cross origin data nontheless. Namely, HTTP responses. (Standards for reading other kinds of data cross origin exist, but are not related to CORS).
No, it's exactly the other way around. The SOP protects you from these security issues. CORS is a feature that can be used to loosen up the SOP, to allow more complex inter-application behaviour.
Algorithms are also improving. I believe it's very unlikely for these two improvements together to not result in one to two orders of magnitude cheaper cost per "intelligence". Of course, that might just make use cases that are too expensive today viable and thereby increase usage further.
LLMs don't tend to help much when solving challenges beyond their skill level. Either they one-shot a challenge, or thei are almost useless as a companion for them.
It is a hard requirement. Once you reach higher levels of challenges you spend most of your time reading through RFCs, web sepcs, Github issues, mailing lists, papers, random bugtrackers and library/framework code. There is no way to create a whitelist for that. Besides, a firewall won't stop good hackers.
Which indications are that?
It is definetly cheaper now. What I want to say with this, is that token costs rising so dramatically that AI usage becomes uneconomical is not a high probability future. Even if AI subscriptions were sold heavily below cost (which is also unlikely, after R&D).
Self hosting at a reasonable scale is much cheaper than people think. I am running clusters of DGX Spark machines with BiFrost load balancers in our company and for client projects. They work flawlessly!
128 GB unified memory, Nvidia chip and ARM CPU for just around 3k€ net. They easily push ~400 input and ~100 output tokens per second per device on say gpt-oss-120b. With two devices in a cluster, thats enough performance for >20 concurrent RAG users or >3 "AI augmented" developers.
And they don't even pull that much power.
The party is called the "Christian Democratic Party" but in practice pushes no christian policies. 47% of germans are legally atheists. Only 5% regularly visit mass.
He has changed his opinion completely. Yes, the ratio has turned.
Only Stripe offers a service doing international VAT for you.
vLLM isn't suitable for people running LLMs side-by-side with regular applications on their PC. It is very good at hosting LLMs for production on dedicated servers. For the prod usecase ollama/llamacpp are practically useless (but that's ok - it's not the projects goal to be).
Northdata [1] does basically this, but mostly ingests European data currently. Perhaps they will expand to ingest US data as well at some point. Not affiliated with them in any way. I just use them to look into company structures every now and again.
Do you plan on adding more models in the future? I would love to see how other OSS modles like Gemma, GPT-OSS and Qwen fare.
A lot of comments here are dismissing this post because the relevant code was isolated. But thats the exact same thing Anthropic did with Mythos! They describe their (very lean) harness in the Anthropic Red Mythos blog post. The harness first assigns each file in the given codebase an importance value. Then points claude code at the cpdebase with a prompt stating that it should focus on that file. It spawns a claude code instances for each file in the codebase.
So no, the fact that the posters isolated the relevant code does not invalidate their findings.
There are quite a few such startups already out there. Results are mixed so far. Though I believe they get much better over the coming months and years.