• 2038 yılında bazı posıx zaman gösterimini kullanan 32-bit sistemlerin çökmesine yol açacak bir yazılım hatasıdır.
    hata, sistem zamanını 1 ocak 1970 tarihinden beri saniye bazında hesaplayan ve 32-bitlik unıx ve türevi sistemlerde 19 ocak 2038 salı günü saat 03:14:07'de sayacın başa dönmesiyle sistem tarihinin 13 aralık 1901 20:45:52'yi göstermesiyle ortaya çıkacaktır.
    son yıllarda bazı çözüm yöntemleri geliştirilse de hiçbiri basit ve uygulanabilir olamamıştır. ancak 64 bitli sistemlere geçişin 2038 yılına kadar tamamlanacağı ve böylece hatanın kendiliğinden ortadan kalkacağı düşünülmektedir.

    alıntı
    buradan görebilriz
  • hala cobol ile yazılmış programları kullanan firmaların olduğu finans sektörü ve hala dos kullanan havacılık, savunma gibi anlık olarak dahi kapatılması mümkün olmayan sektörler ile her şeyi "akıllı" yapma amacıyla öteye beriye 32 bit işlemci tarafından işletilen sensör yerleştirmeyi sağlayan iot akımı ve akıllı sayaçlar, akıllı x'ler gibi insanların "ya bunun işlemcisi 32 bit olsa ne olur 64 bit olsa ne olur?" dedikleri cihazlarda kendilerini gösterecektir.

    birçok alanda muhtemelen y2k vakasında olduğu gibi koda "yıl 1970'ten küçükse yıla x kadar yıl ekle" denilerek sorun yaklaşık bir 50 yıl ötelendikten sonra "ee artık hala daha 32 bit işlemci kullanan varsa da artık kendisi bilir" denilen zamanlara bırakılacaktır.
  • posix kullanan 32bit sistemlerin 2038 yılına kadar kalabileceğini düşünmüyorum. insanları etkilemeyecektir y2k kadar. sorunun sebebi saatin binary gösterimi arttıkça eski haline dönmesi ve sayacın sıfırlanması. yani saniye bazında hesaplama yapmayan 32bit sistemde sıkıntı çıkarmazdı.

    temel olarak baktığımızda temel programlama sorunları var mesela xx99'dan sonra xx00'a geçme. yanlış bir yaklaşım yüzünden xx100'e geçebilirsiniz. bazı şirketler mesela y2k problemini önlemek için geçerli tarihin işlemlerin kesintiye sebep olmamasını kural haline getirmişlerdir year 2000 conformity requirements.

    eski sistemlerdeki bu sorunlara aslında donanım kısıtlamasından dolayı böyleydi şu anki 64bit sistemler ile böyle bir sıkıntımız yok.

    benzer bir bilişim sektörü sıkıntısı ise ipv4protokolündeki ip limiti sıkıntısıdır bu probleme de bilişimciler farklı çözümler getirmişlerdir (bkz: cgn ip) fakat kesin çözüm ipv6dır.
  • hazır dinciler kıyamet beklerken,
    professor ali demirsoy 2035'i işaret ediyorkeen

    cool baby mi desek.
  • 2038 yılında bilişim sistemlerini etkileyebilecek bu problemi açıklamaya çalıştım ben de.

    https://youtu.be/uml6vmd5ui4

    bundan önce daha iyi anlaşılması adına bahsetmek istediğim y2k, yani 2000 yılı bug'ı.

    bildiğiniz gibi bilgisayar sistemleri 1950'li yıllarda geliştirilmeye başlandı ve günümüze kadar devam etti. bu süreçte birçok program yılları yalnızca son iki basamakla temsil ederek 2000 yılını 1900'den ayırt edilemez hale geldi. bu da 1 ocak 2000'de bir çok sistemde problemler yaşanacağına dair kehanet oluşmasına neden oldu.

    peki ne oldu 1 ocak 2000 günü?

    aslında çok büyük bir olay yaşanmadı, avustralyada otobüslerde bilet kontrolü yapılan makinalar bozuldu, japonyada bir kaç cep telefonu markasında hatalar yaşandı, amerikada bazı slot makinaleri çalışamaz hale geldi. yani ölümcül bir olay yaşanmadı bilişim sistemlerinde. korkulduğu gibi olmadı yani.

    2038 yılı problemi ise, birçok dijital sistemde zamanı 1 ocak 1970' 00:00:00 utc'den* bu yana geçen saniye sayısı olarak temsil etmek ve onu işaretli bir 32-bit tamsayı olarak saklamakla ilgilidir. bu tür uygulamalar, 19 ocak 2038 utc 03:14:07'den sonraki süreleri kodlayamaz. y2k sorununa benzer şekilde, yıl 2038 sorunu, zamanı temsil etmek için seçilen yetersiz sayıda bit (rakam) nedeniyle oluşur.

    nedenleri

    1 ocak 1970'den bu yana, işaretli* bir 32-bit tamsayı kullanılarak depolanabilen en son zaman, 19 ocak 2038 salı günü 03:14:07'dir (2^31 - 1 = 1 ocak 1970'ten sonra 2147483647 saniye).

    bu tarihten sonraki süreyi artırmaya çalışan programlar, değerin dahili olarak negatif bir sayı olarak saklanmasına neden olur ve bu sistemler, 13 aralık 1901 cuma günü 20:45:52'de (1 ocak 1970'den 2147483648 saniye önce) meydana geldiği şeklinde yorumlayacaktır). bu, sayacın kullanılabilir ikili rakamların veya bitlerin bittiği ve bunun yerine işaret bitini çevirdiği tamsayı taşmasından kaynaklanır.

    hangi sistemler savunmasız?

    öncelikle embeded olarak çalışan ve özellikle tarihleri hesaplama veya loglama için kullanan sistemler. özellikle uçuş sistemlerinde ve otomobillerde yoğun olarak kullanılıyor bu tarz sistemler. bu sistemlerdeki abs gibi kilitlenme önleyici fren sistemleri, esc ve esp gibi elektronik stabilite kontrolü yapan kısımlar ve gps alıcıları kullanıyor olabilir. ancak bu, tüm bu sistemlerin y2038 sorunundan etkileneceği anlamına gelmez, çünkü bu tür birçok sistem tarihlere erişim gerektirmez. bunu yapanlar için, mutlak saatler/tarihler değil de, yalnızca saatler/tarihler arasındaki farkı izleyen sistemler hesaplamanın doğası gereği büyük bir sorun yaşamayacaktır.

    ayrıca mysql'in 2021 ağustos sürümünden önceki versiyonlarında, unix_tımestamp fonksiyonu 19 ocak 2038 salı günü 03:14:07'den sonra 0 döndürüyormuş.

    problemi veri yapıları hangileri?

    günümüzde kullanılan birçok veri yapısı, gömülü 32 bitlik zaman temsiline sahip. ama tam bir liste vermek neredeyse imkansız.

    dosya sistemleri (birçok dosya sistemi, süreleri temsil etmek için yalnızca 32 bit kullanır), binary dosya biçimleri (32 bit zaman alanlarını kullanan), veritabanları (32-bit zaman alanları olan), unix_tımestamp() benzeri komutlara sahip sql gibi veritabanı sorgu dilleri vs..

    kısaca 32-bit zaman gösterimleri içeren veri yapılarını kullanan herhangi bir sistem risk arz edecektir.

    peki çözümü nedir?

    2038 yılı sorunu için evrensel bir çözüm yoktur. örneğin freebsd ve openbsd gibi işletim sistemleri bazı değişiklikler yapmışlar ama bazı değişiklikleri de backward compatibility nedeniyle yapamamışlar.

    neden umursayalım ki daha 17 sene var?

    bazen gelecekte bazı şeyler olur ve bunun ne zaman olacağını bilmek isteriz. bazen, 17 yıllık bir ipotek gibi, 17 yıldan fazla bir süre sonra planlanması gerekir. bu sorun zaman geçtikçe daha da kötüleşecek, çünkü yazılım geliştirici olmanın en sinir bozucu yanlarından biri, her zaman upgrade yapmayan birilerinin olmasıdır. ve her zaman, asla upgrade yapmayan bir çok insan olacak, emin olun.

    64 bit işlemcileri kullanmaya başladığımızda sorun ortadan kalkacak, değil mi?

    64 bit işlemci kullanmanız, 2038 yılı bug'ı konusunda temiz olduğunuz anlamına gelmez. örneğin, yeni apple bilgisayarınızda 64 bit işlemci var ama işletim sistemi hala 32 bit tam sayılar ve 32 bit time_t ile çalışıyor.

    tamsayı boyutunu değiştirdiğinizde, tüm yazılımınızı yeniden derlemeniz gerekir. o zaman mac uygulamalarının 32 bit ve 64 bit sürümleri göndermesi gerekir. ancak bu durum hem geliştirici, hem de kullanıcı için acı verici ve sorunlu bir süreç.

    ve sırf yeni bir 64 bit işlemci kullanıyor olmanız, herkesin kullanacağı anlamına da gelmez. 32 bit işlemciler sadece pc'lerde ve eski donanımlarda değil, arabanızda, telefonunuzda, saatinizde, tv'nizde, dvd oynatıcınızda da ucuz ve bol bol duruyor olacak.

    kaynaklar:

    https://en.wikipedia.org/wiki/year_2038_problem

    https://www.quora.com/…-overflow/answer/soner-gönül
hesabın var mı? giriş yap