regularfry

That particular example doesn't quite fit, but I've certainly seen cases where otherwise perfectly ordinary fixed strings needed to be broken up to meet linting rules.

"Pretty much" doing a lot of work. But it's kinda analogous to 99% JPEG compression: yes you can detect loss, but you get meaningful compression ratios out of it and the subjective appearance is nigh-on perfect.

Shannon would be pointing out that if you can throw away half the model without apparent degradation, we're nowhere near packing in all the information we could in training. There must be a better arrangement than we've currently got.

The problem is that the situation in the RAM market might just... not go away. It's locked in for the next couple of years unless the AI market goes pop. Which it might! But if it doesn't, there's no particular reason to think that the incentives for cornering the market like OpenAI have would go away.

We might see that new normal in five years or so. We will see a new normal sooner than that if there's a run on AI because of the sudden availability of DRR fab capacity, but also we'll probably see the level of local models freeze at whatever state they've got to at that point. But an equally likely outcome is that any new DDR capacity that comes online is just immediately absorbed by frontier AI, and consumer devices stay at "just good enough" for a decade.

I've been getting 40-50t/s out of qwen3.6:27b on a 4090 limited to 350W with the MTP changes that went in. That comes out at 8.75J/t at the upper end. No idea how that compares with anything else out there. I'd expect a 5090 to be a bit cheaper because it'd be faster within the same power limit.

You've gained that happening much less frequently. The tradeoff is making every other problem harder to diagnose.

The difference won't be in the individual tasks. It'll be in the scale of job they can take on and how you interact with the model. Think of pairing with a junior vs replacing a full delivery team, that's the sort of difference we'll be looking at. We'll be able to get closer to the latter by being more clever with harnesses, I reckon, but the frontier labs will run ahead because for any given harness trick they can lean harder on model smarts.

It's not quite true to say that if you release it you get nothing. If it's worthwhile and picked up by the open-weights labs, you get much bigger and better models implementing it than you would have had access to or been able to train otherwise, quicker than if they had to figure it out de novo.

Not in the first 800,000. Maybe in the first 8,000. They really struggled with reliability early on the E65, they introduced a lot of new (to them) technology all at once.

Don't we also have to worry about heating of the solar panels themselves? 150W/m^2 isn't the incident power, it's the output power. Incident is something like ten times that. Some of that's going to be reflected, but not all of it.

25% of cars. It was... not good.

Other way round. He invented the induction motor (1887) which the three-phase grid was then demonstrated to drive (1891). That's how influential it was. There are other reasons a three-phase grid is handy but being able to drive these brushless contraptions must have seemed utterly wild at the time.

If you had bought a 7 or 5 Series at that time, you would not have had that experience. The 2001 7 Series had something like a 25% roadside breakdown rate.

The difference in outcome isn't that big but yes, you need to be more rigorous. For instance I've found that the Kimi K2.5 and K2.6 models will comment out failing tests rather than fix a problem they just caused (mistaking them for "pre-existing failures"), so you need to specifically make commented-out tests break the build. I've not personally had that problem with any of the Anthropic or OpenAI models.

If the collecting fabric was on the inside, you'd literally have a stillsuit. I can imagine there would be complications with it getting clogged by oils from the skin.

Plus, you know, completely ruining thermoregulation by preventing heat loss through evaporation.

Oh, fascinating. So they did reuse the existing gemma4 MoE.

It's fast enough that "ask it twice and pick the best" should still come out ahead performance-wise. I don't know how much that would close the quality gap by, but it's worth a play.

This is a different model with, confusingly, approximately the same number of params as the existing gemma4 MoE. Unclear from a quick scan whether one was trained somehow from the other.

The mechanism isn't the same as speculative decoding. Speculative decoding happens sequentially and (usually) a couple of tokens at a time; diffusion doesn't, and does blocks of text at once. I haven't read the collateral yet but my assumption would be that it's trained to keep the specific experts stable across a diffusion block.

I've built hardware with a pi zero 2 + pi cam running a mildly fine-tuned YOLO doing local-only object detection as a USB-OTG device, in a use case where any off-device API calls would have been totally unacceptable, and where the object detection was part of the human interaction loop with a hard ceiling of 300ms on the total interaction time of which the object detection was only one process among many.

We're not going to fit Nano Banana or anything like it on a device with 512MB RAM and a GPU old enough to be irrelevant, and again, API calls just aren't on the menu.

Yes, but that doesn't have to imply that the compute part of the durable jobs framework also needs to be part of the database snapshot. You almost certainly want that defined in code anyway, if only to have a sane versioning story. So then by having it also be part of the snapshot, you've now got the problem that there are apparently two sources of truth for that bit of the code.

Search for "heretic"+Gemma/qwen/DeepSeek for examples where exactly this has been done.

Part of that was incidental factors. The 701 happened partly because of a glut of cheap, standardised screens designed for that first generation of in-car dashboard sat-nav systems.

It didn't help that those screens weren't particularly good.

Is it? I had it pegged as pretty much neck-and-neck with the 8GB M1 Macbook Pro that work gave me.

Yes not only large employers, but it's easiest to think in those terms.

And it's only true that "employees come and go" is a problem if 1. you assume turnover has to be high, and 2. you don't know where to find qualified people you need. Turnover will be high if you assume you need commodity devs and don't, for instance, invest in their skills (like teaching them minority languages if that's your thing).

If I see a company hiring for "python developers" or "java developers" at this point I absolutely know what sort of problems their codebases will have, because they're in the commodity market and treating development as a cost centre to be minimised. Which leads to lower salaries, which drives higher turnover.

It's all self-fulfilling.

The question is appeal to whom. Large employers want you to learn popular languages so that you're a commodity in a liquid market. But that's not a signal of economic value; it's the reverse. It's saying "I'm entirely replaceable."

What you can predict is that those employers for whom clojure (or any other minority language) is either acceptable or preferred are deciding that they don't want commodity, low-margin employees. It's a signal that they prefer not to buy the mass-market offering, and ought to expect to pay a premium.

What that means is that if your only way of finding jobs is to be one of the mass-market crowd, you're unlikely to find a premium-paying employer because that's not where they're looking.

I've found it helps to give the model a lower nesting limit than you might give a human who has access to a paren-balancing editor. If all functions are shallow, there's less opportunity for paren balancing to get out of control, and reasoning about the evaluation flow doesn't have to jump back and forth so much.

This also doesn't hurt the code from a human reader's point of view.

> With respect, this topic in particular has been beaten to death.

Yes and no. From the discussion here I've learned about the existence of jank, which wouldn't have come up a year or so ago and might be an interesting solution to a problem for me as it evolves (that problem mainly being me not wanting to use C++ or any of the other directly supported languages in a plugin ecosystem). So these things are worth bubbling up every now and again just for the discussion to have a chance to play out.

"tolerates".

Models on Bedrock can have different and additional terms and conditions, there's even variety within the same provider for some of them. The Anthropic ones certainly have their own EULA. It's a bit frustrating because ideally it should be a known legal status, but in fact it still needs legal review if you're doing anything interesting.

4. AWS billing is already cross-charged to different departments per account. Copilot/Claude/Codex would need that setting up all over again, and is (probably) all coming out of a central bucket right now. Switching to Bedrock APIs is really easy, and solves a problem for people high enough up in the organisation that they can insist on it.

> The GPU fares poorly on Intel's side

'Twas ever thus. I really wish we had a better baseline default without having to reach for NVidia/AMD.