跳过正文
  1. 网络/

Debian 11停止维护,Debian 14什么时候发布?

3 分钟·
x
作者
x
熟练掌握Spring Boot、Spring Cloud等Java技术栈,专注于分布式系统设计与微服务架构。热爱技术分享,探索编程之美。
目录

Debian 11(Bullseye)的官方支持已经在 2026 年 8 月 31 日正式终止,五年生命周期画上句号。如果你手里还有跑在 Debian 11 上的服务器(尤其是当路由器、跑代理服务的那些自建盒子),现在就该考虑升级了。顺带把大家常问的另一个问题也理一下:下一个大版本 Debian 14 到底什么时候能等到。

一、Debian 11 的生命周期是怎么结束的
#

Debian 的支持周期不是一次性截止,而是分阶段收紧的:

  • 常规支持(Regular Support):由 Debian 安全团队维护,覆盖发布后约 3 年,或到下一个稳定版发布后 1 年,以较晚者为准。Debian 11 发布于 2021 年 8 月 14 日,常规支持到 2024 年 8 月 14 日结束。
  • 长期支持(LTS):常规支持结束后,由 Debian LTS 团队接手,再维护 2 年。Debian 11 的 LTS 于 2026 年 8 月 31 日正式到期,这也是"11 不更新了"这句话的准确出处——从这天起,官方不再为 Debian 11 提供任何安全补丁。
  • 扩展长期支持(ELTS):如果因为某些历史包袱暂时走不开,Freexian 提供的商业 ELTS 服务会把部分核心包的支持再延长到 2031 年 6 月,但只覆盖部分架构和软件包子集,不能当成长期方案,更适合作为迁移前的缓冲期。

也就是说,从 2026 年 9 月开始,继续在生产环境跑 Debian 11 意味着裸奔——任何新出现的 CVE 都不会再有官方补丁。

二、还在用 Debian 11 该怎么办
#

优先级排序:

  1. 直接升级到 Debian 13(Trixie):这是目前的当前稳定版(2025 年 8 月发布),支持周期最长,值得一步到位,跳过中间的 Debian 12。
  2. 退而求其次升级到 Debian 12(Bookworm):如果软件兼容性上有顾虑,Bookworm 目前仍在常规支持期内,可以作为过渡,但迟早还要再跳一次。
  3. 实在来不及的,先上 ELTS 顶一阵:只是缓兵之计,不要当成长期方案。

升级前记得先看一遍官方 Release Notes 里的不兼容变更列表,尤其是网络配置(ifupdown vs netplan)、iptablesnftables 的迁移这类容易踩坑的地方——如果你是用 Debian 搭路由器或跑自建服务,这些恰恰是最容易在升级后翻车的部分。

三、Debian 14(Forky)现在到什么阶段了
#

先说结论:Debian 14 预计要到 2027 年年中(大致 6-8 月)才会发布,现在下手还早。

Debian 的发布节奏并不固定在某个日期,而是"冻结后功能稳定即发布",但近几个版本实际上都落在大约两年一个周期:Bookworm(12)2023 年 6 月,Trixie(13)2025 年 8 月,按这个间隔推算,Forky(14)落在 2027 年中是比较合理的预期。

目前的进展:

  • 代号已经确定为 Forky(取自《玩具总动员 4》里的角色 Forky,延续 Debian 用玩具总动员角色命名的传统)。
  • Forky 分支已经在 2025 年 8 月 Trixie 发布后作为 testing 分支开出来,处于日常滚动开发状态。
  • 截至目前还没有排定冻结(freeze)时间表——按 Debian 的惯例,正式冻结前至少会提前 14 天公告,真正进入冻结才算是进入发布倒计时的实质阶段。
  • 已经在讨论中的方向包括可复现构建(reproducible builds)覆盖范围扩大、LoongArch64 架构支持等,但这些都还在开发阶段,具体最终会不会进正式版存在变数。

