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:

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.