Debian 13 "Trixie" yayımlandı

• Debian projesi, yaklaşık 2 yıl 1 ay 30 günlük geliştirme sürecinden sonra yeni kararlı Debian 13 "Trixie" sürümünü tanıttı
• GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0, Xfce 4.20 gibi birçok masaüstü ortamını standart olarak destekliyor
• 14.100'den fazla yeni paket eklendi; toplam paket sayısı 69.830 oldu, 8.840 paket ise yaşlanma nedeniyle kaldırıldı
• 44.326 paket güncellendi ve büyük ölçekte bir kod tabanı revizyonu gerçekleştirildi; toplam disk kullanımı 403GB, kod satırı sayısı ise 1.4 milyar oldu
• Desteklenen mimariler: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x
  • resmi olarak riscv64 desteği ilk kez sunuldu
  • i386 desteğinin durdurulmasına karar verildi: resmi çekirdek ve kurulum araçları sağlanmıyor, yalnızca 64-bit CPU'larda sınırlı kullanım mümkün
  • armel mimarisi bu sürümle son kez destekleniyor
• i386 dışındaki tüm mimarilerde 64-bit time_t ABI uygulanıyor ve 2038 sonrası tarihler destekleniyor

• Yazılım ve Geliştirme Araçları

  • Toplam paketlerin %63'ünden fazlası güncellenmiş olarak sunuluyor
  • Öne çıkan yazılım ve geliştirme araçları: Apache 2.4.64, Bash 5.2.37, BIND 9.20, curl/libcurl 8.14.1, Emacs 30.1, GNU Compiler Collection 14.2, GIMP 3.0.4, LibreOffice 25.2, Linux kernel 6.12 LTS, LLVM/Clang 19, Python 3.13, Rustc 1.85, Systemd 257, Vim 9.1 vb.
  • arch, sunucu, masaüstü, küme, veritabanı, web ve depolama sunucuları gibi çeşitli kullanım alanları için uygun
  • Otomatik kurulum ve yükseltme testleri gibi kalite güvence süreçleri güçlendirildi

• Bulut ve Canlı Kurulum Desteği

  • Amazon EC2, Microsoft Azure, OpenStack, PlainVM, NoCloud gibi bulut servisleri için imajlar sağlanıyor
  • Bulut imajlarında cloud-init otomasyonu ve hızlı örnek başlatma için çekirdek/önyükleyici optimizasyonu kullanıldı
  • Canlı imajlar amd64, arm64 için DVD, USB ve ağ önyükleme formatında sunuluyor
  • Canlı imajlarla farklı masaüstü ortamlarını seçerek deneyimleyebilir ve GUI'siz standart bir imaj da kullanılabilir
  • Kurulum Calamares ve standart Debian Installer ile yapılabilir; HTTP Boot desteği dahil birçok kurulum yöntemi kullanılabilir

[zihado]

irc'deki debian kanalında bulunanların sağlıklı olup olmadıklarını bilmiyorum. Debian potato döneminde irc'de oldukça çok zaman geçirirdim. 😄

[jungmin1237]

Docker etiketi de zaten çıktı
https://hub.docker.com/layers/library/…

[dongjinahn]

Ben de 512 MB RAM'li, aylık $2.5 VPS'te Ubuntu kullanıyordum; Debian'a geçince bunu çok beğendim. Ubuntu'dan geçince zaten alışkındım ve ayrıca daha az RAM kullanıyor.

[GN⁺]

Hacker News Yorumları

