更喜欢Linux而不是Windows的客观原因

诸如此类的陈词滥调是含糊其辞的，是建立在轶事和传闻之上的。它们会引起没完没了的、不必要的争论，把事实搞得一团糟。

评论一个人喜欢的操作系统很容易，但给出客观、具体的例子却很难。

在警告Windows和Linux都在移动目标的同时，本文档描述了更倾向于使用Linux作为桌面操作系统的一些具体技术原因。

这些理由不是详尽的--也不是故意的--但旨在具有代表性。

本文档不会讨论封闭与开放源码的开发，而是将重点放在功能性上。其他地方有很多关于开放源码的优点和缺点的讨论。

(此外，既然我们现在知道连微软都喜欢开源了，还有什么好讨论的呢？)。

这次讨论只会提到微软和其他公司，只要他们的行为与Windows和Linux的技术能力直接相关。

(顺便说一句，微软在开源世界里得到了很多废话，但对于一家利润依赖于专有软件和设备销售的公司来说，它的行为是典型的。这是经济上的，而不是恶意的。)

讨论的目的是尽可能准确，但代价是技术细节可能导致干燥。

我最熟悉的是基于Debian的Linux发行版系列，所以我的评论必然会更多地涉及这些发行版，但我已经尝试在可能的情况下包括其他发行版。

在本文档中，术语Linux是整个发行版的缩写，包括引导加载程序、内核、外壳、窗口管理器、包管理器等。同样，术语Windows指的是Microsoft Windows NT现代版本的所有默认组件，包括Windows XP、Windows Vista、Windows 7和Windows 8。

支持Linux的许多相同论点也适用于BSD系列操作系统(以及总体上与POSIX兼容的操作系统)，但不幸的是，我对它们中的任何一个都不够熟悉，无法具体评论。

大多数人在桌面上使用Windows，因为它是默认的。很少有人意识到切换到另一个操作系统的好处，愿意为此付出努力的人就更少了。

有兴趣尝试Linux的Windows用户可能很难找到一个连贯的理由这样做，因为对操作系统的比较往往是模糊的、不知情的或基于观点的。

即使是那些了解并选择使用Linux的人也无法很好地向他们的同事解释它的好处，尤其是在不放下Windows用户或Windows应用程序的情况下。

此外，桌面上还有许多Linux的开源替代品，包括名为ReactOS的Windows的二进制兼容克隆。如果只是开源的问题，为什么要费心去学习Linux呢？

即使你不使用Linux或Windows，知道Linux的优势在哪里也是很有用的，因为这些问题与所有操作系统都相关。

如果您是Linux的新用户，本文档旨在告诉您一些您可能不知道的Linux的好处，如果您感兴趣，还可以深入挖掘。

如果你是一名经验丰富的Linux用户，本文档是对这样一种理论的检验，即获得反馈的最快方式是在人们关心的事情上公开犯错。欢迎更正和补充。

本文档并不是说Windows在所有方面都是劣势的，甚至不是说它整体上是劣势的。

相反，这是为了让人们了解为什么有些人选择使用Linux作为桌面操作系统，尽管它有缺点，也可能是为了挑战人们对Linux和Windows的一些误解。

当然，我们欢迎对其进行修改和添加。Windows开发人员最了解它的缺陷和优点。

最后，更好和更差的定义必然是主观的，尽管书名声称是客观的。你可能会由衷地不同意下面的大部分内容，但即使如此，它也可能对你有用。

以下是Windows内核或API导致的特定限制的示例列表。

例如，在Windows 8之前，桌面版本的Windows不能从USB启动。(在运行Windows 8的实时USB时，仍然不能挂载内部硬盘。)。

BartPE LiveCD构建程序是第三方软件，可以在任何版本的Windows上运行，但它只能为Windows XP或Windows Server 2003制作LiveCD。

还有WinBuilder项目，它最接近于现代Windows版本的全功能LiveCD，但安装软件和驱动程序有时仍是一个挑战。

如果虚拟机出现故障，也不用太担心。仅仅因为虚拟机无法正确引导并不意味着您的引导介质不能工作，我看到了一些奇怪的结果，这取决于VM拥有的内存量和我加载的驱动程序。

由于缺少功能齐全的Windows实时版本，因此很难用于确定错误是由硬件还是软件问题引起的，从文件系统损坏或磁盘扇区损坏的机器恢复数据，以及在不创建新硬盘驱动器分区的情况下测试不同版本的OS。

实时版本的Linux是完整的操作系统，能够挂载和重新分区磁盘、连接到互联网并运行Web浏览器，甚至可以在下次启动时保留设置和数据(对于永久的实时USB闪存驱动器)。这使得实时版本的Linux对于从损坏的硬盘驱动器恢复文件、对整个驱动器进行可引导备份、在不加载潜在受损操作系统的情况下扫描磁盘上的恶意软件、区分硬件问题和软件问题以及其他需要临时操作系统的任务非常有用。

有些Linux发行版(如Puppy Linux)非常轻量级，它们默认从RAM磁盘运行，因此磁盘I/O比必须访问旋转硬盘的操作系统快得多。(这是以磁盘空间受RAM限制为代价的。不过，没有理由不能挂载内部或外部驱动器来存储文件。)。

很少有硬件预装Linux的桌面版本，所以Linux的实时版本往往工作得很好，因为它几乎总是这样安装的。

与实时引导类似，Linux通常作为虚拟机运行，因此它能够很好地适应硬件的变化。

物理硬盘上现有的Linux分区可以被虚拟化并在另一台机器上运行，这是Windows所不具备的优点。

与Linux不同，Windows安装不能轻易地从一个硬件迁移到另一个硬件。这不仅是因为微软的激活机制，而且是因为安装的内核和驱动程序依赖于实际的硬件。

问题出在Windows，因为它的驱动程序设置，特别是存储设备的驱动程序设置，是不可移植的。除非修改Windows注册表以强制启动物理机和虚拟机的存储驱动程序，否则每次都很可能会出现0x0000007B停止蓝屏错误，需要恢复或修改注册表才能修复。

尽管内核没有专有驱动程序(例如一些WiFi卡)，但它甚至可以将Linux安装转移到USB机箱，然后直接在同一架构的另一台机器上引导它。

Windows路径长度限制为260个字符，包括文件名。(实际上，它通常更像199个字符。)这不是NTFS或Windows本身的缺陷，而是Windows API的非Unicode版本中的缺陷。

这个问题可以通过使用Unicode版本的API调用来避免，但许多应用程序(例如Windows资源管理器、.NET以及随后的PowerShell)都没有这样做。

当然，在编写良好的软件中，大多数操作系统限制都不是问题。也许Windows路径足够长。MAX_PATH在真正的软件中真的存在问题吗？

但更大的问题是，许多Windows开发者太习惯于解决这个问题，以至于这个问题已经根深蒂固，可能永远不会得到解决。

Linux内核确实有一个可调整的路径名长度限制；它在典型的内核和文件系统中有4096个字符。您可以通过运行以下命令来检查它：

但是，Linux在其上运行的任何文件系统都不会强制执行此限制，因此在尝试解析规范文件路径时，一些libc实现一度容易受到缓冲区溢出的影响。

2008年的POSIX修订版已经解决了这个问题，但在此之前，Linux内核不得不进行非标准修改以避免溢出，并在Linux程序员手册的realpath(3)手册页中警告了这个问题。

这说明，虽然Linux内核开发者小心翼翼地避免破坏外部兼容性，但他们也故意暴露错误的假设，因为错误的假设往往会导致难以修复的错误。这就是为什么Linus Torvalds为Linux选择了异常高的定时器中断频率：

我选择1000的部分原因是为了确保那些认为HZ是100的人会被迅速踢到裤子里。这意味着要做出巨大的改变，而不是微妙的小改变。例如，人们往往会突然说机器已经开机100天了(即使它真的只开机了10天)，但如果它只停机了两倍，这一点可能会被忽视。

Linux使用区分大小写的文件名，因为Unix使用区分大小写的文件名。Unix区分大小写，因为Multics区分大小写。Multics区分大小写，因为ASCII标准既包括大写字母，也包括小写字母。[1]。

电报代码只使用大写字母，或者至少不区分大写和小写。即使是1930年的国际标准ITA2，也使用了一个5位代码，可以在字母和数字之间切换，但不能大写和小写。[2]同样，穿孔卡片只使用大写字母。

