Linux çekirdek tarihi ve günümüze etkileri

Linux çekirdek geçmişinin kısa özeti

Linux çekirdek geçmişi, Eylül 1991'deki 0.01 sürümünden günümüzde sunucularda çalışan 7.x serisine kadar uzanır. Sürüm listesi, bu geçmişin en az ilgi çekici kısmıdır. Az sayıda karar çekirdeğin yapısını belirlemiştir ve her birinin bugün kiraladığınız bir makine üzerinde hâlâ sonuçları vardır.

Buradaki tarihler ve sürüm numaraları kernel.org ve yayınladığı sürüm geçmişinden alınmıştır. Ağustos 2026 itibarıyla mevcut durum şöyledir: 7.0 sürümü 12 Nisan 2026'da, 7.1 sürümü 14 Haziran 2026'da yayınlanmış olup 7.2 sürümü ise aday sürümler (release candidate) aşamasındadır.

1992 yılında yapılan GPL tercihinin güncel önemi

Sürüm 0.01, 17 Eylül 1991 tarihinde Torvalds'ın bizzat kaleme aldığı bir lisansla yayımlandı. Bu lisans, kaynak kodun dağıtılmasını zorunlu kılıyor ve daha kritik bir madde ekliyordu: "Bunu bir ücret karşılığında, 'işlem' masrafları dahil olmak üzere dağıtamazsınız." 1991 yılında yazılım disketlerle dağıtılıyordu ve disketlerin kopyalanıp postalanması bir maliyet gerektiriyordu. Bu madde, ticari bir Linux dağıtımını imkansız kılıyordu.

Torvalds bu durumu değiştirdi. GNU General Public License (GPL) lisansına geçiş, Ocak 1992'deki 0.12 sürüm notlarında duyuruldu ve 1 Şubat 1992 itibarıyla yürürlüğe girdi. Mart 1992'de yayımlanan 0.95 sürümü, bu lisans altında çıkan ilk sürümdü. Daha sonra Linux üzerine inşa edilen tüm ticari yapılar, bu değişikliğe dayanmaktadır.

Çekirdek yalnızca GPL sürüm 2 lisansına tabidir ve hiçbir zaman sürüm 3'e geçmemiştir. Torvalds 2007 yılında, büyük ölçüde GPLv3'teki "anti-tivoisation" kuralı nedeniyle bu geçişi reddetti. Söz konusu kural, GPL kodu içeren bir cihazın, bu kodun değiştirilmiş bir kopyasını da kabul etmesini zorunlu kılıyordu. Torvalds, kilitli donanımları üreticinin kendi ticari meselesi olarak değerlendirdi. 2017 yılında çekirdek geliştiricileri, Kernel Enforcement Statement belgesini yayımladı. Bu belge, GPLv3'ten bir maddeyi ödünç almaktadır: Bir ihlali bildirimden sonra düzelten kişi, lisansını kalıcı olarak kaybetmek yerine korumaya devam eder.

Bu durumun sunucular üzerinde iki sonucu vardır. Önyüklediğiniz çekirdek ikili dosyası, eşleşen kaynak koda erişim hakkını beraberinde getirir; dolayısıyla hiç kimse size inceleyemeyeceğiniz veya yeniden derleyemeyeceğiniz bir Linux çekirdeği veremez. Ayrıca çekirdek üzerindeki telif hakkı bildirimi, çekirdek servislerini standart sistem çağrıları ile kullanan kullanıcı programlarının bu lisans kapsamında olmadığını belirtir. Bu sayede tescilli veritabanları ve izleme ajanları, herhangi bir kuralı ihlal etmeden Linux üzerinde çalışabilir. İzin verici (permissive) bir lisans ise tam tersi bir baskı oluşturur. Bir platform seçmeden önce bu farkı anlamak önemlidir: bkz. Sunucu platformu olarak Linux ve FreeBSD.

Monolitik çekirdek pratikte neden kazandı

