A common topic of discussion amongst even the most casual of computer users is the difference between the various operating systems they use. While popular culture reflects this mostly in terms of a debate on whether Windows-based Intel PCs are superior to their Mac OS-run Apple counterparts (or vice versa), an equally passionate debate includes Linux-based operating systems. To a certain extent, such debates are moot. There is no one perfect operating system, and this is not to suggest a false sense of egalitarianism among them, but rather to highlight the effects of the different design choices made by software engineers.
These design choices have profound implications on what operating systems are best suited for. Stability is perhaps a critical issue in the design of operating systems, and the differences between Linux and Windows in this regard are rather telling of what goals their respective engineers had in mind. Godbey (2006) reports that the “monolithic approach” to design which characterizes Microsoft Windows means that its individual components are not designed to work independently of one another.
As a result, proof checking its code for the purposes of eliminating glitches and bugs is a problematic and tedious affair for Microsoft’s quality assurance people. As a Linux advocate, Godbey denounces Microsoft Windows in this regard due to resulting issues with stability, which, according to Shaffer (2006) requires users to interrupt their systems with periodic reboots to purge the memory of accumulated glitches. On the other hand, the modular nature of Linux’s design means that the functioning of the individual components that make up the operating system are not necessarily contingent upon other components.
This means that glitches in one particular component of the operating system are far less likely to impact other components negatively. Godbey claims that this makes Linux superior in the area of stability, allowing it to fulfill a server role in computer networking because it, as Shaffer (2006) notes, does not necessitate reboots as frequent as Microsoft Windows, and can therefore run longer without interruptions. “So, to put it all together: each piece of a Linux system is independent of the rest of the system. In Windows, each part of the system depends on all the other parts.
And like a house of cards: if one part fails, the whole thing collapses (as we see often with the ‘Blue Screen of Death’). In Linux, if one part fails, the rest of the system keeps running and the failed process is restarted automatically. ” (Godbey 2006) Still, Microsoft maintains a larger registered market share, not just because Windows operating systems come pre-installed with most pre-built PCs sold, but because casual users are drawn to the intertwined functionality of applications – the same functionality built into the kernel that permits the aforementioned stability problems in the first place.
However, stability problems usually result from poorly written programs rather than a lack of fool proofing in the operating system itself. Poorly written programs can compromise O/S integrity and it becomes necessary for mechanisms to be present that enable users to terminate offending programs. Windows presently makes primary use of the Windows Task Manager while Linux makes use of the KDE System Guard in a similar capacity.
Because Windows is founded on a design ethos of broad backwards compatibility and hardware compliance, it relies upon an expansive library of drivers in order for it to be able to interface with a highly diverse array of devices. As a result, Windows XP is capable of running on PCs using myriad combinations of parts such as Singaporean motherboards, decades-old legacy soundcards and various media storage formats. The reason behind this broad compatibility is because of the excellent relationships which Microsoft has persistently maintained with hardware vendors, as such there is a range of third party device drivers available for Windows.
(Saarinen 2001) However, broad hardware support also translates to an increased likelihood that poorly written device drivers can compromise the operating system’s stability. This is most problematic when it comes to issues concerning graphics or video drivers, which can render Windows non-functional. By contrast, Linux can revert to a text-based system in the event that the GUI fails. Windows also has a command prompt based safe mode for similar circumstances but its functionality in trouble shooting is far more limited than the one used by Linux.
(Minasi 2000; Horowitz 2008) As Wallen (2008) observes: “…the command line will always be an invaluable tool for administration purposes. […] I can’t imagine administering a Linux machine without the command line. But for the end user, this is not necessarily the case. You could use a Linux machine for years and never touch the command line. Same with Windows. You can still use the command line with Windows, but not nearly to the extent as with Linux. And Microsoft tends to obfuscate the command prompt from users.
[…] And if a user does get the Windows command line up and running, how useful is it really? ” Furthermore, the abovementioned concern regarding the necessity or lack thereof for reboots to be made in order to maintain kernel integrity within either operating system is addressed by engineers from both sides of the fence in different ways. At present, Microsoft Windows Vista uses hotpatching technology to reduce downtimes, however no similar measure exists in preceding versions of Windows such as the more ubiquitous Microsoft Windows XP.
Linux on the other hand reboots mostly for the sake of updates made to the kernel. Furthermore, a special utility can update the kernel without a hardware reset, enabling the operating system to maintain functions without being interrupted by a reboot. (Shaffer 2006; Microsoft Tech Net 2008) Persistent stability issues for any operating system eventually get addressed through software updates. However, the two platforms of Windows and Linux differ in this point substantially enough to significantly impact the issue of stability.
In the case of Windows, the code to the operating system remains a closed-source platform, and as such much of its source code is protected as a trade secret. This means that any updates to the system are made available at the pace that is best suited by the company’s software development and support team, and updates are a controlled release affair. Therefore, as the single source for remedies to issues, problems and glitches, Microsoft shoulders the entire responsibility for the stability of their Windows operating systems.
The problem then is that stability issues can only be resolved as quickly as they can attend to it. (Horowitz 2008; Langa 2003; Minasi 2000) Linux on the other hand, is an open-source platform available in multiple variants and configurations which benefits from a broad homebrew user base. Therefore, while the casual users may suffer to some extent due to the steep learning curve required to master the innards of the system, stability issues can be resolved by any solution presented by hobbyist software engineers that have come to familiarize themselves with the operating system.
As a result, many of the stability issues that have come and gone in the history of Linux have been resolved quickly through collaboration among hobbyists and the open-source nature of the code means that the operating system is subject to constant peer review by a broader range of individuals and institutions. Some of these emergent solutions are not perfect, but they go a long way towards stop gapping problems through the incremental introduction of more fool proof solutions provided by the user base itself. (Horowitz 2008; Langa 2003; Minasi 2000)
Another stability concern is the susceptibility to malicious code of both operating systems. While Langa maintains that neither system is inherently more secure than the other, Roberts & Yacono (2003) observe that “code crackers and virus authors” maintain greater interest in “attacking Microsoft systems,” than they do in Linux. Part of this has to do with the greater market share which Microsoft Windows commands in the desktop command: It is far more effective to write malware to target Windows than Linux simply because software engineers can target a greater spread of computer users on that platform than on Linux.
Additionally, the closed source design philosophy which Microsoft favors means that there are fewer code watchdogs scrutinizing the operating system for flaws and applying remedies to it than there are for Linux. This is not just an arbitrary user demographic point to be made, but rather a telling indicator of how open source design can have massive effects on the economy of software updates. Because Linux is open source, any existing flaws are already there in the open for users and hobbyists to be aware of.
Therefore, code flaws are visible upon release and distribution and are usually addressed by distros or by hobbyists as soon as possible, whereas Microsoft tends to keep any design flaws in their operating systems pretty close to the chest in the hopes that no one ‘finds out’. The result is that the code for Microsoft Windows operating systems is expected to be buggy, and it is only a matter of uncovering key vulnerabilities in order to mount an effective virus or malware attack. By contrast, Linux flaws are already on the table and malware authors operate under the assumption that any vulnerabilities will eventually go away.
The window of opportunity for both operating systems is thus, constructed very differently. All in all, Linux based operating systems maintain the upper hand in issues of stability. This is not to suggest that it is, ultimately, the superior operating system. But rather, it benefits from a user base structure that serves these issues much more efficiently, and operates according to a user paradigm that demands greater involvement (as well as a steeper learning curve) with the innards of the system in order to implement more responsible controls to the system.
Windows, on the other hand suffers from a closed design policy that leaves code problems a mystery while closing off users from taking an active role in the development of solutions to stability.
Works Cited
Godbey, Douglas. “Changes on the horizon? ” Infopackets. 23 February 2006. Retrieved online on December 6, 2008 from: http://www. infopackets. com/news/unix_linux/2006/20060223_changes_on_the_horizon_part_3. htm Godbey, Douglas. “Linux vs. Windows: Stability. ” Infopackets, 13 October 2006. Retrieved online on December 6, 2008 from: http://www. infopackets. com/news/unix_linux/2006/20061013_linux_vs_windows_stability. htm