Simon Tatham

When to automate a repetitive task:

NO-BRAINER: "This is obviously going to be faster to automate than to do it by hand _even once_. Let's automate it right now, and not do it by hand at all."

FORESIGHTED: "Doing it once by hand is faster than automating it, but I'm going to have to do it a lot of times, so it still saves time to automate it first."

NEED A RUN-UP: "I don't yet understand this task well enough to automate it, so I'll do it a few times by hand first to get the idea."

RAN OFF THE RUNWAY: "Great, now I've done this by hand a few times, I think I can automate it reliably! Oh, oops, turned out I only had one more case of it left to do."

TERRIFIED OF RUNNING OFF THE RUNWAY: "This is a one-off, so it would be a waste of time to automate it, I'll just do it manually."
[next day] "Oh, oops, I made a mistake and have to do it again. But it should be fine this time."
[a month later] "Even though I've had to redo it 25 times already, surely _this_ is the last time? So it would still be a waste of time to automate it."

Aaaaah, that rare pleasure when an OS update demands a reboot just _after_ you finish doing a thing that was sprawling across four terminal windows and three other applications.

The existence of 'coreutils' implies the existence of 'reutils', in which the cp, mv and ln commands take their two arguments in the opposite order.

#MathJoke #GeekJoke

This week I saw the weirdest endianness bug I can remember.

In a particular piece of program output, one out of every four characters was in the right place, and the other three were cyclically permuted. For example:

01234567 expected output
12035647 actual output

The 3 and 7 are where they should be, but we've changed 012 → 120 and 456 → 564.

This only happened when the code was compiled and run on a big-endian system. Little-endian, it was fine.

It's not too surprising that an endianness issue involves bytes being misordered, in groups of 4 or 8 which might be the size of a register or primitive integer type. But _that_ particular misordering was very strange!

Perhaps it's unfair to set this as a puzzle. I certainly wasn't able to make sense of it myself without finding the actual bug in the code. But in case anyone does want a hard puzzle, see if you can think of a way for that to happen, before looking at the answer in the next toot!

A "naming things is hard" anecdote I was just reminded of by an old web page:

In the 1990s, when 32-bit versions of Windows were introduced, a new executable file format was needed for native 32-bit programs. The existing 16-bit file format used by Windows 3.x was called "NE", for "New Executable". The 32-bit one was named "PE", for "Portable Executable".

Windows 95 could still run 16-bit Windows 3.x programs. But Windows 3.x couldn't run the newer 32-bit ones. (Ok, there was Win32s, but it had very restricted usefulness.)

In other words, the format called "New" was the older one of the two, *and* the format called "Portable" was the one that didn't work everywhere!

In bare-metal or embedded programming environments, a natural kind of simple example program is one that just counts up from zero, on whatever output device you have – 7-segment display, or in binary on a row of LEDs, etc. But it's quite confusing if the manual refers to it as a "counter example"!