29 Ocak 1992 tarihinde Andrew Tanenbaum, comp.os.minix haber grubuna "LINUX is obsolete" başlıklı bir ileti gönderdi. İki iddiada bulundu. Sürücülerin ve dosya sistemlerinin tek bir ayrıcalıklı adres alanı içinde çalıştığı monolitik çekirdeklerin 1970'lerin tasarımı olduğunu, bu parçaların sıradan süreçler olarak çalıştığı mikro çekirdeklerin ise geleceği temsil ettiğini savundu. Ayrıca Linux'un Intel 386 mimarisine sıkı sıkıya bağlı olduğunu ve asla taşınamayacağını öne sürdü.

Taşınabilirlik iddiası, portlama çalışmalarıyla yanıtlandı. Mart 1995'teki 1.2 sürümü Alpha, SPARC ve MIPS desteğini ekledi. Haziran 1996'daki 2.0 sürümü ise 64-bit Alpha portunu getirdi.

Tasarım iddiası ise bir uzlaşma ile yanıtlandı. Linux hiçbir zaman bir mikro çekirdek olmadı. Bunun yerine yüklenebilir çekirdek modüllerine kavuştu: çalışan bir çekirdeğe ekleyip tekrar çıkarabildiğiniz nesne dosyaları sayesinde, bir sürücü çekirdek ikili dosyasından ayrı olarak dağıtılabilir hale geldi.

lsmod | head
modinfo virtio_net | head -5

lsmod şu anda nelerin yüklü olduğunu listeler. modinfo ise modülün geldiği dosyayı ve kabul ettiği parametreleri yazdırır. Sanal bir sunucuda disk ve ağ yolunun büyük bir kısmı modüllerden oluşur; bu nedenle tek bir çekirdek imajı, daha önce hiç karşılaşmadığı donanımlar üzerinde önyüklenebilir.

Modüller, bu esnekliği mikro çekirdek tasarımının getirdiği maliyet olmadan sağladı. Bir sürücüyü kendi süreci içinde izole etmek, her çağrıda bir bağlam değişimi (context switch) ve mesajlaşma maliyeti ödemek anlamına gelir; 1992 yılında bu maliyet oldukça yüksekti.

Linux'un koruduğu ve planlama gerektiren maliyet ise şudur: bir modül tam çekirdek ayrıcalıklarıyla çalışır, bu yüzden hatalı bir modül tek bir süreci değil, tüm makineyi çökertir. Bu durumun en çok hissedildiği yer, ana hat (mainline) dışındaki modüllerdir. Ana hat içinde yer almayan bir üretici sürücüsü, her yeni çekirdek sürümünde yeniden derlenmelidir; DKMS bir yükseltme sırasında tam olarak bunu yapar ve bu derleme başarısız olduğunda, yeniden başlatmanın ardından cihaz basitçe kaybolur.

SMP'nin tamamlanması neden on beş yıl sürdü

Haziran 1996'da yayınlanan Linux 2.0, simetrik çoklu işlemeyi (SMP) destekleyen ilk çekirdekti; bu, birden fazla CPU'nun tek bir çekirdeği çalıştırabileceği anlamına geliyordu. İlk uygulama, tek bir kilit olan büyük çekirdek kilidini (BKL) kullanıyordu, bu nedenle aynı anda yalnızca bir işlemci çekirdek kodu içinde bulunabiliyordu. Bu nedenle ikinci bir CPU, kullanıcı alanında hesaplama yapan bir iş yüküne yardımcı olurken, sistem çağrılarından oluşan bir iş yüküne çok az katkı sağlıyordu çünkü bu çağrılar aynı kilidin arkasında kuyruğa giriyordu.

Bu kilidin kaldırılması on beş yıl sürdü. Kalan kullanıcılar büyük ölçüde Arnd Bergmann tarafından ince taneli kilitleme yapısına dönüştürüldü ve BKL, 18 Mayıs 2011'de yayınlanan 2.6.39 sürümünde silindi. Zamanlayıcı da aynı yavaş zaman çizelgesinde ilerledi: 2.6.0 sürümündeki O(1) zamanlayıcı, 2007'de 2.6.23 ile gelen Completely Fair Scheduler (CFS) ve Ekim 2023'te 6.6 sürümünde CFS'nin yerini alan EEVDF.

