The problem here is one of design philosophy that goes back to the early days of unix. It is that, unless user action is needed, unix (and, derivatively, Linux and related programs running on other OSs) are "silent". That is, they don't give continuous update information to show that they're working. They either complete successfully, or they fail If they fail, you get information on the failure. If they succeed, you either get output relating to the completion or you just get a prompt for the next command if success doesn't require any output to the screen.striplar wrote: I bought a very large SD card, and running the partition resizing program took forever, without much feedback to say whether it had died or not. There appear to be two phases to that operation, one took about 5 minutes, the other about 10. Most young people would probably have pulled that plug on it by then, assuming that it had crashed.
What has been done in "consumer friendly" systems is to apply the idea that you need to give *some* sort of progress status so that people can tell that the program is still doing *something*, even if they don't know exactly what.
And, yes, people do tend to get nervous if a program gives no indication that things are going okay, even people who *know* about old unix programs and they way they behave.