entrope

Do you think AI subscriptions are analogous to either price gouging during an emergency or ticket scalping? I don't see the similarities.

It is fair to complain that subscription AI usage limits are opaque, but that is at best tangentially related to them being subsidized relative to API prices.

Having a clean DAG still breaks down with recursive Make: if binary X depends on library A, then X's Makefile either has a rule to recurse to A (and then parallel builds of A might happen, even when building from the top level, unless you use -j1) or it doesn't (and then you can only build from the top level Makefile and you might give up parallelism due to granularity of the top-level DAG).

At the time that essay was written, Make was the best runner available, and the only portable one. There are better options now.

Is not describing the feedback part of the feedback you got? You're kind of playing into Forgejo's narrative about governance.

What about those do you think are "shady"? Price discrimination in favor of small customers at the expense of large customers is somewhat common; businesses want customers to buy more of their products, but customers are not obliged to buy more if they like their current deals. Having limits on using finite resources seems even easier to justify.

It depends. My personal experience is with RINEX, a text file format for GNSS observation data. gzip compresses large sets of files by about 4x. Someone named Yuki HATANAKA came up with a compact text format (CRX) that shrinks it by about a factor of 4.1x. You can gzip CRX for a total ratio of almost 12x, or bzip3 it for a total ratio of 17x. But if you combine Hatanaka's technique (essentially higher-order delta coding) with some others, you get a binary format with a compression ratio of 19x that reads faster than the CRX text.

When one's uncompressed RINEX files are 200 GB/day, it's worth some effort to shrink the files, especially if it means they are faster to read.

The 90% and 95% are against some blend of tasks meant to be broadly representative. A pricey model seldom fails a problem that cheap models do well, so there's stratification of tasks by difficulty. Someone doing novel research may be in the "hard" 15% of the blend, where P(solution) goes from one third to two thirds.

On the other hand, if it's cheap to tell whether you got a good solution, and you think the 90 and 95% apply to your task blend, then it's almost always worth trying the cheap model first.

> Shouldn't they be 64 bits on most modern systems then?

Arguably so, but then one would lose the ability to natively name 16-bit integer types because "short" would be 32 bits.

An earlier comment addresses x86-64. AArch64 (pedantically, the A64 instruction set used for AArch64's 64-bit execution mode) is similar, in that addresses are 64 bits wide but ALU instructions typically encode a width bit, called "sf", that selects either 32- or 64-bit data registers and arithmetic. See, for example, https://arm.jonpalmisc.com/latest_aarch64/add_addsub_ext .

I thought it was a really good, clear write-up of a very nice engineering discovery and optimization. If anything, I think an LLM would generate native superscript for the `2^(-r)` expression, so I didn't have an impression of LLM authorship.

Maybe an LLM did the search for what expressions to put in the blocks vs tail of the vectorized collision detection, but that seems like a good place to use an LLM as long as all of the expected bit relations are verified as checked properly.

> Mercury 2.5 is below average in intelligence, but well priced when comparing to other models of similar price.

Well priced when compared to other models of similar price, eh?

Are we allowed to call this slop, even if the output is not directly from an LLM?

Allowing more than one lead byte is a complication of the existing standard. As many others have pointed out, we have plenty of coding space without that (e.g. by allowing 5- and 6-byte UTF-8 again), so the case for the extra complexity is currently not compelling.

> BOMs (and especially the hilarious UTF-8 BOM) are strictly a legacy Microsoft/Windows thing

How should a reader infer the bye order for a UCS-2 or UTF-16 file without a BOM? It seems like one would have to read until finding a code point that would be illegal under one ordering (but files might not include such a code point).

Similarly, a UTF-8 BOM is a useful flag to distinguish UTF-8 from other text encodings. You are right that the ambiguity goes away if those other encodings do, but people don't want to rewrite their legacy files. Some people don't want to use two bytes for common non-ASCII characters, so they are really attached to ISO-8859 or Windows-1252 or koi8r or whatever. CJK languages have their own encodings that are more efficient for their languages. UTF-8 is great for English speakers, but it's a compromise for everyone else, so they might reasonably want incompatible systems for their own use. UTF-8 BOM is a good "magic" sequence to detect encoding as long as people have non-UTF-8 files.

Apple needs better GPUs for "AAA gaming on macOS". My M2 Max is pretty awful at games that run fine on a desktop GPU. An M(whatever) Ultra to play games seems like a debatable value proposition.

LLMs do tend to reinvent the wheel. There are off-the-shelf solutions. In-process, the major options seem to be Meta's Faiss, Spotify's Annoy and Alibaba's zvec. zvec's shared libraries are tens of megabytes in size, and I haven't looked closely at the others. My program is in Go, so even C bindings can be a pain.

If you have billions of vectors, you should use a dedicated implementation: nearest-neighbor algorithms in high-dimensional space can be tricky, and there are a lot of trade-offs. My case is amenable to a simple implementation because I don't need huge scale. That's also why I did not need or want an out-of-process server.

The first one was offered with no explanation and no claimed better alternative. malloc() is probably the simplest interface for generic runtime allocation, and simplicity has a lot in its favor. malloc() does not provide type safety, is susceptible to external fragmentation, and makes it harder to meet the performance goals outlined in the rest of the blog post. So malloc() reflects trade-offs, but saying that the standard API "is the worst memory allocation API to use" should be supported, even if briefly, instead of simply asserted: meeting the goals I listed inflicts other drawbacks, like needing to create and manage separate heaps.

I thought my explanation for the second one was already clear: "Programs should avoid, if possible, [doing X] too often" is a truism because "too often" implies that some reduction is possible. One should leave out the ", if possible," -- although deciding what is "too often" can be challenging and sometimes a matter of taste. (Is reducing allocation frequency by 5% worth doubling the CPU usage or memory usage or code complexity? Maybe in some cases, but often not.)

Having rolled my own RAG the other week, I personally would recommend talking through it with Claude Opus or a similar model.

My baseline was (vibe coded) full-text search with SQLite, and we landed on long chunks with overlap, with a really simple nearest-neighbor search: quantize the index to a sign bit per scalar, which makes it super cheap to estimate dot products, then calculate better (8-bit quant index times native precision for the query) dot products to sort the top documents. A vector database would make sense for a much larger corpus, but I currently have fewer than two million rows. Claude vibe-coded it to use an OpenAI-speaking local inference server and made semantic search an optional augmentation for the full-text search.

"If your documents fit the window, the advice stands: keep truncate." "Two reasons we still chunk even when the document would fit:"

Which advice do you stand by? Obviously, very short content doesn't need chunking, so let's consider a document that fills 75% of the input context.

When chunking, your cost overhead (per token) goes up as the number of new tokens per chunk goes down. That's an argument for longer chunks, although the averaging/smearing point argues for not going too long.

Embedding calculations are effectively prefill: on my cheapo local inference system (32 GB AMD R9700 + 8 GB AMD RX 7600), the older 8 GB card goes about 80% as fast as the bigger card for Qwen3-Embedding-4B (a bit over 19 chunks/second on my usual corpus, blog posts+comments that are mostly well under 32K tokens). So I would suggest that anyone who is limited by CPU embedding models could benefit from even a small local GPU.

For your blog post, I would suggest an explanation of the chunking modes, either in the blog post or as a hyperlink to the docs about them. "truncate" and "sentence" are fairly clear, whereas the others are not. (If "mean" just computes the mean of the embeddings, that seems like a poor choice. The arithmetic at https://www.johndcook.com/blog/2026/09/16/coffee-milk-latte/ might work for single words, but seems likely to break down at the document level. "recursive" and "fixed" are opaque, at least to me.)

If/when I index my team's documents, I will consider a content-aware chunking that fits as many sentences, paragraphs or sections as possible into each chunk, with overlap determined by the level at which the chunk finishes. Content-agnostic chunking is easier to code and more generic, but indexing should respect a document's internal structure.

A lot of the article focuses on problems induced by a 512-token input limit. For example, one needs a lot more chunks with such a small input, especially with overlap. I realize that some embedding models do have input contexts that small, but 8K and 32K are fairly widely supported and reduce chunking-related problems.

For languages like English, there's also usually a lot of redundancy within a text, so 512 tokens might not give a very clear indication of the context. Lots of documents have similar introductions (like "#include <foo.h>\n") that make short contexts and truncation particularly harmful.

Also, "Nothing in the document past that point can ever be retrieved, and nothing anywhere told you." This is user-hostile behavior, even if they didn't want to admit to users that the auto-embedding support was poor.

Finally, the paragraph later on about truncation being "what you already have" reads like Claude talking to the developer, not like a vendor talking to users. But sure, maybe this is a good default for a database searching page titles, chat logs and Xeets?

On the bright side, lots of people will be saved from reading bad prose like "Malloc (libc) is the worst memory allocation API to use" and "Programs should avoid, if possible, allocating/deallocating memory too often". (By definition, "too often" means it can possibly be avoided, and usually that it can practically be avoided.)

So is "does [not] fix [attribute]". The opening dot list has several others, such as "X, Y, Z stay open", "the claim carries its ___", "___ is a statement about ___ and says nothing about ___", and repeating a pair of numbers followed quickly by the difference between them. (It's +0.009!)

And I have to think hard to guess what it probably meant by "Comparability is a property of the reference the results are traceable to, not of the number". I don't think "[X and Y] are different scopes by canonical bytes" even makes sense.

Then I don't understand at all what point you were trying to make about being miserable in our jobs. Cleaning up after bad code has always been part of the job for decades; so has balancing the creation of new technical debt against resource availability.

The whole point of the MS Access reference is that similar situations have been tropes since at least the 1990s. Bad code generated by someone who doesn't know how to program well -- whether that person is supposed to be a professional programmer but is incompetent, or has a different job -- is nothing new, and neither is having competent programmers clean it up. LLMs probably generate more of it, but can also fix a lot of it, or at least patch it up.

A year ago, LLMs were not useful for me as a programmer. Now they are: the models are better, they can use long contexts more effectively, and the harnesses are better at helping the models. Nowadays my job is mostly not programming, but LLMs let me organize and prepare tools in spare time rather than needing days or weeks of attention. I would not trust them on a 200k+ line project -- and Claude Opus 5 has issues even on 50k LOC projects -- but they absolutely can help given good direction and a narrow enough scope.

That's not very close to the argument they make; the claim (right or wrong) is that large corporations often use monorepos, and those are bigger than single-project repositories like used for open source projects.

Their claim is consistent with Google's experience, but somewhat at odds with (say) that of FreeBSD, OpenBSD and NetBSD.

Why "sadly"? The person writing a link should provide enough detail for readers to figure out whether they should follow the link. I rolled my eyes the first time I saw this entry on HN because it just said "Neki" and the (generic) target domain name. A two-word description got added, and that makes it interesting instead.

The same thing as the last word of "That is the difference between 22 and 226 seconds, measured." Techies I know would mostly omit "measured"; the rest would show, not tell.

Drawing a strong conclusion from one shaky data point - classic human tell?

I've been reading John D. Cook for years (maybe decades? "The Endeavour" is one of my oldest bookmarks), and this post was no more written by AI than his oldest posts.

The usual metaphor for keeping customers is a walled garden, right? I think it's useful to distinguish them by default.

2048-bit RSA gives something like 28 more bits of security than 1024-bit RSA has, so it would take about 250 million times as long to factor one 2048-bit key.

> This time the glitch was 33 feet, who's to say next time it couldn't be 3300 feet?

People who study this. This glitch was caused by unusual, structured, widespread distortions in the ionosphere. There's no known mechanism that would cause enough distortion to make the errors 100 times as large. There would also be other symptoms of any unknown cause.

https://claude.ai/share/5cc4163e-9cbf-47cd-9749-4bb55bca42fe if you don't mind discursions into safety of aviation navigation systems. Caution: Do not take the error bounds in the second half as relevant to errors for unaugmented single-frequency users; those users will see much bigger errors.

M-Code is a new encrypted signal that is not fully operational yet. OCX was supposed to enable it.

GPS has always had the P(Y) code, which is an encrypted signal, at a higher chip rate than the C/A code that has been broadcast on L1 forever. The P(Y) code has its own interesting history of (semi-)codeless processing. If the US military is lucky, the history books will close on that by 2030: https://www.gps.gov/codelesssemi-codeless-gps-access-commitm... . (Currently, 21 GPS satellites broadcast L5.)

To meet its integrity budget, a GBAS needs at least triple redundancy, not just a single station.

If one has a lot of patience, one can read the details of how it works at https://elibrary.icao.int/product/299828 (along with SBAS, the ICAO name for what WAAS does; the constellations they can augment; GRAS, a weird hybrid between GBAS and SBAS that apparently went nowhere; ILS; VOR; DME; and VHF marker beacons). Annex 10 Vol I probably doesn't say explicitly that triple redundancy is required, because if you had a single receiver with an MTBF of something like 10 billion hours then you could use just that one.

This particular 30-foot error should go away almost entirely for future receivers that implement DFMC SBAS or ARAIM.