rmunn

Probably because it's so useful in detecting the "smell" of fraudulent numbers. Fraud is, of course, going to be most common where money is involved, but it can show up in many other places: for example, someone might be tempted to fudge their scientific data if their career depends on getting numbers that aren't quite where they want the numbers to be...

If a number distribution that should be following Benford's Law isn't, that's nowhere close to actual proof of fraud, but it can be a pointer helping you know where to start looking. Because if all the files except this one have numbers that follow Benford's Law, yet this one doesn't, then that's the place where you start digging for other, more positive, evidence of manipulation.

Correct. Index funds are owned by people. For example, I have invested a large chunk of my retirement savings in an S&P 500 indexed fund (as many, many other people do). Whatever stocks the S&P 500 list, are what I end up owning; if I don't want to own one of those, I have to either roll that money into a different fund (which IIRC has limits, can't do that too often without tax consequences) or take the money out (and pay a tax penalty for withdrawing it before retirement).

So whether the index funds do or don't buy a certain stock has direct implications for real, non-millionaire, people.

What you said was "why should Britain have any say in these matters?"; the question of "Did Britain have a need to claim Gibraltar back when?" is a different question entirely, which I am not qualified to answer, having never studied Gibraltar's history. I have studied a little, just a little, of African history, though — and I don't think you would have brought it up as an example if you knew much about it. Because warfare between different nations/tribes/empires/whatever (the terms have been different at various times) was a constant factor. To the point that for some countries, their lives were actually improved by being occupied by a foreign invader. Not all, and certainly not if the foreign invader was Belgium. (Goodness gracious, the Belgian occupation of Congo was a neverending parade of horribles).

But Africa is such a huge continent, with such a variety of countries (each with their own complicated history) that pretty much any generality you can make about Africa is going to be wrong about large portions of the continent, and about large portions of the history of its various countries. It's perhaps not such a good example to talk about an entire complex continent for a simple point, so I should stop rambling on about it. (But I do recommend finding a book about the empire of Aksum sometime. It's fascinating).

Pretty much nowhere was a blank spot on the map before the current inhabitants took it over from the previous ones. Nor was it a blank spot when the previous inhabitants took it over from the ones who came before them. Many places in the world have changed hands dozens of times over the years, belonging first to the Babylonian Empire, then to the Medes and the Persians, then to the Romans, then... and so on, and so on. If you start counting past conquest as needing to be kept track of, you quickly end up in a maze of twisty little battles, all different. Where do you draw the line and say "Okay, well, the Romans count as being the original owners, but not the Medes or the Persians?"

My opinion is that what your distant ancestors did should not be held against you — go far enough back and pretty much everyone has some ancestors who were good people, and some who did flat-out evil things — and that what happened 200 years ago is not a good argument for overturning the status quo. Some exceptions could apply, but "my ancestors took this land by force X number of years ago" is true of just about everyone, everywhere. The only sane thing to do is to hold the past lightly and consider what is the right thing for the current inhabitants today.

Why does Britain have any say in the people who live in, say, Liverpool? Because that's historically been British territory. So what's the difference? Only real difference I can see is length of history (a few hundred years vs. nearly a thousand years). But as far as I'm concerned, a few hundred years vs. nearly a thousand years doesn't make much difference. I'd argue that any territory that has belonged to country X for longer than all of its inhabitants have been alive has a pretty fair claim to be historical territory of country X, and should continue being part of country X unless there's a very good reason otherwise. (Such as a valid treaty, a clear referendum, and so on).

It gets all complicated and messy when war is involved, of course. I'm talking about peaceful transfers of ownership here.

I would add natural navigation barriers such as rivers and lakes (and some, but not all, mountain ranges) to the list of "clean" borders. They're not straight lines, but they're a natural place to site a border.

There are many, MANY islands scattered around Earth's oceans. Not all of them have the resources to be self-sufficient, so any inhabitants have to import goods from somewhere. There are two options: either each island is its own country, or some islands belong to some other country. Given how easy it is to navigate to most islands (some of them are in harder-to-navigate straits), it doesn't make much practical difference whether the owning country is close or far away.

So no, as a general rule I can't agree. I can certainly agree that there are some rather silly cases, but it's just not practical for all islands to be self-governing, so I can't agree with the general rule you propose.

I'm deliberately giving an illustration that shows that relative power throughout most of history had to do with physical strength and weapons, rather than money.

And if you didn't mean that slavery is caused by relative wealth differentials, then saying "... the people who treat them like slaves have even more. It's all about the relative difference between people who are alive today ..." was a very poor way of making your point. So what was your point that I missed, then?

Given the power draw of the GPUs and RAM needed to run those local LLMs, I don't see them being comfortable to hold in one's pocket anytime soon. :-) Not until some not-yet-imagined breakthrough in heat dissipation is made. But a thin client that talks to the local LLM on your private network, that's already possible today. So yes, within the next 5-10 years I fully expect I'll actually want to use an AI assistant on my phone. Currently I go through the settings and turn everything related to Google Assistant off, and do that again after every Android update. But once it's talking to a model that I control, instead of a model controlled by the world's largest advertising company, I'll feel the opposite way about it.

