> Today we have a huge oversupply of scientists, however there's too many of them to allow judging for potential, and many are not actually capable of dramatic impact.
This is a fairly sweeping anti-science statement without any supporting evidence to back it up. Fairly typical of the HN anti-public research hive mind sadly.
Intel SGX Fuse Key0, a.k.a. Root Provisioning Key Extracted by Researchers
Plundervolt: Software-Based Fault Injection Attacks Against Intel SGX
SGX-Bomb: Locking Down the Processor via Rowhammer Attack
Foreshadow: Extracting the Keys to the Intel SGX Kingdom
ÆPIC Leak: SGX, Intel’s data fortress, has been breached yet again
Intel SGX defeated yet again–this time thanks to on-chip power meter
SGAxe and Crosstalk: Plundering of crypto keys from ultrasecure SGX
Spectre Attack on SGX PoC
Pretty incoherent article. Not sure what point they are trying to make about the threat model of SGX. SGX was/is a groundbreaking attempt to solve a very difficult problem IMO. TEEs are still an active area of research that has benefited massively from the availability of an actual implementation in mainstream processors. And most other CPU manufacturers are also offering their own flavour of TEE, many of which have learned lessons from SGX.
The point about the threat model of SGX is that insulating an enclave with it does nothing to protect the code actually handling the data from the enclave.
It really does not even protect against firmware side attacks. For that, TPM attestation is just as good.
At some point, somewhere, data processed by the SGX enclave has to pass through the usual VTd or such. Unless SGX enclave is used to feed data directly into hardware, in which case the weak point is the firmware and bus instead.
If it ensured no side channel attacks, it would be useful for some operations. But it does not therefore it isn't.
SGX is very useful. Source: I built a product that made it easier to use and we explored a lot of use cases as part of that.
Firstly yes SGX is designed to block firmware attacks. That's a part of the threat model indeed.
Secondly, you can't feed data from SGX enclaves directly to hardware devices. It's encrypted data in, encrypted data out. Of course, data must pass through the untrusted host OS and hypervisor, but that is no problem, it's how it's designed to work. That's why the clients of the enclave handshake with it using remote attestation.
You can block side channel attacks with SGX if you are careful. The enclave transitions do clear uarch state in the ways needed, the rest is app-level stuff (but it has to be).
I used to see a lot of confusion about stuff like SGX because some people don't realize it's only intended to be used with remote attestation. If you don't have a smart client that's remotely attesting the enclave over a network, it isn't going to get you anything. That requires changes to app architectures.
It was touted as making cloud computing secure. How anyone could actually believe this is beyond me. The cloud provider has physical access to the host machine. For all I know it could all be smokes and mirrors, emulated on a C64, while all my data is getting exfiltrated. The only people who ever bought into this is cryptobro crackheads and government contractors doing it for compliance bullshit. Up to 0% of cloud customers went as far as to even try to verify the thing does what it says it does.
Case in point: TeleMessage. Supposedly E2E-Encrypted message archival turns out to be a plain text database on some servers. Surprised Pikachu face.
This is some tinfoilhat stuff. An extreme suggestion that a cloud provider would physically open up machines and exfiltrate the keys so that they could then read the memory of a customer workload, for what reason? Remember that hardware is virtualised and makes it difficult to pin point which server is running what. Not using such tech makes it easier for the cloud provider to inspect memory so that is not a better approach.
If you argue that you can trust the cloud provider not to be malicious, you also just argued that you don't need SGX at all. No tinfoil hat required.
And yes, not using that tech is not a better approach then, but not worse either. But better in the way that Intel doesn't need to build convoluted shit into their cpus that might actually worsen security through exploits.
Ages and ages ago I was an EE turned programmer and everyone was hyping JUnit at the time. I had a customer ask for it on a project so fine I'll learn it. I kept thinking it was stupid because in my mind it barely did anything. But then I got it: it did barely do anything, but it did things you'd commonly need to do for testing and it did them in a somewhat standardized way that kept you from having to roll your own every time. Suddenly it didn't feel so stupid.
This article was written a few weeks after MCP was released and touches on why MCP is important. While I guess you could argue that technically there's nothing to it, protocols such as MCP is addressing a missing need to standardize interactions between your ai app and another service. Code needs to now be written for users, devs (apis), and ai.
HTTP was never an extraordinarily different protocol, there was really nothing to it from a technical perspective. What was important was it wrapped up a lot of the concepts from the various hypertext and linking protocols that existed into a standard that was widely supported. The standard and the compatibility across servers and clients made it important. This is generally true for protocols across the board. In fact very few standards protocols are particularly revolutionary from a technical perspective. That’s in many ways very much not the point.
I don't think that this is a fair comparison. HTTP actually has a specification that you need to follow if you need the web to _work_ (or at least, look good). MCP and others on the other hand are just you explaining to the LLM how you want it to format its responses.
MCP is barely worth being called a protocol; LLMs are now smart enough to follow instructions however you give them. When I played around with creating my own tool-using agent, I specified the tools in YAML, and asked it to use custom tags to 'call' them. It worked just fine.
More critically, there's nothing stopping the LLM from _not_ obeying whatever it is you give it, especially as the context fills up and/or the user trying to break it, except its own training. There is no proper HTTP server that would give you invalid responses 'just because'. Yeah, you could wrap the agent in a function that calls it again and again if the response isn't properly formatted with whatever formatting error happened, but I don't think any sane person would call that 'following the protocol', as the only entity it makes happy is whoever you're buying tokens from.
> MCP and others on the other hand are just you explaining to the LLM how you want it to format its responses.
There's a little bit more to MCP than that. Arguably the most useful part of MCP is more on the (MCP) server side, in regards to discoverability of tools. Having a standard protocol for listing tools, resources and prompts means all you need is the endpoint where the server is located, and you can just get the tool list in a couple of lines of code, pass it to the LLM and then invoke the tool(s) without hand-rolling a bunch of code.
This is probably more useful if you think in terms of using MCP tool servers written by other people. If you're only using your own stuff, then sure, you only write your own interface code once. But if you want to use tools provided by others, having a standard is handy (albeit certainly not required).
I like the way @01100011 phrased it in his analogy with Junit:
"I kept thinking it was stupid because in my mind it
barely did anything. But then I got it: it did barely
do anything, but it did things you'd commonly need to do
for testing and it did them in a somewhat standardized
way that kept you from having to roll your own every
time.".
It's all 'clever prompting' all the way down. 'Chain of thought', excuse me, 'reasoning', 'agents'. It's all just prompt scaffolding and language models.
There is no way this ends the way the salespeople are saying it will. Indexing over a compressed space and doing search is not the future of computation.
You can (theoretically) constrain LLM output with a formal grammar. This works on the next token selection step and not just another prompt hack. You could also (theoretically) have a standard way to prompt an LLM API with formal grammar constraints.
That would be a very useful feature.
MCP is not that, MCP is completely unnecessary bullshit.
The first part of this comment is great, but can you please avoid name-calling in the sense that the HN guidelines use the term?
"When disagreeing, please reply to the argument instead of calling names. 'That is idiotic; 1 + 1 is 2, not 3' can be shortened to '1 + 1 is 2, not 3." - https://news.ycombinator.com/newsguidelines.html
Your comment would be just fine without that last bit—and better still if you had replaced it with a good explanation of how MCP is not that.
Can you elaborate a bit more on "theoretical" formal grammars and constraints that would allow the LLM to use a search engine or git commands and produce the next tokens that take the results into account?
Here are some practical, non-theoretical projects based on a boring and imperfect standard (MCP) that provide LLMs capabilities to use many tools and APIs in the right situation: https://github.com/modelcontextprotocol/servers
An LLM doesn't "use" anything. Your agent does that. The agent is the program that prompts the LLM and reads the response. (The agent typically runs locally on your device, the LLM is typically on a server somewhere and accessed through an API.)
For the agent to parse an LLM's reply properly you'd ideally want the LLM to give a response that adheres to a standard format. Hence grammars.
I'm guessing your confusion stems from the fact that you've only ever used LLM's in a chat box on a website. This is OpenAI's business model, but not how LLM's will be used when the technology eventually matures.
The Web was freely available, while Gopher was licensed, making it less accessible and competitive
As usual, open beats closed! TimBL actually is on video discussing how CERN didnt care to make money off the protocol, and it was lucky that they let it be freeee.
I wonder if it's just our egos talking, telling us that for something to have value within this technical sphere it has to be complex and 'hard won'?
I see this agent stuff as a pretty basic agreement wrapped up in the vernacular of a protocol, i.e. "we'll put this stuff in the 'role' prop on our JSON", and then everyone else knows where to look for it. It's not especially important what we decide, as long as we create shared expectations.
I used to think protocols and RFCs and other products of standards bodies were the juicy 'big boy table' of tech, but then I realised: ok, it's not so complex–and perhaps doesn't itch my engineering itch–, but SOMEONE needs to take responsibility for deciding the protocol, otherwise it's just a bunch of randoms making up interfaces 1:1 with other parties and no useful tooling emerging for a long time. Best to beat it to the punch and just figure out a 'good enough' approach so we can all get on and make cool stuff.
Addendum: I will say, however, that the AI space has a particularly unhealthy attraction to naming, coining, forming myriad acronyms and otherwise confusing what should be a very simple thing by wrapping it up in a whitepaper and saying LOOK MA LOOK!
Well.. autodiff isn't particularly technically sophisticated. But I doubt that when it was first invented in the 1950s, people could have foreseen that a lot of autodiff put together can write an implementation of autodiff.
If you're interested in more technical approaches, I think they're starting to come together, slowly. I've seen several research directions (operads / cellular sheaves for a theory of multiagent collaboration, the theory of open games for compositional forwards/backwards strategy/planning in open environments) that would fit in quite nicely. And to some extent, the earliest frameworks are going to be naive implementations of these directions.
Even worse is that virtually no one in this space even recognizes the fairly rich research into “agents” throughout the history of computer science.
Mention John Holland’s work in adaptive systems, Hewitt’s actor model or even Minsky’s “Society of the Mind” and you’ll be met with blank stares.
I do believe LLMs have the potential to make these older ideas relevant again and potentially create something amazing, but sadly the ignorant hype makes it virtually impossible to have intelligent conversations about these possibilities.
If you know more than others, that's great, but in that case please share some of what you know, so the rest of us can learn. Just putting others down doesn't help.
Hewitt's actors are arguably the earliest version of "agents" out there. But about one out of every 17,000 techbros running around claiming to be an AI expert today has even heard of actors. Much less Society of Mind, or any of the pioneering work on Agents that came out of the Stanford KSL[1] or UMBC (remember "AgentWeb"[2]?).
And don't even mention KQML, FIPA, DAML+OIL, or KIF, or AgentSpeak, or JADE...
Nah, all joking aside, no problem. I think it's relatively rare for me to be that way, but I'm human like everybody. And certain "hot button" issues can occasionally set me off. Too late to change this, but I'll try to keep that in mind in the future.
Sorry but this is such a shallow comment. In what way is the US government directing public funding to academic institutions not state control? It's just a different organisational framework that appears to have been more successful.
Half the global population lives on less than $7 a day. I admire your optimism, but it's perfectly possible to keep large swathes of people living in abject poverty.
Is there an equivalent of LORA using RL instead of supervised fine tuning? In other words, if RL is so important, is there some way for me as an end user to improve a SOTA model with RL using my own data (i.e. without access to the resources needed to train an LLM from scratch) ?
It's well written but completely unjustified in its criticism of UK universities or their role given the resources required to train SOTA models. Are any US universities training SOTA models? No. Your point about the need for private venture capital is exactly correct. I think some kind of new funding stream needs to be identified for doing this. The US is forcing China to sell TikTok's US arm for national security reasons. We could try to do something similar in return for granting US Big Tech companies access to Europe - I guess the digital tax is a step in this direction. But it seems challenging to enforce that given the current power dynamics.
What an utter bullshit take. As if the ATI could ever be competitive at LLMs given the resource requirements needed to train foundational models. If we want UK universities to continue to make contributions in this sphere we either need to massively reduce the cost of training SOTA LLMs, create some national shared GPU infrastructure, or resource universities to access cloud infra. Unfortunately the latter is just introducing further dependencies on overseas (and increasingly problematic) private clouds. If things continue as they are then having the capability to train SOTA models will be a strategic imperative for every nation.
I see. Let's just assume that DeepSeek's V3/R1 budget of ~$5.5M was a lie and the Alan Turing Institute is just too poor to compete with their nine-figure sums. I guess I have no further questions.
> the $5-6M cost of training is misleading. It comes from the claim that 2048 H800 cards were used for one training, which at market prices is upwards of $5-6M. Developing such a model, however, requires running this training, or some variation of it, many times, and also many other experiments (item 3 below). That makes the cost to be many times above that, not to mention data collection and other things, a process which can be very expensive (why? item 4 below). Also, 2048 H800 cost between $50-100M. The company that deals with DC is owned by a large Chinese investment fund, where there are many times more GPUs than 2048 H800.
Oof, sounds like the budget for V3/R1 was exactly what I said. Having access to compute and running experiments is kind of the bare minimum for a supposed AI lab. And since this is a Western lab, their options for training are far more advantageous. But even if I were to accept all of those ridiculous fudged numbers, that's still within the Alan Turing Institute's budget.
Of course their anti-deep learning "most senior scientist" hasn't heard of DeepSeek, lol.
This is a fairly sweeping anti-science statement without any supporting evidence to back it up. Fairly typical of the HN anti-public research hive mind sadly.
reply