4 Ekim 2022 Salı

Soğuk Kahve Demlemeye (Cold Drip) Radikal Yaklaşımlar - 1

Bir zamandır kahve demlemek ve içmekle ilgileniyorum. Eskiden de içiyordum ama ne olduğu çok farketmiyor gibiydi. Hakkında biraz okuyunca [4] çok fazla parametrenin olduğunu ve çok değişik kahveler yapma imkanını farkettim (tam bir cinyısım). Bu seride birkaç değişik tarifi ve denememi paylaşmak istiyorum. Birileri okuyup "ben de şöyle yaptım" dese güzel olur elbette ama beklentileri yüksek tutmamak lazım.

Malumunuz kahve çok farklı şekillerde demlenebiliyor. Kullanılan ekipmanı, suyun sıcaklığını, basıncını değiştirerek (aslında başka parametreler de var ama onlara ayrıca değinmeyi planlıyorum) çok değişik içimli kahveler demlemek mümkün. Bu yazın başlangıcında Kaan'ın hediye ettiği soğuk demleme (cold brew) sürahisi [1] ile soğuk kahve yapmaya başladım. Burada yapılan özetle kalın öğütülmüş kahveyi (daha sonra buraya kahve öğütmeyle ilgili yazının linkini eklerim) soğuk suyla, uzun süre (12 - 24 saat arasında) bir arada tutup çözülmesini sağlamak. Bunun sonucu kahveyi sıcak suda çözmek gibi olmuyor ama hedeflenen de o zaten. Kahve çekirdeğini ve miktarını değiştirerek çok güzel içimli kahveler elde etmek mümkün bu yöntemle.

Aradan geçen zamanda birçok kahve ekipmanı alınca soğuk kahve demlemek için ikinci bir yöntem daha olduğunu gördüm ve onun için gerekli şişeyi [2] alarak beni bu yazıya getiren yola girmiş oldum. Bu yöntemde kahve doğrudan suyun içinde kalmıyor, onun yerine sizin ayarladığınız hızda (saniyede bir damla, üç saniyede bir damla gibi) kahvenin üzerine damlıyor. Bu yöntem ile 2 ila 6 saat arasında soğuk demlenmiş kahve elde etmek mümkün ve ilk demlemeden çok farklı bir tadı oluyor kahvenin (Burada aroma, notalar gibi kelimeleri kullanmak istemedim :) ama gelecek yazılar nasıl olacak bilemiyorum). Soğuk kahvenin en önemli dezavantajı asiditesi düşük olduğundan ve buzla servis edildiğinden yaz sıcağında gereğinden çok içilebilmesi bence. Soğuk da olsa içtiğimiz şeyin kahve olduğunu gözden kaçırmamamız lazım.

Bir süre standart tariflerle soğuk kahve demleyince başka ne yapabilirim sorusu insanın aklını kurcalıyor. Ben önce soğuk suyun ve buzun olduğu hazneye meyve parçaları koymayı denedim. Önce birkaç parça şeftali bıraktım, sonra bir portakalın kabuğunu. Her ikisinde de ortaya çıkan soğuk kahvede belirgin bir aroma hissedemedim. Belki bu eklemeleri kahvenin bulunduğu yere koysaydım sonuç farklı olabilirdi bilemiyorum. Bunları da ileride deneyeceğim.

