最近，我在Linux Foss世界中看到了许多自诩为进步的发展，但实际上却非常恼人，而且适得其反。
结果适得其反，以至于它们实际上造成了重大的倒退、成本，就像GTK+3毁掉了用户体验和我们将永远享受Linux桌面之年的可能性。
GTK+2曾经是Linux桌面应用程序的图形用户界面工具包。它高度可定制，相当轻量级，并且可以从C编程，这意味着几乎任何脚本语言都可以与它接口。
它的开发人员没有以向后兼容的方式改进现有的工具包代码，而是决定引入许多突破性的API更改，这些更改需要大量的移植工作才能使现有的代码库与后续的GTK+3兼容，并且在支持GTK+3的同时保持对GTK+2的支持通常会在源代码库中涉及很多#ifdef混乱，而不是很多开发人员愿意维护的。
此外，GTK+3还取消了许多用户可定制的主题选项，有效地让开发者花费大量精力创作的现有主题中的大部分变得毫无用处。以下是用户抱怨的问题列表。
由于移植GTK+2应用程序需要花费大量精力才能使用GTK+3，许多已完成的GUI应用程序项目由于缺乏人力、对主要开发人员失去兴趣或过早死亡而永远无法移植。这类程序的一个例子是优秀的音频编辑器Sweep，它的上一次发布是在2008年。随着Linux发行版移除对GTK+2的支持，这些应用程序基本上消失在时间的空虚中。
发行版的另一种选择是将(未维护的)GTK+2和GTK+3都保存在自己的存储库中，这样只有GTK+2的应用程序仍然可以使用，然而这会导致这些应用程序的用户基本上需要双倍的磁盘和RAM空间，因为这两个工具包都需要紧挨着放在一起。此外，只有在构建这两个工具包的Glib库中没有突破性变化的情况下，这才能起作用。
更糟糕的是，由于GTK+3的迁移激怒了开发人员，许多人转而使用QT4或QT5，这需要使用C++，所以一个典型的Linux发行版现在混合了GTK+2、GTK+3、GTK+4、QT4和QT5应用程序，每个工具包都会消耗相当多的资源。
微软(TM)知道得更清楚，认为向后兼容是其成功和市场地位的圣杯和根本原因。任何有25年历史的Win95时代的Win32图形用户界面应用程序在最新的Windows(TM)版本上仍然可以正常运行。他们甚至仍然支持使用一些内置仿真器的16位MS-DOS应用程序。
从微软的角度来看，freedesktop.org的决策者决定让GTK+3成为一头完全不同的野兽，这对他们有利。当然，我们被教导永远不要相信恶意，而要相信愚蠢，所以这一举动背后实际上存在真正的阴谋和金钱补偿是不可想象的。否则我们就会成为阴谋论者的疯子，对吗？
虽然蟒蛇2的发育多年来一直非常稳定，但蟒蛇3一眨眼的功夫就发生了变化。在将python3更新到下一个版本之后，现有代码不再像预期的那样工作，这并不少见。
像我这样的许多开发人员更喜欢使用稳定的开发环境，而不是像python3那样不稳定的开发环境。
随着决定停止使用python2，数以千计的基于py2的应用程序将经历与GTK+2应用程序相同的命运，而且没有维护者：它们将被淘汰，并从发行版存储库中消失。这可能比人们预期的要快，因为默认情况下，Python提供了对系统的OpenSSL库的绑定，该库有进行向后不兼容更改的历史。至少，一旦网络就新的TLS标准达成一致，python2将变得完全无用。
将python2移植到python3通常不像GTK+2到GTK+3那样复杂，但由于Python的动态特性，语法检查器不能自动捕获所有代码问题，因此在运行时会遇到很多问题，导致移植的应用程序抛出回溯并停止执行，这可能会带来严重的后果。
许多公司仍有数百万行代码仍在python2中，为了使其与python3兼容，将不得不付出相当多的汗水和费用。
一旦学会了配置Linux盒网络连接所需的少数ifconfig和route命令，就可以轻松地在所有发行版中管理这一方面。现在，有人想出了一个绝妙的主意，宣布ifconfig和好友过时，并提供一个新的、更强大的工具来完成它的工作：IP。
启动网络设备的命令现在是ip link set dev eth1 up，而不是旧的ifconfig eth1 up。这看起来真的像是进步吗？最糟糕的是，该工具的文档并不直观，所以人们基本上不得不向谷歌(Google)寻求例子，展示从一个命令到另一个命令的翻译。
最新的基于system d的发行版想出了像enx78e7d1ea46da或vethb817d6a这样的网络接口名称，而不是传统的eth0。Ubuntu 20上默认分配的接口名称太长了，普通人甚至记不住，任何配置尝试都需要从IP复制/粘贴输出的名称。然而，几乎每个发行版都伴随着这种由Poetting/freedesktop.org口述的胡说八道。
尽管在UNIX上使用的传统构建系统Autoconf有其不足之处，但它的设计方式是只有应用程序开发人员需要全套工具，而消费者只需要POSIX兼容的外壳环境和make程序。
更现代的构建系统，比如cmake和介子系统，根本不关心用户必须安装的依赖项，事实上，根据这一点，介子作者声称他们的目标之一就是强迫用户安装一个尖端版本的python3，这样它就可以被普遍认为是既定的。
CMake是用C++编写的，由70多MB的提取源代码组成，从源代码构建需要大量时间。它是根据调试信息构建的，从3.9.3版本开始占用了434MB的硬盘空间。它的主要原因是它支持Microsoft(TM)Visual Studio(TM)解决方案文件，因此Windows(TM)用户只需点击几下就可以从源代码编译程序。
他们两人的共同点是，他们放弃了著名的用户界面来配置和制作，并发明了自己的NIH解决方案，这需要用户学习另一种方法来构建他的应用程序。
这两个构建系统似乎都获得了像systemd一样的狂热追随者，或者有人付钱让巨魔出现在GitHub上，通过拉请求将GNU autoconf替换为其中任何一个，例如12。有趣的是，与freedesktop.org紧密相连的GNOME已经将将所有组件切换到meson作为其目标之一。它们的移植工作几乎涉及Linux桌面堆栈中的所有关键组件，包括cairo、pango、fontconfig、freetype、。这一努力背后的议程可能是什么？
我们生活在一个时代，在自由和开放源码软件的世界里，人们不得不不断地重新学习东西，转向新的、理应更好的、但更臃肿的解决方案，通常给人的印象是有人从脚下拉地毯。这一领域的许多关键变化都是由一小群决策者强行通过的，他们往往与红帽/侏儒/freedesktop.org关系密切。我们正在购买这款产品。在这一领域，许多关键的变化都是由一小撮决策者强行通过的，他们往往与红帽/侏儒/freedesktop.org关系密切。我们正在购买这款产品。别忘了，红帽(Red Hat)和微软(Microsoft)是合作伙伴，甚至可能拥有相同的股东。