amluto

I’ve come to learn an interesting dichotomy in software:

Some software is correct by construction, in the sense that the overall design makes sense and the cases that don’t work are generally local bugs.

Some software is incorrect by construction, and it tends to work by some combination of luck and by carefully working around the incorrect design in most or all code paths that could expose the incorrectness. (AI can be quite effective at finding the relevant places to insert workarounds.)

ParticleDB sounds like the latter category. Plenty of large projects have portions that are in one category and portions that are in another.

As an aside, for the last day or two, I’ve been contemplating that the Linux kernel’s handling of folio pinning seems to be in the incorrect-by-construction category. Good times. No, I haven’t found a hard-to-fix bug that I would credibly characterize as a security or likely accidental corruption issue [0], but this seems mostly like luck.

[0] I do appear to have re-discovered a bug that some massive Anthropic dump from a couple months ago also found, and it’s getting fixed. If your application does “fixed” io_uring I/O or certain types of iommu-based or maybe RDMA on a memfd, you might plausibly encounter it on rare occasions. I didn’t bother making a reproducer.

While heating something that hot using “passive” components (is a laser really passive?) is awesome, is it really useful? 5500K is considerably hotter that, say, the combustion chamber of a rocket, and those chambers need active cooling. And even 1500K is plenty hot that the Carnot efficiency of the heat engine part will be high.

Also, a solar pumped laser needs cooling, just like a heat engine! Just from first principles, you can’t have a gadget at thermal equilibrium that magically produces an excess of light at its output frequency — this would violate the second law of thermodynamics.

And if you imagine a model three-level laser, exposing all three transitions to bright light will pump the nonlasing intermediate transition (overfilling level 2, thus reducing the population inversion in a laser lasing on the 3 -> 2 transition, or pumping useful level 2 atoms back up to level 3 in a laser lasing on 2 -> 1) and will actively un-pump the lasing transition in any variety of laser (because light in the wrong mode will cause a population-inverted transition to emit into that same wrong mode by simulated emission).

> It has a penchant for maintaining API/etc contracts to a fault in the absence of instructions to the contrary.

AI has no magic powers to figure out what the “API/etc contracts” are in a nasty old codebase. This problem is fundamentally hard and not always well defined.

AI is also (at least for now) not consistently good at writing tests that test the behavior that matters. Recent models seem to be getting slightly less bad, but again, this is a hard problem.

I’ve personally used AI to rewrite gnarly code where the goal is to have exactly identical results to the old code. GPT-5.6 Sol could do this correctly with some extra help guiding it to rest the right things, and I haven’t tried this particular task on a newer model.

But ancient code like in the article is probably an enormous buggy mess full of accidental behaviors and implementing protocols in ways that do not fully match the spec. Some, but not all, of the mismatches will be cases where the spec is wrong. Sure, an AI can probably generate a new implementation with a similar set of bugs, but is this what is actually wanted? Also, depending on the gnarly set of bugs, a clean implementation may be unable to reproduce the bugs, leading to a messy implementation instead.

> Fundamentally: There is no way to lock webapps to reproducible builds.

One could absolutely use subresource integrity to lock one’s reference to a vendor’s subresource to a specific version. That’s what it’s there for.

Even if you are correct on the technical point, it’s still a security issue.

1. A carrier should not be able to render my device unusable in a manner that persists after I remove the SIM.

2. Dual SIM is a thing. One carrier should not be able to disable the other one.

(You do appear to be incorrect on the technical point as well.)

Except that a sensible deployment of PXE boot would also have the servers attest to their state prior to giving them any secrets. This vulnerability breaks this workflow.

Or to a protein that is sufficiently insoluble protein that there isn’t much of it in dashi.

One could (but maybe shouldn’t) eat a bonito flake or two as an experiment.

What I mean is: the MOx sensors, in theory, measure some function of the concentrations of various gasses in the air. The datasheets even give you some flavor of this function for some of the sensors.

But the actual behavior, at least for the SGP4x series, is so outrageously unstable and path dependent that you still can’t learn the value if that function of the gas concentrations. At best you get changes on timescales of minutes to a few hours but not on timescales of days.

What’s the “pool” case? A function allocates a growable arena in normal heap or virtual memory?

High pass. Probably actually band pass.

The instrument is pretty crappy - it has basically no calibration or, AIUI, long term stability. So you can’t really use it to characterize the chemical content of the air. What you can do is observe changes. I’m guessing the manufacturer wanted to avoid people getting confused by the absurd raw reasons, so they came up with a formula called “VOC Index” that HPFs the data. It will average 100 IIRC. You’re supposed to use it to notice events that cause changes - if it hits 170 every day at 2 PM them you can guess that something’s happening at 2 PM.

None of this is in the chip. It’s implemented by the driver. There’s an implementation in esphome, for example.

VOC index means literally nothing. (I've read the datasheet, implemented some kludges to log raw data, and contemplated the formulas. The data is high-pass filtered. You literally cannot conclude anything about a single measurement if you assume the sensor is somehow magically perfect. You might conclude that there is more VOC (or less -- not all VOCs have the same sign in their effect) when cooking than when not cooking.)

I target 0 PM2.5, but this only necessarily makes sense as a target if you have the ability to filter your home's supply air. And a good vent hood should be able to avoid any detectable bump while cooking (although a vent hood without filtered makeup air may cause a bump due to increased infiltration of exterior air).

ChatGPT Pro says that it can be done faster based on the earlier OpenAI DFT paper.

All of these algorithms are neat but utterly ridiculous :)

The answer I got back makes me suspicious that quite a few of the recent OpenAI improvements on problems that involve some sort of multiplication are are related to each other and may even be, in some sense, examples of the same insight.

I think you have an also have not disproven the existence of a magical gadget of this general style. The programs mentioned in the paper have a very restrictive form, and I think you’re right that a program of that sort cannot propagate information through the array faster than the naive algorithm. But the actual average-case-ish gadget mentioned later is not of that form - it also has additions and maybe other things going on.

Interestingly, the operations discussed in this part of the note are, I think, pretty much exactly the operations needed to operate on classical representations of an m-qubit quantum state, implementing single-qubit unitary quantum gates on each qubit.

I suspect that, if you had asked me fifteen years ago if I thought you could do the same exact operations like this on each of n different states (on a classical computer) faster than n times however long it would take to do it once, I would have said “sure, why not?” It probably helps that I worked with people who really liked matrix multiplication and similar problems :)

For fun, I have ChatGPT Pro chewing on the following prompt:

Suppose I have a m-qubit quantum state. I can do an operation U = U_1 \otimes ... \otimes U_m, which is just a unitary operation on each individual register.

I can also simulate this on a classical computer. Start with the state, written out classically as a complex amplitude for each state in the computational basis (i.e. 2^m complex numbers). U acts on this state in a linear manner to produce a new state. What's the classical time complexity of this? (Assume a model of computation with exact complex addition, multiplication, conjugation, etc taking unit time, but don't cheat by encoding absurd things into complex numbers. Assume data movement is free.)

Now suppose I want to apply the same U to n separate input states. Can I do better than n times however long it takes to do the operation once?