- Katılım
- 25 Mart 2016
- Mesajlar
- 5,389
- Reaksiyon puanı
- 4,382
- Puanları
- 113
Eğer Linux dünyasındaki gelişmeleri yakından takip ediyorsanız 2038 bug'unu duymuşsunuzdur. Basitçe özetlemek gerekirse bu sorun Unix'in 32-bit veri değerli zaman formatında en son gösterilebilecek zamanın 19 ocak 2038'de 03:14:07 UTC zamanı olması. Sonrasında standart zaman kütüphanesini kullanan bütün C programları tarihlerle ilgili sorunlar yaşamaya başlayacak.
2000 yılı sorunu, aynı zamanda da milenyum bug'u veya Y2K problemi olarak bilinen bug aslında bilgisayarların takvim zamanını belirleme ve depolamalarıyla ilgili bir bug idi. Bu sorun ilk bilgisayarların depolama birimleri çok pahalı olması nedeniyle var oldu. Veri alanını düşürmek için, porgramcılar 6 karakterli AAGGYY tipinde tarih formatı kullandılar. Para tasarrufu sağladı ancak böylece veri tabanlarındaki dosyaların boyutlarını düşürdü. Bazı programlar 2000 yılı, 1900 yılı ve 19100 yılı arasındaki farkı ayırt edemez oldu.
Bu sorunun üstesinden gelmek için devletler özel komiteler kurdu ve kritik altyapı sorununun çözüldüğünden emin olmak istediler. Bugün, aynen 2038 yılı sorunu bilgisayar dünyasında hala varlığını koruyor.
Bu 2038 yılı bug'u yada diğer adı ile Y2K38 bug'u 32 bit değerler ile hesaplanan zamana dayalı veri depolama senaryolarında sıkıntı çıkarabilir.
Bu tarihte Unix'in 32 bit zaman formatının en son gösterebildiği değer 03:14:07 olacak. Tam olarak 1 ocak 1970 tarihinden 2,147,483,647 saniye sonra. Bu zamandan sonra bu sorundan dolayı zaman değerleri negatif olarak depolanacak ve sistemler kendilerini 13 Aralık 1901 tarihinde sanacaklar.
Basit bir dille, Unix cihazlar'ın saati dolacak. Bugün, standart zaman kütüphanesi kullanan C programları tarihle ilgili sorunlar yaşamaya başlayacak.
Wikipedia'dan ayrıntıları görebilirsiniz.
https://en.wikipedia.org/wiki/Year_2038_problem
Buyurun, 2038 bug'unun zamanı nasıl resetleyeceğini açıklayan bir gif
Şu anda bu sorunu çözebilecek evrensel bir çözüm yok. Eğer zaman değerlerini depolamakta kullanılan time_t dosya tipinde bir değişim yapılsa, 32 bit time_t değerlerini kullanan uygulamalardaki kodlarla uyumluluk sorunlarını beraberinde getirirdi. Diyelim ki time_t'yi bir 32-bit integer ile değiştirildi ve böylece maksimum zaman limiti artırıldı. Ama, bu da negatif olarak ifade edilen 1970'deki değerleri mahvederdi.
64 bit'i kullanan işletim sistemi ve programlar 64-bit time_t değerlerini kullanır. 64 bit zaman değerini kullanmak bunadn 292 milyar yıl sonrasına kadar değerin kullanımına olanak sağlar.
Bununla ilgili bazı tavsiyelerde bulunuldu, milisaniye/mikrosaniyelerin depolanması ile de dahil olmak üzere 64 bit değerde minimum 300.000 yıl kullanımı için. (1 Ocak 1970 yada 1 ocak 2000). Diğer öneriler ise programları yeni kütüphanelerle yeniden derlenmesi vs... Hala çalışmalar sürüyor ve uzmanlara göre 2038 yılı sorununun çözmesi çok zor bir sorun olmaması gerekiyor.
2038 yılı hikayesini ilginç buldunuz mu ? Görüşlerinizi bizimle paylaşın
Kaynak: What Is The Year 2038 Problem In Linux? Will Unix Clocks Fail On Jan. 19, 2038?
2000 yılı sorunu, aynı zamanda da milenyum bug'u veya Y2K problemi olarak bilinen bug aslında bilgisayarların takvim zamanını belirleme ve depolamalarıyla ilgili bir bug idi. Bu sorun ilk bilgisayarların depolama birimleri çok pahalı olması nedeniyle var oldu. Veri alanını düşürmek için, porgramcılar 6 karakterli AAGGYY tipinde tarih formatı kullandılar. Para tasarrufu sağladı ancak böylece veri tabanlarındaki dosyaların boyutlarını düşürdü. Bazı programlar 2000 yılı, 1900 yılı ve 19100 yılı arasındaki farkı ayırt edemez oldu.
Bu sorunun üstesinden gelmek için devletler özel komiteler kurdu ve kritik altyapı sorununun çözüldüğünden emin olmak istediler. Bugün, aynen 2038 yılı sorunu bilgisayar dünyasında hala varlığını koruyor.
Bu 2038 yılı bug'u yada diğer adı ile Y2K38 bug'u 32 bit değerler ile hesaplanan zamana dayalı veri depolama senaryolarında sıkıntı çıkarabilir.
Bu tarihte Unix'in 32 bit zaman formatının en son gösterebildiği değer 03:14:07 olacak. Tam olarak 1 ocak 1970 tarihinden 2,147,483,647 saniye sonra. Bu zamandan sonra bu sorundan dolayı zaman değerleri negatif olarak depolanacak ve sistemler kendilerini 13 Aralık 1901 tarihinde sanacaklar.
Basit bir dille, Unix cihazlar'ın saati dolacak. Bugün, standart zaman kütüphanesi kullanan C programları tarihle ilgili sorunlar yaşamaya başlayacak.
Wikipedia'dan ayrıntıları görebilirsiniz.
https://en.wikipedia.org/wiki/Year_2038_problem
Buyurun, 2038 bug'unun zamanı nasıl resetleyeceğini açıklayan bir gif
Şu anda bu sorunu çözebilecek evrensel bir çözüm yok. Eğer zaman değerlerini depolamakta kullanılan time_t dosya tipinde bir değişim yapılsa, 32 bit time_t değerlerini kullanan uygulamalardaki kodlarla uyumluluk sorunlarını beraberinde getirirdi. Diyelim ki time_t'yi bir 32-bit integer ile değiştirildi ve böylece maksimum zaman limiti artırıldı. Ama, bu da negatif olarak ifade edilen 1970'deki değerleri mahvederdi.
64 bit'i kullanan işletim sistemi ve programlar 64-bit time_t değerlerini kullanır. 64 bit zaman değerini kullanmak bunadn 292 milyar yıl sonrasına kadar değerin kullanımına olanak sağlar.
Bununla ilgili bazı tavsiyelerde bulunuldu, milisaniye/mikrosaniyelerin depolanması ile de dahil olmak üzere 64 bit değerde minimum 300.000 yıl kullanımı için. (1 Ocak 1970 yada 1 ocak 2000). Diğer öneriler ise programları yeni kütüphanelerle yeniden derlenmesi vs... Hala çalışmalar sürüyor ve uzmanlara göre 2038 yılı sorununun çözmesi çok zor bir sorun olmaması gerekiyor.
2038 yılı hikayesini ilginç buldunuz mu ? Görüşlerinizi bizimle paylaşın
Kaynak: What Is The Year 2038 Problem In Linux? Will Unix Clocks Fail On Jan. 19, 2038?