Objective reasons to prefer Linux to Windows

Introduction

"Linux is more stable and reliable."

"Linux is more secure and private."

"Linux is faster and less bloated."

"Linux is more flexible and customizable."

"Linux gives you more control over your computer."

Stop it.

Clichés like these are vague and wishy-washy, and they are founded on anecdotes and hearsay. They cause endless, unnecessary debates and make a muddle of the facts.

It's easy to opine about one's preferred operating system, but harder to give objective, concrete examples.

With the caveat that both Windows and Linux are moving targets, this document describes some specific technical reasons to prefer using Linux as a desktop operating system.

These reasons are not exhaustive—and not meant to be—but aim to be representative.

This document will not cover servers, phones, or embedded devices.

This document will not cover closed vs. open source development, but will instead focus on functionality. There is plenty of discussion of the advantages and disadvantages of open source elsewhere.

(Besides, what is there to discuss when we now know that even Microsoft loves open source?)

This discussion will only mention Microsoft and other companies in so far as their actions are directly relevant to the technically capabilities of Windows and Linux.

(As an aside, Microsoft gets a lot of guff in the open-source world, but its behavior is typical for a corporation whose a bottom line relies on sales of proprietary software and devices. It's economics, not malice.)

The discussion is intended to be as accurate as possible, at the cost of possible dryness due to technical detail.

I am most familiar with the Debian-based family of Linux distributions, so my remarks will necessarily touch on these more, but I have tried to include other distributions when possible.

In this document, the term "Linux" is shorthand for the entire distribution, including bootloader, kernel, shell, window manager, package manager, etc. Similarly, the term "Windows" refers to all default components of modern versions of Microsoft Windows NT, including Windows XP, Windows Vista, Windows 7, and Windows 8.

Many of the same arguments in favor of Linux also apply to the BSD family of operating systems (and POSIX-compliant operating systems in general), but unfortunately I am not familiar enough with any of them to comment specifically.

Why write this?

Most people use Windows on the desktop because it's the default. Few are aware of the benefits of switching to another operating system, and even fewer are willing to put in the effort to do so.

A Windows user interested in trying Linux will probably have difficulty finding a coherent reason to do so, since comparisons of operating systems tend to be vague, uninformed, or opinion-based.

Even people who know and use Linux by choice may not do a good job of explaining its benefits to their colleagues especially without putting down Windows users or Windows applications in general.

Also, there are many open source alternatives to Linux on the desktop, including a binary-compatible clone of Windows called ReactOS. If it were just a matter of being open source, why bother with the additional effort to learn Linux?

Even if you don't use Linux or Windows, it's useful to know where Linux has an edge, since these issues are relevant to all operating systems.

If you are a new Linux user, this document is intended to inform you about some of the benefits of Linux you may not be aware of, and to dig deeper if you are interested.

If you are an experienced Linux user, this document is a test of the theory that the fastest way to get feedback is to be publicly wrong about something people care about. Corrections and additions are welcome.

If you are a Windows user:

• This document is not intended to convert you to Linux. (That would be silly.)
• This document does not claim that Windows is inferior in every way, or even that it is inferior overall.
• Instead, this is meant to provide insight into why some people choose to use Linux as a desktop operating system, despite its shortcomings, and possibly to challenge some misconceptions that people have about Linux and Windows.
• Corrections and additions are, of course, welcome. Windows developers are ones who know the most about its flaws and strengths.
• Finally, definitions of better and worse are necessarily subjective, despite the title's claim of objectivity. You may heartily disagree with substantial parts of what follows, but perhaps it may be useful to you, even so.

Intrinsic technical deficiencies of the Windows NT operating system

This is a list of examples of specific limitations that are the result of the Windows kernel or API.

Live booting limitations.

Windows LiveCDs, though they do exist, are hampered by licensing restrictions and technical limitations.

For example, until Windows 8, desktop versions of Windows could not boot from a USB. (And while running a live USB of Windows 8, it is still not possible to mount internal hard disks.)

The BartPE LiveCD building program is 3rd party software that will run on any version of Windows, but it is only able to make a LiveCD for Windows XP or Windows Server 2003.

There is also the WinBuilder project, which is the closest to a fully-functional LiveCD of modern Windows versions, but installing software and drivers is still sometimes a challenge.

If the Virtual Machine fails don’t worry too much. Just because the Virtual Machine fails to boot right does not mean your boot media won’t work, I’ve seen odd results depending on the amount of memory the VM has and what drivers I load.

https://www.irongeek.com/i.php?page=security/winbuilder-win7pe-se-tutorial

The absence of fully functional live versions of Windows makes it difficult to use for, e.g, determining if a bug is due to hardware or software problems, recovering data from a machine with filesystem corruption or bad disk sectors, and testing out different versions of an OS without making a new hard drive partition.

Live versions of Linux are full operating systems, able to mount and repartition disks, connect to the internet and run a web browser, and even retain settings and data on the next boot-up (for persistent live USB flash drives). This makes live versions of Linux useful for recovering files from damaged hard drives, making bootable backups of an entire drive, scanning a disk for malware without loading a potentially compromised operating system, distinguishing hardware problems from software problems, and other tasks requiring a temporary operating system.

Some live Linux distributions, such as Puppy Linux, are lightweight enough that they default to running from a RAM disk, and consequently have much faster disk I/O than an OS that must access a spinning hard drive. (This comes at the cost of disk space being limited by RAM. There's no reason you can't mount an internal or external drive to store files, though.)

Very little hardware comes with a desktop version of Linux pre-installed, so live versions of Linux tend to work very well, since that is almost always the way it is installed.

Virtualization and driver limitations.

Similar to live booting, Linux is often run as a virtual machine, and consequently it is well-adapted to changes in hardware.

An existing Linux partition on a physical hard drive can, with some care, be virtualized and ran on another machine, a virtue which Windows does not share.

Windows installations, unlike Linux, cannot easily be moved from one hardware to another. This is not just due to Microsoft's activation mechanism but the fact that the installed kernel and drivers depend on the actual hardware.

https://www.virtualbox.org/wiki/Migrate_Windows

The problem lies with Windows, in that its driver settings, particularly for storage devices, are not portable. Unless you modify the Windows registry to force start storage drivers for both the physical and virtual machines, you will mostly likely end up with a 0x0000007B STOP blue screen error each time which will require a restore or modifying the registry to fix.

https://askubuntu.com/questions/174581/is-there-any-way-to-boot-windows-7-partition-in-virtual-machine

It's even possible to transfer a Linux install to a USB enclosure and boot it directly on another machine of the same architecture, although the kernel will lack proprietary drivers (e.g. some wifi cards).

Maximum path lengths.

Windows path lengths are limited to 260 characters, including filename. (In practice, it is often more like 199 characters.) This is not a flaw in NTFS or Windows per se, but in the non-Unicode version of the Windows API.

This problem can be avoided by using Unicode versions of the API calls, but many applications (e.g. Windows Explorer, .NET and consequently Powershell) have not done so.

Of course, most OS restrictions are not an issue in well-written software. Maybe Windows paths are long enough. Is MAX_PATH an actual problem in real software?

Judging by the number of bug reports and complaints, the answer appears to be yes.

1. nodejs/node-v0.x-archive#6960
2. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61922
3. https://llvm.org/bugs/show_bug.cgi?id=20440
4. https://bugs.eclipse.org/bugs/show_bug.cgi?id=164186
5. https://bugs.python.org/issue19636
6. https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14228
7. https://social.msdn.microsoft.com/forums/vstudio/en-US/e4a8ee8d-b25d-4b47-8c0c-88329bbece7d/please-increase-maxpath-to-32767
8. https://stackoverflow.com/questions/1880321/why-does-the-260-character-path-length-limit-exist-in-windows
9. https://stackoverflow.com/questions/1065993/has-windows-7-fixed-the-255-character-file-path-limit
10. https://stackoverflow.com/questions/833291/is-there-an-equivalent-to-winapis-max-path-under-linux-unix
11. https://stackoverflow.com/questions/1858907/svn-command-line-utility-will-not-work-if-full-file-name-is-longer-then-256-char
12. https://www.itefix.net/content/rsync-file-name-too-long-91
13. https://web.archive.org/web/20161112033727/http://sqlite.1065341.n5.nabble.com/Path-Length-Limit-on-Windows-td70642.html
14. https://sumedha.blogspot.com/2011/01/svn-checkout-fails-windows-max-path.html
15. http://forums.mozillazine.org/viewtopic.php?f=29&t=263489

But the bigger issue is that many Windows developers are so used to working around the problem that it has become deeply entrenched and may never be fixed.

The Linux kernel does have an adjustable pathname length limit; it's 4096 chars in typical kernels and filesystems. You can check it by running:

$ getconf PATH_MAX /

However, this limit is not enforced by any filesystems that Linux runs on, and consequently some libc implementations were for a while susceptible to buffer overflow when trying to resolve canonical file paths.

The 2008 POSIX revision has addressed the issue, but prior to this the Linux kernel had to make non-standard modifications to avoid overflow, and warned about the problem in the realpath (3) man page of the Linux Programmer's Manual.

This illustrates that while the Linux kernel developers scrupulously avoid breaking external compatibility, they also intentionally expose false assumptions, since false assumptions tend to cause hard-to-fix bugs. This is why Linus Torvalds chose an unusually high timer interrupt frequency for Linux:

I chose 1000 originally partly as a way to make sure that people that assumed HZ was 100 would get a swift kick in the pants. That meant making a _big_ change, not a small subtle one. For example, people tend to react if "uptime" suddenly says the machine has been up for a hundred days (even if it's really only been up for ten), but if it is off by just a factor of two, it might be overlooked.

—Linus Torvalds, Selectable Frequency of the Timer Interrupt (2005)

Filename case-insensitivity.

Linux uses case-sensitive filenames because Unix used case-sensitive filenames. Unix was case-sensitive because Multics was case-sensitive. Multics was case-sensitive because the ASCII standard included both an uppercase and a lowercase alphabet. [1]

Why did ASCII do this? It was a close call, and almost didn't happen.

Telegraphy codes used uppercase only, or at least did not distinguish upper and lowercase. Even ITA2, an international standard from 1930, used a 5-bit code with a shift to switch between letters and figures, but not upper and lowercase. [2] Similarly, punched cards used uppercase letters only.

Encodings with different bit patterns for uppercase and lowercase had been proposed as early as 1959, [3] though they were not widely implemented. For example, the IBM 7030 "Stretch" supercomputer, first installed at Los Alamos National Laboratory in 1961, had an 8-bit encoding that interleaved uppercase and lowercase alphabets. [4] However, the 7030's character encoding did not catch on.

Early on, ASCII committee concluded that 6-bit encodings (64 bit patterns) were insufficient to include both control characters and special characters in addition to the required 26 alphabetics and 10 numerics, so they decided to use a 7-bit code. However, ASCII was designed to include a useful 6-bit subset, which could only fit a single alphabet.

The consideration of a 6-bit, 64-character graphic subset was important to the standards committee. If the ultimate decision was that columns 6 and 7 would be for graphics, then columns 2 through 7 would contain Space, 94 graphics, and Delete. But, even with the code providing 94 graphics, a major assumption of the standards committee was that data processing applications would, for the foreseeable future, be satisfied with a monocase alphabet (that is, a 64- or less graphic subset) as they had in the past---that 64-character printers would predominate. So it was important to be able to derive a 64-character, monocase alphabet, graphic subset from the code by simple, not complex, logic.

—Charles E. Mackenzie, "Coded character sets: history and development" (1980), p.228

In fact, some of the committee members wanted to reserve the remaining space for control characters.

The conclusion of the preceding paragraph is based on the assumption that two alphabets, small letters and capital letters, would be included in the 7-bit code and that decision had not yet been made. If the decision was ultimately made that columns 6 and 7 would would contain controls, then small letters would not be included in the 7-bit code. *

* If the committee did decide for controls in columns 6 and 7, it is still likely that they would have wanted an alphabet of small letters to be provided. Presumably, the small letter alphabet would then have been provided by a caseshift approach.

—Ibid, p.232

Though the committee first formed in 1961, it wasn't until late 1963 that they finally agreed to include a lowercase alphabet, largely because of the influence of the International Telegraph and Telephone Consultative Committee (CCITT).

At the first meeting of ISO/TC97/SC2 in 1963 October 29-31, a resolution was passed that the lower-case alphabet should be assigned to columns 6 and 7.

—Ibid, p. 246

The ISO proposal, though, did not include the lower case alphabet and the five accent marks that the CCITT considered essential.

—Eric Fisher, "The Evolution of Character Codes, 1874-1968", p.22

Why is it useful for filenames to include upper and lowercase?

It can make filenames more intelligible, such as distinguishing between the abbreviation for United State ("US") and the first-person plural objective pronoun ("us") in paths such as /usr/share/X11/locale/en_US.UTF-8/.

It also allows more possibilities for filenames, and makes filename comparisons simpler and faster because they don't have to occasionally convert to uppercase or lowercase.

Bear in mind that it's MUCH more work for a filesystem to be case-insensitive than -sensitive. A filesystem is case-sensitive by default, in the simplest case; it can only be made case-INsensitive through a lot of extra engineering. In UNIX, all the system has to do is sort on the ASCII values of the first letters of the filenames. In the Mac OS and Windows, the filesystem has to be smart enough to create synonyms of various letters — A for a, and so on — and sort accordingly. That takes a LOT of code. It's a testament to the completeness of the original Mac OS that in 1984 this was all handled properly, before Windows even brought lower-case letters to the PC side.

http://xahlee.info/UnixResource_dir/_/fileCaseSens.html

https://archive.md/6AhY9

However, there is also no shortage of opinions that enforcing filename case-sensitivity -- and even case-sensitivity in general -- was a bad decision. [5]

There are also passionate views to the opposite effect. [6]

Laying aside that argument for the moment, why did Windows filenames end up case-insensitive?

Strictly speaking, modern Windows filenames could be case-sensitive, but they aren't because the Windows API for opening files is not case-sensitive, i.e. the default call to CreateFile does not enable the FILE_FLAG_POSIX_SEMANTICS option.

However, Windows' own NTFS filesystem is case-preserving. This means that it is possible to mount an NTFS partition with Linux and make a file called "Myfile.txt" in the same directory as "MYFILE.TXT", but it will not be possible to read or modify both of those files, at least not with standard Windows software.

This API behavior exists to maintain compatibility with MS-DOS filesystems. [7] MS-DOS was built on Tim Paterson's 86-DOS (released in 1980) and Marc McDonald's FAT filesystem, which were designed for compatibility with CP/M. [8] [9] CP/M was created in 1973 by Gary Kildall, and also used case-insensitive filenames. [12]

Lower case ASCII alphabetics are internally translated to upper case to be consistent with CP/M file and device name conventions.

http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch1.htm

The CP/M manual does not state explicitly why it uses these conventions, but Gary Kildall wrote CP/M on a DEC PDP-10 mainframe running the TOPS-10 operating system when he was working at Intel. [10] Consequently, there are many similarities between CP/M and TOPS-10, including filename case-insensitivity.

(It should be noted that CP/M has also been compared to RT-11, a DEC operating system for the PDP-11 minicomputer that is closely related to TOPS-10, [11] although the influence may not have been as direct.)

Why did TOPS-10 use case-insensitive names? Because the DEC SIXBIT encoding used for filenames was optimized for its architecture.

RAD50 was used in FILES-11 and RT-11 disks. It was used to store 3 characters in a 16 bit word. SIXBIT was used on TOPS-10 36bit systems to store 6 characters in a word. It also allowed for a fast file name search since the names were all on word boundaries (full filename compair took 2 compair, and 1 mask operation 6+3 file names).

https://lkml.org/lkml/2002/7/30/257

(CP/M was written for an eight-bit architecture, which is presumably why it used an 8.3 filename instead of a 6.3 filename.) [13]

Similarly, the RT-11 didn't use ASCII for filenames, but rather an encoding called RADIX-50, which helped to save memory. [14]

Neither of these encodings are used much anymore, but their case-insensitivity, a useful optimization on 1970s hardware, endures to this day.

The lack of agreement on filename case-sensitivity may seem insignificant, but it has caused persistent difficulties in cross-platform development. [15] [16] [17]

Developers of cross-platform software try to avoid making assumptions about filename case-sensitivity, but problems of this ilk crop up when porting from Windows to Linux or vice-versa. [18]

For example, the Linux port of the Unity engine has issues with case-sensitive filesystems.

Unity does not properly run on a case-sensitive file system (which is something that Unity users have discovered if they’ve tried to install and run Unity on a case-sensitive HFS+ file system). This is primarily due to Unity’s asset database, and how it stores paths to map them to GUID values. Of course we tried to be smart in the early days, but if you don’t set up a way to actually verify that what you’re doing works on a case-sensitive file system, then it will never fail that some well-intentioned programmer throws a toLower() in somewhere and ruins the party.

Filename restrictions.

In Linux and other Unix-derived operating systems, the only characters that may not appear in the name of a file or directory [21] are the slash / (which is used to delimit paths) and the ASCII null \0 (which is used to terminate strings in C). [22]

Windows has the same restrictions, as well as many other restrictions which are considerably more complex and are partly the result of backwards compatibility with CP/M pseudofiles.

This has had long-term consequences, such as imposing some surprising restrictions on URLs in Microsoft's web application framework, ASP.net (these were relaxed in a later version).

Windows also does not permit filenames to contain colons, due to their use in delimiting drive names like C:\. This causes issues in sharing files across platforms.

For example, a UNIX file name can use a colon (:), but a Windows file name cannot use a colon (:). If a UNIX user attempts to create a file with a Windows illegal character on a Windows Services for UNIX network file system (NFS) share, the attempt is unsuccessful and the UNIX client computer receives an input or output error.

https://support.microsoft.com/en-us/kb/289627

This also makes filenames containing timestamps somewhat inconvenient. Since filenames cannot contain colons, an ISO 8601 timestamp such as 1970-01-01T00:00:00Z cannot be part of a valid filename. Windows software uses various workarounds, such as removing the colon entirely or replacing it with a similar-looking Unicode character. [19]

(It should be acknowledged that on Linux the names of directories in $PATH cannot contain colons either, [20] but such restrictions do not apply to filenames.)

Limited filesystem support.

Windows has built-in support for its own NTFS filesystem, UDF (used for some CDs and DVDs), and the legacy FAT16/FAT32/exFAT family. All other filesystems require installation of third-party software.

Linux has drivers for almost all file systems that can be legally mounted without paying royalties, including ones that don't see much use nowadays, like Amiga file systems. It can also mount FAT and NTFS filesystems, despite Microsoft's lucrative patent licensing deals and ongoing litigation against Android manufacturers and other companies that use the Linux kernel's FAT drivers.

For the system partition, Linux users can choose among the usual ext3 journaling filesystem or up-and-coming filesystems like Btrfs. Unlike FAT and NTFS filesystems, ext3 and Btrfs do not require defragmentation to maintain good performance. (Realistically, though, defragmentation isn't that important for NTFS, either.)

Finally, Linux permits unprivileged users to run their own filesystems via FUSE. This has many practical benefits, such as accessing cloud storage as if it were an ordinary directory.

There is a project to bring FUSE to Windows, but it is no longer maintained and its various forks are not as mature as the Linux implementation.

UTF-16, not UTF-8.

UTF-8 has many practical advantages over UTF-16.

• It is a superset of ASCII, so it is backwards-compatible with existing text files.
• Zero bytes do not appear at any point in a valid UTF-8 representation, so strcpy() still works.
• It is self-synchronizing, i.e. it is possible to resynchronize after a lost or corrupted code point without re-reading the entire string.
• It is more portable because it does not require a byte-order mark and is less likely to be mistaken for other encodings.
• Internet Explorer has been known to have security issues with UTF-16.

If the Windows API were designed today, it would probably use UTF-8. The Unicode Consortium primarily recommends UTF-16 for compatibility with Java and the Windows API.

In principle, UTF-16 would have the advantage of constant time addressing of single characters, but in practice most programming languages do not provide data types for this, with the exception of Go and rust.

File extensions are the sole determiner of filetype.

On Windows, the file extension is the sole determiner of what program runs when opening a given filetype. This makes it easier to dupe a Windows user into unintentionally running malware.

Also, if the file extensions for different filetypes happen to collide, as they inevitably do, one program must take default precedence over the other for that file extension.

For example, there a lot of different file formats with a .dat file extension, but only one application gets to open them by default.

On Linux, filetypes are determined by a combination of filesystem metadata (e.g. execute permissions), heuristics based on file signatures (a.k.a "magic numbers"), and .desktop configuration files with mimetype information (which includes file extensions).

A file's executable status is separate from its file extension, and an executable text file written in a scripting language can control how it is run via the first-line shebang convention, e.g. #!/usr/bin/env python3 -i.

Windows does not support shebang lines, but languages that emphasize cross-platform compatibility, such as Python, have implemented work-arounds.

Ineffectual read-only permissions semantics.

Permissions are a big topic in multi-user computing, and both Linux and Windows have adapted over time, each with various advantages and disadvantages. [23] [24]

However, here is a specific example of a relatively simple, single-user permissions feature: it is sometimes desirable to set old files as read-only, so that they are still easily accessible (i.e. not compressed in a .zip file), but are less likely to be accidentally deleted, moved, or modified.

On Windows, the content of a read-only file cannot be altered, but the file itself can be moved, renamed, or deleted, because the folder it is in cannot have a read-only status.

In Linux, by contrast, a read-only directory cannot have files added to it, and files in such a directory cannot be moved, renamed, or deleted without first removing the read-only status from the directory they are in. Modifications of the contents of the files depend on the individual file permissions.

Architectural deficiencies of the Windows platform

These are limitations of the Windows platform which are not intrinsic to the operating system, but are the result of default behavior or restrictions on the Windows ecosystem.

Limitations on access to external volumes.

When accessing external volumes such as flash drives, Windows assigns different capital letters to each volume, each letter corresponding to a different absolute path root. This is necessary for backwards compatibility with MS-DOS, but it is not without drawbacks.

Perhaps the most obvious problem is that there are only 26 letters in the English alphabet. But what does this mean in practice?

One consequence is that the assigned drive letter may be different when a drive is reconnected. This means that, for example, applications that track recently used files will look for files under the old drive letter, and be unable to find the files.

I have a problem with Word when working with documents on my flash drive. If I insert the drive days later and try to use the recently used file list, Word sometimes says it can’t find the document.

I’ve worked out that when I insert the flash drive it’s not always using the same drive letter – it’s F or G drive but occasionally even later in the alphabet.

How can I change the flash drive letter or, even better, make it appear as the same drive letter each time?

https://office-watch.com/2008/make-a-consistent-drive-letter-or-path-to-a-removable-drive/

Fortunately, there is a solution: NTFS mount points.

Volume mount points are robust against system changes that occur when devices are added or removed from a computer.

https://technet.microsoft.com/en-us/library/Cc938934.aspx

If you're running out of drive letters, one trick is to use a mount point for each logical drive that you are going to bring into Windows; this way, performance can be contained to a logical drive and still conform to your drive letter standards.

[ . . . ]

There are many scenarios in which you would want a large number of drives, such as multiple databases for Microsoft SQL Server or Exchange Server installations. Exchange databases are notorious for needing their own drives per mailbox store and, if you provision out well, you will quickly run out of drive letters.

—Rick Vanover

http://www.techrepublic.com/blog/the-enterprise-cloud/use-mount-points-if-you-run-out-of-windows-drive-letters/

Unfortunately, Windows doesn't use mount points by default for external hard drives or flash drives, possibly because mount points behave slightly differently than drive letters.

The problem is the recycle bin. This "undo" option is maintained with a hidden system file that is on the partition that holds the files being deleted. Unfortuantely, when the command to delete a folder is given, the system attempts to delete the folder using the mount point folder's Master File Table, and not the subfolder's Master File Table. The mount point folder's MFT doesn't host the record, and an access denied message is kicked back to you for having the temerity to try and recycle a directory which apparently doesn't even exist! The only solution for this is to not recycle subfolders and directories, but to outright delete them.

https://web.archive.org/web/20170327135652/https://getyouriton.blogspot.com/2009/08/serious-gotchas-with-mounted-drives-or.html

While NTFS filesystems have a root directory, Windows has no unique root directory; instead, each drive has its own root.

https://stackoverflow.com/questions/151860/root-folder-equivalent-in-windows

My Computer roughly corresponds to a root directory in concept, and looks like a folder when viewed in Windows Explorer, but there is no My Computer folder anywhere on the filesystem. Instead, My Computer is a virtual folder.

Unlike file system folders, users cannot create new virtual folders themselves. They can only install ones created by non-Microsoft developers. The number of virtual folders is thus normally much fewer than the number of file system folders.

[ . . . ]

The file systems of the various disk drives can be seen to be subsets of the larger namespace hierarchy. The roots of these file systems are subfolders of the My Computer folder. My Computer also includes the roots of any mapped network drives.

https://msdn.microsoft.com/en-us/library/cc144090%28VS.85%29.aspx

Unix-based operating systems, on the other hand, have a unique root directory called / [25] and can mount drives (including removable media) as directories anywhere on the hierarchy. This provides uniform access and permission controls to storage volumes without requiring new syntax [27] or knowledge of the underlying hardware.

https://unix.stackexchange.com/questions/93960/why-is-linuxs-filesystem-designed-as-a-single-directory-tree

On Linux, flash drives are mounted under /media/ [26] and are assigned a directory based on their label. If the drive is removed and re-mounted again, the path to the drive will be the same as before unless the partition label has been changed or the drive is manually mounted elsewhere.

File managers on Linux also handle deleting files on flash drives. When a file on an external drive is put into the trash, it goes into a user-specific hidden folder on the drive itself, not the trash in the user's home directory.

Limited default debugging tools.

Windows has limited facilities for debugging a running process. You can analyze the wait chain, or, failing that, create a dump file.

On Linux, you can attach the gdb debugger to a running process, start a logfile that catches all the output, and run a backtrace when the program fails (it's better with debugging symbols, though).

Alternately, if the process is already unresponsive, you can attach strace and see what system calls it makes, and observe how it responds to various kill signals.

There are plenty of Windows programs similar to gdb and strace, [28] [29] but they don't come installed by default, whereas both strace and gdb come with almost all Linux distributions, so system administrators can rely on being able to use them with nearly any Linux box.

Restrictive default file locking.

Windows applications lock files they use by default, so file access is a nuisance by default. If an application is misbehaving and you want to examine a file it is using, this is generally blocked until the application is killed.

This becomes particularly interesting when the files are hidden thumbnails.

This is a known problem with Windows 7 related thumbnail caching which locks hidden files, thus preventing deletion or moving them.

https://superuser.com/questions/537041/action-cant-be-completed-open-in-another-program

The folder rename operation fails because thumbcache.dll still has an open handle to the local thumbs.db file and does not currently implement a mechanism to release the handle to the file in a more dynamic and timely fashion.

https://support.microsoft.com/en-us/kb/2025703

The other common mistake was for linux developers to assume you can delete/move a file while it’s open. This doesn’t work on Windows, because Windows locks the file when it’s open.

https://npf.io/2017/03/3.5yrs-500k-lines-of-go/

By contrast, on Linux it is not unusual for two different applications to share read access to the same file, or for one process to read a file while another process is writing to it, since applications do not lock files by default.

Lack of granular execution access control

Windows does not have a similar concept to sudo/doas/please (sudo, but with regex). Users cannot run arbitrary commands as a given user without knowledge of the alternate user's password (see runas).

This creates difficulty for large multi-user systems when assigning roles without administrator access. Performing tasks that need to step outside of low privilege is not a simple matter without divulging the alternative user's credentials.

Unix systems support the SUID execute bit (normally mode 4755) on a binary which, when executed switches process ownership to the file owner, not the user that executed it. This is sorely lacking in Windows and would change the access landscape if it were implemented, many organisations could then solve many issues where users execute programs as a privileged user when they wouldn't otherwise need to.

Lack of control over desktop environment.

Windows has many ways to customize its appearance; there are many alternative shells and visual themes, and it's possible to change the login shell or run without explorer.exe at all. [34]

There is Windows software for tiling window managers, [30] virtual desktops, [31] focus follows mouse, [32] and special effects to rival Compiz. [33]

Given all these choices and customization options, what functionality could Windows possibly lack?

Here is the problem: the Windows API determines the behavior of libraries like user32.dll, gdi32.dll, and comctl32.dll. Everything in hardware goes through the Windows API, including keystrokes, mouse clicks, and graphics. Thus, the API can be used to restrict what programs can do. [35]

This is not a theoretical problem. Because of Intel's High-bandwidth Digital Content Protection, Windows applications cannot use the graphics card to manipulate windows the way Flip3D does.

https://stackoverflow.com/questions/3848558/what-is-the-api-to-create-applications-like-flip3d

Sometimes it isn't the API, either; on Windows 8 it is impossible to disable the dwm window compositor.

In Windows Vista and Windows 7, desktop composition is disabled in a number of scenarios. In Windows 8, DWM desktop composition is a core operating system component and cannot be disabled. With a few exceptions, desktop composition is always on; it’s started before the user logon and remains active for the duration of a session.

—Windows Dev Center documentation

https://msdn.microsoft.com/en-us/library/windows/desktop/hh848042%28v=vs.85%29.aspx

This was not without controversy.

I understand the choice and it improves the overall experience, but it is going to force us to retire some of our older software, and it tool [sic] many years to overcome the problems caused.

—Dan Ritchie

https://msdn.microsoft.com/en-us/library/windows/desktop/hh848042%28v=vs.85%29.aspx

Linux also has an API, but it is based on the POSIX standard, is not tied to the desktop environment, and is not controlled by a single corporation in the same way that the Windows API is.

Non-resizable dialog boxes.

The single Windows UI library means that accessibility improvements and user interface customization can be difficult to implement.

For example, on Linux, graphical dialog boxes (e.g. those generated by xmessage or zenity) are resizable by default, but on Windows they are non-resizable by default, i.e. WS_THICKFRAME is not enabled by default.

http://eric.aling.tripod.com/PB/tips/pbtip39.htm

Unlike regular windows, most dialog boxes can't be maximized, minimized, or resized. They can, however, be moved.

https://web.archive.org/web/20150429182602/http://windows.microsoft.com/en-us/windows/working-with-windows#1TC=windows-7

This can pose user-interface problems, especially on high-resolution monitors.

It feels so silly to have three acres of screen real estate but be fighting to see three characters hidden by dot-dot-dot in a window not much bigger than a postit note.

—stewardware, January 7, 2011

https://answers.microsoft.com/en-us/windows/forum/windows_7-desktop/cannot-resize-small-windows/160862cf-6e52-4a99-9365-d380491a067d

One workaround for this problem is to run a third-party background process that watches for window creation and mouse click events. [36] [37] [38]

The README is not directly linkable via URL, so here are some of the salient parts:

• What is ResizeEnable?

It's a very ugly system hack that sits in your system tray and attempts to make windows that can't usually be resized, resizeable.

• Why was it written?

It was written following a request from a friend. He runs his PC at a screen resolution above 1280x1024, and was fed up with having to pick items from a list that could only display three items because the window didn't take into account the screen resolution, hence only occupying about 20% of the desktop 'real-estate'.

• How does it work?

ResizeEnable sits in the background and attaches itself into Windows via three 'Hooks'. The first hook is so that it can see which windows are created/destroyed, in which it attempts to alter the window's style so that it can be resized. The second hook intercepts all messages for every single window to see if it is a message associated with resizing a window that it has previously altered the style of. If the message is associated with sizing, it then resizes all the child windows (Buttons, Edit boxes and so on) simply by scaling them to fit the new windows size. Its ugly, but most of the time it works ok. The third hook spots whether the mouse has been pressed in the 'sizing area' of a window and takes care of doing all the work of resizing the window. This hook didn't exist in v1.0 but has been added to make even more windows resize properly.

There are some drawbacks to this approach:

• Known problems

1. Most applications will respond to having their windows resized ok. Well, applications that have followed the guidelines will. <grin>
2. Some applications have, shall we say, problems, when their window has been resized and all sort of visual chaos will be revealed.
3. Some applications won't respond at all, which is rather strange!
4. Certain windows will 'jiggle' as you attempt to resize them, seemingly resizing and then snapping back to their original size. This is annoying, but we're not sure what is causing it.
5. Some versions of Internet Explorer, coupled with certain version of Windows98/NT seemed to crash with v1.0 of ResizeEnable. We don't have that setup on any of our test machines so we can't test it. But, we have done a little bit more work so ResizeEnable is a bit more choosy as to which windows it can work with. So it -might- not crash anymore. If it still crashes, then all we can suggest at the moment is that you upgrade to Internet Explorer 6. We're not Microsoft pushers, but Internet Explorer 6 has better error reporting and shouldn't just explode without warning.
6. Some Microsoft applications have dialogs that can be resized, but none of their contents move. This is down to the fact that the contents of the dialog ARE NOT STANDARD MICROSOFT CONTROLS! They are some bastardisation written specially for the application. They may look like normal buttons/drop downs, but they sure as heck aren't! Hence, ResizeEnable can't tell them to move or resize. Yet again, Microsoft ignore their own codebase and reinvent the wheel. And people wonder why their applications are so big..

Update inertia.

Another consequence of tying the desktop environment to the operating system version and providing a single desktop environment for a given version of Windows is that improvements that require changes to the user interface are often delayed.

UAC

For example, users run as administrator by default in Windows XP and earlier. Microsoft fixed this problem via User Account Control when Windows Vista was released, but the required changes to the user interface were controversial, [39] and many users learned to ignore it or turned it off entirely.

Despite Microsoft ending support for Windows XP in April 2014, a large number of users are still running Windows XP in 2015, many of them as administrators.

Windows 8

The transition from Windows 7 to Windows 8 was controversial, in part because the Metro user interface departed substantially from the previous versions of Windows. [44] [45] [46] [47] [48] [49]

Enterprise customers, in particular, refused to upgrade from Windows 7, citing usability problems. [50] [51]

These examples are relevant not because they show that Microsoft makes occasional mistakes, but to highlight the risks of monoculture and vendor lock-in and to provide contrast to the way that the Linux ecosystem maintains checks and balances.

Linux users can run the latest kernel and applications on a window manager that hasn't changed much since 1987, [40] [41] and some of them actually do so by choice. [42] [43]

This reflects a general distrust of mandatory backward-incompatible updates. When the GNOME developers made controversial changes in GNOME 3, [52] [53] [54] a team forked GNOME 2 to become MATE, which retained the "traditional desktop metaphor". A fork would be impossible if GNOME 2's source code were proprietary.

A fork like MATE will either eventually fade away, continue to coexist with its parent project, or even overtake its parent, depending on the needs of its users.

Crippled multi-user remote access.

Windows remote desktop licensing makes multi-user remote access and sharing of machine resources expensive. By design, multiple concurrent sessions are disabled on all but the server version of Windows, and third-party remote desktop software is not permitted to legally circumvent this limitation. [57] [58] [59]

Note that this is a licensing issue, not a technical limitation of Windows itself, but it compromises the utility of the operating system.

Because Linux is multi-user by design, multiple local instances of the X server are not unusual, even with different desktop environments (e.g. GNOME and KDE can coexist on the same Linux box). X sessions can be accessed remotely using e.g. VNC or X over SSH. Often, two different users will work remotely at the same time on the same machine using different desktop environments.

A multiseat configuration is also possible if the hardware is available. Even on single-user machines this capability of the X server is useful to e.g. run two different desktop environments at the same time.

Also, sometimes Linux users will forego the X server entirely and log in from a text-only virtual terminal (a.k.a tty). This is important to be able to do if the X server crashes or cannot start.

Because the Linux kernel does not rely on the X server to function, the X server can be restarted without rebooting.

If a crash is unrecoverable and it becomes necessary to reboot the kernel, one can do so cleanly even if the X server is unresponsive by using the "Magic Alt-SysRq keys", key combinations which send instructions to the kernel.

(Windows has Ctrl-Alt-Delete, but requires a responding display manager to allow the user to cleanly reboot.)

There is a plethora of window managers [55] and desktop environments [56] to choose from on Linux, even on the same distribution, making it highly customizable to the system's resources and the user's wishes. However, they all use the same X Window System (a.k.a X11) provided by the X server, typically X.org.

The X11 system is by no means perfect; in fact, many former X11 developers are hard at work on its replacement, Wayland, and Canonical (the company behind Ubuntu) is working on a separate but similar endeavor called Mir.

However, X11 has become so pervasive that versions of it power not only Linux desktops but also the BSD family of operating systems and OS X (XQuartz), and it's also been ported to Windows and Android, even though they don't use it as a display manager.

Some notes on performance.

So far, we have avoided the topic of performance almost entirely.

This is because evaluating and comparing performance is a complex and nuanced topic, incorporating at the very least hardware-specific considerations and deep knowledge of every level of software.

It also incorporates psychology, since people don't care if software has good performance if they don't perceive it to have good performance.

As a result, unqualified generalizations about the performance of complex software such as an operating system are nearly always wrong.

There are some things, however, that we do know about relative performance of the Windows and Linux kernels.

First, an anonymous Windows kernel developer stated in 2013 that he believes that Windows has fallen behind in performance because of how Microsoft functions as a corporation. (This developer gave a SHA1 hash of part of the NT kernel as proof, which while not incontrovertible is certainly strong evidence that he is who he claims to be.)

Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening. The cause of the problem is social. There's almost none of the improvement for its own sake, for the sake of glory, that you see in the Linux world.

Granted, occasionally one sees naive people try to make things better. These people almost always fail. We can and do improve performance for specific scenarios that people with the ability to allocate resources believe impact business goals, but this work is Sisyphean. There's no formal or informal program of systemic performance improvement. We started caring about security because pre-SP3 Windows XP was an existential threat to the business. Our low performance is not an existential threat to the business.

—Anonymous Windows NT kernel developer

https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/

Contrast with Microsoft's "Linux Myths" article from 1999.

Myth: Linux performs better than Windows NT

Reality: Windows NT 4.0 Outperforms Linux On Common Customer Workloads

The Linux community claims to have improved performance and scalability in the latest versions of the Linux Kernel (2.2), however it's clear that Linux remains inferior to the Windows NT® 4.0 operating system.

A decade later, Microsoft contributed device driver code to the Linux kernel.

Secondly, testing and optimizing on multiple platforms can yield unexpected performance benefits for both operating systems. When Valve ported Left 4 Dead 2 to Linux in 2012, they discovered that OpenGL on Windows and Linux achieved a higher framerate than Direct3D on Windows.

After this work, Left 4 Dead 2 is running at 315 FPS on Linux. That the Linux version runs faster than the Windows version (270.6) seems a little counter-intuitive, given the greater amount of time we have spent on the Windows version. However, it does speak to the underlying efficiency of the kernel and OpenGL. Interestingly, in the process of working with hardware vendors we also sped up the OpenGL implementation on Windows. Left 4 Dead 2 is now running at 303.4 FPS with that configuration.

—Valve Linux Team

Configuration and software packaging.

While these topics could be included under architectural limitations, they are large enough to deserve their own section.

Default software.

Linux distributions have development tools installed by default, such as a C compiler (usually gcc), build automation (e.g. make), text utilities (diff, patch, grep, find, etc.), and more than one shell (e.g. bash, dash, and csh).

In fact, the POSIX standard requires that these be available. Standards like POSIX make writing and using portable software easier, and standard POSIX tools are unlikely to become obsolete.

On Windows, by contrast, there is no default set of tools that match the POSIX utilities (though certainly not for lack of trying). [60]

The Windows C compiler and build system is not installed by default, even though a zero-price Community version is available.

There is a scriptable shell on all version of Windows (CMD.EXE) but the currently favored Windows shell (PowerShell) was not available by default until Windows 8.

Software configuration: registries and text files.

On Windows, configuration files are not centralized in the user's home directory. The data that retain configuration when upgrading or recovering from data loss are scattered around as .INI text files in unpredictable directories or in the Windows Registry. In principle, applications should put config files in %APPDATA%, but in practice many of them put it in the install directory.

Furthermore, %APPDATA makes no distinction amongst an application's configuration and plugins, history and log files, and cached data.

This makes configuration less robust and harder to adapt to the needs of specific users. Windows developers have noted the many other drawbacks of the registry in particular.

On Linux, most configuration can be done graphically within applications or configuration managers provided by the desktop environment. A lot of it is handled by the package manager. However, there are a variety of possibilities depending on the needs of the people using it.

System administrators, for example, care about system-level configuration files, generally text files in /etc/.

Text files are simple to edit for ad-hoc debugging and automation, easy to diff, easy to backup or version control, and robust against corruption.

User level configuration is stored in dotfiles (hidden folders or files) in the user's home directory, often under the ~/.config/ folder. Plugins and logfiles generally go under ~/.local/share/, and cached data under ~/.cache/.

There are good arguments to the effect that making dotfiles responsible for configuration is problematic. Configuration files would make much more sense if stored in a dedicated configuration folder in the user's home directory, and many applications follow the XDG base directory standard, which is intended to address this problem.

Centralized databases like the Windows Registry are usually unnecessary for configuration. Applications for which text files are a bad choice, e.g. ones which need random access to large amounts of structured data or which require atomic updates, can use, for example, an SQLite database in the user's home directory. In a similar vein, the GNOME desktop provides dconf, which is probably the closest thing to a Windows Registry that Linux has.

Moreover, using ordinary files instead of a database for application configuration has many benefits. Since many configuration files on Linux are textual, they are easy to modify, back up, and diff or merge, which means users can share and benefit from others' customized configurations and more easily accommodate upstream changes.

It also means that migrating to a different Linux distribution is not as painful as starting from scratch, since many applications keep the configuration formats relatively stable and merging in the customizations is usually straightforward. During major Debian upgrades, for example, administrators can choose to adopt new configuration files, keep the old ones, or diff and merge the files into a hybrid.

For example, the RSS reader liferea puts the list of RSS feeds in $HOME/.config/liferea/feedlist.opml, favicons (which can be re-downloaded if necessary) in $HOME/.cache/liferea/favicons/, and the SQLite database containing the actual RSS feeds in $HOME/.local/share/liferea/liferea.db.

This means that backing up the configuration for liferea is as simple as backing up the contents of $HOME/.config/liferea/, and no cache files or big databases are included.

In short, configuration on Linux is better adapted to the needs of its users than on Windows. Ordinary users have the package manager or applications themselves for managing configuration, developers who like to keep their configuration under version control can use tools like GNU Stow, and system administrators can use dedicated configuration management tools like Puppet, Chef, Ansible, SaltStack, etc.

Package manager with signed binaries.

Windows Installer is a software package manager in the sense of installing and uninstalling software, but it does not provide the salient features of modern Linux packaging systems, such as:

• securely retrieving the package from a trusted remote or local repository,
• adding and removing third-party repositories,
• changelogs,
• optional fully automatic non-interactive installation,
• mandatory cryptographic signing of packages, [61]
• backporting security fixes to stable versions,
• licensing metadata,
• and sophisticated dependency management.

To be sure, there is an open-source package manager for Windows, Chocolatey, that is under active development. However, thus far the Chocolatey repository is not as comprehensive as Linux repositories. Here are some examples of packages which are not in the Chocolatey repository (as of July 2015).

• Apophysis fractal flame editor *
• xyscan data extractor *
• HEPHAESTUS periodic table for X-ray spectroscopy *
• EXPGUI XRD analysis *
• DiffPDF PDF comparison *
• xchat IRC client *

(This list isn't particularly significant, it's just example open-source software that I happen to use which has a Windows version.)

Also, the Chocolatey development team acknowledges that it does not currently have package moderation or package signing in place yet, which is significant for overcoming Window's issue with installing software from untrusted sources.

On the bright side, most of the language-specific package managers such as Haskell's cabal, Perl's CPAN, .NET's NuGet, Node.js's npm, Python's pip, and Ruby's RubyGems are available on Windows.

Linux has several mature, general-purpose packaging systems, including Fedora's rpm-based yum package manager, Debian's deb-based apt and dpkg, Arch Linux's pacman, and so on. This is one reason Linux users are less susceptible to malware: they generally install packages that are cryptographically signed by the maintainers, not opaque executables from a website which may or may not use secure HTTP. Even inexperienced users can safely install and uninstall software if it is all from a trusted repository.

Package managers have other benefits, such as avoiding dependency hell while saving the disk space of duplicated libraries. Package managers have decent (though not perfect) security, and provide the ability to upgrade all software at once with a single command (or button if you use one of the many available GUIs). Instead of requiring all application developers to re-implement automatic updates, packaging makes secure, regular updates much more accessible and convenient for users and developers.

Package mangers can make backups easier by decoupling installed applications from stored personal files.

Want to remember which programs you have installed without backing up every single binary? Just save the output of dpkg -L or its equivalent as a text file of installed packages, and voilà, you can restore them later.

If your backup fails or you just want to switch to a different Linux distribution with the same package manager, you can easily get back your installed software by feeding your package manager the package list. All you need is a fresh Linux install and a good internet connection. Meanwhile, you can keep your home directory backed up using cloud storage or physical drives (ideally both), and the backup software doesn't need to run as root since it's only accessing your home directory.

Packaging also makes distributing scripts with library dependencies easier. For example, installing python and matplotlib is simple on Linux, but a pain in the neck on Windows.

Fixing configuration problems with commands instead of GUIs.

Graphical user interfaces are excellent for some kinds of software, but they are clumsy and error-prone for rapidly fixing configuration problems. Many Linux config problems can be fixed by editing a line in a text file or running a few commands in a terminal. Windows configuration generally requires navigating deeply nested GUIs and ticking various checkboxes. This has similar security problems to blindly running commands in a terminal, but in a way that is much less efficient for doing routine configuration tasks.

Graphical user interfaces (GUIs) are helpful for many tasks, but they are not good for all tasks. I have long felt that most computers today do not use electricity. They instead seem to be powered by the "pumping" motion of the mouse! Computers were supposed to free us from manual labor, but how many times have you performed some task you felt sure the computer should be able to do? You ended up doing the work by tediously working the mouse. Pointing and clicking, pointing and clicking.

—William E. Shotts, Jr. "Learning the shell"

In addition, using GUIs for configuration makes user support and documentation significantly more time-consuming. Text is easier to automate, store, transmit, index, and search than screenshots or ad-hoc notations like Tools -> Options -> General Options -> ...

The emphasis on textuality also makes diagnosing problems easier. For example:

• Want to see what disks and partitions are mounts? Run lsblk.
• Want to see which displays you're connected to? Run xrandr.
• Want to see what USB devices are connected? Run lsusb.
• Want to restart your networking daemon? Run sudo /etc/init.d/networking restart.

Another benefit of textuality is using search engines to find similar problems. Many a Linux user has thought they had found a new bug, only to run a quick web search that turned up dozens of users with the same issue. (The Arch Linux BBS forum and bug tracker, for example, tends to be ahead of the curve on bug reports.)

Finally, software configuration can be kept or removed easily. When uninstalling a software package on Debian Linux, the user may either also wipe the system configuration (via apt-get purge) or leave the configuration in place when the application is installed again (via apt-get remove).

Remote administration.

Accessing a Windows machine remotely generally requires remote desktop software. While it is possible to install an SSH server, this must installed and configured on each machine; there is no built-in secure shell access on a vanilla Windows box.

In addition, Windows machines do not respond to ping (ICMP) by default. Arguably, this is the wrong choice. [62] [63]

By contrast, nearly all Linux machines respond to ping and most allow ssh for remote access. Combined with the use of text files for configuration and the simplicity of package management, many tech support and remote administration tasks are easier and faster to resolve when accessing a remote machine running Linux.

Cultural problems.

It might appear at this point that we are throwing objectivity to the wind, but these are practical issues caused by cultural differences, not subjective criticism of Linux/Unix culture vs. Microsoft Windows culture.

Public bug trackers.

Windows and proprietary software in general do not usually maintain a public bug tracker, although there are exceptions [64] [65] [66]. Software companies have strong incentives to keep their issue tracking systems internal due to things like customer confidentiality, security, and public relations.

Because bug trackers for proprietary software are not public, it can be hard to for a user to discern if their problem is shared by others, what they can do to fix it, and whether or not a bug has been fixed in the latest version.

For this reason, many companies maintain a large user support staff. The inefficiencies and pitfalls of this are evident to anyone who's had to set up their home internet connection before. Some companies complement user support with user forums, which have the same issues with signal-to-noise ratio that most forums have.

By contrast, projects like the Linux kernel and the Debian project maintain accountability and clarity by publicly tracking and acknowledging bugs, even when it is embarrassing to do so [67] [68].

Debugging habits.

By requiring or encouraging reboots for installing software or changing configuration, Windows encourages bad habits such as restarting software to make a bug go away, or avoiding using parts of an application as a work-around, rather than reproducing and reporting bugs.

In 2000, when Hotmail switched from FreeBSD to Windows server, a white paper noted this problem:

Windows operations still involves too many reboots. Sometimes they are unnecessary, but operators reboot a system rather than take the time to debug it. For example, a service may be hung, and rather than take the time to find and fix the problem, it is often more convenient to reboot. By contrast, UNIX administrators are conditioned to quickly identify the failing service and simply restart it; they are helped in this by the greater transparency of UNIX and the small number of interdependencies. Some reboots are demanded by an application installation, and are not strictly necessary.

—David Brooks, Microsoft Hotmail Migration Technical Case Study

https://www.theregister.co.uk/2002/11/21/ms_paper_touts_unix/

https://web.archive.org/web/20030206115538/http://remus.softimage.net/hotmail.html

In the long run, this hurts both proprietary and open-source software on the Windows platform.

Malware.

In principle, Linux and Windows users are equally susceptible to malware. Android, for example, runs on the Linux kernel, and there is plenty of malware that targets it.

In practice, though, Windows users are more likely to inadvertently install malware, primarily because of the way they install non-malicious software (see notes on package management). Finding trustworthy sources for software is non-trivial, and requiring ordinary users to do it is harmful in a variety of ways; it tends to encourage a cargo-cult mentality toward security instead of systematic root-cause analysis.

As a result,

• Windows users must spend considerable time and effort detecting and removing malware.
• Windows users may falsely attribute software misbehavior to malware.
• Some Windows users may even confuse failing hardware with malware. [69]

This also has consequences for developers. Because few Linux users experience problems due to malware, they will report bugs caused by the actual applications, not ones caused by malware.

Most Linux distributions use cryptographically secure package managers which is a significantly better security model than downloading unsigned executables over a network and then granting them administrative privileges.

Finally, because Linux is a ubiquitous server operating system, its security is under constant attack, and Linux desktop users benefit from fixes to the vulnerabilities.