P.S. If "clown-based LLMs" was an autocorrect-assisted typo for cloud-based, it was inspired. :-) If you typed that on purpose, it was also inspired. Have an upvote.

I've been running Claude Code in a VM, where I clone the GitHub repos I want it to work on (they're open source so no login info needed) but have no other credentials. I used to reset the VM every day, but that was getting to be a bit of a hassle so I switched to a monthly reset. But even so, it would be hard for Claude to exfil anything more than what open-source projects I've been working on in the past month (at worst). Which still could tell someone quite a lot about me, but most of that info is already out there available with a Google search — after all, when you contribute to open source projects, your name and email address get stored in immutable Git history.

But after seeing this, I think I might switch to a weekly VM reset rather than monthly.

BTW, if anyone is interested in a decent setup for an AI agent jail, the scripts at https://jai.scs.stanford.edu/arch-vm.html are what I used, plus adding a few more packages to the pacstrap command such as dotnet-sdk. I then made the guest root directory a BTRFS subvolume, so that I can snapshot it. Then spinning up a new VM is a `sudo btrfs subvol snap template-root newvm` command (basically instant) followed by running the `qemu-system-x86_64` command (takes a couple of seconds). It's easy, but I retain complete control over the contents of the VM. It's been great so far.

> I reject all notions that these are mutually-exclusive concepts.

Agreed; just because I "rarely" pull out the calculator doesn't mean I never use it. Sometimes my wife asks me "If this cake recipe calls for filling a 9-inch pan with batter, and makes 3 layers, but I have an 8.5-inch pan and I'm making two layers, then how much should I reduce the recipe?" The π terms cancel each other out in that math, but I still can't do (4.25×4.25×2) / (4.5×4.5×3) in my head faster than I can punch it into the calculator. (It comes out to about 0.59, BTW, meaning she should use either half or two-thirds of the recipe depending on if she wants a slightly thinner or thicker cake).

Bringing this back to the broader LLM-related discussion, the lesson I took away from the Fable kerfluffle was "the model will usually, but not always, be available." You might have an Internet connection hiccup, you might have hit your subscription usage credits for the week and not be willing to pay API pricing, the model might even be taken away from you. (Most of which are problems you won't face if you run a local model, but that's a different discussion). So just as it's important to learn mental math even when you have a calculator as backup, it's important to retain the skill to solve many categories of problems without the LLM, even if you still reach for the LLM for the categories of problems that it can solve faster than you can.

I have a calculator (and many other tools, of course) in my pocket at all times, now... and yet I don't pull it out very often. Because I can add $1.99 + $3.49 faster in my head ($2 plus $3.50 minus two cents = $5.48) than I could get the result by pulling out the phone, swiping my access pattern, tapping the calculator app, and punching in the results. Heck, even if I had a dedicated calculator that only required pulling it out and pressing an On button, I'd still come up with the result faster than I could punch the buttons.

It's definitely worth it for kids to invest the time it takes to learn the little shortcuts involved in mental math: that effort gets repaid many times over during the course of a normal human lifetime.

EDLIN.EXE or bust!

One of my college buddies, when getting set up for a marathon viewing of the trilogy (extended editions, naturally), referred to it as "twelve hours of butt-numbing Tolkien goodness". Exact words: it was more than 20 years ago but that phrase was so evocative it stuck in my memory.