Bu çalışma, 4 vCPU'lu bir planın günümüzde neden sıradan karşılandığının sebebidir. Aynı zamanda bilinmesi gereken bir sınırı da işaret eder. Paylaşımlı bir sanal sunucuda çekirdeğiniz iş parçacıklarınızı zamanlar, hipervizör ise çekirdeğinizi zamanlar. top komutunu çalıştırın ve %st alanını okuyun. Steal time, çekirdeğinizin kullanmaya hazır olduğu ancak ana makinenin başka bir konuğa verdiği CPU süresidir; bu nedenle çekirdeğinizin içindeki hiçbir ayar bunu geri kazandıramaz.

2.6 serisi çekirdek derleme yöntemini neden değiştirdi

2.6 öncesinde sürüm numaraları çiftler halinde gelirdi. İkinci numaranın çift olması kararlı bir seriyi (2.4), tek olması ise geliştirme aşamasını (2.5) temsil ederdi. 2.4 sürümü 4 Ocak 2001'de, 2.6 ise 17 Aralık 2003'te yayınlandığından, kullanıcılar bir sonraki kararlı seri için neredeyse üç yıl beklemek zorunda kaldı. Dağıtımlar bu kadar bekleyemediği için geriye dönük yamalar (backport) uyguladı. "2.4" sürümünü dağıtan iki farklı tedarikçi, aralarında binlerce yama farkı olan çekirdekler sunuyordu.

Bu ayrım 2.6'dan sonra terk edildi. Ana hat (mainline) artık yaklaşık iki haftalık bir birleştirme penceresi açıyor, yeni çalışmaları kabul ediyor, ardından süreç sakinleşene kadar sürüm adayları (release candidate) yayınlıyor ve kernel.org tarafından hala belgelenen 9 ila 10 haftalık bir döngüyle yeni sürümü çıkarıyor. Modelin diğer yarısı, 4 Mart 2005'te Greg Kroah-Hartman ve Chris Wright tarafından sürdürülen 2.6.11 sürümüne yönelik yalnızca düzeltme içeren ilk kararlı ağaç (stable tree) yayınıyla geldi. Kararlı ağaç yalnızca düzeltmeleri kabul eder, yeni özellikleri reddeder.

Bunun bir yan etkisi olarak sürüm numarası bir vaat olmaktan çıktı. 3.0, 4.0, 5.0 ve 7.0 sürümleri yeniden yazılmış kodlar değildir. Torvalds, ikinci numara onu rahatsız edecek kadar büyüdüğünde ilk numarayı yükseltir; Nisan 2026'da 6.19'dan sonra 7.0'a geçilmesinin nedeni budur. Bir sunucu için önemli olan, dağıtımınızın hangi dalı takip ettiği ve o dalın hala düzeltme alıp almadığıdır.

Nisan 2005'te BitKeeper kopuşu git'i nasıl ortaya çıkardı

Şubat 2002'den itibaren çekirdek, Larry McVoy'un şirketi BitMover'a ait tescilli bir dağıtık sürüm kontrol sistemi olan BitKeeper ile 2.5 serisinden başlayarak geliştirildi. BitMover, çekirdek geliştiricilerine bazı koşullara bağlı ücretsiz bir lisans verdi: rakip bir sürüm kontrol aracı üzerinde çalışamaz ve BitKeeper'ı tersine mühendislik ile inceleyemezdiniz. Birçok geliştirici, içeriğini okumalarına izin verilmeyen bir araçla özgür bir çekirdek oluşturmaktan hoşlanmıyordu.

