Belki almayı düşünenlere faydası olabilir diyerek daha önce Kindle Keyboard (2010), Kindle Paperwhite (2013) ve Kindle Voyage (2015) kullanmış biri olarak yeni aldığım Kindle Oais hakkında yazayım istiyorum.
* Oasis'in diğer kindle'lardan en önemli farkı bence 7" ekranı. Diğer kindle'ların ekranları 6" iken Oasis onlardan daha uzun değil ama daha geniş. Elinize alınca basılı kitaplara daha yakın bir oranda olduğunu hissediyorsunuz.
* 300 ppi çözünürlüğü ile daha fazlasını aramayacağınız bir okumaya deneyimi sunan Oasis'in aydınlatması da benim bundan önce kullandığım tüm kindle'lardan daha başarılı. Yanlardan yapılan aydınlatmaların hangi noktadan geldiği belli olmayacak kadar başarılı bir tasarımı var. Parlaklığı otomatik ayarlama konusunda da çok iyi.
* Su geçirmiyor oluşu bir ekitap okuyucu için nasıl bir ihtiyaç çözemesem de böyle bir özelliği olduğunu da not düşeyim.
* Metal yüzeyi bir ekitap okuyucu için berbat. Tamamen metalden yapılmış yüzeyi asla ısınmıyor ve elinizdekinin kitaptan çok farklı bir şey olduğunu sürekli hissediyorsunuz.
* Cihazın küçük bir kısmı cep telefonunuz kadar kalınken geri kalan kısım yarısı kalınlığında. Önce bunun elimde tutarken bir denge sorununa yol açacağını düşünmüştüm ama öyle olmadı. İnce tarafı gerçekten çok ince.
* Amazon eski kindle'lara kulaklık girişi koymasına rağmen sonradan bunu kaldırmıştı. Oasis ile birlikte kulaklık girişi geri gelmese de bluetooth bağlantı imkanı getirilmiş. Görme engelliler ve sesli kitap dinlemek isteyenler için kullanışlı olacağını düşünüyorum.
* Disk kapasitesi en az 8gb olarak satılıyor ama ekitaplar o kadar az yer kaplıyor ki bu benim için ciddi bir getiri sayılmaz.
* Sayfa değiştirmek için hem dokunmatik ekran hem de yanlardaki tuşları kullanmak mümkün. Dokunmatik ekranı etkisiz hale getirmek de mümkün.
* Amazon hala kullanılabilir bir tarayıcı geliştirebilmiş değil. Neden temel işlevleri yerine getirebilen bir tarayıcı yazdırmıyorlar insan hayret ediyor.
* Ekranı hala renkli değil.
* Şarjı diğer kindle'lara kıyasla dramatik derecede az dayanıyor. Eskiden Voyage'ı ayda bir şarj ederken Oasis'i haftada bir şarj ediyorum. Cihazın inceliğinin arkasındaki pilden alındığını tahmin etmek güç değil ama şarjdan vazgeçip daha ince bir kindle alma hayalim yoktu doğrusu.
* 250$'lık fiyatıyla çok çok pahalı.
7 Kasım'da piyasaya çıkacak Paperwhite'ın son hali 130$ olacak ve o da su geçirmeyecekmiş (kimin ihtiyacı varsa). Bence bekleyip onu alın. 7" ekran ve aydınlatması çok başarılı ama bu kadar az şarj ve bu fiyata Oasis almayın.
31 Ekim 2018 Çarşamba
23 Nisan 2018 Pazartesi
Google Summer of Code 2018
Bu yıl kabul edilen bizim çocuklar:
Dara Akdağ: Upgrading Ontology Tagging at WikiPathways
Cem Başsoy: Designing a Generic Tensor Library for Boost.uBlas
Semih Serhat Karakaya: Integration of Nextcloud/ownCloud as Storage and User File Provider
Kaan Sancak: PathwayMapper Improvements and Integration into cBioPortal
Alper Çakan: WebVLMC (Remote UI for VLMC)
Mert Tümer: LibreOffice Android Viewer
Talat Uyarer: Redis Implementation For Gora
Ahmet Tanakol: Generating JSON Editors based on JSON Schema
Doğukan Çelik: A calendar database of social events and conferences
Furkan Tokaç: Improve handling for touchpads and mice with Libinput
Ahmet Çandıroğlu: Improvements for Newt, a Cytoscape.js based SBGN editor
Meraklısı için: 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
Dara Akdağ: Upgrading Ontology Tagging at WikiPathways
Cem Başsoy: Designing a Generic Tensor Library for Boost.uBlas
Semih Serhat Karakaya: Integration of Nextcloud/ownCloud as Storage and User File Provider
Kaan Sancak: PathwayMapper Improvements and Integration into cBioPortal
Alper Çakan: WebVLMC (Remote UI for VLMC)
Mert Tümer: LibreOffice Android Viewer
Talat Uyarer: Redis Implementation For Gora
Ahmet Tanakol: Generating JSON Editors based on JSON Schema
Doğukan Çelik: A calendar database of social events and conferences
Furkan Tokaç: Improve handling for touchpads and mice with Libinput
Ahmet Çandıroğlu: Improvements for Newt, a Cytoscape.js based SBGN editor
Meraklısı için: 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
1 Ekim 2017 Pazar
Hangi Masaüstü Ne Kadar Türkçe Konuşuyor? -10-
Dönem dönem düşen masaüstü ortamlarının çeviri oranlarının çok yükseldiği bir zamanda yazabildiğim için mutluyum. Aşağıdaki rakamlara bakınca bir GNU/Linux dağıtımı kullanmanın önündeki (eğer varsa) engellerden birinin yerelleştirme olmadığını rahatça söyleyebiliriz sanırım.
KDE: Geçen yıl %81 olan KDE çeviri oranı büyük bir artış göstererek %94 seviyesine çıktı. Daha önce neredeyse hiç çevirisi olmayan yardım içeriğinin de %8'i Türkçeye çevrildi. Çok yakında daha yükseğe çıkacağını tahmin ediyorum. KDE'nin en çok yerelleştirildiği 12. dil Türkçe.
GNOME: Geçen yıl %90 olan çeviri oranı %99'a yükseldi. Yardım içeriği neredeyse hiç çevrilmeden duruyor.
Enlightenment: Geçen yıl %74 olan çeviri oranı %73'e geriledi.
XFCE: Xfce web sayfası da dahil olmak üzere %100 çeviri oranına sahip.
LXDE: Lxde projesinde yer alan bütün yazılımlar %100 Türkçe çevirisine sahip.
LibreOffice: Özgür ofis paketi LibreOffice'de çeviri durumu çok iyi. Bütün sürümlerin arayüzleri %100 Türkçe'ye çevrilmiş durumda. Yardım içerikleri de %99 civarında yerelleştirildi.
Çevirmenlerin ve onlara destek olanların eline sağlık!
KDE: Geçen yıl %81 olan KDE çeviri oranı büyük bir artış göstererek %94 seviyesine çıktı. Daha önce neredeyse hiç çevirisi olmayan yardım içeriğinin de %8'i Türkçeye çevrildi. Çok yakında daha yükseğe çıkacağını tahmin ediyorum. KDE'nin en çok yerelleştirildiği 12. dil Türkçe.
GNOME: Geçen yıl %90 olan çeviri oranı %99'a yükseldi. Yardım içeriği neredeyse hiç çevrilmeden duruyor.
Enlightenment: Geçen yıl %74 olan çeviri oranı %73'e geriledi.
XFCE: Xfce web sayfası da dahil olmak üzere %100 çeviri oranına sahip.
LXDE: Lxde projesinde yer alan bütün yazılımlar %100 Türkçe çevirisine sahip.
LibreOffice: Özgür ofis paketi LibreOffice'de çeviri durumu çok iyi. Bütün sürümlerin arayüzleri %100 Türkçe'ye çevrilmiş durumda. Yardım içerikleri de %99 civarında yerelleştirildi.
Çevirmenlerin ve onlara destek olanların eline sağlık!
20 Eylül 2017 Çarşamba
XXII. Türkiye'de İnternet Konferansı, Akademik Bilişim 2018 ve 3. Kamu Açık Kaynak Konferansı
Türkiye'de İnternet Konferanslarının yirmi ikincisi bu yıl 2-4 Kasım 2017 tarihlerinde Bahçeşehir Üniversitesinde yapılacak.
3. Kamu Açık Kaynak Konferansı ise 25-26 Ekim 2017 tarihleri arasında ATO Congresium'da düzenlenecek.
Yirminci Akademik Bilişim Konferansı için Karabük Üniversitesi ev sahibi olacak ve 31 Ocak - 2 Şubat 2018 tarihlerinde gerçekleşecek.
Bilişim camiasının bu üç büyük buluşmasını takvimlerinize şimdiden işaretleyin de sonradan keşke haberim olsaydı demeyin.
3. Kamu Açık Kaynak Konferansı ise 25-26 Ekim 2017 tarihleri arasında ATO Congresium'da düzenlenecek.
Yirminci Akademik Bilişim Konferansı için Karabük Üniversitesi ev sahibi olacak ve 31 Ocak - 2 Şubat 2018 tarihlerinde gerçekleşecek.
Bilişim camiasının bu üç büyük buluşmasını takvimlerinize şimdiden işaretleyin de sonradan keşke haberim olsaydı demeyin.
28 Mayıs 2017 Pazar
Özgür yazılım ile açık kaynağın ne farkı var?
Özgür Yazılım hareketi 1983'de başlayan ve kullanıcıların yazılımları çalıştırma, anlama, değiştirme ve değiştirdikleri halini dağıtma özgürlüklerini savunan bir harekettir. Açık Kaynak ise neredeyse aynı ilkeleri farklı ifadelerle savunan ve 1998'de ortaya çıkan, özgür yazılım topluluğunun içinden çıkan bir oluşumdur. Özgür Yazılım hareketinin başlatıcısı Stallman açık kaynağı bir yazılım geliştirme metodolojisi, özgür yazılımı ise bir sosyal hareket olarak görmektedir. Stallman uzun yıllardır neden kendisini bir açık kaynak savunucusu olarak kabul etmediğini yazılarıyla ve konuşmalarıyla anlatıyor olsa da çok fazla anlaşıldığı söylenemez. Bu yazıda ikisi arasında bir fark var mı ve biz hangi ifadeyi kullanmalıyız konularını tartışmak istiyorum.
[1] http://www.nyucel.com/2017/05/genel-kamu-lisansnn-gpl-onemli-fark.html
[2] http://www.nyucel.com/2017/05/ack-kaynak-sadece-kaynak-koda-erisim.html
[3] http://www.nyucel.com/2017/05/ozgur-yazlm-m-ack-kaynak-m-1.html
Lisans
Bir yazılımla ne yapabileceğinizi belirleyen şey onun özgür yazılım veya açık kaynak olması değil o yazılımın kullandığı lisanstır. Temel kavramları aynı bile olsa her özgür yazılım lisansı aynı kullanım şartlarını sunmaz. Watcom lisansı gibi neredeyse kimsenin kullanmadığı lisansları bir tarafa bırakırsak bütün açık kaynak yazılım lisanslarının aynı zamanda özgür yazılım lisansı olarak kabul edildiğini görürüz. Konuya lisanslar açısından bakınca özgür yazılımlar ile açık kaynak yazılımlar arasında bir fark yoktur [3].
Yanlış anlamalar
Türkçe konuşan insanlar olarak "free software" ifadesinde yaşanan "bedava" mı "özgür" mü karışıklığını yaşamıyor olmamıza rağmen "open source" yazılım denildiğinde sadece kaynak kodu açık olan yazılımın anlaşılması gibi sorunla, İngilizce konuşanlar gibi, karşı karşıya kalıyoruz. Özgür yazılım denildiğinde arkasında yazılımın ve kullanıcıların özgürlüklerini önemseyen, onun için mücadele eden bir felsefe olduğunu anlamak kolay olmasına rağmen maalesef onun hakkında da kafa karışıklığı az değil. Genel Kamu Lisansı (GPL) en bilinen özgür yazılım lisanslarının başında geliyor olmasına rağmen tek özgür yazılım lisansı değil. GPL özgür yazılımın dört şartına ek olarak Copyleft kavramını da kullanmaktadır. Özgür yazılımın şartları yazılımı sizin nasıl haklarla edineceğinizi belirlerken Copyleft onu nasıl dağıtmanız gerektiğini söyler. Yani Copyleft özelliğine sahip bir lisansla lisanslanmış bir yazılımı yine aynı şartlarla dağıtmanız gerekir [1]. Bütün özgür yazılım lisanslarının böyle bir zorunluluğu olmamasına rağmen maalesef genel kanı bu yönde ülkemizde.
Açık kaynak ise ülkemizde en az anlaşılan kavramlardan biri. Bunda adının yaptığı çağrışımın etkisi de büyük elbette. Hem kullanıcılar, hem de önemli miktarda geliştirici bir yazılımın kaynak kodunu görebildiğinde onu açık kaynak sanmak gibi bir kavramsal hataya düşüyor [2]. Github benzeri bir kod barındırma ortamına yazılımının kaynak kodlarını koyan bir yazılımcı onun hemen açık kaynak olduğu yanılgısına kapılıyor.
Açık kaynak yanlış anlaşılmaya çok müsait olduğundan açık kaynak ifadesini her kullandığımızda onun kaynağı açık olan yazılım anlamına gelmediğini ve mevcut 10 şartını anlatmak oldukça zor bir iştir. Bunu yapmadığımızda hem özgür yazılım hem de açık kaynak hareketlerinin uğraştıkları konuları önemsememiş oluruz. Özgür yazılım dediğimizde birilerinin kafasını karıştırma riski oldukça düşüktür. Günümüzde gittikçe artan bir hızla özel mülk yazılımların da kaynak kodlarının açıldığını hesaba katarak, insanları yanlış yönlendirmemek için açık kaynak yerine özgür yazılım ifadesini kullanmak daha doğru bir hareket olacaktır.
Açık kaynak ise ülkemizde en az anlaşılan kavramlardan biri. Bunda adının yaptığı çağrışımın etkisi de büyük elbette. Hem kullanıcılar, hem de önemli miktarda geliştirici bir yazılımın kaynak kodunu görebildiğinde onu açık kaynak sanmak gibi bir kavramsal hataya düşüyor [2]. Github benzeri bir kod barındırma ortamına yazılımının kaynak kodlarını koyan bir yazılımcı onun hemen açık kaynak olduğu yanılgısına kapılıyor.
Açık kaynak yanlış anlaşılmaya çok müsait olduğundan açık kaynak ifadesini her kullandığımızda onun kaynağı açık olan yazılım anlamına gelmediğini ve mevcut 10 şartını anlatmak oldukça zor bir iştir. Bunu yapmadığımızda hem özgür yazılım hem de açık kaynak hareketlerinin uğraştıkları konuları önemsememiş oluruz. Özgür yazılım dediğimizde birilerinin kafasını karıştırma riski oldukça düşüktür. Günümüzde gittikçe artan bir hızla özel mülk yazılımların da kaynak kodlarının açıldığını hesaba katarak, insanları yanlış yönlendirmemek için açık kaynak yerine özgür yazılım ifadesini kullanmak daha doğru bir hareket olacaktır.
Düşmanımız açık kaynak değil özel mülk yazılımdır
Özgür yazılım taraftarları olarak sıklıkla açık kaynak ifadesini özgür yazılım olarak düzeltiyoruz. Bunu kafa karışıklığına neden olmamak için yaptığımız halde, istemeden de olsa, sanki açık kaynağın kötü bir şey olduğu algısını da yaratabiliyoruz. Halbuki durum böyle değil. Özgür yazılım ve açık kaynak hareketleri kullanıcıların özgürlüklerini savunan hareketlerdir. Biz özgür yazılım savunucuları açık kaynağı düşman olarak görmeyiz. Hem özgür yazılımın hem de açık kaynak yazılımın insanlık için kötü olarak kabul ettiği yazılımlar özgür olmayan (özel mülk) yazılımlardır.
We in the free software movement don't think of the open source camp as an enemy; the enemy is proprietary (nonfree) software.
[2] http://www.nyucel.com/2017/05/ack-kaynak-sadece-kaynak-koda-erisim.html
[3] http://www.nyucel.com/2017/05/ozgur-yazlm-m-ack-kaynak-m-1.html
20 Mayıs 2017 Cumartesi
Özgür Yazılım mı Açık Kaynak mı?
Yazılım lisansları son kullanıcı tarafında neredeyse hiç okunmayan metinler olmalarına rağmen yazılım geliştiriciler arasında bile yaygın olarak okundukları söylenemez. Elbette son kullanıcının yazılım lisansıyla ilişkisi geliştiriciden çok farklıdır. Elindeki yazılımı nasıl değiştireceği, başka bir yazılım içinden nasıl çağırabileceği, statik mi dinamik mi derlemesi gerektiği, kendi koduna birlikte dahil edebileceği yazılımların lisanslarının nasıl olması gerektiği gibi konularla ilgilenmez son kullanıcı. Bu bahsettiğim durumlarda geliştiricilerin nasıl davranması gerektiği lisans metinlerinde genellikle ayrıntılı olarak tarif edilir.
Son kullanıcı genellikle yazılımı özgürce kullanabiliyor mu, başkasıyla paylaşabiliyor mu, gelecekte de kullanabilecek mi, güvenli mi gibi konularla ilgilenir. Son kullanıcının yazılımın lisansını okumadan da onunla ilgili neler yapabileceğini öğrenmesinin bir yolu yazılım lisansının hangi sınıfa girdiğini ve o sınıftaki yazılımların belirleyici özelliklerini bilmesidir. Eğer yazılım bir özgür yazılımsa onunla yapılabilecek şeyler çok kısa ve net bir şekilde belirlidir [1]. Biraz daha fazla madde içeren açık kaynak bir yazılımın şartları da net olarak tarif edilmiş durumdadır [2]. Örneğin elde ettiğiniz yazılım GPLv3 ile lisanslanmışsa ve bu lisansın bir özgür yazılım lisansı olduğunu biliyorsanız diğer ayrıntılarla çok ilgilenmeden onu gönül rahatlığıyla kullanabilirsiniz.
Özgür yazılım ve açık kaynak lisanslarıyla ilgili şartları okuduğunuzda aradaki farkı kolayca anlamanız mümkün olmayabilir. Bu sizi tedirgin etmesin zaten büyük kalabalıkların da durumu böyle. Bir yazılıma açık kaynak dediğinizde biri sizi "hayır o özgür yazılım" diye uyarıyorsa "arada ne fark var?" diye sorun. Çok büyük ihtimalle açıklayamayacaktır. Bu yazıyı çok uzatmamak için aradaki kavramsal ayrılıkları bir başka yazıya bırakıp burada hangi lisanslar özgür yazılım, hangileri açık kaynak kategorisine giriyor göstermek istiyorum.
Hangi lisansların özgür yazılım kategorisine girdiğini görmek isteyenler buraya [3], açık kaynak yazılım lisanslarının hangileri olduğunu görmek isteyenler buraya [4] bakabilirler. Özgür yazılımla ilgili bağlantıya bakarsanız (biliyorum çoğunluk bakmayacak) hangi lisansların GPL-uyumlu olduğunu, hangilerinin GPL uyumlu olmasa da özgür yazılım olduğunu görebilirler. Hangi lisansların özgür yazılım lisansı olarak kabul edilmediği de nedenleriyle birlikte açıklanmış durumda. Bir lisansın GPL-uyumlu olması o lisansla yazılmış bir kodun GPL lisanslı bir yazılıma dahil edilip dağıtılabileceği anlamına gelir.
Aşağıdaki lisanslar hem GPLv3-uyumlu özgür yazılım lisansları, hem de açık kaynak lisanslarıdır. Sayıları sizi şaşırtacak kadar fazla olan bu lisansların listesi şöyle:
[1] http://www.nyucel.com/2017/05/genel-kamu-lisansnn-gpl-onemli-fark.html
[2] http://www.nyucel.com/2017/05/ack-kaynak-sadece-kaynak-koda-erisim.html
[3] https://www.gnu.org/licenses/license-list.html
[4] https://opensource.org/licenses/alphabetical
Son kullanıcı genellikle yazılımı özgürce kullanabiliyor mu, başkasıyla paylaşabiliyor mu, gelecekte de kullanabilecek mi, güvenli mi gibi konularla ilgilenir. Son kullanıcının yazılımın lisansını okumadan da onunla ilgili neler yapabileceğini öğrenmesinin bir yolu yazılım lisansının hangi sınıfa girdiğini ve o sınıftaki yazılımların belirleyici özelliklerini bilmesidir. Eğer yazılım bir özgür yazılımsa onunla yapılabilecek şeyler çok kısa ve net bir şekilde belirlidir [1]. Biraz daha fazla madde içeren açık kaynak bir yazılımın şartları da net olarak tarif edilmiş durumdadır [2]. Örneğin elde ettiğiniz yazılım GPLv3 ile lisanslanmışsa ve bu lisansın bir özgür yazılım lisansı olduğunu biliyorsanız diğer ayrıntılarla çok ilgilenmeden onu gönül rahatlığıyla kullanabilirsiniz.
Özgür yazılım ve açık kaynak lisanslarıyla ilgili şartları okuduğunuzda aradaki farkı kolayca anlamanız mümkün olmayabilir. Bu sizi tedirgin etmesin zaten büyük kalabalıkların da durumu böyle. Bir yazılıma açık kaynak dediğinizde biri sizi "hayır o özgür yazılım" diye uyarıyorsa "arada ne fark var?" diye sorun. Çok büyük ihtimalle açıklayamayacaktır. Bu yazıyı çok uzatmamak için aradaki kavramsal ayrılıkları bir başka yazıya bırakıp burada hangi lisanslar özgür yazılım, hangileri açık kaynak kategorisine giriyor göstermek istiyorum.
Hangi lisansların özgür yazılım kategorisine girdiğini görmek isteyenler buraya [3], açık kaynak yazılım lisanslarının hangileri olduğunu görmek isteyenler buraya [4] bakabilirler. Özgür yazılımla ilgili bağlantıya bakarsanız (biliyorum çoğunluk bakmayacak) hangi lisansların GPL-uyumlu olduğunu, hangilerinin GPL uyumlu olmasa da özgür yazılım olduğunu görebilirler. Hangi lisansların özgür yazılım lisansı olarak kabul edilmediği de nedenleriyle birlikte açıklanmış durumda. Bir lisansın GPL-uyumlu olması o lisansla yazılmış bir kodun GPL lisanslı bir yazılıma dahil edilip dağıtılabileceği anlamına gelir.
GPLv3 uyumlu özgür yazılım ve açık kaynak lisansları
Aşağıdaki lisanslar hem GPLv3-uyumlu özgür yazılım lisansları, hem de açık kaynak lisanslarıdır. Sayıları sizi şaşırtacak kadar fazla olan bu lisansların listesi şöyle:
- 2-clause BSD License (BSD-2-Clause)
- 3-clause BSD License (BSD-3-Clause)
- Apache License 2.0 (Apache-2.0)
- Artistic License 2.0 (Artistic-2.0)
- Boost Software License (BSL-1.0)
- CeCILL License 2.1 (CECILL-2.1)
- EU DataGrid Software License (EUDatagrid)
- eCos License version 2.0
- Educational Community License, Version 2.0 (ECL-2.0)
- Eiffel Forum License V2.0 (EFL-2.0)
- GNU Affero General Public License version 3 (AGPL-3.0)
- GNU General Public License version 2 (GPL-2.0)
- GNU General Public License version 3 (GPL-3.0)
- GNU Lesser General Public License version 2.1 (LGPL-2.1)
- GNU Lesser General Public License version 3 (LGPL-3.0)
- Historical Permission Notice and Disclaimer (HPND)
- ISC License (ISC)
- MIT License (MIT)
- Mozilla Public License 2.0 (MPL-2.0)
- Python License (Python-2.1)
- Sleepycat License (Sleepycat)
- Universal Permissive License (UPL)
- W3C License (W3C)
- wxWindows Library License (WXwindows)
- Zope Public License 2.0 (ZPL-2.0)
- zlib/libpng license (Zlib)
GPLv3 uyumlu olmayan özgür yazılım ve açık kaynak lisansları
Bazı özgür yazılım lisansları GPL-uyumlu olmayabiliyor. Genel Kamu Lisansının diğer özgür yazılım lisanslarından farkını daha önce yazmıştım, belki okumak isteyebilirsiniz şimdi [1]. GPL uyumlu olmadığı halde özgür yazılım lisansı olan lisansların sayısı da az değil. Bunların arasından açık kaynak lisansı olarak da adı geçenlerin listesi de şöyle:- Academic Free License 3.0 (AFL-3.0)
- Apple Public Source License (APSL-2.0)
- Common Public Attribution License 1.0 (CPAL-1.0)
- Eclipse Public License 1.0 (EPL-1.0)
- European Union Public License, Version 1.1 (EUPL-1.1)
- IBM Public License 1.0 (IPL-1.0)
- LaTeX Project Public License 1.3c (LPPL-1.3c)
- Lucent Public License Version 1.02 (LPL-1.02)
- Microsoft Public License (MS-PL)
- Microsoft Reciprocal License (MS-RL)
- Mozilla Public License 1.1 (MPL-1.1)
- Nokia Open Source License (Nokia)
- Open Software License 3.0 (OSL-3.0)
- PHP License 3.0 (PHP-3.0)
- Q Public License (QPL-1.0)
- RealNetworks Public Source License V1.0 (RPSL-1.0)
- Sun Public License 1.0 (SPL-1.0)
- Zero Clause BSD License (0BSD)
Açık kaynak olduğu halde özgür yazılım olmayan lisanslar
Peki açık kaynak olduğu halde özgür yazılım lisansı olarak kabul edilmeyen lisanslar neler? diye soruyor olmalısınız şimdi? Eğer özgür yazılımın ve açık kaynağın şartlarını okumuşsanız bunun kolay kolay sağlanamayacak bir durum olduğunu biliyor olmalısınız ama [3] ve [4] adreslerinde adı geçen ve bu şartı sağlayan sadece bu kadar az lisans olduğunu okumak sizi şaşırtacaktır sanırım. Eğer bu lisanslardan biriyle lisanslanmış bir yazılıma açık kaynak derseniz doğruyu söylemiş olurken, özgür yazılım derseniz hatalı bilgi vermiş olursunuz.- NASA Open Source Agreement 1.3 (NASA-1.3)
- Reciprocal Public License 1.5 (RPL-1.5)
- Sybase Open Watcom Public License 1.0 (Watcom-1.0)
Arada hiç mi fark yok?
Her ne kadar neredeyse bütün açık kaynak yazılımlar özgür yazılım olmanın kriterlerini yerine getiriyor olsalar da doğrusu yazılım kendisini nasıl tanımlıyorsa o terimi kullanmaktır. Örneğin Genel Kamu Lisansı ile lisanslanmış bir yazılım kendini açık kaynak olarak tanımlıyorsa ona açık kaynak demek doğrusudur ama tersini söylemekte de teknik olarak hatalı bir durum olmadığı herkesçe açık olmalı.Özgür yazılım ve açık kaynak aynı şey mi?
Yukarıda okuduğunuz şeylere rağmen özgür yazılım ve açık kaynak farklı dünya görüşlerini temsil eden fikirler. Bu konu hakkında ayrı bir yazı okumak isterseniz buradan okuyabilirsiniz.
[1] http://www.nyucel.com/2017/05/genel-kamu-lisansnn-gpl-onemli-fark.html
[2] http://www.nyucel.com/2017/05/ack-kaynak-sadece-kaynak-koda-erisim.html
[3] https://www.gnu.org/licenses/license-list.html
[4] https://opensource.org/licenses/alphabetical
16 Mayıs 2017 Salı
Özgür yazılım penceresinden WannaCry
Birkaç gündür neredeyse bütün haberlerde bir fidye yazılımı olan WannaCry hakkında okuyoruz. Microsoft'un bütün işletim sistemlerini etkileyen bir samba açığından faydalanan bu yazılım kullanıcıların bilgisayarlarındaki dosyaları şifreledikten sonra 300$ ödeme yapmaları halinde bu durumdan kurtulabileceklerini anlatan bir mesaj gösteriyor. İşin teknik kısmı hakkında çokça yazılıp çizildiğinden bu yazıda başka bir konudan; özgür yazılımın yaşananlara nasıl bakması gerektiğinden bahsetmek istiyorum. Sadece Microsoft'un işletim sistemlerini etkileyen bu büyük açığı bir avantajmış gibi kullanmadan önce aşağıdaki konularda düşünmemiz gerekiyor.
Neden özgür yazılım kullanılsın istiyoruz?
Biz özgür yazılımları daha güvenli oldukları, daha hızlı oldukları veya daha özelleştirilebilir oldukları için mi kullanıyoruz? Toplam sahip olma maliyetleri daha düşük diye mi özel mülk yazılımlar yerine özgür yazılımları tercih ediyoruz? Özgür yazılımlar bu saydığım avantajlara hatta daha fazlasına sahip oldukları halde sahipli yazılımlar karşısındaki gerçek üstünlükleri bunlar değil elbette. Özgür yazılımları herkesin istediği amaçlar için çalıştıramadığı, programın nasıl çalışabildiğini anlayamadığı, ihtiyacına uygun şekilde değiştiremediği, elindeki yazılımı dağıtmasının önünde kısıtlamaları olan sahipli yazılımlarla karşılaştırmaya buradan başlamamamız gerekir. Eğer temel argümanımız hız, güvenlik, ucuzluk olursa yarın sahipli bir yazılım bu konularda öne geçtiğinde söyleyecek sözümüz kalmaz. Kendimizi kandırmayalım bazıları hali hazırda bu konuların bazılarında daha ilerideler ama biz yine de özgür yazılımları kullanma taraftarıyız. İnsanların özgürce kullanıp, dağıtamadığı yazılımları özgür yazılımlarla kıyaslamaya başlamadan önce onların minimum insani ihtiyaçları karşılamaları gerekir [1]. İnsanlara, şirketlere, kamuya neden özgür yazılımlar kullanmaları gerektiğini doğru argümanlarla açıklamak çok önemli [2].
Özgür yazılım kullanılsaydı benzer bir durumla karşılaşılamaz mıydı?
Elbette karşılaşılabilirdi. Hatta karşılaşıldı da. GNU/Linux ve *BSD'lerde en çok kullanılan kabuk olan bash'in bu hatayla karşılaştırılabilecek büyüklükte bir hatası olan shellshock ancak 25 yıl sonra farkedilebildi. Bash'in kaynak kodları bu süre boyunca hepimizin gözlerinin önündeydi hem de. Bu yazdıklarımdan elbette kaynak kodların erişilebilir olmasının güvenlikle ilgili olumlu etkisinin olmayacağı anlamı çıkartılmamalıdır [3]. Bugün yaygın olarak kullanılan bir özgür yazılıma eklenen kodlara dünyanın her köşesinden geliştiriciler, geliştirici adayları ve meraklılar bakıyor. Kaynak kodlarını göremediğimiz bir yazılıma bir arka kapı kolaylıkla eklenebilirken aynı şeyi bir özgür yazılıma yapmak (imkansız demeyeyim ama) çok çok zordur. Durum böyle olmasına rağmen özgür yazılımlarda güvenlik sorunu hiç olmaz dememek gerekir, çünkü yaşadığımız örnekler var. Bugün wannacry sadece Windows'ta yaşanıyor siz GNU/Linux kullanın dersek yarın shellshock benzeri bir durumda söyleyecek sözümüz kalmaz. Bizim temel argümanımız özgürlük olmalıdır ve bu GNU/Linux kullanın demek için yeterlidir.
Microsoft'un neredeyse kimsenin kullanmadığı samba-v1'e hala destek veriyor olması görülmedik bir şey midir?
Geriye uyumluluk bütün yazılımların ciddi sorunlardan biri durumunda maalesef. Eski sürümlere destek verildiğinde böyle şeyler olabilirken desteğin kesilmesi de başka sorunlara yol açabiliyor bazen. Windows10'a bile samba-v1.0 desteğini vermesi elbette Microsoft'un kabahati ama bu hiç yapılmayan bir yanlış da değil. Neredeyse her yerde TLS 1.2 kullanılırken SSL'in eski sürümlerine verilen desteğin suistimal edilmesi yüzünden yaşadığımız şeyler üzerinden çok da uzun zaman geçmedi. Microsoft zamanında Windows'lardan bu desteği kaldırabilirdi ve bu onu daha iyi bir işletim sistemi yapmazdı. Bizim windows ve diğer sahipli işletim sistemlerini kullanmayın dememizin arkasında yatan şey onların tasarım ve planlama hataları değil özgür olmamalarıdır.
Microsoft Windows XP kullanıcılarına bir şey borçlu mu?
Microsoft'un Windows XP'yi piyasaya sürüş tarihi 2001. Elimizi vicdanımıza koyup konuşalım hangi işletim sistemine 16 yıl destek veriliyor? Dört yıl önce XP desteği artık sona erdi diye de yazdılar. XP çıktığı tarihte piyasada olan Debian 2.2 veya Redhat 6.2 için destek alamadığından şikayetçi kimse var mı? Aradan geçen bunca yılda kamunun kaynaklarını bir özgür işletim sistemine geçişte kullanmamış ve hala Windows XP kullandıran yöneticiler kusura bakmasınlar ama suçun önemli bir kısmı onları üzerinde.
WannaCry'dan etkilenenler elbette sadece XP kullanıcıları değil bütün Windows sürümlerinin kullanıcıları oldu ama tahmin edilenin çok üzerinde XP kullanıcısı olduğu da görülmüş oldu. Bir kurumun yöneticisi arka planda ne yaptığını bilmediği, en temel insani ilkelere uygun olmayan bir işletim sistemini kullandırıyorsa suçu Microsoft'a atamaz bence.
GNU/Linux veya BSD'ler Windows'un alternatifi mi?
Özgür yazılımdan, özgür işletim sistemlerinden sanki Windows'un alternatifiymiş gibi bahsetmeyi kabul edilemez buluyorum. Bu konuda daha önce çokça yazdığım için tekrarlamak yerine aşağıya bağlantılarını bırakıyorum. [4], [5], [6]
11 Mayıs 2017 Perşembe
Genel Kamu Lisansının (GPL) önemli farkı: Copyleft
Özgür yazılım sade ve güçlü bir mekanizma üzerine kurulu bir felsefe. Özel mülk yazılım lisansları nasıl firmaları koruyan hükümler içeriyorsa özgür yazılım lisansları da kullanıcıları, yani toplumu korumaya çalışıyorlar. Bir yazılım lisansının özgür yazılım lisansı kabul edilebilmesi için ilgili yazılımla ilgili aşağıdaki dört temel özgürlüğü garanti etmesi gerekiyor:
Aslında kullanıcılar da bir yazılımı kullanmadan önce onun getirdiği kısıtlamaları ve sağladığı özgürlükleri öğrenebilmek için bu lisansları okumalı ama hem metinler yer yer teknik ifadeler içeriyor hem de çok uzunlar. Asıl bağlayıcı metinler İngilizce olanlar olmasına rağmen Linux Kullanıcıları Derneğinin kamuoyunun kullanımına sunduğu Özgür Yazılım Lisansları sayfası oldukça yararlı olacaktır. Eğer yazılım geliştiricisi değilseniz özgür yazılımın temel kavramlarını ve kullandığınız yazılımın bir özgür yazılım olduğunu bilmek yeterli bir güven zinciri oluşmasını sağlayabilir.
İdeal bir dünyada yukarıdaki dört şart yeterli olabilecekken günümüz dünyasında özgür yazılımların özel mülk yazılımlara dönüştürülmesinin önüne geçmek için bazı önlemler almak gerekmektedir. Genel Kamu Lisansının yukarıdaki şartlara ek olarak getirdiği en önemli farklılık Copyleft'tir.
Copyleft yazılımınızın mevcut halinin ve/veya değiştirilmiş halinin de özgür yazılım olarak kalmasını garantilemenin bir yoludur. Copyleft bir özgür yazılımı alan kişilere onun özgün halini ve/veya değiştirilmiş halini yine özgür yazılım olarak dağıtmaları gerektiğini söyler. Yani elde ettiğiniz Copyleft özelliğine sahip bir yazılımı aldığınız özgürlükleri aynen devretmeden dağıtamazsınız. Bu şartın bütün özgür yazılımlara ait olmadığını sadece Copyleft'in bir getirisi olduğunu akıldan çıkartmamak gerekir. Bütün özgür yazılımların böyle zorunlulukları yoktur. Bazı özgür yazılım lisansları aldığınız yazılımın kaynak kodunu kapatıp özel mülk yazılım olarak dağıtmanıza bile izin verir. GPL Copyleft özelliğini taşıyan bir özgür yazılım lisansıdır. Özgür yazılımların bir listesi için bu adrese bakabilirsiniz.
Copyright, yani telif hakkı, kullanıcıların özgürlüklerini kısıtlamak için kullanılan bir terim iken Copyleft bu özgürlüklerin devam etmesini garanti altına almaya yöneliktir. Adının çağrıştırdığının aksine Copyleft, Copyright'ın tersi değil onu kullanmanın bir yoludur. Copyleft yazılımın telif hakkından vazgeçmek anlamına gelmediği gibi eğer telif hakkından vazgeçerseniz Copyleft'in kullanımının şartları ortadan kalkmış olur. Yani telif hakkına sahip olmadığınız bir yazılımın nasıl dağıtılacağına zaten karışamazsınız.
Yazdığınız kodu Genel Kamu Lisansıyla nasıl lisanslayabileceğinize dair bu yazıyı da okumak isteyebilirsiniz.
- Yazılımı herhangi bir amaç için çalıştırma özgürlüğü,
- Yazılımın nasıl çalıştığını öğrenme ve onu değiştirme özgürlüğü,
- Yazılımı yeniden dağıtma özgürlüğü,
- Yazılımın değiştirilmiş halinin dağıtılabilmesi özgürlüğü.
Aslında kullanıcılar da bir yazılımı kullanmadan önce onun getirdiği kısıtlamaları ve sağladığı özgürlükleri öğrenebilmek için bu lisansları okumalı ama hem metinler yer yer teknik ifadeler içeriyor hem de çok uzunlar. Asıl bağlayıcı metinler İngilizce olanlar olmasına rağmen Linux Kullanıcıları Derneğinin kamuoyunun kullanımına sunduğu Özgür Yazılım Lisansları sayfası oldukça yararlı olacaktır. Eğer yazılım geliştiricisi değilseniz özgür yazılımın temel kavramlarını ve kullandığınız yazılımın bir özgür yazılım olduğunu bilmek yeterli bir güven zinciri oluşmasını sağlayabilir.
İdeal bir dünyada yukarıdaki dört şart yeterli olabilecekken günümüz dünyasında özgür yazılımların özel mülk yazılımlara dönüştürülmesinin önüne geçmek için bazı önlemler almak gerekmektedir. Genel Kamu Lisansının yukarıdaki şartlara ek olarak getirdiği en önemli farklılık Copyleft'tir.
Copyleft yazılımınızın mevcut halinin ve/veya değiştirilmiş halinin de özgür yazılım olarak kalmasını garantilemenin bir yoludur. Copyleft bir özgür yazılımı alan kişilere onun özgün halini ve/veya değiştirilmiş halini yine özgür yazılım olarak dağıtmaları gerektiğini söyler. Yani elde ettiğiniz Copyleft özelliğine sahip bir yazılımı aldığınız özgürlükleri aynen devretmeden dağıtamazsınız. Bu şartın bütün özgür yazılımlara ait olmadığını sadece Copyleft'in bir getirisi olduğunu akıldan çıkartmamak gerekir. Bütün özgür yazılımların böyle zorunlulukları yoktur. Bazı özgür yazılım lisansları aldığınız yazılımın kaynak kodunu kapatıp özel mülk yazılım olarak dağıtmanıza bile izin verir. GPL Copyleft özelliğini taşıyan bir özgür yazılım lisansıdır. Özgür yazılımların bir listesi için bu adrese bakabilirsiniz.
Copyright, yani telif hakkı, kullanıcıların özgürlüklerini kısıtlamak için kullanılan bir terim iken Copyleft bu özgürlüklerin devam etmesini garanti altına almaya yöneliktir. Adının çağrıştırdığının aksine Copyleft, Copyright'ın tersi değil onu kullanmanın bir yoludur. Copyleft yazılımın telif hakkından vazgeçmek anlamına gelmediği gibi eğer telif hakkından vazgeçerseniz Copyleft'in kullanımının şartları ortadan kalkmış olur. Yani telif hakkına sahip olmadığınız bir yazılımın nasıl dağıtılacağına zaten karışamazsınız.
Yazdığınız kodu Genel Kamu Lisansıyla nasıl lisanslayabileceğinize dair bu yazıyı da okumak isteyebilirsiniz.
7 Mayıs 2017 Pazar
SSH sunucusuna nasıl güveniyoruz?
SSH ve HTTPS bir çok yönden benzeyen protokoller. Daha önce HTTPS hakkında yazdığım için benzer şeyleri tekrar etmek yerine SSH'ın temel bir farkından bahsetmek istiyorum.
Bir SSH bağlantısı için istemci ve sunucu önce selamlaşıyor, ardından sunucu sertifikasını gönderiyor, istemci sertifikayı onayladıktan sonra sertifika içindeki açık anahtarla bir oturum anahtarı oluşturuluyor ve iletişim bu anahtarla şifrelenerek yapılıyor. HTTPS ile olan bu benzerliğin en önemli farkı sertifikayı onaylama kısmı oluyor. HTTPS için kullanılan sertifikalar çoğunlukla güvenilen Sertifika Otoriteleri (CAs) aracılığı ile üretildiğinden tarayıcılarımız sertifikaları onaylamak için onları kolaylıkla kullanabiliyor. SSH için kullanılan sertifikalar ise hemen hemen her zaman sunucu tarafında kendinden imzalı bir şekilde üretiliyor. SSH bağlantısının bütün güvenliği bu sertifikanın güvenilir olması üzerine kurulu olduğundan istemcinin bu sertifikayı bir şekilde onaylaması gerekiyor. SSH istemcilerinin sertifikaları onaylamak için farklı seçenekleri var:
Sunucu anahtarının parmak izinin kontrolü
Bir SSH sunucusuna bağlanmak için ilk isteği yaptığımızda aşağıdaki gibi bir durumla karşılaşıyoruz.
Bu aşamada eğer sunucu anahtarının parmak izini bilmiyorsak onaylayabileceğimiz bir şey de yok demektir. İlk aşamada "8iz5L6iZxKJ6YONmad4oMbC+m/+vI9vx5C5f+qTTGDc" gibi bir ifadenin ezberlenmesi imkansız gibi görünse de yapılamaz değil ama oldukça zor olduğunu kabul edelim.
Randomart kullanmak
Sunucunun anahtarının parmak izi yerine ondan üretilmiş bir konsol görselini akılda tutmak daha kolay bir seçenek. Eğer ssh'ı "-o VisualHostKey=yes" parametresiyle kullanırsak aşağıdaki gibi bir görsel görüp onu onaylayabiliriz:
Hem sunucu anahtarının parmak izi hem de ondan oluşturulan bu görsel tek yönlü fonksiyonlar kullanılarak üretildiklerinden tamamen aynısı değil de çok küçük (mesela tek karakterlik) bir farkla üretilemezler. Yani tamamını hatırlamasak bile genel olarak aklımızda tutarak bile sertifikayı onaylayabiliriz aslında.
DNS kullanarak
Sunucu anahtarının parmak izinin doğruluğunu bizim yerimize onaylayabilecek bir mekanizma olması işimizi çok kolaylaşmaz mıydı? Sertifikaları kendimiz oluşturduğumuz için bir CA'dan yardım alamıyoruz ama SSH bağlantısını makine adıyla yapıyorsak mecburen kullanmak zorunda olduğumuz DNS sunucuları burada imdadımıza yetişiyor. Makine adına karşılık gelen IP adresini nasıl DNS sunucusuna sorabiliyorsak aynı şekilde sunucu anahtarının parmak izini de sorabiliriz. Bu işlemi de "-o VerifyHostKeyDNS=yes" parametresiyle yapıyoruz. Eğer sunucumuzla ilgili böyle bir DNS kaydı girilmişse aşağıdaki gibi bir cevap alırız sunucudan:
DNS sunucusuna eklenecek tek satırlık bir girdi ile kullanıcılarımıza bu imkanı sunabilecekken neden kullanılmıyor bilemiyorum doğrusu. Belki bu yazıyı okuduktan sonra siz kullanırsınız ;)
6 Mayıs 2017 Cumartesi
HTTPS nasıl çalışıyor?
HTTPS kullandığımızda internet trafiğimizin şifrelendiğini biliyoruz. Gizlilik, mahremiyet gibi bizim için çok önemli olan konularda güvendiğimiz bu protokolün nasıl çalıştığını kısaca açıklamak istiyorum.
Aslında HTTPS standart HTTP protokolünün TLS şifrelemesi ile kaplanması anlamına geliyor. Gönderip aldığınız veriyi araya giren birinin anlam çıkaramayacağı şekilde şifrelediği için değiştirilmesinin de önüne geçer. Bu sayede HTTPS kullanarak gönderdiğimiz kullanıcı adı ve parolamız, kredi kartı bilgilerimiz ve hatta ulaştığımız sayfanın adresi (https://en.wikipedia.org/wiki/HTTPS gibi) trafiğimizi dinleyenlerce görülemez. HTTPS ile temelde iki ana hedef gerçekleştirilir:
Bu hedeflere ulaşabilmek için ilk yapılacak şey TLS bağlantısının kurulmasıdır. HTTP için kullandığımız istemci (çoğu durumda tarayıcımız) TLS bağlantısının kurulması için de aracılık eder. Taraflar aralarında aşağıdaki gibi anlaşırlar:
[1] https://www.nyucel.com/2019/07/guvensiz-kanaldan-anahtar-degisimi.html
Aslında HTTPS standart HTTP protokolünün TLS şifrelemesi ile kaplanması anlamına geliyor. Gönderip aldığınız veriyi araya giren birinin anlam çıkaramayacağı şekilde şifrelediği için değiştirilmesinin de önüne geçer. Bu sayede HTTPS kullanarak gönderdiğimiz kullanıcı adı ve parolamız, kredi kartı bilgilerimiz ve hatta ulaştığımız sayfanın adresi (https://en.wikipedia.org/wiki/HTTPS gibi) trafiğimizi dinleyenlerce görülemez. HTTPS ile temelde iki ana hedef gerçekleştirilir:
- Ulaştığımız adresin gerçekte ulaşmaya çalıştığımız adres olduğundan emin olunması,
- Sunucu ve istemci arasındaki trafiğin sadece bu iki taraf tarafından çözümlenebilecek şekilde şifrelenmesi.
Bu hedeflere ulaşabilmek için ilk yapılacak şey TLS bağlantısının kurulmasıdır. HTTP için kullandığımız istemci (çoğu durumda tarayıcımız) TLS bağlantısının kurulması için de aracılık eder. Taraflar aralarında aşağıdaki gibi anlaşırlar:
- İstemci sunucuya bir "client hello" mesajı gönderir. Bu mesajda istemcinin desteklediği protokolün sürümü ve tercih ettiği kriptografik algoritmaların listesi bulunur.
- İlk mesajı alan sunucu istemciye bir "server hello" mesajı gönderir. Bu mesajda ise istemciden aldığı listeden seçilen kriptografik algoritma ve oturum ID'si bulunur. Sunucu ayrıca sayısal sertifikasını da gönderir. Sunucunun istemciyi doğrulaması gereken durumlarda bir de "client certificate request" mesajı gönderilir ama biz bunun gerekmediğini varsayacağız.
- Bu aşamadan sonrasına devam edilebilmesi için istemcinin sunucu sertifikasını onaylaması gerekir. Bir sunucu sertifikası aşağıdaki bilgileri içerir:
- Sertifikanın sahibi,
- Sertifikanın geçerli olduğu alan veya makine adı,
- Sunucunun açık anahtarı,
- Sertifikanın geçerli olduğu tarih aralığı,
- Sertifikanın sayısal imzası.
- Bu sertifika eğer istemcinin güvendiği bir Sertifika Otoritesi (CA) tarafından üretilmişse veya bu aşamada istemci sertifikayı güvenli bulursa sertifikanın onaylanması adımı geçilmiş olur. Aksi durumda iletişime devam edilmez. Tarayıcılarımızın bizi "bağlantı güvenli değil" diyerek uyardığı sayfaları gördüğümüz nokta burası oluyor.
- Henüz sunucu ve istemci arasında yapılmasını planladığımız trafiğin başlamadığını unutmadan devam edelim. Bulunduğumuz durumda istemci sunucudan aldığı sertifikaya güvenebileceğini doğruladı ama sunucunun bu sertifikanın gerçek sahibi olduğunu henüz doğrulamış değil. Sunucu bu sertifikayı kendisiyle iletişime geçen herkese gönderdiği için bu sertifikayı ele geçişmiş herhangi bir taraf bizi yanıltıyor olabileceğinden bunu da doğrulaması gerekiyor. Bunun doğrulaması da sertifika içinde bulunan sunucunun açık anahtarıyla gerçekleştiriliyor. İstemci bu açık anahtarı kullanarak sunucuya bir veri gönderdiğinde ancak sunucu o açık anahtarla ilişkili gizli anahtara sahipse veriyi deşifreleyebilecektir.
- Artık istemci ve sunucu bu açık anahtarı ve bir anahtar değişim algoritmasını kullanarak oturum boyunca verileri şifreli gönderip almak için bir ortak anahtar oluşturabilirler [1].
- Simetrik şifrelemede kullanılacak anahtar oluşturulduktan sonra istemci sunucuya bir "finished" mesajını bu anahtarla şifreleyerek gönderir. Bu noktadan sonra taraflar aralarında simetrik şifreleme algoritmalarından birini kullanırlar.
- Mesajı alan sunucu da aynı anahtarla şifreleyerek "finished" mesajını istemciye iletir. Böylece her iki taraf da şifrelemede kullanacakları bir ortak anahtar üzerinde anlaşmış ve birbirlerini doğrulamış olurlar.
[1] https://www.nyucel.com/2019/07/guvensiz-kanaldan-anahtar-degisimi.html
4 Mayıs 2017 Perşembe
Google Summer of Code 2017
Bu yıl kabul edilen bizim çocuklar:
Memduh Gökırmak: Crimean Tatar-Turkish MT
Mustafa Özçelikörs: A4MCAR: A Distributed and Parallel Demonstrator for Eclipse APP4MC
Okan Aşık: JdeRobot GSOC'17 Application for Visual HFSM Project
Altay Adademir: Project IX: Expanding the Extension Manager
Asil Kaan Bozcuoglu: Knowledge and Learned Model Exchange Between Robotic Agents using openEASE
Gökhan Gurbetoğlu: Improvements to Notebookbar
Muhammet Kara: Revamp the Customization dialog
Hasan Balcı: Cytoscape.js Extension for Querying Large Networks
Duygu Keşkek: SunPy Website Improvements
Candan Eylül Kilsedar: OSM extrusion adapter
Semih Serhat Karakaya: Security App
Alperen Karaoğlu: Performance Co-Pilot Project Proposal: Blocked process detection and reporting
Canberk Koç: Store integration for Taler merchants
Meraklısı için: 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
Memduh Gökırmak: Crimean Tatar-Turkish MT
Mustafa Özçelikörs: A4MCAR: A Distributed and Parallel Demonstrator for Eclipse APP4MC
Okan Aşık: JdeRobot GSOC'17 Application for Visual HFSM Project
Altay Adademir: Project IX: Expanding the Extension Manager
Asil Kaan Bozcuoglu: Knowledge and Learned Model Exchange Between Robotic Agents using openEASE
Gökhan Gurbetoğlu: Improvements to Notebookbar
Muhammet Kara: Revamp the Customization dialog
Hasan Balcı: Cytoscape.js Extension for Querying Large Networks
Duygu Keşkek: SunPy Website Improvements
Candan Eylül Kilsedar: OSM extrusion adapter
Semih Serhat Karakaya: Security App
Alperen Karaoğlu: Performance Co-Pilot Project Proposal: Blocked process detection and reporting
Canberk Koç: Store integration for Taler merchants
Meraklısı için: 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
2 Mayıs 2017 Salı
Açık kaynak sadece kaynak koda erişim anlamına gelmez!
Açık kaynak (open source) Türkçede nadiren doğru kullanılan bir terim. Özgür yazılım yerine bilerek/bilmeyerek açık kaynak denildiği gibi bazen de sadece kaynak kodun ulaşılabilir olması bile bir yazılıma açık kaynak denilmesine neden olabiliyor. Özgür yazılım ile açık kaynak yazılım arasındaki farkları başka bir yazıya bırakarak burada bir yazılımın açık kaynak yazılım sayılabilmesi için gerekli koşulları açıklayalım.
Açık kaynak girişimi genel kanının aksine özgür yazılım hareketinden çok sonra başlamıştır. Özgür yazılım gönüllülerinin taraftarı olmadıkları bir yazılım felsefesi olsa da açık kaynak yazılımların sadece kaynak kodlarının açık olduğu, başka bir özgürlüğü beraberinde getirmediği fikrini maalesef çok yaygın olarak duyuyoruz. Hatta özel mülk bir yazılımın kaynak kodunu github benzeri bir ortamda görenlerin onu açık kaynak yazılım sanması bile az rastlanır bir şey değil. Aslında son derece açık bir konu olmasına rağmen en çok kafa karışıklığına neden olan konulardan da biri. Bir açık kaynak yazılım lisansının sağlaması gereken şartlar aşağıdaki gibi:
1. Ücretsiz yeniden dağıtım
Bir açık kaynak yazılım lisansı ile yazılımın satışı veya başka yazılımların bir parçası olarak dağıtılması kısıtlanamaz ve bu satışlardan bir pay talep edilemez.
Açık kaynak girişimi genel kanının aksine özgür yazılım hareketinden çok sonra başlamıştır. Özgür yazılım gönüllülerinin taraftarı olmadıkları bir yazılım felsefesi olsa da açık kaynak yazılımların sadece kaynak kodlarının açık olduğu, başka bir özgürlüğü beraberinde getirmediği fikrini maalesef çok yaygın olarak duyuyoruz. Hatta özel mülk bir yazılımın kaynak kodunu github benzeri bir ortamda görenlerin onu açık kaynak yazılım sanması bile az rastlanır bir şey değil. Aslında son derece açık bir konu olmasına rağmen en çok kafa karışıklığına neden olan konulardan da biri. Bir açık kaynak yazılım lisansının sağlaması gereken şartlar aşağıdaki gibi:
Bir açık kaynak yazılım lisansı ile yazılımın satışı veya başka yazılımların bir parçası olarak dağıtılması kısıtlanamaz ve bu satışlardan bir pay talep edilemez.
2. Kaynak kod
Programın kaynak kodu içermesi ve derlenmiş haline olduğu gibi kaynak kodun da dağıtılmasına izin vermesi gereklidir. Programın kaynak kodu içermeyen bir biçimi varsa tercihen web adresinden ücretsiz indirilmesine izin verilmelidir. Kaynak kodun bir programcının değiştirebileceği bir biçimde olması gerekir. Kasten karmaşıklaştırılmış veya bir çeviriciden geçirilmiş kodlar kabul edilmez.
Programın kaynak kodu içermesi ve derlenmiş haline olduğu gibi kaynak kodun da dağıtılmasına izin vermesi gereklidir. Programın kaynak kodu içermeyen bir biçimi varsa tercihen web adresinden ücretsiz indirilmesine izin verilmelidir. Kaynak kodun bir programcının değiştirebileceği bir biçimde olması gerekir. Kasten karmaşıklaştırılmış veya bir çeviriciden geçirilmiş kodlar kabul edilmez.
3. Türetilen işler
Bir açık kaynak lisansı değişikliklere ve türetilen işlere izin vermeli ve onların özgün yazılımın lisansı ile aynı şartlarda dağıtılmasına izin vermelidir.
4. Yazarın kaynak kodunun bütünlüğü
Lisans yazılımın kaynak kodunun değiştirilmiş halinin dağıtılmasını ancak tek bir durumda kısıtlayabilir. Bunun mümkün olabilmesi için yazılım kaynak koduyla birlikte derleme zamanında kullanılabilecek yama dosyalarının dağıtımına izin verilmelidir. Böyle bir şey yapıldığında lisansta açıkça yazılımın değişiklik yapılmış kaynak koddan derlenebileceği belirtilmelidir. Yazılım kaynak kodda değişiklik yapılıp derlendiğinde isminin veya sürüm numarasının değiştirilmesini gerekli kılabilir.
Lisans yazılımın kaynak kodunun değiştirilmiş halinin dağıtılmasını ancak tek bir durumda kısıtlayabilir. Bunun mümkün olabilmesi için yazılım kaynak koduyla birlikte derleme zamanında kullanılabilecek yama dosyalarının dağıtımına izin verilmelidir. Böyle bir şey yapıldığında lisansta açıkça yazılımın değişiklik yapılmış kaynak koddan derlenebileceği belirtilmelidir. Yazılım kaynak kodda değişiklik yapılıp derlendiğinde isminin veya sürüm numarasının değiştirilmesini gerekli kılabilir.
5. Kişi veya gruplara yönelik ayrımcılık yapılamaz
Yazılım lisansıyla herhangi bir kişiye veya gruba yönelik bir kısıtlama getirilemez. Bazı ülkelerin ticaret kanunları böyle şeyler yapmayı zorunlu kılıyor olabilir ama lisansta bu yasalara uyma gerekliliğini hatırlatılabilir ancak kendisi bu kısıtlamalara dahil olamaz.
Yazılım lisansıyla herhangi bir kişiye veya gruba yönelik bir kısıtlama getirilemez. Bazı ülkelerin ticaret kanunları böyle şeyler yapmayı zorunlu kılıyor olabilir ama lisansta bu yasalara uyma gerekliliğini hatırlatılabilir ancak kendisi bu kısıtlamalara dahil olamaz.
6. Çalışma alanına yönelik ayrımcılık yapılamaz
Yazılımın herhangi bir amaç için çalıştırılması engellenemez. Örneğin bir yazılımın ticari kullanım veya genetik araştırmalar için kullanılması kısıtlanamaz.
7. Lisansın dağıtımı
Programa eklenen haklar ayrıca bir sözleşmeye gerek kalmadan programın yeniden dağıtıldığı herkes için geçerli olmalıdır.
8. Lisans bir ürüne özgü olmamalı
Programa eklenen haklar, programın belirli bir yazılım dağıtımının parçası olmasına bağlı olmamalıdır. Program bu dağıtımdan çıkarılır ve lisans koşulları dahilinde kullanılır veya dağıtılırsa, programın yeniden dağıtıldığı tüm taraflar, orijinal yazılım dağıtımı ile birlikte verilenlerle aynı haklara sahip olmalıdır. Örneğin bir ofis paketini açık kaynak lisanslarından biriyle lisansladığınızda bileşenlerinden birinin ancak bu paketle birlikte kullanıldığında lisansla verilen haklara sahip olacağını söyleyemezsiniz. Her bir bileşen ayrı ayrı da kullanılsa lisans aynen geçerli olmalıdır.
Programa eklenen haklar, programın belirli bir yazılım dağıtımının parçası olmasına bağlı olmamalıdır. Program bu dağıtımdan çıkarılır ve lisans koşulları dahilinde kullanılır veya dağıtılırsa, programın yeniden dağıtıldığı tüm taraflar, orijinal yazılım dağıtımı ile birlikte verilenlerle aynı haklara sahip olmalıdır. Örneğin bir ofis paketini açık kaynak lisanslarından biriyle lisansladığınızda bileşenlerinden birinin ancak bu paketle birlikte kullanıldığında lisansla verilen haklara sahip olacağını söyleyemezsiniz. Her bir bileşen ayrı ayrı da kullanılsa lisans aynen geçerli olmalıdır.
9. Lisans diğer yazılımları kısıtlamamalı
Lisans, lisanslı yazılımla birlikte dağıtılan diğer yazılıma kısıtlamalar getirilmemelidir. Örneğin, lisans, aynı ortamda dağıtılan diğer tüm programların açık kaynaklı yazılım olması gerektiğinde ısrar etmemelidir. GPL ile lisanslanan yazılımlar da bu koşulu sağlarlar. Bu koşulu yazılımınızda GPL lisanslı bir kod parçasını veya GPL lisanslı bir kitaplığı kullanmanız durumunda yazılımınızı da GPL ile lisanslamanız gerekmesiyle karıştırmamak gerekir. Bir GNU/Linux dağıtımının açık kaynak lisanslı bir programı dağıtması onun sadece benzer lisanslı yazılımları dağıtabileceği anlamına gelmemesi gibi düşünülebilir.
Lisans, lisanslı yazılımla birlikte dağıtılan diğer yazılıma kısıtlamalar getirilmemelidir. Örneğin, lisans, aynı ortamda dağıtılan diğer tüm programların açık kaynaklı yazılım olması gerektiğinde ısrar etmemelidir. GPL ile lisanslanan yazılımlar da bu koşulu sağlarlar. Bu koşulu yazılımınızda GPL lisanslı bir kod parçasını veya GPL lisanslı bir kitaplığı kullanmanız durumunda yazılımınızı da GPL ile lisanslamanız gerekmesiyle karıştırmamak gerekir. Bir GNU/Linux dağıtımının açık kaynak lisanslı bir programı dağıtması onun sadece benzer lisanslı yazılımları dağıtabileceği anlamına gelmemesi gibi düşünülebilir.
10. Lisans bir teknolojiye bağımlı olmamalıdır
Lisansın hiçbir hükmü bir teknolojiye veya arayüze bağımlı olmamalıdır. Kullanıcının bir arayüzde koşulları kabul etmesi ve bir düğmeye tıklaması gibi zorunluluklar karşısında alternatifsiz bırakmasına izin verilmemektedir.
Gördüğümüz gibi bir yazılımın açık kaynak lisansına sahip olması onun sadece kaynak kodlarına ulaşılabildiği anlamına gelmediği gibi açık kaynak bir yazılımı alıp kaynak kodunu (lisans özellikle buna izin vermiyorsa) kapatarak dağıtamazsınız. Açık kaynak yazılım lisanslarının listesine buradan bakabilirsiniz.
29 Nisan 2017 Cumartesi
Kaynak kodun açık olması güvenliği nasıl etkiler?
Özgür yazılımla yeni tanışmış olanların aklına ilk gelen sorulardan biri kaynak kodun açık olmasının bir güvenlik sorunu oluşturup oluşturmayacağı oluyor. Madem programın kaynak kodu ortada saldırganlar bunu saldırı için de kullanabilirler, bu da olumlu bir şey değil diye düşünüyor büyük kalabalıklar. Güvenlikle ilgili neredeyse bütün yazılımların kaynak kodlarının açık olması, kullandığımız bütün şifreleme araçlarının kodlarının ortada olması içinizi rahatlatmıyorsa birlikte bakalım durum gerçekten böyle mi?
Algoritmayı gizleyerek güvenlik sağlanamaz
Kriptografi dersinin başlangıcında anlatılan konu budur: bir algoritmayı gizleyerek onu daha güvenli hale getiremezsiniz. Konuyla ilgisi yok ama gizlenmesi gereken şey algoritma değil anahtar olmalıdır. Eğer güvenlik için tek dayanağınız algoritmanın gizliliği olursa o sızdırıldığında (saklanmak istenen her şey bir gün sızdırılacaktır) algoritmanın yenilenmesi gerekecektir. Bunun ne kadar büyük maliyetli bir iş olacağı düşünülünce açıklıktan başka alternatif olmadığı da görülecektir.
Hatasız yazılım olmaz!
Yazdığınız programın kaynak kodunu ister açın isterseniz kapalı tutun mutlaka hatalar/açıklar içerecektir. Yazılımı tek başınıza sizin yazmış olmanız veya bir grupla geliştirmiş olmanız bu gerçeği değiştirmeyecektir. Ne kadar kalabalık bir geliştirici topluluğunuz olursa hatalar da o kadar azalacaktır. Benzer şekilde test için projeye ayırabileceğiniz kaynak da hataların azaltılmasına olumlu katkıda bulunacaktır. Projenizin kaynak kodlarını geliştirici ekipten başka kimsenin görmesine izin vermezseniz bütün bu yük sizin üzerinizde olacaktır. Halbuki projenizi bir özgür yazılım veya açık kaynak lisansıyla lisanslarsanız kaynak kodlarınıza başkaları da bakıp hataları size bildirebilecek veya daha da iyisini yapıp iyileştirmeleri size gönderebilecektir. Eğer benim projeme kim bakacak diyorsanız kendi endişenizi kendiniz ortadan kaldırmışsınız demektir ama projenizi dışarıdan katkı almaya uygun bir şekilde lisanslarsanız projeye ayıracağınız bütçe ile bedelini ödeyemeyeceğiniz geliştiricilere ve testçilere kavuşabilirsiniz.Özgür yazılımlara daha çok göz bakar
Yazılımın geliştiricisi değil de kullanıcısı iseniz daha çok kişi tarafından ortaklaşa geliştiriliyor olması ve daha fazla test edilmiş olması sizin için daha az hata barındıran bir yazılım anlamına gelecektir. Neden bir şirketin çalıştırabileceği sınırlı sayıda yazılım geliştiriciye güvenebilirken dünyanın dört bir tarafına dağılmış çok daha büyük kalabalıklara güvenmeyeceksiniz? Hangi şirket bir tarayıcı yaklaşık 5000 kişinin kod göndermesine, yani yazılımın kodlarını okumasına kaynak ayırabilir? Bunu ancak özgür yazılımın gücü sağlayabilir.Yazılımların hataları çoğunlukla kod okuyarak bulunmaz
Bir projenin kaynak kodlarını okuyup hatasını bulmak tahmin edilenden çok daha zor bir iştir. Elbette yazılımların hataları, açıkları kodları da okunarak tespit edilebilir ama yukarıdaki örneğe bakarsanız yaklaşık 16 milyon satırlık bir projede bunun pek kolay bir iş olmayacağını tahmin edebilirsiniz. Peki yazılımların açıkları nasıl bulunuyor? Belirli koşullar altındaki davranışlarına bakılarak elbette. Neredeyse bütün GNU/Linux dağıtımlarının varsayılan olarak kullandığı kabuk olan bash'in 1989'dan bu yana içerdiği bir hata ancak 2014'de görülebildi. Eğer kodu okuyup açığı tespit etmek sanıldığı kadar kolay olsaydı bu 25 yıldan kısa sürerdi herhalde.Özgür yazılımların açıkları çok hızlı kapatılabilir
Özgür yazılımlar kullanıcılarına yazılım üzerinde değişiklik yapma ve bu değişikliği dağıtma hakkı verdiklerinden bir yazılım için geçerli bir hata veya açık bulunduğunda onu mutlaka geliştiricinin düzeltmesi gerekmez. Yazılımın geliştiricisini veya ait olduğu firmayı beklemek zorunda kalmazsınız özgür yazılım kullanırken.
Yazılımın kaynak kodlarının açık olması elbette yukarıda saydığım avantajlar için yeterli değildir. Eğer kullanıcılar yazılımı istedikleri gibi çalıştıramıyorsa, değiştiremiyorsa, dağıtamıyorsa veya değiştirdiği halini dağıtamıyorsa yazılım bu getirilerden mahrum kalacaktır. Yani sadece kaynak kodun açık olmasından sihirli bir iyileştirme beklememek gerekir. Bu avantajları bize sağlayan şey özgür yazılımdır.
6 Nisan 2017 Perşembe
Tam sayılarda kalansız bölme
Ortaokulda hepimizin öğrendiğimizi sandığımız ama pek azımızın öğrendiği bir konu tam sayılarda kalansız bölme konusu. Diğer bütün konular gibi bu konu da sadece kuralları budur diye anlatıldığı için sadece ikiye, üçe ve beşe bölme kurallarını aklımızda tutabiliyoruz. Onların da neden öyle olduğunu bilmediğimiz gibi sorgulamıyoruz bile. Bu konuyu neredeyse 15 yıldır bilgisayar mühendisliği birinci sınıf öğrencilerine soruyorum ve doğru öğrenmiş neredeyse kimseyi görmedim. Aslında o kadar kolay bir konu ki bir kere doğru anlatılsa insan istese bile unutamaz. Muhtemelen bu yazıyı okuyan kimsenin işine yaramayacaktır ama çocuklarınıza, hala kızına, emmioğluna falan anlatırsınız diyerek kısaca açıklamak istiyorum.
Önce hızlıca bildiğimiz kuralları hatırlayalım. Bir tam sayının ikiye bölünebilmesi için son rakamının (birler hanesinin) 2, 4, 6, 8 veya 0 olması gerekir. Beşe bölünmesi için ise birler hanesinin 5 veya 0 olması gerekiyor. Buraya kadar çok mantıklı görünen kurallar dizisi konu üçe bölünmeye geldiğinde değişiyor. Artık son basamağa değil bütün basamaklardaki rakamların toplamına bakmak gerekiyor. Bütün rakamlarının toplamı üçe bölünüyorsa sayı da bölünür diye öğretiyoruz çocuklara. Evet doğrusu bu ama ne alakası var sayının üçe bölünmesiyle rakamlarının toplamının üçe bölünmesinin? Öğrencilerin çok büyük çoğunluğu bu soruyu sormuyor bile, soranları da öğretmenler kural böyle diyerek geçiştiriyor. Matematiği bile böyle öğrettiğimiz çocuklar ileride hiçbir şeyi sorgulamayan büyüklere dönüşüyorlar. Halbuki neden 13 üçe bölünmüyor da 12 ikiye bölünüyor (son rakama bakıyorsak aynı kriteri sağlıyor ikisi de) veya 15 üçe bölünüyor da 11 ikiye bölünmüyor (rakamları toplamına bakarsak böyle olmalıydı) soruları akıllara bile gelmiyor.
Hele bir yediye bölünme kuralı var ki akıllara zarar. Üniversiteye gelmiş ve bu kuralı hatırlayan kimse olmuyor. Aşağıya vikipedi'den alıntılıyorum, neden kimsenin hatırlamadığını hemen göreceğiz:
Bu örnek üç basamaklı bir sayı için yazıldı ama sayının kaç basamaklı olmasıyla ilgisi olmadan genişletilebileceği herkes için açık olmalı. Bir kere böyle düşünmeye başlayınca ikiye bölünme kuralı da kolayca yazılabilir:
Gördüğümüz gibi aslında ikiye ve üçe kalansız bölme kurallarında bambaşka şeylere bakmıyoruz ama bu kadar kolay bir konu neden doğru anlatılmıyor anlamak çok güç doğrusu. Son olarak yediye bölünme kuralını bir kere de biz yazalım. Bunu da unutacaksınız ama gerektiğinde çıkartabileceğinizi bileceksiniz. Bu kuralı dört basamaklı sayılara ve daha fazlasına genişletmek de son derece kolay olacaktır:
Ülkede bir şeyler iyi yapılsın istiyorsak sadece kuralları ezberletmeye çalışmak yerine matematiğin içindeki güzellikleri ve yapılan işlerin doğasını anlatmalıyız çocuklarımıza. Yaptığı işlemi neden yaptığını bile bilemeyen biri nasıl onun üstüne bir şey ekleyebilir?
Önce hızlıca bildiğimiz kuralları hatırlayalım. Bir tam sayının ikiye bölünebilmesi için son rakamının (birler hanesinin) 2, 4, 6, 8 veya 0 olması gerekir. Beşe bölünmesi için ise birler hanesinin 5 veya 0 olması gerekiyor. Buraya kadar çok mantıklı görünen kurallar dizisi konu üçe bölünmeye geldiğinde değişiyor. Artık son basamağa değil bütün basamaklardaki rakamların toplamına bakmak gerekiyor. Bütün rakamlarının toplamı üçe bölünüyorsa sayı da bölünür diye öğretiyoruz çocuklara. Evet doğrusu bu ama ne alakası var sayının üçe bölünmesiyle rakamlarının toplamının üçe bölünmesinin? Öğrencilerin çok büyük çoğunluğu bu soruyu sormuyor bile, soranları da öğretmenler kural böyle diyerek geçiştiriyor. Matematiği bile böyle öğrettiğimiz çocuklar ileride hiçbir şeyi sorgulamayan büyüklere dönüşüyorlar. Halbuki neden 13 üçe bölünmüyor da 12 ikiye bölünüyor (son rakama bakıyorsak aynı kriteri sağlıyor ikisi de) veya 15 üçe bölünüyor da 11 ikiye bölünmüyor (rakamları toplamına bakarsak böyle olmalıydı) soruları akıllara bile gelmiyor.
Hele bir yediye bölünme kuralı var ki akıllara zarar. Üniversiteye gelmiş ve bu kuralı hatırlayan kimse olmuyor. Aşağıya vikipedi'den alıntılıyorum, neden kimsenin hatırlamadığını hemen göreceğiz:
Sayının rakamlarının altına birler basamağından başlayarak (sağdan sola doğru) a b c d e f 2 3 1 2 3 1 - + sırasıyla ( 1 3 2 1 3 2 ...) yazılmalı ve şu hesap yapılmalıdır: ( 1.f + 3.e +2.d ) - ( 1.c + 3.b + 2.a ) = 7.k + m ( k, m: tamsayı) Sonuç, 7 veya 7 nin katları ( m = 0 ) olursa, bu sayı 7 ile tam olarak bölünür. Ayrıca bu sayı 10a + b olarak yazıldığında a - 2b sayısı 7'ye bölünüyorsa, asıl sayı 7'ye bölünebilir.Aşağıdaki gibi anlatılsa hepimiz üçe bölünme kuralının neden sayının basamak değerlerinin toplamıyla ilgili olduğunu kolayca görebiliriz:
Bu örnek üç basamaklı bir sayı için yazıldı ama sayının kaç basamaklı olmasıyla ilgisi olmadan genişletilebileceği herkes için açık olmalı. Bir kere böyle düşünmeye başlayınca ikiye bölünme kuralı da kolayca yazılabilir:
Gördüğümüz gibi aslında ikiye ve üçe kalansız bölme kurallarında bambaşka şeylere bakmıyoruz ama bu kadar kolay bir konu neden doğru anlatılmıyor anlamak çok güç doğrusu. Son olarak yediye bölünme kuralını bir kere de biz yazalım. Bunu da unutacaksınız ama gerektiğinde çıkartabileceğinizi bileceksiniz. Bu kuralı dört basamaklı sayılara ve daha fazlasına genişletmek de son derece kolay olacaktır:
Ülkede bir şeyler iyi yapılsın istiyorsak sadece kuralları ezberletmeye çalışmak yerine matematiğin içindeki güzellikleri ve yapılan işlerin doğasını anlatmalıyız çocuklarımıza. Yaptığı işlemi neden yaptığını bile bilemeyen biri nasıl onun üstüne bir şey ekleyebilir?
5 Nisan 2017 Çarşamba
Eposta üniversiteler için ne anlama geliyor?
Bir önceki yazımda üniversitelerin %52'sinin eposta servisini kendi kontrolü olmayan şirketler aracılığı ile verdiğini yazmıştım. Üniversitelerin %17'sinin de eposta sunucularını MS işletim sistemleri üzerinden sağladığı düşünülünce konuya özgür yazılım açısından bakan biri için durum oldukça kötü görünüyor. Bu yazıda da üniversiteler neden bu tercihi yapıyorlar ve sonuçları neler oluyor konularını tartışmak istiyorum.
Telekom altyapısına çok az yatırım yapıldığından ULAKBİM üniversitelere çok kısıtlı bant genişlikleri verebiliyor. 50.000 öğrencisi ve 2000 personeli olan bir üniversitenin hızının yaklaşık 1Gbit/s olduğunu söyleyebilirim (çoğu anadolu üniversitesi için rakamlar bunun çok altında aslında). Aşağıda dün avrupada yaşayan bir arkadaşımla yaptığım yazışmada da görebileceğiniz gibi bir ev kullanıcısı 500 Mbit/s hızı tek başına kullanabiliyor. Hal böyleyken kurum içi eposta haberleşmesinin tamamını Amerika'ya gönderip alması veya yurtiçine gönderilen her epostanın Avrupayı gezip öyle yerine ulaşması bence kötü bir karar. Harcanan bu bant genişliğinin parasını üniversiteler kendi ödemiyor ama sonuçta ödeniyor.
Konuyla ilgili hala ikna edici olmayan bir yer varsa yorum olarak yazarsanız cevaplamaya çalışayım.
Biz yapamayız, ara eleman olalım fikrinin bir uzantısı
Üniversitelerin üreten ve paylaşan kurumlar olması durumunda neler yapabildiğinin dünyada pek çok örneği var BSD (Berkeley Software Distribution), wu-ftpd (Washington University ftp daemon) ve (MIT tarafından geliştirilen) Kerberos diğer pek çokları arasından bir çırpıda aklıma gelenler. Elbette eposta sunucularını kendimiz tutsak fezaya bayrak dikecektik, dışarı verdiğimiz için dikemiyoruz demiyorum ama eposta sunucusunu dahi kendi ayakta tutamayan bir üniversite nasıl olacak da dünyada yapılmamış bir işi kendi bilgi işleminden bekleyecek bilemiyorum. Eposta sunucularının diğer bütün sunucu servisleri gibi sorunlar çıkarttığı tahmin etmesi zor olmayan bir gerçek ama bunları çözmeye çalışmak, bu çözümleri başkalarıyla paylaşmak harcanan emeğe değecek bir iş bence. Sunucu servislerini dışarı taşımak bilgi işlemleri sorunları çözebilen birimler olmaktan sorun raporlayan birimlere dönüştürmek demek oluyor.Bu servisler gerçekten "bedava" değil
Ne Google ne de Microsoft üniversitelere eposta hizmeti verirken belirli kullanıcı sayılarına kadar ücret talep etmiyor. Bu hizmeti sonsuza dek ücretsiz vereceklerinin, hatta vereceklerinin garantisi de yok. Yakın gelecekte bu servisi ücretli hale getireceklerini de düşünmüyorum doğrusu. Bir üniversitenin binlerle ifade edilen personelinin, onbinlerce öğrencisinin epostalarına üste para vermeden sahip olabilen bir kurum bundan neden vazgeçsin ki zaten? Peki bedava olmayan ne o zaman? İnternet bağlantısı tabi ki. Bilmeyenler için yazayım; ülkemizde üniversiteler internet bağlantısı için kendi bütçelerinden bir harcama yapmıyorlar. TÜBİTAK'a bağlı ULAKBİM bütün devlet üniversitelerinin bağlantıları için faturayı kendisi ödüyor. Durum böyle olunca üniversitelerde internet bağlantısı sanki ücretsizmiş gibi bir algı oluşuyor ama durumun öyle değil.Telekom altyapısına çok az yatırım yapıldığından ULAKBİM üniversitelere çok kısıtlı bant genişlikleri verebiliyor. 50.000 öğrencisi ve 2000 personeli olan bir üniversitenin hızının yaklaşık 1Gbit/s olduğunu söyleyebilirim (çoğu anadolu üniversitesi için rakamlar bunun çok altında aslında). Aşağıda dün avrupada yaşayan bir arkadaşımla yaptığım yazışmada da görebileceğiniz gibi bir ev kullanıcısı 500 Mbit/s hızı tek başına kullanabiliyor. Hal böyleyken kurum içi eposta haberleşmesinin tamamını Amerika'ya gönderip alması veya yurtiçine gönderilen her epostanın Avrupayı gezip öyle yerine ulaşması bence kötü bir karar. Harcanan bu bant genişliğinin parasını üniversiteler kendi ödemiyor ama sonuçta ödeniyor.
Kararlar teknik değil idari
Üniversite bilgi işlem daire başkanlıklarının çoğunlukla çok kısıtlı kaynaklarla çalıştığı bilenen bir gerçek ama çok yeni kurulmuş bir kaç üniversite dışında mail hizmetini google veya MS'e devretmiş üniversiteler zaten servisi veriyordu. Önemli bir çoğunluğunda bu işi çok kaliteli yapan arkadaşlarımız vardı, hala da o kurumlarda çalışıyorlar. Eposta sunucusunu biz işletmeyelim kararı bu servisi veren teknik bilgisi olan personelin kararı değil, üst yönetimlerin aldıkları kararlar. Bunu çok fazla sistem yöneticisinden bizzat dinledim.
Eposta sunucusu işletmek zor bir iş mi diye sorarsanız cevabım 'yeterince bilmiyorsanız her sunucuyu işletmek zor' olacaktır. Birer eğitim ve araştırma kurumu olan üniversiteler işletmesi zor diyerek kullanıcıların mahremiyetlerini hiçe sayarak bu görevden vazgeçmemeliler. Böyle bakınca DNS de zor bir servis diyerek yarın onu da mı kontrolümüz dışında bir yere vereceğiz?
Eposta yazışmalarının mahremiyeti hiç düşünülmüyor
Eposta yazışmalarımızı MS veya Google'a teslim etmek bütün yazışmalarımızı iki bütün amerikan şirketinin diskinde tutmak demek olurken bundan rahatsız olmamak nasıl mümkün oluyor anlamakta zorluk çekiyorum gerçekten. Bütün kullanıcıların gönderip aldıkları mailler üzerinden yapılabilecek en hafif şeyin reklam gösterimi olabileceğini düşünüyorum. Konuya bilgi güvenliği açısından bakınca durumun vahametini görmemek mümkün değil. Son dönemde hakkında çokça konuşulan kişisel verilerin korunması açısından bakınca da kurumların kullanıcılarının epostalarını hiçbir kontrolleri olmayan kurumlara devretmesi üzerinde konuşulması gereken bir konu olmalı.
İnternet erişim engellemeleri hiç hesaba katılmıyor
Neredeyse üç yıl youtube engelinin yaşandığı bir ülkede yaşıyoruz. Bu engellemelerin önce dns çözümlemesiyle yapıldığını daha sonra ise google'a ait IP adreslerinin engellendiğini hatırlatmak isterim. Google bu adresler üzerinden sadece youtube yayınını değil başka servislerini de yaptığından diğer servislere erişimde sorunlar yaşandığını düşününce yarın benzer bir yasaklama olduğunda (olmayacağını düşünen varsa tanışmak isterim kendisiyle) eposta servisinde bir aksama olduğunda üniversiteler kiminle konuşup servislerini ayağa kaldırabilirler? Benzer şekilde dosya paylaşım sitelerine getirilecek bir yasakla eposta servisleriyle birlikte kullanıcılara sunulan depolama alanları da bir anda erişilmez duruma gelecektir. Üniversiteler bütün kullanıcılarını vpn veya tor kullanmaya yönlendirmeyecekse bu durum için bir planlarının olması gerekir ama olmadığını hepimiz biliyoruz.
Servisi başkasına yaptırmak elimizdeki araçları alıyor
Kurum dışından biri size eposta gönderdiğini söylesin ve siz bunu alamamış olun. Ortada bir sorun olduğu açık ama bunu nasıl çözeceksiniz. Eğer eposta sunucusu kurumunuzdan biri tarafından yönetiliyorsa sunucu loglarına bakmasını sorunu teşhis etmesini isteyebilirsiniz ama bunu google'dan nasıl isteyeceksiniz?
Kullanıcılarınıza google ve/veya sunmadığı bir teknolojiyi kullandırmak istemeniz durumunda yine eliniz kolunuz bağlı durumdasınız. Örneğin epostalarınızı Google'a vermişseniz eposta sunucunuza IPv6 üzerinden de erişilebilirken MS henüz bu hizmeti vermiyor (en azından Outlook kullanan hiçbir üniversite MX kaydına böyle bir girdi yapmamış). Eposta sunucusunu kendisi barındıran 17 anadolu üniversitesinin eposta sunucusuna IPv6 üzerinden de ulaşılabiliyor. Elbette Microsoft da yarın IPv6 hizmeti vermeye başlayabilir ama yeni bir teknolojiyi denemek, kullanmak için bu şirketlerin zamanlamasını beklemek üniversitelerin yapması gereken bir şey mi sizce de?
Yerli de değil, milli de
Son zamanlarda hemen herkesin dilinde olan yerli yazılım, milli yazılım söylemi ile epostaları Amerika'da, Avrupa'da saklamak yan yana getirmesi zor şeyler gibi görünmüyor mu size de? Bu konuda daha önce uzunca yazdığım için tekrarlamak istemiyorum ama özgür yazılımlar sanki bu topraklarda yazılmış gibi kullanabileceğimiz ve ihtiyaçlarımıza göre özelleştirebileceğimiz yazılımlarken onları kullanmalıyız.
Dünyada durum nasıl?
Dünyaca ünlü, hemen herkesin adını bildiği MIT, Harvard, Yale, Caltech, Purdue, Oxford ve Princeton eposta servisini MS veya Google'a vermiş değil. Bunda da gören gözler için bazı ibretler olmalı.
Konuyla ilgili hala ikna edici olmayan bir yer varsa yorum olarak yazarsanız cevaplamaya çalışayım.
Kaydol:
Kayıtlar (Atom)
yapay zeka çağında hâlâ bilgisayar mühendisi olunmalı mı?
Yazıyı okumaya sabrı olmayanlar için kısaca söyleyeyim: kimse gelecekle ilgili tavsiye verecek bir şey bilmiyor. Önceden de bilmiyordu bugün...
-
İkinci gün sadece öğleye kadar süren çalıştayda iki oturum yapıldı. Bunlardan ilkinde daha önce üzerinde konuşulan sorunlar için katılımcıla...
-
Pardus ülkemizdeki en geniş özgür yazılım topluluğunu bir araya getirmiş bir projedir. Kitlelerin linux ve özgür yazılımla tanışmalarına ve ...
-
Dün özgürlükiçin forumlarında okuduğum konu doğru mu diye gidip yerinde gördüm. Çanakkale'ye bir buçuk ay önce gönderilmiş olan etkileşi...














