One of my pet peeves is people using the letter "u" to mean micro. Its a greek letter mu, "μ", and seeing as the entire thing is capitalised here, it could also be "Μ" (uppercase greek mu, not uppercase latin M)
The problem is that µ is usually hard to type (unless you have a Greek keyboard or a custom keyboard mapping). This said, although I tolerate stuff like "47 uF" in electronic schematics (also because legacy software didn't even allow the µ symbol), I definitely find horrible to see stuff like "us" instead of "µs" in an article.
Interesting. The header size seems big for low-resources embedded systems (e.g. with only 256 bytes of EEPROM). I'd rather use a file identifier (e.g. a 8-bit number) to identify what a file is doing instead of arbitrary names.
It's one of those things that every embedded dev kind of cobbles together on their own as they discover the limit of struct arrays stored in EEPROM.
Except this one actually seems worse in some ways, because to find a file you have to keep following what is effectively a single linked list of file headers until you find the file you need.
The authors even acknowledge this is just a copy of tar's approach, and even acknowledge that that was in turn done this way due to a lack of random seeking on tape systems at the time. But a microcontroller's EEPROM/SPI/... data is nothing like this? You can just do arbitrary seeks. So I'm not sure what they were going for here.