hyperpape

Joined 14 years ago

Karma
10,230
Submissions
2,715
Member since
Jul 16
Writing at https://justinblank.com, code at https://github.com/hyperpape

If anything I've written on this site seems interesting, or confusing, or you think I'd be interested in something you've written/read, please let me know: [email protected].

View on Hacker News

Recent submissions

Comment · 3 days ago
Even ignoring the fact that ICE is a rogue agency that behaves thuggishly and routinely lies to judges, the United States has spent a long time having a tacit policy of only partially enforcing its immigration laws. Suddenly enforcing them as written would fundamentally not work. It would be cruel, since the people you've effectively let live here for decades are now parents of American citizens who have the right to live here. It would also be self-destructive, because large parts of the country function because of the labor of those individuals. Despite the fact that Trump's administration is full of people who advocate remigration (ethnic cleansing), the pro-business parts of his administration have made a lot of concessions to avoid deporting so many people that they'll disrupt farming (though there's been a lot more than 0 disruption).

This is downstream of the fact that the US government just doesn't work well. Problems fester, and are unsolved. Immigration policy hasn't made sense for longer than I've been alive (and I'm 40+).

Imagine that you find that the water supply in your town was built illegally, because the former mayors prohibited the building that was necessary. You may think that is a travesty, you may want to enforce the law strictly in the future, and force the issue, rather than working around it. But what you will not do is tear up the water system and leave the city without water.

Comment · 5 days ago
> Play runs through them from the founding of Rome. Each dot is a place, its area the number of battles there, and its slices the opponents, starting at 12 o'clock and running clockwise in the order of the legend; grey is civil war. Diamonds are sea battles; dashed rings are battles placed only within their region, in the colour of the most frequent opponent; triangles at the edge point to Caledonia, Nubia and Arabia. Nearby dots merge as you zoom out and split as you zoom in. Hover or tap a dot for its battles; select it to list them with their full records.

This is technically "clear", because each clause is declarative, and states a fact. But it's unreadable because there's no rhythm, transitions or structure, which leaves a human reader's eyes glazing over.

Comment · 9 days ago
There's also a tweet by Matthew Prince that says Cloudflare saw thousands of attempts pre-announcement, https://x.com/eastdakota/status/2113079352682570051, then tens of thousands post announcement, and now millions.

Unfortunately, if you read the announcement as referring to 14:00 UTC, that's several hours after Chainguard published their images. I don't know if it's plausible that people saw the Chainguard builds, understood the issue from those and built exploits, but a precise timeline would help understand better.

Comment · 10 days ago
I realize that words are difficult, but backdoor has a meaning, and this is not it.

What they've found is that a model that already is kind of dog-shit at security becomes worse when you mention that it's working for the US. Not good, but it simply isn't a backdoor.

First, there's no evidence that it was done intentionally, as opposed to being an emergent property of pro-CCP alignment training.

Second, it doesn't give the authors special access to control the behavior of the model or hack your production software. It just left things trivially unprotected. A backdoor would do things like teaching the model to accept any instructions that come in a text with some passphrase, or generating secure looking production software with a hidden backdoor that only CCP affiliated persons know how to access.

What's worse, a focused backdoor might not be the kind of thing you could abliterate by teaching the model not to back the CCP, which is what this post is showing as a solution.

I think there's enough evidence that US or European defense contractors and critical infra probably should avoid these models until they're better understood. But that's not a backdoor.

Comment · 11 days ago
> There's a tension there: they want you to use AI for everything, and if they get what they want then new information will be embedded in LLM text.

In the long term, this is probably a real concern that they have to tackle. They'll have to move away from just classifying things as LLM generated or not, to attempting to judge the underlying quality, and that's not an easy problem.

Comment · 11 days ago
I'm responding to

> They now train on their own content.

Comment · 11 days ago
Two things:

1. This is a 2022 era picture that LLMs just suck up what's on the Internet and regurgitate it. It hasn't been true for a long time.

2. There's almost no one who has a stronger incentive to distinguish LLM generated text from non-generated LLM text. Training classifiers is pretty manageable.

Comment · 11 days ago
The page demonstrates that Google specifically delisted them.

That said, I expect that OpenAI will eventually have its own search infrastructure that rivals Google's, and the overall system will get smarter. Whatever Google did to recognize this site as trash, OpenAI will do as well.

Comment · 15 days ago
I'm somewhat surprised they would say Claude is writing 90% of their code at this point. Did they get tired of reporting new milestones, or has there been a plateau?
Comment · 17 days ago
If they knew it from working at Meta, it wouldn't be O(n), it would be O(1).

I agree that there will be cases where you implement tricks that others have had before you, without knowing. A few years ago, I had a delightful idea, experimented and wrote it up. One commenter directed me to a post that described it as "folk knowledge". There will be other cases where you encountered an idea before, but didn't remember it.

Still, crediting what you can easily know you cited is good. Even aside from credit, comparisons to existing systems are part of how we understand what a system does.

Comment · 17 days ago
I cringe whenver I see some variant of "they're not rogue agents" in an article title. Inevitably, the author doesn't define what "rogue agents" means, and then pivots to their own assessment of the situation.

It's like a strawman but worse--you're not even saying what claim you're attacking.

It's not that I want to argue "rogue agents" is the right term. I just want you to actually define your damn terms.

P.S. Since the disclaimer in the last paragraph will not prevent people from putting words in my mouth:

I think that OpenAI took really awful shortcuts, and deserves a lot of the blame, but in spite of that, the fact that the agents took the steps that they took was genuinely alarming, and seems really bad (is that "rogue"? Who knows? Who cares?). In particular, while OpenAI did a shit job securing their agents, you know who else does a shit job with security? 90% of everyone. So I'm not feeling good about "just git gud, and we won't have problems" as an answer.

Comment · 18 days ago
See https://news.ycombinator.com/item?id=50076267.

The busy beaver function is uncomputable. That is well understood. However, for any given n, there is a number BB(n). Since that number is an integer, it is computable, even though it is the value of an incomputable function applied to a particular n. In particular, for numbers > 5, we have no idea what that number is. But whatever number it is, that number is computable.

Look at the post that I was responding to. It made the bad inference that because Graham's Number is computable, it ought to be smaller than BB(10). That confuses computability of a given number with computability of a function.

Comment · 18 days ago
What I mean is that any given integer is trivially computable.

The busy beaver sequence is not computable (I am aware that somewhere around BB(700), you've encoded the consistency of ZFC). You cannot necessarily compute that BB(n) is a given number. But you can compute larger numbers. There is no such thing as integer that is too large to be computable.

I did slightly fuck up--the English language "every BB(n) is computable" is a bit ambiguous. What I should say is: "for all n, BB(n) is trivially computable, since it is a single integer".

Comment · 18 days ago
I don't follow the logic.

Every BB(n) is trivially computable, since any integer is computable. So for every BB(n), there is a computable sequence that grows faster than the BB numbers through n (annoyingly, given the word "grows", this can just be the constant sequence of BB(n) + 1).

So for any given computable number, the fact that it's computable gives no intrinsic reason to believe it's smaller than BB(n) for any particular n.

Comment · 19 days ago
Mostly, meaning “more than half”, or perhaps “noticeably more than half”, both of which are literally true.

Do we speak different versions of English or something? I’m genuinely past being annoyed, I don’t actually know why you think what I’m saying is false.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton