Bilgisayarlar ve 2038 yılı

Belli bir süredir gündemde olan bir sorun bugün takip ettiğim Compunauts listesinde karşıma ilginç bir şekilde çıkınca FM kitlesi ile paylaşayım dedim.

Basit bir Perl komut satırı ile sisteminizin 2038 yılına nasıl tepki vereceğini inceleyebilirsiniz...


perl -e 'use POSIX; $ENV{'TZ'} = "GMT"; for ($clock = 2147483641; $clock < 2147483651; $clock++) {print ctime($clock); }'

Yukarıdaki komutu MS Windows üzerinde Linux uygulamalarını çalıştırmak ve derlemek için kullandığım Cygwin ve bir Debian GNU/Linux sistemlerde denediğimde aşağıdaki çıktıyı elde ediyorum:

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
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

MS Windows için derlenmiş Perl'i kullanarak Windows 2000 Server komut satırında şu şekilde denediğimde ise:


perl -e "use POSIX; $ENV{'TZ'} = 'GMT'; for ($clock = 2147483641; $clock < 2147483651; $clock++) {print ctime($clock); }"

Şöyle bir çıktı elde ediyorum:

Tue Jan 19 05:14:01 2038
Tue Jan 19 05:14:02 2038
Tue Jan 19 05:14:03 2038
Tue Jan 19 05:14:04 2038
Tue Jan 19 05:14:05 2038
Tue Jan 19 05:14:06 2038
Tue Jan 19 05:14:07 2038

Görülen o ki 2038 yılı ile ilgili sorun devam ediyor. Uygulamaların bir kısmının 64 bitlik bir time_t kullanarak derlendiğinde sorunun bir kısmının giderilebileceği düşünülürse de 32 bit kullanarak tarih depolayan veritabanı sistemlerine dikkat etmekte fayda var!

Görüşler

tongucyumruk
yaklaşık 20 yıl önce

Öhüm, dayanamayacağım ne yapayım...

import sys, time
print "n".join([time.ctime(f) for f in range(2147483641,2147483651)])

tongucyumruk
yaklaşık 20 yıl önce

oops, sys modülüne ihtiyacımız yok... alışkanlıklar işte...

sametc
yaklaşık 20 yıl önce

hangisi daha okunaklı ;))

mascix
yaklaşık 20 yıl önce

perl

FZ
yaklaşık 20 yıl önce

sametc
yaklaşık 20 yıl önce

abarttınız ama :)

yani gercekten bir kodlara goz atin .....

hiç programlama dilii bilmeyen biri perl kodunu gorunce 10 cesit soru sorar...

peki python icin kac soru sorar soyliyeyimmi 0 belki print "n" ile ilgili sorar o kadar...........

ilk ogrenilen dil: kolay anlaşılan dildir ....

tongucyumruk
yaklaşık 20 yıl önce

Öhüm, print "n" değil aslında print "(backslash)n" olacaktı...

sametc
yaklaşık 20 yıl önce

Bende zaten onu kastetmiştim. yani bu "n" ne anlama gelir diye..

sundance
yaklaşık 20 yıl önce

Yahu ben de bunu anlamıyorum. Bana ne hiç programlama dili bilmeyen adamdan, dahası bana ne kardeşim Perl bilmeyen adamdan. Perl bilmeyen adam Perl anlamaya çalışmasın, bu mudur sıkıntı ?

Siz hiç duydunuz mu ? "Fransızca güzel bir dil ama Fransızca bilmeyen birisi hiçbir şey anlamaz"

Boşverelim bunları, asıl mesele "Ben xxxx'le şöyle şahane bir program yaptım, şu şu işi yapıyor" demek. Bunları konuşalım.

tongucyumruk
yaklaşık 20 yıl önce

Açıkçası bir dili bilmeyen o dili anlamasın fikrine katılmıyorum. Özellikle seninde daha önce bahsettiğin "kendi kendine yetme" konusunda bu daha da önemli bir hal alıyor. Şöyle düşünelim. Ben Perl veya C bilmiyorum. Fakat önümdeki Perl veya C kodu okunaklı bir şekilde yazılmışsa içindeki çok derin olmayan hataları kodu okuyarak ayıklayabiliyorum. Bu sayede hem bir patch ile o kodun yazarına yardımcı olmuş oluyorum, hem de kendi kendime yeterek e-posta listelerinde veya irc'de yardım almama gerek kalmadan sorunumu çözüyorum. Bu nedenle Perl bilmeyen Perl kodu okumasın yaklaşımı bana hatalı geliyor.

Ha bunun Python'un okunabilirliğiyle alakası ne? Python diğer dillere oranla kodu biraz daha okunabilir yazmaya zorluyor. Peki python'da okunaksız kod yazılmaz mı? Bal gibi de yazılır, yazdım oradan biliyorum.

