edflsafoiewq

I think the GP's point is, if you don't know what quantization is, the article gives the impression it consists of discarding some of the values, which is where the compression comes from. This is a good "0-th order" intuition, but quantization is a softening of this; instead of fully retaining or fully discarding a value, there is a sliding scale of how much information to discard. If you already know what quantization is, it's easy to see how discarding is a special case, but the article gives the impression discarding = quantization.

Why is that sad?

There's actually two kinds of changes here: changes to the law, and changes to your description of the-law-and-its-changes (metachanges). For example, if you make a mistake in recording a change to the law, you need to fix that (unlike eg a source repo where mistakes in a commit message are forever).

So to make this a git repo, I guess you'd make the snapshots be the law plus markup for all the changes, and the diffs are the metachanges. For each snapshot S, you could generate a git repo whose snapshots are the law and the whose diffs are the changes in the law (as described by S). However, this probably isn't the best way to query S.

Specifically, it registers a keydown handler on the <html> that swallows everything.

But "a Frankenstein" could be his work, like "a Picasso".

Yes. It applies to "linear algorithms", which are basically functions of the form

  fun f(x1, x2, x3, ...):
    t1 = 3*x1 + 2*x2
    t2 = 4*t1 + 5*x3
    ...
    return (some subset of t vars)

where each ti is a linear combination of previous t vars, inputs x vars, or constants.

The cost model is just the number of additions performed.

The situation AFAICT is something like this: the server mints unique download URLs which can only be used once. This is generally so they can't be shared. It serves the URL to the first comer and when that connection drops (maybe with some timeout) subsequent requests to that URL produce 410 Gone. So if your download fails halfway through, you can't re-request the same URL with a Range, which is how normal resumption works. You need to get a new one-time URL minted and download that.

So from the browser's perspective, these are two distinct, unrelated URLs. There isn't a mechanism where it can know they are backed by the same file.

This browser behavior seems pretty reasonable. I'd try fixing it by doing something different on the server.

How would you solve it?

I'll try this.

The way I have to resume downloads in Firefox is

1. Move the .part file to a temp file

2. Start the download again; a new .part file gets created

3. Pause the download

4. Move the temp file to the .part file, overwriting it

5. Unpause the download; it resumes from where the old .part file stopped

This is only necessary if a "one-time" download link gets interrupted part-way through, eg. by a flaky connection. Attempting to resume a one-time link like normal gets (I assume) a 400 response and FF kills the .part file.

Exploiting an emulator through a ROM is significantly harder than inserting some malicious code into a binary.

I highly doubt that is what's happening. More likely the server is serving a webp under a .png filename or something.

I think this narrow view on determinism comes up a lot. Essentially any program can be made deterministic over single inputs by fixing all side-inputs. But there is determinism over classes of inputs too, eg. an algorithm given input X deterministically outputs X+1.

I think the wider view is usually what people mean when they talk about nondeterminism in LLMs. Maybe because computers are traditionally so deterministic the wide view is almost taken for granted by programmers.

Not if you're not giving feedback.

Presumably the same problems exist for avif/jxl?