Linux kerneli'nin 19 ocak 2038 bugu :(

Bu konuyu okuyanlar

eronis

Müdavim
Emektar
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
Year_2038_problem.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?
 

Halktan Biri

Müdavim
Emektar
Katılım
30 Ekim 2016
Mesajlar
9,401
Reaksiyon puanı
9,163
Puanları
113
Bir şeyleri sıfırdan yapmak gerekiyor sanırım. :)
Çok uğraştırıcak bir soruna benziyor.
 

ConfickerBelasi

Müdavim
Katılım
8 Ekim 2011
Mesajlar
53,870
Çözümler
1
Reaksiyon puanı
16,121
Puanları
113
o zamana kim öle kim kala? kıyamet kopmuş olursa ne önemi var ki...
 

NESDelisi

Müdavim
Katılım
12 Temmuz 2011
Mesajlar
2,686
Reaksiyon puanı
1,294
Puanları
113
Yaş
29
Bence 2038'e gelmeden önce Linux'un ölmesini istemiyorsak, şimdiden başlamak lazım bu sorunun çözümüne.
 

eronis

Müdavim
Emektar
Katılım
25 Mart 2016
Mesajlar
5,389
Reaksiyon puanı
4,382
Puanları
113
Bence 2038'e gelmeden önce Linux'un ölmesini istemiyorsak, şimdiden başlamak lazım bu sorunun çözümüne.
Yaa, muhtemelen onu çözmenin yolu o kadar zor değildir, sadece şu an daha öncelikli sorunlar olduğu için onu sürekli erteliyor, ama bir yanda da not edilmiş halde tutuyorlardır. Çok zor bir sorun olduğuna inanmıyorum.
 

NESDelisi

Müdavim
Katılım
12 Temmuz 2011
Mesajlar
2,686
Reaksiyon puanı
1,294
Puanları
113
Yaş
29
Tamam haklısın da, linuxu neden insanlar çok tercih etmiyor çözemedim.
 

eronis

Müdavim
Emektar
Katılım
25 Mart 2016
Mesajlar
5,389
Reaksiyon puanı
4,382
Puanları
113
Tamam haklısın da, linuxu neden insanlar çok tercih etmiyor çözemedim.
Çocukken Windows 98 kullanmış biri olarak bunu anlayabiliyorum. Ben küçüklüğümden beri Windows kullandığım için benim için geçiş korkutucu idi. Ama zor olmadı. Herkes için böyle. Herkes Microsoft ürünlerini kullanamyı biliyor ve başka bir sistemi kullanmayı öğrenmek istemiyor. Daha doğrusu korkuyor. Çocuklara Linux kullandırın.
 

ConfickerBelasi

Müdavim
Katılım
8 Ekim 2011
Mesajlar
53,870
Çözümler
1
Reaksiyon puanı
16,121
Puanları
113
bana zor olmadı ha Linux Mint ya xp ya vista ya 7 ha 8 ya 9 ya 10 fark etmiyor...
win95-win98se de...
 

eronis

Müdavim
Emektar
Katılım
25 Mart 2016
Mesajlar
5,389
Reaksiyon puanı
4,382
Puanları
113
bana zor olmadı ha Linux Mint ya xp ya vista ya 7 ha 8 ya 9 ya 10 fark etmiyor...
win95-win98se de...
Demek istediğim, bir insana çocukken ne kullandırırsan ona alışıyor. Misal bak dedelerimize, babannelerimize ? Onlar akıllı telefon kesinlikle istemezler. Tuşlu telefona zor geçirdik onları. İnsanlar hayatları boyunca ne kullandılarsa, onu kullanmaya devam etmek istiyorlar. Bu versiyon olayı falan değil. Yani adam akıllı yol gösterecek biri yoksa benim gibi manyağın biri evindeki oyun bilgisayarının kıçına tekmeyi basıp, eski bir netbook alıp, XP'yi beğenmeyip, bu bilgisayara Linux kurma kararı kolay almıyor. Benim gibi geçenler baya azınlıktadır. Genelde hep birinin yol göstermesiyle geçiyor insanlar. Adam akıllı yol gösterirsen geçebilirler, ama çıkıp da Arch, Slackware, Gentoo, Debian, Fedora falan önermeye kalkarsan altından kalkamazlar. Mint öner, Manjaro öner, basit dağıtımlar öner, adam rahat geçer. Ama geçiren kişinin iyi fikir vermesi lazım.
 

TSLA

Öğrenci
Katılım
4 Şubat 2018
Mesajlar
27
Reaksiyon puanı
21
Puanları
3
Yaş
19
Ben de kimsenin yönlendirmesi olmadan geçtim ama geçiş bi hayli kolay oldu desem yalan olmaz. Çünkü Windows'un hep sıkıntısını çekmişimdir. Linuxta tek sıkıntım dagıtım seçmek:p:p
 

Jelican

Öğrenci
Katılım
14 Ocak 2017
Mesajlar
7
Reaksiyon puanı
2
Puanları
3
Sanırım bu 2038 sorunu başımızı ağrıtacak gibi. Benim telefonum da en son 2036 tarihini gösteriyor, bunun sebebi nedir?
 

ConfickerBelasi

Müdavim
Katılım
8 Ekim 2011
Mesajlar
53,870
Çözümler
1
Reaksiyon puanı
16,121
Puanları
113
daha 2036'ya da 2038'e de çok var bu çocuğunun sorunu...
 

caglarturali

Öğrenci
Katılım
4 Mayıs 2011
Mesajlar
22
Reaksiyon puanı
7
Puanları
3
Başlık biraz yanıltıcı olmuş. Aslına bakarsanız bu sorun Linux kerneli ile veya herhangi bir yönden Linux ile doğrudan bağlantılı değil.

Şöyle ki, bahsi geçen tarih 1 Ocak 1970 00:00:00, tüm yazılım sistemlerinin başlangıç noktası olarak kabul ettiği ve bu sayede sistem içi/sistemler arası saat/tarih işlemlerinde tutarlı sonuçlar alınmasını mümkün kılan bir tür dijital milattır. Yaygın olarak Unix Epoch ismiyle anılmasının yanında, Unix Time, POSIX Time, Unix Timestamp veya sadece Timestamp diye anıldığını görmek de mümkündür.

Avantajı, tüm bir tarihi tek bir sayı ile ifade edebilmektir. Böylece, gerektiğinde iki tarihi karşılaştırmak, 1 ve 2'yi karşılaştırmak kadar kolay bir işleme dönüşür. Aynı şeyi gün.ay.yıl saat:dakika:saniye formunda saklanan tarih bilgileri ile yapmak, hem zahmetli hem de hatalara açıktır.

Ve 32-bit integer veri yapısının tutabileceği maksimum değer olan 2,147,483,647 sayısına ulaşıldığında, orijinal Unix Epoch takviminin sonuna gelmiş olacağız. Peki şu an bu takvime göre hangi tarihteyiz? F12 veya Ctrl + Shift + I kombinasyonu ile tarayıcınızın geliştirici araçlarını açıp Console sekmesinde şu kodu çalıştırarak öğrenebilirsiniz: new Date().getTime() Aslında bu kodun çıktısı olan sayı, 32 bit integerın tutabileceğinden daha büyük bir sayı. Çünkü JavaScript, Unix zamanını saniye bazında değil, milisaniye bazında sayıyor. Şu anki Unix zamanını saniye cinsinden görmek için de bu kodu kullanabilirsiniz: (new Date().getTime() / 1000).toFixed(0) Bu kodları tekrar tekrar çalıştırarak Unix zamanının akışını gözlemleyebilirsiniz.

Peki bir çözüm bulunmazsa -ki böyle bir ihtimal olduğunu düşünmüyorum- sadece Linux sistemleri mi etkilenecek? Tabii ki hayır. Yukarıda bahsettiğimiz gibi bu tarihi referans alan tüm yazılım sistemleri, yani basitçe hemen hemen bütün yazılım sistemleri bu sorundan etkilenecektir. Çözüleceği kesin olan (öyle olmak zorunda) bu sorun hakkında sorulabilecek tek soru, nasıl çözüleceğidir. Çünkü getirilecek çözüm, halihazırda kullanılan bütün yazılım ortamlarında uygulanmak durumunda olacağı ve kritik önem sahip bir veri türünü etkileyeceği için önemlidir. Ben şahsen, önümüzdeki birkaç yıl içerisinde bu soruna cevaben ortaya atılmış çözümler göreceğimizi ve 2038'e varmadan çok önce aşama aşama bu sorunu aşacağımızı düşünüyorum.

