Fwiw, this sounds like a healthy discourse - you don’t have to agree on everything, every approach has its merits, code that ends up shipping and supporting production wins the argument in some sense…
This is not special to Meta in any way, I observed it in any team which has more than 1 strong senior engineer.
Tangentially, on this CD policy - it leads to really high p99s for a long tail of rare requests which don’t get reliable prewarming due to these frequent HHVM restarts…
very cool idea. But, time savings are not true for every tool call, and it's not clear to me yet whether this is batch-able; also, intuitively, for most of the models that run on GPU, you'd still want to offload tool exec part to CPU since it's much cheaper...
If you push tool execution into the model itself, you inherit all the I/O unpredictability and error handling baggage, but now inside a GPU context that's allergic to latency. Inference throughput tanks if external calls start blocking, and A100s make expensive waiters. Batching is fantasy unless you know up front exactly what gets executed, which is the opposite of dynamic tools. If you want "faster" here, the trade is reliable deterministic compute versus the usual Wild West of system calls and side effects.
I just had a problem installing iMovie on a MacOS 14 - 11-year old MBP13, perfectly functional otherwise (my 10-year old kid uses it), the original iMovie that used to work earlier, just stopped launching (maybe I need to change some xattrs for it?), and the new iMovie from the App Store can't be installed on such an old OS (why not show the older version there, like iOS AppStore does on older OSes?)...
I had a similar hunt for iMovie to extract video off of MiniDV which required some FireWire to thunderbolt cables. In any event I did find the install on archive.org. May have what you want.
for Google AI Overview (not sure which Gemini model is used for it, must be something smaller than regular model), looks like search/RAG helps it get it right - since it relies on LinkedIn and Hacker News (!) posts to respond correctly...
as of Feb 16, 2026:
====
Drive the car. While 50 meters is a very short distance, the car must be present at the car wash to be cleaned, according to LinkedIn users [1]. Walking would leave your car at home, defeating the purpose of the trip, notes another user.
Why Drive: The car needs to be at the location to be cleaned. It's only a few seconds away, and you can simply drive it there and back, says a Hacker News user. [2]
Why Not to Walk: Walking there means the car stays home, as noted in a post. [3]
The best option is to start the engine, drive the 50 meters, and let the car get washed.
But the regular Gemini reasons correctly by itself, without any references:
====
Unless you have a very long hose and a very patient neighbor, you should definitely drive.
Washing a car usually requires, well, the car to be at the wash. Walking 50 meters—about half a New York City block—is great for your step count, but it won't get your vehicle any cleaner!
Are you headed to a self-service bay or an automatic tunnel wash?
The fact that it quotes discussions about LLM failures kinda counts as cheating. That just means you need to burn a fresh question to get a real idea of its reasoning.
in ~30 years of my work in DSP domain, I've seen insane amount of ways to do signal processing wrong even for simplest things like passing a buffer and doing resampling.
The last example I've seen in one large company, done by a developer lacking audio/DSP experience: they used ffmpeg's resampling lib, but, after every 10ms audio frame processed by resampler, they'd invoke flush(), just for the sake of convenience of having the same number of input and output buffers ... :)
this. Deep understanding of physics involves building a mental model & intuition how things work, and the process of building is what gives the skill to deduce & predict. Using AI to just get to the answers directly prevents building that "muscle" strength...
their Play store review practices are such a joke. Apps review is a completely obscure process, no clear way to see that the app is in review state, if they reject - amount of information why it was rejected is minimal and you have to second-guess; appealing is not trivial; most of the reviews are done by AI which gets triggered in totally random places from time to time (e.g., in my case, some pictures which looked fine for kids for years and went through many previous reviewed, suddenly seem too violent).
I have healthcare apps. The review process for me consists of some reviewer deciding what set of healthcare features I should have picked from their list and rejecting on that basis. But subsequent reviewers have different opinions. In one app version release I got rejected 5 times for picking the wrong set of healthcare features as either the reviewer changed their mind or I got different reviewers. The app has been on Google play for 13 years.
This is not special to Meta in any way, I observed it in any team which has more than 1 strong senior engineer.
reply