от одного процессора до продакшн-стандарта дата-центровfrom single-processor to the data-center production standard
Самая долгоживущая мажорная ветка в истории ядра: SMP, загружаемые модули как норма, журналируемые файловые системы, и — на середине пути, в 2.6 — полный отказ от параллельных стабильной/нестабильной веток в пользу непрерывной разработки, схема, которая работает и сегодня.The longest-lived major branch in the kernel's history: SMP, loadable modules as the norm, journaling filesystems, and — halfway through, at 2.6 — a full switch away from parallel stable/unstable branches toward continuous development, a scheme still in use today.
Ветка 2.x охватывает 15 лет — с 9 июня 1996 (2.0.0) до 21 июля 2011, когда финальная 2.6.39 сменилась не 2.6.40, а 3.0.0. Внутри неё четыре крупные подветки со своим характером: 2.0 (первый SMP), 2.2 (стабилизация и рост числа архитектур), 2.4 (десктопная зрелость — USB, PnP, ext3) и 2.6 (смена самой модели разработки, длившаяся восемь лет — дольше, чем 2.0, 2.2 и 2.4 вместе взятые). Именно в 2.6 сложилась привычная сегодня практика: одна ветка, релизы каждые 2–3 месяца, никакого разделения на «стабильную» и «экспериментальную» линию.The 2.x branch spans 15 years — from June 9, 1996 (2.0.0) to July 21, 2011, when the final 2.6.39 was followed not by 2.6.40 but by 3.0.0. Within it sit four major sub-branches, each with its own character: 2.0 (the first SMP), 2.2 (stabilization and a growing architecture count), 2.4 (desktop maturity — USB, PnP, ext3), and 2.6 (a shift in the development model itself, lasting eight years — longer than 2.0, 2.2, and 2.4 combined). It was in 2.6 that today's familiar practice took shape: one branch, releases every 2–3 months, no split into "stable" and "experimental" lines.
| версияversion | датаdate | что именно изменилосьwhat actually changed |
|---|---|---|
| 2.0.0 | 1996-06-09 | первый релиз с поддержкой SMP (Алан Кокс) — но всё ядро под единым big kernel lock: пока один CPU внутри ядра, второй ждёт; загружаемые модули (LKM) становятся штатной возможностью, а не экспериментом; файловая система ext2 — новый дефолтthe first SMP-capable release (Alan Cox) — but the whole kernel sits under a single big kernel lock: while one CPU is inside the kernel, a second one waits; loadable kernel modules (LKM) become a standard feature, not an experiment; ext2 becomes the new default filesystem |
| 2.0.x | 1996–1999 | параллельная стабильная линия несколько лет получает багфиксы и порты на новые архитектуры (m68k, MIPS, PowerPC, SPARC64), пока 2.1.x развивается как нестабильная веткаthe parallel stable line receives bugfixes and ports to new architectures (m68k, MIPS, PowerPC, SPARC64) for several years, while 2.1.x develops as the unstable branch |
| 2.2.0 | 1999-01-25 | IP Chains (ipchains, Расти Расселл) — третье поколение firewall-кода для Linux; расширенная поддержка SMP (до 16 CPU), улучшенное управление памятью, больше архитектур в мейнлайнеIP Chains (ipchains, Rusty Russell) — the third generation of Linux firewall code; extended SMP support (up to 16 CPUs), improved memory management, more architectures in mainline |
| 2.3.15 | 1999-08-26 | в нестабильную ветку вливается netfilter (преемник ipchains, тот же автор — Расти Расселл), заложивший основу для iptablesnetfilter merges into the unstable branch (ipchains's successor, same author — Rusty Russell), laying the foundation for iptables |
| 2.4.0 | 2001-01-04 | поддержка USB и Plug-and-Play (автоопределение устройств и ресурсов) — ключевой шаг к десктопной зрелости; netfilter/iptables как штатный firewall вместо ipchainsUSB and Plug-and-Play support (automatic device and resource detection) — a key step toward desktop maturity; netfilter/iptables as the standard firewall, replacing ipchains |
| 2.4.15 | 2001-11 | в мейнлайн входит ext3 — журналируемая файловая система поверх ext2, совместимая по формату данных, но с журналом транзакций, резко сокращающим время восстановления после сбояext3 lands in mainline — a journaling filesystem built on ext2, data-format compatible but with a transaction journal that sharply cuts crash-recovery time |
| 2.6.0 | 2003-12-17 | смена модели разработки: конец разделения на стабильную/нестабильную ветки (предыдущий цикл разработки занял почти 3 года и стал невыносимо тяжёл в поддержке двух параллельных кодовых баз) — отныне одна ветка, новые фичи вливаются постепенно, релизы каждые 2–3 месяца, каждый сразу считается стабильнымa development-model shift: the end of the stable/unstable split (the previous cycle had taken almost 3 years and become unbearable to maintain across two parallel codebases) — from now on, one branch, new features land incrementally, releases every 2–3 months, each one considered stable immediately |
| 2.6.13 | 2005-08 | inotify (уведомления об изменениях файловой системы без polling), execute-in-place, улучшенный CFQ I/O-планировщик, горячее подключение CPU на i386inotify (filesystem change notifications without polling), execute-in-place, an improved CFQ I/O scheduler, i386 CPU hot-plugging |
| 2.6.20 | 2007-02 | KVM (Kernel-based Virtual Machine) входит в мейнлайн — Linux сам становится гипервизором через аппаратную виртуализацию (Intel VT/AMD-V), а не только гостевой ОСKVM (Kernel-based Virtual Machine) lands in mainline — Linux itself becomes a hypervisor via hardware virtualization (Intel VT/AMD-V), not just a guest OS |
| 2.6.23 | 2007-10-09 | CFS (Completely Fair Scheduler) заменяет прежний O(1)-планировщик — справедливое распределение CPU-времени через виртуальное время выполнения вместо приоритетных очередей; параллельно приходят Xen guest support и lguest (паравиртуализация)CFS (Completely Fair Scheduler) replaces the earlier O(1) scheduler — fair CPU-time distribution via virtual runtime instead of priority queues; Xen guest support and lguest (paravirtualization) arrive alongside it |
| 2.6.24 | 2008-01 | control groups (cgroups) — механизм группировки процессов для лимитирования и учёта ресурсов (CPU, память), позже ставший фундаментом контейнеризации (Docker, Kubernetes появятся годы спустя именно на этой базе)control groups (cgroups) — a mechanism for grouping processes to limit and account for resources (CPU, memory), later becoming the foundation of containerization (Docker and Kubernetes would build on exactly this years later) |
| 2.6.28 | 2008-12 | Btrfs включается в мейнлайн как экспериментальная файловая система — copy-on-write, снапшоты, встроенный RAID, задуманная как долгосрочная замена ext-семействаBtrfs is merged into mainline as an experimental filesystem — copy-on-write, snapshots, built-in RAID, intended as a long-term replacement for the ext family |
| 2.6.31 | 2009-09 | ext4 объявляется стабильной (была experimental с 2.6.19) — увеличенные лимиты размера, extents вместо блочного маппинга, отложенное выделение блоковext4 is declared stable (had been experimental since 2.6.19) — larger size limits, extents instead of block mapping, delayed block allocation |
| 2.6.39 | 2011-05-18 | финальный релиз ветки: удаление Big Kernel Lock (BKL) — легаси-механизма блокировки родом из 2.0, тянувшегося 15 лет; масштабируемость ext4 на SMP, обновления Btrfsthe branch's final release: removal of the Big Kernel Lock (BKL) — a legacy locking mechanism dating back to 2.0, carried for 15 years; ext4 SMP scalability, Btrfs updates |
| 3.0.0 | 2011-07-21 | не техническая, а символическая смена номера: минорная версия 2.6.x разрослась до неудобных величин, плюс совпадение с 20-летием проекта — по содержанию 3.0 продолжает 2.6.39 без архитектурного разрываnot a technical but a symbolic version change: the 2.6.x minor number had grown unwieldy, plus it coincided with the project's 20th anniversary — in content, 3.0 continues 2.6.39 with no architectural break |
К середине 1990-х многопроцессорные x86-серверы уже не были экзотикой, но ядро 1.x могло использовать только одно ядро CPU — вся остальная вычислительная мощность простаивала. 2.0.0 (9 июня 1996) закрыла этот пробел трудами Алана Кокса: появилась поддержка симметричной многопроцессорности (SMP). Решение было предельно консервативным — вокруг всего ядра поставили один большой спинлок (Big Kernel Lock, BKL): если один процессор уже исполняет код ядра, второй просто ждёт снаружи. Параллелизм получался грубым, но зато безопасным — тонкая блокировка отдельных подсистем потребовала бы риска, на который в 1996 году идти не стали. Этот же релиз закрепил ext2 как файловую систему по умолчанию и сделал загружаемые модули ядра (LKM) штатной, а не экспериментальной возможностью.By the mid-1990s, multiprocessor x86 servers were no longer exotic, but the 1.x kernel could only use a single CPU core — the rest of the compute capacity sat idle. 2.0.0 (June 9, 1996) closed that gap through Alan Cox's work: symmetric multiprocessing (SMP) support arrived. The approach was deliberately conservative — a single big spinlock (the Big Kernel Lock, BKL) wrapped the entire kernel: if one processor was already executing kernel code, a second one simply waited outside. The resulting parallelism was coarse but safe — fine-grained locking of individual subsystems would have meant a risk nobody was ready to take in 1996. This same release also cemented ext2 as the default filesystem and made loadable kernel modules (LKM) a standard rather than experimental feature.
2.2.0 (25 января 1999) расширила SMP до 16 процессоров и подтянула поддержку памяти и архитектур, но главным символом этой ветки стал ipchains Расти Расселла — третье поколение linux-firewall (после ipfw и ipfwadm), с более гибкой фильтрацией фрагментированных пакетов и подсчётом трафика. Ipchains прожил недолго в качестве магистрального решения: уже в августе 1999-го, в 2.3.15, тот же Расселл влил в нестабильную ветку netfilter — архитектуру с хуками на разных стадиях прохождения пакета через сетевой стек, которая полностью заменит ipchains в 2.4 под именем iptables.2.2.0 (January 25, 1999) extended SMP support to 16 processors and improved memory and architecture support, but the branch's real emblem was Rusty Russell's ipchains — the third generation of Linux firewall code (after ipfw and ipfwadm), with more flexible fragmented-packet filtering and traffic accounting. Ipchains didn't stay the mainline solution for long: already in August 1999, in 2.3.15, that same Russell merged netfilter into the unstable branch — an architecture with hooks at various stages of a packet's path through the network stack, which would fully replace ipchains in 2.4 under the name iptables.
2.4.0 (4 января 2001) — момент, когда Linux начал всерьёз выглядеть как система для обычных пользователей, а не только для серверов и энтузиастов. Поддержка USB означала, что клавиатуры, мыши и звуковые карты можно было просто подключить, а Plug-and-Play позволял ядру самому определять устройства и настраивать их ресурсы, не заставляя пользователя вручную резолвить конфликты IRQ. Netfilter/iptables заменил ipchains как основной механизм фильтрации трафика. Спустя почти год после релиза, в версии 2.4.15 (ноябрь 2001), в мейнлайн вошла ext3 — журналируемая файловая система, использующая тот же формат данных на диске, что и ext2, но добавляющая журнал транзакций: после сбоя питания система восстанавливается за секунды сверкой журнала, а не долгим fsck по всему разделу.2.4.0 (January 4, 2001) was the moment Linux started to seriously look like a system for ordinary users, not just servers and enthusiasts. USB support meant keyboards, mice, and sound cards could simply be plugged in, and Plug-and-Play let the kernel detect devices and configure their resources itself, instead of forcing users to manually resolve IRQ conflicts. Netfilter/iptables replaced ipchains as the primary traffic-filtering mechanism. Almost a year after the release, in version 2.4.15 (November 2001), ext3 landed in mainline — a journaling filesystem using the same on-disk data format as ext2 but adding a transaction journal: after a power failure the system recovers in seconds by replaying the journal, instead of a lengthy fsck across the whole partition.
Цикл разработки 2.4 (от 2.2 до 2.4 прошло два года, а от 2.4 до 2.6 — почти три) вымотал сообщество: поддержка двух параллельных кодовых баз — «стабильной» чётной и «нестабильной» нечётной — требовала дублирования усилий и откладывала попадание новых возможностей к пользователям на годы. 2.6.0 (17 декабря 2003) закрыла эту модель насовсем: с этого момента разработка идёт в одной ветке, новые фичи вливаются постепенно, без разрушительных единовременных переписываний, а релизы выходят каждые 2–3 месяца и сразу считаются пригодными для использования. Эта модель — не единственное изменение 2.6: именно в ней ядро получило современный вид, о котором пойдёт речь в следующих шагах, но сама смена процесса разработки оказалась не менее значимой, чем любая отдельная техническая фича, потому что определила темп всех последующих десятилетий.The 2.4 development cycle (two years from 2.2 to 2.4, almost three from 2.4 to 2.6) wore the community out: maintaining two parallel codebases — a "stable" even-numbered one and an "unstable" odd-numbered one — meant duplicated effort and delayed new features reaching users by years. 2.6.0 (December 17, 2003) ended that model for good: from this point on, development happens in a single branch, new features land incrementally without disruptive one-time rewrites, and releases ship every 2–3 months and are considered usable immediately. This model wasn't 2.6's only change — the branch is also where the kernel took on its modern shape, covered in the next steps — but the process shift itself turned out to matter just as much as any single technical feature, because it set the pace for every decade that followed.
Внутри одной формальной версии «2.6» уместилось больше архитектурных изменений, чем в любой предыдущей мажорной ветке целиком. inotify (2.6.13, 2005) заменил неэффективный polling файловой системы событийными уведомлениями. KVM (2.6.20, 2007) превратил Linux из гостевой ОС для чужих гипервизоров в полноценный гипервизор на основе аппаратной виртуализации Intel VT/AMD-V. CFS (2.6.23, октябрь 2007) заменил планировщик с приоритетными очередями O(1) на модель справедливого распределения через виртуальное время выполнения — тот же принцип с доработками используется и в современных ядрах. cgroups (2.6.24, 2008) добавили механизм группировки и лимитирования ресурсов процессов, который десятилетие спустя станет фундаментом Docker и Kubernetes, хотя в момент появления об этом ещё никто не знал. Btrfs влилась экспериментальной файловой системой в 2.6.28 (2008), а ext4 была объявлена стабильной в 2.6.31 (2009) после двух лет статуса experimental.Within the single formal version "2.6" fit more architectural change than any previous major branch held in its entirety. inotify (2.6.13, 2005) replaced inefficient filesystem polling with event notifications. KVM (2.6.20, 2007) turned Linux from a guest OS running under someone else's hypervisor into a full hypervisor built on Intel VT/AMD-V hardware virtualization. CFS (2.6.23, October 2007) replaced the O(1) priority-queue scheduler with a fair-distribution model based on virtual runtime — the same principle, refined further, is still used in modern kernels. cgroups (2.6.24, 2008) added a mechanism for grouping and limiting process resources that a decade later would become the foundation of Docker and Kubernetes, though nobody knew that yet at the time. Btrfs merged as an experimental filesystem in 2.6.28 (2008), and ext4 was declared stable in 2.6.31 (2009) after two years as experimental.
2.6.39 (18 мая 2011) стала последним релизом номинальной ветки 2.6 — и удалила Big Kernel Lock, механизм грубой блокировки, доставшийся ещё от 2.0.0 пятнадцатью годами ранее: масштабируемость SMP наконец избавилась от последнего рудимента эпохи «единого замка на всё ядро». 29 мая 2011 Линус Торвальдс объявил, что следующий релиз получит номер не 2.6.40, а 3.0 — минорная цифра разрослась до неудобных величин, а год совпадал с 20-летием первого поста в comp.os.minix. Технически 3.0.0 (21 июля 2011) продолжает 2.6.39 без разрыва — это чисто нумерационный, символический жест, а не архитектурная веха, тот же паттерн повторится пятнадцать лет спустя при переходе с 6.x на 7.x.2.6.39 (May 18, 2011) became the last release of the nominal 2.6 branch — and removed the Big Kernel Lock, the coarse locking mechanism inherited from 2.0.0 fifteen years earlier: SMP scalability finally shed the last vestige of the "one lock for the whole kernel" era. On May 29, 2011, Linus Torvalds announced the next release would be numbered not 2.6.40 but 3.0 — the minor number had grown unwieldy, and the year coincided with the 20th anniversary of the first comp.os.minix post. Technically, 3.0.0 (July 21, 2011) continues 2.6.39 without a break — a purely numerical, symbolic gesture rather than an architectural milestone, the same pattern that would repeat fifteen years later at the 6.x → 7.x transition.
К 2.6.39 ядро несло уже принципиально иной набор свойств, чем 1.x: настоящая (пусть и грубая на старте) многопроцессорность вместо однопроцессорной архитектуры, набор из трёх поколений сетевой фильтрации (ipchains → netfilter/iptables), два поколения журналируемых файловых систем в мейнлайне (ext3, ext4) плюс экспериментальная Btrfs, справедливый CPU-планировщик (CFS) вместо приоритетных очередей, встроенная поддержка виртуализации (KVM) и механизм группировки ресурсов (cgroups), ставший впоследствии основой контейнеризации. Модель разработки — та же, что используется и сегодня: единая ветка, релизы каждые 2–3 месяца, никакого разделения на «for developers only» и «for production».By 2.6.39 the kernel carried a fundamentally different property set than 1.x: real (if coarse at the start) multiprocessing instead of a single-processor architecture, three generations of network filtering (ipchains → netfilter/iptables), two generations of journaling filesystems in mainline (ext3, ext4) plus experimental Btrfs, a fair CPU scheduler (CFS) instead of priority queues, built-in virtualization support (KVM), and a resource-grouping mechanism (cgroups) that would later become the basis of containerization. The development model is the same one used today: a single branch, releases every 2–3 months, no split into "for developers only" and "for production."
Смена первой цифры с 2 на 3 создаёт ложное впечатление архитектурного скачка, сравнимого с переходом 1.x → 2.x (появление SMP). На деле 3.0.0 технически идентична по духу 2.6.40 — Торвальдс сам объяснял решение исключительно неудобством разросшейся минорной цифры и совпадением с 20-летием проекта, а не назревшей технической необходимостью.The jump from 2 to 3 creates a false impression of an architectural leap comparable to the 1.x → 2.x transition (the arrival of SMP). In reality 3.0.0 is technically what 2.6.40 would have been in spirit — Torvalds himself explained the decision purely by the unwieldiness of the growing minor number and the coincidence with the project's 20th anniversary, not by any pressing technical need.
Формально «поддержка SMP появилась в 2.0» звучит как завершённая история, но Big Kernel Lock превращал параллелизм в скорее теоретическую возможность: под нагрузкой с интенсивными системными вызовами два CPU реально работали параллельно только в userspace, а не в ядре. Настоящая тонкая блокировка подсистем ядра — многолетний процесс, растянувшийся практически на всю ветку 2.x и завершившийся снятием BKL только в 2.6.39, спустя 15 лет после его введения.Formally, "SMP support arrived in 2.0" sounds like a closed chapter, but the Big Kernel Lock made parallelism more of a theoretical possibility: under a syscall-heavy workload, two CPUs genuinely ran in parallel only in userspace, not inside the kernel. Real fine-grained locking of kernel subsystems was a multi-year process that stretched across nearly the whole 2.x branch and only finished with the BKL's removal in 2.6.39, 15 years after it was introduced.
Ретроспективно легко описать cgroups как предвестник Docker, но в 2008 году механизм преподносился исключительно как инструмент учёта и лимитирования ресурсов для administrator-задач (например, resource control в мультипользовательских системах). Docker появится только в 2013-м, а до этого cgroups годами использовались в куда более скромных сценариях — это иллюстрация того, как фундаментальные абстракции ядра часто находят своё главное применение спустя годы после появления, а не по изначальному плану.In hindsight it's easy to describe cgroups as a Docker precursor, but in 2008 the mechanism was presented purely as a resource-accounting and limiting tool for admin tasks (e.g. resource control on multi-user systems). Docker wouldn't appear until 2013, and before that cgroups spent years in far more modest scenarios — an illustration of how fundamental kernel abstractions often find their killer use case years after introduction, not by original design.