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

Probably not because the whole point is they don't do critical review

> ArXiv gives the appearance of scientific credibility that a blog post wouldn't have

That's an error on your side not theirs


Then just call it Substack.

This comment is one of the most bizzare things I've seen here regarding ArXiv.

Good observation, that seems like the most likely explanation. Do you ever see "true" CF=0 (with nonzero arg) or did they just take the lazy approach?

No, CF=0 occurences seem to be happen frequently and uniformely distributed like valid results at ~1/65536, not clustered. Under a minute-long all-core load CF=0 always produces zero, but that's to be expected according to the manual.

Here are some stats:

    Rounds (N): 1000000000
    Failed (F): 15312
    Valid  (V): 999984688
    N/65536: 15258.789
    V/65536: 15258.555
    Failed, result was zero: 15312
    Failed, result non-zero: 0
    Bucket value for      0: 15312
    Bucket value for      1: 15290
    Bucket value for  65535: 15223
    Min bucket value: 14670
    Max bucket value: 15835
I used this C program to collect them:

    #include <stdio.h>
    #include <stdint.h>
    #include <stdbool.h>

    const size_t N = 1000000000; // 1e9

    struct rdrand16_result {
        uint16_t n;
        bool ok;
    };

    static inline struct rdrand16_result rdrand16()
    {
        struct rdrand16_result result;
        __asm__ __volatile__( "rdrand %0" : "=r" (result.n), "=@ccc" (result.ok) );
        return result;
    }

    int main()
    {
        size_t buckets[0xFFFF + 1] = { 0 };
        size_t notok = 0, notok_zero = 0, notok_nonz = 0;
        for (size_t i = 0; i < N; ++i) {
            struct rdrand16_result result = rdrand16();
            ++buckets[result.n];
            if (! result.ok) {
                ++notok;
                notok_zero += result.n == 0;
                notok_nonz += result.n != 0;
            }
        }
        size_t max = 0, min = N;
        for (size_t i = 0; i <= 0xFFFF; ++i) {
            size_t n = buckets[i];
            min = n < min ? n : min;
            max = n > max ? n : max;
        }
        printf("Rounds (N): %zu\n", N);
        printf("Failed (F): %zu\n", notok);
        printf("Valid  (V): %zu\n", N - notok);
        printf("N/65536: %.3f\n", (double)N / 65536);
        printf("V/65536: %.3f\n", (double)(N - notok) / 65536);
        printf("Failed, result was zero: %zu\n", notok_zero);
        printf("Failed, result non-zero: %zu\n", notok_nonz);
        printf("Bucket value for      0: %zu\n", buckets[0]);
        printf("Bucket value for      1: %zu\n", buckets[1]);
        printf("Bucket value for  65535: %zu\n", buckets[0xFFFF]);
        printf("Min bucket value: %zu\n", min);
        printf("Max bucket value: %zu\n", max);
        return 0;
    }

> but that's to be expected according to the manual

Confusingly, the AMD programming manual (Rev. 3.38 - July 2026) only explicitly states this ("that the result is always zero when CF=0") in the description of RDSEED, but the Intel SDM mentions this in the description of both instructions.


The bleach+ammonia one seems realistic enough to me

> Instead of finding a nerfed model, after six weeks of reconstructing wire logs, parsing transcripts, analyzing output tokenization, and staring at data, I found a much deeper issue. The model identity had remained the same, but the inference regime being delivered behind that model had not.

Is this something specific that shows up in the wire log, or is this the author's intepretation? The fact that Claude Code versions change over time in the test is suspicious. Anthropic has stated in the past that the underlying model behavior does not change over time, but Claude Code will change from version to version and this is expected. So if it's just Claude Code more aggressively tuning some knob in its requests, that's a pretty different thing than the underlying model changing.


They posted a long document explaining it all https://x.com/Lon/status/2101034933284417614

They're not measuring a fixed set of questions. This was post-hoc analysis on whatever prompts they were running each day.

Anyone can understand why it would go up or down depending on the work they're doing that day. This analysis is silly.



Ah I didn't catch that. Yeah without controlling the inputs this doesn't prove much.

It would appear no one else submitted the posts in question, so the most obvious answer is the account is finding interesting articles that no one else has found. It would be one thing if it won out of many dupe posters, but that doesn't seem to be what's happening.

This is valid.

1. each one is a first-party vendor announcement, submitted very close to the announcement and under the vendors headline.

2. Titles are "verbatim" vendor headlines. No editorializing which follows HN guidelines to the letter.

3. Someone; a script/agent is watching vendor feeds and X accounts then submitting within minutes of the posting.

4. Altman/Navier–Stokes post got [duped] so prob not inside thing.


High frequency karma farming.

You aren't serious about high-frequency karma ("HFK") unless you colocate your equipment with the routing for your sources so you can beat your HFK competition to a submission by at least 200ms.

We will have reached HFK-ception when the bots are fighting to be the first to submit "How I used AI to build a High-Frequency Karma Farming Bot on Hacker News."


Then a week later: "Paul Graham announces a 100000$/month high priority access plan to the HackerNews via YC API." :)

YC already announced something along these lines.

re: https://www.ycombinator.com/early-access


Oh my... I should be more careful in my predictions :)

Their scraper is physically really close to the internet building!

There's a good chance it'll be scrubbed now that it's frontpaged here

Tangent, but that's not in the movie. It was in Clarke's contributions to the script and novelization, but Clarke and Kubrick had a bitter falling out over different visions and Kubrick took out much of Clarke's stuff from the final product.

It was made explicit in the sequel movie 2010: The Year We Make Contact, but even if you don't consider that movie canon, the explanation still makes sense solely within the context of 2001, IMO.

Sounds like he acted the way HAL would have in that situation, two competing drives, remove one (kill the crew) and the task is much easier.

Both of your links are basically ads, or at least the titles make them sound like it.

> Lenovo showed a model that incorporates solid-state air cooling. That technology has been around for a while but it looks like it matured and is production-ready. This allows for super-light and slim designs, which, in turn, should allow for bigger batteries installed and I think it's some sort of breakthrough

See now this sounds like something I'd click on. (The linked article doesn't really discuss any of the technology or engineering though)


There have been several threads and developments on this over the past few days, including statements from the primary subjects involved. Third-hand instagram comments are not really the best source to be bringing in.


Everybody comes into information in different ways. There were no comments here about this specific aspect of the story - which is definitely interesting!


Weren't the agents massively parallel, whereas the lean verifier presumably is not? Also, I presume said agents were themselves running the verifier on their own parts many times.


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

Search: