Today, both Windows and Linux systems are robust and secure enough for daily uses. The dreaded “STOP” message from the blue screen or the “kernel panic” messages from a Linux terminal have become a rare occurrence (after the initial setup).
While system crash due to kernel code bugs is rare, ill-behaved user space code can exhaust system resources and cause the system to hang. And to the end user, there is little difference between a blue screen and an unresponsive user interface, and pretty much the only thing he can do is to do a hard reset.
I have seen Linux/Unix systems running for years without requiring reboot. Rogue processes can be killed without affecting the rest of the system. Windows however, has long suffered from the need of requiring frequent reboot. System updates aside, many rogue processes can cause the system appears to hang and there is no efficient way to kill these rogue processes.
To be more concrete, I will use a small Windows command shell program to illustrate my point.
Suppose you have a batch file c:\temp\test.bat and the code is:
@echo off
start /B c:\temp\test.bat
start /B c:\temp\test.bat
{repeat many times here}
start /B c:\temp\test.bat
What this code does is to recursively call itself and fork off as many instances as possible. When you run this code under windows, you will find out that the whole system seems to stop responding. Because the number of instances of cmd.exe grows exponentially, it will exhaust the available handles in a matter of seconds. So when you try to launch the task manager to kill it, you will find yourself waiting forever for the task manager to show up. Since the cmd.exe process is being created at an exponential rate, windows scheduler is having a hard time keeping up the pace and leaving other vital processes to starve. At this point, even though the operating system is still alive, there is not much the user can do except to wait and hope that the scheduler will eventually give task manager a chance to run so that the rogue process can be killed or resort to reboot.
This situation is handled much better in modern Linux/Unix system (note, historically, Unix handled this poorly and lead to the infamous while(1) fork();). Similar to the windows script we used above, the following script can be used for the same purpose under Linux/Unix:
/tmp/test.sh
sh ./test.sh
sh ./test.sh
{repeat many times here}
sh ./test.sh
When test.sh is invoked, it will start invoking sh at an exponential rate. But the user can suspend (Ctrl + Z) the process or use a kill -9 to kill the parent process.
So in this simple test, we can clearly see that process scheduling in Linux/Unix systems is more robust than in Windows. It also illustrates that rogue processes can cause just as much headaches as blue screens do.