• Şu anda bu yazıyı bir Debian sisteminde yazıyorum; Debian'ı günlük kullanımımda gerçekten memnuniyetle kullanıyorum. Ubuntu eskisine göre belirgin şekilde kötüleştikten sonra Debian 6'ya geçtim ve bununla ilgili pişmanlığım olmadı. Debian'ın hem ilke hem pratiklikte dengeli olması hoşuma gidiyor: temelde özgür yazılıma odaklanırken gerektiğinde non-free yazılım veya firmware yüklemeyi de kolayca mümkün kılıyor. Paket kılavuzları, dpkg ve çok sağlam dokümantasyonu da seviyorum (dokümantasyonda Arch hâlâ birinci sırada). stable/testing paket akışları sayesinde eski sürümlerin istikrarı ile daha yeni, neredeyse stabil sürümler arasında seçim yapabiliyorum. En önemlisi, benim hata yapmadığım sürece Debian kaynaklı bir hata nedeniyle sistemimin bir kez bile bozulduğuna tanık olmadım. Ciddi şekilde önyüklenemez hale gelme veya sorun yaşama durumları oldu; bunların her birinde sebep üçüncü taraf depo eklemek ya da ayarları yanlış yapmak olmuştu.

  • Debian gerçekten iyi bir sistem, ama benim yanlış yapana kadar hiç bozulmuyor diyecek bir deneyimi paylaşmam zor. Özellikle Debian stable'da çekirdekte çok fazla yama uygulanıyor; hızlı değişen DRM alt sisteminde geri taşıma (backport) sırasında ayıklanması zor çöküşleri birkaç kez gördüm. Sürüm numarası yayın boyunca aynı görünse de, pratikte Ubuntu'da olduğu gibi sürekli yeni çekirdek (hwe hattı) kullanmak bu yama baskısını azaltıyor. Bu yüzden VM'lerde Debian, bare-metal'de Ubuntu kullanıyorum. Debian-backports deposundan çekirdek denememişim.

  • Ben de Ubuntu Server kullanırken yükseltme sorunlarıyla çok uğraşarak bırakmıştım. 75'ten fazla VPS yönetiyorum ve bakım güncellemelerinde her seferinde önyükleme sorunlarıyla karşılaşma kaygısı yaşadım. Böyle bir toparlama çoğu VPS için 1-2 saat ekstra alıyordu. 2015 civarında 8.x döneminden beri Debian'a geçtiğimde çok daha stabilim. Ben bir şeylere yanlış müdahale etmediğim sürece bir şey bozulmuyor.

  • Ubuntu'nun neden bu kadar kötüleştiğine nereden bağladığını merak ediyorum

  • Debian'ın tek eksisi, yeni bir sunucu yazılımını yükler yüklemez hemen çalıştırma eğiliminde olması. Çoğu varsayılan yapılandırma güvenli ama ayarlama yapmadan servislerin başlaması biraz ürkütücü. Red Hat ise, kurulumdan sonra benim elle başlatmama kadar servislerin açılmamasını tercih ettiği için bana bu açıdan daha iyi geliyor.

  • Debian benim sunucu işletimimin temelidir. Sunucularımı eski stable'da tutup yeni sürüm özelliklerini geçici sistemlerde test ediyorum. Bookworm'da nftables'i öğrendim, Trixie'de labwc'yi denedim. labwc, Wayland'ı desteklerken Openbox tarzı ayarlara da izin veriyor.

• Debian topluluğu gönüllülerine çok şey borçluyum. Debian ve Debian tabanlı sayısız projenin olmasını tamamen siz mümkün kılıyorsunuz. Gerçekten çok kişi ve şirket sizden kazanç sağlıyor. Kişisel olarak, bu Trixie sürümü özellikle çok heyecan verici. Kişisel yan projem olan ntfy, paket olarak eklenip Trixie'ye dahil edildi. Ancak bunu sürüm döngüsünün sonlarına doğru ntfy paketleyicisi lisans sorusu sorduğunda öğrendim; Debian paketinde web uygulaması eksik ve bazı özellikler yamalarla kaldırılmış. Stripe, Firebase, WebPush vb. çıkarımı kolaylaştırmak için build tags da ekledim, bu yüzden bir sonraki Debian sürümünde daha az yama bekliyorum. Upstream maintainer olarak neden web uygulamasının kalktığına dair net bir anlatım olmadığını görmek üzülttü; kaldırıldığını biliyorum ama bir sonraki sürümde nasıl geri eklenebileceğini bilmiyorum. apt install ntfy çalıştırıldığında web uygulaması gelmezse birçok kullanıcı hayal kırıklığı yaşar. Tavsiye veya rehber memnuniyetle kabul edilir. Kaynak kod da buna bakılabilir.

  • Paket bakıcısı, buna dair bir ekleme yaptı: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098866#10. Web uygulaması Node.js tabanlı ve bu Node.js paketleri Debian'da yok. Debian felsefesi gereği bir paketin bağımlılık kaynaklarını doğrudan pakete taşımak istenmiyor. Böyle yapmak demek, bağımlı paketleri de üretip yönetmek zorunda kalmak; bu da büyük yük demekmiş gibi.

  • Debian'de npm paket derleme işi mutlaka derlenebilir olmalı. Bu nedenle ayrı bir debian-specific package.json içinde npm bağımlılıklarını Debian paketlerine dönüştürmek, taşımak ya da ayrı paket olarak sunmak gerekiyor. Potansiyel olarak epey büyük bir iş yükü anlamına geliyor. Lockfile büyükse gerçekten çok emek istiyor. Bakıcının bunu fazla iş gördüğü sanırım. Debian yaklaşımında ntfy-web gibi ayrı bir paketle sunmak daha doğal görünüyor.

  • ntfy sayesinde çok teşekkür borçluyum. Evde Meshtastic düğümündeki olay bildirimlerini almak için her gün kullanıyorum.

  • ntfy yazılımını gerçekten çok iyi kullanıyorum.

  • Bağımlılık sorununun çözümü için, konteyner görüntüsüyle dağıtmak daha iyi bir yol olabilir.