Madem suya bir şey ekleyip tadı değiştirmek imkanı olmadı o zaman su yerine başka bir şey kullanayım diye düşündüm (aslında Kaan'la düşündük). Jameson Cold Brew Viskiden de ilham alarak (onların böyle yapmadığını biliyoruz) kahvenin üzerine damlayan sıvıyı su yerine viski olarak değiştirip denemeye karar verdik. Bu denemede kullandığım malzeme şöyle:


Soğuk demlemeyi su ile yaptığımızda 50 gr kahve kullanıyor ama ben viskiyle bu oranı denediğimde kahve tadı çok sert geldi. Kahve miktarını 15 gr seviyesine çekip denediğimde de çook gerilerden gelen bir kahve tadı aldım. Benim Brezilya çekirdeği [3] kullanmış olduğumu (espresso için kahveyi el değirmeniyle öğütüyorum ama soğuk kahveler için miktar çok fazla olduğundan öğütmeye üşendim işin doğrusu), viskinin de The Famous Grouse olduğunu akıldan çıkartmamak gerekir elbette. Başka kahve çekirdekleriyle ve başka viskilerle sonsuz deneme yapılabilir bu konuda. Neyse ben 30 gr kahvenin üzerine 3 saniyede 2 damla viski damlayacak şekilde bir düzenek kurdum. Burada şunu da söyleyeyim: kahvenin üzerine döktüğünüz ilk damla su aşağıdan çıkmayacaktır. Kahve bir miktar suyu emer, bundan fazlası aşağı düşmeye başlar. Ben bu aşamayı kahveye çok yavaşça soğuk su ekleyerek geçtim. İlk damla düşünce su eklemeyi bıraktım. Nazım "Nerdeyse tatlı bir söz gibi ilk damla düşecekti yere" diyor ya tam orada viskinin damlamasını başlattım. Böyle yapınca 70'lik viskiden neredeyse 70'lik çıktı elde etmiş oldum. Viskiyi de iki saat kadar buzlukta bekletmiştim (merak etmeyin kolayca donduramazsınız viskiyi).


Yaklaşık 3 saat sonra demleme işlemi tamamlanmıştı. Bunları şişeleyip soğumaya bıraktım. Sonuç tahmin ettiğimden çok çok güzel oldu. İlk yudum içimi sert bir viski gibi gelirken arkadan çok yoğun bir kahve tadı geldi.

Deneyen herkesin beğendiği (aslında çok az arkadaşım denedi ama hepsi de hem viskiden hem de kahveden anladıkları) için bu yazıyı yazmaya cesaret buldum. Çok farkı denemeler yapmaya açık bir alan olduğundan belki size de yeni şeyler denemek için ilham verir diye düşündüm.


[1] https://www.amazon.com.tr/gp/product/B00IJ3PAIM/

[2] https://www.amazon.com.tr/gp/product/B07YB1QGLP/

[3] https://www.amazon.com.tr/gp/product/B08ZDJWDL4/

[4] https://www.amazon.com.tr/dp/1784724297/

13 Haziran 2021 Pazar

Halkın parasıyla oluşturulan yazılımlar halkın malı olmalı

Avrupa Özgür Yazılım Vakfı uzun zamandır yürüttüğü bir kampanya ile "Vergi verenlerin parasıyla üretilen yazılımlar Özgür Yazılım olarak yayınlanmalı"[1] diyor. Uzun yıllardır kamuda çalıştığım için bu hedefin çok uzağında olduğumuzu biliyorum. Bizde neredeyse her kurum ihtiyacı olan yazılımları çoğunlukla kaynak kodunu almadan, kimseyle paylaşamayacağı, kendisi üzerinde bir geliştirme yapamayacağı şekilde alıyor veya yazdırıyor. Böyle olunca aynı sorunu her kurumun yeniden çözdürmesi, lisans bedeli ödemesi, üzerinde geliştirme yapamaması gibi olumsuz durumlar oluyor. Bunu yapanlar özel şirketler olduğunda bile özgür yazılımları kullanmalarını teklif ederken kamu kurumlarının bizim vergilerimizi böyle harcamamaları konusunda bir bilinç oluşturulmalıyız. Kurumların yöneticileri bilişim dünyasından o kadar habersizler ki ortada böyle bir sorun olduğunun bile farkında olmuyorlar çoğunlukla. Eğer iyi anlatılırsa halkın vergilerinin verimli kullanılması konusuna hiçbir yöneticinin ayak dirememesi gerekir.

Bu hafta Ankara Büyükşehir Belediye Başkanı Mansur Yavaş'ın duyurduğu "Lezzet Ankara" uygulamasının bir özgür yazılım olarak lisanslanmasının yukarıda bahsettiğim kampanyanın yaygınlaşması için önemli bir adım olabileceğini düşünüyorum. Elbette bunun için ikna edilmesi gereken kişi başkentin belediye başkanı değil onun bilişim alanıyla ilgili görevlendirdiği kişiler olmalı. Bu yazıyı hem onları hem de ilgilenen diğer yetkilileri göz önünde tutarak ayrıntılandırmak istiyorum.

Kamu kurumları ister kendi personellerine geliştirme yaptırsınlar, isterse dışarıdan alım yapsınlar çok basit birkaç noktaya dikkat ederek halkın vergilerinin çok daha verimli kullanılmasını sağlayabilirler. Burada akıllara gelebilecek konuların üzerinden geçelim.

Yazılımınızı özgür yazılım yapınca kontrolü kaybetmeyeceksiniz

Özgür yazılımların kaynak kodları açık oluyor, kurum çalışanları dışından da destek verenler olabiliyor dediğimizde sanki her gönderilen kod yazılıma dahil edilmek zorundaymış gibi algılandığı oluyor. Durum böyle değil elbette. Yazılımı özgür yazılım olarak lisanslayınca dışarıdan kod katkısını nasıl alacağınızı yine kurum olarak belirliyorsunuz elbete. İsteyen (lisans şartlarına uyarak) sizin kodunuzu kullanabiliyor ama siz uygun bulduğunuz kodları projenize dahil ediyorsunuz. Tedirgin olacak bir şey yok aksine geliştiriciler harcayacakları emeğe değeceğini düşünürlerse kendi kadronuzla hayal bile demeyeceğiniz büyüklükte işler yapabilirsiniz.

Özgür yazılımlar güvenlik tehlikesi anlamına gelmez

Bu konuda uzunca yazdığım için tekrarlamak istemiyorum ama özet olarak şunu söyleyeyim "bir algoritmayı gizleyerek onu daha güvenli hale getiremezsiniz"[2]. Güvenlik sürekli ilgilenmeniz gereken bir konu olacaktır. Yazılımınızı özgür yazılım lisansıyla lisanslayıp kaynak kodlarını açtığınızda elbette kodlardaki hataları düzeltmek ve iyileştirmeler yapmak için bakanlar olduğu gibi saldırganlar da olacaktır ama yazılımı geliştirmek isteyenlerin sayısının saldırganlardan fazla olduğuna ve pek az güvenlik açığının yazılımın koduna bakarak tespit edildiğine güveniyoruz. Sizi kandırmayalım, kaynak kodlar açılınca güvenlik sorunu kaybolmayacak.

Yazılımınızın kaynak kodunu hemen açmanızı beklemiyoruz

İster kurum içinde geliştirilsin isterse dışarıya yazdırılmış olsun en başından itibaren kodlar başkalarının da göreceği şekilde düşünülerek yazılmadıysa içinde bazı kirli çözümler içeriyordur. Sadece tek bir noktada kullanılacak diye planlandığından özelleştirmeye uygun halde değildir. Bazı servislere erişimde kullanılan gizli bilgiler kaynak kod içine yazılmış olabilir. Bunların kaynak kod açılmadan önce temizlenmesi ve özelleştirilmeye uygun hale getirilmesi gerekir. Bu emek isteyen bir iştir ama bir başka kamu kurumunun baştan yazması, yazdırması düşünülünce maliyetinin ne kadar önemsiz olacağını hesaplamak kolay olacaktır. Elinizdeki kaynak kodların açılması için tecrübeli yazılım firmalarından destek alarak işe başlayabilirsiniz. Bundan sonra bunu bir kurum kültürü haline getirirsiniz ve ilave desteğe ihtiyacınız kalmaz.

Yazılımın kaynak kodunu herkesin göreceği bir hale getirmenin faydaları saymakla bitmeyecektir. Bir yazılım güvenliği firmasından alacağınız danışmanlık size kullanıcı verilerini nasıl saklamanız gerektiği konusunda da yol gösterecektir örneğin. Yazılımınız kullandığı algoritmayı iyi gerçekleştirmiştir ama kullanılan algoritma güvenli değildir belki. Önceden yazılmış olanları siz düzeltirsiniz, bundan sonra yazılacak olanlara da hepimiz bakarız.

Bundan sonra her yazılımın kaynak kodunu da satın almalısınız

Yazılımları eğer kurum içinde geliştirmiyor da dışarıdan alıyor veya ihtiyacınıza göre yazdırıyorsanız şartnamelerinize yazılımın kaynak koduyla birlikte teslim edilmesi gerektiğini mutlaka yazmalısınız. Halkın vergileriyle oluşturulan bir ürün mutlaka halkın malı olmalıdır. Sadece kaynak kodların verilmesini değil bir özgür yazılım lisansıyla lisanslanmasını da şartlarınız arasına koymalısınız. Bunu yapmazsanız aldığınız kaynak kodları paylaşamayacağınız gibi geliştirme dahi yapamayabilirsiniz.

Bu süreç elinizdeki yazılımlar için bedava olmayacak

Mevcut yazılımların kaynak kodlarının açılması sürecinde elbette bir maliyet olacaktır ama bu asla yazılımın yeniden yazılması kadar olmayacaktır. hem zaten hedefiniz hiç para harcamamak değil vergilerimizin verimli harcanması olmalıdır.

Yazılımların kaynak kodlarını açmak yazılım firmalarına zarar vermez

Merak etmeyin bütün kamu kurumları teker teker muhasebe yazılımı lisansı satın almayacak diye yazılım firmalarına zarar vermiş olmazsınız. Yazılım çözümlerine her zaman ihtiyaç olacaktır, firmalar gerekli inovasyonu geliştireceklerdir. Zaten bir firma kendisi yazılım geliştirmiyor, sadece yurtdışı bir firmanın ürününün lisansını satıyorsa ona yazılım firması bile dememek gerekir. Onlar başlarının çaresine baksınlar, bu kamunun sorunu değildir.

Herkesin dilindeki yerlilik, millilik sorununu çözmüş olacaksınız

Bu konuda da önceden uzunca yazmıştım[3] ama yazılımları özgür yazılım yaparak geliştirmenin ülkemizde yapılmasına, bizim üreten bir ülke olmamıza katkı sağlamış olacaksınız. Geliştirme yapabilmek için dışa bağımlı olmayacağız. Sadece bunlar bile yazılımları özgür yazılım yapmanız için yeterliyken bir de onları kamunun vergileriyle ürettiğinizi ve başka şansınızın olmadığını hesaba katmalısınız.

Vergi verenlerin parasıyla üretilen yazılımlar Özgür Yazılım olarak yayınlanmalıdır!

24 Ocak 2021 Pazar

GNU/Linux'ta erişim hakları

Bu yazıda anlatacaklarım GNU/Linux için olacak ama hepsi UNIX benzeri işletim sistemleri için geçerli olacaktır. Erişim hakları konusu her ne kadar işletim sistemindeki araçlarla ve çekirdeğin desteğiyle ilgili olsa da kullanılan dosya sisteminin buna izin veriyor olması gerekir. Temel erişim haklarından bahsedince bu konuya geri döneceğiz.

GNU/Linux işletim sistemleri çok kullanıcılı ve çok görevli işletim sistemleridir. Kullanıcı yönetimi ve neden işletim sisteminde bu kadar fazla kullanıcı olduğu başka bir konuşmanın konusu olacak kapsamlı bir konudur. Sistemde bulunan her dosya ve dizinin mutlaka sahibi bir kullanıcı ve ait olduğu bir grup olur. Yani bir dosya olamaz ki sahibi veya ait olduğu grubu belli olmasın.

GNU/Linux için üç temel ve üç de gelişmiş erişim hakkından bahsedebiliriz. Temel erişim hakları okuma (r), yazma (w) ve çalıştırma (x) haklarıdır. Şimdi örnek bir dosya için bu erişim haklarını görelim: 

$ ls -l /bin/ls -rwxr-xr-x 1 root root 142144 Eyl 5 2019 /bin/ls 

Burada ilk sütunda 10 karakterlik bir bilgi görüyoruz. İlk karakter erişim hakkıyla değil de listelenen şeyin ne olduğuyla ilgili bir bilgi veriyor bize. Bu bilgi şunlar olabilir: 

  • - Ordinary or Regular File 
  • d Directory 
  • c Character special file 
  • b Block special file 
  • l Symbolic link 
  • p Named pipe 
  • s Socket 

ls komutu listelediği şeyin tipini nasıl ayırt ediyor konusu ayrıca öğrenilmeye değer bir konudur.

İlk karakteri böylece geçtiğimize göre kalan 9 karaktere bakalım. Bunları üçerli gruplar halinde inceleyeceğiz. 

$ ls -l /bin/ls -rwxr-xr-x 1 root root 142144 Eyl 5 2019 /bin/ls 

İlk üç karakter ilgili dosyanın sahibi olan root kullanıcısının haklarını belirler. Bu örnekte dosyanın sahibi (u) dosyayı okuyabilir, dosyaya yazabilir ve dosyayı değiştirebilir. Dosyanın ait olduğu root grubunun (g) üyeleri dosyayı okuyabilir ve çalıştırabilir ama dosyada değişiklik yapamazlar. Dosyanın sahibi olmayan ve dosyanın ait olduğu gruba üye olmayan diğer kullanıcılar (o) ise dosyayı okuyabilir ve çalıştırabilirler ama değişiklik yapamazlar. Demek ki erişim haklarından bir karakter bulunmuyorsa o erişim hakkına sahip olunmadığını anlamamız gerekir.

İşletim sistemi üzerinde ancak sahip olduğumuz hakları değiştirebilir ve paylaşabiliriz. Yani bir dosyanın sahibi biz değilsek onun sahipliğini başka bir kullanıcıya veremeyiz. Benzer şekilde erişimimiz olmayan bir dosyanın erişim haklarını da değiştiremeyiz. Bizim /tmp dizini altında oluşturduğumuz testfile dosyası için şu işlemleri yapalım: 

  • Dosyanın sahibine çalıştırma izni verelim 

chmod u+x /tmp/testfile 

  • Dosyanın ait olduğu gruptan okuma iznini alalım 

chmod g-r /tmp/testfile 

  • Dosyanın sahibi ve diğerlerinden çalıştırma iznini alalım 

chmod uo-x /tmp/testfile 

Bu işlemleri şöyle tanımlamak da mümkün: 

  • Okuma hakkı için 4 (2 üzeri 2) 
  • Yazma hakkı için 2 (2 üzeri 1) 
  • Çalıştırma hakkı için 1 (2 üzeri 0) 

Bir dosyayı herkes okuyabilsin, sahibi dışında kimse üzerine yazamasın ve çalıştıramasın dediğimizde şu komutu çalıştırmalıyız: 

$chmod 744 /tmp/testfile 

Eğer bir dosyaya 777 erişim hakkını verirsek herkes o dosyayı okuyabilir, üzerine yazabilir ve çalıştırabilir. Hiçbir dosyaya veya dizine böyle bir erişim hakkını vermememiz gerekir. İleride benzer bir istisnasını görüp onun için ayrı bir erişim hakkı tanımlayacağız ama bir dosya veya dizine 777 erişim hakkını verirsek onu gören ilk kullanıcı onu siler. Bu doğanın kanunlarından biridir. 

Peki oluşturduğumuz dosya ve dizinler hangi kurala göre erişim haklarına sahip oluyorlar? Bunu belirleyen şey umask değeridir. Ubuntu 20.04 üzerinde umask komutunu çalıştıralım. 

$ umask 

0002 

Şimdi bir dosya ve dizin oluşturup erişim haklarına bakalım. Dosya için 664, dizin için 775 erişim haklarıyla oluşturulduğunu göreceğiz. Demek ki dosya oluştururken umask değerini 666’dan, dizin oluştururken 777’den çıkartarak erişim hakları belirleniyor. 

Yazının başlangıcında dosya sisteminin de bu yeterliliklere sahip olması gerektiğini söylemiştim. Erişebildiğiniz herhangi bir vfat dosya sistemi ile biçimlendirilmiş disk üzerinde dosya oluşturup onun erişim haklarını değiştirmeyi denediğinizde bunu yapamadığınızı göreceksiniz. Bunun nedeni vfat’in erişim haklarını düzenlemeye imkan vermemesidir. 

Buraya kadar sanki işletim sisteminde gerek duyulan bütün erişim hakları problemleri çözülmüş gibi gelebilir. Şimdi önce yeni bir ihtiyacı ve onun için üretilmiş yeni çözümü görelim: 

/etc/shadow dosyasında her kullanıcı için birer satır bulunur. Bu satırların ikinci sütununda kullanıcıların parolalarının gölgelenmiş halleri bulunur. Bu dosyanın erişim hakları şöyledir: 

-rw-r----- 1 root shadow 1,7K Ara 17 20:20 /etc/shadow 

Görüyorum ki benim yetkili kullanıcı olmayan bir kullanıcıyla bu dosyada değil değişiklik yapmam, dosyayı okumam bile mümkün değil. Diğer yandan biliyoruz ki her kullanıcı kendi parolasını değiştirebiliyor. Bir kullanıcı kendi parolasını passwd komutuyla değiştirebilir. Bu komutun erişim haklarına bakalım. 

-rwsr-xr-x 1 root root 67K May 28 2020 /usr/bin/passwd 

Şimdilik dördüncü karakter olarak x yerine s olmasına takılmayalım. Biliyoruz ki süreçler kendilerini çalıştıran kullanıcıların yetkileriyle çalışırlar. Yani bir kullanıcı hangi dosyalara yazabiliyorsa onun çalıştırdığı süreçler de ancak o dosyalara yazabilirler. Peki nasıl oluyor da benim yazamadığım bir dosyaya benim çalıştırdığım bir süreç (/usr/bin/passwd) yazabiliyor? İşte bunu sağlayan erişim hakkına SUID bit deniyor. Bir dosyayı kim çalıştırırsa çalıştırsın sanki onu sahibi çalıştırmış gibi davransın isteniyorsa ona aşağıdaki gibi bir erişim hakkı vermek gerekir. 

$ chmod u+s /tmp/testfile 

Burada sıkça karıştırılan şey bu erişim hakkının ancak root kullanıcısı tarafından verilebileceği konusudur. Bu komutla her kullanıcı SUID bit erişim yetkisini bir dosyaya verebilir ama böyle yaparak sadece dosya üzerindeki kendi yetkilerini onu çalıştırma hakkı olan diğer kullanıcılara vermiş olacağını aklımızdan çıkarmamak gerekir. Bir dosyayı kim çalıştırırsa çalıştırsın sanki onun ait olduğu grubun bir üyesiymiş gibi çalıştırmasını istersek ona aşağıdaki komutla SGID bit erişim yetkisini vermiş oluruz. 

$ chmod g+s /tmp/testfile 

Yukarıda bir dosyaya veya dizine 777 erişim haklarını vermemek gerektiğini, böyle bir erişim hakkı verildiğinde onu ilk gören kullanıcının sileceğini söylemiştim. /tmp dizini tam da böyle bir erişim hakkına ihtiyaç duyar; bu dizine bütün kullanıcılar (oturum açma izni olmayan sistem kullanıcılar dahil) yazabilmelidir. Bizim istediğimiz şey bu dizine her kullanıcının yazabilmesi ama kullanıcıların sadece kendi oluşturdukları dosyaları değiştirebilmesidir. Bu erişim hakkı şimdiye kadar bahsettiğimiz erişim haklarıyla düzenlenemez. Bunu sticky bit erişim yetkisiyle aşağıdaki gibi düzenleyebiliriz. 

$ chmod o+t /tmp/testdizin 

Sticky bit erişim hakkı verilmiş bir dizine bütün kullanıcılar yazabilir ama sadece kendi sahip oldukları dosyaları değiştirebilirler. Bazı kullanıcıların bazı dosyaları sanki root kullanıcısı gibi çalıştırmalarını sağlayan sudo aracı da mevcut olmakla birlikte onu erişim hakları arasında sınıflamamak daha doğru olacaktır. Konunun daha iyi anlaşılabilmesi için aşağıdaki sorulara cevap vermeye çalışmak iyi bir pratik olacaktır. 

  • Okuyamadığınız bir dosyaya yazmanız nasıl mümkün olabilir? Anlamlı bir örnek verebilir misiniz? 
  • Biliyoruz ki dizinler değil dosyalar çalıştırılabilir. Bir dizinin çalıştırılması ne anlama gelir? 
  • umask değeri nasıl değiştiriliyor? Nasıl kalıcı hale getiriliyor? 
  • Bir dizine SUID bit erişim hakkı verilebilir mi? Verilebilirse bu ne anlama gelir? 
  • Bir dizine SGID bit erişim hakkı verilebilir mi? Verilebilirse bu ne anlama gelir?
  • Sticky bit erişim hakkı bir dosyaya verilebilir mi? Verilebilirse bu ne anlama gelir?

Yazıda bahsedilen konuyu dinlemek isteyen olursa diyerek bağlantısını bırakıyorum.


 

29 Aralık 2020 Salı

Yalansavar'ın 2019 yılı için yaptığı kehanetler 2020'de ne kadar gerçekleşti?

Geçen yıl yazdığım bir yazıyla [1] Yalansavar [2] ekibinin 2019 yılı için yaptığı kehanetlerin ne kadarının tuttuğunu bir bağımsız denetleme kuruluşu olarak incelemiştim. Yaptığım akademik incelemenin bir sonucu olarak 10 kehanetin tamamının tutmuş olduğunu hayretler içinde görmüştüm. Işıl Arıcan, Serdar Başeğmez ve Tevfik Uyar'ın bu konu hakkında yaptıkları çok eğlenceli podcast'i [3] dinlemenizi öneririm. Programda 2020 için de öngördükleri şeyler vardı ve eminim yine güzel bir podcast ile bunu konuşurlar ama ben yine madem bağımsız bir denetleme kuruluşuyum neden yapılmayanı yapmıyorum diyerek başka bir inceleme yapmaya karar verdim.

Hem sıkıcı olmamak için, hem de Yalansavar podcast'inin sürprizini bozmak istemediğimden bu sefer 2019 için yapılan kehanetlerin 2020'de ne ölçüde gereçekleştiğine bakacağız birlikte. Her ne kadar Yalansavar ekibinin her sene gerçekleşecek iddiası olmasa bile kehanetlerinin yıllara sığmayan gücünü görmek onları da şaşırtacaktır diye tahmin ediyorum. Şimdi üç skeptik kahinimizin öngörülerine ve 2020 için karşılıklarına bakalım.

Işıl Arıcan

  • Trump kabinesi büyük bir skandalla sallanacak!
Bu kehaneti bundan sonraki yıllar için Amerikan başkanı olarak okumak gerekecek olsa da bu yıl Trump kabinesi öyle sallandı ki seçimi kaybetti [4]. Ortada Trump kabinesi diye bir şey kalmadı.
  • Uzakdoğu'da veya Asya'da büyük bir deprem olacak ve beraberinde tsunami görülebilir!
Diğer pek çok depremin yanında 30 Ekim 2020'de İzmir'de meydana gelen deprem ve tsunaminin [5] bu kadar uzaktan bilinebilmiş olması eminim sizi de çok şaşırtmıştır.
  • Şöhretin zirvesindeki bir yıldız intihar ederek hepimizi üzecek

Sizi bilmem ama ben Yūko Takeuchi'nin intiharına [7] üzülmüştüm. Bu habere üzülmeyenler Işıl Arıcan'ın kehanet gücünü değil kendi vicdanlarını sorgulasınlar.

Işıl Arıcan'ın 2019 yılı için yaptığı kehanetlerin 2020 için dahi %100 başarılı olması benim diyen kahinleri düşüncelere sevk etmiştir diye umuyorum.

Serdar Başeğmez

  • Siyasetin zirvesinden bir yıldız kayacak!

Siyasetçiler bu seneyi de kayıpsız kapatmadılar ve kehanet tuttu. NY Times'ın hazırladığı uzun listeye [7] bakılabilir.

  • Sözdebilime devlet katında çok büyük bir engel gelecek!

Nature'da çıkan "Pseudoscience and COVID-19 — we’ve had enough already" başlıklı uzun makaleden [9] devlet katında bir engel ifadesini çıkartmak mümkün olur mu bilemiyorum. Bir ilave bilgi gelmezse bu kehaneti tutmamış saymak icap ediyor.

  • Nobel sürpriz bir isme gidecek!

Milliyet'in sayfasında [8] Nobel edebiyat ödülünün Louise Glück'e verilmesinin sürpriz olup olmadığını okumak isteyebilirsiniz belki. Bu kehanetten de Serdar Başeğmez'e tam puan veriyoruz.

  • 2019'un çok başlarında bugüne kadar görmediğimiz parlak bir kırmızı ay göreceğiz ve bu özellikle Kuzey Amerika gibi bir yerlerde görülecek!

Bir sonraki kanlı ay 26 Mayıs 2021'de gözlenebileceğinden bu kehaneti tutmuş kabul edemiyoruz [10]. Yine de dönem dönem ayın kırmızı göründüğünü söyleyenler olacaktır. Tartışmaya açık bir konu olduğundan belki bu bölümü daha sonra düzenleyebilirim.

Serdar Başeğmez'in 4 kehanetinden ikisini doğrulayabildiğim :) için ortalaması %50 oluyor. Elimizdeki verilere bakınca sayın Başeğmez'in kehanetlerinin 2021 senesinde en azından %75 doğrulukla gerçekleşeceğini söyleyebiliriz.

Tevfik Uyar

  • Afrika'da veya Amerika'da patlak verecek yeni bir bela insanlığın önemli bir kısmını tehdit edebilir!

Keşke tutmasaydı diyeceğimiz bu kehanet için covid-19'dan [11] başka bir kanıta gerek yoktur sanırım.

  • Ciddi büyüklüğe sahip depremler olabilir ve bundan on binlerce kişi etkilenebilir!

Sayın Uyar'ın ciddi büyüklükle kastının ne olduğunu bilemesek de 7 ve üzerinde şiddete sahip 9 deprem olmuş 2020 içinde [12]. 2016'dan bu yana 8 şiddetinde deprem olmayan ilk yıl 2020 olmuş. Dünyanın başında covid belası varken bir de böyle büyük felaketin olmaması büyük şans diyor ve bu kehanetten de tam puan veriyoruz.

  • Büyük devletlerden birinde ekonomik dalgalanma yaşanabilir ve bunun sonucunda bazı halk hareketleri ortaya çıkabilir!

Covid sonrası neredeyse bütün ülkelerde ekonomik dalgalanmalar olduğu ve bunun vatandaşları çok zor durumlara soktuğu hepimizin malumu olduğundan ayrıca bir bağlantı vermiyorum [13].

Böylece Tevfik Uyar'ın kehanetlerinin tutma oranı da %100'e ulaşmış oluyor.

Kehanetlerin geneline baktığımızda kast edildiği yıl için %100 bir başarı oranı varken, aynı kehanetlerin bir sonraki yıl için dahi %80 oranında doğruluk göstermiş olması nice skeptiklere acaba dedirtmiştir sanırım.


[1] https://www.nyucel.com/2019/11/yalansavarn-2019-kehanetleri-ne-kadar.html

[2] https://yalansavar.org

[3] https://yalansavar.org/2020/02/03/podcast-21-2019-kehanetleri/

[4] https://www.bbc.com/turkce/haberler-dunya-55014827 

[5] https://en.wikipedia.org/wiki/2020_Aegean_Sea_earthquake

[6] https://en.wikipedia.org/wiki/Yuko_Takeuchi

[7] https://www.nytimes.com/interactive/2020/obituaries/notable-deaths-politics-public-affairs.html

[8] https://www.milliyet.com.tr/2020-nobel-edebiyat-odulu-nu-louise-gluck-un-kazanmasi-surpriz-mi--molatik-17403/

[9] https://www.nature.com/articles/d41586-020-01266-z

[10] https://www.space.com/39471-what-is-a-blood-moon.html

[11] Bunun için bir bağlantı bekleyen yoktur sanırım.

[12] https://en.wikipedia.org/wiki/List_of_earthquakes_in_2020

[13]

Soğuk Kahve Demlemeye (Cold Drip) Radikal Yaklaşımlar - 1

Bir zamandır kahve demlemek ve içmekle ilgileniyorum. Eskiden de içiyordum ama ne olduğu çok farketmiyor gibiydi. Hakkında biraz okuyunca [4...