Sonuç olarak programlama dilinin Perl veya Python olması okunabilirlik konusunda sadece bir araç, olay eninde sonunda programcıda bitiyor.

FZ
yaklaşık 20 yıl önce

Kusura bakma ama ben de bu mevzu ile verilmiş 3 örnekten en kolay anlaşılabilir olanının Python olduğuna katılmıyorum. Python bilmeyen biri olarak koda bakınca şunu düşünüyorum:

import diye bir şey kullanılmış, herhalde bazı kütüphaneleri, ek özellikleri vs. kullanmak için bir şeyler çağrılıyor. Sonra ekrana bir şey basılacak, ardından bir nokta geliyor... Buradan hemen sonra devreye join diye bir fonksiyon girmiş. Bir şeyleri birleştirecek herhalde. Belki bunu da basacak gibi... Göreceğiz. Ne birleşecek? time.ctime(f) diye bir şey var. Nesneye yönelik programlama herhalde. time diye bir nesnenin ctime diye bir metoduna f parametresi geçilmiş. f ne? Ardından sanki bir döngü geliyor. f var içinde, önceki fonksiyona geçilen f ile aynı mı? f'nin bir range yani aralık içinde olduğu söylenmiş, acaba nasıl artıyor, bu belli değil. Peki bu döngü ile time nesnesinin metodu mu birleşiyor. Yoksa time nesnesi aslında döngünün içinde mi, yoksa önce döngü çalışıyor, sonra bu f bir sürü değer alıyor ve bir anda hepsi time.ctime'a parametre olarak mı geçiliyor? Eğer f in ... diye döngü kurabiliyorsam range dememe gerek var mı, zaten vereceğim şeyin başlangıcı, bitişi (ve belki adım miktarı) yeterli olmaz mı... vs. vs. bir sürü soru.

Perl'e bakınca şunu görüyorum, POSIX diye bir modül kullan. Bir dizi... hayır hayır bir tür anahtar değer çifti (key/value pair), bunu belli bir değere eşitle. Sonra 70'lerden beri alışık olduğumuz bir for döngüsü içinde, ilk değerden başla, son değere dek bir artırarak git, döngü içinde döngü değişkenini ctime fonksiyonundan geçir ve çıkan şeyi bas (döngü bitene dek).

Lisp'e bakınca şunu görüyorum: encode-universal-time fonksiyonuna bir dizi sabit değer geç (muhtemelen bunlar bir şekilde encode edilecek olan gün ay yıl saat, vs. gibi şeyler, fonksiyonun ismi kabak gibi ortada çünkü ;-), neyse işte, çıkan değere 5000 ekle, çıkan değeri decode işlemine tabi tut yani ters fonksiyon uygula. Bitti. (Hmm, evet, tabii PRINT işlevselliği nerede değil mi? E iyi ama burada Lisp'i interpreter modunda kullanmıyor muyuz, yani niye print diyeyim ki, zaten Lisp'e verdiğim şeyler evaluate edilir yani değerleri hesaplanır ve sonuç bana yine Lisp ortamında döndürülür, pratik bir durum değil mi ;-)

Sonuç: Sonuç yok süreç var. Anadilimizi öğrenene kadar bile min. birkaç yıl harcıyoruz, uğraşacağımız dili öğrenmek için de biraz zahmete katlanalım, bir zahmet.

