Debian, 2038 sorununu beklemeden tamamen 64 bit zaman düzenine geçiyor

• Debian, Y2K38 (Unix Epochalypse) sorununu önceden engellemek için bir sonraki sürüm Debian 13'ten itibaren 32 bit mimarilerde de 64 bit time_t kullanımını resmileştiriyor
• Mevcut 32 bit time_t sınırlaması nedeniyle 19 Ocak 2038'den sonra zamanın 1900'e geri dönmesi gibi bir durum yaşanabileceğinden, bu sorunun daha fazla ertelenmemesine karar verildi
• 64 bit donanım zaten güvenli olsa da, gömülü sistemler, IoT ve benzeri maliyet hassasiyetine sahip 32 bit cihazlarda Debian talebi sürdüğü için önleyici adım ihtiyacı vurgulanıyor
• Toplam 6.429 pakete dağılmış time_t türü için, ABI uyumluluğunun bozulması göze alınarak eşzamanlı geçiş içeren büyük ölçekli bir çalışma yürütüldü
• i386, hurd-i386 gibi bazı eski destek mimarileri istisna olarak kalırken, 64 bit time_t tabanlı yeni bir x86 (i686) mimarisinin eklenme olasılığına da değiniliyor

---

Debian'ın Y2K38 hatasına yanıtı: 64 bit zamana geçiş

• Debian, yaklaşan Y2K38 ya da Unix Epochalypse sorunundan kaçınmak için, desteklenen en eski donanımların bir bölümü dışında tüm ortamlarda 64 bit zamana geçiyor
• Bununla, 19 Ocak 2038'de ortaya çıkması beklenen 32 bit signed int aralığının aşılması nedeniyle oluşan zaman değeri hatası önleniyor

Y2K38 ve Unix Epochalypse sorununun arka planı

• Y2K38 sorunu, 1 Ocak 1970'ten bu yana geçen saniyeleri 32 bit signed int ile ifade eden Unix sistemlerinde, 2038 sonrasında taşma meydana gelerek zamanın 1900 gibi geçmiş yıllara yanlış dönmesi olayıdır
• Bu durum, geçmişteki Y2K (2000 yılı sorunu) gibi kısa veri biçimi seçimine dayanan mimari bir karardan kaynaklanır
• Y2K döneminde geliştiricilerin önceden aldığı önlemler sayesinde büyük bir kaos önlenebilmişti
• 64 bit donanım için yazılımlar zaten güvenli, ancak Debian hâlâ gömülü, düşük özellikli ve eski ortamlarda yaygın biçimde kullanılıyor

Debian'ın başlıca adımları

• Debian 13 "Trixie" sürümünden itibaren tüm ana mimarilerde 64 bit time_t varsayılan olarak uygulanacak
• 64 bit donanım zaten güvenli olsa da, sorunlar özellikle 32 bit işlemci tabanlı gömülü cihazlar ve eski donanımlarda sık görülüyor
• Bu tür ekipmanlar, otomotiv kontrolü, IoT, TV ve yönlendirici gibi maliyet hassasiyeti yüksek ve yüksek adetli sevkiyat yapılan alanlarda hâlâ kullanılıyor
• Yeni cihazların çoğu OpenEmbedded, Alpine, Android, Gentoo gibi kendi derlenen Linux dağıtımlarını kullansa da, Debian tabanlı gömülü cihazların kullanım alanlarının önümüzdeki yıllarda da süreceği öngörülüyor

Uygulama ve değişiklikler

• time_t değişkenleri ilgili kodlara 6.429 pakete dağılmış durumda olduğundan büyük ölçekli bir çalışma gerekti
• Bu değişiklik ABI (Application Binary Interface) uyumluluğunu bozabileceği için, ilgili tüm kütüphane ve paketlerde eşzamanlı olarak düzenleme yapıldı
• Bakım ekibine göre bu çalışma tamamlandı ve yeterince test edildi

İstisnalar ve gelecek planları

• i386 portu (mevcut x86), mevcut ikili dosya çalıştırma uyumluluğu amacıyla 32 bit time_t kullanmayı sürdürecek
• i686 mimarisi için 64 bit zaman ve daha modern ISA (Instruction Set Architecture) desteği ayrıca tartışılabilir
• hurd-i386 portu, çekirdek desteğinin yetersizliği nedeniyle dönüştürülmeyecek; bunun yerine hurd-amd64'e geçiş planı ilerliyor

Geliştiriciler için notlar

• Geliştiriciler, yazılımlarının 64 bit zaman değişkenlerine geçişle bozulup bozulmadığını Debian wiki'de anlatılan yöntemlerle test edebilir
• Ayrıntılar ve teknik belgeler Debian wiki üzerinde sunuluyor

