Rust zorunlu bağımlılığı, Mayıs 2026'dan itibaren Debian APT'ye geliyor

• Debian'ın APT paket yöneticisine Mayıs 2026'dan sonra Rust tabanlı kod ve bağımlılıklar dahil edilecek
• İlk aşamada Rust derleyicisi, standart kütüphane ve Sequoia ekosistemi entegrasyon kapsamına giriyor
• .deb, .ar, .tar dosya ayrıştırıcıları ile HTTP imza doğrulama kodu, bellek güvenliği ve birim testlerinin güçlendirilmesi açısından başlıca iyileştirme alanları
• Rust araç zinciri olmayan portların 6 ay içinde Rust ortamı kurması veya desteklerinin sonlandırılması (sunset) gerekecek
• Bu adım, projenin genel olarak modern araçlar ve teknolojilere geçişi için atılıyor; eski donanım uyumluluğunun ilerlemenin önüne geçmemesi hedefleniyor

---

APT'ye Rust kodu ekleme planı

• APT'ye Rust kodu ve sert bağımlılık (hard dependency) Mayıs 2026'dan sonra eklenecek
  • Uygulama zamanı Mayıs 2026 sonrasıdır; bundan önce devreye alınmayacak
• İlk entegrasyon kapsamı Rust derleyicisi, standart kütüphane ve Sequoia ekosistemi ile sınırlı

Kod kalitesi ve güvenliği artırma amacı

• .deb, .ar, .tar dosya ayrıştırma kodu ile HTTP imza doğrulama kodu, Rust geçişinin başlıca hedefleri
  • Bu alanların bellek güvenli bir dilin ve güçlendirilmiş birim test yapısının avantajlarından büyük ölçüde fayda sağlayacağı belirtiliyor

Port bakımcılarına yönelik gereksinimler

• Rust araç zinciri olmayan portlar 6 ay içinde Rust ortamı kurmak zorunda
  • Aksi takdirde ilgili portun sonlandırılması (sunset) söz konusu olabilir

Projenin yönü

• Debian projesinin modern araçlar ve teknolojileri kullanarak gelişmesi gerektiği vurgulanıyor
  • Eski donanım veya retro bilişim cihazlarına uyma çabasının ilerlemeyi geciktirmemesi gerektiği açıkça ifade ediliyor

Diğer bilgiler

• Gönderen, Debian ve Ubuntu çekirdek geliştiricisi Julian Andres Klode
• E-posta, Debian geliştirici e-posta listesi debian-devel üzerinde yayımlandı
• Ek dosya olarak PGP imzası (signature.asc) bulunuyor
• Ek teknik ayrıntılar veya takvim değişikliklerine dair bir ifade yer almıyor

[GN⁺]

Hacker News görüşleri

• Görünüşe göre zamanı sonunda geldi. Güvenilmeyen veri ayrıştırma kodunu hâlâ C ile tutmak, zaman geçtikçe büyüyen bir teknik borç.
  Rust, C'den yazması çok daha zor değil ve dil tasarımı ile kod güvenliği konusunda bugünkü bilgimizle C'yi yeniden yapsaydık ortaya çıkabilecek türden bir dil.
  32 bit x86 desteği pratik gerekçelerle bırakılabiliyorsa, bu mimariler için de aynısı geçerli. Gerçekten sürdürmek istiyorsanız Rust toolchain backend'ini kendiniz yazmanız gerekir

  • Şu anda temel sistemde çekirdek uygulamalar için izin verilen diller kabaca C, C++, Shell(bash), Perl ve Python. Python yaklaşık 20 yıl önce eklendi ve Rust, C'nin rolünü değiştirecek kadar ona yeterince yaklaşan ilk dil.
    Go buna en çok yaklaşandı ama systemd gibi çekirdek bir sistemde kullanılacak kadar hiç tartışılmadı. Geçmişte C++, Python ve Perl eklenirken de böyle tartışmalar olup olmadığını merak ediyorum
  • “.deb, .ar, .tar ayrıştırıcıları ve HTTP imza doğrulama kodu bellek güvenli bir dilden fayda görür” deniyor ama son 30 yılda olgunlaşmış kodları sırf yeni bir dilde yeniden yazmanın ne gibi somut bir fayda sağlayacağından emin değilim.
    Zaten sahada kanıtlanmış kodu atıp yerine yeni uyumluluk sorunları ve hatalar üretmek gerçekten buna değer mi diye düşünüyorum
  • Eski C kodundaki güvenlik sorunlarını çözmek için daha pratik bir yaklaşım olarak Fil-C projesi var. C'yi fiilen yönetilen bir dil gibi hâle getirerek yeniden yazma ihtiyacını azaltıyor
  • Bu sadece bellek güvenliği meselesi değil. C topluluğunun yaşlanması nedeniyle bakım yapacak insan bulmak zorlaşıyor. Bizim ekip de tüm C/C++ kodunu başka dillere taşıyor. C/C++ geliştiricilerinin çoğu 40'lı yaşlarında ve iş değiştirmeye pek istekli değiller
  • Rust'ın C'nin modern bir yeniden icadı olduğu iddiasına katılmak zor. Örneğin COSMIC masaüstünün saat widget kodu, benzer karmaşıklıktaki C koduna (GNU coreutils gibi) kıyasla çok daha zor okunuyor