Bu durum, Andrew Tridgell'in BitKeeper depolarıyla iletişim kuran bir programı göstermesinin ardından Nisan 2005'te bozuldu. BitMover bunu tersine mühendislik olarak nitelendirdi ve ücretsiz lisansı geri çekti. Çekirdek, bir geliştirme döngüsünün ortasında sürüm kontrol sistemini kaybetti.

git üzerindeki çalışmalar 3 Nisan 2005'te başladı. Torvalds bunu 6 Nisan'da duyurdu. 7 Nisan'da git kendi kendini barındırır (self-hosting) hale geldi; yani git'in kendi geçmişi zaten git içinde tutuluyordu. Birkaç dalın ilk birleştirme işlemi 18 Nisan'da gerçekleştirildi. Haziran 2005'te git, 2.6.12 sürümünün yayınlanmasını yönetti. Torvalds, kısa bir süre sonra bakım sorumluluğunu Junio Hamano'ya devretti ve çekirdeğe geri döndü.

Tasarım doğrudan sorunun kendisinden doğdu: binlerce katkıda bulunan kişi ve kimsenin güvenmediği bir ağ üzerinden birbirlerinden veri çeken bakımcılar. Her nesne, içeriğinin karması (hash) ile adlandırılır; bu nedenle eski geçmişteki bir baytı değiştirmek, ondan sonraki her commit'in adını değiştirir. Bir klonun sadece bir iddia değil, kanıt olmasının nedeni budur. Her dağıtım hattı, her yapılandırma deposu, çoğu ekibin kod gönderdiği barındırma servisi ve kendi sunucunuzda çalıştırabileceğiniz git sunucusu, bir çekirdek hakkındaki lisans tartışmasından türemiştir.

LTS modelinin vaat ettikleri ve etmedikleri

Mainline sürüm, üretim ortamında çalıştırılacak sürüm değildir. Bir mainline sürüm, 9 ila 10 hafta sonra yerini bir sonrakine bırakır. Stable ağacı, her sürümden sonra birkaç hafta boyunca düzeltmeleri barındırır. Genellikle LTS olarak adlandırılan Longterm dalları ise bu düzeltmeleri yıllarca taşır ve dağıtımlar temel olarak bu dalları kullanır.

Aralık 2009'da yayınlanan 2.6.32, bu modelin kendini kanıtladığı sürümdür. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 ve Ubuntu 10.04 LTS bu sürümü kullanmıştır ve dal, ortaya çıkışından altı yıldan fazla bir süre sonra, Şubat 2016'ya kadar desteklenmiştir.

Bu vaat birden fazla kez değişmiştir. Başlangıçta iki yıl olan destek süresi, bazı dallar için altı yıla çıkarılmıştır. 2023 yılında stable sürüm sorumluları, eski ağaçlara geriye dönük düzeltme (backport) taşımanın bakım süresini tüketmesi ve eski dalların yeterince test edilmemesi nedeniyle varsayılan süreyi tekrar iki yıla indirmiştir. 25 Şubat 2026 tarihinde Greg Kroah-Hartman, bu dallara bağımlı olan şirketlerle yapılan görüşmelerin ardından daha uzun projeksiyonlar yayınlamış ve mevcut çerçeve üç ila altı yıl arasına çekilmiştir.