早在1959年，人们就提出了大小写不同位模式的编码方案[3]，但并未得到广泛应用。例如，1961年首次安装在洛斯阿拉莫斯国家实验室的IBM7030超级计算机采用的是交错大小写字母的8位编码。[4]然而，7030的字符编码并没有流行起来。

早些时候，ASCII委员会得出结论，6位编码(64位模式)除了需要26个字母和10个数字之外，不足以同时包括控制字符和特殊字符，因此他们决定使用7位编码。然而，ASCII被设计为包括一个有用的6位子集，它只能容纳一个字母表。

对于标准委员会来说，考虑6位、64字符的图形子集是很重要的。如果最终决定列6和列7用于图形，那么列2到列7将包含空间、94图形和删除。但是，即使代码提供了94个图形，标准委员会的一个主要假设是，在可预见的将来，数据处理应用程序将满足于一个单一的字母表(即64个或更少的图形子集)，就像它们过去所做的那样-64个字符的打印机将占主导地位。因此，能够通过简单(而不是复杂)的逻辑从代码中推导出64个字符的单一字母表图形子集是非常重要的。

事实上，一些委员想把剩下的空间留给控制角色。

上一段的结论是基于这样的假设，即7位代码中将包括两个字母，即小写字母和大写字母，而这一决定尚未做出。如果最终决定第6列和第7列将包含控件，那么7位代码中将不包含小写字母。*。

*如果委员会真的决定对第6栏和第7栏进行控制，他们仍然很可能希望提供一个小写字母表。据推测，小写字母表可能是通过替换大小写的方法提供的。

虽然该委员会最初成立于1961年，但直到1963年末，他们才最终同意采用小写字母，这在很大程度上是由于国际电报和电话咨询委员会(CCITT)的影响。

在1963年10月29-31日召开的ISO/TC97/SC2第一次会议上，通过了一项决议，将小写字母分配到第6列和第7列。

然而，国际标准化组织的提案没有包括CCITT认为必不可少的小写字母和五个重音符号。

它可以使文件名更容易理解，例如区分路径/usr/share/X11/Locale/en_US.UTF-8/中的United States缩写("；US&34；)和第一人称复数宾语代词("；us&34；)。

它还允许文件名有更多的可能性，并使文件名比较更简单、更快，因为它们不必偶尔转换为大写或小写。

请记住，文件系统对大小写不敏感比对大小写敏感的工作要多得多。默认情况下，文件系统区分大小写，在最简单的情况下，只能通过大量额外的工程使其不区分大小写。在UNIX中，系统所要做的就是对文件名的前几个字母的ASCII值进行排序。在Mac OS和Windows中，文件系统必须足够智能，能够创建各种字母的同义词--A代表a，以此类推--并进行相应的排序。这需要大量的代码。1984年，在Windows向PC端提供小写字母之前，所有这些都得到了正确的处理，这证明了最初的Mac OS的完备性。

然而，也不乏观点认为，强制文件名区分大小写--甚至通常区分大小写--是一个糟糕的决定。[5]。

严格地说，现代Windows文件名可能区分大小写，但它们不区分大小写，因为用于打开文件的Windows API不区分大小写，即对CreateFiles的默认调用不会启用FILE_FLAG_POSIX_SEMANTICS选项。

但是，Windows自己的NTFS文件系统是保留大小写的。这意味着可以使用Linux挂载NTFS分区，并在与MYFILE.TXT&34；相同的目录下创建名为Myfile.txt&34；的文件，但不能读取或修改这两个文件，至少不能使用标准Windows软件读取或修改这两个文件。

此API行为的存在是为了维护与MS-DOS文件系统的兼容性。[7]MS-DOS是在Tim Paterson的86-DOS(1980年发布)和Marc McDonald的FAT文件系统上构建的，旨在与CP/M兼容。[8][9]CP/M是由Gary Kildall于1973年创建的，也使用不区分大小写的文件名。[12]

小写ASCII字母在内部转换为大写，以符合CP/M文件和设备命名约定。