• Çekirdek sistemi Rust ile yeniden yazma eğilimi güçlü ama eski araçları yeniden yazmanın güvenliği gerçekten artırıp artırmadığı şüpheli.
  Yeni sistemleri devreye almanın zor olduğunu anlıyorum ama yine de hâlâ telgraf çağından kalma tasarım kararlarının katman katman birikmesiyle oluşmuş bir yapıyı koruyormuşuz gibi geliyor

  • Bu tür yeniden yazımlar için iki gerekçe duyulabiliyor.
    Birincisi, eski C/C++ kod tabanlarıyla uğraşmak isteyen yeni katkıcı neredeyse yok. Rust'a taşınınca yeni geliştirici çekmek daha kolay oluyor.
    İkincisi, güvenilirlik kullanım sıklığıyla sınanır ama güvenlik ancak saldırılarla sınanır. Eski kodun bütün saldırı vektörlerinden geçtiğini varsaymak zor. Bu yüzden önleyici güvenlik güçlendirmesi için güçlü bir gerekçe var
  • uutils/coreutils MIT lisanslı, GNU coreutils ise GPL, yani lisans farkı var. Şirketler açısından bu önemli bir nokta olabilir
  • Birilerinin öğrenmesi gerektiğine göre, basit ve test etmesi kolay projeleri alıştırma amacıyla yeniden yazmak bence makul. Ama ortaya çıkan sonucun aslıyla yer değiştirmesi ayrı bir tartışma

• Debian posta dizisine göre Rust, Debian'ın çoğu sürüm mimarisinde zaten zorunlu.
  İlgili e-postada yalnızca alpha, hppa, m68k ve sh4 istisna olarak anılıyor. Bu mimarilerin geleceğinin ne olacağını merak ediyorum

  • İnsanların bu kadar eski makineleri hâlâ kullanıp kullanmadığını gerçekten merak ediyorum. Çoğu 20 yıldan eski donanım.
    Rust, m68k için Tier 3 hedefi sunuyor ama diğer mimariler için yok. Gerçek kullanım senaryolarını merak ediyorum
  • Debian Supported Architectures'a göre bu platformlar gayriresmî durumda.
    32 bit x86 ve MIPS çıkmışken bunların kalmış olması şaşırtıcı. Bende de biraz nostalji var ama gerçek kullanım alanlarını pek bilmiyorum
  • m68k için zaten bir LLVM portu var, dolayısıyla Rust uygulaması mümkün. alpha, hppa ve sh4 için LLVM backend'leri de eğitsel birer referans olarak değerli olurdu.
    Eskiden LLVM'de bir DEC Alpha backend'i vardı ama bu çok eski bir mesele
  • Ubuntu açısından bu mimarilerin ticari değeri yok
  • Tamamen demode oldukları için son desteklenen sürümde bırakılabilirler ya da kendi dağıtımlarını yapabilirler. Rust desteği eklemek gerçekçi değil

• Rust topluluğunun mevcut projelere sızmak yerine yeni ve modern teknolojiler üretip bunu kanıtlamasını isterdim.
  Redox gibi bağımsız projeler buna örnek ama neden bu tür girişimler daha fazla desteklenmiyor, yazık

  • Bu, Debian'ın Rust bağımlılığı ekleme yönündeki resmî kararı. Dışarıdan Rust hayranlarının dayatması değil.
    Elbette “Rust ile yeniden yazın” diyen saldırgan hayranlar var ama bu durum ondan farklı
  • ripgrep tam da buna örnek. Sıfırdan yapıldı ve insanlar gerçekten seviyor

• Rust standart kütüphanesini kullanmakta sorun yok ama basit bir deb ayrıştırıcısı derlemek için 500 cargo paketi çekmek istemem

