A while back I ported htdemucs (the same thing this uses) to onnx/wasm/webgpu so you can do it in browser (though I only bothered with the 4-stem version): https://bakkot.github.io/demucs-js/

I dunno, lots of companies seem pretty happy to build large portions of their business on top of unvetted single-maintainer open source projects. Don't see why they'd stop doing so now.

(Anyway, I don't care so much about what companies go for, as opposed to what I can do on my own devices.)

Exactly my thoughts. My point was targeted more towards consumers who usually don't have a voice in the software/hardware they buy. Reverse engineering, de-vendor locking, and open sourcing the protocol gives us freedom to use the device we purchased however we want, for as long as we want.

Depends on exactly where you draw the line at "breakthrough", but there's been at least a few novel and interesting results coming from outside mathematicians. Recently for example there were https://old.reddit.com/r/math/comments/1uxj3cy/after_openais... from Phillip Kerger at Berkeley, and https://www.erdosproblems.com/forum/thread/119/proof-claims from Samuel Korsky at Two Sigma (the latter of which was more of a collaboration between the human and machine, not a one-shot like several of the other results we've discussed).

They didn't open a PR against zig either, the compiler concurrency work they did was also only ever in their own fork.

In case anyone missed it, this PR is based on that:

> This is an implementation of the design Filip Pizlo published in 2017: "Concurrent JavaScript: It Can Work!".

This used to be more common but the pattern these days is to have the binaries split into optionalDependencies which declare their supported CPU etc, one per supported platform. Then npm will install just the matching one (optionalDependencies that require a different platform aren't installed).

The fact that most of the ecosystem has moved to this pattern is a big part of why this change is now feasible.

that's why. for those who want to read more about this, napi-rs support this natively

https://napi.rs/docs/deep-dive/release

They have taken action as of very recently. The latest version [1] of npm warns when there are install scripts and tells you they will be disabled by default in a future version, with a per-dependency opt in mechanism [2].

[1] https://github.com/npm/cli/releases/tag/v11.16.0

[2] https://github.com/npm/rfcs/pull/868

This is way too little, way too late.

To see what I mean, try actually packaging a cross-platform binary dependency in their ecosystem.

I have; you specify one optional dependency per platform and set the requirements in each package. It works fine. A bunch of packages do this (e.g. esbuild). I don't know what your complaint is or what you're asking for.

The proposal used to do more thing and we didn't change the URL after we ultimately arrived at this set of APIs.

There's an RFC for this: https://github.com/npm/rfcs/pull/868

> most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages

Technically true, but wheels can include a `.pth` which will run arbitrary code as soon as Python is started, which is only marginally less dangerous. Recently exploited in the LiteLLM attack.

That appears to be an exploitable feature of the language, not the package manager per se.

We could then add the philosophical question of asking what's the difference between:

1. Adding malicious code to a package's .pth file that's evaluated automatically on every python invocation

2. Adding malicious code to the package itself that's evaluated automatically on every python invocation _that uses that package_

Packaging systems that don't run arbitrary code when you install a package are more trustworthy than ones that do, but there's still the essential trust you have to place in all code you're installing, directly and indirectly.