rav

> For example, it would be interesting to incorporate Ghost Font into CAPTCHA systems, as most systems are easily solved by AI today.

It seems to me like it should be easy enough to take Ghost Font, apply normal video compression techniques, and analyze the compressed signal to recover the visual outline of the letters, which you would then analyze with OCR (or an AI I guess ...). In other words, a novel CAPTCHA technique but not necessarily "fundamentally more difficult" than existing CAPTCHA techniques, once the cat-and-mouse game gets going.

Today I learned that jq -Rrj is a shorter command line for doing the same as tr -d '\n'.

Not the first time that a Nature publication's "too good to be true" results turn out to be based on simple programming errors... Nature 532, 210 (2016) was retracted after it was shown that a hand-coded gradient function, used in gradient descent, had a simple sign error (details in arXiv 2003.05808).

There's a note at the end:

> As always, this blog post is written by me, without any AI, so all errors are my own.

However, the illustrations in the post are clearly made by generative AI, are they not?

> Of course, if you're implementing POSIX vi, there are quite a few features that have aged poorly, like roff/troff macros and line-editing

What do you mean by "roff/troff macros"?

EDIT: Ah, you're probably talking about the "section-wise" movements, defined in POSIX with language like "A line whose first character is a <period> and whose second and third characters match a two-character pair in the 'sections' edit option (see ex)" - that's the first time I've stumbled upon the 'sections' and 'paragraphs' options in the Vim manual ... Very quaint!

How is it "50-90%" savings? If a given application doesn't repeat its queries, surely there's nothing to save by caching the responses?

You can rewrite it using let-or-else to get rid of the unwrap, which some would find to be more idiomatic.

    let value = Some(param.as_ref()) else {
      // Handle, and continue, return an error etc
    }
    // Use `value` as normal.

At the moment it seems like you can avoid AI search results by either including swear words, or by using 'minus' to exclude terms (e.g. append -elephant to your search query).

I often run rm -rf as part of operations (for reasons), and my habit is to first run "sudo du -csh" on the paths to be deleted, check that the total size makes sense, and then up-arrow and replace "du -csh" with "rm -rf".

My suggestion: Change the color of visited links! Adding a "visited" color for links will make it easier for visitors to see which posts they have already read.

On a small team I usually already know who wrote the code I'm reading, but it's nice to see if a block of code is all from the same point in time, or if some of the lines are the result of later bugfixing. It's also useful to find the associated pull request for a block of code, to see what issues were considered in code review, to know whether something that seems odd was discussed or glossed over when the code was merged in the first place.

Ooh, core.hooksPath is quite nifty. I usually use something like

         ln -sf ../../scripts/git-pre-commit-hook .git/hooks/pre-commit

which simply adds a pre-commit symlink to a script in the repo's scripts/ dir. But hooksPath seems better.