• Debian, özgür hesaplama hayatımın güvenilir temeliydi. Condorcet oylama yöntemi, usulünce uzlaşma ve ilke temelli karar verme konusunda benden çok şey aldı. Bu projenin ve kültürünün dünyaya etkisi gerçekten ölçülemez kadar büyük. Sevgiyle kutlu olsun.

• i386 mimarisinin nihayet genel desteğinin sona erdiği duyurulmuş (en yeni çekirdek veya kurulum programı yok, 64-bit CPU'larda kullanılmalı, saf 32-bit donanım için artık yükseltme önerilmiyor). 2025 Ağustos'a kadar i386 desteğinin sürmesi iyi olmuş. Ben halen Debian 10 Buster'ı Pentium 3 tabanlı donanımda çalıştırıyordum (2024 Haziran EOL). Eski donanımlarda test edebilmek için bu kadar uzun desteklenmiş olmasına çok minnettarım. i386 ile en yeni işletim sistemini isteyen biri varsa OpenBSD'yi de değerlendirebilir.

  • 2007 civarında son Pentium 3 kullandığım zaman oldu sanıyordum ama bugün 1 dolara 100 kat hızlı bir PC bulabildiğin bir çağdayız.

  • i386, eğer Debian ports altyapısına (ör. m68k) geçerse, Debian 14 veya 15'te deneysel olarak da olsa kullanılmaya devam edeceğini düşünüyorum.

  • old stable, yaklaşık bir yıl daha destek alıyor sanırım. Yani 2025'ten sonra da tamamen bitecek demek değil.

  • Bu sadece Debian desteği için geçerli; Linux çekirdeği, orijinal Pentium sonrası 32-bit CPU'ları hala destekliyor (bazı klon çipsetler hariç).

  • 386 ile 32-bit'i karıştırmıyor musun? Normal 32-bit mimari genelde 686'dır; 386 zaten 80'lerin konusudur.

• sysvinit hala mümkün. Zaten sunucu ve masaüstünde test ettim. Belirli bir paketin bağımlılık kaynaklı sorunları nedeniyle aşağıdaki komutlarla aynı anda kaldırma/kurulum yaparak sorunu geçebilirsiniz. İlgili Debian hatasına göre systemd-sysv ve systemd'nin başına "-" koyup kaldırmak kilit nokta. Bu şekilde debootstrap ile üretilen sysvinit build'i, bookworm'dakiyle neredeyse aynı (masaüstünü de içeriyor). bookworm ya da buster'da olduğu gibi apt preferences içinde yalnızca libsystemd0'i tutup diğer systemd paketlerini priority -1 yaparsanız yeter.

  • Debian 13'te gerçekten sysvinit düzgün çalışır mı diye merak ediyorum. Yani systemd olmadan da server için sysvinit kullanmak mümkün mü diye sormak istiyorum.

  • Paylaşılan bilgiye teşekkürler. En azından lxc konteynerlerinde test etmeyi düşünüyorum.

  • Bu kadar ileri gidişi niçin yapıyorsunuz?

• x86-64 için .torrent imajını bulmak zor olabiliyor diye bağlantıları derledim
  Minimal: netinstall ISO
  Full: DVD ISO

  • Çoğu kullanıcıda DVD (full) imajına ihtiyaç olmaz. Kurulum sırasında paketleri indiren minimal netinstall CD yeterli olur.

• Trixie'de resmi olarak desteklenen 7 mimariyi derledim

  • amd64(64-bit PC)
  • arm64
  • armel(ARM EABI)
  • armhf(ARMv7 EABI hard-float)
  • ppc64el(64-bit little-endian PowerPC)
  • riscv64(64-bit little-endian RISC-V)
  • s390x(IBM System z)
    RISC-V'in gerçekten kullanılabilir donanımı pek yok ama nihayet ilk sınıf platform muamelesi görmek sevindirici. Son dönem PowerPC ve System z'nin nerelerde kullanıldığı, amd64/arm64/riscv64 dışında diğer dağıtımlarda hangi mimarinin gerçekten dağıtıldığı merakımı çekiyor.

  • Power ve z hâlâ bugün bile milyarlarca dolarlık bir işin sahibidir. Her iki mimari de özellikle finans ve bankacılıkta yaygın. IBM, z konusunda hâlâ gurur duyuyor ama Power sanki sadece ayakta kalmak için varmış gibi geliyor; bu biraz üzücü. Power mimarisi ve sistem tasarımı gerçekten çok iyi.

  • Mainframe'ler, tek bir sunucu ile onlarca yıldır kesintisiz hizmet verilecek işlevlerde yer edinmiş durumda. Hatta işlemci ve belleğe kadar bileşenler hot-swap (çalışan sistemde değiştirilebilir) oluyor, işletim sisteminden ayrı olarak donanımı sürekli izleme ve teşhis mümkün. Donanım sorunu algılanınca otomatik olarak sahibine ve IBM'e bildirim gidiyor. IBM, 2000'lerin başından beri mainframe'de Linux'u birinci sınıf işletim sistemi olarak destekliyor. Geliştirici açısından bakınca, s390x kalan son büyük-endian mimarilerden biri (SPARC hâlâ var ama bakım modunda ve Oracle sadece Solaris'le ilgileniyor), bu da endian hatalarını yakalamada işe yarıyor. Şu an kalan tek 32-bit mimariler armel ve armhf; bu sürüm armel'in son desteği oluyor (not). Yakında resmi 32-bit destek de bitecek gibi görünüyor.

  • IBM bu iki mimarinin ana dağıtımlarda düzgün çalışmasını sağlamak için ciddi efor harcıyor. Bu yüzden diğer mimarilerde ekosistemin kendiliğinden yaşatmasından çok, IBM'in desteğiyle listede kalıyorlar.

