символический сброс нумерации и тихий фундамент контейнерной эпохиa symbolic version reset and the quiet foundation of the container era
Ветка, которая началась с чисто нумерационного жеста (2.6.39 → 3.0, без технического разрыва) и закончилась заделом под live kernel patching. Внутри — четыре года непрерывной разработки той же модели, что и в 2.6, и один релиз (3.8), который спустя годы окажется решающим для контейнеризации.A branch that opened with a purely numerical gesture (2.6.39 → 3.0, no technical break) and closed with groundwork for live kernel patching. In between: four years of continuous development under the same model as 2.6, and one release (3.8) that would turn out, years later, to be decisive for containerization.
Ветка 3.x охватывает три с половиной года — с 21 июля 2011 (3.0.0) до 8 февраля 2015 (3.19, последний релиз перед сменой номера на 4.0). Модель разработки не менялась: та же непрерывная схема, введённая в 2.6.0 — единая ветка, релизы каждые 2–3 месяца, каждый сразу пригоден к использованию. Содержательно ветка запомнилась не одним громким архитектурным сдвигом (как SMP в 2.0 или единая модель разработки в 2.6), а плотной серией более узких, но впоследствии крайне значимых изменений: зрелость Btrfs, продолжение борьбы с bufferbloat в сети, и, что важнее всего в ретроспективе, user namespaces в 3.8 — механизм, без которого современная контейнеризация выглядела бы иначе.The 3.x branch spans three and a half years — from July 21, 2011 (3.0.0) to February 8, 2015 (3.19, the last release before the number changed to 4.0). The development model didn't change: the same continuous scheme introduced at 2.6.0 — a single branch, releases every 2–3 months, each usable immediately. Content-wise the branch is remembered not for one loud architectural shift (like SMP at 2.0 or the unified development model at 2.6) but for a dense series of narrower, later hugely consequential changes: Btrfs maturing, continued anti-bufferbloat networking work, and — most significant in hindsight — user namespaces in 3.8, a mechanism without which modern containerization would look different.
| версияversion | датаdate | что именно изменилосьwhat actually changed |
|---|---|---|
| 3.0.0 | 2011-07-21 | чисто нумерационный жест (см. 2.x) — по содержанию продолжение 2.6.39: data scrubbing и автодефрагментация в Btrfs, Xen Dom0, JIT-компиляция BPF-фильтров, sendmmsg() для батчинга отправки пакетов, setns() для более удобной работы с контейнерамиa purely numerical gesture (see 2.x) — content-wise a continuation of 2.6.39: Btrfs data scrubbing and automatic defragmentation, Xen Dom0, JIT-compiled BPF filters, sendmmsg() for batching packet sends, setns() for more convenient container handling |
| 3.1 – 3.2 | 2011-10 – 2012-01 | 3.2 (4 января 2012): блоки ext4 крупнее 4 КБ (до 1 МБ) для больших файлов, более быстрый scrubbing и автобэкап критических метаданных в Btrfs, верхние лимиты CPU-времени в планировщике процессов, ускоренное восстановление TCP-соединений после потери пакетов3.2 (January 4, 2012): ext4 block sizes above 4 KB (up to 1 MB) for large files, faster Btrfs scrubbing and automatic backup of critical metadata, upper CPU-time limits in the process scheduler, faster TCP connection recovery after packet loss |
| 3.3 | 2012-03-18 | улучшенный ребалансинг и restripe между RAID-профилями Btrfs; настраиваемый лимит очереди передачи сетевых устройств для борьбы с bufferbloat, network priority cgroup, TCP-буферы per-cgroupimproved rebalancing and restriping between Btrfs RAID profiles; a configurable transmit-queue limit on network devices to fight bufferbloat, a network priority cgroup, per-cgroup TCP buffer limits |
| 3.5 | 2012-07-21 | новый алгоритм управления сетевой очередью против bufferbloat, checkpoint/restore для TCP-соединений, TCP Early Retransmit (RFC 5827)a new queue-management algorithm against bufferbloat, checkpoint/restore for TCP connections, TCP Early Retransmit (RFC 5827) |
| 3.6 | 2012-09-30 | TCP Fast Open на стороне клиента — сокращение TCP-рукопожатия до одного SYN-пакета с cookie за счёт кеширования параметров предыдущего соединенияTCP Fast Open, client side — shrinking the TCP handshake to a single SYN packet with a cookie by caching the previous connection's parameters |
| 3.7 | 2012-12-10 | TCP Fast Open на стороне сервера — теперь полный цикл клиент/сервер поддержанTCP Fast Open, server side — now the full client/server cycle is supported |
| 3.8 | 2013-02-18 | ключевая для будущего веха: непривилегированные пользовательские процессы получают возможность создавать user namespaces (CLONE_NEWUSER) — capabilities перестают быть глобальными и интерпретируются в контексте namespace, что позволяет процессу быть root внутри контейнера без root-прав на хосте; плюс NUMA balancing для многопроцессорных системa milestone whose importance would only become clear later: unprivileged user processes gain the ability to create user namespaces (CLONE_NEWUSER) — capabilities stop being global and are interpreted within a namespace's context, letting a process be root inside a container without root on the host; plus NUMA balancing for multi-socket systems |
| 3.10 | 2013-06-30 | объявлена LTS-веткой (получила фиксы ещё около двух лет после обычного цикла); станет базовым ядром RHEL 7 на много лет вперёд, несмотря на бэкпорты гораздо более новых возможностей поверх номинально старой версииdeclared an LTS branch (received fixes for about two more years past the normal cycle); becomes RHEL 7's base kernel for years to come, despite much newer features being backported on top of the nominally old version |
| 3.11 | 2013-09-02 | O_TMPFILE — новый флаг open()/openat() для создания анонимных временных файлов без видимости в файловой системе; zswap — сжатый write-back кеш для страниц подкачки в самой RAM вместо диска; ранняя поддержка huge pages на ARM, KVM/Xen на ARM64O_TMPFILE — a new open()/openat() flag for creating anonymous temporary files invisible in the filesystem; zswap — a compressed write-back cache for swapped pages kept in RAM itself instead of on disk; early ARM huge-page support, KVM/Xen on ARM64 |
| 3.13 | 2014-01-19 | TCP Fast Open включён по умолчанию (было опционально с 3.7); продолжение накопления сетевых улучшенийTCP Fast Open enabled by default (had been opt-in since 3.7); continued accumulation of networking improvements |
| 3.14 | 2014-03-30 | deadline-планировщик для realtime-задач, memory compression (zswap) объявлена стабильной, portable-версия lock validator для userspace, per-inode свойства (например, сжатие) в Btrfs, ASLR ядра (kernel address space randomization), новый сетевой планировщик пакетов против bufferbloata deadline scheduling policy for realtime tasks, memory compression (zswap) declared stable, a userspace port of the lock validator, per-inode properties (e.g. compression) in Btrfs, kernel address space randomization, a new anti-bufferbloat packet scheduler |
| 3.16 – 3.18 | 2014 | продолжение стабилизации: доработки Btrfs, планировщика, файловых систем; накопление патчей для будущего live-patching до его формального появления в 4.0continued stabilization: Btrfs, scheduler, and filesystem refinements; accumulation of patches toward future live-patching ahead of its formal debut in 4.0 |
| 3.19 | 2015-02-08 | финальный релиз ветки — 22 февраля 2015 Торвальдс объявляет, что следующая версия получит номер 4.0, а не 3.20, по опросу сообщества (незначительное большинство предпочло сброс минорной цифры)the branch's final release — on February 22, 2015, Torvalds announces the next version will be numbered 4.0, not 3.20, following a community poll (a slim majority preferred resetting the minor number) |
3.0.0 вышла 21 июля 2011 сразу вслед за 2.6.39, номинально «новая мажорная ветка», но по содержанию продолжающая ту же линию развития Btrfs, cgroups и сетевого стека, что шла последние несколько лет. Функционально релиз добавил зрелые возможности Btrfs (data scrubbing, автодефрагментация), поддержку Xen Dom0 (запуск Linux как управляющего домена гипервизора Xen) и пару системных вызовов, полезных именно для будущей контейнеризации — sendmmsg() для батчинга отправки сетевых пакетов и setns() для присоединения процесса к уже существующему namespace, что стало одним из строительных блоков будущих container runtime.3.0.0 shipped July 21, 2011, right after 2.6.39 — nominally a "new major branch" but content-wise a continuation of the same Btrfs, cgroups, and network-stack development that had been running for the previous several years. Functionally the release added maturing Btrfs capabilities (data scrubbing, automatic defragmentation), Xen Dom0 support (running Linux as a Xen hypervisor's control domain), and a couple of syscalls that would matter specifically for future containerization — sendmmsg() for batching network packet sends and setns() for attaching a process to an already-existing namespace, one of the building blocks of later container runtimes.
Три релиза 2012 года (3.2, 3.3, 3.5) сформировали заметный сквозной сюжет — сетевую подсистему массированно дорабатывали против bufferbloat, явления, когда чрезмерно большие буферы очередей на сетевых устройствах вместо снижения задержки её, наоборот, увеличивают под нагрузкой. Настраиваемые лимиты очередей передачи, per-cgroup TCP-буферы и новые алгоритмы управления очередью — всё это заходило постепенно, релиз за релизом, а не одним большим патчем. Параллельно Btrfs получала автобэкап критических метаданных и улучшенный ребалансинг между RAID-профилями — файловая система, влитая экспериментальной ещё в 2.6.28 (2008), постепенно набирала функциональность, ожидаемую от production-кандидата.The three 2012 releases (3.2, 3.3, 3.5) formed a noticeable throughline — the networking subsystem was heavily reworked against bufferbloat, the phenomenon where oversized queueing buffers on network devices increase latency under load instead of reducing it. Configurable transmit-queue limits, per-cgroup TCP buffers, and new queue-management algorithms all landed gradually, release by release, rather than in one big patch. In parallel, Btrfs gained automatic backup of critical metadata and improved rebalancing between RAID profiles — a filesystem merged as experimental back in 2.6.28 (2008) was steadily accumulating the functionality expected of a production candidate.
3.8 (18 февраля 2013) добавила возможность для непривилегированных процессов создавать собственные user namespaces через CLONE_NEWUSER. До этого релиза namespaces (введённые постепенно начиная ещё с 2.6.x) требовали root-прав, что резко ограничивало их применимость: обычный пользователь не мог изолировать процесс без вмешательства администратора. С 3.8 процесс без каких-либо привилегий получил возможность создать namespace, внутри которого он сам — root (UID 0), при этом отображаясь на хосте как непривилегированный пользователь (например, UID 100000). Это и есть техническая основа rootless-контейнеров: никаких setuid-бинарников, никакого повышения привилегий на хосте. В 2013 году эта возможность не сопровождалась заголовками «вот фундамент контейнерной революции» — Docker выйдет только в марте следующего года, и полноценная популярность user namespaces в контейнерных runtime придёт ещё позже.3.8 (February 18, 2013) added the ability for unprivileged processes to create their own user namespaces via CLONE_NEWUSER. Before this release, namespaces (introduced gradually since 2.6.x) required root privileges, which sharply limited their usefulness — an ordinary user couldn't isolate a process without administrator involvement. From 3.8 on, a process with no privileges at all could create a namespace inside which it is root (UID 0), while appearing on the host as an unprivileged user (say, UID 100000). This is the technical basis of rootless containers: no setuid binaries, no privilege escalation on the host. In 2013 this capability didn't come with headlines reading "here's the foundation of the container revolution" — Docker wouldn't ship until March of the following year, and full popularity of user namespaces in container runtimes would arrive even later.
3.10 (30 июня 2013) была объявлена LTS-веткой — получила фиксы значительно дольше обычного цикла. Особую судьбу этой версии определило то, что Red Hat выбрала её как базовое ядро RHEL 7, а значит, и всех производных дистрибутивов (CentOS 7 и позже совместимых с ним систем) — на годы вперёд. При этом Red Hat практиковала интенсивный бэкпорт новых возможностей из гораздо более свежих апстрим-версий поверх формально «версии 3.10», из-за чего номер версии в проде переставал прямо отражать реальный набор поддерживаемых фич — источник постоянной путаницы для тех, кто судил о возможностях системы по одной цифре версии ядра.3.10 (June 30, 2013) was declared an LTS branch — receiving fixes well past the normal cycle. What sealed this version's particular fate was Red Hat choosing it as RHEL 7's base kernel, and by extension every derivative distribution's (CentOS 7 and later compatible systems) for years to come. Red Hat then practiced heavy backporting of features from much newer upstream versions on top of the formally "3.10" kernel, which meant the version number in production stopped directly reflecting the actual feature set supported — a persistent source of confusion for anyone judging a system's capabilities by a single kernel version digit.
Релизы 3.11–3.18 продолжили модель постепенного накопления. O_TMPFILE (3.11) упростил создание защищённых временных файлов, невидимых в файловой системе до момента явной линковки. zswap (3.11, стабилизирован в 3.14) добавил сжатый write-back кеш для страниц подкачки прямо в RAM — компромисс между полным отказом от swap и медленным диском под нагрузкой. TCP Fast Open прошёл путь от клиентской поддержки (3.6) через серверную (3.7) до включения по умолчанию (3.13) — типичный пример того, как сетевая фича внедряется не одним релизом, а серией. Deadline-планировщик для realtime-задач и kernel ASLR (3.14) добавили строительные блоки для предсказуемости и безопасности, каждый — узкий по объёму, но значимый для своей области применения.The 3.11–3.18 releases continued the pattern of gradual accumulation. O_TMPFILE (3.11) simplified creating secure temporary files invisible in the filesystem until explicitly linked. zswap (3.11, stabilized in 3.14) added a compressed write-back cache for swapped pages right in RAM — a middle ground between no swap at all and a slow disk under load. TCP Fast Open went from client support (3.6) through server support (3.7) to being enabled by default (3.13) — a typical example of a networking feature rolling out across a series of releases rather than one. The deadline scheduling policy for realtime tasks and kernel ASLR (3.14) added building blocks for predictability and security, each narrow in scope but significant within its own domain.
3.19 (8 февраля 2015) стала последним релизом ветки. 22 февраля 2015 Торвальдс, опросив сообщество, объявил, что следующий релиз получит номер 4.0, а не 3.20 — причина та же, что и с переходом 2.6 → 3.0 четырьмя годами ранее: минорная цифра снова выросла до неудобной величины, архитектурного разрыва не было. Технически значимой оказалась не сама смена номера, а то, что именно вошло в 4.0 сразу вслед за ней — фундамент live kernel patching, объединивший наработки SUSE (kGraft, представлен в феврале 2013) и Red Hat (kpatch, март 2013) в единый механизм Livepatch, позволяющий накатывать критические исправления безопасности на работающее ядро без перезагрузки. Formально это уже история ветки 4.x, но её корни — прямое продолжение многолетней параллельной работы двух проектов, стартовавшей ещё в разгар цикла 3.x.3.19 (February 8, 2015) was the branch's last release. On February 22, 2015, Torvalds, after polling the community, announced the next release would be numbered 4.0 rather than 3.20 — the same reasoning as the 2.6 → 3.0 transition four years earlier: the minor number had again grown unwieldy, with no architectural break involved. What mattered technically wasn't the number change itself but what landed right after it in 4.0 — the foundation of live kernel patching, unifying SUSE's work (kGraft, introduced February 2013) and Red Hat's (kpatch, March 2013) into a single Livepatch mechanism that lets critical security fixes be applied to a running kernel without a reboot. Formally that's already 4.x's story, but its roots are a direct continuation of years of parallel work by two projects that started in the thick of the 3.x cycle.
К 3.19 ядро приобрело набор возможностей, которые определят следующее десятилетие инфраструктуры: непривилегированные user namespaces как техническая основа rootless-контейнеров (даже если сами контейнерные экосистемы вокруг них ещё только формировались), Btrfs как зрелую (хотя формально всё ещё не «default») альтернативу ext-семейству, комплексную борьбу с bufferbloat в сетевом стеке и первые строительные блоки для патчинга ядра без перезагрузки. Модель разработки не менялась ни разу за всю ветку — единая линия, релизы по расписанию, никаких параллельных веток. Именно отсутствие драматических архитектурных разрывов и делает 3.x веткой, которую проще всего описать неправильно: она выглядит как «промежуточная» между 2.6 и 4.0, но именно в ней появился один из важнейших примитивов современной инфраструктуры.By 3.19 the kernel had acquired a feature set that would define the following decade of infrastructure: unprivileged user namespaces as the technical basis of rootless containers (even as the container ecosystems built around them were still forming), Btrfs as a mature (though formally still not "default") alternative to the ext family, systematic anti-bufferbloat networking work, and the first building blocks for rebooting-free kernel patching. The development model never changed across the whole branch — one line, releases on schedule, no parallel branches. It's precisely the absence of dramatic architectural breaks that makes 3.x the branch easiest to describe wrong: it looks like a mere "in-between" stretch between 2.6 and 4.0, yet it's exactly where one of modern infrastructure's most important primitives appeared.
Docker (март 2014) популяризировал контейнеры до статуса мейнстрим-технологии, но ключевой примитив для непривилегированной изоляции — user namespaces — появился в ядре годом раньше, в 3.8 (февраль 2013). Сами namespaces (PID, network, mount) вводились ещё в 2.6.x постепенно; 3.8 закрыла последний барьер — требование root для их создания. Путать «Docker сделал контейнеры массовыми» с «Docker изобрёл контейнеры» — распространённая ошибка, стирающая годы предшествующей работы над ядром.Docker (March 2014) popularized containers into a mainstream technology, but the key primitive for unprivileged isolation — user namespaces — appeared in the kernel a year earlier, at 3.8 (February 2013). The namespaces themselves (PID, network, mount) had been introduced gradually since 2.6.x; 3.8 closed the last barrier — the root requirement for creating them. Conflating "Docker made containers mainstream" with "Docker invented containers" is a common mistake that erases years of prior kernel work.
Версия ядра в /proc/version на RHEL 7/CentOS 7 действительно показывает 3.10.x на протяжении всего жизненного цикла дистрибутива, но Red Hat систематически бэкпортировала функциональность из значительно более новых апстрим-веток (иногда вплоть до 4.x) поверх этой базы. Суждение о возможностях системы по номеру версии ядра в таких enterprise-дистрибутивах вводит в заблуждение — реальный набор поддерживаемых фич нужно проверять по changelog дистрибутива, а не по номеру ветки апстрима.The kernel version in /proc/version on RHEL 7/CentOS 7 genuinely shows 3.10.x for the distribution's entire lifecycle, but Red Hat systematically backported functionality from significantly newer upstream branches (sometimes as far as 4.x) onto that base. Judging a system's capabilities by the kernel version number on such enterprise distributions is misleading — the actual supported feature set needs checking against the distro's changelog, not the upstream branch number.
Переход 2.6.39 → 3.0 (2011) был мотивирован разросшейся минорной цифрой и совпал с 20-летием Linux — что легко запомнить как единую причину. Переход 3.19 → 4.0 (2015) был мотивирован тем же самым (неудобная минорная цифра), но никакой круглой годовщины в этот момент не было — Торвальдс просто устроил опрос сообщества и последовал за слабым большинством. Смешивать эти два случая в одну историю «Линус любит менять цифры к юбилеям» — неточность: совпадение с 20-летием было разовым, а не правилом.The 2.6.39 → 3.0 transition (2011) was motivated by the growing minor number and coincided with Linux's 20th anniversary — easy to remember as a single cause. The 3.19 → 4.0 transition (2015) was motivated by the same thing (an unwieldy minor number), but there was no round anniversary at that point — Torvalds simply polled the community and followed a slim majority. Merging these two into one story of "Linus likes changing numbers on anniversaries" is inaccurate: the 20th-anniversary coincidence was a one-off, not a rule.