I already can't remember jq syntax. Naming this jg just means I'll type one, instinctively use the other's syntax, and get an error anyway. It's a DX trap.

But I will admit, the new syntax makes a lot more sense.

An intelligence satellite - which is not a super common utility nations have - will locate where the aircraft _was_ X hours ago, or at least many minutes ago. A constantly updated missile with a rather simple GPS tracker would benefit A LOT from a live location of its target.

> would benefit A LOT from a live location of its target.

There are very few attack modes which are enabled by this. The ship is a giant slow moving metallic object. You just need to get relatively close. Guidance will easily do the rest.

The real problem is not seeing the instantaneous location of the ship. It's being able to draw a line on a map such that you know it's likely destination and time of arrival.

Treat LLMs as dyslexic when it comes to spelling. Assess their strengths and weaknesses accordingly.

They're literally text generators so that's... troubling

They're text generators, but you can think of them as basically operating with a different alphabet than us. When they are given text input, it's not in our alphabet, and when they produce text output it's also not in our alphabet. So when you ask them what letters are in a given word, they're literally just guessing when they respond.

Rather, they use tokens that are usually combinations of 2-8 characters. You can play around with how text gets tokenized here: https://platform.openai.com/tokenizer

_____

For example, the above text I wrote has 504 characters, but 103 tokens.

For Latin alphabet-based languages, it's pretty similar to how names from those languages are transliterated to Japanese or Korean. You get "Clare" in English and (what, to me, sounds like) "Kurea" in Japanese; equivalent (I'm told!) but not the same. It would be wrong to try to assess the IQ of Japanese (who don't know English) by asking about properties of the original word that are not shared by the Japanese equivalent. On the other hand, English speakers won't ever experience haiku fully, since the script plays a big role in the composition (according to what I'm told... I don't know Japanese, but anime intake exposed me to opinions like this; and even if I'm dead wrong with details, it sounds like a plausible analogy, at least...)

There are incredible authors who happen to be dyslexic, and brilliant mathematicians who struggle with basic arithmetic. We don't dismiss their core work just because a minor lemma was miscalculated or a word was misspelled. The same logic applies here: if we dismiss the semantic capabilities of these models based entirely on their token-level spelling flaws, we miss out on their actual utility.

Will that protect you from the agent changing the code to bypass those safety mechanisms, since the human is "too slow to respond" or in case of "agent decided emergency"?

There are so many use cases for small and super fast models that are already in size capacity -

* Many top quality tts and stt models

* Image recognition, object tracking

* speculative decoding, attached to a much bigger model (big/small architecture?)

* agentic loop trying 20 different approaches / algorithms, and then picking the best one

* edited to add! Put 50 such small models to create a SOTA super fast model

In 20$ a die, they could sell Gameboy style cartridges for different models.

Okay, now _this_ is the cyberpunk future I asked for.

That would be very cool, get an upgraded model every couple of months. Maybe PCIe form factor.

Yes, and even holding couple of cartridges for different scenarios e.g image generation, coding, tts/stt, etc

Make them shaped like floppy disks to confuse the younger generations.

Microsoft

dude that would be so incredibly cool

Great write-up! There are so many directions you can take it to:

* By training on user data, you can source specific model data images, and then train & classify the airplane model. It might require another model, where only the bbox will be the input, together with distance/calculated measurements of the object ("pixel size"), and the orientation of the plane (side? front? belly?).

* Provide alerts/notification of special aircrafts like helicopters, military, airforce-1, etc'

* When bbox is detected, you can run super-resolution upscaling on the photo/stream of images

This is a perfect example of a "bug" actually being a requirement. The travel industry faced a similar paradox known as the Labor Illusion: users didn't trust results that returned too quickly. Companies intentionally faked the "loading" phase because A/B tests showed that artificial latency increased conversion. The "inefficiency" was the only way to convince users the software was working hard. Millions of collective hours were spent staring at placebo progress bars until Google Flights finally leveraged their search-engine trust to shift the industry to instant results.

Is it? I hope I won't step on somebody's else toes: GenAI would greatly help cover existing functionality and prevent regressions in new implementation. For each tool, generate multiple cases, some based on documentation and some from the LLM understanding of the util. Classic input + expected pairs. Run with both GNU old impl and the new Rust impl.

First - cases where expected+old+new are identical, should go to regression suite. Now a HUMAN should take a look in this order: 1. Cases where expected+old are identical, but rust is different. 2. If time allows - Cases where expected+rust are identical , but old is different.

TBH, after #1 (expected+old, vs. rust) I'd be asking the GenAI to generate more test cases in these faulty areas.

Hey, cool initiative!

Worth mentioning in the title that it's CPU-only: >1200 tokens/s on a single thread is impressive.

Have you considered doing optimization iterations like nanogpt-speedrun? Would be interesting to see how far you can push the performance.