Linux Kernel History: Wetin Still Matter Today

The short version of Linux kernel history

Linux kernel history dey start from version 0.01 for September 1991 reach the 7.x series wey dey boot for servers today. Release list na the least interesting part. Small number of decisions shape the whole thing, and each one still get consequence for machine wey you rent this afternoon.

Dates and version numbers here come from kernel.org and the release history wey e publish. The current state, as of August 2026: 7.0 arrive on 12 April 2026, 7.1 on 14 June 2026, and 7.2 dey for release candidates.

Why GPL choice for 1992 still matter

Version 0.01 dem publish am for 17 September 1991 under licence wey Torvalds write by himself. E require say dem must distribute source, and e add one line wey matter pass: "You may not distribute this for a fee, not even 'handling' costs." For 1991, software dey release for floppy disks, and copying and posting floppy disks dey cost money. That clause make commercial Linux distribution impossible.

E change am. Dem announce move go GNU General Public License (GPL) for the 0.12 release notes for January 1992, and e take effect for 1 February 1992. Version 0.95, for March 1992, na the first release wey dem publish under am. Every business wey later build on Linux dey depend on that change.

The kernel na GPL version 2 only, and e never move go version 3. Torvalds refuse am for 2007, mostly because of the anti-tivoisation rule for GPLv3. That rule require say device wey ship GPL code must also accept modified copy of that code. E see locked hardware as the manufacturer's own business. For 2017, kernel developers publish Kernel Enforcement Statement. The statement borrow one part of GPLv3 anyway: person wey correct violation after dem tell am about the violation go keep the licence, instead of losing am permanently for the first breach.

Two consequences follow for server. The kernel binary wey you boot carry right to the matching source, so nobody fit give you Linux kernel wey you no fit inspect or rebuild. And the copyright notice for the kernel talk say the licence no cover user programs wey use kernel services through normal system calls. Na why proprietary databases and monitoring agents fit ship for Linux without breaking anything. A permissive licence create the opposite pressure, and this difference dey worth understanding before you pick platform: see Linux and FreeBSD as server platforms.

Monolithic kernel na wetin win for real life

For 29 January 1992, Andrew Tanenbaum post one message wey get title "LINUX is obsolete" for comp.os.minix newsgroup. E make two claims. Monolithic kernels, where drivers and filesystems dey run inside one privileged address space, na design from 1970s, while microkernels, where those parts dey run as ordinary processes, na the future. And Linux dey tightly tied to Intel 386, so e no go ever work for other systems.

Portability claim get answer through porting. Version 1.2 for March 1995 add Alpha, SPARC and MIPS. Version 2.0 for June 1996 add 64-bit Alpha port.

Design claim get answer through compromise. Linux no turn microkernel. E get loadable kernel modules: object files wey you fit insert into running kernel and remove again, so driver fit ship separately from kernel binary.

lsmod | head
modinfo virtio_net | head -5

lsmod show wetin dey loaded now. modinfo print the file wey module come from and the parameters wey e accept. For virtual server, most of the disk and network path na modules, na why one kernel image fit boot for hardware wey e never see before.

Modules give that flexibility without the cost wey microkernel design carry. If you isolate driver inside im own process, you go pay for context switch and message for every call, and for 1992 that cost big.

The cost wey Linux keep na the one wey you need plan for: module dey run with full kernel privileges, so bad module fit bring the whole machine down instead of only one process. Out-of-tree modules na where this matter dey show. Vendor driver wey no dey mainline must rebuild against every new kernel, and na DKMS dey do this during upgrade. If that build fail, the device simply no dey available after reboot.

SMP finish take fifteen years

Linux 2.0 for June 1996 na the first kernel wey support symmetric multiprocessing (SMP), meaning say more than one CPU dey run one kernel. The first implementation use one lock, the big kernel lock (BKL), so na only one processor fit dey inside kernel code at any time. So second CPU fit help workload wey dey calculate for user space, but e help system call workload small, because dem queue behind the same lock.

To remove that lock take fifteen years. Dem convert the remaining users go fine-grained locking, mostly through the work of Arnd Bergmann, and dem delete BKL for 2.6.39, wey release on 18 May 2011. Scheduler too move for the same slow timeline: O(1) scheduler for 2.6.0, Completely Fair Scheduler (CFS) from 2.6.23 for 2007, and EEVDF, wey replace CFS for 6.6 for October 2023.

