orlp

So if this happened to OpenAI it would've been instantly auto-updated everywhere? VS Code has an "auto update delay" which I have configured to a week, but I just found out that (https://code.visualstudio.com/updates/v1_123):

> Note: This delay does not apply to extensions from trusted publishers such as Microsoft, GitHub, and OpenAI. These extensions continue to update immediately.

You can't even configure which publishers you "trust"...

It's not (just) about cheap labor. The sheer density of resources and knowledge in Shenzhen is just insane.

Manufacturing at small to medium scales is so heavily determined by small blockers/latencies. Missing some component, or need a modified PCB? In the US or Europe you'd be happy to find a replacement within a week, or more likely have to wait a month for it to come from China. In Shenzhen you can probably walk 2km and pick it up yourself in under an hour.

> There is a lot of cynicism in this thread but the fact this is still open and hour later ends the narrative in my view.

Clearly people aren't cynical enough.

I find it strange no one in this thread has even considered the possibility that the private key of the wallet isn't on the machine.

OP gets their working exploit neatly logged (or even multiple approaches), keeps the money, strengthens the illusion the exploit isn't that bad, and gets a free $500 on top from someone who added to the wallet.

Math isn't a science. The scientific method is irrelevant for it.

Block-level full disk encryption? AES-CTR would require a per-write nonce.

Encrypting UUIDs in a database?

ISO 9564-1 PIN encryption?

AES is used for a whole lot more than just encryption in CTR mode.

`values` might be quite large (up to W), without `values_agg` getting the current window value would be O(W) rather than O(1).

Note that there isn't a `finalize` call, only an `eval`, which gives the current aggregate over the window. You typically use these sliding window functions in a way where you want to get the current value every time the window moves.

> If you push, then pop, you should have the same data as you started with.

That's the case for a LIFO queue, but not a FIFO queue. Both commonly use the push/pop nomenclature.

That's right, and one more property I consider very important for numerical stability:

- The aggregate only depends on the value currently in the window.

Most problems caused by NaNs/infinities/catastrophic cancellation/etc in sliding windows are covered by this property.

I don't like `shift` as a name because it might give the impression the entire window shifts. Push increases the window size by one and pop decreases the window size by one (evicting the earliest pushed element).

In my mental model `shift` would move the entire window, it would be one push + one pop.

My question wasn't one for right now, it's an ongoing question as more of the field starts adopting AI.

> I enjoy programming and producing high quality work. Why would I want to give up the thing I find fun and produce something subpar?

No one who cares wants to. That's not the question.

The question is whether you can continue to get paid doing so.

Sadly the experience with physical products tells us that the vast majority of people prefer cheap disposable crap over expensive craftsmanship.

It's likely that way more than just one of these is wrong. But even if it turns out 80% is wrong this is still 100+ results...

I'm more worried about them doing bad things at the behest of people who want them to do bad things.

That is 1. immediately technically possible, and 2. realistic.

If you need a source for 2 I'd suggest you open any history book.

I'm not denying that, but I'd still like to know what that cost.

Yes, what does that mean?

Oops, edited.

I'd really like some clarity on what that means. E.g. DeepMind has 'cheated' with this in the past, claiming that AlphaZero only took 4 hours to reach super-human chess levels while conveniently leaving out the fact that it was 4 hours x 5000+ TPUs. Sure it's impressive that it only took 4 hours wall-clock but it's very misleading as to cost.

Can we get a number in Blackwell GPU-hours, kWh, or some other compute-scaled metric?

Polars does have an asof join so I guess the mapping hasn't been made yet from SQL. Could you open up an issue at https://github.com/pola-rs/polars/issues ?

I'm not sure what you tried. Is this not what you want?

    >>> df = pl.DataFrame({"x": ["a", "b", "c"], "y": ["d", "e", "f"]})
    >>> df.with_columns(new=pl.col.x + " text " + pl.col.y)
    shape: (3, 3)
    ┌─────┬─────┬──────────┐
    │ x   ┆ y   ┆ new      │
    │ --- ┆ --- ┆ ---      │
    │ str ┆ str ┆ str      │
    ╞═════╪═════╪══════════╡
    │ a   ┆ d   ┆ a text d │
    │ b   ┆ e   ┆ b text e │
    │ c   ┆ f   ┆ c text f │
    └─────┴─────┴──────────┘