[
  {
    "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, Ağustos 2026 itibarıyla 6 adet longterm dalı listelemektedir. En eskisi olan 5.10, Dec 2026 tarihinde sona erdiğinde 6.0 yıl boyunca düzeltmeleri taşımış olacaktır. En yenisi olan 6.18 sürümünün ise Dec 2028 tarihine kadar sürmesi öngörülmektedir; bu da 3.1 yıllık düzeltme desteği anlamına gelir.

Bu tarihleri bir sözleşme değil, bir alt sınır olarak değerlendirin. 6.6 ve 6.12 projeksiyonlarının her ikisi de Şubat 2026'da ileri bir tarihe çekilmiştir; kimsenin kullanmadığı bir dal ise destekten düşürülebilir. Dağıtımınız genellikle bu seçimi sizin yerinize yapar: Debian 13, 6.12 sürümünü; Ubuntu 26.04 LTS ise 7.0 sürümünü kullanır. Bu fark, sunucuda LTS ile ara sürüm seçimi sorusunun pratik karşılığıdır ve Ubuntu 24.04'ten 26.04'e yükseltme yaptığınızda arka planda gerçekten değişen şey budur.

Bu durumdan kaynaklanan bir tuzak mevcuttur. Ubuntu 24.04 üzerinde uname -r komutu, 6.8.0-51-generic gibi bir çıktı verir. Bu çıktı, upstream temel sürüm ile dağıtımın kendi eklediği backport'ların birleşimidir; dolayısıyla bu numara size dalın nereden başladığını söyler, içinde hangi düzeltmelerin olduğunu değil. Çekirdeği sadece sürüm dizgisine bakarak değerlendiren tarayıcılar, tam da bu nedenle dağıtım çekirdekleri hakkında hatalı alarmlar üretir.

Çekirdeğin şu anki tartışma konuları

İki tartışma gündemdedir ve her ikisi de iş yükünün kime ait olduğu üzerinedir.

Rust, Aralık 2022'de 6.1 sürümüyle altyapı olarak çekirdeğe dahil edildi. 7.0 sürümünde deneysel etiketi kaldırıldı; böylece çekirdeğin temel dilleri C, assembly ve Rust haline geldi ve derleme süreci artık nightly derleyiciye ihtiyaç duymuyor. Tartışma, bakım sorumluluğu üzerinedir. Bir arayüzü değiştiren C sürdürücüsü, okumadığı Rust bağlamalarını bozabilir; tartışma, bu bağlamaları düzeltmenin kimin görevi olduğu üzerinedir.

İkinci tartışma ise yapay zeka katkılarıdır. Sasha Levin, makine destekli yamaların listelere ulaşan hacminin artması üzerine Temmuz 2025'te bir politika önerdi. Belge 23 Aralık 2025 tarihinde işlendi ve şu anda çekirdeğin kendi süreç dokümantasyonunda docs.kernel.org/process/coding-assistants.html adresinde yer almaktadır. Bir yapay zeka temsilcisi Signed-off-by etiketi ekleyemez; çünkü bu satır, Developer Certificate of Origin (DCO) belgesini onaylar ve bunu yalnızca bir kişi onaylayabilir. Yardım, inceleme sırasında Co-developed-by: etiketinden değiştirilen Assisted-by: etiketi ile beyan edilir; çünkü bir araç yazar değildir. Üretilen kod, yalnızca GPL-2.0 ile uyumlu olmalıdır. Yamayı gönderen insan, yamayı inceler ve sorumluluğunu üstlenir.

Politikanın arkasındaki baskı, inceleme süresidir. Bir yama oluşturmak saniyeler sürerken, bir sürdürücünün bir yamayı incelemesi bir öğleden sonrasını alabilir. Bir etiket bu dengesizliği gidermez. Ancak koruduğu şey kökendir: geçmiş, her değişiklik için kimin imza attığını kaydetmeye devam eder; bu, DCO'nun 2004 yılında korumak için getirildiği özelliktir.

Bu geçmişin kiraladığınız sunucu için anlamı

• Lisans, sağlayıcınızın başlattığı çekirdeği neden okuyup yeniden derleyebildiğinizin ve sahipli yazılımların neden üzerinde çalışmaya devam ettiğinin sebebidir.
• Monolitik tasarım, tek bir sürücü hatasının neden tüm makineyi yeniden başlattığının ve çekirdek dışı bir modülün neden her çekirdek yükseltmesinde yeniden derlenmesi gerektiğinin sebebidir.
• Sürüm modeli, sürüm numarasının size neden çok az şey anlattığının, buna karşın dalın ve kullanım ömrü sonu tarihinin neden neredeyse her şeyi açıkladığının sebebidir.
• Sanallaştırma türü, ne yapabileceğinizi belirler: KVM üzerinde kendi çekirdeğinizi başlatıp modül yükleyebilirsiniz; ancak ana makine çekirdeğini paylaşan kapsayıcı sanallaştırmasında uname -r ana makinenin sürümünü gösterir, modprobe başarısız olur ve çeşitli sysctl değerleri salt okunur durumdadır.

FAQ

Linux çekirdeği neden GPLv3 değil de hala GPLv2 lisansına sahip?

Torvalds, 2007 yılında GPLv3'e geçmemeye karar verdi. Bunun temel nedeni, GPL kodunu içeren bir cihazın, bu kodun değiştirilmiş bir sürümünü de kabul etmesini zorunlu kılan "anti-tivoisation" (cihaz kilitlemeyi engelleme) şartıdır. Torvalds, kilitli donanımları üreticinin kendi meselesi olarak görür. Ayrıca, çekirdek üzerindeki telif hakları binlerce katılımcıya ait olduğundan ve başvurulabilecek bir hak devri sözleşmesi bulunmadığından, lisans değişikliği pratikte imkansıza yakındır. Çekirdek yalnızca GPL-2.0 lisansına sahiptir; bu nedenle yalnızca GPLv3 altında sunulan kodlar çekirdeğe dahil edilemez.

Linux çekirdeği monolitik bir çekirdek mi yoksa mikro çekirdek mi?

Yüklenebilir modüllere sahip monolitik bir çekirdektir. Sürücüler ve dosya sistemleri çekirdeğin adres alanı içinde çalışır ve lsmod şu anda yüklü olanları gösterir. Bunun sonucu bir tarafta hız, diğer tarafta ise etki alanıdır: hatalı bir modül tüm makinenin çökmesine (kernel panic) neden olabilir; mikro çekirdek mimarisinde ise sadece ilgili süreç kaybedilir. 1992'den bu yana kullanıcı alanındaki FUSE dosya sistemleri ve çekirdeğin çalıştırmadan önce doğruladığı eBPF programları sayesinde bu durum esnemiştir.

Mainline, stable ve longterm çekirdekleri arasındaki fark nedir?

Mainline, Torvalds'ın ağacıdır; her 9 ila 10 haftada bir yayınlanır ve yeni özellikler ilk olarak buraya eklenir. Stable, en güncel mainline sürümünü alır ve birkaç hafta boyunca hata düzeltmeleri alır. Longterm dalları yıllarca düzeltme almaya devam eder ve dağıtımların kendi çekirdeklerini oluştururken temel aldıkları sürümler bunlardır. kernel.org, mevcut longterm dallarını ve her biri için öngörülen kullanım ömrü sonu (end-of-life) tarihlerini listeler.

Linux çekirdeği yapay zeka tarafından yazılan kodları kabul ediyor mu?

Evet, Aralık 2025'te kabul edilen bir politika kapsamında kabul edilmektedir. Kullanılan araç bir Assisted-by: etiketinde belirtilmeli, yapay zeka temsilcisi bir Signed-off-by satırı eklememeli ve üretilen kod GPL-2.0 ile uyumlu olmalıdır. Gönderimi yapan insan, yamayı incelediğini ve Developer Certificate of Origin kapsamında sorumluluğu üstlendiğini belirten "sign-off" işlemini gerçekleştirir.

Bir sunucuda hangi çekirdek sürümünü kullanmalıyım?

Hemen hemen her durumda, dağıtımınızın desteklediği sürümü kullanmalısınız. Dağıtım çekirdeği; bir longterm dalı, geriye dönük taşınan (backported) düzeltmeler ve satıcının testlerinden oluşur; sağlayıcınızın imajları ve destek anlaşmalarınız bu yapı üzerine kuruludur. Belirli bir sürücüye veya özelliğe ihtiyaç duyduğunuzda daha yeni bir mainline çekirdeği derleyebilirsiniz; ancak geçiş yapmadan önce ilgili dalın kullanım ömrü sonu tarihini kontrol etmelisiniz.