Na this work make 4 vCPU plan no strange today. E still show one limit wey you need know. For shared virtual server, your kernel dey schedule your threads, while hypervisor dey schedule your kernel. Run top and read the %st field. Steal time na CPU wey your kernel ready to use but host give another guest, so no tuning inside your kernel fit recover am.

Why 2.6 series change how dem dey build kernel

Before 2.6, version numbers dey come in pairs. Even second number mean stable series (2.4), while odd one mean development (2.5). Dem release 2.4 on 4 January 2001 and 2.6 on 17 December 2003, so users wait almost three years for the next stable series. Distributions no fit wait, so dem backport patches. Two vendors fit both ship "2.4", but the kernels fit differ by thousands of patches.

Dem drop this split after 2.6. Mainline now open merge window for about two weeks, accept new work, then run release candidates until things quiet down. After that, e release every 9 to 10 weeks, na the cadence wey kernel.org still document. The other part of the model start on 4 March 2005 with the first release of the stable tree. Na fix-only update for 2.6.11 be that, and Greg Kroah-Hartman and Chris Wright maintain am. Stable tree dey accept fixes and reject features.

One effect be say version number stop to be promise. 3.0, 4.0, 5.0 and 7.0 no be rewrites. Torvalds dey increase the first number when the second one grow reach level wey annoy am. Na why 7.0 follow 6.19 for April 2026. For server, wetin matter na which branch your distribution dey track, and whether that branch still dey receive fixes.

How the BitKeeper break produce git for April 2005

From February 2002, dem dey develop the kernel with BitKeeper, one proprietary distributed version control system from Larry McVoy company, BitMover, starting with the 2.5 series. BitMover give kernel developers free licence with conditions: you no fit work on competing version control tool, and you no fit reverse engineer BitKeeper. Plenty developers no like say dem dey build free kernel with tool wey dem no get permission to read.

E break for April 2005, after Andrew Tridgell demonstrate one program wey dey talk to BitKeeper repositories. BitMover call am reverse engineering and withdraw the free licence. The kernel lose its version control system for the middle of development cycle.

Work on git start for 3 April 2005. Torvalds announce am for 6 April. For 7 April, git don dey self-hosting, meaning say git own history don already dey kept inside git. The first merge of several branches run for 18 April. For June 2005, git manage the release of 2.6.12. Torvalds hand maintenance over to Junio Hamano soon after, then go back to the kernel.

The design come directly from the problem: thousands of contributors, plus maintainers wey dey pull from one another across network wey nobody trust. Every object get name from the hash of its content, so if you change one byte for old history, the name of every commit after am go change. Na why clone be evidence, no be claim. Every deploy pipeline, every configuration repository, the code host wey most teams dey push to and the git server wey you fit run by yourself grow from licensing argument about one kernel.

Wetin the LTS model promise, and wetin e no promise

Mainline no be wetin you suppose run. A mainline release dey replaced 9 to 10 weeks later. The stable tree dey carry fixes for some weeks after each release. Longterm branches, wey dem usually write as LTS, dey carry dem for years, and na the ones distributions dey build on.

2.6.32, wey release for December 2009, na where the model show say e work. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 and Ubuntu 10.04 LTS all ship am, and dem maintain the branch until February 2016, more than six years after e appear.

The promise don change more than once. E first be two years, then six years for some branches. For 2023, the stable maintainers reduce the default again to two years, because backporting go old trees dey use maintainer time, and old branches no dey get enough real testing. On 25 February 2026, Greg Kroah-Hartman publish longer projections again, after discussion with the companies wey depend on those branches, and the current framework dey run from three to six years.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

kernel.org list 6 longterm branches as of August 2026. The oldest one, 5.10, go don carry fixes for 6.0 years when e end for Dec 2026. The newest one, 6.18, dem project say e go run reach Dec 2028, wey be 3.1 years of fixes.

Treat those dates as minimum, no be contract. The 6.6 and 6.12 projections both move forward for February 2026, and dem fit drop branch wey nobody dey use instead. Your distribution normally dey choose for you: Debian 13 ship 6.12, and Ubuntu 26.04 LTS ship 7.0. That difference na the practical meaning of the LTS versus interim release question for server, and na wetin really dey change underneath you when you upgrade Ubuntu 24.04 to 26.04.

