Hacker Newsnew | past | comments | ask | show | jobs | submit | octoberfranklin's commentslogin

Exactly the same thing that's been happening with vulnerabilities and bugfixes the past few months.

I fear that AI is going to cause ossifying secrecy in many fields, much like what happened semiconductor design the past 10-15 years.


> https://cims.nyu.edu/~tristanb/statement.pdf

This really need to be a top-level story on HN..

I asked whether the model had been trained on, or had access to, our sessions in Codex, into which we had been putting all our drafts for the whole of this project. I was told the model did not look up user data. I asked again, about training, and I did not get an answer.

This whole episode is more horrific than "AI is eating math". We now have a clear and economically damaging (or at least career damaging) example of the "training on customer tokens" problem.

We can't ignore this problem any longer.


We don't have any proof of that at all. Please stop rushing to judge without data.

> We don't have any proof of that

It’s fair to give benefit of doubt to Buckmaster given OpenAI is currently being very credibly sued by Apple for openly stealing others’ original work in another context.


I disagree. If it were not user hostile the days before BIOSes were cryptographically signed the SMM code would have no reason to disallow the kernel modifying or replacing it. Like `insmod` lets root-in-userspace modify kernel-privilege-level code.

In fact the whole situation is very much analogous to Kernel Lockdown, which is controversial.

With signed bootcode you can give a reason for not letting the userspace modify the SMM code. But when all this stuff was designed there were no bootcode signatures.


the SMM code would have no reason to disallow the kernel modifying or replacing it

Don't forget that SMM code started out in A0000 --- the area of RAM that would've otherwise been inaccessible and wasted anyway, because it was usually decoded to the VGA. Also, this was the era of DOS; there was no difference between "kernel" and "application".


It's like that for reliability and compatibility. The kernel on a 386 wants to stomp over everything, so if we want the kernel to not stomp on something we'd better hide it.


It certainly is a vulnerability, because SMM is a higher privilege level than root.

(The fact that there is such a thing as a higher privilege level than root is what annoys people).


"Vulnerability" has a negative meaning, so let's name it in a positive way, like "jailbreak", "liberation" or something.


Murder has a negative meaning. Let's name it "neutralization" or "sending to a higher place".

Giving it a new name doesn't mean the original name is less correct. Vulnerability is a relative definition. It's a vulnerability in the context of the chipmakers security model but not necessarily yours. It could be a hidden feature in your world.


Link is broken:

Access is temporarily restricted

We detected unusual activity from your device or network.

Reasons may include:

Rapid taps or clicks JavaScript disabled or not working Automated (bot) activity on your network Use of developer or inspection tools Need help? Submit feedback.


There is a more helpful way to reply, that includes this text.


I believe in linking over copy & paste, in particular when I want neither to quote the full FAQ nor editorialize by selective quoting. By reading the FAQ, people can form their own opinion on it.


"If I don't know you, I don't merge you"

And if you catch somebody submitting code they can't explain, you don't know them anymore.

It's really simple. Open source has always had a social layer. Github culture tries to eliminate it, and that's the source of this vulnerability.


Nonsense, it's easy: you just need a social process like Linux has. Patches are ignored unless you've proven yourself to somebody. Start by participating in technical discussions on IRC or the smaller mailing lists; do that for a while before you submit patches. For smaller projects: "if I don't know you, I don't merge you".

Linux's LLM policy allows AI-generated code because the project was never vulnerable to this DoS attack in the first place. They kept the social defense they've had for decades.

The killzone here is Github culture, where people decided it was normal to accept code from anonymous randoms with anime avatars. They're doomed.


They pipeline-parallelize across multiple chips. DeepSeek v4 Pro will be 30 chips.


> and dense with cryptic language

Yeah if you ask it a medical question, it answers in that impenetrable jargony style that clinical journals use... full of unnecessarily custom adjectives ("orthopedic" instead of "of the bone") and discipline-specific terms (anterior, distal) even when the user didn't display mastry of this terminology (hint to frontier labs: add training cases for this; it will improve your model's usability).

My theory is that LLMs perceive the writing styles of various fields as being like different (but related) languages, and they're inclined to answer a question in the language of its source material unless specifically asked otherwise. If you add "ELI5" the model treats it as a question plus a translation task.

I think this is why programming questions are answered with an exaggerated cringey form of HN-speak ("load bearing", "gate" as a verb, "dissolves") by some models.


it's like asking a developer to explain something.

I always get Haiku to rephrase anything human-facing.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: