Rebooting a system generally gets it to a known state. That is easiest to test, and bugs in there are often found and fixed. Sometimes a combination of variables can get a system into a state that contains a bug. That bug might not allow you to return to a good state, or you might not know how to.
The bugs can range from a variable overflowing, to memory leaks, to bad code paths in the source code.
When restarting you are initializing again from a blank slate, then proceed from there to assess the situation. Imagine cleaning your work area prior to start your activity or turning a car engine off then turning it on to see how it acts.
Also with finished products the passage from off to on is the most basic function that is supposed to go through before anything else so the (re) initialization is in one way or another a good first step to do in every situation
There are many reasons, but this is the main one: Humans think from start to finish, they can’t help it. So computer programs (which power all those devices) are written with this “start to finish” view. At the beginning, everything is usually pretty easy. After a while with some decisions and stuff it gets complicated. So the farther you get (which means the longer you use a device), the more likely it is somebody lost track of something and there is an error. But if you restart, the device (program) comes back to the start again, whjere everything was nice and easy.
I would even argue this applies to every system humans develop even mecahnical ones.
Computers are state machines. This means that each operation they perform assumes a given state, expects a certain type of input, and produces an expected output. If the state of the machine is not as expected, the result will not be reliable.
An invalid state can arise from multiple issues, such as malfunctioning hardware, or unexpected input. Since the state, and thus the operation of the computer, is largely dependent on each operation proceeding it (eg. the output of an operation operation at step 1 is used as an input in step 4), then errors can compound and at some point the process will not be able to proceed or recover. Resetting the device puts it back into a known good state (it clears any memory and goes back to step 1).
As an analogy, if I gave you a list of directions from A to B that were like, “take 2 steps right, 4 steps forward, 5 steps left” and for whatever reason something goes wrong – maybe you counted the wrong steps, or it rained last night and I didn’t account for a puddle on the path you had to go around – then if you keep following the steps I wrote at some point you’re going to realise something is wrong. You could try to work backwards to fix any errors, but that assumes you even know where the error occurred in the first place. So your best bet is to go back to A and start again.
Computers have ‘state’ – what’s going on inside it at any particular moment. They are also predictable – they do exactly what you tell them to. Unfortunately people writing software make mistakes and when they do the net effect is that the state becomes something that nobody expected it to and stuff starts going wrong. When you off/on something the state gets set back to ‘nothing’, which is what we were expecting, so the software works properly again.
Latest Answers