One trap dey follow from this. uname -r for Ubuntu 24.04 dey print something like 6.8.0-51-generic. That one na upstream base plus the distribution own backports, so the number tell you where the branch start, but e no tell you which fixes dey inside. Scanners wey judge kernel by the version string dey raise false alarms against distribution kernels exactly because of this reason.

Wetín kernel dey argue about right now

Two arguments dey happen now, and both one na about who go do the work.

Rust enter as infrastructure for 6.1 for December 2022. For 7.0, dem comot the experimental label, so the kernel core languages now na C, assembly and Rust, and build no longer need nightly compiler. The argument na about maintenance. If C maintainer change interface, e fit break Rust bindings wey dem no dey read, and the argument na about who responsibility e be to repair dem.

The second argument na AI contribution. Sasha Levin propose policy for July 2025, after machine-assisted patches begin reach the lists in bigger numbers. Dem commit the document on 23 December 2025, and e now dey inside kernel own process documentation for docs.kernel.org/process/coding-assistants.html. AI agent no suppose add Signed-off-by tag, because that line dey certify Developer Certificate of Origin (DCO), and na only person fit certify am. Dem dey declare assistance with Assisted-by: tag. Dem change am from Co-developed-by: during review because tool no be author. Generated code must dey compatible with GPL-2.0-only. The human wey send the patch go review am and carry responsibility for am.

The pressure behind the policy na review time. Generating patch fit take seconds, but reviewing one fit take maintainer whole afternoon. Tag no fit correct that imbalance. Wetin e preserve na provenance: history still dey record who sign for each change, and na that property DCO come protect when dem introduce am for 2004.

Wetín this history mean for the server wey you rent

• The licence na why you fit read and rebuild the kernel wey your provider boot, and why proprietary software still dey run on top of am.
• The monolithic design na why one driver bug fit reboot the whole machine, and why you must rebuild an out-of-tree module every time you upgrade the kernel.
• The release model na why version number no tell you much, while the branch and the end-of-life date tell you almost everything.
• The virtualisation type decide wetin you fit do at all: for KVM you boot your own kernel and load modules, but for container virtualisation wey dey share the host kernel, uname -r go show the host version, modprobe go fail, and several sysctls go dey read-only.

FAQ

Why Linux kernel still dey GPLv2 and e no be GPLv3?

Torvalds reject GPLv3 for 2007, mainly because of the anti-tivoisation requirement. This requirement force device wey ship GPL code to also accept modified version of that code. E see locked hardware as manufacturer business. Relicensing almost impossible for real life too, because thousands of contributors get copyright for the kernel and no assignment agreement dey available to fall back on. Kernel na GPL-2.0-only, so code wey GPLv3 alone cover no fit merge.

Linux kernel na monolithic kernel or microkernel?

Na monolithic kernel with loadable modules. Drivers and filesystems dey run inside kernel address space, and lsmod dey show the ones wey load now. The result na speed for one side and bigger blast radius for the other side: faulty module fit make the whole machine panic, while microkernel go only lose one process. Since 1992, the difference don reduce through FUSE filesystems for user space and eBPF programs wey kernel verify before e run dem.

Wetin be difference between mainline, stable and longterm kernels?

Mainline na Torvalds' tree. E dey release every 9 to 10 weeks, and new features first land there. Stable dey take the latest mainline release and receive bug fixes for some weeks. Longterm branches continue to receive fixes for years, and na dem distributions use build their kernels. kernel.org dey list current longterm branches and projected end-of-life date for each one.

Linux kernel dey accept code wey AI write?

Yes, under policy wey dem commit to for December 2025. Dem must name the tool inside an Assisted-by: tag. AI agent no fit add Signed-off-by line, and generated code must work with GPL-2.0-only. Human submitter sign off, meaning say e review the patch and accept responsibility under the Developer Certificate of Origin.

Which kernel version I suppose run for server?

For almost every case, use the one wey your distribution dey maintain. Distribution kernel na longterm branch plus backported fixes plus vendor testing. Na this one your provider images and support arrangements assume. Build newer mainline kernel when you need specific driver or feature. Before you commit to am, check the end-of-life date for the branch wey you wan move to.