• systemd'de NIC isim yönetimi kaygısı varsa release note'u (link) okuyabilirsiniz. udevadm komutu ile yükseltme sonrası arayüz adlarının nasıl değişeceğini önceden görebilirsiniz. bond/lo arayüzleri hariç listeyi aşağıdaki tek satır komutla da alabilirsiniz. Şimdiye dek kendi testlerimde yükseltmeden dolayı arayüz adının değiştiğini görmedim. Bu yüzden yukarıdaki yöntem gerçekten ad değişimini önceden yakalıyor mu emin değilim.

  • Bu muhtemelen arayüz adlandırmasıyla ilgili en son büyük değişim. enoX etiketleri her zaman stabil kalmalı; bunu BIOS (ACPI tabloları vb.) hangi portun hangi ID olduğunu söylediği için gereksiz değil. ensX ise PCIe slotuna göre; fakat bir PCIe hiyerarşisinde bir slota birden fazla NIC gelebileceği için karmaşıklık oluyor. Systemd bu istisna durumları çözmek için arayüz adlandırma mantığını birkaç kez değiştirmiş. Bir dönem PCIe slot numarası dolaylı okunarak çakışma yaşanmıştı, bunu systemd 257 giderdi.

  • systemd'nin Predictable Network Interface Names özelliğini güncellemeden önce kapattıysanız yine de arayüz adı değişebilir mi?

• Slink'ten beri Debian kullanıyorum. Hâlâ apt-get ... yazmadan geçemiyorum, yine de her şey bir şekilde çalışıyor. 25 yılı aşkın süredir yükseltmelerde büyük-küçük sorunlar oldu ama bununla harcanan zaman/çaba diğer Linux veya kapalı kaynak yazılımlarla kıyaslandığında gerçekten epey azdı. Tek bir üzüntüm: topluluğa daha fazla katkıda bulunamamışım. Debian'ın en büyük avantajı, kullanıcının en azından sistem davranışını belli seviyede anlamasını gerektirmesi. Bu yüzden "olabildiğince sade ama aşırı sadeleştirmeden kaçınan" felsefeyi iyi uyguladığını düşünüyorum.

• Debian'ın en büyük artılarından biri, stable'dan stable'a 15 dakikadan az sürede yükseltilebilmesi. İlk sistemim, paket indirme ve yeniden başlatmayla birlikte 10 dakikadan daha kısa sürede göç etti. Özellikle güçlü bir bilgisayarım ya da yüksek bant genişlikli bir ağım yoktu; 50 Mbps'lik bir mini PC kullanıyordum.