I think the person you're replying to is more so saying that by choosing the right queries, machine, disk setup, caching, settings, thread count, RAM amount, etc, you can get quite different results. There is a reason everyone always wins their own benchmarks, and it doesn't even have to be dishonest - you optimize and iterate for your own benchmark whereas everyone else just gets one shot to do well out of the box.

I tried my best to be as transparent and fair as possible, running everyone with out-of-the-box settings on a third party's queries (DuckDB), a third party's data generator (tpcgen-rs, from the DataFusion guys), on a stock setup available to everyone (AWS machines).

The one exception is that we also ran Polars locked to 32 threads on the large machine (in addition to the out-of-the-box setup), which was to highlight we can do a lot better on small data. We still suffer from a relatively high constant overhead on very high CPU count machines if the data isn't large enough, but I'm working on fixing that. It's possible that DuckDB / DataFusion have similar scaling issues with high thread counts and would do better with 32 threads as well, I didn't test that.

Peak memory usage per query is in the raw data (in `results/`) in the repository: https://github.com/pola-rs/polars-2.0-benchmark/.

Doing the benchmarks for 2.0 on the large AWS metal machines at small data sizes (SF=10) really opened my eyes that we have some low-hanging fruit in Polars when it comes to optimizing our constant overhead for smaller queries.

For example our join currently does a full partition into T partitions, for each of the T threads. Overall we create T^2 partitions, which on a 192-core machine is non-trivial. Great if you have a ton of data to feed that with, but if you 'only' have a few dozen million rows it becomes rather small. This is the primary reason we saw in the benchmarks that Polars pinned to 32 threads beats 192 thread Polars at SF=10.

I'll be working on improving that soon. I expect that to have a big impact on SF=10, and a decent impact on ClickBench, which sits between SF=10 and SF=100 in terms of rows.

Actually yes. We had already been planning to do 2.0 for a long time. We originally said we'd move on from 1.x quickly when released 1.0 but ended up staying at 1.x much longer than intended.

From a quick check our first PRs were merged to the 2.0 branch in June:

    2026-06-17T21:27:51Z #27993 chore: Stop coercing `pl.col(...)` to selector ...
    2026-06-18T14:19:26Z #27996 chore!: Replace multi-seed hash API with a single seed
    2026-06-19T07:05:11Z #27991 chore(python!): Remove `Expr.flatten` function

This fits one of the patterns I wrote about ~1.5 years ago:

https://orlp.net/blog/bad-ai/#objective-p-mathrm-relevant-1-...

I think it still holds up.

Why exclude the elderly?

Unless proven otherwise I assume any delete button in 2026 is just

    UPDATE tracking_data
    SET shown_in_interface = false
    WHERE account_name = 'm463'

You can do it with just 3 instructions for IEEE 754-2019 minimumNumber (ignores NaN):

        vminpd          ymm2, ymm1, ymm0
        vcmpunordpd     ymm0, ymm0, ymm0
        vblendvpd       ymm0, ymm2, ymm1, ymm0

If you want proper IEEE 754-2019 minimum (propagate NaN, -0.0 < +0.0, NaN bitpattern picked in the usual way) you can do it in 6:

        vminpd          ymm1, ymm0, ymm1
        vbroadcastsd    ymm2, qword ptr [rip + .LCPI0_0]
        vandpd          ymm2, ymm0, ymm2
        vorpd           ymm1, ymm2, ymm1
        vcmpunordpd     ymm2, ymm0, ymm0
        vblendvpd       ymm0, ymm1, ymm0, ymm2

I personally find this a load of nonsense I don't care about.

If you want propagating NaNs but don't care about signed zero or NaN payload/sign, you can use

        vminpd  ymm2, ymm0, ymm1
        vminpd  ymm1, ymm1, ymm0
        vorpd   ymm0, ymm1, ymm2

What I do in Polars is a bit different, there for propagating NaNs I do

    if (self < other) | self.is_nan() { self } else { other}

this isn't fully optimal on x86-64 but it's fairly simple and autovectorizes decently on various platforms, here's AVX2:

        vcmpltpd        ymm2, ymm0, ymm1
        vcmpunordpd     ymm3, ymm0, ymm0
        vorpd           ymm2, ymm3, ymm2
        vblendvpd       ymm0, ymm1, ymm0, ymm2

How do you define malicious?