CP/M手册没有明确说明使用这些约定的原因，但Gary Kildall在英特尔工作时，在一台运行TOPS-10操作系统的DEC PDP-10上编写了CP/M。[10]因此，CP/M和TOPS-10之间有许多相似之处，包括文件名不区分大小写。

(应该指出的是，CP/M也与RT-11相提并论，RT-11是一种用于PDP-11小型机的DEC操作系统，与TOPS-10密切相关[11]，尽管其影响可能没有那么直接。)。

为什么TOPS-10使用不区分大小写的名称？因为用于文件名的DEC SIXBIT编码针对其架构进行了优化。

在FILES-11和RT-11磁盘中使用Rad50。它用于存储16位字中的3个字符。在TOPS-10 36位系统上使用SIXBIT在一个字中存储6个字符。它还允许快速搜索文件名，因为所有名称都在单词边界上(完整文件名CompAir需要2compair，1次掩码操作需要6+3个文件名)。

(CP/M是为8位体系结构编写的，这大概就是它使用8.3文件名而不是6.3文件名的原因。)[13]。

同样，RT-11没有使用ASCII作为文件名，而是使用了一种名为Radix-50的编码，这有助于节省内存。[14]。

这两种编码都不再经常使用，但它们不区分大小写，这是对20世纪70年代硬件的有用优化，一直延续到今天。

在文件名区分大小写方面缺乏一致意见似乎无关紧要，但这给跨平台开发带来了持续的困难。[15][16][17]。

跨平台软件的开发人员试图避免假设文件名区分大小写，但当从Windows移植到Linux或从Linux移植到Windows时，这类问题就会出现。[18]。

Unity无法在区分大小写的文件系统上正常运行(Unity用户如果试图在区分大小写的HFS+文件系统上安装和运行Unity，就会发现这一点)。这主要归功于Unity的资产数据库，以及它如何存储将它们映射到GUID值的路径。当然，在早期我们试图变得聪明一些，但如果您没有设置好实际验证您所做的操作在区分大小写的文件系统上是否有效，那么一些好心的程序员在某个地方抛出一个Tolower()并毁掉聚会是不会失败的。

Multics中的所有内容都区分大小写；Multics允许使用全大写和小写ASCII字符集。

多语言命令名和编程语言使用小写旁路约定，但用户可以在路径名、标识符、用户名等中自由使用大写字母。

显然，BCD没有小写字符，Multics根本没有使用BCD，只是将日志、崩溃和磁带挂载消息从ring0输出到原始SElectric操作员的控制台。

由于Multics文件系统区分大小写，外部名称必须区分大小写，并且在没有太多讨论的情况下，我们选择让所有变量名称区分大小写。

分配给触摸者的代码和小写字母字符之间应该存在简单的对应模式。

摘自第#34；页《256个字符的通用卡片码的建议》，《ACM通讯》，第2卷，第9期，9月1日。1959年。

Mac和Windows用户必须让技术支持人员通过电话向他们朗读文件名。他们必须能够给他们的母亲写一些关于如何打开邮件程序的便条，而不用担心文件名是如何大写的。难道你从来没有对路径中文件夹名称首字母大写的URL感到恼火吗？在得到一个绝对不是404个避风港的回复之前，你难道没有因为电子邮件地址区分大小写而暗地里感到高兴吗？

众所周知，无论是初学者还是有经验的用户，程序中区分大小写都很容易出错。Bob Frankston是Multics的校友，也是VisiCalc的共同发明人，他曾经说过这是Multics给世界造成的最大错误。

基于C的语言最有害的问题之一是它们区分大小写。虽然这个决定在1972年这种语言诞生的时候可能是有意义的，但人们想知道为什么克奈根和里奇的罪行在过去的33年里一直被盲目地延续下去。

除非你有非常令人信服的理由让某些东西区分大小写，否则不区分大小写是一个更人性化的设计选择。设计对机器来说更容易的软件充其量也是有问题的。

让人类学习和处理计算机存储大小写字符的方式不再有任何借口。取而代之的是，软件应该处理人类语言的奇特之处。

既然它似乎是出于观点而不是必要性的表现，可以说区分大小写是现代技术最糟糕的表现方式。

这真的很愚蠢，它会导致大量的问题，而且再也没有什么好的理由来区分大小写了。

.