[GN⁺]

Hacker News görüşleri

• Steve Langasek, hayatının son birkaç yılında bu sorunu çözmeye odaklanıp büyük ilerleme sağladı; bundan sonra 64 bit time_t gördüğümde onu hatırlayacağım
  • Bu güzel haberi tekrar paylaştığın için teşekkürler, Steve'i özlüyorum; Joey hâlâ Debian faaliyetlerine devam ediyor mu merak ediyorum
• Y2K sorunu (iki basamaklı yıl gösteriminden kaynaklanan 2000 yılı sorunu) konusunda, o dönemde 2 bayt tasarruf etmek çok değerliydi; 70'ler ile 90'lar arasındaki yazılımlar hızla değişiyordu, bu yüzden 5 yıldan uzun kullanılmaları beklenmiyordu; fazla küçümseyici bir bakış açısı gibi geliyor
  • Bugün bile iki basamaklı yıl çok kullanılıyor; örneğin kredi kartı son kullanma tarihi (mm/yy) kısa yazmak daha pratik olduğu için iki basamaklı yıl kullanılıyor, kart ömrü için yeterli ama 2100'de dönüşüm sorunu çıkabilir; Y2K'nin büyük kısmı UI sorunlarından kaynaklanıyordu (iki karakterlik text field, +1900 hardcode edilmesi vb.); bizzat gördüğüm Y2K hatası, bir internet forumunun 1999'dan 19100'e geçmesiydi (basit bir çıktı hatası); Y2K sadece COBOL'un sorunu değildi
  • Böyle durumlarda “erken optimizasyon” aslında faydalı olurdu; tarihi 1900 yılında 0 olan basit bir int değeriyle temsil etselerdi daha da fazla bayt tasarrufu sağlanabilirdi; 3 bayt ile 1900'den yaklaşık 44.000 yılına kadar, 2 bayt ile de yaklaşık 2070'e kadar kapsanabilirdi
  • İnsanların karıştırdığı nokta, 2 bayt daha eklemek değil 2 karakter daha eklemek zorunda olmalarıydı; COBOL'da ister sayı ister veri olsun, karakter boyutu kadar sabit genişlikte yer ayrılıyordu, bu yüzden 4 basamaklı yıl için 4 karakterlik alan gerekiyordu; bu alan boyutları veri erişiminde, UI'da, batch dosyalarında, ara dosyalarda, aktarım dosyalarında vb. tüm programa hardcode edilmişti
  • Y2K'den hemen önce büyük bankaların hisselerinin çakmasını bekleyip yüklü miktarda put opsiyonu alan tanıdıklarım vardı ama gerçekte neredeyse hiçbir büyük olay yaşanmadı
  • 80'lerin sonlarında COBOL ile çalışırken yalnızca 1 basamaklı yıl saklayan bir program gördüm; yapısını anlatınca tuhaf gelmişti ama kayıtlar her 4 yılda bir otomatik silindiği için kullanımda sorun yaratmıyordu, hangi yıl olduğu her zaman açıktı
• 64 bit time_t Epochalypse'ı çözecek ama tüm sistemler basitçe 64 bit saniyeye geçmiyor; ext4 zaten 30 bit kesir çözünürlüğüne (nanosaniye düzeyi) ve 34 bit saniye çözünürlüğüne geçti ama birkaç yüzyıl sonra yine sorun çıkacak; bir gün 64 bit saniye + 64 bit kesirden oluşan 128 bit zaman damgasında karar kılınacağını tahmin ediyorum, o zaman insanlık tarihindeki öngörülebilir geleceğin tamamı kapsanabilir
  • 64 bit saniye zamanı yaklaşık 585 milyar yıla denk geliyor, WolframAlpha hesabı
  • 64 bit kesir çözünürlüğü bile yetmeyebilir; Planck zamanına yaklaşmak için 144 bite kadar çıkmak gerekir
  • ext4 zaman damgalarını merak ediyordum, zfs ve btrfs dosya sistemlerinin zamanı nasıl işlediğini de merak ettim; btrfs muhtemelen 64 bit kullanıyordur, zfs'nin de (ext4 ile karıştırıyor olabilirim) benzer olmasını bekliyorum