I love gyros; you're making me want to go visit that diner. Do you mind revealing its name and the city it's in? (If you don't want to because that would reveal too much about your own location, I understand perfectly well and have no objections). Odds are I'm nowhere close to it, but sometimes my job takes me to unexpected locations, so I'm always happy to have a list like "If you're ever in Topeka, Kansas, check out (name of hole-in-the-wall burrito joint), they make the best darn burritos I've ever had". (For clarity: that's a made up example, I don't know anything about restaurants in Topeka).

That Evangelion analogy is a good one. I don't necessarily agree with all of it (for example, I think the high synch rate is the weakest part of the analogy, and LLMs can be used as tools with some decent success without needing to plunge into them too deeply), but every piece of it can be coherently argued for (for example, perhaps I'm missing an even higher threshold of success that I could achieve with a higher "synch rate" equivalent, and I just don't know about it).

But kudos for coming up with such an evocative analogy.

> ... human trafficking exists because some people are rich and others are poor ...

No, it doesn't. This is an absurd claim, and nobody intelligent should take it seriously. Human trafficking exists because some people choose to do evil things. There are plenty of relatively-rich people who are actively trying to stop the evil of human trafficking.

Furthermore, just being wealthy has not, historically, made you immune to being made a slave. For just one example, look at the story of Joseph in the Bible. He was his father's favorite son, the heir presumptive to fantastic wealth for his time (that "coat of many colors" his father gave him cost the equivalent of what a sports car would today), and yet his brothers who hated him sold him into slavery while his father wasn't around to protect him. Throughout history, cross-border slave raiding has been a thing, too: it didn't matter how much gold you had tucked under your bed if the Vikings (or whoever) caught you alone, or outnumbered and overpowered your hired guards: once they hauled you away and slapped chains on you, you no longer had access to your wealth, and your life depended on making your captors happy with your work.

To think that slavery, ancient or modern, is caused by relative wealth differentials reveals an abysmal ignorance of both history and human nature.

Seconded, I diff diffs all the time after a rebase or after merging the `develop` branch into my feature branch (which I sometimes do when the rebase would have produced so many merge conflicts over so many commits that it's just not worth the hassle, even using rerere — and since our team routinely uses the GitHub "Squash and merge" button, the develop->feature branch merge gets squashed away and doesn't end up showing up in the develop branch log once the PR is merged). It's the best way I've found to double-check that I didn't made a mistake in merge conflict resolution: does the diff from branchpoint to before-rebase still match the diff from new branchpoint to after-rebase? Yes? Then I probably didn't screw up the merge conflict resolution.

I've recommended https://learngitbranching.js.org/ to so many people. Something about seeing it visually, with the arrows pointing from child to parent, just clicks in the mind where a written explanation doesn't. (Not for everyone, of course: some people understand it quite well from the written explanation. But if your coworkers who don't grok Git are visual learners, https://learngitbranching.js.org/ might be the thing that helps them unlock a deeper understanding of what's going on with branches and HEAD and so on).

The fact that I misread that as "prebase" (I've done the same misreading with "prerelease" in the past, too) is why I prefer `before-rebase`, even though `pre-rebase` is slightly faster to type.

TIL!

The best explanation anyone has come up with for those dodecahedrons was as tools for making jewelry from gold wire. Here's a video by an expert knitter named Amy Gaines in which she demonstrates the process: https://www.youtube.com/watch?v=lADTLozKm0I

The segment where she uses a replica dodecahedron to make a chain from aluminum wire (stiffer than gold, meaning this would have been easier with actual gold) is entirely convincing. It explains everything about the shape of the objects, both the protruding knobs on the end and also the fact that the holes are of different sizes.

I find it really useful to be able to diff two commits, which if you're using a binary format is only possible if you have a meaningful-diff tool for that format. Some formats have one already created, more formats don't. (Though these days, an LLM might be able to produce something suitable).

Good point, that's no more ceremony than moving a branch. I guess I've just gotten "branches are movable tags" so deep into my hindbrain that I absorbed "tags are hard to move". But that's not actually true, and for what I'm doing (save this point in history for a while) a tag makes slightly more sense, semantically, than a branch.

I have so many branches named `temp` or `before-rebase` for exactly that reason; I'm using them effectively as tags, but branches can be moved around with less ceremony than tags (since tags are designed to be for things like v1.2.3, placed once and then almost never moved again), so I usually just do `git branch before-rebase/some-feature` before running a big `rebase -i`.

I've almost never needed to run `get reset before-rebase`. But I have often done `git log -p before-rebase` and compared that to the post-rebase state of the branch, to ensure that the merge-conflict resolution(s) that came up during the rebase haven't accidentally introduced an unintended change.

Unless E remained untouched because it was not rewritten, and ended up staying parented on B instead of getting reparented onto B'.

Which is usually not what you want; most of the time you want E', which is E reparented onto B'. But sometimes you want E to remain untouched and stay parented on the original B. Depends on the situation.

Probably to take a series of commits and decide "this one goes on branch A, this one on branch B", e.g. if you intermingled fixing bug A and B in the same branch, you could more easily go through and assign each commit to a new branch.

The existing workflow for that would be (there are several possible workflows, but this is what I would do):

  git checkout intermingled-branch
  git branch bugfix-A
  git branch bugfix-B
  git checkout bugfix-A
  git rebase -i
  # Edit the file, keep commits that fix bug A, drop commits that fix bug B
  git push origin bugfix-A:bugfix-A
  git checkout bugfix-B
  git rebase -i
  # Edit the file, keep commits that fix bug B, drop commits that fix bug A
  git push origin bugfix-B:bugfix-B

I suspect large companies vs. small companies is another big part of the problem. What I mean is that in small companies, there's usually only one or two layers between the owner(s) and the lowest-level employees. Which means that usually, everyone making management decisions is well aware of the needs of the company and where the company's profits actually come from. It's (usually!) only in large companies with half-a-dozen (or more) layers between the CEO and the workers that you can end up with the kind of empire-building, turf-guarding management that turns a company sclerotic, and makes decisions like selling off / discontinuing a service that was a key part of what their clients needed.

I'd be happier if that gist had been actually written by a human. As it is, I have very little way of verifying, until someone else can confirm the findings, that the AI tool that produced that report didn't hallucinate part or all of it. It might all be accurate, for all I know, the point is that I'm having a hard time trusting an AI-generated report until it's been verified.

Does anyone know if there's anyone else who has reproduced these findings for themselves yet?

Excellent idea; it's good practice to do that with APIs, so why not with command-line tools as well?