Here’s how I think the state of Mac automation on Monterey can be characterized:
Shortcuts has a Run Shell Script action, just like Automator’s
Going in the opposite direction, there’s now a shortcuts command that can run shortcuts from Terminal or a shell script
there’s also a way to run Shortcuts from within AppleScript
tell application "Shortcuts Events" run the shortcut named "Make GIF" end tell
“Shortcuts Events” isn’t available in the current developer beta.
third-party automation tools like Keyboard Maestro, which has a good AppleScript dictionary for running its macros, will fit in well
one oddity left unresolved: built-in scripting languages are being deprecated
Re-installing the system in Big Sur should only rarely be of any value when trying to fix problems. The most likely situation in which this could help is when Safari has serious problems which can’t be fixed by any other means. Intel Macs without a T2 chip can still have external/removable recovery disks which should function as before, although cloning the system is likely to become increasingly difficult.
Intel Macs with a T2 chip can only use external recovery disks if their security protection is downgraded at all times to allow them to boot from external disks.
M1 Macs don’t benefit from external recovery disks. Use their primary recoveryOS on their internal SSD instead. Neither does making their backup disks bootable serve any useful purpose.
SSDs are drives but not "disks" in that they store data on semiconductors instead of a mechanical disk.
SSDs consist of dozens or even hundreds of flash chips ("parallel units"), which can be accessed concurrently.
transparently stripe larger files across the flash chips at page granularity
at the flash level there is not much difference between sequential and random reads
schedule hundreds of random IO requests concurrently in order to keep all flash chips busy
by starting lots of threads or using asynchronous IO interfaces such as libaio or io_uring
SSDs' latency only appears so low [at 10us level]
the actual write latency of NAND flash is about 1ms – 10 times slower than a read. because SSDs are caching writes on volatile RAM
On most data center/server SSDs, write latency cannot be measured directly:
the sync/flush will complete immediately
because a battery guarantees persistence of the write cache even in the case of power loss.
Out-Of-Place Writes: NAND flash pages cannot be overwritten. Page writes can only be performed sequentially within blocks that have been erased beforehand.
It would be too expensive to erase the entire block just to overwrite a single page in-place.
SSDs perform page updates by writing the new version of the page to a new location.
This means that the logical and physical pages addresses are decoupled.
Flash Translation Layer (FTL): A mapping table that translates logical (software) addresses to physical (flash) locations.
Garbage Collection: The old version of overwritten pages must eventually be reclaimed
The number of physical (flash) writes is generally higher than the number of logical (software) writes; The ratio between the two is called write amplification
decreases performance and reduces flash lifetime
depends on the access pattern and how full the SSD is (larger seq writes -> low write amp.)
In general, worst-case write amplification for a fill factor f is
f=0.99 -> WA=100
so most SSDs have hidden spare capacity [overprovisioning], which is typically 10-20% of the total capacity