简单说:Debian 14 目前连冻结日期都没有,2027 年中只是按历史节奏做的推算,不是官方承诺的日期,实际情况以 Debian 项目后续公告为准。

四、小结
#

  • Debian 11:2026 年 8 月 31 日 LTS 到期,之后已无官方安全更新,需要尽快升级到 12 或 13。
  • Debian 14:代号 Forky,预计 2027 年中发布,目前尚未进入冻结阶段,不用着急等它。

对于自建路由器、代理服务这类长期挂机跑的机器,建议直接规划好升级窗口,不要拖到最后一刻才动手。

相关文章

使用Debian作为路由器:完整配置指南

在企业环境或高级家庭网络中,使用Linux系统(特别是Debian)作为路由器可以提供更强大的功能、更高的灵活性和更好的性能。本文将详细介绍如何将Debian配置为功能完整的路由器,包括DHCP服务、DNS服务、NAT配置、IPv6中继、网桥设置等核心功能。

TLS非对称加密流程详解:从握手到对称加密通信

13 分钟
TLS(Transport Layer Security,传输层安全协议)是互联网上最广泛使用的安全协议之一,它为客户端和服务器之间的通信提供了加密、身份验证和数据完整性保护。本文将详细介绍TLS握手过程中客户端和服务端的具体操作,包括CA证书验证、密钥交换,直到最终生成AES对称加密密钥进行正常通信的完整流程。

部署基于artalk的评论系统

1 分钟
在现代博客和网站中,评论系统是与读者互动的重要工具。Artalk 是一个开源的评论系统,具有轻量级、易于集成和高度可定制的特点。本文将介绍如何在 Hugo 博客中部署基于 Artalk 的评论系统。

AI Agent Loop 与 ReAct 模式:思考-行动-观察是怎么循环起来的

7 分钟
现在几乎所有"AI Agent"框架——不管是 Claude Code、各种 Agent 编排工具,还是自己写的一个几十行的工具调用脚本——底层跑的都是同一个骨架:模型不是一次性把答案吐出来,而是反复经历"想一步、做一步、看结果、再想下一步",直到任务完成。这个骨架有个具体的名字,叫 ReAct(Reasoning + Acting),来自 Yao 等人 2022 年的论文《ReAct: Synergizing Reasoning and Acting in Language Models》。这篇聊聊这个循环具体是怎么回事、现代 LLM API 是怎么实现它的,以及实践中最容易踩的几个坑。

AI浪潮下,后端开发岗位正在发生什么

5 分钟
“AI 要取代程序员了"这句话已经被说了三年多,热度不减,但也越说越空。它更像一句情绪表达,而不是一个可以拿来做决策依据的判断。与其纠结这个非黑即白的问题,不如换个更具体的问法:在后端、企业级开发这个具体场景里,AI 已经实际改变了什么,还没有改变什么,正在改变什么。这篇笔记只谈这个。

AI Agent的记忆与技能系统:从失忆到越用越懂你

大语言模型本质上是无状态的——每次调用,模型对"你是谁"“上次聊了什么"“你喜欢什么风格"一无所知,除非这些信息被显式塞进当前的上下文窗口。这和 RAG 要解决的问题不是一回事:RAG 补的是模型"没见过的知识”,而这里要聊的是模型"没记住的经历”——同一个用户、同一个项目,换一次会话就打回原形,昨天纠正过的错误今天还会再犯一遍。

RAG检索增强生成:原理、数据切片与向量化详解

11 分钟
大语言模型(LLM)虽然拥有海量的通用知识,但它的知识边界止于训练数据的截止日期,也无法访问企业内部文档、私有数据库这类"没见过"的信息。想让模型回答这些问题,通常有两条路:**微调(Fine-tuning)把新知识"炼"进参数里,或者RAG(Retrieval-Augmented Generation,检索增强生成)**在回答前先把相关资料"喂"给模型。本文重点讲后者——它的基本原理、数据切片(Chunking)与向量化(Embedding)的具体做法,以及一个经常被混淆的问题:向量化和大模型训练到底是不是一回事。