• Rust-for-GCC portu kararlı hâle gelene kadar beklemek mantıklı olabilir.
  Çekirdek de GCC desteği gelene kadar Rust'ı zorunlu yapmayı planlamıyor.
  Birden fazla uygulama ortaya çıkarsa dil daha az kırılgan hâle gelir.
  Ama mimari desteği şimdi keserseniz, ileride Rust toolchain'i geldiğinde geri dönüş süreci karmaşıklaşabilir

  • Aslında bu mimariler zaten 10 yıldan uzun süredir Debian'ın dışında. Bu değişiklikle yeni düşen bir şey yok
  • Resmî destek yok ve bakım bireylerin boş zamanında yaptığı bir iş düzeyinde. Bir şirket uzun vadeli bakım üstlenmedikçe geri dönmeleri zor
  • GCCRS henüz libcore bile derleyemiyor ve Rust 1.50 seviyesinde. Genel amaçlı bir derleyici olması için daha yıllar var gibi görünüyor.
    Hatta rustc_codegen_gcc'nin daha önce kararlı hâle gelmesi daha olası
  • Portlar Debian resmî sürümüne dahil edilmiyor, yalnızca unstable kanalı üzerinden dağıtılıyor

• Debian Rust tartışma e-postasının yazarının keepassxc paket bakımcısı olduğunu hatırlatmak isterim.
  Geçmişte de upstream geliştiricilere ve kullanıcılara karşı sert davranışlar sergilediğine dair diziler var

  • Ben de o e-postayı görünce hemen kontrol ettim, eski tartışma dizisini hatırlayıp güldüm
  • Açıkçası kullandığı ifadeler sert ama hakaret değil, doğrudanlık içeriyor. Bence gereksiz drama
  • HN gönderisinin kendisi saldırgan değil ama bazıları aşırı alınıyor gibi
  • Bu kültür özgür yazılım dünyasında yaygın. Gerçek kullanıcılar yerine idealize edilmiş kullanıcı tipinin peşinden gitme eğiliminin GNOME 3 ve Mozilla dönemlerinden beri sürdüğünü düşünüyorum

• Bir insanın fikrinin zamanla nasıl değiştiğini görmek ilginç. Önceki açıklama bağlantısı

  • Zamanla fikrini değiştirebilmek güzel bir tavır
  • Rust'ın APT'ye girişi de coreutils geçişinde olduğu gibi yönetsel bir karar olabilir

• Rust'ın sadece bir hype olduğunu düşünüyorum. Gömülü dünyada hâlâ C kral.
  Çevremde gerçekten Rust kullanan ya da değerlendiren kimseyi görmedim

  • “Benim çevremde yok” diyerek sonuca varmak zor. Rust kullanan çok sayıda gömülü geliştirici var
  • AWS içinde EC2, IAM, DynamoDB ve S3 gibi çekirdek servisler Rust ile yazılıyor.
    Performans ve bellek verimliliği korunurken geliştirme hızı da yüksek.
    Tek dezavantajı ikili dosya boyutu. Rust'ın geleceği bana göre zaten sağlam biçimde yerleşmiş durumda
  • Rust gömülünde de güçlü ama üretici desteği yetersiz olduğu için donanıma özgü başlangıç işi fazla.
    Yine de cazibesi yalnızca bellek güvenliği değil, dilin ve toolchain'in genel kalitesi
  • avr-rust, esp-rs, cortex-m gibi projelerle gömülü ekosistem de yavaş yavaş değişiyor
  • Microsoft, Google gibi şirketlerde de Rust tartışılıyor ve gerçek ürünlerde kullanılıyor

• Çok dilli (polyglot) ortamların daha fazla sorun çıkardığını düşünüyorum.
  Python, Node, Go, Rust gibi her biri için ayrı toolchain ve paket yöneticisi gerekiyor; bu da karmaşıklığı artırıyor.
  Node ile buffer overflow sorununu ortadan kaldırdık ama bu kez tedarik zinciri saldırıları arttı.
  Bence sıfırdan başlamak daha iyi; Rust'ı tam anlamıyla kullanmak istiyorsanız Redox OS'ye katkı vermek daha doğru

  • Gerçekte her dilin kendine özgü artıları ve eksileri var ve Debian, pratik bir işletim sistemi olarak çeşitli dilleri desteklemek zorunda.
    Her şeyi tek bir dilde yeniden yazmak gerçekçi değil, Redox'u öne çıkarmak da tersine verimsiz olabilir.
    Rust zaten yeterince kanıtlanmış bir dil ve C'ye kıyasla değişiklik yaparken kendini vurma olasılığı daha düşük derlenmiş bir dil olarak değer taşıyor.
    Eski mimarileri bırakmak da çok uç bir karar sayılmaz
  • Debian gibi büyük bir projede seçenekleri geniş tutmak mantıklı. Rust eklemek gayet anlaşılır bir karar.
    Hangi dilin çıkarılıp hangisinin ekleneceğine Debian bakımcıları karar vermeli
  • Linux, karmaşıklıkla savaşmayı zaten onlarca yıl önce bıraktı