amluto

What does the installation or lack thereof of firejail have to do with anything? You can do this with plain unshare + iptables.

What they do not have is a version of chatgpt.com that is not a slow, awkward, glitchy mess.

As a user of Astra, it writes code that appears to work. It does not necessarily write sensible code that is architected in a way that makes sense based on what it does. I just watched it do a major rework of a couple thousand lines of code by keeping the original organization and kludging up an adapter to make old code have new semantics.

I would expect that this approach, coupled with lots of fun asking for changes and none of the grunt work of actually thinking about the result, could result in exponentially increasing amounts of mess.

I haven’t used a recent Anthropic model - maybe it’s better at this.

I’m wondering whether Opus 5.5 would have caused growth in an absolute sense or just growth relative to competitors.

Anthropic’s market share is pretty high and there is not enough total currently addressed market for growth at the expense of a competitor to make a big long-term difference.

My laptop is shockingly competitive with my quite nice workstation.

(IMO the really impressive part is the thermals. My laptop can dissipate some 45W on a sustained basis, and my workstation takes quite a bit more than 45W to outperform my laptop.)

> A clear example is Google. They can easily give all compute to Deepmind, yet majority is allocated to be sold at market rate.

Google is in the business of buying compute and renting it out. To the extent that their internal use reduces revenues from that business, there is an opportunity cost.

Anthropic is not in that business.

The getting-the-car-over-the-barrier one looks particularly simple. It’s hard to see from the animation, but the obvious solution is to back up then drive forward. I’m not remotely surprised that Astra can figure that out, and I’m also not particularly surprised that Astra can come up with weights that do this.

In my mind, they’re putting huge downward pressure on the major US AI companies’ ability to become platforms.

Think about the history of AWS. Amazon made a very specific point of building, specifically, a “platform”. When they developed a major internal service, they would sell it. Basically anyone who wanted to use it could pay AWS (often an outrageous amount, but it was often worth it), and AWS would provide the service, and AWS was consistently neutral and trustworthy. They didn’t really tell you what you could or couldn’t do, they didn’t even ask what you wanted it for, and they never used your private data for their own purposes. AWS pulled this off quite well despite the fact that competing products and even open source products could and still can, with effort, do most of what AWS offered.

Compare to OpenAI and Anthropic. They want to sell you their front-ends (chatgpt.com, claude.ai, their apps and harnesses), but the big money is selling enterprise contracts with per-token pricing. The latter is the platform.

But their platforms suck in comparison to their open competition. You are paying for inference on a series of models, but:

- You need to negotiate with them if you don’t want them to retain your data.

- They might not even be willing to not retain your data.

- Part of the model output gets encrypted before you see it.

- You are not allowed to give the model arbitrary input.

- They run classifiers on the token stream to try to restrict what you may or may not do.

- You cannot see the model’s internal states.

- You are extremely restricted in your ability to modify the model and you may not be allowed to modify it at all.

- Oh, and maybe the price is above market rates.

The last point is not really a big deal: AWS has demonstrated quite effectively that customers will pay many, many billions of dollars above market rates for a high quality platform.

But I think the rest are a big deal, and the open-weight models allow anyone to use a provider other than Anthropic and OpenAI and avoid all the other problems in the list. This means that, if I’m a startup building a product that uses AI, I get to choose between OpenAI/Anthropic-like terms and a far better alternative. And this makes it very hard for OpenAI or Anthropic to sell me on their platform even at equivalent pricing.

This whole approach has an excellent chance of working extremely poorly. A device intended to power a whole house will have the ability to supply someone’s idea of the inrush current needed by a house, the reactive and harmonic current needed by a house, and the quality of waveform needed by a house. An EV’s 120V socket may be designed to operate one appliance for a while, but a single appliance may be a very different sort of load than hundreds of watts of crappy LED.

Also, this whole idea of connecting an EV via a manual transfer switch involves running an entirely separate cable connected to an entirely separate point near your main panel. The cost-effective (but currently mostly impractical solution) is to use the same physical wires for charging and for islanded V2H.

A lot of houses won’t run off 120V/20A. You’ll also need to kludge around the fact that your house wants 120V/240V.

In any case, serious V2H should support much more than 2kW. An EV with a charger with less than 6kW capacity is almost unheard of. Two EVs should be able to supply twice the current. All that’s technically needed is an charger that is physically capable of operating as an inverter (which I believe adds little cost), some way to derive a neutral (the usual solution is a relay and an autotransformer, again not particularly expensive), and the control logic to convince all of the above to actually operate in this mode.

> White flour has a slightly higher protein content

The bags of 13.5% protein whole wheat flour and 16% (!) protein whole khorasan flour in my pantry are not convinced this is a generally true statement.

Sorry, what device are you using to supply power once you've flipped the switch? Sure, you can get a (legal, even) manual transfer switch and plug in a little portable generator, but if we're talking about using your car as a power source, this is not going to work.

What Enphase/ISO standard is this? I’ve never heard of it, and my attempt to search came up with nothing useful. There’s ISO 15518-20 bidirectional, which seems like it barely solves the problem.

It should be possible for a vehicle’s built-in inverter/charger, the EVSE, and the MID to all cooperate even if all three are from different vendors, but this is not a thing.

A manual switch doesn’t solve the problem: there still needs to be a way to inform the inverter that the switch is open.

A fundamental problem here is that V2H during an outage requires a disconnection device (in the NEC this is a “microgrid interconnect device”), and the manufacturers of such things have made no effort whatsoever to standardize the control protocol. This means that you cannot build an islanded-V2H-ready house and just plug in a car. So the whole concept is kind of dead in the water.

At least Tesla is vertically integrated enough to pull it off within their own product portfolio, but this has approximately no value if you want to use a non-Tesla car.

It would look like a very different language that would be thoroughly incompatible with the existing ecosystem.

Indeed. Option[Foo] really just means Foo | None - you can’t have an Option[Foo] at runtime. Fundamentally, Python’s static typing system describes a language that is a sort of mediocre match for Python.

Another fun one is List[Foo]. Runtime Python has lists but you can’t ask a list what type of list it is, and you can’t write isinstance(a, List[Foo]).

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. 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 sufficiently insoluble protein that there isn’t much in dashi.

One could 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?

I’m thinking of the SGP40, which is a popular model for air quality sensors that is specifically intended to report “VOC Index”:

https://sensirion.com/media/documents/296373BB/6203C5DF/Sens...

I’ve personally played with the SGP41, but I’m guessing the poster I replied to has the SGP40 because they didn’t mention NOX Index.

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.