You don't have to wait for updates to newer versions to get dd to report its progress. The status line that dd prints when it finishes can also be forced at any point during dd's operation by sending the USR1 or INFO signals to the process. E.g.:
ps a | grep "\<dd"
# [...]
kill -USR1 $YOUR_DD_PID
or
pkill -USR1 ^dd
It also doesn't require you to get everything nailed down at the beginning. You've just spent the last 20 seconds waiting and realize you want a status update, but you didn't think to specify the option ahead of time? No problem.
I've thought that dd's behavior could serve as a model for a new standard of interaction. Persistent progress indicators are known to cause performance degradation unless implemented carefully. And reality is, you generally don't need something to constantly report its progress even while you're not looking, anyway.
To figure out the ideal interaction, try modeling it after the conversation you'd have if you were talking to a person instead of your shell:
"Hey, how much longer is it going to take to flash that image?"
The way dd works is close to this scenario.
I've thought that dd's behavior could serve as a model for a new standard of interaction. Persistent progress indicators are known to cause performance degradation unless implemented carefully. And reality is, you generally don't need something to constantly report its progress even while you're not looking, anyway.
To figure out the ideal interaction, try modeling it after the conversation you'd have if you were talking to a person instead of your shell:
"Hey, how much longer is it going to take to flash that image?"
The way dd works is close to this scenario.