为什么 Debian 会变成这样？

共有 191 条讨论

1.     Debian will remove code that “calls home”
       or tries to update software in a way that
       bypasses the Debian packaging system.
   

   感谢上帝。我很高兴有这样一个发行版。

   回复

   1. 大多数优秀的嵌入式发行版都会这么做。例如，SUSE 最近就因为 “calling home ”而禁用了一个软件包，如：did side-leading。https://security.opensuse.org/2025/05/07/deepin-desktop-remo…

      Debian 的确如此。FF 在发布时禁用了遥测技术： https://wiki.debian.org/Firefox

      回复

      1. 不幸的是，这并不完全正确。

         例如，在 OpenSUSE Leap 15.6 上关闭 firefox 时，会启动 “pingsender ”来收集遥测数据：

         https://imgur.com/a/k3Nnbbj

         它已存在多年。其他发行版上也有。

         回复

         1. 有人报告/打开过相关问题吗？也许只是他们不知道而已。

            回复

      2. 我认为 Firefox 许可证不允许他们这么做。我认为只有 Mozilla 制作的二进制文件才能使用 FF 品牌。

         回复

         1. 的确，Mozilla 最近才允许 Debian 为其修改版使用该品牌：https://en.wikipedia.org/wiki/Debian%E2%80%93Mozilla_tradema…

            回复

            1. 最近？差不多是十年前：https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006

               回复

         2. 这就是我们有一段时间使用 IceWeasel 的原因

            回复

   2. 不幸的是，这还不是 Debian 政策的一部分，Debian 中仍有许多不同程度的隐私问题。

      https://wiki.debian.org/PrivacyIssues

      回复

      1. 我不再在服务器或个人电脑上使用 Debian，但事实上，他们自己主办了一个页面来解释 Debian 可能存在的隐私问题，这让我对他们更加信任，在合适的时候向他人推荐 Debian 也更有安全感。

         回复

         1. 这只是一个维基页面，由我和其他一些 Debian 成员/贡献者撰写。别看得太多 🙂

            回复

         2. 你现在用的是什么？Nixos？

            回复

            1. 是的，NixOS 用于所有服务器（家庭实验室 + 专用远程服务器），Arch 用于桌面。

               回复

               1. 在这方面，Arch 是个雷区。

                  回复

                  1. 老实说，你怎么做它就怎么做¯_(ツ)_/¯

                     回复

                     1. Windows 也是你用足够多的注册表黑客就能创造出来的，不过我并不向任何人推荐它。

                        回复

                        1. 好吧，但 Windows 默认装有间谍软件，而且会努力保持这种状态。注册表黑客随时可能停止工作。

                           Windows 对任何与隐私相关的东西都充满敌意。

                           Arch 的默认设置是自己动手。虽然有很多猎枪，但操作系统并不敌对。对我来说，这就是巨大的差别。

                           回复

                        2. 不尽然，有时它会强迫我在关机/重启时应用更新，尽管我并不想这么做。注册表黑客似乎都无法禁止这种行为。我听人说过有一种特殊的 Windows 发行版/版本可以禁用这种功能，但我实在不想重装整个操作系统，这样当我启动 Windows 或离开 Windows 时，就不会被迫等待两次缓慢的更新（一次是现在，另一次是将来我下次启动 Windows 时）。

                           这一切都是因为 Ableton 不愿意支持 Linux :/我理解，只是太糟糕了……

                           回复

                  2. Arch 对我来说是极好的。我非常喜欢使用 Flatpaks，主要将 Arch 用作基础操作系统，只需进行极少的配置更改。

                     回复

                     1. 我正在市场上寻找一款合适的笔记本电脑。我不想扯远了，戴尔或其他 “企业级 ”笔记本电脑是否支持 Arch？

                        回复

                        1. 对一个相当宽泛的问题的简短回答： 是的

                           更多色彩：我在2012年的戴尔Latitude（英特尔，集成显卡）上运行Arch已经好几年了。目前我在联想Thinkpad T14s（第二代，AMD，集成显卡）上运行Arch非常愉快。

                           Arch wiki 上确实有很多关于特定型号 Arch 的页面，一旦你列出了感兴趣的型号，就能得到帮助，比如：https://wiki.archlinux.org/title/Lenovo_ThinkPad_T14s_(AMD)_…

                           回复

                        2. 我有一台戴尔 Vostro 7620，目前正在运行 Arch。即使使用的是 Nvidia 显卡，我也很少遇到问题（只有一次，Nvidia 驱动程序更新导致系统崩溃），所以我觉得还是用 Arch 吧。

                           回复

                        3. 我没怎么试过，但只要避免使用 nvidia 或带有奇怪组件的高级笔记本电脑，就不会有问题。我的建议是选择商务系列，因为它们有更多标准化的外设。如果能保证提供一些 linux 支持就更好了。

                           回复

   3. 虽然出于技术原因，在构建过程中也有类似的策略，但 nixpkgs 中却没有这项策略。

      因此，我可以通过 nixpkgs 在 NixOS 中添加 spotify 或 signal-desktop，但它们不会自动更新。但它们可能会尝试，这就违反了 Debian 的指导方针。

      这是条艰难的界线–我喜欢依赖于某种服务架构的现代商业软件。但我可以肯定的是，在 10-15 年后，这些软件就会因为公司破产或更改服务条款而被破坏。因此，我很欣赏那些不那么容易兴奋的人所坚持的原则，他们关心的是软件包系统的长期健康发展。

      回复

      1. 在尝试更新的过程中，NixOS 上的 Spotify 很可能会显示一些大的错误信息，说它无法安装更新，这导致用户体验相当糟糕，而实际上一切都能按预期运行。为软件打补丁以删除此类错误信息似乎很公平。

         回复

      2. 公平地说，我们（Nixpkgs 维护人员）有时确实会删除或禁用那些会给家里打电话的功能，尽管这并不是政策规定。话虽如此，但如果能成为政策就更好了。以前肯定讨论过这个问题（我猜最近一次是在 devbox 事件之后）。

         回复

         1. 我每次启动 Discord 都会下载东西。所以肯定没有政策来删除这种行为。

            是的，说得好，在 devbox 默认启用人工智能训练时确实讨论过这个问题。不知何故，这里似乎有不止一种打电话回家的行为，因为在其他情况下，这种行为显然是可以容忍的。

            回复

   4. 我很高兴opensnitch也能在Debian trixie中使用，以减轻Debian尚未发现的问题。

      回复

   5. 为什么我不能让 GNOME 停止呼叫主页？ 每次我在 OSX 主机系统上启动带有 GNOME 的 Debian 虚拟机时，都会因为一些奇怪的 GNOME 网络端点连接而弹出 Little Snitch。这是我最讨厌的一个问题。

      回复

      1. 你可以问问 GNOME 团队是否接受补丁。他们可能认为打补丁是不好的。

         回复

      2. 请发送补丁。

         回复

   6. 最近我得知 visidata(1) 电话回家了，尽管很多人要求删除，但 Debian 软件包中的这一功能并没有被禁用，这让我非常失望：

      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001647

      https://github.com/saulpw/visidata/discussions/940

      回复

      1. 维护者在该主题中的回复实在令人沮丧。他们只是一味地描述错误，好像软件包的行为是可以接受的。

         我想知道 Debian 处理这类维护者的流程是什么。

         我希望他们能尽快将 “不给家里打电话 ”作为实际政策。

         回复

         1. 太气人了。开发者只是在找借口，拒绝解决用户真正关心的问题。他们为什么要打电话回家？到底是什么关键用例需要这样的入侵？

            “每天的用户数量是我们在这个项目上工作的动力，否则我们就会觉得自己是在对着一片空白编码”。
            

            所以，他们写代码给家里打电话（默认情况下），然后挖空心思为它辩护……只是为了自己的感受？开什么玩笑？

            回复

            1. > 所以，他们写代码给家里打电话（默认情况下），然后挖空心思为它辩护……只是为了自己的感受？开什么玩笑？

               这比打电话回家做广告好还是坏？

               另外，我觉得把 “获取广告 ”称为 “打电话回家 ”有误导之嫌。你知道 Ubuntu 也是这么做的吗？这比这个更值得愤怒。

               如果有人告诉我，这个软件会给家里打电话，但除了 ping 之外，它并没有传输任何其他信息，那我就会觉得他们在骗我，让我不知道它到底在做什么。

               我并不因为作者希望与喜欢他软件的人建立一点人际关系而感到不快。我也希望看到人们喜欢我做的东西。这是否存在隐私风险？也许吧，但它甚至不在我每天看到的前 1000 条留言中。有更重要的事情要做。

               但是……如果你真的只是想愤怒，我最近写了一个 DNS 服务器，我把它作为家庭系统的默认设置。目前，它会打印每一个请求，你可以试试看。如果你对这件事那么生气，你会被其他你根本不知道的事情吓一跳….，这还只是 DNS 查询，甚至还没有发送遥测数据！

               回复

   7. 这是我最喜欢 Debian 的一点。

      回复

   8. 不过也不能保证他们能抓到所有这样做的软件：D

      回复

      1. 任何此类遗留行为都将成为可报告和可修复的错误。

         回复

         1. 我不确定政策中是否有明确规定，也不确定是否任何团队都能决定该怎么做……

            回复

            1. 政策中还没有规定。

               https://wiki.debian.org/PrivacyIssues

               回复

            2. 但政策并不能保证执行所有可能的情况。

               回复

   9. 所以他们有自己的 Go fork？

      这只是一个可能的例子，还有很多其他的例子都有遥测代码。

      回复

      1. 没有。TFA 中的表述有点过于笼统–Debian 通常不会删除任何 “打回家 ”的代码。软件 “打电话回家 ”是有充分理由的，是的，这包括遥测。事实上，Debian 有自己的 “遥测 ”系统：

         https://popcon.debian.org/

         遥测完全可以接受，只要它是选择性的且不包含个人数据，而这两点都适用于 Go 的遥测，所以没必要分叉。

         回复

         1. > 只要是选择加入且不包含个人数据，遥测是完全可以接受的

            遥测的定义就是包含个人数据。只是敏感程度和使用方式不同而已。另外，“匿名化 ”也是不可靠的，这一点已被反复证明。

            在 popcon 的例子中，我认为 Debian 运行的服务器会收集最低限度的数据，然后汇总，Debian 维护者会使用这些数据来决定在整合软件包、跟上安全更新等方面的工作重点。通常是可以的。

            对于商业软件来说，我认为遥测技术会攫取任何法律允许的/不被用户察觉的数据（随你挑；），供应商会将数据点与唯一 ID 绑定，并将 “感兴趣群体 ”的数据卖给出价最高的人。不行。

            个人偏好：例如，崩溃报告： “报告 “或 ”跳过“（默认 = 跳过），并勾选 ”不再询问”。这样，向供应商提供有用的信息就不费吹灰之力了，而且还能让它不妨碍用户。

            鉴于这一点非常简单，但供应商却一直忽视上述问题（甚至对付费用户也是如此），这实在令人恼火。

            回复

            1. > 根据定义，遥测包含个人数据

               为什么定义中必须包含 PII？我认为 DNF 计数 (https://github.com/fedora-infra/mirrors-countme) 应被视为 “遥测”，但它似乎没有收集任何个人数据，至少按照我对遥测和个人数据的理解是这样。

               我猜，你要么必须能够辩称 DNF 计数不是遥测，要么必须能够辩称它包含 PII，但我看不出你如何能做到这两点。

               回复

               1. IP 是 PII。你点击了服务器，你的匿名性就被破坏了。

                  回复

                  1. 是的，所以供应商一定不能存储它。隐私政策中通常会有类似说明。如果你不相信供应商能做到这一点，那就不要选择发送数据，或者最好不要使用供应商的软件。

                     回复

                     1. 有时，我们不得不或只是想运行我们不了解或不完全信任的开发商提供的软件。这就意味着，在你的威胁模型中，需要将软件开发商视为攻击者，并采取相应的缓解措施。

                        我认为，用户已经无法从本质上信任普通的开发者了。在过去的 20 多年里，关于遥测、给家里打电话、对用户进行 A/B 测试和其他实验的想法，以及从根本上说，让软件做开发者想做的事而不是用户想做的事，已经在很多很多的开发者身上彻底根深蒂固了。这就是为什么真正认真对待隐私问题已成为一个卖点：因为大多数开发者都不重视隐私问题，所以隐私问题才会如此突出。

                        回复

                        1. 我不能说你错了，但我可以说，就我自己而言，如果我不相信开发人员不会用遥测技术坑我，我就不能相信开发人员不会用他们的代码坑我。我想不出在哪种情况下这种信任不是二元的，要么我可以信任他们（在遥测和代码执行方面），要么我在这两方面都不能信任他们。您能描述一下我漏掉了哪种情况吗？

                           回复

                           1. 你并没有遗漏什么。总的来说，我认为你已经无法真正信任绝大多数软件开发人员了。激励机制对用户的影响大得离谱。

                              如果你采取下一步行动 “不要使用你不信任的供应商的软件”，你就会严重限制你可以使用的软件数量。每个用户都可以自行决定这样做是否可行。

            2. popcon 一直存在的问题是，众所周知它并不准确，但因为它是可用的数据，所以人们会根据它做出决定。

               以下机构最不可能使用 popcon

               – 有任何合理隐私政策的组织（包括几乎所有运行超过几台机器的人）

               – 关注隐私的个人

               最有可能开启 popcon 的是：Debian 开发人员，以及第一次安装 Debian 的新用户。

               回复

               1. 是啊，这难道不可惜吗？如果我们不是灾难性地认为遥测数据永远只是为了监视我们，而是认为实际上有值得信赖的项目存在，那不是很好吗？特别是对于自由和开放源码软件（FOSS）项目来说，它们通常没有能力进行广泛的内部用户测试，遥测技术提供了非常有价值的数据，让它们了解软件的使用情况和可以改进的地方，特别是在用户体验方面，许多自由和开放源码软件都严重缺乏用户体验。这个主题就是这种非黑即白思维的最好例证，它认为无论如何都要把遥测技术从软件中剥离出来，这种思维通常是基于某种基本观点，即无论如何都不可能实现匿名，所以为什么还要去尝试呢？这种想法于事无补。我通常会为提供遥测功能的自由和开放源码软件打开遥测功能，因为我希望他们能利用遥测功能来改进软件。

                  回复

                  1. 打开和无法关闭是两码事。

                     回复

            3. > 根据定义，遥测包含个人数据。

               请查阅 “遥测 ”和 “个人数据 ”的定义。后者总是指可识别的个人。

               回复

               1. 几乎所有匿名化方案都是可逆的，所以 “可识别 ”在你的定义中没有任何分量。

                  “个人 “也不重要，除非软件确定它不是被某个人使用。

                  回复

                  1. 根据你的定义，所有数据都是 PII。

                     回复

                     1. 许多公司的隐私政策和客户合同都同意这一点。即使是一个数据包，无论内容如何，都是在发送 IP 地址，而这被许多公司视为 PII。这不是我的观点，而是成千上万份合同的内容。许多公司都希望了解与跟踪员工有关的每一个第三方。偏离这一点就违反了合规要求，可能导致审计失败和罚款。这些政策在服务器上得到严格遵守，而在工作站上则较少，但我认为随着时间的推移，这种情况会有所改变。

                        回复

                        1. 我只能重复上面的话：这与你存储和分析的数据有关。根据你的定义，所有互联网流量都属于 PII 范围，因为其中包含 IP 地址，而这是荒谬的，因为至少在欧盟，对如何处理这些数据有非常严格的规定。

                           如果你有一个nginx日志并存储了IP地址，那么是的：这就包含了PII。因此，解决办法就是：不要存储 IP 地址，问题就解决了。遥测数据也是如此：编写一份隐私政策，说明你不会存储任何有关传输的元数据，并说明你将传输哪些数据（更好的办法是：准确显示你将传输哪些数据）。遥测可以以安全、匿名的方式进行。我想知道那些对此提出异议的人是如何完成工作的。根据你对 PII 的定义，我不知道你怎么能传输任何数据。

                           回复

                           1. 根据你对 PII 的定义，我不明白你怎么能传输任何数据。

                              在服务器端，你不会这样做。你的应用程序只会做它应该做的工作，不会拨出任何数据。所有资源都将托管在数据中心内。

                              在工作站上，这取决于企业政策，如果有已知的数据泄漏，VPN/防火墙会阻止，IT 部门也会通过设置应用程序政策来阻止企业管理的工作站上的数据泄漏。只要遥测的编码方式不是阻断依赖，就不会有问题。

                              这不是我的定义。这是金融行业数以千计的 B2B 合同中的定义。在工作站上的执行仍然很松散，这意味着需要由 IT 部门来锁定。有些公司对此非常重视，有些公司则不以为意。

         2. > 遥测是完全可以接受的，只要它是选择性的，不包含个人数据，这两点都适用于 Go 的遥测，因此没有必要分叉。

            最近情况有所改变。遥测是默认启用的（我想从 Golang 1.23 开始？）

            我是最近在一个没有互联网出口的新虚拟机上遇到类似情况才知道的：https://github.com/golang/go/issues/68976

            https://github.com/golang/go/issues/68946

            如果 Golang 没有完全解决这个问题，我想 Debian 至少应该修改默认设置（如果还没有的话）。

            回复

            1. 它会创建遥测数据，但实际传输是选择性的。

               回复

               1. 在默认配置下试图联系外部遥测服务器是个问题。并非所有不必要的本地聚合数据都会被实际传输，这是另外一回事。

                  回复

      2. “将移除 “的意思是，这是 Debian 维护者打补丁的典型/公认原因之一，如此处 [0] 的意思 4，而不是说保证移除所有遥测数据。

         [0] https://www.merriam-webster.com/dictionary/will

         回复

   10. 这是我两年前从 Ubuntu 转向 Debian 的众多原因之一。另一个原因是快照。

       回复

       1. snap 以及 “桌面版 ”和 “服务器版 ”完全不同的网络实现方式，让我不得不重新开始学习 nix。

          尤其是在 systemd 出现之前，我充其量只能算是个新手，而我在 Ubuntu 的学习过程中又同时尝试了这 3 种巨大的变化（哦，对了，还有容器）。

          我是抱着 “它一定会把我惹毛 ”的期望去体验它的，结果它轻而易举地就超过了我的预期。

          回复

       2. 是啊。Snap 是 Canonical 在 Ubuntu 中植入的所有复杂功能的象征。

          回复

          1. 还有整个 systemd 栈。Canonical的员工获得了足够多的选票，将其强行上传到debian中。

             我改用了devuan。它很棒，但社区因为一些毫无必要的破坏性东西而分裂，这很糟糕。

             回复

   11. 天哪，我真希望有人能把 discord 改成这样。我已经厌倦了每隔一天就通过软件包管理器更新一次，但无论如何，迪斯科舞厅都要下载自己的更新。

       是的，我已经禁用了更新检查。不，这并不能解决问题。

       回复

   12. 这已不再是事实。

       最明显的例子就是火狐浏览器。Debian 项目允许 Firefox 在打包系统之外自动更新，由 Firefox 自行决定。

       还有在基本安装中包含非自由软件，这完全违背了 Debian 社会契约。

       当 Debian 项目决定让 Ubuntu 来决定其发布计划时，他们就发生了翻天覆地的变化。

       Debian 曾经是一个由系统管理员为系统管理员开发的发行版，它重视稳定性而非及时性，但现在却被 Ubuntu 和 Freedesktop.Org 的人超越了。我从 Debian 第 3 版开始就使用它，以前我的系统会间隔____________________年才崩溃一次。如今，避免崩溃的唯一办法是：1）删除所有 Freedesktop.Org 代码（pulseaudio、udisks2 等）；2）坚持使用 Debian 9 或更低版本。

       回复

       1. > 最明显的例子是火狐浏览器。Debian 项目允许 Firefox 在打包系统之外自动更新，这取决于 Firefox 的意愿。

          不，不是这样的。稳定版的 ESR 已禁用其更新机制。测试版/非稳定版也一样。它遵循标准版本，但自动更新机制被禁用。

          即使是 Mozilla 为 Debian 提供的官方火狐软件包，其自动更新机制也被禁用，你只能从版本库中获取更新。

          唯一的自动更新版本是 .tar.gz 版本，你可以将其解压缩到你的主文件夹中。

          这是纯粹的虚假宣传。

          此外：

          Debian 已经不再提供 pulseaudio 了。从那时起，它就是 pipewire。很多人都没有注意到这一点，因为它就是那么顺畅。Ubuntu 的改动没有经过适当的严格审核（我关注的是 Debian-devel），而且还是在准备就绪的时候发布。Ubuntu 遵循 Debian Unstable，而 Unstable 套件是滚动发布的，他们可以随时对其进行快照并开始工作。

          我从 Debian 第 3 版开始也在用它，但我仍然只在内核发生变化时才重启或升级系统。与 Ubuntu 相比，同样的配置执行同样的任务，Debian 要快得多，它就是我们所熟悉和喜欢的 Debian（也许没有 systemd，我就不多说了）。

          回复

          1. 在当前的 Debian 稳定版中，pulseaudio 至少是 kde 桌面的默认设置。Trixie 可能会改变这一点，但尚未正式发布。

             回复

       2. 如果在软件包管理器之外安装，Firefox 只能自行更新。这适用于 Debian 及其分叉。如果我点击 “帮助”->“关于”，就会显示 “您的组织禁用了更新”。我个人希望各发行版能建议安装 Betterfox [1] 或 Arkenfox [2]，让 Firefox 更完善一些。

          [1] – https://github.com/yokoffing/Betterfox

          [2] – https://github.com/arkenfox/user.js

          回复

       3. 我是 Debian 的忠实粉丝，目前是 Devuan 的用户。我确信它仍有问题，但感觉很好很稳定，尤其是在与时俱进的旧硬件上。(Thinkpad R61i，装有core2duo T8100 和 middleton bios）。

          回复

       4. >最明显的例子就是火狐浏览器。Debian 项目允许 Firefox 在打包系统之外自动更新，由 Firefox 自行决定。

          您个人选择安装 flatpak 或 tar.gz 版本，很可能是因为您运行的是不再受支持的旧版 Debian。

          >如今，避免这种情况（崩溃）的唯一办法是…

          运行不支持的旧版本，而已知的安全漏洞永远不会被修复，这并不是一个好的建议，也不是拆除管道的好办法。从地板开始拆卸管道几乎不是一个好主意。

          Pipewire 看起来非常稳定，如果你真的想要一些更简约的东西，最好从最简约的东西开始，而不是剥离一些东西。

          例如，Void 在这方面就很不错。

          回复

2. 作为一个曾经维护过 Debian 发布的 PHP 库的人，他们对源代码的修改简直糟透了。有好几次，他们以微妙的方式破坏了库，而且几乎没有向库的用户表明他们运行的是分叉版本。我也从来没有就他们修补的所谓 “错误 ”联系过他们。

   回复

   1. > 他们修改了源代码，真他妈糟透了

      作为维护者，我当然能理解这种感觉，我可能也不会感觉很好。作为用户，我很好奇他们认为需要做哪些修改，他们在你的库中到底改了什么？

      回复

      1. 我所维护的库（SimplePie）是一个 RSS 源解析器，支持 RSS/Atom 规范的所有类型。由于这些特定格式的历史原因，要解析真实世界的数据需要大量的兼容性黑客，而且 “规范”（实际上只是网站上的一个模糊页面）与实际使用情况相比并不准确。

         这已经是很久以前的事了（10 多年前），但我记得大概是有人报告说部分库不符合规范，Debian 就打了这些补丁。这破坏了对实际 feed 的解析，造成了数周无法复制的调试问题。如果他们在第一时间向上游报告，我本可以进行调查，但没有机会这样做。

         回复

         1. 这听起来非常粗心。这不仅破坏了一个明显经过深思熟虑的功能，还违反了稳健性原则。无论人们喜欢与否，这都是网络的指导原则。最重要的是，这种 “修复 ”对用户不利。

            出发点是好的，但不幸的是，结果却是糟糕的。

            最近，这里有一个关于 GitHub 上操作系统项目如何被报告纠缠的讨论。一些开发者评论说，这甚至剥夺了他们发布代码的动力。

            机制总是一样的，不是吗？为什么我们不能拥有美好的事物 “的问题。因为有人会利用系统或基于信任的关系，这至少会让一切变得更糟。

            回复

         2. 啊，这听起来像是 Debian 方面的一个糟糕的解决方案，而且非常出人意料。当然，修补安全/隐私问题是有道理的（从用户的角度来看），但像这样改变功能？这就不那么合理了，尤其是他们甚至都没有尝试向上游提交修改。

            回复

         3. 首先，我想说我爱 Debian。他们有一个伟大的发行版，简单易用，使用起来非常愉快，而且基本上只靠志愿者的努力就能维持下去。

            不过，我认为在某些方面，他们给了软件包维护者太多的自由。在 Debian 中，成为软件包维护者的门槛相对较低，但一旦一个软件包有了维护者–除非真的违反了 Debian 的政策–这个人似乎对所有与软件包相关的决定都有最终决定权。有时，这些决定最终会引起争议。

            你的情况就是一个例子。软件包维护者在理想情况下应该与上游作者合作，但却不需要，因为很多上游作者要么联系不上，要么主动拒绝任何下游用户的打扰。(源代码压缩包链接在他们的主页上，他们的支持也就到此为止了！）。我不知道这里有什么解决方案，但可能有一些改进是可以而且应该做的，而不需要所有上游作者都订阅 Debian 开发邮件列表。

            回复

            1. 同意。出发点是好的，但由于发行版软件包维护者与上游之间沟通不足、领域经验不足或两者兼而有之，经常会出现问题。我认为解决的办法是对维护者应进行哪些类型的自定义设置（一般来说，要比现在少）、如何与上游沟通以及更多的代码审查设定更高的期望值。

               回复

               1. 在保持整个操作系统稳定方面，用户更信任 Debian（以及维护者），而不是上游供应商。顾名思义，上游提供商可能与操作系统无关，他们只关心自己的软件包，或许还有他们偏好的依赖关系。

                  Debian 赢得了这种信任，它的软件更新规则是经过实战检验的，也是众所周知的。

                  回复

            2. > 成为 Debian 软件包维护者的门槛相对较低

               这是一个典型的不光彩、高要求、无报酬的志愿者职位，比在施粥处或食物银行做义工要高上几级。门槛低也就不足为奇了。

               对于上游维护者来说，建立自己的竞争性 Debian 软件包 repos 完全无视 Debian 的规则也是轻而易举的事，微软就有一个 VS Code 软件包 repos。

               回复

   2. 作为一款免费游戏的上游，我也有过类似的经历。他们有时也会把这些错误转发给我们。

      回复

3. 与之相对应的是 2008 年 Debian 特有的私钥熵损失 [1]。虽然这已经是一个非常古老的漏洞，但显而易见的后续问题是：Debian 如今是如何预防或缓解此类事件的？后来是否发生过类似事件（当然是非安全事件）？

   [1] https://en.wikipedia.org/wiki/OpenSSL#Predictable_private_ke…

   回复

   1. Debian 会打很多补丁，但这些补丁并非出于发行原因的严格要求。下面是 GnuPG 补丁的例子：

      * https://udd.debian.org/patches.cgi?src=gnupg2&version=2.4.7-…

      这里有很多与标准相关的政治内容。具体例子见

      * https://sources.debian.org/src/gnupg2/2.4.7-19/debian/patche…

      上游 GnuPG 项目（及其所属的标准派别）明确反对使用没有用户 ID 的密钥，因为这会带来潜在的安全问题。RFC4880 OpenPGP 标准也明确禁止使用这种方式。通过 Debian 流程，此类密钥的支持者绕过了上游项目和标准的立场。

      回复

      1. > 里面有很多与标准有关的政治内容。

         公平地说，在 Debian 的情况下，政治是必然的。Debian 是操作系统的愿景。它的政策、标准和指导方针都是以此为目标，将操作系统视为一个整体。

         这远远超出了 “收集软件包，粘合并上传 ”的范畴。

         我想其他发行版也是如此（有的更多，有的更少）。

         回复

   2. 您是否有任何统计数据表明，Debian 补丁引入的 CVE 值得修复的漏洞比软件已经包含的还要多？OpenSSL 的历史并不纯洁。

      不要忘了，在此之前，该补丁已在 OpenSSL 邮件列表中发布，并收到了通过评论。

      话虽如此，如果你想问是否有一个渗透测试小组负责审查所有补丁？没有。就像 99.999999999% 的现有软件都没有这样的团队一样。

      回复

      1. 这正是我想听到的答案，谢谢。(当然，我不认为 Debian 应该为这些事件负责。）Debian 还发送其他补丁吗？例如，我不知道 Debian 还经常自己创建一个 man 页面。

         回复

         1. Debian 的目标当然是为上游做贡献，但由于上游的 CLA，由于大多数 Debian 的打包者都是志愿者，许多 Debian 的贡献者都很忙，许多上游都不活跃，以及其他原因，这种情况并不总是发生。

            回复

         2. 如果你访问任何软件包的 https://tracker.debian.org/，它都会列出需要向上游发送的补丁。

            回复

            1. 啊，我是说政策和指南。我对 Debian 的流程并不熟悉，所以我可以想象，只有某些补丁程序是由维护者自行决定是否向上游发送的。不过，Debian 似乎至少有将补丁与上游源代码分开维护的政策。

               回复

               1. Debian 使用 Quilt 系统对每个软件包进行补丁维护。在打包软件时，您需要获取原始源代码（即 orig.tar.gz），然后用 Quilt 在其上添加补丁，并以这种方式构建软件。

                  然后运行测试，如果测试通过，就打包并上传。

                  这样就可以把补丁作为一个软件包发送给上游，并说：“我们做了这些，如果你想把它们包括进来，这可以干净利落地应用到 x.y.z 版本，欢迎任何反馈”。

                  回复

               2. 理论上，你希望所有的补丁都发送到上游，但如果是出于某种特殊的 debian 原因，就不能发送。

                  补丁是单独维护的，因为 Debian 通常不会重新打包项目发布的 .tar.gz（或其他文件），以免签名无效，也不会让人们检查文件是否真的一样。如果项目发布的文件中包含不能合法再分发的文件，则属于例外。

                  回复

      2. 该补丁发布在了错误的 OpenSSL 邮件列表上，坦白说，Debian 的这个错误比我们从 OpenSSL 上看到的任何其他错误都要严重。

         据我所知，Debian 并没有对安全关键软件的补丁进行专门的安全审查，而这是其他发行版的正常做法。

         回复

         1. 这可能是人类历史上最严重的计算机安全漏洞，但同样，我们也很难将其视为 Debian 或 OpenSSL 的系统性问题。当我们面对这样一个历史上仅有一次的事件时，它发生的地点是非常随机的。这就是小样本推论的问题所在。

            回复

            1. 我认为从事件中吸取教训很重要。很明显，两个项目的设计都存在问题，导致了错误的发生，而事实上，在随后的几年里，其中的几个问题都得到了修复（虽然修复的速度并不快，而且直到主要的企业赞助商开始关注 OpenSSL 的维护问题时才修复）。

               回复

               1. 我同意，但并不清楚替代方案中是否存在更严重的设计问题。

                  回复

         2. 另一方面，这也暴露了 OpenSSL 依赖于 “未定义行为”（Undefined Behavior）的可预测性。像 GCC 更新这么简单的事情就能在更多的系统上产生同样的效果，而不仅仅是 Debian，而且不需要对 OpenSSL 本身打补丁。

            回复

            1. > 另一方面，它暴露了 OpenSSL 依赖于 “未定义的行为”（Undefined Behavior）始终可预测地工作。在不对 OpenSSL 本身打补丁的情况下，像 GCC 更新这么简单的事情就能在比 Debian 更多的系统上产生同样的效果。

               不是这样的。它是从地址被占用的数组中读取未初始化的字符值（并将其随机化为正在生成的密钥），这导致了未指定的值而非未定义的行为。

               回复

               1. 你说得对，我记错了。其实这样也好不了多少，因为并没有要求未指定的值必须实际发生变化。编译器开发人员可以在读取任何未指定的 “字符 ”值时总是返回 “0x00”，这不会提供任何熵。将其 XOR 入可确保无法减去熵，但如果没有其他熵源，则无法返回错误。OpenSSL 能够在其 RNG 中生成 0 个熵且不返回错误，这仍然是一个需要修复的重要错误。

                  回复

                  1. > 将其 XOR 可以保证无法减去熵，但如果没有其他熵源，则无法返回错误。

                     不，他们是先将来自多个熵源的数据 XOR 到一个中间缓冲区（该缓冲区从未初始化过，因为它的全部意义就在于随机），然后再将其 XOR 到一个缓冲区，由此生成密钥。Debian 的补丁删除了最后的 XOR。这并不是原始代码中的错误（除了难以理解之外）。

                     回复

               2. 当前内核为零页。代码一开始就有错误。

                  回复

                  1. 不，没有错误。代码使用了一个未初始化的数组，将不同来源的随机数进行 XOR。它没有初始化数组，因为这样做没有任何价值，反正关键就是随机。

                     回复

                     1. 正如我所说，新内核会将页面清零，未初始化的区域很可能会被清零，或者是相当确定的。

                        回复

                        1. 这很好。如果为零也不是什么错误。反正你也只会把一堆随机值 xor 进去，就没必要特意把它设为零了。

                           回复

            2. 令人抓狂的是，在这次事件之后，他们恢复了未初始化的用法，并在接下来的 50 年里一直沿用至今。这并不像未来的编译器会毁掉整个宇宙那样轻微：它让 Valgrind 在 OpenSSL 的所有用户身上都变得不那么有用了，这正是安全关键软件所希望看到的。

               (与此同时，早在这次事件之前，fedora 在编译 openssl 时就使用了 -DPURIFY 功能，以安全、正确的方式禁用了不良行为）。

               回复

   3. https://research.swtch.com/openssl 提供了更多的背景信息：openssl 被问及这一变更，并且似乎批准了它（至于是否每个人都理解批准的内容则是另一个问题）。目前还不清楚 openssl 为何从未采用该补丁（其他人是否只是运气好？），但我想知道，如果打上了该补丁（或通过构建开关隐藏了这些行），会有什么反应。

      回复

      1. > 不清楚为什么 openssl 从未采用该补丁。

         OpenSSL 已经有一个选项 -DPURIFY 可以安全地禁用不良行为。

         回复

   4. 你好、

      一如既往：imho (!)

      我记得这件事–如果我的记忆没有出错的话：

      是 openssl 访问了未分配的内存，以收集随机性/熵来生成密钥。

      而 Valgrind 则抱怨可能存在内存泄漏问题–它是一款侧重于检测内存管理问题的剖析工具。

      * https://valgrind.org/

      维护者并没有仔细查看/试图了解到底发生了什么/导致了什么问题，而是简单地注释掉/禁用了这些访问……

      错误时有发生，但 Debian 社区很好地处理了这个问题–在我的印象中，他们一直都是这样做的。

      我不知道……与那些与公司有关联的发行版相比，我更喜欢 Debian 随时采用的开放和社区驱动的方法。

      最后但并非最不重要的一点是，他们有社会契约。

      长话短说：至少对我来说，这是对 Debian gnu/linux 发行版的支持，而不是反对:))

      只是我的 0.02 欧元

      回复

      1. 但为什么要在 debian 中打补丁，而不在上游提交错误呢？

         安全库的上游问题加倍重要： 坏人故意破坏加密实现的例子不胜枚举。他们总是让它看起来像一个诚实的错误。

         据我们所知，该软件包之前或未来的 debian 维护者都在为某个三字母机构工作。这种改动应该是违反 Debian 政策的。

         回复

   5. 如果涉及 OpenSSL，我会优先考虑其他人，而不是 OpenSSL。

      为什么？

      回复

      1. 正如其他一些评论所说，补丁发布到 OpenSSL 后，有人说没问题。后来他们又说这不是一次适当的审查。

         回复

   6. 这和打电话回家有什么关系？

      回复

4. 这些理由都很好，但并不全面。除非有人能告诉我，Debian 对 xscreensaver 的修改属于哪一类。据我所知，这只是出于美学原因和打包者与上游的意见分歧。

   回复

   1. 这里列出了补丁及其解释：

      https://udd.debian.org/patches.cgi?src=xscreensaver&version=…

      编辑：找不到任何出于美学原因的补丁。

      回复

      1. 91_remove_version_upgrade_warnings.patch是出于美观原因的补丁。

         Debian 保留了许多已修复错误的旧版本。上游维护者必须处理过时版本的错误报告。为了减轻工作量，他添加了过时版本警告。Debian 将其删除。

         回复

         1. 我承认我没有检查过该补丁，但如果不在互联网上的某个地方检查版本信息，该警告怎么可能起作用？这已在 OP 中列出。

            回复

            1. 我记得它只是硬编码了发布日期，如果超过两三年就会发出警告。

               这还算合理。我同意 Debian 应该修补 phone-home 和自动更新（又称开发者 RCE）。不过，他们应该保留 xscreensaver 仅限本地的警告。这不是隐私或系统完整性问题。

               不过，jwz 在权利问题上也有失偏颇。

               他们都错了。

               回复

               1. 不熟悉代码库的人很容易搞砸，下面是 SimplePie 的例子：

                  https://news.ycombinator.com/item?id=44061563

                  我认为这种做法不合理。当你实际上是在做一个 fork 时，不要让现有的项目名称成为你的负担，让他承担你造成的问题。

                  回复

               2. > 然而，jwz 在权利问题上也有失偏颇。

                  一定要记住不要从 HN 链接到他的网站，因为当你从 HN 点击链接到他的网站时，你会看到一张睾丸的 NSFW 图片。当当曾经在外向链接上设置了 rel=noreferrer，但这导致了与其他人更多的争执…

                  FOSS 圈子里有些人就是喜欢挑起事端，而 jwz 并不是唯一一个。在我看来，另一个有此类问题的人是 systemd 一群人，尽管在这种情况下…… 在我看来，这在某种程度上是情有可原的，因为他们正在努力解决那些让每个人都生活困难的实际问题。

                  回复

                  1. > 永远记住不要从 HN 链接到他的网站，因为你会看到一张睾丸的 NSFW 图片

                     他这样针对 HN 用户的理由是什么？

                     回复

                     1. 睾丸不言自明 [1]。早在十多年前，他就对 VC 怀有严重的政治怨恨[2]，而我能找到的关于 JWZ 睾丸出现在 HN 上的最早记载是在 9 年多以前[3]。

                        [1] NSFW https://imgur.com/32R3qLv

                        [2] （重定向到 NSFW，请在隐身状态下打开，否则您会看到睾丸）https://www.jwz.org/blog/2011/11/watch-a-vc-use-my-name-to-s…

                        [3] https://news.ycombinator.com/item?id=10804953

                        回复

                        1. > 睾丸不言自明

                           真的不能。上面说他讨厌 HN 的用户，但没说为什么。真的只是因为他不喜欢流量吗？

                           如果是因为他对 VC 心怀怨恨，这还可以理解，但他为什么要拿 HN 用户出气呢？

                           回复

                           1. > 如果说他与风险投资公司有仇（这一点更容易理解），那他为什么要拿 HN 用户出气？

                              这是一种小小的抗议。让人们感到不舒服。

                           2. 如果目睹你抗议的人都不知道你在抗议什么，那抗议还有什么意义？

5. 最精彩的部分莫过于他们偷换 FFmpeg 或其他库，以某种方式编译东西，却不测试结果，然后发布完全损坏的软件。

   回复

   1. 你运行的另一个发行版做得更好吗？

      回复

      1. Fedora？Arch Linux？我非常尊重 Debian 的维护者，但我在这些发行版上遇到的问题要少得多。

         回复

6. 我非常尊重 Debian，感谢他们为更大的生态系统所做的一切，但这也是我使用 Arch 的原因。只需参考软件的官方文档，就能知道它是否正确，这要容易得多。此外，我还从未遇到过因为坚持使用上游版本而导致软件间的互操作被破坏的情况。修改上游软件似乎是一项繁重的工作，可能会带来很多破坏和弊端，因此并不值得。

   回复

   1. 你似乎在暗示，Debian 为了与操作系统的其他部分集成而对上游软件进行了大量重大修改，而 Arch 则完全没有。这两种说法都不对。

      回复

      1. 我知道这是一个范围，但我倾向于尽可能减少对上游的改动。

         回复

         1. 如果这意味着程序根本无法运行？或者有补丁修复的 bug 无法修复？或者可以支持的设备反而不支持了？

            我已经为很多东西打了补丁，以改善 kde 在手机/平板电脑上的运行。经过很短或很长时间后，它们确实被合并了，但与此同时，拥有平板电脑的人（比如我）却可以真正使用该软件。

            为什么要等几个月甚至几年呢？

            回复

7. 在我看来，关于手动页面的问题一直是系统的一个缺陷。有相当数量的手册页面，如果能在原版软件中加入，将使整个世界受益匪浅，但它们却被埋没在 Debian git 仓库的补丁子目录中，而且多年来一直如此。

   这并不是说 Debian 是唯一的例子。FreeBSD/NetBSD 的软件包/端口系统中也有一些对全局有用的东西，却被当作本地补丁藏了起来。问题的关键并不在于 Debian 是个问题，而在于它也系统化了这样一种思想，即（具体地说）外部内容的手册页面主要进入操作系统自己的源代码控制，而不是最后才进入源代码控制。

   回复

   1. 通常情况下，Debian 手册页面的作者或软件包维护者会将其发送到上游。补丁也是如此。有时上游不需要手册页，或需要不同格式的手册页，而 Debian 人员没有时间重写。

      回复

      1. 有人认为这很正常。但经过几十年的观察，在我看来，这只是一种看法，实际情况并非如此。很多时候，这些东西只是被卡住了，从来没有送出去过。

         我还认为，“原作者必须不接受手册页 ”的观点是一种解释信念与现实不符的方式，而不承认是信念本身出了问题。当然，在很多情况下，事情的结果就像我们在另一篇文章中提到的 net-tools 的例子一样，原作者显然是想要手册页的，因为他们最终还是写了一些，并最终重复了 Debian（和 FreeBSD/NetBSD）的努力，这些都是与开发者中普遍存在不接受手册页文化的观点相矛盾的证据。

         回复

         1. 人们也很容易认为，那些从事无偿软件打包工作的人应该做更多的免费工作。

            我已经为我维护的 300 个软件包向上游发送了大约 50 个补丁，虽然这减少了长期工作量，但工作量也是惊人的。

            通常情况下，Debian 补丁的许可证与原始项目的许可证相同。因此，如果有人认为应该向上游发送更多的补丁，也可以发送。

            通常情况下，Debian 主

            回复

            1. 我并没有要求你们对我的软件进行二次开发。我也没要求你们用同样的名字来发布我的软件的修改版（有可能被破解和/或有很大的不同）。

               如果你要这么做，就应该让人们知道。否则就不要这么做。这不是 “但许可证允许 ”的问题，而是做什么才是正确的问题。

               Debian 是目前所有 Linux 发行版中最让我头疼的一个。实际上，在我的记忆中，Debian 是唯一一个让我伤心的系统。Debian 将大量的工作推向了更广泛的生态系统，而这些人却从未要求过。

               我没有选择与 Debian 联系在一起，但我别无选择。你选择了与你维护的软件包联系在一起。

               所以，别跟我说什么 “但我的时间是无偿的！”。要么好好干，要么就别干。两者都可以；没有维护者要求你打包任何东西。他们只是要求你不要通过随机发送补丁（可能会损坏和/或意见很大）的方式间接地把工作推给他们，他们甚至从未被告知过这些补丁。

               回复

               1. > 如果你要这么做，那就应该让人们知道。否则就不要这么做。这不是 “但许可证允许 ”的问题，而是做什么才是正确的问题。

                  好吧，我在此告诉你： 每个发行版都会给软件打补丁。所有发行版。Debian、Arch、Fedora、Gentoo、NixOS、Alpine、Void，大的、小的、商业的、业余的。全都有。

                  回复

                  1. 根本不是这样。一些发行版可能会修补一些编译问题，或者罕见的破坏性错误，但不会像 Debian 所做的那样。声称其他任何事情都是特朗普式的谬论。

                     回复

                     1. Debian 到底是做什么的？

                        回复

      2. 这个。

         很多时候，上游并不是不提供帮助，只是上游认为在其发布的版本中很少用到手册页，不想花时间维护与他们的 README.md 或 –help 所提供的文档（手册页必须与之保持同步）并行的文档。

         回复

   2. 我曾多年为 NetBSD 打包软件（主要是 Gnome 2.x）。我几乎一直在尝试向上游提供本地补丁，这些补丁要么是构建修复所需的，要么是改进所需的（比如适应非 Linux 文件系统层次结构或使用不同 API 的灵活性）。

      但这是一场艰苦的战斗，令人精疲力竭。大多数补丁在数月或数年内都会被忽视，常见的回应是 “这还有必要吗？”或 “请更新补丁，它已经不再适用了”。一般来说，这都要耗费大量精力。因此，补丁留在发行版中是…… “正常 ”的。

      回复

   3. 另一个问题是，这些手册可能会过时（和/或完全错误）。

      总的来说，我觉得这是一种停留在 1995 年的 Debian 政策。现在有其他合理的方式来获取文档，虽然 manpages 对某些类型的程序很有用，但对其他程序就不那么有用了。

      回复

   4. 只有在项目缺乏手册页或手册页非常糟糕的情况下，才会出现这种情况。

      回复

      1. “只会发生 “的情况比你想象的要多得多。在我的经验中，“只有 ”是很常见的。

         随便挑一个例子来说：

         Debian 7 年前就有一个本地手册页面，介绍原始软件中没有文档说明的（Sourceforge 旧版本中的）iptunnel(8) 命令：

         https://salsa.debian.org/debian/net-tools/-/blob/debian/sid/…

         3 年后，原版软件也独立推出了自己的手册页面，但却截然不同：

         https://github.com/ecki/net-tools/blob/master/man/en_US/iptu…

         然后 Debian 又把它引进了！

         https://salsa.debian.org/debian/net-tools/-/blob/debian/sid/…

         这种事情并不罕见。

         回复

         1. 哇，1 个实例。好吧。世界末日。

            回复

8. > Debian 避免在其软件包存档的主要部分包含任何无法合法分发的内容…

   相关：netadata 将从 Debian https://github.com/coreinfrastructure/best-practices-badge/i 中删除…

   回复

9. 但是，在 Debian 看来，为其发布的软件打补丁会带来哪些风险，他们又是如何降低这些风险的呢？

   回复

   1. Debian 不是一个人在战斗。很多补丁都是针对 CVE 的回传修复。

      还有诸如 “这个项目只能用过时版本的 gcc 进行编译”，所以只能选择放弃或修复。与此密切相关的是只在特定架构上出现的 bug，因为开发者只使用 amd64，从未在其他架构上编译或运行过，所以他们做出了错误的假设。

      还有，python 每次发布都会丢弃标准库模块，导致程序崩溃。因此，它们被单独打包到 python 之外。

      此外，还有人从尚未发布的项目中挑选错误修复。

      你有什么理由认为，Debian 开发人员在基因上比其他人更容易犯错？考虑到 debian 拥有大多数项目都不具备的密集测试设置，你有什么理由认为 debian 开发人员在基因上比其他人更容易犯错呢？

      回复

      1. 我是按照作者的说法来表述的。

         你凭什么认为我认为 Debian 比其他人更容易犯错？它是我家里使用的两个发行版之一。我非常钦佩他们的开发人员。

         回复

   2. 我的意思是，这取决于打的是什么补丁？如果是添加丢失的 manpage，我不知道会出什么问题？更改构建选项（如启用或禁用功能）是补丁，还是预期的更改（如果这样的配置选项不好，上游提供它的责任又该归咎于谁）？默认配置文件（既可能使软件更安全，也可能使软件更不安全，例如在 TLS 或 SSH 中使用何种密码）又是怎么回事？

      回复

10. 这也是我 10 多年前转用 RHEL 的原因之一。

    实际上，我更喜欢 RHEL 保持软件包上游打包方式的政策，这意味着上游文档更准确，我也不必学习我的操作系统是如何移动东西的。

    记忆犹新的一个例子是 postgres，RHEL 没有尝试将它的二进制文件链接到 PATH，我可以自己用 ansible 来做。

    Debian 中另一个令人讨厌的例子是他们如何在 mysql 中创建管理员账户，或者 apt 如何用另一个服务器软件替换一个服务器软件，只因为它们使用的是同一个端口。

    我希望对发生的事情有更多的控制，而 Debian 却剥夺了我的控制权，并试图替我思考，这在服务器环境中是不受欢迎的。

    现在，Fedora 的 nano-default-editor 软件包让我很不爽。这意味着我必须先卸载这个元软件包，然后再安装 vim，否则就会出现软件包冲突。别替我想我想用什么编辑器。

    回复

    1. > 实际上，我更喜欢 RHEL 保持软件包上游打包方式的政策。

       如果这是你的标准，我不认为 RHEL 是正确的选择。Arch 可能是你想要的

       回复

    2. “实际上，我更喜欢 RHEL 保持软件包上游打包方式的政策”。

       你在开玩笑吗？红帽一直以给软件包打补丁而臭名昭著，下载一个 SRPM 看看就知道了。

       回复

    3. 我认为 Red Hat 并非如此，但 Slackware 却是如此。

       如果你想要和上游文档一样的软件包，那就运行 Slackware 吧。

       Debian 确实在许多软件包中添加了一些非常不错的功能，比如使用 .d 目录中的文件配置多个 uWSGI 应用程序。这是 uWSGI 的一项功能，但 Debian 将其打包得非常好。

       回复

    4. > 实际上，我更喜欢 RHEL 保持软件包上游打包方式的政策。

       除非在我上次使用基于 RHEL 的软件之后的 10 年里发生了什么变化，否则肯定没有这样的政策。

       回复

    5. 几乎每个人都把 nano 作为默认设置已经很久了，至少在我看来是这样的，因为我不得不弄清楚哪个软件包支持脚本，并在操作系统安装后自己安装 vim 已经很久了。

       RedHat在他们的发行版中做了很多手脚，你可能需要像Arch这样的发行版，因为它在这方面更省心。我个人更喜欢 Debian，它是 Linux 发行版中的花岗岩石。

       回复

11. 这不是文章的最佳名称。我的第一个猜测是版本变更，或软件从 repo 中添加/删除。结果发现这是关于源代码修改的。

    回复

    1. 作为一个以英语为母语（英国）的人，我在读这篇文章之前也不太清楚。

       我个人认为 s/change/modify 更合理，但这只是我的观点。

       除此以外，我还是 Debian 的忠实粉丝，与其他发行版相比，我一直 “感觉 ”它更安静，这也是我非常在意的一点。

       因此，我们更需要一个更朗朗上口/更易于理解的标题，因为我相信这些短小精悍的要点所包含的信息非常有影响力。

       回复

       1. 打补丁解决隐私问题并不在 Debian 政策中，这只是 Debian 文化的一部分，但仍有一些未修复/未发现的问题，最好运行 opensnitch 来缓解其中的一些问题。

          https://wiki.debian.org/PrivacyIssues

          回复

          1. 谢谢你的链接，这将非常有用。

             > 最好运行 opensnitch 以减少其中的一些问题

             对于关心保护工作站的人来说，Opensnitch 是一个不错的建议；而对于我来说，我更关心的是我的家庭实验室中运行着数百个软件的数十个虚拟机和容器，一个注重隐私的操作系统是一个很好的基础，还有更多层次的问题，我就不多说了。

             回复

             1. 家庭实验室通常也运行非发行版的软件，因此也可能存在更多隐私问题。使用像 privoxy 这样的 SOCKS 代理过滤外网，可能是一个好的开始。

                回复

       2. 我马上就明白了它的意思，但我想这只是因为我已经知道 Debian 在这方面是臭名昭著的。

          回复

    2. 我也是。我希望得到一个解释，为什么我已经习惯了、运行得很好而且没有损坏的软件，却因为 “无人维护 ”而在下一个版本中被从 Debian 中删除。

       回复

12. OpenBSD 也是如此，但它的安全性和适当的 POSIX 功能与 Linux主义（如 wordexp）截然不同。

    回复

13. 发行版的维护者是否与其他发行版的维护者（以及他们的维护者）共享补丁、手册、调用首页指标和其他数据？

    此外，他们是否公开发布任何变更信息？

    回复

    1. 每个二进制软件包都应该有一个源码包，补丁通常放在软件包的一个子目录中。

       回复

    2. 他们通常会向上游发送所有内容，所有内容都在源码控制中公开。有些维护者会在 repology.org 上查找其他发行版的软件包。

       回复

    3. > 他们会公开发布任何变更信息吗？

       这完全是无稽之谈，他们当然会，这是一个开源发行版。一切都可以从 packages.debian.org 上找到。

       回复

       1. 他们甚至还有一个专门发布这些信息的门户网站，上面有统计数据，还有许多说明，解释为什么要做特定的改动： https://udd.debian.org/patches

          回复

       2. 对不起，我想澄清一下，我是指以一种易于解析的方式。我不会把安装在我系统上的每个开发工具的源文件都调出来，检查原始的 .patch 文件，然后花时间去理解其中的差异。

          不过，你似乎在假设一个无辜的问题是恶意的，这是你的问题。

          回复

    4. > 发行版维护者是否与其他发行版维护者（以及他们的维护者）共享补丁、手册、调用首页指标和其他数据？

       是的，至少在 Debian 源码包中有补丁。此外，为了社会公益和减轻发行版的维护负担，我们也非常鼓励维护者向上游发送补丁。https://udd.debian.org/patches.cgi 上的 “尚未向上游转发的补丁 ”字段是查找此类补丁的自动工具。

       回复

14. 是啊，不用了，看看 pure-ftpd、apache、nginx 等软件就知道了。我不需要一些奇怪的配置框架来配合我使用的软件。

    回复

    1. MySQL？不，你用的是 mariadb

       回复

       1. 说实话，我宁愿用 MariaDB。它与线兼容，但功能更多，比如 RETURNING 子句。为什么 MySQL 从来没有过这样的功能，这真是一个谜（开个玩笑，那是因为 Oracle）。

          回复

    2. 我赞成。软件包维护者破坏软件的情况并不少见，但这实际上不过是 “应用商店 ”模式的一个缩影，即在用户和软件之间插入了一个激进的分销商。

       这就是为什么我很高兴 flatpaks/snaps/appimages和容器化能发展到今天的地步，因为它极大地减少了软件分发的中间环节。

       回复

       1. 既然这里是自由和开放源码软件的世界，你当然可以自由地摒弃发行版。但

          > 这实际上只不过是 “应用商店 ”模式，让一个激进的发行商把自己插在用户和软件之间。

          这与事实不符。像 Debian 这样的发行版试图将数以万计的独立开发软件整合成一个连贯的操作系统。不喜欢这样也没关系。你想自己使用和管理这数以万计的独立软件也可以。但发行版既不是 “应用商店”，也不会在用户和软件之间 “插入自己”。在自由和开放源码软件世界里，后者是不可能的。许多用户选择将发行版置于他们和软件之间。你可以选择其他方式。

          回复

          1. 我在使用 Arch，而且我认为它尽可能使用上游代码。在我看来，这种模式要好得多。

             回复

             1. 我并不想争论哪种发行版模式最好，或者是否应该完全避免使用发行版。这是一个混乱、复杂的问题，对每个人来说都充满了个人变数。

                我只是想纠正这样一种观念，即发行版就是一个 “应用商店”，在软件和用户之间 “插入自己”。发行版是试图让许多不同的软件在不同程度上 “协同工作”。不同程度的修改可能会，也可能不会。一个极端是，它可能只是一个完全分离的软件集合，没有任何东西将这些软件连接在一起。另一个极端是类似于 BSD 这样的软件。Arch 和 Debian 则介于两者之间。

                对于 “共同工作 ”或修改的正确程度，有识之士肯定会有不同意见。

                回复

             2. 你为什么认为 Debian 的打包者不会这样做？

                回复

                1. 因为众所周知，Debian 的打包者会用不必要的补丁来修改他们打包的软件。

                   回复

                   1. 当然众所周知，但这是真的吗？

                      回复

                      1. 事实上，一个软件可以拆分成多个软件包，没错。

                         回复

             3. 这是一个更好的模式，直到你修复了一个错误，但上游却毫无反应。

                回复

                1. 不要修复漏洞，把它留给开发者。

                   回复

                   1. 但开发人员往往不会修复它们。

                      回复

                   2. 当你在公共场合遇到垃圾时，你是否也会把垃圾丢在地上？尽量把东西留得比捡到时更好。

                      回复

                   3. > 不要修复错误，让开发人员去做

                      开发人员说。

                      与此同时，用户却被一个坏掉的软件困住了。

                      回复

          2. >但发行版既不是 “应用商店”，也不会在用户和软件之间 “插入自己”。

             请翻阅用户 rmccue 在本主题中的第二条评论。鉴于 Debian 不会向用户提供任何关于它修改了上游软件的信息，显然，他们完全有可能在用户不知情的情况下插入自己。在这种情况下，根据开发者的说法，甚至会引入微妙的错误。

             因此，你可能会因为某些维护者自以为比开发者懂得更多而运行着漏洞百出的软件，但你却浑然不知，因为你对这一过程毫无实际了解。这当然不是任何意义上的 “选择”。

             没有人真正愿意使用由 debian 维护的漏洞百出的 php 库，而不是由开发者维护的功能正常的 php 库，他们很可能只是从来都没有意识到这一点。

             回复

             1. > 鉴于 Debian 没有向用户提供任何迹象表明它甚至修改过上游软件

                Debian 也没有向用户表明我们没有修改过上游软件。修改软件是自由与开放源码软件世界的核心工作。如果用户想知道是否修改了什么，如果是，那么源代码当然是可以免费获取的。

                > 如果用户想知道软件是否被修改，以及修改了什么，那么源代码当然是可以免费获取的。

                他们没有在任何地方 “插入自己”！是你，用户，插入了 Debian！

                > 在这种情况下，根据开发者的说法，他们甚至引入了一些微妙的 bug。

                当然，任何软件修改都可能引入、改变或修复错误。或者三者兼而有之。

                > 因此，你可能会因为某些维护者自以为比开发者懂得多，而运行出错误百出的软件。

                这种情况有可能发生。有时，由于 “某些维护者 ”比软件的原始开发者更了解整个系统，所以运行的软件漏洞较少。或更关心用户的自由或隐私。

                > 而你却不知道，因为你没有关于这一过程的实用信息。

                “实用信息”？除了更新日志和源代码，你还想要什么？

                > 这当然不是任何意义上的 “选择”。

                当然不是！您选择运行 Debian。Debian 对这一点是完全公开的！

                > 没有人愿意使用由 Debian 维护的漏洞百出的 php 库，而不是由开发者维护的正常运行的 php 库。

                我自己不使用 PHP，但我几乎总是非常感谢 Debian 系统上软件包的维护者们，他们为适应 Debian 政策和 Debian 社会契约而对上游软件进行了调整（通常是非常令人厌烦的！）。(免责声明：我自己也是一名 DD。）

                > 他们很可能从来都没有意识到这一点。

                如果 Debian 安装指南上有这样的说明：“请注意，Debian 软件包可能与软件原始开发者提供的不完全相同–Debian 的目标是建立一个以我们的社会契约和政策为中心的统一的通用操作系统”，会有帮助吗？

                回复