• Debian'ın Y2K38, yani Unix Epochalypse sorununu çözdüğü söyleniyor ama aslında i386 dışındaki tüm 32 bit portlarda time64_t geçişi zaten tamamlandı; yalnızca i386 eski ikili uyumluluk nedeniyle istisna, diğerlerinin hepsi, m68k dahil, değiştirildi; bizzat m68k, powerpc, sh4 ve hppa geçişini yaptım
• time_t bir değişken değil, bir veri tipidir
  • Haberde aktarılan içerik Debian wiki'sine dayanıyor; özgün metinde açıkça şöyle deniyor: “time_t gerçekten her yerde karşımıza çıkıyor. 35.960 paketin 6.429'unun kaynak kodunda yer alıyor. time_t içeren ve ABI üzerinden açığa çıkan yapıları olan paketlerde, tüm ABI aynı anda migrate edilmek zorunda.” Wiki bunu habere göre daha net açıklamış
  • “For everything” ifadesiyle armel, armhf, hppa, m68k, powerpc ve sh4 kastediliyor, i386 değil; i386'in geleceği yok ve asıl amaç eski ikilileri/dinamik kütüphaneleri çalıştırmak olduğu için bunun bozulması istenmiyor
  • “Debian 13 Trixie çıktıktan sonra uygulanacak” ifadesi aslında bunun Trixie'ye dahil olduğu anlamına geliyor
• Keşke komut satırı uzunluk sınırı da sınırsız/dinamik hale getirilse; 96GB belleğim olmasına rağmen sık sık “argument list too long” hatası alıyorum ve sinir bozucu oluyor
  • Çekirdeği yeniden derleyerek komut satırı uzunluğu sınırını (yaklaşık 100 bin karakter) kaldırabilirsin, Stack Overflow bağlantısı; ama bu bana temel sorunu çözmek gibi gelmiyor, 4k JPEG kadar uzun argümanları nerede kullanacağını merak ediyorum
  • RLIMIT_STACK değerini artırmak yeterli; örneğin ulimit -s 4000 4MB stack demek, daha da artırmak için /etc/security/limits.conf dosyasını düzenleyip yeniden giriş yapmak gerekir
  • Electron içine paketleyip http post JSON isteğiyle göndermek olmaz mı?
  • MAX_ARG_STRLEN değerini yeniden tanımlayıp çekirdeği yeniden derleyebilirsin; sayfa boyutu daha büyük makineler kullanmak da bir yöntemdir (ör. 64k sayfa boyutlu RHEL Arm çekirdeği), ama komut tamponu yerine prosesler arasında veri taşımak için pipe kullanmak çok daha kolay
  • Dosya yolu sınırı da benzer bir sorun; bazı build sistemlerinde (Debian + python + dh-virtualenv vb.) yollar çok uzayabiliyor, bunu olduğu gibi kabul etmek daha rahat olurdu
• 64 bite geçilse bile bir gün yine sınıra ulaşılacak; 4 Aralık 292277026596 saat 15:30:07'de (UTC) insanlık ne yapıyor olacak merak ediyorum
  • Muhtemelen o zamana kadar IPv6'nın tam benimsenmesinin 100. yılını kutluyor oluruz
  • 5 milyar yıl içinde Güneş kırmızı deve dönüşecek ve Dünya'nın yüzeyi tamamen buharlaşacak
  • O zamana kadar daha iyi bir takvim sistemine geçmiş olmayı umuyorum, tabii zaman damgası sorunu yine kalacak
  • 128 bit zamana geçeriz
  • RFC 2550 (Y10K & beyond) uygulanabilir görünüyor; 1 Nisan 1999'da yayımlanmış
• OpenBSD 5.5 aynı değişikliği uygulayalı 11 yıl olmuş bile, OpenBSD 5.5 sürüm notları
  • Herkesi geçmiş bir örnek; 90'larda OS/2'nin 32 bit API'sinin 64 bit zaman döndürdüğünü fark edip kendi 64 bit time_t kullanan C++ standart kütüphanemi yazıp kullanmıştım
  • Konu biraz farklı ama böyle zamanlarda Linux yerine sunucularımı OpenBSD'ye geçirme isteği geliyor
  • OpenBSD uyumluluğa daha az kafa yorabiliyor ve kullanıcı sayısı da çok daha az, bu da değişikliklerde hata veya edge case ihtimalini azaltıyor
• “Debian artık yeterince tamamlanmış ve test edilmiş durumda, bu yüzden Trixie çıktıktan sonra geçilecek” deniyorsa, bu Trixie'de yer almayacağı anlamına mı geliyor diye merak ediyorum
  • Trixie sürüm notlarında yer aldığı yazıyor, Trixie sürüm notları
• Y2K38'e Unix Epochalypse dendiğini ilk kez duyuyorum ama sevimli bir ad, yayılabilir gibi
  • Wikipedia Year 2038 Problem maddesinde de bu isim geçiyor, 2017'den beri şaka yollu kullanılıp yayılmış
  • epochalypse-project.org diye bir proje de var
  • “it’s kind of fetch” ifadesinde Mean Girls filmine bir gönderme var gibi
  • Epochalypse'a yaklaşık 12 yıl 5 ay 22 gün 13 saat 22 dakika kaldı