Bilmediğin dilde sorun çözmeye gelince, yani şimdi sana 50 sayfa Türkçe metin sunsam ama bu metin mesela astronomideki bir problemin bir tarifiyle ilgili olsa hemencecik anlayabilecek misin eğer astronomi hakkında bilgi sahibi değilsen? (üstelik böyle bir metin matematiğe çok az göndermede bulunarak da yazılabilir, o yüzden 50 sayfa dedim zaten :-P

Düşüncem şu: Eğer kodun hedeflediği problem alanındaki teoriye vakıf değilseniz o kod, yani kodu geçtim, kabaca anadilinizde mevzuyu anlatsam yine anlamakta güçlük çekersiniz, başka kaynaklara yönelip daha uzun ve açıklayıcı anlatımları okumak gerekir. Bundan ötürü yani kodda sözdizim hatası bulmak kolay olabilir ama yani o kadarını derleyici ya da yorumlayıcı ya da kaynak kod analiz sistemleri de yapıyor. Dilin anlamına yani semantiğine vakıf olmak ve bunun da ötesine o dille çözülmeye çalışılmış probleme vakıf olmak ise bambaşka bir şey, bu bağlamda elbette dil programcıya ne denli soyutlama ve metaprogramlama gücü sunarsa o kadar iyi.

tongucyumruk
yaklaşık 20 yıl önce

Anlatmaya çalıştığım şey şu: Kodun okunabilirliği önemlidir. Ben Perl bilmiyorum, Lisp'ten de "Lisp biliyorum" diyecek kadar anlamıyorum fakat üç dilin üçünde de verilen örnekler ne yapmaya çalıştığını rahatlıkla anlamama yetecek kadar açık yazılmıştı. Bana kalırsa i in range(0,10) da i=0; i=10; i++ da kıyısından köşesinden programlamaya bulaşmış herhangi bir insan için yeterince açıktır.

Kodu okuyup ne olduğunu anlamak için değil "kendi kendine yetebilmek" için kodu okumaktan bahsediyorum. Yoksa oturup Zope'un kodlarını okuyup anlamak isterseniz kodun Python ile yazılmış olması eğer python bilmiyorsanız tabiiki bir avantaj sağlamaz.

Bir programın ne "anlattığını" kavrayabilmek için o dili bilmek tabiiki gereklidir. Fakat basitçe bir derleyicinin yakalayamadığı bir ıİ problemini bu problemle daha önce uğraşmış biri C bilmese dahi C kodunun içinde bulup az bir C bilgisi ile düzeltebilir.

bm
yaklaşık 20 yıl önce

Yahu ben de bunu anlamıyorum. Bana ne hiç programlama dili bilmeyen adamdan, dahası bana ne kardeşim Perl bilmeyen adamdan. Perl bilmeyen adam Perl anlamaya çalışmasın, bu mudur sıkıntı ?

Baska bir alinti yapayim:

The Novice has been the focus of an alarming amount of attention in the
computer field. It is not just that the preferred user is unskilled, it is
that the whole field in its application rewards novices and punishes experts.

( Erik Naggum http://groups-beta.google.com/group/comp.lang.lisp/msg/a6df017072f4c700 devami orada)

Yani yanliz degilsiniz, pekcok insan bundan rahatsiz. Ben Perl'
u sevdigimden demiyorum bunu, ama _ana_ kistasimiz 3-5 dakikada birseylerin anlasilmasi/olmasi/yapilabilmesi olunca bu karakter itibariyla anlasilmasi/olmasi/yapilmasi 3-5 dakikadan fazla surmesi gereken seylerin esasinda bunlardan faydalanmamalari icin bir sepep olmayan kisilerce dislanmasi sonucunu doguruyor. Yazik oluyor.

sundance
yaklaşık 20 yıl önce

Çok güzel alıntı, uzmanların cezalandırılması konusu gerçekten olmakta, teşekkürler.

sametc
yaklaşık 20 yıl önce

http://www.fazlamesai.net/modules.php?name=News&file=article&sid=2532

bu haberde yer alan sozlerinizi hatırlamanızı isterim :)

bm
yaklaşık 20 yıl önce

CL-USER> (encode-universal-time 59 59 23 31 12 2038)
4386434399
CL-USER> (decode-universal-time (+ 5000 (encode-universal-time 59 59 23 31 12 2038)))

19
23
1
1
1
2039
5
NIL
-2
CL-USER>

problem neydi?

( http://clhs.lisp.se/Body/f_dec_un.htm [clhs.lisp.se])

bm
yaklaşık 20 yıl önce

Cok tarafli oldu. Problem var esasinda, ama bignum'la hallolan problemden farkli: http://naggum.no/lugm-time.html [naggum.no]

raistlinthewiz
yaklaşık 20 yıl önce

y2k38 :)
bi kac sene once, y2k bug gundemdeyken, bu konuda bir arastirma yapmis ve konuyla ilgili bir yazı yazmıstım ama simdi bulamıyorum :)

Görüş belirtmek için giriş yapın...

İlgili Yazılar

Beni Bul Bebek

redial
24 Mart 2003, 1 dakika okuma süresi

Bebek bir yapay zeka programıydı...
Mehmet Emin Arı'nın yeni bir hikayesi...
turk.internet.com ' dan okuyabilirsiniz

FBI 10 yıl önce OpenBSD IPSEC 'e gizli arkakapılar(backdoors) ekledi!!

y0rk
15 Aralık 2010, 1 dakika okuma süresi

GoVirtual Education CEO'su Gregory Perry FBI ile imzaladıgı NDS in bitiminden hemen sonra bir itirafta bulundu. 10 yıl önce FBI tarafından OpenBSD IPSEC içersine birden fazla backdoor yerleştirdiklerini duyurdu. openbsd kullanan vpn ve firewall lar artık güvenli degil, VMWare VSphere in durumu ise tartışılır duruma geldi.

Bilgisayarlar ve 2038 yılı

Görüşler

İlgili Yazılar

Beni Bul Bebek

FBI 10 yıl önce OpenBSD IPSEC 'e gizli arkakapılar(backdoors) ekledi!!

Linux dergisi demişken...

Internet - Özgürlük - Hayat

Kablosuz Yaşam