Konuyu görünce açıklama yapma gereği hissettim. Umarım bir nebze açıklık getirebilmişimdir.
 

Jelican

Öğrenci
Katılım
14 Ocak 2017
Mesajlar
7
Reaksiyon puanı
2
Puanları
3
Başlık biraz yanıltıcı olmuş. Aslına bakarsanız bu sorun Linux kerneli ile veya herhangi bir yönden Linux ile doğrudan bağlantılı değil.

Şöyle ki, bahsi geçen tarih 1 Ocak 1970 00:00:00, tüm yazılım sistemlerinin başlangıç noktası olarak kabul ettiği ve bu sayede sistem içi/sistemler arası saat/tarih işlemlerinde tutarlı sonuçlar alınmasını mümkün kılan bir tür dijital milattır. Yaygın olarak Unix Epoch ismiyle anılmasının yanında, Unix Time, POSIX Time, Unix Timestamp veya sadece Timestamp diye anıldığını görmek de mümkündür.

Avantajı, tüm bir tarihi tek bir sayı ile ifade edebilmektir. Böylece, gerektiğinde iki tarihi karşılaştırmak, 1 ve 2'yi karşılaştırmak kadar kolay bir işleme dönüşür. Aynı şeyi gün.ay.yıl saat:dakika:saniye formunda saklanan tarih bilgileri ile yapmak, hem zahmetli hem de hatalara açıktır.

Ve 32-bit integer veri yapısının tutabileceği maksimum değer olan 2,147,483,647 sayısına ulaşıldığında, orijinal Unix Epoch takviminin sonuna gelmiş olacağız. Peki şu an bu takvime göre hangi tarihteyiz? F12 veya Ctrl + Shift + I kombinasyonu ile tarayıcınızın geliştirici araçlarını açıp Console sekmesinde şu kodu çalıştırarak öğrenebilirsiniz: new Date().getTime() Aslında bu kodun çıktısı olan sayı, 32 bit integerın tutabileceğinden daha büyük bir sayı. Çünkü JavaScript, Unix zamanını saniye bazında değil, milisaniye bazında sayıyor. Şu anki Unix zamanını saniye cinsinden görmek için de bu kodu kullanabilirsiniz: (new Date().getTime() / 1000).toFixed(0) Bu kodları tekrar tekrar çalıştırarak Unix zamanının akışını gözlemleyebilirsiniz.

Peki bir çözüm bulunmazsa -ki böyle bir ihtimal olduğunu düşünmüyorum- sadece Linux sistemleri mi etkilenecek? Tabii ki hayır. Yukarıda bahsettiğimiz gibi bu tarihi referans alan tüm yazılım sistemleri, yani basitçe hemen hemen bütün yazılım sistemleri bu sorundan etkilenecektir. Çözüleceği kesin olan (öyle olmak zorunda) bu sorun hakkında sorulabilecek tek soru, nasıl çözüleceğidir. Çünkü getirilecek çözüm, halihazırda kullanılan bütün yazılım ortamlarında uygulanmak durumunda olacağı ve kritik önem sahip bir veri türünü etkileyeceği için önemlidir. Ben şahsen, önümüzdeki birkaç yıl içerisinde bu soruna cevaben ortaya atılmış çözümler göreceğimizi ve 2038'e varmadan çok önce aşama aşama bu sorunu aşacağımızı düşünüyorum.

Konuyu görünce açıklama yapma gereği hissettim. Umarım bir nebze açıklık getirebilmişimdir.

Çok haklısınız. Umarım o zamana gelmeden soruna çözüm bulunur, yoksa sistemlerin zaman ayarları büyük sorunlara yol açacak gibi gözüküyor.
 

darkstar

Müdavim
Katılım
21 Ağustos 2016
Mesajlar
1,638
Reaksiyon puanı
1,481
Puanları
113
Bugünkü serverların yani kritik veri barındıran platformların tamamı olmasa da büyük çoğunluğu x64 mimarisi üzerinde.
2038 yılına kadar da muhtemelen x32 mimarisinde bir donanım kalmaz yani gereksiz bir endişe.
Slackware 14.2 x64 testi herhangi bir problem yok...

bash-4.3# ./2038.pl

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038
 
Son düzenleme:
Üst