You can set up paths that route to different local ports. As long as your apps don't need to live at the root path you can have as many as you like. And you can still have something on the root path as long as it doesn't need the subpath.

Here's `tailscale funnel status` on my machine:

    $ tailscale funnel status
    
    # Funnel on:
    #     - https://my-machine.tailXXXX.ts.net
    
    https://my-machine.tailXXXX.ts.net (Funnel on)
    |-- /            proxy http://localhost:3000
    |-- /foo         proxy http://localhost:3001
    |-- /bar         proxy http://localhost:3002
    |-- /baz         proxy http://localhost:4004

or just use a tailscale sidecar[0] in a docker container and give it any hostname you want

[0]: https://tailscale.com/blog/docker-tailscale-guide

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