Debian 13 trixie 正式发布
经过2年1个月30天的开发，Debian项目欣然推出其全新稳定版本13(代号trixie)。
trixie 将获得为期 5 年的支持，这得益于 Debian 安全团队 和 Debian 长期支持团队 的共同努力。
Debian 13 trixie 包含多个桌面环境，例如：
- GNOME 48,
- KDE Plasma 6.3，
- LXDE 13，
- LXQt 2.1.0，
- Xfce 4.20
本次发布包含超过14,100个新包，总包数达69,830个，同时有超过8,840个包因过时而被移除。本次发布中共有44,326个软件包进行了更新。trixie的整体磁盘使用量为403,854,660 kB(403 GB)，由1,463,291,186行代码组成。
感谢我们的翻译人员，使 trixie 的 man 页面在多种语言中可用。
manpages-l10n 项目为手册页提供了许多改进和新的翻译。特别是罗马尼亚语和波兰语的翻译自 bookworm 以来有了显著提升。除 i386 之外的所有架构现在使用 64 位 time_t ABI，支持 2038 年之后的日期。Debian 贡献者在确保包构建产生字节级可重复结果方面取得了显著进展。您可以使用新包 debian-repro-status 检查系统中已安装包的状态，或访问 reproduce.debian.net 查看 trixie 及更高版本的整体统计数据。
Debian 13 trixie 包含大量更新的软件包(占上一版本所有软件包的 63% 以上)，例如：
- Apache 2.4.64
- Bash 5.2.37
- BIND DNS 服务器 9.20
- Cryptsetup 2.7
- curl/libcurl 8.14.1
- Emacs 30.1
- Exim(默认邮件服务器)4.98
- GNUcash 5.10
- GNU编译器集合 14.2
- GIMP 3.0.4
- GnuPG 2.4.7
- Inkscape 1.4
- GNU C库 2.41
- LibreOffice 25.2
- Linux 内核 6.12 LTS 系列
- LLVM/Clang 工具链 19(默认)，17 和 18 可用
- MariaDB 11.8
- Nginx 1.26
- OpenJDK 21
- OpenLDAP 2.6.10
- OpenSSH 10.0p1
- OpenSSL 3.5
- Perl 5.40
- PHP 8.4
- Postfix 3.10
- PostgreSQL 17
- Python 3, 3.13
- Rustc 1.85
- Samba 4.22
- Systemd 257
- Vim 9.1
凭借这一广泛的软件包选择及其传统的广泛架构支持，Debian 再次忠实于其成为“通用操作系统”的目标。它适用于多种不同的使用场景：从桌面系统到上网本；从开发服务器到集群系统；以及用于数据库、Web 和存储服务器。同时，通过对 Debian 软件仓库中所有软件包进行自动安装和升级测试等额外质量保证措施，确保了 Debian 13 版本能够满足用户对稳定版本的高度期望。
此次发布首次正式支持 riscv64 架构，使用户能够在 64 位 RISC-V 硬件上运行 Debian 并享受所有 Debian 13 功能。trixie 正式支持的架构总计七种：
- 64 位 PC(amd64)，
- 64 位 ARM(arm64)，
- ARM EABI(armel)，
- ARMv7(EABI 硬浮点 ABI，armhf)，
- 64 位小端 PowerPC(ppc64el)，
- 64 位小端 RISC-V(riscv64)，
- IBM System z(s390x)
i386 架构不再作为常规架构支持：i386 系统没有官方内核，也没有 Debian 安装程序。i386 架构现在仅用于 64 位(amd64)CPU。运行 i386 系统的用户不应升级到 trixie。相反，Debian 建议在可能的情况下重新安装为 amd64，或淘汰硬件。
trixie 将是 armel 架构的最后一个版本。有关 ARM EABI 支持的更多信息，请参阅发布说明中的 5.1.3. armel 的最后一个版本。
Debian 云团队为多个云计算服务发布了 trixie：
- Amazon EC2(amd64 和 arm64)，
- Microsoft Azure(amd64)，
- OpenStack(通用)(amd64、arm64、ppc64el)，
- PlainVM(amd64、arm64、ppc64el)，
- GenericCloud(arm64、amd64)，
- NoCloud(amd64、arm64、ppc64el)
通用云镜像应能在任何虚拟化环境中运行，此外还有一个 NoCloud 镜像，可用于测试构建过程。
云镜像通过 “cloud-init“ 提供自动化钩子，并通过专门优化的内核包和 GRUB 配置优先实现快速实例启动。
想试试看吗？
如果你只是想尝试 Debian 13 Trixie 而无需安装，你可以使用可用的 live 镜像，这些镜像通过计算机内存加载并运行完整的操作系统，处于只读状态。
这些实时镜像适用于amd64架构，并支持DVD、USB闪存盘及网络启动环境。用户可选择不同的桌面环境进行体验：GNOME、KDE Plasma、Cinnamon、MATE、LXDE、LXQt 和 Xfce。Debian Live Trixie 提供标准实时镜像，因此也可尝试不带任何图形用户界面的基础 Debian 系统。
若您对该操作系统满意，可选择从实时镜像将系统安装至计算机硬盘。实时镜像包含独立的 Calamares 安装程序以及标准的 Debian 安装程序。更多信息可在 Debian 官网的 发布说明 和 实时安装镜像 部分查阅。支持多架构的 Debian Trixie 容器镜像也可在 Docker Hub 上获取。除标准镜像外，还提供精简版本以减少磁盘占用。Debian 安装程序和 Debian 实时镜像现可通过 HTTP 启动在支持的 UEFI 和 U-Boot 固件上启动。
要直接将 Debian 13 Trixie 安装到计算机的存储设备上，您可以从多种安装介质类型中选择进行 下载，例如：蓝光光盘、DVD、CD、USB 闪存盘或通过网络连接。请参阅安装指南以获取更多详细信息。
Debian 现支持 78 种语言，其中大部分语言同时提供基于文本和图形用户界面。
安装镜像可通过BitTorrent(推荐方法)、Jigdo或HTTP立即下载； 如需更多信息，请参阅Debian光盘版。trixie不久后也将通过众多供应商提供实体DVD、CD-ROM和蓝光光盘版本。
升级 Debian
从上一版本 Debian 12 bookworm 升级至 Debian 13 trixie 的过程，对于大多数配置而言，将由 APT 包管理工具自动处理。
在升级系统前，强烈建议您进行完整备份，或至少备份任何无法承受丢失的数据或配置信息。升级工具和流程相当可靠，但升级过程中发生硬件故障可能导致系统严重损坏。
您需要备份的主要内容包括 /etc、/var/lib/dpkg、/var/lib/apt/extended_states 目录中的文件，以及以下命令的输出：
$ dpkg --get-selections ‘*’ # (引号很重要)
我们欢迎用户提供从 bookworm 升级到 trixie 的相关信息。请通过在 Debian 错误跟踪系统 中提交包含 upgrade-reports 包的错误报告来分享您的结果。
自 Debian 12 正式发布以来，Debian 安装程序经历了大量开发，带来了更好的硬件支持以及一些非常有用的全新功能，例如
- 改进的语音合成硬件和软件支持
- 对安装在 btrfs 子卷上的 Debian 的初步且受限的恢复支持
- 分区磁盘时默认单位从 MB 改为 GB
- 如果安装介质不是真实的 CD(如 USB 闪存盘、SD 卡、ISO 文件)，则禁用 CDROM 源，因为 APT 在安装后无法使用它
- 支持与 systemd-boot 配合使用的安全启动
建议在升级前从 APT 源列表文件中移除 bookworm-backports 条目；升级后可考虑添加 trixie-backports。
如果您的 APT 配置涉及固定版本或 APT::Default-Release，可能需要进行调整以允许将包升级到新稳定版本。请考虑 禁用 APT 固定版本。
在某些情况下，升级过程中或运行 trixie 时可能会出现问题。
例如，OpenLDAP 客户端 libldap2 和服务器 slapd 的 TLS 支持现在由 OpenSSL 提供，而非 GnuTLS。这会影响可用的配置选项及其行为。如果未指定 TLS CA 证书，系统默认信任存储库将自动加载。如果您不希望使用默认的CA，必须显式配置受信任的CA。有关LDAP客户端配置的更多信息，请参阅ldap.conf.5手册页。
我们在发布说明中的5. 升级 trixie 时需注意的问题中记录了此问题及其他可能的问题。建议您在升级前阅读该内容。
与往常一样，Debian 系统可无缝升级，无需强制停机，但强烈建议阅读 发布说明 以及 安装指南，以了解可能存在的问题，并获取安装和升级的详细说明。发布说明将在发布后几周内进一步完善并翻译成更多语言。
我正在我的Debian系统上撰写这篇文章，这是一个非常优秀的发行版，作为日常使用系统一直表现出色。在Ubuntu质量大幅下滑后，我切换到了Debian 6，至今从未后悔过。
我喜欢Debian在理念上的务实态度，它默认是自由软件发行版，但同时也方便安装非自由软件或固件二进制文件。我喜欢Debian的包管理规范，喜欢dpkg，喜欢Debian的文档，尽管Arch在这一方面仍是最优秀的。我喜欢稳定版/测试版的软件包分支，这使得选择旧但非常稳定的软件包与选择稍旧但几乎同样稳定的软件包变得容易。
而其中最好的部分是，我从未遇到过因系统本身问题导致的Debian系统崩溃，所有问题都与我的操作有关。我遇到的每一个Debian系统无法启动或出现其他严重问题的案例，都是因为我尝试从第三方仓库添加内容，或者搞砸了配置或其他操作，而不是Debian系统本身的问题。
>我从未遇到过Debian系统因自身问题而崩溃的情况。
Debian 确实很棒，但这并非普遍体验。特别是，我曾因 Debian 稳定版对内核的重度补丁(具体而言，DRM 子系统快速迭代导致的回溯回归，引发难以调试的崩溃)而受困，尽管 Debian 发布版本在发布周期内理论上使用“相同”的内核。相比之下，Ubuntu 使用更新的内核，并通过 -hwe 选项避免了大量补丁冲突。因此我仍然使用 Debian 虚拟机，但在裸金属上使用 Ubuntu。我尚未尝试过来自 debian-backports 仓库的内核。
>Debian 在稳定版中对内核进行大量补丁修改
需要引用来源。
Debian稳定版使用上游LTS内核，我并不清楚他们在该基础上进行了大量补丁修改。
上游-stable分支对接受的补丁要求非常宽松，而且遗憾的是，这些补丁在发布前也没有经过严格测试(你可以看到每个-stable分支几乎每周都会发布新版本)，这可能就是你遇到问题的原因。
LTS 在最近一段时间也在各个领域进行了重大破坏性更改，今年某个时候 virtio 严重损坏，一个常用的 netlink 接口也出现了问题。感谢 Arch 内核贡献者帮助追踪并向上游反馈这些问题，因为我们有共同受影响的用户。在整个事件中，Debian 和 Ubuntu 的 bug 跟踪系统一片死寂，用户贡献寥寥无几，令人沮丧的是，AWS、GCP 等厂商在复制内核补丁树时，盲目地将相同问题推送给用户，并拒绝回应 bug 报告和邮件。
你说得对，稳定性来自测试，但围绕 Linux 的测试工作普遍不足，无论讨论的是哪个分支。
测试内核并不容易，但门槛其实很低。
Arch 的一个鲜为人知的优点是，它让成千上万的用户成为了测试者。在有人说“这不应该是用户的责任”之前，我要说我并不确定。我们都在一起面对这个问题。我宁愿在家里的桌面上处理一两个 bug，只要它能在出现在用于工作服务器的发行版之前得到修复，从而避免在那里引发更严重的问题。
> Arch 的一个鲜为人知的优点是，它让成千上万的用户成为了测试者。
你也可以通过Debian的“测试”和“不稳定”发布通道做到这一点。除了新“稳定”版本发布前的几个月(通常这不是大问题，而且修复“稳定”版本中的回归问题本应是更高优先级)，只要不要将其安装在依赖其正常运行的系统上即可。但在家中仅用于娱乐和实验的桌面系统上运行则完全没问题。
我也有类似经历。我那位不太懂技术的弟弟也使用与我相同的笔记本配置(Arch+XFCE)。他知道如何使用 -Syyu 选项，通常不会出现问题。最近的升级中出现了VLC包拆分问题，所以我让他先别升级，等我过去帮忙。虽然我需要亲自筛选并安装可选依赖项进行升级，但一周后问题已解决(我猜是基于用户反馈)，常规的yay -Syyu安装就正确安装了所需的可选依赖项。
我并不认为自己特别擅长 Linux。我只是在过去几年中每天在桌面上运行它，除了摆弄 TWM 之外，我没有做太多关于内部结构的探索。
尽管有各种传言，我在基于 Arch 的桌面发行版上遇到的麻烦远少于当年使用 Ubuntu 和 Debian 时。
不过，服务器上我还是会选择 Debian。
是的，我也是这么认为的。我认为发布周期其实根本不重要。原因在于，大多数兼容性问题都是由GNOME和KDE的组件/扩展以及发行版中预装的大量非桌面环境(DE)但又复杂的软件引起的，比如Manjaro，这类发行版每隔一周就会破坏向后兼容性。
当人们切换到Arch时，通常会从头开始配置系统，最终选择简单工具并避免大多数发行版强加给你的不稳定组件。
virtio 漏洞影响了我。我有一个主机节点(Debian)带有一块网卡，该网卡被传递给虚拟化的 OpnSense。存储使用两块消费级 NVMe 硬盘组成 RAID 0 作为系统盘。我原本预计这种配置会导致停机，但内核漏洞并未在我的问题清单中。
请注意，LTS 和 ELTS 并非由 Debian 维护。
维基上有更多相关信息。
负责 Debian LTS 和 Freexian ELTS 的团队成员均为 Debian 成员/贡献者，Debian LTS 的更改最终会合并到 Debian 软件仓库中，而 Freexian ELTS 的更改则以外部仓库形式公开发布。
https://wiki.debian.org/LTS https://wiki.debian.org/LTS/Team https://wiki.debian.org/LTS/Funding https://wiki.debian.org/LTS/Extended
https://news.ycombinator.com/item?id=44853371
我认为他们指的是LTS内核，而不是Debian的LTS。
没错，我指的是https://www.kernel.org/中的_长期_分支，以防有误。
是的，看来是这样，谢谢。
据我所知，补丁在这里：https://salsa.debian.org/kernel-team/linux/-/tree/debian/lat…
这些补丁是否算得上“重大”当然见仁见智，但绝非微不足道。
依我之见，考虑到内核的规模和复杂性(数百万行代码、支持多种架构、子系统数量以及数量惊人的设备驱动程序)，这些补丁几乎可以忽略不计。我认为他们基本上是在发布一个原生内核 😀
典型的 Linux 用户回应。天啊……
如今，我所有的“Debian”裸金属系统实际上都在运行Proxmox，我认为这在基础Debian系统方面是一个相对理想的折中方案——Proxmox内核基本上是Ubuntu内核，但除此之外，它是一个相当标准的Debian系统。
我之前曾考虑过在其他标准 Debian 系统上(滥用)使用 Proxmox 仓库，仅仅是为了获取内核……
在公司，所有物理服务器都运行 Proxmox VE(按政策规定)，90% 的虚拟机是 Debian(使用 cloudinit genericcloud)，其余为各种 Linux 和 Windows 系统。
上游内核在稳定版本中已经回滚了足够多的回归问题，Debian 的内核团队在这方面并没有提供太多帮助。
您使用的 GPU、显示服务器和合成器堆栈是什么？
集成Intel GPU且无图形系统，仅使用KMS VT(文本控制台)。这正是令人沮丧的地方——仅显示控制台不应在CPU负载下导致内核 panic！诚然，这只是个案且发生在多年前，我听说Debian现在已减少了类似RHEL的“拼凑内核”做法。
drm/i915 在我的一台机器上使用起来相当糟糕。在 5.3 内核时代，该芯片组的 Intel 驱动程序并不理想，我记得当时有很多 bug 报告。以下是我遇到的多个问题之一
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/673
英特尔的集成显卡驱动团队，实际上所有驱动团队，在一段时间内(大约五年前？)都频繁出现问题。同一时期，他们还搞砸了e1000e驱动。
另一方面，我过去和现在都有很多 Debian 安装，其中一些使用英特尔集成显卡。它们在很长一段时间内都没有出现任何问题。说实话，我甚至不记得我的任何英特尔集成显卡系统崩溃过。
…我使用 Debian 已有近二十年，见过无数 GPU 问题。我过去写 Xorg.conf 文件时甚至不用手册，哈哈。 🙂
也许你可以再给 Debian 一次机会。
是的，我放弃了 Ubuntu Server，因为升级带来的太多麻烦。我管理着 75 个以上的 VPS 实例用于应用程序托管，每次进行维护更新时都令人紧张，因为有可能会导致系统无法启动。这意味着每个 VPS 需要额外花费 1-2 小时来恢复。早在2015年Debian 8.x时代就切换到了Debian，此后一切顺畅。除非是我自己搞砸了，否则从未出现过故障。
我也是。我使用的所有服务器软件(PostgreSQL、Caddy、Bun 等)在 Debian 上运行得非常顺畅，而且我从未遇到过更新导致 Debian 服务器出现问题的情况。
我对Debian唯一的顾虑是，它倾向于在安装后立即启动新服务器软件，而我还没有机会进行适当的配置。大多数包的默认设置是合理的，但这仍然让我有点担心。我更喜欢Red Hat的安装方式，即安装后先不启动，直到我决定启用它。
这是一个众所周知的issues，但可能不太为人所知的解决方案，参见<https://unix.stackexchange.com/questions/723675/debian-ubunt…>
我认为这是在Debian上避免服务自动启动的推荐方法。
很好的提示。我记得学过，然后又忘了。可能不止一次。
这仍然应该是默认行为。
只要有合理的防火墙规则就行了。例如，如果我安装了openssh-server并且它自动启动，它无法离开我的机器，因为我的nftables不允许22端口的入站连接。这只是了解默认行为并调整你的实践而已。
这是对明显设计问题的一种“你用错了方法”的回应。
一个合理的防火墙无法防止本地攻击者进行权限提升。虽然这种情况不太可能发生，但这仍然是一个可能被利用的漏洞。
Debian 为大多数服务捆绑了 AppArmor 配置文件。这将阻止攻击者访问 AppArmor 配置文件定义的边界之外的区域。
这是对一个荒谬问题的临时解决方案。
防火墙规则难道不是 OP 提到的“配置”的一部分吗？
不，因为你可以在安装包 X 之前安装并配置防火墙。(无需了解 X 的任何信息，防火墙的默认设置即可阻止 X 执行任何操作)
但你无法(轻松地)在安装包 X 之前配置它本身；安装后，它会立即运行，因此你只能在首次运行后进行配置。
> 其中一个最好的部分是，我从未遇到过 Debian 系统因自身问题而崩溃的情况。我遇到的所有 Debian 系统无法启动或出现其他严重问题的案例，都是因为我尝试从第三方仓库添加组件，或搞砸了配置，而不是 Debian 系统本身的问题。
你不够努力 😉
我在旧款 MacBook Pro 上安装了 Debian，之前也在更老款的 iMac 上使用过，多年来遇到过一些问题。这些问题都与专有驱动程序有关——WiFi、显卡、摄像头等——苹果公司显然不希望用户在他们的硬件上使用自由软件。虽然总能找到解决办法，但过程中难免会遇到一些令人头疼的环节和障碍。
但它绝对是我最喜欢的发行版，我尽可能在所有地方使用它。几乎在任何地方都“开箱即用”，除了苹果设备。
我努力不够。和你以及GP一样，这种情况已经持续了二十年。
> 自从Ubuntu大幅下滑后，我从未后悔过。
Ubuntu在哪些方面走下坡路了？
对我来说，是Ubuntu破坏了上游项目并引入了自己不必要的系统。
我遇到的一些问题是Ubuntu造成的，而不是上游项目。其中一个是Tracker不知何故占用了大量CPU资源并拖慢了系统。另一个是输入法问题，我需要输入一种相当罕见的语言，而Ubuntu有一天突然无法正常使用。这不是上游项目的问题。
更大的问题是Ubuntu在系统尚未准备就绪时就添加了新功能。Unity桌面环境最初缺少许多基本功能，使用体验不佳。后来还有一次短暂但灾难性的尝试，试图用Mir取代Xorg。
我的非技术背景的父母仍在使用 Ubuntu，已经使用了大约二十年，对他们来说大部分时间都还不错。如果熟悉 Linux 系统，我不会推荐 Ubuntu，但对于非技术用户来说，Ubuntu 运行良好。然而，就在几个月前，我对 Ubuntu 的另一项更改感到震惊。我母亲最重要的程序是 Thunderbird，她有一个长期的电子邮件存档。Thunderbird的配置文件可以轻松地在多台电脑之间迁移，因为它只是一个文件夹的副本。突然间，Ubuntu迁移到了Thunderbird的snap版本，因此在软件更新后，她发现自己有了一个新版本和一个空的配置文件。当然，新配置文件位于~/snap目录下，而更新并没有试图与旧配置文件建立链接。
然后还有一些愚蠢的事情，比如在 Unity 仪表盘搜索中使用亚马逊搜索结果来查找你的文件或程序。不，Ubuntu 绝非糟糕，但多年来，我一直推荐 Linux Mint 作为友好的 Debian 衍生版本。
Snaps？专有包管理器从来都不是很好。
据我所知，Snap 作为包格式本身并非专有。它与 Flatpak 一样开源。专有的部分是 Canonical 官方的 Snap 商店，他们对 Snap 进行了修改，使其仅能使用该商店。这与 Flatpak 仅绑定到 Flathub 的情况类似。
当然这违背了开源软件的精神，但其中还有一些微妙之处，不能简单地用“Snap 是专有的”来概括。
Snap 不仅在理念上存在问题，从实际应用角度也同样糟糕，正如 Thunderbird 的案例所示。Ubuntu 上的 Firefox 默认情况下在网络摄像头支持方面存在严重权限问题，即使是专家也难以解决(涉及 AppArmor、Pipewire、Snap 和 FF 设备配置)，这使得它在主流笔记本上无法用于仅通过浏览器访问的 Microsoft Teams 等场景。
容器技术虽在服务器端流行，但对桌面环境只会增加故障风险和开销，尤其对于像Debian的apt这样已成熟且组织良好的系统。过去十多年间，根本没有出现过足以 justify 引入额外抽象层的新桌面应用。
此外，使用 snap 的应用程序启动速度明显更慢。这完全不可接受。
我尝试过制作 snap 包，但发现它们与 Ubuntu 的基础包紧密绑定。它们完全不具备可移植性。本质上，它们只是针对用户级应用程序的 Ubuntu 专用包格式。
例如，使用 FlatPak 时，你可以为包选择一个基础运行时，其中包含大部分与系统无关的库。而使用 snap 时，你需要指定一个 Ubuntu 版本作为基础运行时，并添加额外的依赖项，这些依赖项都是 Ubuntu 包。
我的理解是，基础层(类似于 FlatPak 提供的)是共享的，并由 snap 管理器下载，因此只要你想下载它，它就是可移植的。
最终结果应与 FlatPak 类似，即几乎没有依赖项，因为它应打包几乎所有内容。
他们是否已发布用于托管自有 Snap 仓库的服务器组件？
我似乎找不到相关信息。任何指引都将有所帮助，至少让我了解该项目的最新状态。
Snapd 仍然硬编码了 Canonical 的 Snap 商店签名密钥，并且没有提供添加自有密钥的机制。其他 Snap 仓库将被视为二等公民。
没有，但由于 Snap 是开源的，实现起来非常简单，因为你知道它需要什么样的有效负载。
> 如果我试图操纵你所说的内容，我可以尝试将某物包装成开源软件，而实际上并非如此。
我没有说“Snap 格式”。
服务器不是，而客户端对使用替代服务器持敌对态度。Snap 是一种解决方案，挑出其中一部分是具有误导性的。
我不太明白为什么这是个大问题。你不必使用 Snap。
默认设置很重要，而 Snap 是 Ubuntu 的默认设置。
话题不是 Snap 是否可避免，而是 Ubuntu 正在走下坡路。而 Snap 被认为是这种走下坡路的一部分，这将是 Ubuntu 的 NIH 综合症。据我所知，Ubuntu唯一成功的开发就是Ubuntu本身——其他项目多年来都已失败，而Snap虽然仍在进行中，但也并未赢得任何人气。
Snap本身并不比Flatpak更好或更差。Canonical的错误，我认为，是将他们的商店作为Snap的唯一托管场所。这就是大家一直在谈论的“专有”部分。
但实际上，即使对于 Flatpak，如果你想获得任何关注，唯一现实的发布平台就是 Flathub，因此两种格式目前都只有一个商店。但 Flatpak 允许自定义商店，而 Canonical 出于某种奇怪的原因决定不允许 Snap 享有这种自由。
另一个问题是，Canonical曾承诺发布服务器组件并启用替代商店，但他们似乎“忘记”了这一承诺。
此外，在未征得用户同意的情况下，强行将用户迁移到Snap并“对Snap团队施加压力以保持其质量”的做法，让用户感到不满。
> 但实际上，即使对于 Flatpak，如果你想获得任何关注，唯一现实的发布 Flatpak 的地方就是 Flathub
但是，对于任何规模的系统，从家庭实验室到企业客户农场，我可以托管自己的本地 Flathub，并安装自己的专用 Flatpak，无需支付任何费用，也无需担心我的包是否会在第二天早上还在那里。
自由很重要，尤其是在那个生态系统中，自由是常态。
我对Ubuntu一直持中立态度，但现在我完全避免使用它，并以最快的方式将剩余的Ubuntu服务器迁移到Debian。
顺便说一下，我已经使用Debian大约20年了。
是的，我也是。我当初选择Ubuntu是因为继承的服务器运行的是Ubuntu，之后自然而然地在桌面端也使用了它。但随着时间推移，我逐渐对他们的“非我发明不可”(NIH)心态感到反感，尝试过更换发行版，最终选择了Debian。
是的，我同意。Snaps或Flatpak在实际应用和技术层面差异不大。它们的区别在于分发方式，包括后端开源的可用性，这使得例如Red Hat和Elementary能够运行自己的商店。
如果你在制作自己的发行版，创建自己的Flatpak商店是轻而易举的，这就是关键所在。Linux Mint不使用Snap，正是因为Canonical强制所有人使用他们的Snap商店。
Canonical 并未强制任何人使用任何东西。Snap 是开源的，如果你想使用不同的商店，只需修改它即可。Mint 实际上分叉了一个僵尸桌面环境，但修改 Snap 中的几行代码却成了问题……
默认设置非常重要，Snap 并非开源(客户端是，后端不是)，你无法“只需修改它(Ubuntu)”来使用不同的商店，因为 Ubuntu 甚至通过 apt 安装 Snap。Mint 不在讨论范围内。
> Mint 不在讨论范围内。
阅读我回复的父评论
我的错，我忽略了这一点！
https://news.ycombinator.com/item?id=44849691
> 这正是Ubuntu的“不愿采用他人成果综合征”
Red Hat也做同样的事。他们多次重新发明轮子(如systemd及其整个生态系统，包括systemd-resolved、timed等，以及podman、buildah、dnf等)
他们只是更成功地让自己的“不愿采用他人成果”项目被他人接受为标准。Canonical 在这方面失败了(往往有正当理由，Unity 曾经一段时间内糟糕透顶)，并放弃了这些项目，这不利于他们未来的发展。
Canonical 开发了自己的 NIH 启动守护进程 Upstart，但由于基本设计和实现存在严重缺陷而失败。Red Hat 开发更好的软件，因此他们的 NIH 项目获得更多采用。
ChromeOS 仍然使用 Upstart。
Upstart 早于 systemd 出现；systemd 的创建很大程度上是为了修复 Upstart 中被认为是根本性设计错误的问题：<http://0pointer.net/blog/projects/systemd#:~:text=On%20Upsta…>(在“关于Upstart”标题下)。
> systemd
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
> 例如 systemd-resolved 和 timed
它们并非强制要求，也不是 systemd 的必备组件，许多发行版使用功能更丰富的替代方案(据我所知，包括 RHEL——上次查看时，他们使用 dnsmasq 和 chrony)。它们通常作为独立的可选包提供：
> podman, buildah
仍远不及 Docker 流行。尽管从技术上讲它们远优于 Docker，且若有人使用它们，正是出于这一原因。
> dnf
仅用于 RHEL 及其上游 Fedora？
—
这一切都毫无意义。
>> podman, buildah
> 仍然远不及 Docker 流行。尽管从技术上讲它们比 Docker 更好，但如果有人使用它们，那也是出于这个原因。
NIH 软件包通常预计会不太流行，是的。它们有一些技术优势，尽管在我看来，这更多是权衡取舍，而不是其中一个严格优于另一个。如果每个人使用它们都是因为技术优势，而不是因为发行版在推动它们，我会感到惊讶。
Red Hat 打造了非常优秀的产品。NIH 有时是正确的，因为没有人发明过这些东西。标准 Unix 工具很棒，但它们无法解决所有问题，因此大多数发行版最终采用了“Debian 方式”或“Red Hat 方式”，当然主要区别在于 deb/apt/dpkg 与 rpm/yum/dnf。在使用Yocto构建嵌入式系统时，基本选择也是Debian风格或Red Hat风格，尽管当然可以做任何事情。
特别值得一提的是NetworkManager，它已成为配置网络的事实标准，因为它很好用。借助nmcli，我甚至可以记住如何从单用户模式连接到Wi-Fi。
>他们只是在让自己的 NIH 项目被其他人接受为标准方面更加成功。
这取决于表述方式。我们也可以说 Red Hat 生产的是真正有用的软件，而 Canonical 的开发似乎并未在现有解决方案的基础上提供额外价值。
我们还可以说 Canonical 努力尝试做与 Red Hat 相同的事情，但是在一个略有不同的领域，且成效不佳。
一个主要区别是，Canonical的项目有版权转让政策，而Red Hat的项目没有——这可能解释了采用动态差异的很大一部分原因。
你说得对。你不需要使用snaps。Ubuntu会为你逐步迁移包。
使用 apt 安装某些包时，系统会自动安装 snap 基础架构并以 snap 格式下载包。你无需手动安装。
不过这并非出于恶意，而是为了“对 snap 团队施加积极压力，促使他们产出更高质量的工作并维持质量标准”(此为官方回答的概括)。
当你使用 apt 获取时安装劣质的 snap 包，这是我经历过的 Linux 发行版拒绝尊重用户意图的最糟糕案例之一。
说得好。
这绝对是现代操作系统中除微软的胡说八道之外，最不顾用户意愿的自我强加偏好。
如果你要使用开源操作系统，系统上安装的内容控制权应本质上归用户所有。如果开发者对是否添加新包或是否需要新包有疑问，就弹出提示并询问——默认不使用应用容器和默认包管理系统。
这真的不难。
其中一次迁移严重破坏了我的工作流程，导致我不得不将系统从Debian升级为完全重新格式化，这耗费了我无法承担的数小时。
自此，Debian成为我的避风港。
你真的得费劲才能避免它们；例如，
apt install firefox会安装 snap你确实得这么做。避免它们真的很困难，因为他们已经修改了“apt”，默认会安装 snap 而不提示。
我同意邻居的评论。如何在 Ubuntu 上不使用 snap？基础 Ubuntu 安装已经包含多个 snap。通过 apt 安装随机软件会导致 snap 安装。我个人不知道如何在 Ubuntu 上避免使用 snap。
我制作了这个 snap“替代方案”来解决这个问题：https://github.com/justinclift
打包形式：https://github.com/justinclift/snapd-empty/releases/download…
这是一个空包，它只是告诉系统snap已安装，以防止强制卸载snap时出现的依赖链问题。
在过去半年里，我在几台无法更改操作系统的Ubuntu 24.04系统上使用它，效果良好。
哎呀，我不知怎么在上面评论中粘贴了错误的仓库 URL。
正确链接应为：https://github.com/justinclift/snapd-empty/
你应该迁移到 Debian。其他所有方案都只是权宜之计，随时可能被 Canonical 取消支持。
我几年前就这么做了，现在非常满意。
你需要卸载所有 Snap 包，卸载 Snapd，并通过 APT 阻止其重新安装。
然后你添加例如Mozilla PPA，使其Firefox包被安装。
是的，你需要这样做。有些包在APT中已经不可用了
如果你使用Ubuntu，是的，你需要这样做。这就是我放弃Ubuntu的原因
我忘了具体上下文，但记得一位 Ubuntu 开发者曾提到，仅 Firefox Snap 的用户数量就超过了某些流行发行版的总用户数。
我认为在面对 Ubuntu 的诸多批评时，这一点值得记住。大多数用户只是在每两年更新一次的 LTS 版本上默默完成工作。
嗯，我不知道开发者指的是哪个流行的发行版，但Debian与流行发行版完全相反。它是一个基础发行版，以某种形式在几乎所有地方默默运行。
例如，大多数基于Linux的(企业级和/或嵌入式)设备都是基于Debian构建的。
附言：Debian及其衍生版本的总安装数量是未知的。Debian安装和基础设施_不收集_此类信息。你可以安装“popularity-contest”，但安装过程中默认选择“否”，因此大多数人不会提交包选择列表，与Canonical对snap安装的跟踪不同。
他们在snap商店中的恶意软件数量也超过了所有其他发行版在其官方仓库中的总和。
依我之见，它也变得过于复杂，默认安装了太多组件，且上游补丁过多。
这使得系统更加脆弱。在2000年代末期它曾非常出色，但随后逐渐恶化。
他们试图将所有这些奇怪的Canonical专有组件植入原生Debian并取代常见组件。
snap、lxd(不是lxc！)、mir、upstart、ufw。
这永远没有尽头，而且总是失败。
LXD被分叉为Incus，这绝对是一大乐事。
无缝的 LXC 和虚拟机管理，支持集群、干净的 API、YAML 模板和内置负载均衡器，就像 Kubernetes 用于有状态工作负载一样。
Incus 非常棒。我认为 Proxmox 是大家在 VMware/Broadcom 事件后迁移的目标，但人们也应该认真考虑 Incus。
快照和motd中的广告
此外，缩短支持周期以推动Ubuntu Pro的采用。对部分包进行微调使其行为略有不同。
切换至sudo-rs、uu-coreutils(基于Rust的组件)等。
它不再是Debian的衍生版本。它变成了另一种东西。
以前就不是我的菜，现在更是不是我的菜。
切换到基于Rust的系统软件与那些明显以盈利为目的(或以控制为目的，这本质上也是长期盈利)的改动(如广告和Snap，使用Snap有巨大阻力)完全不同。
是的，但我更喜欢在我的安装中使用基于 glibc + GNU Coreutils 的系统。它们是在像 snap、Ubuntu Pro 和 MOTD 广告这样的(致命)问题上额外添加的钉子。
另一个需要问的问题是：与直接使用Debian相比，它在哪些方面有所改进？
在早期，它对关键图形堆栈的发布计划与Debian不同，且通常更具一致性。
随着时间的推移，一旦Shuttleworth决定收取下一笔赎金，你越来越有可能遭遇突如其来的变故。
> 与直接使用Debian相比，它在哪些方面有所改进？
他们的律师愿意冒风险发布预编译的ZFS内核模块(这些模块始终与内核保持同步)。如果你对这类技术感兴趣，这非常重要，因为在安装后移除冗余代码比多年来一直关注DKMS(确保它没有自行拆解并继续正常工作)要容易得多。
在我的其中一台机器上启动 Firefox 只需几分钟。
Unity 应用程序菜单中的亚马逊广告(那叫什么来着，‘lenses’还是什么的？)。
我是一个老派用户，所以并不是Ubuntu的目标受众，但Ubuntu在处理一些较旧、使用较少的Linux组件时表现不佳。
我记得的两件事是NFS的默认配置问题(除了需要安装nfs-common，我对此没有意见)和apt-cache不显示包描述。还有许多其他小问题影响了像我这样的人，但不会影响那些在2010年后才接触Linux桌面的人。不过我的记忆力不好，所以只记得这两点。是的，这些问题有提交过 bug 报告，但它们在跟踪器中躺了多年，Ubuntu 方面从未关注过。
当我长大到不再在意落后几年时，我又回到了Debian。
哦……天啊。
> 我喜欢dpkg，我喜欢Debian的文档，即使Arch在这一方面仍然是最好的。
这很奇怪，因为在我学习制作 Debian 包时，我发现官方文档比其他任何发行版的都要好得多。特别是《政策手册》，非常详细，不断改进，甚至记录了每个版本之间的增量变化。(最后一点使包维护者更容易跟上当前的最佳实践。)
Arch在这方面有更好的东西吗？
你是否在将Arch的维基与Debian的维基进行比较？在这方面我同意你的观点。
> 我从未遇到过Debian系统因非人为因素而崩溃的情况。
我的经历与此相反。我是一位使用 Linux 超过 25 年的用户，尝试过多种发行版，但其中约一半时间以 Debian 作为主要桌面系统。大约十年前我与 Debian 分道扬镳，以为我们还能做朋友，但每次尝试在新的机器上安装它时，都会发生一些奇怪的事情，最近一次是在一个月前，在一台全新的 Intel N150 机器上，它在视频模式方面给我出了问题。今天，我的笔记本电脑在从bookworm升级到trixie时出了问题，出现了大量错误信息，导致无法使用Docker和VirtualBox。幸运的是，Debian早在我升级前就教会我将整个根文件系统备份到外部存储介质，因此没有造成实际损失。但现在时间紧迫，我必须尽快迁移到其他系统，否则将被迫使用一个与任何新软件都无法兼容的旧版本。
> 我喜欢 Debian 在理念上的审慎务实态度
关于 Debian 可以说很多，但就我而言，那不是重点。
Debian 因纯粹的理念原因对软件进行补丁修复，因为他们认为这些软件不够自由。那不是务实，而是务实的反面。这无疑给试图发布这些软件的开发团队带来了巨大负担。
你没经历过他们无缘无故破坏OpenSSL随机数生成器的那段日子。那是在2008年，导致的漏洞至今仍未消除。https://16years.secvuln.info/
我仍然使用Debian，但即使过了这么多年，我仍然无法忘记这样的事情。
虽然我同意你的观点，但如果你设定这样的标准，那么Debian在所有我使用过的操作系统中都遥遥领先，无论是否基于Linux。我记得几十个更严重的 Windows 漏洞，其中大多数甚至没有影响到我，因为当时我没有使用 Windows。Mac 也有它的份额。
你期望 Debian 今天对这个 17 年前的事件做什么？
> 其中最棒的一点是，我从未遇到过因系统自身问题导致的Debian系统故障，所有问题都与我自身操作有关。
https://blog.kronis.dev/blog/debian-updates-are-broken
https://blog.kronis.dev/blog/debian-and-grub-are-broken
不过，我遇到的绝大多数软件偶尔也会出现故障，我感谢Debian的存在。
我认为这一切都是真的，但“这是我的错”这一部分在我使用NixOS后有所改善。系统崩溃了？只需重启到上一版本并从Git获取configuration.nix即可。我在2016年首次安装后不久曾重新安装过一次，但我不记得自己做错了什么。第三次安装NixOS是在上周，当时我购买了一台预装Windows的新电脑。
Debian 是我的基础。我将服务器运行在旧稳定版上，并在临时系统上测试新版本的功能。
我通过 Bookworm 学习了 nftables，通过 Trixie 学习了 labwc。
labwc 支持通过 Openbox 配置的 Wayland。
为什么你仍然使用旧稳定版而不是稳定版？
我一直是Fedora用户，现在也是。但我的电脑在2023年迁移到了Proxmox(Debian)。现在一个Fedora Atomic在虚拟机中运行，使用flatpaks和podman容器：D
你没有具体说明你喜欢 Debian 的哪些方面，你所写的大部分内容也适用于许多其他发行版。
那么，以下是我不喜欢 Debian 的地方 🙂
– 我不喜欢Debian的包管理工具(dpkg、debootstrap、debuild等)。实际上，我讨厌Debian打包体验的方方面面。每次为Debian打包时，我都会陷入chroot环境的混乱设置中，不得不三番五次确认环境中没有泄露任何内容。
– Debian 有个习惯，就是按照自己的方式重新打包一切，無視上游的設計理念。Debian 的包會擁有自己的一套配置目錄、默認設置、路徑等，與原始安裝的樣子完全不同。
– Debian 有個令人討厭的習慣，就是默認啟動已安裝的服務。因此你總是要在配置管理中繞來繞去，先禁用服務，再安裝、配置，然後重啟。
你通常是就地更新还是在有新主要版本发布时进行全新安装？
我总是就地更新。并且我遵循发布说明中所有升级流程的建议。
感谢所有使 Debian 及其衍生版本成为可能的 Debian 志愿者。你们的工作让如此多的人和企业受益，这真是令人惊叹。感谢你们！
个人而言，Trixie 对我来说非常令人兴奋，因为我的副项目 ntfy [1] 已被打包 [2] 并现在包含在 Trixie 中。我直到发布周期后期才得知该项目已被纳入，当时包维护者要求澄清许可证问题。因此，Debian 版本的 ntfy 不包含网络应用(这真是个遗憾)，并且有几处被“移除”(这没关系)。我联系了维护者，并最近添加了构建标签[3]，以便更轻松地移除 Stripe、Firebase 和 WebPush，这样下一个 Debian 化版本就无需包含(如此多的)尴尬补丁。
作为“上游维护者”，我必须说，为什么不包含网络应用程序一点也不明显。它显然是被故意移除的[4]，但我真的不知道该如何将其纳入下一个Debian版本。如果网络应用程序无法正常工作，大多数人执行“apt install ntfy”将会非常令人失望。任何帮助或指导都非常欢迎！
[1] https://github.com/binwiederhier/ntfy
[2] https://tracker.debian.org/pkg/ntfy
[3] https://github.com/binwiederhier/ntfy/pull/1420
[4] https://salsa.debian.org/ahmadkhalifa/ntfy/-/blob/debian/lat…
维护者在此处给出了简要说明：https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098866#10
> 该网络应用是一个 Node.js 应用，需要一些目前不在 Debian 中的包。
由于在 Debian 中将依赖项打包到包内部是被不推荐的，维护者本需要自行添加并维护这些包。我猜他们不想承担这个工作。
> 但由于缺少 golang 和 nodejs 包，ntfy 中的多个功能无法通过 Debian 包管理器获取
哇。Node 和 Golang 难道不应该已经包含在 Debian 的官方仓库中了吗？
Node.js本身是有的，但当你手动安装一个Node项目时，你需要输入npm install并等待它下载所依赖的500个不同包。
Debian遵循与其他传统语言相同的哲学，期望所有这些依赖项都被打包为独立的Debian包。
我只是想说，这让我认真考虑是否要采用禁止重新打包的许可证/政策：有人可以重新打包我的项目，而且做得更糟，还继续使用我的项目名称？绝对不行。我不想承担当人们向我抱怨重新打包版本缺少某个功能时带来的负担。
我的意思是，这就是开源软件的运作方式。任何人都可以分叉你的项目，做任何事情，然后收工。采用MIT许可证或其他许可证也无法拯救你——重新打包业务基本上就是AWS的整个商业模式。
分叉是可以的，做任何事情，但一旦你对代码进行了实际修改，就应该采用自己的名称。这就是商标的作用，只是官方商标注册对开源项目来说有些难以企及(例如：成本)。你能想象为每个小项目都申请商标，以防有人将其重新打包并大量摘取其中内容吗？
是的，但并非所有用这些语言编写的包都是如此。
关于网络部分：
Debian 源代码必须足以构建。因此，对于 npm 项目，通常需要一个特定于 Debian 的 package.json 文件，其中每个 npm 依赖项(包括构建所需的开发依赖项)必须被替换为其等效的 Debian 包(可能也需要移植)、封装(通常不太理想，尤其是对于第三方代码)，或移除。哦，还有，享受为所有这些版本对齐的乐趣吧。这虽然可行，但面对如此庞大的锁定文件，工作量并不小。如果我猜得没错，维护者可能无法为额外的工作量和梳理所有这些包的努力找到合理理由。
我认为无论哪种情况，Debian 的做法可能是将其拆分为一个补充的 ntfy-web 包。
只想说声感谢 ntfy！我每天都用它来接收家中 Meshtastic 节点的事件通知。
感谢 ntfy，这真是个实用软件！
或许将它作为容器发布(如果尚未如此)来处理依赖关系会更合适。
https://docs.ntfy.sh/install/#docker
> ntfy镜像支持amd64、armv6、armv7和arm64架构。使用起来应该相当简单。
> 因此，Debian 版本的 ntfy 不包含网络应用程序(这真是个遗憾)，并且有一些功能被“移除”(这没问题)。
我的建议是，拒绝为使用 Debian 版本软件的用户提供支持，并自动关闭所有来自 Debian 的 bug 报告，声明你不支持外部补丁的软件。
你绝不是第一个这样做的人，这是一个完全合理且明智的决定。你无需参与 Debian 自身政策强加给维护者和用户的疯狂行为。
我同意维护者不应被期望支持其软件的补丁版本，但作为用户，我喜欢你所称的“疯狂”的Debian政策。我实际上会选择Debian，正是因为他们对依赖关系持谨慎态度。
Debian 并非对依赖关系谨慎。Debian 经常破坏他们发布的软件，有时是明目张胆地移除整个功能，有时是悄无声息地引入新 bug。我并不在意 Debian 是否认为这不算破坏。从我的角度来看，用户在尝试使用我的产品时会获得远非明确的糟糕体验。
我个人不会使用Debian，但人们有权自由选择。我不想浪费时间与Debian维护者打交道，也不想按照他们认为软件应该如何运作的方式来处理。我建议所有软件开发者都这样做，并且对此直言不讳，因为很容易被灌输一种观念，认为你应该以某种方式支持他们的用户，因为他们想使用你的产品，或者认为为了支持他们那些冷门目标而引入更改是合理的，尽管未来的支持负担实际上会落在你身上。
我想明确告诉那些决定对它不感兴趣的人，他们并不孤单，这样做完全没问题。
需要明确的是，我这里特别提到 Debian，因为他们在打补丁方面是最大的罪魁祸首，但这条评论同样适用于任何应用侵入性补丁的发行版。
Debian 在依赖关系方面确实更为谨慎，因为你不会遇到不在仓库中的隐藏依赖关系。
我不想安装一个会下载并执行 500 个 Node 包的应用程序，而我不知道这些包的作用。这些包应该已经过审核并包含在 Debian 中。如果没有，那我对它不感兴趣。
绕过发行版仓库获取仓库中软件的依赖项会导致意外行为。
> Debian 在处理依赖项时更加谨慎，因为您不会遇到仓库中不存在的隐藏依赖项。
对于“谨慎”的定义，我个人并不认同。
Debian 并不审核包。Debian 维护者比他们经常质疑的“上游”更不称职，这就是为什么他们会以不同程度的严重性破坏东西(OpenSSL 有人吗？)。更不用说那些疯狂的事情，比如维护者决定支持他们喜欢的分支而不是用户实际上想要的软件(Libav 有人吗？)。
> 如果不是这样，那我没兴趣。
这是你的选择。这并不意味着开发者应该关心，也不意味着这实际上是个好主意。
ntfy 是一个非常有用的工具。非常感谢你制作了它，也感谢你为我们这些懒得自己托管的人维护 ntfy.sh 服务。
祝贺！
Debian 是我自由计算生活三十年的稳定基石。他们的一切做法——从向我展示康多塞、组织稳定的混乱、通过有节制的共识前进，到基于艰苦奋斗的原则——都以某种方式影响了我，从技术到社会，再回到技术。
我热爱这个项目，以及它通过发布和文化对世界产生的不可估量的影响。
带着我全部的爱，g’o xx
> i386 架构不再作为常规架构支持：i386 系统没有官方内核，也没有 Debian 安装程序。i386架构现仅限于在64位(amd64)CPU上使用。运行i386系统的用户不应升级至trixie。Debian建议用户在可能的情况下重新安装为amd64，或淘汰该硬件。
令人惊叹的是，i386支持一直延续至2025年8月。我正在 Pentium 3 系统上运行 Debian 10 Buster，该处理器于去年 6 月 2024 年才达到生命周期结束(EOL)。该硬件仍可正常使用，我对支持持续如此之久深表感激！
OpenBSD 仍为寻求在旧 32 位硬件上运行现代操作系统的用户提供 i386 支持。
希望i386(或可能是一个新的i386类端口，添加对64位时间值的支持)能够迁移到Debian 14(forky)或Debian 15(duke)的非官方Debian Ports基础设施。Debian Ports有一个m68k端口，因此支持i386端口不应是太大问题。
有何目的？若非出于怀旧情结(例如运行古老硬件)，您很可能拥有需要该环境的定制应用程序。无论是出于技术限制、合规要求，还是对未知技术的恐惧，都无法改变现状。请将系统与互联网隔离，并继续运行最后一次正常工作的版本。
我对不必要的电子废物感到不满，但i386架构的处理能力几乎比树莓派或N100低一个数量级。
Debian的口号是“通用操作系统”。它是一个在大量架构上都有活跃端口的发行版[1]，甚至包括一些极其冷门的架构。
这种普遍兼容性的目标使Debian项目与商业软件以及其他开源项目区分开来。
传统的x86架构仍然比Debian宣传的某些官方支持平台更受欢迎，而且直到最近，仍然有基于x86的处理器为利基应用程序制造，例如AMD Geode和其他处理器。
我认为Debian项目停止对新x86系统提供官方支持实在令人遗憾。不过值得庆幸的是，似乎会有非官方的移植版本，而且像MX Linux和AntiX这类小众发行版可能会继续维护自己的构建版本。
如果开源社区能开发出更强大的机制来维持对这些相对小众架构的支持(例如通过增加对模拟技术的依赖而非实际硬件)，那将是最理想的。
[1] https://wiki.debian.org/SupportedArchitectures
我的 Linux 机器非常现代化，但我仍然需要安装 i386 架构支持，因为 Steam 需要 32 位支持。而 Steam 需要 32 位支持，以便用户能够玩 15 年前的游戏。
(诚然，Ubuntu 提供的 32 位支持并非完整的操作系统，且如今无法在 32 位机器上安装 Ubuntu)
Debian 在 i386 架构方面的做法与 Ubuntu 基本一致。虽然仍为该架构构建软件包，但i386系统不再受支持，且没有32位内核包。
例如，注意i386仍列在https://packages.debian.org/trixie/bash的底部
因此，如果你使用的是 amd64 CPU，Debian 的 “i386” 包仍可在其上正常运行。根据发布说明：
> i386 架构现仅适用于 64 位(amd64)CPU。
也许这是那些在 CPU 频率未达到 33 MHz 时运行过快的游戏之一。;)
在当前硬件上，启动 Steam 可能需要几天时间，考虑到其加载时间。
我认为这种情况不再存在，参见https://gitlab.winehq.org/wine/wine/-/releases/wine-9.0#wow6…，不过这并非所有地方的默认设置。
根据Passmark的测试，奔腾4 1.3GHz处理器的性能仅为树莓派5的1/55，因此我估计两者性能差距至少有两个数量级。而初代树莓派的性能则是奔腾4 1.3GHz的16倍…
你可以回收电子废物(是的，我知道部分电子废物最终会流向中国/印度等国家。但并非全部如此。)
电子废物的问题远不如电力消耗带来的碳足迹差异巨大。
> 原版树莓派的速度是P4 1.3GHz的16倍…
并非如此。我用过两者。
~700MHz的ARM 11架构，主要是顺序执行，没有SIMD。我用过很多次。
..vs..
1.3GHz乱序执行带SIMD
i386架构并未被淘汰，它仍在存档中以支持32位应用程序。主要变化是存档中不再包含32位内核(linux-image-686包已不再提供)。但大多数包仍提供 i386 版本：
它仍然存在，但没有官方的 ISO 或安装程序。
如果情况就是这样，你仍然可以使用debootstrap，编译一个内核，并将根参数指向你全新的安装。
如果官方的i386架构是用你的硬件不支持的指令集构建的，那只能自认倒霉。
如果官方的i386架构是用你的硬件不支持的指令集构建的，那只能自认倒霉
虽然理论上可能，但这种情况只会出现在 30 年前的处理器上。Debian 的 i386 架构仍以 -march=i686 作为基准编译目标，即经典的 Pentium Pro：https://en.wikipedia.org/wiki/P6_(microarchitecture)
我有一台2007年左右的AMD Geode硬件(18岁)，仅对i686有部分支持。需要真正的3/4/586内核。
不确定为何被点赞，可能是人们不相信这是事实。确认如下：AMD Geode LX是一款<5W的32位x86处理器，不支持SSE指令集，因此并非完全兼容i686。根据维基百科，该处理器生产至2019年：https://en.wikipedia.org/wiki/Amd_geode#AMD_Geode
它被用于 OLPC XO-1 项目。思科 ASA 系列防火墙在其生命周期中的某个阶段也曾使用过 Geode 处理器。
若有人想进行相关操作，以下是新端口文档：
https://wiki.debian.org/PortsDocs/New
其中大部分信息与从头开始创建新的硬件端口有关。i386 支持只需在正式计划从主 Debian 仓库中移除后(这可能从 Debian 分支或 duke 开始)，将其降级到 Debian 端口基础设施中，这可能需要一些特殊处理。
(回答“有何用途？”的问题，目前二手市场上仍大量存在且价格低廉的32位专用硬件(如早期“上网本”)，其中许多设备做工优良且使用体验良好。尽管此类硬件已无法流畅浏览“现代”网页，但仍可用于轻量级任务，包括作为更强大机器的“瘦客户端”。)
现有i386端口将保持原样以支持旧软件(尤其是游戏)(但CPU基线可能会提高)，它不会被移除，因此您需要为32位专用硬件创建新架构。
由于i386也不会进行2038年问题转换(因为这会破坏ABI)，因此你需要为新端口创建新的ABI，或者也为其进行2038年问题转换。
随着时间推移，越来越多的32位漏洞会被引入，因此维护工作也将大量增加。
> …它不会被移除
我看到过关于这一点的矛盾信息，但没有官方声明。我想一旦 forky 的实际发布计划确定，我们就会知道更多，这可能需要一些时间。
你是否将“386”与 32 位混淆了？686是标准的32位架构。386是上世纪80年代的产物，对吧？
当发行版提到i386支持时，通常实际上指的是i586或i686，是的。
真正的i386支持意味着与1985年原版Intel 386处理器兼容。486处理器在1989年添加了少量新指令，但真正带来变革的是1993年的奔腾处理器——这为我们带来了i586架构，这是当今大多数现代软件的最低要求。虽然许多软件仍可在普通奔腾处理器上运行(若编译支持)，但SSE2优化则需要至少奔腾4或酷睿系列处理器。
我经常玩复古电脑，发现OpenBSD的i386目标在4.1版本后停止支持真正的386处理器，并在6.8版本中逐渐停止支持i486。现在至少需要奔腾级处理器(i586)，尽管该架构仍被称为i386，可能是因为它常被用作“32位”的代名词。
Debian 3.0 是最后一个在 80386 处理器上运行的版本，但即使“i386”架构的 CPU 要求提升到 486、然后是 Pentium、再到 Pentium II，这个名称仍然保留下来。部分是因为惯性，部分是因为不想破坏现有的镜像基础设施。
是的，386 和 486 在整个 90 年代仍保持相关性，因为新处理器的价格总是更高，而客户更倾向于选择更多或更快的内存/磁盘空间/显卡/声卡(那时候这些都是重要因素)而非更出色的 CPU 性能。
Linux内核现在也要求至少支持i486。据我所知，这一决定与优化多核/对称多处理(SMP)支持有关——这有点荒谬，因为常见的80386系统甚至不支持SMP，更不用说多核了。但不管怎样。
Linux在386芯片上运行良好——这实际上就是它最初开发的平台。但英特尔在486、奔腾和奔腾Pro芯片中添加了大量新功能。在某个节点上，决策者认为继续支持P6架构之前的芯片已无价值。
这是一个有些奇怪的决定，因为无疑有更多 386、486 和奔腾用户，而 Linux 继续支持的一些平台用户更少，但这就是他们做出的选择。但他们并非孤例。就连 NetBSD 也要求至少使用 486DX 处理器。
据我所知，Debian在架构名称上仍保留了i386，尽管其32位要求已有所演变。
i386是32位x86架构最常见的称谓https://en.m.wikipedia.org/wiki/IA-32
据我所知，这指的是 Debian 的支持，而 Linux 内核确实支持 32 位 CPU，尽管仅限于原始的 Pentium 处理器(不包括某些克隆版本)。
那么，旧的稳定版本是否还有额外一年的支持？也就是说，超过 2025 年。
Buster 的支持将持续至 2028 年 6 月。
Debian 并未提供此支持。
https://www.debian.org/releases/
Buster 早已不再获得 Debian 的支持。
Buster LTS 去年夏天已达到生命周期结束(EOL)。请注意，LTS 由非营利组织通过志愿者提供支持，而非 Debian(尽管他们做得很好)。
ELTS 是付费支持，同样非 Debian 提供。
请查阅 Debian 的维基以获取更多关于支持时间框架以及 LTS 和 ELTS 含义的信息。
我原本打算写《书虫》。《书虫》是最后一个支持i386内核的系统，其支持期限将持续至2028年6月。
Freexian是一家营利性公司，所有LTS/ELTS贡献者均为Debian维护者，而LTS是Debian的一部分，ELTS虽也公开可用，但存放在外部存档中。
https://wiki.debian.org/LTS https://wiki.debian.org/LTS/Team https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Funding
啊，他们曾经宣传过是非营利组织，但现在看来已经改变了。那可能意味着“我们不追求利润”，而不是“非营利实体”。感谢您提供这方面的信息。
回到LTS：
Debian LTS并非由Debian安全和发布团队管理，而是由一群对推动其成功感兴趣的志愿者和公司组成的独立团队负责。
简而言之，Freexian 100% 不是 Debian，也不是 Debian 的“一部分”，它只是免费使用 Debian 的基础设施来支持 LTS。这并不影响他们所做的良好工作，但我们也不应将一家私营公司及其目标与 Debian 及其目标混为一谈。
LTS 尽最大努力，但仅支持其能力范围内的内容。这并非其过错。因此，他们会优先处理使用范围更广且已收到捐赠的软件包。
因此，像 Apache2、MariaDB 等广受欢迎的软件包将得到妥善处理。而全球仅有 400 名用户的罕见软件包？则不然。
LTS会接受补丁和任何帮助，但这仍与用户数量相关。如果一个包在全球只有400名用户，且大多数用户已升级到下一个版本？我想你明白我的意思。
(我曾让客户放弃使用LTS，因为他们使用了罕见包，同时向他们保证LAMP服务器仍受支持。这里流行度很重要，因为这涉及志愿者和外部人员的努力。)
—
ELTS 仅支持软件包的子集。这不是“完整”支持。我认为在桌面环境中使用它极为不明智，除非他们付费获得支持并获取了所有受支持软件包的列表。
—
https://www.freexian.com/lts/extended/docs/debian-10-support…
“请注意，当您请求报价时，我们会发送一份不支持或支持有限的软件包列表，以便您做出明智的决策。”
是的，我知道该页面提供了 Git 仓库等部分支持信息。
但我的观点是：整个发行版并非全部受支持，您需要自行跟踪这些信息，必须保持谨慎，即使如此，也需确保未运行罕见软件包。
再次强调，这两个程序都非常出色。它们表现良好，且专心致志，但我们必须清楚这里的限制。
例如，稳定版 Debian 中 main、non-free 和 contrib 仓库的安全支持差异：
https://www.debian.org/security/faq#contrib
如你所见，contrib 和 non-free 仓库实际上没有保证的安全支持。原因虽合乎逻辑，但用户需明确此处的细微差别。
同样，用户需明确LTS与ELTS的细微差别。
例如，我所有服务器安装均通过preferences.d中的pinning规则屏蔽了non-free、non-free-firmware和contrib，仅允许特定的绝对必要包重新启用。
(例如，我可能允许命令行应用程序，但不允许任何网络连接的应用程序，并且仅在对功能、SUID 位和其他类似内容进行一次检查后才允许)
—
实际上，我认为 LTS 是一种普通用户不应使用的依赖。我建议我们集体不要鼓励桌面用户(例如)使用 LTS。
LTS/Freexian团队成员均为Debian成员/贡献者，因此说“Freexian完全不是Debian”并不准确。基本上，一些Debian成员成立了一家公司以获取资金开发LTS版本，并提供其他付费服务。
至少对于bullseye版本，LTS团队据称支持所有包，除游戏和少数其他包外。要查明哪些软件包不受支持也非常简单，只需运行一个命令即可，无需发送邮件。
https://wiki.debian.org/LTS/Bullseye https://wiki.debian.org/LTS/Using#Check_for_unsupported_pack… https://salsa.debian.org/debian/debian-security-support/-/bl…
其他部分已达成一致，不过需注意 LTS 贡献者是获得报酬的，而安全团队成员可能并非如此(尽管其中部分成员确实获得报酬)。
我认为在实际操作中，当贡献/非自由软件从上游获得安全更新时，Debian 确实会在稳定版/长期支持版中收到更新。例如英特尔微代码或 Wi-Fi 固件。
我也觉得 Debian 拥有长期支持版是浪费时间，人们应该能够在旧稳定版的一年常规安全支持期内升级到下一个稳定版。
顺便说一下，Ubuntu的安全支持也存在类似问题；main仓库有支持，universe仓库则没有。
谢谢，我猜其中部分是某种扩展的、带星号的支持吧？
游戏软件不受支持，还有一堆其他包：
https://wiki.debian.org/LTS/Bullseye https://wiki.debian.org/LTS/Using#Check_for_unsupported_pack…
如今OpenBSD至少需要Pentium处理器。
没错！我做了一些测试，发现6.8是最后一个支持486处理器的版本。原因是OpenBSD项目在6.9版本中切换到了clang编译器，并在过程中依赖于Pentium指令集。
不过这并不妨碍你在老款 Socket 3 主板上安装 Pentium Overdrive 并运行最新版本。;)
天啊，我以为自己用 P3 算落后了，那都 2007 年了哈哈。现在花 $1 就能买到快 100 倍的处理器 😀
哈哈，没错，这只是台用于娱乐/爱好的电脑。它的配置相当不错——1.3GHz处理器、512MB内存、512GB SSD(通过SATA卡连接)、快速AGP显卡。我可以在这里运行1080p分辨率的Debian桌面系统。
Debian(以及许多其他提供编译二进制文件的发行版)使用“i386”来指代所有32位x86处理器，包括Pentium 3。
随着Trixie的发布，APT宣布采用新的源格式“debian.sources”。较旧的“sources.list”格式仍被支持，但未来可能在Debian版本中被废弃。
详见下方：
– https://wiki.debian.org/SourcesList#APT_sources_format
– https://www.debian.org/releases/trixie/release-notes/upgradi…
“apt modernize-sources” 命令可用于模拟并用新的 “.sources” 格式替换 “.list” 文件。
> apt modernize-sources
哦，真方便，我几年前手动转换了所有文件。当时如果有这个就好了(或者知道这个？)。我真的很喜欢新的 deb822 格式，将 GPG 密钥内联嵌入其中很方便。我希望一旦这个格式普及，使用自定义公共 apt 仓库的人们会开始直接提供 .sources 文件。这应该比以前处理 apt-key 相关操作(尤其是密钥轮换时)要简单得多。
同感。我一开始也需要一段时间适应；我的第一反应是“通过脚本创建会更麻烦”，但随后Ansible在2.15版本(Bookworm发布前不久)添加了deb822_repository [0]，问题便迎刃而解。
[0]: https://docs.ansible.com/ansible/latest/collections/ansible/…
DEB822 至少从 Buster 版本开始可用。我认为 Bullseye 是第一个使用它的版本。
[0]: https://manpages.debian.org/buster/apt/sources.list.5.en.htm…
它于 2015 年随 apt 1.1 一起发布，这是一次重大的配置变更，此后每个版本都在强制执行不同的内容。
哦，这很好。尤其好的一点是，它允许你在同一段中同时指定 Suites: 和 Components:，这样你就不用重复输入剩下的内容来添加 -updates 和 -backports 套件。
你仍然可以使用 sysvinit，我已经测试过服务器和桌面版本。
来自我的构建服务器：
存在一个无法绕过的依赖关系，必须同时卸载和安装相关包。Debian 中的一个漏洞指出了上述问题，通过在 “systemd-sysv-” 前添加 “-” 作为修复方案，并允许卸载必要组件。
在应用此修复后，使用debootstrap构建的sysvinit与bookworm几乎完全一致，这包括桌面环境。
与bookworm到buster版本一样，你仍然需要类似以下内容：
等等，Debian 13上的sysvinit真的能正常工作吗？也就是说，可以移除systemd并使用sysv init运行一个可用的服务器操作系统？
是的。
我也运行了一个完整的桌面环境，没有使用它。有多个变体。
不过我没有使用GNOME的桌面环境(尽管我运行GTK/GNOME软件)，所以无法对此发表评论。
是的，MX Linux 将实现这一点(作为单独的 ISO 镜像，目前他们一直提供一个单一 ISO 镜像，允许用户在每次启动时选择 systemd 或 sysvinit)：
https://mxlinux.org/blog/changes-coming-with-mx-25/
如果你在WWW的其他地方有更好的内容，我可以为你提供比在Hacker News上随机帖子超链接更详细的引用。(-:
* https://jdebp.uk/Softwares/nosh/guide/services/systemd-login…
为什么你要这样做？
可能是为了避免使用 systemd。不过，此时也可以直接切换到 Devuan。
选择。
感谢分享。我倾向于在我的LXC容器中采用它，至少目前是这样。
我一直使用sysvinit直到Debian 11。然后它在LXC容器中变得无法使用 :(，所以我不得不咬紧牙关。但对于基本系统，它确实有效。
他们只是简要提到了这一点，而且没有具体说明数字，但此次发布在 AMD64、ARM64 和 RISC-V 架构上，超过 30,000 个包实现了 95% 以上的位对位可重复性(所有架构的平均值为 92%)。
祝贺团队——非凡的工作！
https://reproduce.debian.net/
在给定的 Debian Trixie 系统上，是否有工具可以知道哪些已安装的包目前无法重现？
替代解析重现网站的方法 🙂
是的！从网站上：sudo apt install debian-repro-status; debian-repro-status
你能帮助我理解为什么剩下的 5% 无法实现位对位可重现吗？例如…如果你下载一个固定版本的源代码 tar 包，并在某种容器中运行 `./configure` 和 `make`，而它没有嵌入某种时间戳…为什么 95% 是可重现的，而有些不是？我想学习/理解。
以对象地址为键的哈希表就是一个例子。
在多次运行中，malloc会分配不同的地址(由于线程或安全考虑)，这意味着对象会出现在表中的不同位置。然后你按内存顺序遍历它，你会看到对象以非确定性顺序出现，而你需要对这些对象进行操作。
嵌入文件路径/时间戳/Git SHA等信息曾流行一段时间，但对可重复构建并不友好。
我注意到 systemd 仍在做这件事，即试图强迫所有 Linux 发行版采用某人决定的唯一正确方式来做某事：
> 5.2.2. systemd 消息：系统已受污染：未合并的二进制文件自版本 256 起，systemd 上游认为拥有独立的 /usr/bin 和 /usr/sbin 目录的系统值得注意。在系统启动时，systemd 会发出一个消息以记录这一事实：系统已受污染：未合并的二进制文件。建议忽略此消息。手动合并这些目录是不受支持的，并且会破坏未来的升级。更多详细信息请参阅 bug #1085370。
目前也没有选项可以禁用此功能，具体讨论请参阅 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370
你可能不喜欢它，但“任意”并非公平的描述；其背后的逻辑已存在超过10年：
http://0pointer.net/blog/projects/stateless.html
https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor…
不过，我的第一反应是，这似乎是在强迫发行版。这让我感到很不舒服。不过，我也很想听听其他人的观点。
需要注意的是，这涉及到另一个问题——Debian已经将/bin合并到/usr/bin中，但现在systemd还希望将/usr/bin和/usr/sbin合并。
哦，谢谢，我完全忽略了这个区别。你说得对。
我的第一个想法是：为什么systemd会关心这个问题？有什么想法吗？
我的第二个想法是：在合并后的/usr中，/usr/{bin,sbin}位于同一文件系统上，那么拥有一个独立的sbin有什么好处？我的理解是，sbin 历史上一直有用，因为它可以提供在启动早期即可使用的静态链接二进制文件，而无需挂载各种库目录。但这种需求似乎已被统一的 /usr 所取代……
> 在合并后的 /usr 中，/usr/{bin,sbin} 位于同一文件系统上，那么保留独立的 sbin 目录有何意义？
实际上并没有什么好处，sbin 目录只是为了兼容性而存在。如今，早期启动过程已被 initrd/initramfs 接管。有人认为你所说的 sbin 的用途实际上是根目录下的 /bin(早期启动)和 /usr/bin(其他位置)，但这一切都非常随意，没有人能真正就用途达成一致。
有人认为 sbin 用于静态二进制文件，另一些人认为用于超级用户二进制文件，但这种区分如今已毫无意义，因为早期启动由 initrd 负责，而许多“超级用户二进制文件”在某些场景下实际上也可以在无特权模式下使用(例如 `mkfs.* `用于创建磁盘映像)，因此将它们放在单独的目录中只是任意的(例如，如果我使用cat命令读取shadow文件，cat命令也可能失败)。
>目前也没有选项可以禁用此功能，具体讨论请参见 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370
该 bug 中的讨论指出，Debian 维护者(及上游开发者)对添加此类选项的上游补丁持开放态度。
> Debian维护者(及上游开发者)对上游补丁添加此类选项持开放态度
此处为过度解读。
仅有两种现实选择：保持现状或在Debian包中移除警告信息
Debian维护者显然在推卸责任，因为所有人都非常清楚上游不会接受此类补丁。
如 bug 报告中已解释，由于 Debian 近期没有进行此迁移的计划，上述警告不仅无用且烦人，还可能造成危害，因此正确做法应是像 xscreensaver 中那样在下游移除它(https://bugs.debian.org/cgi-bin/bugreport.cgi? bug=819703#84)
但这样做会招致Lennart的愤怒，因此唯一的选择就是忽略该报告。
或许我们需要引入上游与发行版分离的概念。
你为什么认为这是试图进行说服战术？在此上下文中，taint 标志仅表示可能与调试相关的信息。如果未来的人对 /usr/bin 和 /usr/sbin 之间可能过时的划分不熟悉，这种情况可能适用。调试消息并非用于评判你的配置道德。它正在积极提升你同时支持两种方式的能力，通过正确标识系统类型以供故障排除之用。
这与调试有何关联？
此外，无论喜不喜欢，“tainted”一词带有负面含义。很难想象它是随意选择的。
> 你为什么认为这是试图进行说服战术？
因为他们这么说了：
> 作为其中的一部分，我们有时会采用之前仅由其中一个发行版使用的方案，并将其提升到系统d的默认设置水平，试图温和地引导所有人采用相同的基礎配置[1]
1. https://0pointer.de/blog/projects/the-biggest-myths.html
这段内容是在那条调试日志添加之前11年写的。两者之间几乎没有关联。11年间事情确实会发生变化，信不信由你。
这是他们的惯用做法，而且从未改变，信不信由你。
> 我们的确有意通过温和推动各发行版朝同一方向发展，使其停止支持这些毫无意义的偏离解决方案。[1]
> 发行版可通过下游补丁偏离此方向，但通过将此设置为安全默认值，我希望能够温和地推动所有人朝同一方向发展。
> 开始逐步引导用户为缺失的架构定义GPT分区类型UUID。 > 让我们生成一条单一的gcc `#warning` 提示，要求用户为其架构定义分区类型UUID，如果这些UUID缺失的话。 [3]
[1] https://lists.freedesktop.org/archives/systemd-devel/2010-Se…
[2] https://lists.freedesktop.org/archives/systemd-devel/2011-Ma…
[3] https://github.com/systemd/systemd/commit/d42e4fa258701ff5e0…
真棒。
Debian选择systemd(虽然这不是新决定)是我将Proxmox切换到FreeBSD/bhyve的原因(顺便说一句，FreeBSD对ZFS支持很棒)。
一旦我将hypervisor系统改为无systemd环境(FreeBSD上不使用systemd)，我就可以在虚拟机中安装一个用于容器化的最小化发行版(比如针对K8s的Talos Linux发行版，它只包含少数几个可执行文件且均为不可变文件)，然后运行那些设计上明确不使用systemd作为PID1的容器。
所以生活很美好：隧道尽头有一个没有 systemd 的世界。
> Debian 选择 systemd(这并不是一个新决定)是我将 Proxmox 切换到 FreeBSD/bhyve 的原因
你考虑过 Devuan 吗？还是说这只是以解决一个烦人的问题为借口，同时解决其他问题？
找到 x86-64 的 .torrent 链接有点困难，所以它们是
精简版：https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/deb…
完整版本：https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/de…
请注意，您可能不需要 DVD(“完整”)镜像。大多数用户应使用“最小”网络安装 CD，并在安装时下载包。
我下载了两个版本，因为我打算分享种子，但确实，如果您拥有快速的互联网连接，那么“最小”版本是完美的… 但如果你在第三世界国家使用糟糕的网络连接，下载镜像可能需要一整天时间，那么在准备安装时拥有完整镜像会更方便。
同意，但对于笔记本电脑来说，将DVD镜像保存在磁盘并添加到apt源中，以便离线安装软件会更方便。
每次想下载Debian时，我都要到处寻找这些文件，这让我感到困惑。这种情况至少已经持续了十多年。
这些文件链接在主页链接的“其他下载”页面上。
是的，我记得有过这种情况，但每次都会感到困惑，不确定具体原因。感觉他们是故意隐藏的。而Arch则相反，获取种子文件非常容易。
是的，这是故意设计的，为了让大多数用户更容易获取netinst下载。
对我来说最大的变化是/tmp的行为。在Debian 13中，/tmp默认成为RAM磁盘(而不是文件系统中的文件)，并使用多达50%的可用内存。但正如预期，Debian的发布说明中包含了一个简单的修复方法，以恢复/tmp的正常行为，适用于那些在/tmp中放置大量小文件或大文件的人和应用程序。
https://www.debian.org/releases/trixie/release-notes/issues….
>“您可以通过以 root 身份运行 systemctl mask tmp.mount 并重启系统，使 /tmp 恢复为普通目录。”
我希望各发行版能为应用程序提供一个新的 /tmpfs(或 /tmp/tmpfs 等)目录，让应用程序可以选择使用内存盘，而不是替换 /tmp 并需要手动退出。
这个问题在 debian-devel 邮件列表中讨论过很多次。首先，tmpfs 本身占用空间不大，而 /tmp 目录多年来已不再被期望具有持久性。
/tmp 目录的问题在于，许多用户和应用程序将其用作跨用户通信媒介，并期望在此处具有持久性，这导致了安全问题并浪费了磁盘空间。
由于大多数打包应用并未以这种方式使用 /tmp，而是按照其应有的方式使用该目录，因此进行了此次更改。
我在其中一台系统上运行 Debian 测试版，此次更改并未产生任何负面影响。甚至可以认为节省 SSD 写入周期是一大优势。
然而，如我在相关讨论中提到的，这种方法在某些场景下可能存在一些缺点。
如果你有时间和兴趣，讨论从 https://lists.debian.org/debian-devel/2024/05/msg00014.html 开始
终端的无限滚动长度可能会耗尽/tmp目录，而当/tmp目录空间不足时，系统可能会出现异常行为。
哪些终端模拟器默认启用无限滚动功能？我对此感到好奇。我已经使用xterm终端并设置512行滚动缓冲区长达三十年，除了大型构建任务外，我无法想象需要更大的滚动缓冲区。
还需注意/tmp和/var/tmp目录在10天和30天后自动删除文件的情况。
此功能也可关闭。
这不是/tmp的特性吗？我将Firefox的默认下载位置设置为/tmp，正是为了这个原因，这样所有垃圾文件会在一段时间后自动删除。此外，每次需要临时Python脚本或测试包时，我都会在/tmp下创建一个venv。
开机时执行一直是标准做法，至今仍最常见。我个人对现在 Debian 和部分发行版通过各种自动化方式在特定时间间隔执行此操作感到惊讶。
这是 systemd 的功能，参见 `man systemd-tmpfiles`。
此前该功能已作为选项提供：https://manpages.ubuntu.com/manpages/xenial/man5/rcS.5.html
我认为superkuh的观点是，这并非systemd相关。清理/tmp目录(删除旧文件)的功能早在systemd出现之前就已存在，甚至在Linux诞生之前就已存在。
是的，但在Debian中，这并非默认设置，直到现在才成为默认。
以前，/tmp会在重启时被清空，而/var/tmp不会。
两者在其他情况下也不会被清理。
因此，对于Debian来说，这是systemd相关的问题。而且这是由一位systemd维护者推动的，他同时也是Debian开发者。
我对Debian“与其他发行版保持一致”毫无兴趣，因为其他发行版应该与Debian保持一致。
在仅存在 Debian 和其他 Linux 发行版的封闭世界之外，这并非 systemd 对可怜的 Debian 做了坏事。从更广阔的世界来看，是 Debian 和其他 Linux 发行版正在以极慢的速度重新发明 Unix 中的事物。
AIX 早在 1.2 版本时就已拥有 /usr/sbin/skulker。
对于AT&T System 5，Fielder和Hunter推广了一款名为rmtrash的类似工具，该工具每天夜间运行。
Fielder和Hunter在其1986年关于Unix系统管理的书籍中体现了传统的Unix思维，该书包含rmtrash：
> 通过将所有临时文件放在一个或两个目录中，可以轻松地在固定时间间隔内清理所有文件。因此，鼓励用户将仅需短暂使用的文件存放在/tmp目录中是个好主意。
skulker并未收录于旧版的comp.unix.aix Usenet FAQ文档中，但鉴于多年来“这就是skulker的功能，你应该每天运行它”这一回答出现的频率，它本应被收录。(-:
对老手来说，这根本不是 systemd 的新功能。对老手来说，新功能是不用脚本实现这一点。我记得 20 世纪 90 年代和 21 世纪初的那些“战争故事”，当时用户会在临时文件名称中包含 LF，而管理员突然意识到 find -print0 和 xargs -0 或 find -exec rm {} + 的实用性。Stéphane Chazelas 多年来对此话题有过很多论述。
不过，mtree(1989年推出)在systemd-tmpfiles发明时已经存在，并且已经具备从规范文件中获取文件名、所有者、权限等信息的理念。令人惊讶的是，似乎没有人尝试过使用 mtree 来完全清除 /tmp 目录。BSD 系统至今仍在多个自动删除 /tmp 文件的位置使用 find 命令，包括每日定时任务，尽管他们早在 1999 年就发现自己的 find 命令拥有 -delete 选项。(-: 甚至我至今仍在使用 find。)
https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/pe…
我无法理解为什么有人会对一个名为“tmp”的目录是临时性的感到惊讶。
这可能是因为使用Linux超过20年，其中标准做法是仅在启动时删除该目录中的文件。在此情况下，“temp”意味着它是该启动过程中的临时文件。最近的重新定义令人惊讶，除非你最近才接触 Linux，或者来自 40 年前的 Unix。
我假设你习惯了每隔十天清理一次 /tmp。想象一下，突然决定出于安全原因和最小化内存使用，清理操作需要每隔十秒钟进行一次。你认为这会影响你使用/tmp的工作流程吗？这与当前情况完全相同。是的，tmp是临时性的，但具体的时间尺度是多少？
不，我误解了我要回复的评论，以为他们假设可以将/tmp作为一个从未被删除的无管理存储区。
我也习惯了系统在启动时自动清除数据。
那我认为你缺乏想象力。我曾在关闭机器后，通过单用户模式重新启动系统，并在启动过程中数据被清除前访问了/tmp目录中的文件。考虑到“关闭机器”也可能意味着“机器断电”，我完全理解人们对这一变化感到惊讶的原因。
“trixie”官方支持的架构总共有七种：
看到 RISC-V 成为主流架构令人欣慰，尽管目前使用该架构的硬件仍较为匮乏。
我很好奇，如今PowerPC和IBM System z被应用在哪些领域？是否存在部署了除amd64、arm64(以及即将推出的)riscv64之外的现代Linux系统？
大型机仍在那些需要单台服务器持续运行且不得中断的场景中发挥作用。它们的设计使用寿命以十年为单位，因此即使是处理器和主内存等组件也配备了热备件，可在不中断操作系统或运行服务的情况下进行热插拔。它们还具备在硬件层面持续运行的系统监控和诊断功能(而非作为操作系统服务运行)，一旦检测到硬件故障，将同时向所有者和IBM发出警报。IBM 自 21 世纪初便将 Linux 作为大型机的一流操作系统选项提供支持。
从开发者角度来看，s390x 也是目前唯一活跃的大端字节序架构(我想还有 SPARC，但该架构已处于生命维持状态，而 Oracle 并不关心任何人在其上运行除 Solaris 以外的系统)，因此对于排查字节序相关 bug 具有实用价值。
另一个有趣的点是，目前仅剩的两个受支持的 32 位架构是 armel 和 armhf。Debian 已宣布这是最后一个支持 armel 的版本(https://www.debian.org/releases/trixie/release-notes/issues….)，因此我猜他们很快就会完全放弃对 32 位架构的支持。
是的，大型机主要应用于对系统可用性要求极高的场景。大多数现代系统都能提供99.9%或99.99%的可靠性，因为试图提供更高的可靠性会导致成本不断攀升。不过，投入巨额资金采购大型机正是实现99.9999999%可靠性目标的策略之一。
来源：https://itic-corp.com/itic-2023-reliability-survey-ibm-z-res…
合法用途通常是针对关系型数据库(本身就是单机架构)等工作负载，这些系统需要24/7高负载运行，属于无法容忍停机的脆弱架构(因原始源代码丢失等原因仍保持脆弱状态)，其中“系统停机”会导致数万甚至数十万人无法工作。
Power和z都是价值数十亿美元的业务。银行业和其他高金融领域是两者的主要市场。IBM似乎仍对z感到自豪，而Power如今似乎只是被容忍，这令人遗憾，因为它是一个不错的指令集架构(ISA)，系统也非常出色。
IBM投入大量人力物力确保开源软件在这些平台上正常运行，尽管它们并不流行
因此，这些架构被主流发行版支持并非像其他架构那样“自然”
对于Debian s390x(IBM Z)，他们仅安排两人负责移植工作，这显然不够。我认为ppc64el的人手可能更少。
> 我不禁好奇，如今PowerPC和IBM System z主要应用于哪些领域？
IBM。
他们拥有红帽，所以我猜他们投入了大量时间和资金来确保内核正常工作。
为什么是Debian，我不确定。
需要特别注意的是缺乏x86(32位x86)支持。
一个时代的终结。
我从Slink时代就开始使用Debian。我仍然输入“apt-get …”，它仍然运行得相当不错。在过去25多年里，升级过程中确实出现过一些问题，但与我同一时期接触的其他Linux和非开源系统相比，处理这些问题的所需时间和精力几乎可以忽略不计。我唯一的遗憾是没有为社区贡献更多。
我最喜欢Debian的一点是，使用它需要对系统运作有一定的了解。对我来说，它很好地遵循了“尽可能简单，但不简单到极致”的原则。
哪个版本是slink？
我的第一次 Debian 安装是在 1996 年。当时我对自己在做什么并没有真正的概念，但能够从校园内的其他机器远程显示窗口对我来说非常神奇，这与我当时习惯使用的 Windows 3.x/95 系统相比显得非常陌生。当时还没有 apt，或者说我当时并不知道有这样的工具，添加新软件的过程非常痛苦。
大约在2005年，我开始优先使用Debian作为我的工作站/桌面操作系统，并将其安装在嵌入式系统(Linksys NSLU2)上以构建微型服务器，我记得那时候是Etch版本。
到2008年，我加入了IBM，他们允许在笔记本电脑上选择Windows或Red Hat，如果你敢于尝试，还有对Ubuntu的实验性支持，它可能在Debian上运行。我成功让它运行起来，并发现在这33万人中，只有22人正在使用它！
我一直都很喜欢它，它总比其他发行版更有道理。现在我的日常设备是Mac，但我仍然保留了几台Debian机器。
作为两台i386系统(均为基于英特尔Atom N270处理器的上网本)的拥有者，我感到有些遗憾。我理解其中的原因，也不否认i386平台如今已非常小众。但我曾希望Debian能延续其支持多种平台的传统，让i386再坚持一段时间。
幸运的是，bookworm将持续获得更新近3年，因此我无需急于为这些“古董”寻找新操作系统。OpenBSD似乎是自然的接班者，但我不确定其Wi-Fi芯片是否受支持。(谁知道这些上网本还能运行多久，它们分别于2008年和2009年生产，已经服役多年了。)
EDIT：太棒了，感谢所有让这成为可能的人，这就是我想说的。
OpenBSD运行得非常完美。Atom上网本，n270，1GB内存，cwm+git dillo(加上DPI插件)，mpv+yt-dlp。
我的~/.config/mpv/config：
我的 ~/yt-dlp.conf
对于其余部分，我使用虚拟环境中的 streamlink(我对 yt-dlp 也做同样的处理)，并在 $HOME/bin 目录下有一个包装脚本：
yt-dlp 包装脚本
streamlink 包装脚本
安装 streamlink
与 yt-dlp 相同：
其余部分，我使用mutt+msmtp+mbsync、slrn、sfeed、lynx/links、mocp、mupdf(用于PDF/CBZ/EPUB)、nsxiv(用于图像)、tut(用于Mastodon)以及Emacs(仅用于Telegram，我从OpenBSD包中安装了tdlib，然后从MELPA安装了Telega)。
整体来说这是一台非常快的机器。CWM+XTerm+Tmux 是我的主要工作环境。我通过 SSH 连接到第三个标签(虚拟桌面)的某个位置，第二个标签用于 Dillo。
非常感谢！
Alpine支持i686架构，目前没有废弃计划。不过未来三年内可能会有变化，谁知道呢。
出于好奇，你用这些上网本做什么？
其中一台放在浴室里，这样我可以在，嗯，忙的时候浏览一些随机的维基百科文章。另一台放在床头柜上，晚上睡觉时播放有声读物/播客。
所以没什么重要的用途。但它们仍然擅长这些事情，而且体积非常小，使得它们非常适合这些使用场景。
好奇，为什么不直接用手机来完成这两个用途？这样似乎会更方便
我确实用手机听Audible，但这两个用途都是在我拥有智能手机之前就开始的(我入坑很晚)，而且我是一个习惯成自然的人。此外，上网本有更大的屏幕、更多的存储空间和真正的键盘(同样，习惯使然)。
我无法代表其他发帖者发言，但我非常喜欢这个想法。拥有专用的工具意味着我可以避免用手机处理所有事情。无论我玩什么游戏来屏蔽通知/干扰等，它总是会分散注意力，让我容易偏离最初使用手机的用途。
antiX将基于Trixie创建一个32位ISO镜像。还有Void、Alpine和Slackware(至少)。
对于担心systemd带来的网络接口控制器(NIC)变更的用户，以下内容摘自发布文档：
https://www.debian.org/releases/trixie/release-notes/issues….
以下是一行命令，排除 bond 接口和 lo。会列出更改前后的详细信息。
文档的逻辑是，在升级到 trixie 之后，但在重启之前，系统已经运行了足够的 systemd 来查看重启后接口将被命名为什么。
到目前为止，我还没有遇到过由于升级而导致接口名称变化的情况，因此无法确定上述方法是否能检测到这种变化。
希望这是最后一个破坏性更改。
enoX 应该始终保持稳定，因为它是 BIOS(在某些 ACPI 表中)告知该设备/端口具有此 ID。
ensX表示PCIe插槽X中的网卡，但在你的PCIe树中可能存在PCIe桥接器，因此从技术上讲，同一个插槽(BIOS声明的插槽)中可能存在多个网卡。因此，多年来systemd在网卡命名方面进行了大量破坏性更改，以确定安全的启发式规则，在存在PCIe桥接器时启用/禁用插槽命名，但仅在某些情况下。
此外，由于历史原因，PCIe插槽编号是间接读取的，这在某些情况下会导致冲突(此问题已在 systemd 257 中修复)
>希望这是最后一次破坏性更改。
每年都要应对 systemd。
您是否知道此更改是否会影响在升级到 Trixie 之前已禁用 systemd 的 Predictable* 网络接口名称的用户？
*哈哈
您可以通过 ‘net.naming_scheme=’ 参数轻松保留当前的命名行为
我已经有使用 net.ifnames=0 的系统。我的问题是，这种新行为是否会影响它们。
不会，新行为只是新的命名方案，你可以选择不使用任何方案，如果只有一个网卡，这样做完全没问题。
Debian 的标志性功能(从稳定版升级到稳定版不到 15 分钟)在这里也表现出色。
我的第一个系统在不到 10 分钟内完成迁移，包括包下载和重启。它也不是什么高性能机器。一台连接到约 50Mbps 网络的 N100 迷你电脑。
当滚动发布发行版普遍存在时，这真的算是标志性功能吗？
是的，尤其是在基础设施和生产环境中使用 Debian 时。我早上边喝茶边升级了三台服务器，没人注意到任何异常。
对于 RedHat 家族，这几乎不可能实现，需要数小时的规划、停机时间等，即使如此，也无法保证成功。
如果你偏好滚动发布，且_不会在服务器上使用_，Debian Testing 就能满足需求(除非你在安全敏感环境中)。我的系统与外部环境隔离良好，因此桌面系统可以无障碍运行 Testing。
服务器和暴露在外的系统始终运行稳定版本，并自动安装安全更新。
这个过程是怎样的？是否需要手动修改sources.list文件，还是有一个单一的命令来触发升级？
有两种主要方法：
如果您的 sources 文件引用了发行版名称(例如：bookworm)，您需要将其修改为 trixie，然后执行“apt update && apt dist-upgrade”。
或者，
如果您的 sources 文件直接引用了发行版套件(例如：stable)，您只需执行“apt update && apt dist-upgrade”，因为 stable 现在指向 trixie。
在第一次重启时，运行“apt autopurge”以移除不再需要的包。
…就这样完成了。
我一直使用 Debian 并且非常喜欢它。但他们以一种只能用“疯狂”来形容的方式，对 Python 的 pip3 进行了补丁修复，导致 –prefix 选项失效。在 Debian 上
会安装到 /usr/local/local，因此必须使用 /usr 作为前缀。而在 OpenSuSE 等系统上，同一命令会安装到 /usr，导致系统崩溃。简直疯了。
https://sources.debian.org/src/python3.7/3.7.3-2+deb10u3/deb…
> python3.7
这确实是一个糟糕的用户体验，但动机很明确：他们试图为旧版本提供 PEP 668 保护。
虚拟环境确实要好得多，说实话。(通过精心配置的
pyvenv.cfg，应该可以让 Python 认为你的 /usr/local 是虚拟环境，但我无法确定这样做是否会带来任何严重的负面影响。)python3.7 发布于 2018 年 6 月 27 日
https://www.python.org/downloads/release/python-370/
为什么这是默认设置？
我认为不是？或者至少，它只在某些特定的旧版 Debian 发行版中存在。
我认为那是补丁引入的版本，它确实存在于 Trixie(使用 3.13 版本)中。
哦。如果它仍然存在，我想没有人给他们任何动力去重新审视它…
这个帖子中充满了对Debian的热爱，这真是令人欣慰。如果你愿意，我鼓励你向Debian捐款。我们所有人都将受益于对Debian这样一个生态系统和运营的支持。
https://www.debian.org/donations
与Debian无关，只是一个长期满意的用户。
个人、公司和其他组织还有许多其他方式可以提供帮助：
https://www.debian.org/intro/help
我已经使用 Debian Trixie 进行测试几个月了，我可以证明这是一个伟大且稳定的操作系统。在用户体验方面，它绝对优于 Ubuntu。
在全新安装时唯一的抱怨是，当屏幕上任何位置有小动画(例如浏览器标签栏中带有加载图标的标签)时，Cinnamon似乎会占用大量CPU资源。这种情况在没有图形加速的虚拟机中尤为明显(别问我为什么工作需要这样)。没有图形加速的系统本就耗资源，但这里还有一个额外进程在实际负载上运行。
然后，我的私人笔记本在升级到 13 之后出现了很多图形问题(在很多应用程序中表现不同，而且当你选择不同的桌面主题时会改变，我甚至不知道如何描述它)。新的 Pipewire(PulseAudio 的替代品，我不知道为什么需要替换它)在 CPU 忙碌时无法正常工作(所以我目前玩游戏时没有游戏声音或背景音乐)。后者在从休眠状态恢复时，有时(大概每五次一次？)会崩溃，但不会直接终止，而是不断向 systemd 发送请求，系统会将所有信息存储在一个糟糕的二进制文件中(无法选择性删除)，最终导致磁盘空间耗尽，并破坏系统其他部分的功能，直到重新启动 pipewire 进程并清除所有日志(记住，无法选择性删除)… 我尝试了在网上搜索到的各种方法，还尝试了大语言模型(LLM)，但都没有用。我猜这些问题是因为这不是新安装的系统，所以这里真的没有责怪/抱怨，只是令人讨厌，而且我在之前的升级中没有遇到过这些问题。尚不确定如何解决，也许我最终会重新安装系统，看看在问题出现之前我可以移植哪些配置。
这些问题显然不是Debian特有的，但我之前在11或12版本中并未遇到类似情况
编辑：哦对了，目前/tmp文件系统的计数器显示为1。我好奇在Debian 14中，我会因为忘记无法随意将临时文件写入/tmp(未提前估算大小)而导致内存不足的次数
我最近在我的 Ubuntu 机器上测试 Cinnamon。我几乎决定从 Gnome 切换，但每次在 Blender 中运行长时间任务时都会遇到问题。
在 Gnome 中，Blender 会变得无响应，但其他一切仍可正常使用。在 Cinnamon 中，整个系统都会变得无响应。
> “trixie”包含大量更新的软件包(占上一版本所有软件包的63%以上)
哇，我惊讶地发现三分之一的软件包在过去_检查_
> 经过2年1个月30天的开发，Debian项目自豪地推出其新稳定版本
我本人也喜欢老软件，因为看到 F-Droid 中有一个(通常很小的)包已经超过 10 年历史，但它能完美实现我的需求且无 bug，并在 Android 10 上运行良好。我好奇这 30% 的包是否更多属于“现状已足够好”类别，还是“无维护者可用”类别
> 运行 i386 系统的用户不应升级到 trixie。相反，Debian 建议在可能的情况下重新安装为 amd64，或淘汰硬件。
我所做的就是切换到 NetBSD。
从理论上讲，我非常支持永远支持旧机器，但出于好奇，我想问一下——如今还有哪些硬件既实用又只配备32位处理器？
我这里有几台旧式台式电脑(塔式机箱)，大部分基于奔腾4处理器，不支持AMD64架构。
这些电脑都配备了DVD光驱，非常适合刻录CD。尽管这些光驱已接近20年机龄(电脑生产于约2005年)，但其性能仍优于大多数“新款”外置光驱。当然，也可以将这些光驱移至较新的电脑上，但其中许多光驱使用的是IDE接口，而现代系统中已很少见到这种接口。此外，现代机箱通常不支持(多个)5.25英寸光驱。
另一个使用场景是编程微控制器。在进行电子设备调试时，总存在短路或其他错误导致连接的电脑主板损坏的风险。我更倾向于将自制电子设备连接到旧电脑而非我的AMD64工作站。
由于这些机器的年龄，我认为它们可能不会再使用太久——我担心甚至不到10年，我的一些旧32位笔记本电脑已经故障。因此，即使对我来说，尝试继续提供软件支持也没有意义。也许如果它们能使用足够长的时间，我会将它们切换到BSD或其他Linux发行版，但目前这些机器在Debian Bookworm(新旧稳定版)上运行良好。
我尝试将一台闲置的旧笔记本电脑改造成“躺在沙发上浏览网页或观看YouTube”的设备。该机器搭载了最后一批仅支持32位的处理器(Pentium M)，因此我为其安装了Debian Bookworm(12)。不幸的是，它甚至无法流畅播放144p的YouTube视频。于是，我将这台机器进行了电子废弃处理。
我想，作为某种无头家庭服务器，它可能仍然有用。另一方面，对于需要24/7运行的设备，树莓派(RPi)的功耗仅为其一小部分，且性能要强大得多。
因此，除了怀旧和一些嵌入式/工业应用场景外，如今很难找到32位专用PC的实际用途。
我的情况下，我有一台第一代32位Atom上网本，我仍然定期使用它来做我一直以来使用它做的事情。硬件仍然工作正常，所以我看不到更换它的理由。
最近几个版本中，Debian与Ubuntu之间的差异正在缩小。令我惊喜的是，Debian在我的笔记本电脑上原生识别了所有硬件组件，而这台电脑是去年发布的。
硬件支持良好，界面也非常出色！相比Ubuntu，它运行起来更流畅，可能是因为默认安装的Snap包和系统服务较少。
我刚刚升级了一台迷你电脑，没有遇到任何问题。主要步骤如下：
我热爱Debian，并对参与该项目的人员充满敬意。虽然我不再使用Debian，但我认为拥有一个不依赖于营利性实体、真正由社区驱动的锚定Linux发行版至关重要。
Arch 不是真正由社区驱动的吗？
> Trixie 的总磁盘使用量为 403,854,660 kB(403 GB)
这意味着什么？如果安装了所有 69,000 多个包，它将占用这么多空间？
由于这也列出了代码行数，听起来更像是源代码加上包。想想一个完整镜像(src + generic + 架构特定包)所需的空间。
确实，这是 Debian 镜像托管所有 Trixie 包所需的空间大小。这是压缩包的总大小，而非同时安装所有包所需的空间(这实际上也不可能实现，因为存在包冲突/替代方案，且 Debian 支持 7 种以上不同架构)。
403GB 的数字代表 Debian 存档中所有源包的总大小，而非典型安装所需的磁盘空间(通常桌面系统安装空间不足 10GB)。
看到他们停止对 32 位系统的支持，我感到非常遗憾，因为我过去 10 年一直在这台电脑上使用 Debian…
有没有人能推荐一个仍在更新的 32 位发行版？
Linux Mint 技术上仍然支持，可能是因为他们落后于 Debian。AntiX 支持，但它有自己的权衡。充分尊重你的情况，如果你无法获得 64 位硬件，现在不升级操作系统也没什么问题
如果我正确理解了Debian维基，Bookworm还将获得一年的更新，因此或许无需立即采取行动，因为Bookworm即将成为旧稳定版本？
除了Mint和AntiX，还有Slackware(我使用Xfce而非KDE)，但安装基础系统之外的软件并非通过'apt-get'流程进行。
Salix Linux 基于 Slackware，确实拥有包含合理应用程序选择的软件包仓库。Salix 基于稳定的 Slackware 15.0，因此其软件包经过了良好的优化和维护。
Void Linux 还提供了一个基于 Xfce4 的 live i686 ISO 镜像，您可以查看并决定是否安装。
我也使用 Xfce，我的电脑是 Acer Aspire One，性能有限……嗯，几乎所有方面都有限制。我升级了存储设备到 SSD，但它仍然搭载 Atom 处理器，所以越轻量级越好。
Gentoo 仍然支持它，但根据你的需求，使用现代编译器在旧硬件上编译的时间会很痛苦。
我已经将所有服务器和笔记本电脑升级到 Debian 13。
幸运的 13，一切顺利……到目前为止没有出现任何问题。非常开心！
感谢 Debian 团队发布了又一个高质量、可靠的版本 🙂
如果你正在升级，请查看 https://www.debian.org/releases/trixie/release-notes/upgradi…。
期待 13 版本！Debian 12 搭配 Pipewire 是我过去两年日常使用的专业音频工作站。从 Windows 迁移后，不再有强制更新阻碍我的工作。这真是解脱。它运行得如此出色！Linux 如今已成为专业音频领域的可行选择！大多数高端转换器本就通过 MADI 或 ADAT 连接，因此不存在驱动问题。驱动问题只是消费级讨论的范畴。
我已经使用 Debian 13 一段时间了(我使用的是 Unstable 版本)，对我来说，令人印象深刻的是，如今默认的 Debian 安装有多么完善。使用 Gnome，你几乎可以直接运行，无需任何配置。它就是这么好用。
不过，我喜欢Flatpak，所以安装了它(非常简单，Flathub还提供了安装指南)，并添加了几个Gnome Shell扩展(一个Dock，这样我妻子偶尔使用我的笔记本电脑时能找到应用程序)。
Debian让你有一种对电脑的掌控感，这是企业版发行版所不具备的，但它仍然相当用户友好(不像Arch)。
我一定会为祖父母的电脑安装 Debian 稳定版。
我曾经喜欢 Debian，因为配置 ALSA/OSS、XFree86 等是一场噩梦。因此，debconf 作为一个中间层机制，用于处理多种不同的架构、设置和硬件，是必要的。SuSE上的Yast2也是如此。到了2004-2005年……没什么特别的。
即使是安装了KDE和KDEi(甚至XFCE)的裸Slackware，只需添加用户并接受默认组成员数组(在提示符下按'up'键)，就能独立完成大量工作。
更不用说 OpenBSD 了，除了自动挂载卷外，这可以通过 toadd 或 tray-app 在几秒钟内轻松处理；如果你足够聪明，可以弄清楚 DBUS/FDo 挂载点，并将其与 XFCE/Plasma/Gnome 集成，而不会遇到太多问题(如果正确配置 doas.conf，hotplugd 可以处理设备卸载)。
其余部分？MESA和X.org将处理大部分图形相关任务。视频和音频驱动程序在几乎所有GNU和*BSD系统上都能自动检测。打印机通常支持无线连接，因此任何助手都能快速查找并将其连接到CUPS。
然而，我无法忍受DPKG/APT的缓慢速度，即使像Trisquel这样的自由发行版也存在这个问题。如果他们将发行版重新基于更简单的 Parabola LTS 版本，并采用 Mate 或 LXDE 桌面环境，用户体验几乎相同，但安装包的速度会快得多。
Debian 中的 dpkg/apt 甚至比 Ubuntu 中的 dpkg/apt 更慢，不确定原因。
可能是个小众问题，但 SDL2 仍在 Trixie 中存在。SDL2-compat 层(将 SDL2 API 转换为 SDL3)处于测试阶段，SDL2 与之并存，旨在用于测试和验证使用 SDL2-compat 的 SDL2 应用程序是否真正兼容。
与 Fedora 和 Arch 的决策过程形成鲜明对比，这两者都用 sdl2-compat 替换了 SDL2，导致大量 SDL2 应用程序无法运行，因为 sdl2-compat 实际上尚未与 SDL2 完全兼容，这让 everyone 纷纷向 SDL 团队投诉。
Fedora 相当于 Red Hat 的测试分支，而 Arch 就是 Arch。
即使Arch也在仓库中保留了SDL2库作为备用。Fedora则直接从仓库中的SDL2跳转到sdl2-compat或完全不支持。要在F42上获得一致的SDL2构建，唯一方法是从源代码构建SDL2。
Debian 13 Trixie 包含大量更新的软件包(与上一版本相比，超过 63% 的软件包已更新)
我不熟悉他们使用的指标定义，但如果在两个版本发布之间的约两年时间里，他们包含在 bookworm 中的包有近 100% 没有更新，我就会担心。
我使用 Debian 作为大多数服务器的系统，所以我确信那句话有合理的解释。
我不知道你为什么认为会有所不同。你担心安全更新吗？就我所知，这并不在评估指标范围内。
即使是这样呢？
如果你看看Debian中的软件包数量，只有一小部分存在CVE漏洞。目前有近3万个软件包源，生成约6万个二进制软件包。
然而我们每周只收到少量安全更新。
另一个例子？Trixie和Bookworm都使用相同的Firefox ESR(扩展发布)版本。当Firefox强制所有人升级到下一个ESR版本时，两者都会得到更新。
除此之外，有些包是文档。有些是“粘合”包，例如用于管理Debian的脚本。这些包在不同版本之间可能不会改变。
最后，Debian实际上维护了大量上游弃用的包。在这些情况下，版本号可能相同(有时)，但会根据需要添加安全更新。
从我的角度来看，除了及时快速的安全更新外，我对大量更新毫无兴趣。为什么我要这样做？更新意味着工作。更新意味着稳定性变化。
我们已经从内核、驱动程序相关更改(如X、Wayland、音频/网卡等)以及桌面应用程序中获得了足够的乐趣和更新。当然，还有任何向前发展的内容，比如网络连接的乐趣。
> 如果他们包含在Bookworm中的包在两个版本发布之间的约两年时间里几乎没有更新，我会感到担忧。
代码不会“变质”，也不是所有内容都会受到生态系统更新和 CVE 的影响。
一个已建立的包在 2 年内没有更新本身并不成问题。
小型软件包在数年间不更新的情况并不少见——要么是因为它们是功能完整的简单工具，很少需要修复漏洞，要么是因为它们是数据文件(如图标或字体包)，可能根本不需要更改。
Debian稳定版就是这样——在主要Debian版本之间保持不变。不过他们会在必要时推送安全更新，因此你不会错过这些更新
你知道他们是如何做到这一点的吗？显然，仓库中的每个包都不会在整个两年周期内得到支持，因此如果在重大重构后出现漏洞，要回溯应用补丁肯定不容易。
他们会自动将 CVE 数据导入安全跟踪器，向 Debian 维护者提交 bug 报告以修复问题，整理跟踪数据，与上游项目和其他发行版协调以获取修复方案等。更多详情请参阅团队网页。
https://security-tracker.debian.org/ https://security-team.debian.org/
这里有一些他们发布的信息：https://www.debian.org/security/faq
确实，要跟上所有这些工作量一定非常巨大
如果上游在该时间段内没有发布新版本，那么就不会有升级。
Plasma 6.3 – 我终于可以放弃KDE Neon了。
如果你想继续使用新版本的Plasma，那么Debian可能会落后几个小版本。
不过，我发现使用从源代码构建的 KDE 组件叠加在标准 Debian 包上相当简单。使用 kdesrc-build 进行构建，然后将这些二进制文件链接到你的 ~/bin 目录，即可完成设置。如果你想重新构建一些关键组件(如 plasmashell 本身)，可能会遇到困难，但我一直使用本地构建的 Kate 和 Konsole 版本，没有遇到问题。
> 你可以预期 Debian 会落后几个小版本。
不过这并不一定永远如此。Bookworm 获得了 Plasma 的 minor 更新，所以我不会惊讶于 Trixie 也会如此。
Bookworm 在 Plasma 发布 bug 修复版本至 5.27.12 时仍停留在 Plasma 5.27.5。Debian可能从这些版本中挑选了少量补丁，但这意味着一个已经非常老旧的版本错过了大量 bug 修复。
即使在此时，Plasma 6.4 已发布近两个月，而 6.3 将不再获得任何更新。当其他人都在升级时，Debian 将继续停留在一个已不再受支持的版本上，至少再过两年或更长时间。
Debian 作为其本身是优秀的，但你最好希望不会遇到桌面环境的问题，因为这些问题将不会得到解决。
如果你愿意付出努力并承担破坏系统的风险，还是有其他选择的。
你可以选择不安装 QT 或 KDE 包，并从源代码编译你的桌面环境。这虽然是个大麻烦，但我已经这样做了好几年。一个额外的好处是你可以参与测试并直接与 KDE 开发者互动。
另一个选择是采用 FrankenUNIX 方式，将 neon 源添加到你的 apt 缓存中。我做过类似的事情，但不推荐这样做。
或者你可以直接使用不稳定版本。很多人都是这么做的。我之前也用过很长时间，只要你愿意偶尔修复一下包管理系统，体验其实并不差。当然比前两个选项要好。
我非常乐意在Plasma 6.3上使用，而不是在不同版本之间切换，因为在某些版本中拖文件到浏览器可以正常工作，但下一次更新后就无法使用了。
我太急躁了，无法将像Debian这样的非滚动发布发行版作为我的主要操作系统，因为在我看来，它在发布新版本时已经包含了一些过时的包。不过我还是很欣赏Debian，它是我的最爱服务器操作系统。
测试版是滚动发布。不稳定版是更刺激的滚动发布。
向团队致敬。
我第一次接触Linux就是通过Debian 2.1。正是这个发行版的CD光盘https://archive.org/details/linux-actual-06-2/LinuxActual_01…
说实话，当时在主电脑上安装它是一段糟糕的经历，因为没有其他资源可以寻求帮助。由于缺乏当时流行的 ADSL 调制解调器的驱动程序，尝试使用它也非常困难。
但如今多年过去，我仍然热爱它 🙂
哦啦啦，GnuCash 5.10。我还在用4.4版本。
找不到发布说明，能帮忙吗？
我找到了文档，但内容太庞大。我需要具体查找4.4与5.10版本之间的差异列表。(至少是最大的差异)
也许标题应该注明它已经发布了？过去几个月关于Trixie的更新很多，为今天做准备。
我认为标题中的“realeased”一词被删除了。可能是HN自动标题编辑器搞砸了原标题。
我何时可以将我的树莓派5从Bookworm更新到Trixie？PiOS是否需要先发起更新？
树莓派操作系统是Debian的衍生版本，而非直接基于Debian。它尚未正式发布。目前存在一个测试版，看起来该版本将支持就地更新
镜像文件稍显过时，但可查看https://raspi.debian.net/
Debian 是我旧款“太空站”设备上唯一能正常运行的 Linux 系统。这确实令人怀念
我指的是 Debian 12，而不是旧版本，这要令人印象深刻得多
你是指 SparcStations 吗？
期待周末进行升级。
我的 RPi 自 Debian 9 以来一直运行 Debian，每次升级都非常顺利。
看来Trixie需要比之前版本更大的启动分区，因此我必须在三台家庭实验室机器上重新安装系统——可能还包括我的Proxmox机器。真是个头疼的问题。
这听起来令人担忧，尤其是Debian长期以来一直硬编码(！)了一个微小的/boot分区用于加密磁盘。这已经导致问题频繁发生(你不得不频繁手动删除它们，这会阻碍你在内核回归后恢复的能力——嗯，我注意到与往常相比，Debian 12 “Bookworm” 的内核回归相对常见……希望 Trixie 更好，但如果它让内核管理问题更复杂，那是个坏兆头)
我已在Resolve工作站上跟踪Trixie分支约两个月。唯一的问题是最新内核不支持ondemand调度器，因此我不得不构建自定义内核来解决此问题。
我已在本地服务器上使用Debian Trixie分支约一年，从未遇到过任何实际问题。非常令人印象深刻。
不错，不稳定分支又开始混乱了。我真诚地为发布和新稳定分支感到高兴，但同时也自私地高兴，因为现在不稳定分支又开始有了动静。
> Trixie的整体磁盘使用量为403,854,660 kB(403 GB)，由1,463,291,186行代码组成。
这使得Debian Trixie大约是Windows XP的32倍，后者大约有4500万行代码，可以说是最好的Windows操作系统。
Debian Trixie 发布于 Windows XP 之后约 24 年。
当然，但 XP 附带的捆绑软件极少，而 Debian 仓库中的每个包都包含在内。
> Windows XP 拥有约 4500 万行代码，堪称有史以来最好的 Windows 操作系统。
不，我认为是早期(或稍晚)的Windows 7，甚至可能是Vista。
> Trixie的总磁盘使用量为403,854,660千字节(403 GB)
这太大了。我需要一个更小的发行版。
你可能是在开玩笑，但如果不是的话，这是在安装所有包的情况下。
不，这是托管完整镜像的磁盘使用量，其他用户也提到了这一点
我敢肯定，与某些替代方案相比，它已经很小了。
你不太可能在其中安装所有内容。
祝贺Debian团队！
Devuan版本可能是GNOME能够运行的最后一个版本…
你说的好像这是件坏事。
我不喜欢GNOME的工程设计或许可证，但就用户界面和设计而言，我认为没有人能超越它(除了热角功能吧)。
嗯，截图看起来不错，但最终会浪费大量屏幕空间。
我想“高级用户”可以忍受“小按钮”界面，但我认为通用界面需要对不习惯随时使用鼠标和键盘的人来说易于使用。
2025年，能用鼠标和键盘就成了高级用户？
不
那你之前的评论是什么意思？
我的意思是，小按钮图形用户界面应该是一个选择，供那些愿意忍受它们的人使用，而不是被强行推广为通用使用。
这些用户不会使用Devuan或GNOME，而是使用Android/iOS。
他们可能不会主动选择Devuan或GNOME，但可能会因为管理员的选择而使用它们。
Io i
那么实际区别是什么？这些发布说明并不清楚。它们只是给出了版本更新。当你没有给人们值得兴奋的内容时，他们如何能感到兴奋？
我们什么时候能得到 Bandit 或 Bluey？
大概在 Debian 用完《玩具总动员》角色之前吧。
…而且既然《玩具总动员5》定于2026年上映，尚未使用的角色池很快就会再次扩大。
[删除]
此处的“争议”似乎是人为制造的，而火焰主要由这类评论员及其追随者煽动。这是带有机会主义色彩的心理战。此人是个职业煽动者。
这并非“关于Linux日益政治化的内容”，而是一个爱抱怨的反受害者MAGA油管博主在挑起争端。直接忽略它吧。
我最终确实找到了一些实际教程，但……说实话，这看起来有点令人望而生畏。我原本以为2025年的教程会更适合普通人。
[删除]
需要引用来源。我真的不知道你在指什么。即使我不得不接受你所说的“性掠夺者”这一说法，我仍然需要权衡他们多年来一直提供的稳定可靠的发行版。
我也不清楚他在说什么，所以做了一些调查。
一位为Canonical公司工作的Ubuntu开源贡献者在Debconf大会上发表演讲。他是一名已认罪并服刑的性犯罪者。这些信息都有详细记录。
但是……然后呢？他已经为自己的罪行服刑。他被列入了国家性犯罪者登记册。现在该怎么办？他应该被视为无法就业吗？他的开源项目贡献应该被拒绝吗？他应该无法就自己擅长的技术主题发表演讲吗？
要么我们认为服刑足以赎罪，要么我们必须努力改革监狱系统，使其达到这一标准。我不知道将某人终身排除在社会贡献之外是否是正确答案。
请注意，这是对那些(像我一样)对这里的情况一无所知的人的非常简要的总结。我不知道他的罪行程度超出了我上面所写的内容，也不知道他服刑的时间是否“看起来”合适(不是说任何一个值都能被所有人同时认为是合适的)。我的假设是：他已被定罪、服刑时间合理、已获释，且在释放后未再犯同类罪行(上述任何一点我都可能有误)。
我还看到过关于其在其他话题中表现粗鲁/对抗性的指控，但因这些内容未包含在GP的投诉中，故不予讨论。
他在被定罪的犯罪行为发生时还是未成年人。这是一个重要点，因为Lunduke的追随者总是到处宣扬，仿佛他是一个成年人，对儿童实施了“数千次”性侵。显然，更接近事实的是，他在开始对兄弟姐妹实施性虐待时自己还是未成年人，而父母对此视而不见。他后来作为成年人被定罪，并如前所述服完了刑期。
>他犯下罪行时也还是未成年人。
错误。别再为性侵者开脱：
他从11岁开始虐待儿童，并一直持续到青少年时期。
https://wng.org/articles/the-high-cost-of-negligence-1617309…
> >他在犯罪时还是未成年人。
> 错误。别为性犯罪者开脱：
A) 没人是在“为任何事开脱”，B) 好，期待你证明这是错误的。
什么，他驻扎海外难道能证明他犯案时年龄多大？不能。我们不知道他是当天被举报时犯案，还是多年之前。可能是多年之前……那时他还是未成年人。
> 他从11岁开始虐待儿童，并一直持续到青少年时期。
啊。所以现在你是在说，他实施犯罪行为时确实是未成年人，而不是“虚假”的。
你真的不擅长辩论，对吧？也许在你学会如何构建一个有条理的论点之前，最好不要在网上辩论。
> 他的开源项目贡献是否应被拒绝？
作为一个认为开源项目应由代码本身说话，而非贡献者身份(包括肤色、性取向等)的人……我认为只要代码质量足够好，他就应有权贡献代码。与其他代码贡献相同的规则。
但Debian项目已决定提拔他，并让他代表Debian参加DebConf等会议，这可能让一些人感到更难以接受。
即使他已服完刑期，那段污点依然存在，而Debian项目需要决定这段污点在多大程度上会影响到他们自身。
>即使他已经服完刑期，那里仍然存在某种污点
在西方法律体系中，社会对犯罪分子实施惩罚的依据是惩罚的正当性。其中一个特征是惩罚的适当性，即惩罚有其终点。服完刑期的犯罪分子不应像该隐一样背负污名或标记，他们有权重新融入社会，因为如果没有这一权利，惩罚的意义何在？
因此，雇佣一名已为其罪行付出代价的人并不反映任何软件项目的负面形象。如果雇主平等对待前罪犯，这反而反映了雇主的良好品格。
在不偏离主题太远的情况下，既然我们在讨论反思，或许可以考虑一下无限期惩罚派的优缺点。
就是那个人。可以说他已经服完刑期，不应被视为无法就业。我原则上同意这一点。我不会主张拒绝他的开源贡献。如果Canonical在尽职调查后决定雇佣他，那是他们的自由。但邀请他担任项目发言人和代表则过于冒进。难道没有更合适的人选吗？
如果你只是想安静地开发软件，那么没人会在乎你是什么样的人，但当你决定以政治活动家的身份行事并要求他人遵守你的个人道德标准时，你组织成员的个人道德就成了可以讨论的对象。
我认为这就是他所指的人。通过链接到此处，我并非在说这些指控是真实的，但这是我在其他地方看到的讨论，我认为原帖作者指的就是这个：
https://x.com/LundukeJournal/status/1944505084919816337
> 明天，7月14日，在年度Debian大会(DebConf ‘25)上，杰里米·比查(Jeremy Bicha)将发表演讲。
> 比查，正如我们上周所知(在他篡改了一个开源维基页面，称人们为“纳粹”之后)，是一名注册性犯罪者——因对幼童实施“数千次”性侵而被定罪。
> 作为 Canonical 公司(Ubuntu 的母公司)的员工，Bicha 将代表 Debian 和 GNOME 参加 DebConf 25。
编辑：深入挖掘 X 线程，这似乎是该指控的主要来源之一：
https://wng.org/articles/the-high-cost-of-negligence-1617309…
编辑2：为了澄清，我本人是Debian用户。并非仇视者。我只是不希望看到Debian的声誉因错误的人被提拔为公开代表项目而无端受损。
我并不对这些指控本身发表评论(这些指控可能属实)，但引用Lunduke时要小心——他在开源软件(OSS)界是个相当有名的点击诱饵式大号。
Jeremy Bicha
如果你能提供更多背景信息，你的评论可能会被更认真地对待。
我不敢相信我们已经达到了这么高的数字，而且还是一个特别幸运的数字
唉，它仍然不适合普通家庭用户作为日常使用，而且可能永远不会适合。遗憾的是，Ubuntu在这一点上必须占据主导地位。
不要喂养喷子，等等… 但我还是忍不住要回应这一点：
> 遗憾的是，它仍然不适合普通家庭用户作为日常使用系统，而且可能永远不会适合。遗憾的是，Ubuntu在这一方面不得不占据主导地位。
确实，Ubuntu曾经是Debian的开箱即用版本，“只需安装即可使用”，而基础Debian则需要一番折腾才能让Wi-Fi正常工作。
然而如今我发现情况恰恰相反：Ubuntu做了很多我不想要的奇怪设置，我不得不“折腾”才能禁用这些功能。而基础版Debian(带固件的ISO镜像)则直接就能用。
对我来说，Ubuntu已正式从我愿意花时间研究的发行版列表中剔除。
两名4至16岁的儿童和两名30至46岁的成年人已使用Debian作为日常系统近十年。其中至少三人属于“普通家庭用户”。虽然因学校和雇主要求不得不使用Windows，但在家中使用Debian始终更优，因其维护需求更低且无干扰。
你可以安装Debian和Ubuntu，使用相同的桌面环境(DE)，除了主题之外，你几乎找不到区别，除非你是知道什么是Snap的资深用户。
事实上，Ubuntu从未是一个特别用户友好的发行版。最初它只是一个使用Debian实验性安装程序安装的Debian系统，后来他们决定在稳定版本中使用它。仅此而已。
如果你想找到一个致力于为初学者提供图形配置工具的发行版，你必须看看SUSE和Mandrake(现为Mandriva)。
Ubuntu为初学者做的唯一具体事情是在互联网连接不普遍的时代，免费寄送光盘，因为当时人们会寻找附带光盘/DVD的纸质杂志。而他们很久以前就停止了这项服务。
>Ubuntu为新手做的唯一具体事情是免费寄送光盘
假设你并非恶意，我乐意帮你纠正记忆偏差：Ubuntu一直拥有非常优秀的专有驱动支持，这使得笔记本电脑能够正常运行并帮助新手入门。我还记得Ubuntu相较于Debian提供了图形化安装程序，这无疑对新手更友好。或许其他发行版也提供了简易安装方式并预装专有驱动，但我记不清有哪款基于Debian的发行版做过类似事情。
无论如何，你错了，光盘并不是让 Ubuntu 对新手有吸引力的唯一因素，每月都有附带光盘的 Linux 杂志，而且价格并不昂贵。我的第一台 Linux 系统是来自杂志的 Kubuntu 6.10，至今我仍在使用 Kubuntu，尽管过去我有时间尝试过不同的发行版，编译自定义内核等，包括 Debian、Sidux、Arch、Mandriva 和 SUSE。
图形化安装程序是Debian的新实验性安装程序。他们只是决定在Debian之前发布一个稳定的发行版。
专有驱动程序的安装是Linux Mint存在的唯一原因，而Linux Mint是Ubuntu的分支，所以你的记忆是错误的。
>专有驱动程序的安装是 Linux Mint 存在的唯一原因，而 Linux Mint 是 Ubuntu 的分支，所以你的记忆是错误的。
我认为你的记忆是错误的，你可能在想视频编解码器和可能的 Flash，而不是专有驱动程序，因为 Ubuntu 在 Mint 之前就已经支持轻松安装驱动程序。
或者除非你的硬盘容量有限，被巨大的 snap 包填满。
或者你需要一些被 snap 破坏的东西。我曾帮助一位用户在升级后，Thunderbird 无法再在 Okular 中打开 PDF 文件。结果发现 Thunderbird 的 dpkg 包已被 snap 包替换，我花了很多时间尝试让它正常工作，提交了错误报告等，最终放弃并从 Mozilla 安装，直到我用 Debian 替换了所有内容。
> 遗憾的是，它仍不适合普通家庭用户作为日常系统使用
我认为这对Debian来说没问题。甚至可能是件好事。
Debian为许多通用任务提供了坚如磐石的基础。Ubuntu和其他发行版可以将这些打包成用户友好的形式，但作为技术用户，我希望能够直接获取一个不带额外组件的基本Linux系统。
> 遗憾的是，它仍然不适合普通家庭用户作为日常使用系统，而且可能永远不会适合。
为什么不呢？
我的家人只需要一个网页浏览器、媒体播放器和办公套件。Debian 稳定版非常适合这里；可以说比其他发行版更适合，因为其他发行版通常需要更频繁的维护。
安装过程稍显简单(但由于使用 USB 安装仍具挑战性)，且官网设计更具吸引力。除了这些，对于普通用户而言，Ubuntu 还有哪些优势？自版本 12 起，默认安装程序已包含专有二进制文件。