Well, keeping users from stomping all over other users' processes or critical system processes is certainly a necessary, but not sufficient, condition for being robust. I would also include the ability to prevent badly written apps from doing the same thing. After all, it's not the user's fault if an app has a memory leak or randomly sucks up every available system resource (I remember an X app -- I think the name was technocron -- which was a graphical depiction of the time of day, which showed the terminator line; it pretty completely wedged the console on Sun, Solaris, Ultrix, or Irix systems, and had to be killed by remotely logging in). Not crashing, regardless of what an app does, is clearly critical. Not corrupting storage in the event of a power failure is critical for desktops; servers and mainframes can be expected to have a UPS, even so, techs have been known to accidently disconnect power.
My current list of robust O/S? Beware, I do not work with most of these currently. In the desktop world, FreeBSD and its close relatives (NetBSD, OpenBSD) are probably more robust than Linux. Any of the current commercial *ixen would fit my criteria for robustness. Tandem's non-stop O/S. VMS and possibly OpenVMS (both, alas, nearly defunct), and the IBM mainframe O/S, with VM probably superior to the MVS offspring. Properly configured Windows NT and XP are reasonably robust; although their security features are usually crippled by the tendency for users normally operate with adminstrator privileges or as administrators. In the non-robust arena, some older Max O/S (before they went to a BSD core) had some problems (my sister's pretty much spontaneously destroyed some critical O/S files), Windows 9x (with 95 worse than 98) and ME. Windows 3.1 and before quite fragile.
grammar correction
emc
"Being forced to write comments actually improves code, because it is easier to fix a crock than to explain it. " —G. Steele
| [reply] |
