Critical Path != Critical Section

I always get the concepts “critical path” and “critical section” confused.

The “critical section” is the part in your algorithm which you must hold a lock for; whereas the “critical path” is an idea from hardware design which relates to the time taken for the longest combinatorial logic that needs to be processed during a clock cycle, thus limiting the frequency you can run your clock at.

Although the terminology “critical path” came from hardware, the same terminology is used in software. ChatGPT has a fairly good write-up on the two uses of the term “critical path”.

I learned a little more about this in Introduction to VHDL for FPGA and ASIC design.

CRC

I watched Ben Eater’s videos How do CRCs work? and Checksums and Hamming distance (the full course is Learn about error detection) then found the Wikipedia page: Cyclic redundancy check.

Also of interest:

Keyspace on the back of an envelope

One question that always plagues me: should I use 32-bit or 64-bit keys. I can never make a firm decision on this point. But I’ve just done some back of the envelope calculations in thinking about it.

If you issued one identity per second, every second of every day, it would take 136 years to exhaust the keyspace.

If you issued one thousand identities per second, it would take 50 days to exhaust the keyspace.

Computer coffee table

Here’s something fun. I had a computer sitting on the floor in my lab for a few months while I waited for some parts to arrive so I could service it. In the intervening time I discovered that it was rather handy, and functioned as a small “coffee table” in the center of my room which was good for storing books and magazines on. So I taped some cardboard to the base (for when I stub my toe on it!) and have kept it as a permanent fixture now.
John's new coffee table made from an old computer case

Target then source

I’m surprised it took me this long to figure this out. But there’s a very big problem with a command like this:

rsync var/data/ target:/var/data/

The problem is that in order to type that command, you first have to type the first part of the command, which includes this command:

rsync var/data/ target:/

That first part of the command is in fact a valid command, and if you pressed ENTER accidentally before you had finished typing the whole command, then rsync would begin to replace your entire root file system with the contents of var. That’s the sort of thing that will ruin your day.

So from now on, when I write command-line tools, I will nominate the target *before* the source, and if both the target and source are not specified then I will return an error.

p.s. Yes, the reverse problem exists, that when you nominate the target first you can still fuck up with the source, but given that you are operating on the target from the source, if you get the source wrong, you can just fix your command and run it again and it will be fixed up.