Blogumu RSS'den takip edenler muhtemelen değişimi görmemiştir (RSS'deki bozukluk dışında). Bundan iki ay önce Dreamhost sunucuların genelini etkileyen bir saldırı sonucunda hasar gördü. Merak edenler için: Dreamhost Sites Hacked. Sabah kalktığımda bu manzara ile karşılaştığımda artık Wordpress'i terketmenin zamanı geldiğini anlamıştım.

Wordpress artık işimi görmemeye başlamıştı. Her ay güncellenmesi, durmadan ihtiyacımın olmadığı özellikleri eklemesi, güvenlik açıkların artması, her geçen gün daha da hantalaşması,vs.. Uzun zamandır bu hantal yapıdan kurtulmayı düşünüyordum. Çünkü Wordpress benim için sadece basit bir blog arayüzünden fazlası değildir. Sunduğu özellikler böyle bir açık kaynak kodlu proje için muazzam olsa da benim için gereksiz bir yükten başka bir şey değildi. Yukarıda anlatığım durum gerçekleşince ben de soluğu Jekyll'de buldum.

Jekyll nedir?

Jekyll statik site üreticisi diye geçiyor. Bunu biraz daha açayım. Jekyll, Ruby ile yazılmış bir uygulama. Belli bir sisteme, şablona göre bir klasör oluşturup içindeki dizinleri oluşturuyorsunuz. Örneğin benim klasörümdeki dizinler şu şekilde:

Yukarıdaki klasörler oluştuktan sonra bu dizin içinde şu komutu çalıştırıyoruz:

# jekyll --safe

Jekyll, yukarıdaki dizini tarıyor ve sonunda _site diye bir klasör oluşturuyor(yukarıdaki resimde yer almıyor, ona sonra değineceğim). Bundan sonra sizin tek yapmanız gereken herhangi bir tarayıcı ile bu _site altındaki index.html dosyasını açmak. Aslında tüm blogunuz ve içeriği _site klasörü içinde oluşmuş ve herhangi bir websunucu üzerinde (Apache,vs..) yayınlamaya hazır duruyor. Hepsi bu kadar. Herhangi bir veritabanı, kurulum,vs.. gibi adımlar yok. Jekyll'in güzel ve beni cezbeden yönlerinden biri bu.

Jekyll'de blog yazma işlemi nasıl işliyor?

Jekyll'de yazılarınızı Markdown veya Textile formatlarında yazabilirsiniz. Böyle olunca hem daha rahat ve hızlı bir şekilde yazabildiğiniz gibi, Vim, Emacs gibi metin düzenleyiciler ile de değiştirebilirsiniz (Jekyll'in bir güzel yani daha).

Bu yazıları da _post dizini altına yerleştiriyorsunuz. Peki bunun nasıl göründüğünü, yani çıktısını nasıl göreceksiniz? Yukarıda bahsettiğim gibi _site klasörü aslında bizim blogumuzun birebir çıktısı oluyor. Tek yapmanız gereken bir web tarayıcı ile bunu açmanız. Jekyll bir adım daha öte gidip size bir kolaylık sunuyor. --server parametresi ile çalıştırdığımızda

# jekyll --server

yerel bir sunucu oluşturuyor ve bize _site içeriğini sunmaya başlıyor(yerelde 4000 port numarasında). Yerelde doğrudan locahost:4000 portundan inceleyebilirsiniz sitenizi.

Örneğin ben genellikle tmux'da iki tane yan yana pencere açıyorum, birinde Jekyll sunucusu çalışıyor bir yanda da Vim açık şekilde yazımı yazıyorum. Vim'de ne zaman yazımı kaydetsem Jekyll bana son halini sunuyor:

Jekyll'de bloglar nerede ve nasıl host edilir?

Burada çeşitli seçenekler var. Aklıma gelen iki tanesi şu şekilde:

1. Yerelinizde oluşan _site klasörünü satın aldığınız bir sunucuya yüklemek. Tabi her seferinde tüm _site klasörünü yüklememiniz tavsiye edilir. Bunun yerine ya bir betik yazıp sadece değişiklikleri sunucunuza yüklersiniz (web jargonunda deploy derler). Bunun için Google'da Jekyll Deployment diye aratırsanız insanların çeşitli betikler, çözümler sunduğunu göreceksiniz.

2. Ya da Github'in Github Pages özelliğini kullanacaksınız (ben bu şekilde kullanıyorum). Github'ın Jekyll desteği var ve size özel subdomain veriyorlar. Ayrıca CNAME özelliği sayesinde satın aldığınız bir domain ismini de buraya yönlendirebiliyorsunuz. Mesela blog.arsln.org adresi farslan.github.com adresini işaret ediyor(bu yüzden github linkine tıklarsanız kişisel siteme yönlendirileceksiniz). Github'daki en güzel özellik doğrudan Jekyll desteği olmasıdır. Yani siz normal bir git deposu açıyorsunuz, yukarıdaki resimdeki gibi bir Jekyll klasör şablonu oluşturuyorsunuz ve gerisini github'a bırakıyorsunuz. Depoyu oluşturduktan sonra depda her değişiklikte (commit) github otomatik olarak jekyll --safe komutunu çalıştırıp _site klasörünü oluşturuyor.

İyi güzel de, nasıl kurulur bu Jekyll, nasıl başlayalım?

Geldik en can alıcı noktaya. Yukarıdaki anlatıklarım ile ilgili sorunun yoksa ve ben bu işi yaparım diyorsanız bundan sonrası kolay. Burada asıl konu Jekyll Nedir sorusuna bir cevap bulmaktı. Yani muhtemelen Jekyll'e geçmek istediniz ama bir türlü işlerin nasıl yürüdüğünü anlamadınız. Yukarıdaki anlatıklarım umarım bu konuda yardımcı olmuştur. Bundan sonra yapmanız gerekenler şunlar:

1. Sıfırdan bir blog başlamayı düşünüyoranız başta Jekyll'i yerel makinenize kurmalısınız(bu her koşulda yapılmalı). Jekyyl ana sayfasındaki kurulum notlarına bakabilirsiniz.

2. Jekyll'i kurduktan sonra Jekyll'in klasör yapısını ve anlamına bakabilirsiniz.

3. Jekyll'in altyapısı ve işlevini öğrendikten sonra asıl mesele olan kendi blogunuzu oluşturmaya geldi. Jekyll'de güzel olan kısım ise, bir uygulumanın kaynak koduna bakar gibi blog sitelerin kodlarına bakıp değiştrebilmenizdir. Bu konuda bir süre site var. Örneğin şurada bir çok kullanıcın Jekyll ile yapılmış sitelerini ve kaynak kodlarını görebilirsiniz: Jekyll kullanıcı siteleri. İsterseniz benim Github'daki bloguma da bakabilirsiniz: farslan.github.com

4. Wordpress'iniz varsa ve geçmeyi düşünüyorsunuz Wordpress to Jekyll aramasını yapıp bununla ilgili belgelere bakabilirsiniz.

5. Markdown veya Textile öğrenebilirsiniz.

Jekyll konusunda bir uyarı

Jekyll'de RSS'den tuttun da yorumlara kadar her şeyi kendiniz yerleştirmeniz gerekiyor. Hatta anasayfa'da üç/dört/beş tane yazı çıkmasını sağlamak bile sizin göreviniz. Sitenin tasarımı, Jekyll konfigurasyonları, eklentileri (örneğin kod renklendirmeleri), gibi bir çok konuyu baştan veya başkalarının şablonlarına bakıp oluşturmanız gerekiyor. Yukarıda verdiğim bağlantılar bu konuda size bir önayak olacaktır.

Bu blogun okuyucusu iseniz muhtemelen bu tarz şeyler sizin için sorun oluşmayacak, ama Wordpress'i basit işler için kullanıyorsanız, Vim'in, Terminal'in yanınından bile geçmediyseniz ve şu ana kadar anlatıklarım ile ilgili soru işaretleriniz oluştuysa elinizi bile vumayın. Çünkü Jekyll terminal, shell, geliştirme gibi konularda aşınalık ve bilgi istiyor. Yani daha doğrusu Jekyll ile uğraşmak istiyor ve kullanmak istiyorsanız bu bilgiler şart.

Jekyll'in avantajları

Benim açımdan en güzel yani Github'da hiç bir derdim olmadan kullanabilmek. Blogda kullanacağım resimleri kişisel hostumda tutuyorum. Yorumlarımı da şahane bir yorum hizmeti olan Disqus ile yönetiyorum. Diğer kalan tüm işlerim github üzerinde olduğu için çok hızlı ve sorunsuz bir altaypıya sahip oluyorum (hız konusu gibi).

Bunun dışında yazılarımı Vim ile yazıp, yerelimde istediğim tarayıcıda sitemi anında görebilmek ve yazıyı oluşturduktan sonra basit bir git push origin master ile konsoldan github'a yollamak paha biçilmez bir deneyim sunuyor bana. Benim gibi işlerinizin çoğunu konsol üzerinden yapıyorsanız, vim/emacs kullanmayı seviyorsanız, git hastası iseniz Jekyll tam biçilmiş kaftan.

Yorum kısmında yazı ile ilgili düşünceleri ve önerilerinizi yazabilir, aklınıza takılan soruları sorabilirsiniz.

01 May 2012 @ 08:36 PM

Kısa Özet

TÜBİTAK'da yer aldığım Pardus projesinden istifa ettim iki hafta önce. Tam 20 ay ( ~1.5 yıl) severek çalışmış, iyi insanlar tanımış, bir çok güzel bilgi öğrenmiş, ama üzgün ve hevesi kırılmış biri olarak ayrıldım. Neden mi?

Uzun Hikaye (geçmişe dair)

Nerden nasıl başlasam sözlerime bir türlü bilemedim. Bu yazılanları büyük bir hüzünle yazdığımı belirteyim. İnsanoğlu hayallerle büyür ama bu hayaller tam gerçekleştiği sandığınız anda kül olup uçtuğunu geç fark ediyor. En iyisi ben kaseti en başa sarıp o şekilde size hikeyimi anlatayım.

Yıl 2010. Hacettepe'den mezun olmama iki ay kala Pardus projesine iş başvuruşunda bulunmuştum. 2008 yılında staj yapmıştım ve böylelikle de ekibin bir çok kısmını kısmen de olsa tanıyordum. Linux ile maceram ise 2005 yıllarına dayanıyor. İşim güçüm Linux idi, okulda insanlara Linux'u anlatırdım, Linux kullanır, Linux CD'si dağıtırdım(Maviportal), kişisel blogumda belgeler yazardım, insanlarla tartışırdım. Bundan daha keyifli bir şey yoktu benim için. Akşam okuldan geldiğim gibi Archlinux ile ilgili gelişmeleri takip eder, şu an hangi teknolojiler, hangi paketlerde ne özellikler mevcut, sistemde ne gibi değişiklikler olacak diye adım adım takip ederdim. Seviyordum çünkü.

Hal böyle olunca Pardus'ta işe başlamak da hayallerimden biriydi. Nitekim öyle de olmuştu. Erkan Tekman'dan kabul mektubunu alınca bölümün önünde sevinçten zıpladığımı, gözlerimin güneş misali parladığı o an orada olanlar bilir. Akşam üstü bunu aileme söyledim ve 2010 Ağustos ayında ise resmen Pardus ekibinde işe başlamıştım.

Pardus ofisinde ilk iş günüm (Ağustos 2010)

İlk ofisimde Onur Küçük, Ozan Çağlayan, İbrahim Güngör ve Serdar Dalgıç vardı. İşe başlamamla birlikte hangi konularda çalışacağım ile ilgili bilgiler aramaya konulmuştum. "İşe Alıştırma" gibi bir faaliyet yoktu, "İşe dalıp" çalışmak vardı. Ben de bilgisayarımı kaptığım gibi ofiste ne yapabilirim diye sormuştum. Onur Abi(ben böyle seslenirdim kendisine): "Bugzilla'daki yeni paket isteklerine bakabilirsin, hataları çözebilirsin, oradan bir gir istersen" demişti. Ben de bunun üzerinde Bugzilla'ya girip gözüme ilk kestirdiğim yeni paket isteğini yapmaya konuldum. Paket ise Geogebra idi.

Daha öncesinde paket yapmama (2009 yılında) rağmen her şey benim için yeniydi. O yüzden hiç yerimde durmuyordum, ayağa kalkıp ofis ofis dolanırdım. Bilmediğim ne varsa her birini tek tek sorar, not alırdım ve uygulardım. Hal böyle olunca da birinci hafta "Yapılacak iş var mı? Bana iş verin" diye serzenişte bulunduğumda bana Texlive ailesinin tüm paketleri atanmıştı. Amacım hem yeni çıkacak Pardus 2011 için bunları yeniden düzenlemek hem de Pisi'den çıkan texlivemodules actionsapi'yi sil baştan tekrar düzenlemek. Texlive paketleri ile uğraşırken gözüme kestirdiğim bazı hataları da kendimce çözmeye çalışıyordum. Bunları da zaman zaman blog yazıları niteliğinde sizlerle paylaşmıştım.

Zamanla bu paketlerin üzerine Fatih Aşıcı'dan da tek tük işler alarak devam ettim. Kimse boş durmuyordu, herkes bir şeyi bir yerlere yetiştirmeye çalışıyor bir şeyler yapmaya çalışıyordu. Ben de bu hızın içinde kendimce bir şeyler yapmaya çalışıyordum. Fatih Aşıcı ile yaptığım işler artınca ve Fatih'in Nisan 2011'de askere gideceği kesinleşince yavaştan onun işlerini devralmaya başladım. Ofisi değiştirdim ve onun yanına geçmiştim. Fatih Aşıcı ile başta Panda ve Panda-KDE olmak üzere bir sürü güzel işlere imza attık.

Fatih Aşıcı askere gidince ona ait paketlerin %70-80'i devralmıştım. Zamanla onun paketlerin bakımı ile uğraşıyor ve bir yandan da X11, Mesa, Ekran kartları gibi teknolojirdeki gelişmeleri takip ediyor ve öğrenmeye çalışıyordum. Hatta bununla ilgili gelişmeleri de sık sık bu blogda sizlerle paylaşıyordum. Örneğin "Wine 64bit" konusundaki gibi. 2011 Ağustos ayında ise, yani tam bir yıl sonra işe iyice alışmıştım. İş yerimi, iş ortamını çok seviyordum. "Bundan sonrası çok güzel olacak, bir sürü güzel işlere imza atacağız, güzel işler yapacağız" diye söylenip duruyordum. Bu bundan 7-8 ay önceydi.

Ayrılıkların başlaması (Temmuz-Ağustos 2011)

Tabi bu şekilde ilerlemedi hiç bir şey.

2011 güzünde ekipten insanlar tek tek ayrılmaya başlamıştı. İsimlerini tek tek vermek istemiyorum, zira gidenleri geliştirici listesi, twitter gibi mecralardan görmüşünüzdür. Gidenler Pardus ekibinde yıllarca çalışmış, deneyimli insanlardı. Onlar gittikçe üzerimizde iş yükü artıyor, ileride yapmak istediklerimize dair hayaller de sönükleşiyordu. İş yükü artıyordu çünkü bu kadar çok paketin bakımını yapmak gerçekten çok zordu. Zor olmasının en büyük etkenlerden biri de eşit olmayan paket dağılımı idi. Benim üzerimde 300'e yakın paket varken, bir başkasının üzerinde en fazla 40-50 olabiliyordu. Bunu her ne kadar eşitlemeye çalışsak da, geliştiricilerin bu konudaki tutumu bu işi daha da zorlaştırmıştı.

İnsanlar ayrıldıkça kurumsal alanlarda da işler artmaya, yeni işler doğmaya başlıyordu. Bu yeni işlerden biri mesela Fatih Projesi idi. Fatih Projesi daha yeni duyulmaya başladığında Pardus ekibi olarak (Erkan Tekman önderliğinde) sık sık Ankara'ya gider gelirdik. O zamanlarda MEB Eğitek'de iki tane akıllı Tahta üzerinde 1-1.5 gün içinde Pardus'u sorunsuz bir şekilde çalıştıracak hale getirip göstermiştik. Erkan Tekman ta o zaman Pardus'un yapabiliceklerini, yapamayacaklarını, yapılması gerekenleri tek tek sıralamış ve bildirmişti.

2011 Kış ayında Tübitak Yönetimini değişmeye başladı. Tübitak içinde yapılan büyük bir toplantı sonucunda Pardus'un Fatih Projesinde yer almaması karar verilmişti. Bizimle yapılan bir toplantı da Pardus'un fiyat kırıcı rolü üstlendiğini, bu yüzden Microsoft karşısında -5 dolar kadar bir avantaj sağladıklarını, o yüzden Pardus'un bu konudaki başarısının yadsınamaz olduğu dile getirilmişti. Bunun duyan ekibin bir kısmı buna çok kırılmış (haklı olarak) ve ayrılmaya karar vermişti. Kan kaybı artarak devam etti bu günden sonra.

Son aylar (Ocak-Nisan 2012)

Aradan aylar geçti. Daha önce yukarıda saydığım isimlerin olduğu ofiste tek başına kalmıştım, var olan işleri düzenlemeye çalışıyorum, bir yandan da ansızın çıkan Fatih Projesi ile ilgili konusunda çalışıyordum. Ben de herkes gibi ayrılmaya karar vermiştim. Sebebleri çoktu, bunun en başında iki yıl önceki hayallerimi gerçekleşmek ve bir şeyler yapabilmek için gerekli zeminin yok olmasıydı. Belki bazı insanlar devlete kapağı atıp tüm gün oturup, aklı zorlamayan rahat işler yapmayı seviyordur, ama ben bunlardan biri değildim.

Çalıştay'da da "501 Developer" sözünü duyunca üzüldüm biraz. "501" geliştiricisi olmak kötü bir şey değil, ama TÜBİTAK tarafından sanki yıllardır böyle çalışıyormuşuz gibi itham edilmek beni çok üzdü. Çünkü bu proje'de yer almış herkes bilir ki, gecesi, gündüzü, haftasonu, fark etmeksizin çalışan bir ekip vardı. Mesai kalmak zevkti ve eve gitsek bile çalışırdık. Kaldı ki bu Pardus Projesinde işe başlayan insanların çoğu zaten işe başlamadan önce de boş zamanlarında destek veren insanlardı. "Sabah 8:00 akşam 17:00 arası çalışıyorsunuz, bize hevesli insanlar lazım" diye itham edilmek hoş olmadı.

20 ay önce Ankara'dan yola çıkarken yanımda bir bavul ve gönlümde yatan kocam hayalim, Pardus'a olan sevdam, hevesim vardı. Fedakarlık yapıp ailemi, dostlarımı, en yakın arkadaşlarımı, anılarımı, alışkanlıklarımı bırakıp gelmiştim. Pardus ve Pardus'la beraber bu ülkem, bu dünya için güzel şeyler üretebilirim diye çıkıp gelmiştim.

Pardus projesiyle ilgili gelişmeler bana herhangi bir proje için bu denli fedakarlığı hiç bir zaman yapmamam gerektiğini acı bir şekilde öğretti.

..

Bu projede yer aldığım sürede bana desteğini esirgemeyen, sorduğum tüm sorularımı eksiksiz bırakmayan, kimi zaman dertlerimi dinleyip derman olan herkese teşekkür ederim. Sizlerden çok şey öğrendim, inşallah ben de öğrendiklerimi yeri ve zamanı geldiğinde başkalarına aktarabilme şansına sahip olurum.

Yeni iş? Gelişmeler var mı ?

Pardus'tan sonra yeni bir işe başladım(16 Nisan 2012 itibariyle). Tanıdık simalar ile çalışıyor olacağım. Önümüzdeki yıllar blogumda yeni işimle ilgili edindiğim bilgileri yine sizlerle paylaşacağım.

22 April 2012 @ 07:00 PM

Herşey bundan yaklaşık 1 yıl önce başladı…

Danışmanlık hizmeti aldığım bir kurumdan (Back-up) gelen reklam postalarından birinde bas bas yazılan “destinasyon” kelimesini okuduğumda yaşadığım çöküntüyü anlatamam. Firmadan hizmet alımı karşılığında para ödediğim için kendimde hak olarak görüp bu durumu şikayet etmeye karar verdim. Zira “destinasyon” kelimesi Türkçe değildi, İngilizce (ya da Fransızca) olan “destination” kelimesinin fonetik halinin yazıya dökülmesiydi resmen. Aradım (zaten telefon üzerinden hizmet veren bir firma olduğu için aramak çok zor olmadı), kelimenin yanlış kullanımından ve bu şekilde kullanmaları halinde üyeliğimi iptal edeceğimden, bunun yerine kullanılabilecek kelimeler olduğundan falan bahsettim. Gayet yapıcı bir konuşmanın ardından telefonun ucundaki görevli konuyla ilgileneceklerini ve bana geri dönüş yapacaklarını söyledi. Resmen sevinmiştim. Yarım saat sonra bir arama geldi, kendinden emin ve bilmiş bir konuşma tonuyla öncelikle benim şikayetimi bana geri anlattı ve ardından zaferi kaçınılmazmış gibi bir gazla “ama ama Back-up kelimesi de İngilizceeee, ona niye bir şey demiyorsunuz kiiii” dedi. Ben de karşılığında “Back-up kelimesi İngilizce ve İngilizce’de nasıl yazılıyorsa öyle yazıyorsunuz, bunda bir problem yok, problem Türkçe olmayan bir kelimeyi Türkçeymiş gibi yazmanızda” dediğimde ise karşıdan “south park” sessizliği efekti geldi. Neyse onlar inatlarından ve yaptıkları yanlıştan vazgeçmediler ben ise üyeliğimden vazgeçtim ve konu kapandı.

Not: Yukarıda yazdığım yazıda da yazım hataları olabilir, Türkçe olmayan kelimeler olabilir. Benim derdim Türkçe olmayan, Türkçe’de birçok alternatifi olan ve hâlâ ısrarla diğer dillerdeki okunuşları ile Türkçe’ye kazandırılmaya çalışan kelimeler.

02 April 2012 @ 08:45 AM

Türkiye'de bir süredir ülkede alınan patent sayısını arttırmak yönünde çalışmalar yürütülüyor. Özetle "Yaw yayın sayımız tavana vurdu, ama para kazanamıyoruz biz bu işten, bi eksiğimiz patent kaldı, onuda halledersek tamamdır" şeklindeki önermeden yola çıkan bu çalışmalar kapsamında Cuma günü izlediğim bir sunum " Bayh-Dole" yasasının bir benzerinin ülkemizde çıkartılacağı yönündeki hazırlıklardan bahsediyordu.

Temel yaklaşımdaki eksikler atıf sayılarından başlar, ulusal intihal alışkanlığımız ve doçentlik atama kriterlerine kadar uzun bir tartışma konusu olur.

Ancak bahsedilen yasa tasarısı özetle üniversitelerde yapılan tüm çalışmaların patent hakkının öncelikli olarak lüniversiteye ait olmasını buluşu yapan araştırmacının ise bundan pay almasını öngörüyor. Bu durum getirdiği artılar (daha çok patent, patent haklarının kurumsal ölçekte takibi ve satışı vb.) ve eksiler (araştırmacıların demotivasyonu, araştırmacıların kurduğu/ortak olduğu garaj şirketlerinin azalması vb.) daha bir süre tartışılır ancak konu ile ilgili önemli bir saptama var.

Türk Amerikan Bilim İnsanları ve Akademisyenleri Derneği (TASSA: www.tassausa.org) Başkanı Prof. Dr. Banu ONARAL diyor ki:

31 March 2012 @ 09:42 PM

26 March 2012 @ 06:59 PM

Bilenler bilmeyenlere anlatsın. Linux Kullanıcıları Derneği ve İstanbul Bilgi Üniversitesi Bilgisayar Bilimleri Bölümü tarafından ortaklaşa gerçekleştirilen Özgür Yazılım ve Linux Günleri 30-31 Mart 2012 tarihinde İstanbul Bilgi Üniversitesi Dolapdere Kampüsü’nde gerçekleştirilecek.

2 gün sürecek olan etkinlikte Telsiz ve Radyo Amatörleri Cemiyeti (TRAC) orada bulunacak. Cumartesi günü de  amatör telsizcilik ve linux konusunda kısa bir konuşma yapacağım. Linux veya amatör telsiz konusuna ilgi duyan herkesi bekliyoruz!

Etkinlik anasayfasına buradan, etkinlik programına ise buradan ulaşabilirsiniz.

73! DE TA1AET

(Fotoğraf: http://www.linuxjournal.com/content/amateur-radio-forums-now-tech-support-i-hope)

23 March 2012 @ 10:16 AM

Hani Facebook’un meşhur “Like” düğmeleri var ya her yerde, hani hepimiz tıklıyoruz ya beğendiğimiz kedi resimlerini görünce… İşte Flattr işi maddiyata döküyor ve tıkladığınız her kedi resmi için sizin önceden belirlediğiniz bir miktarı kediye gönderiyor. Aylık bir miktar belirliyorsunuz; minimum 2 € ya da 3 $, ve bu miktar ay boyunca beğendiğiniz kedi resmi sayısına bölünerek kedilere dağıtılıyor. Yani artık ufak tefek destekler için, PayPal’a giriş yap, miktarı belirle gibi zahmetlerden kurtuluyorsunuz. Sürekli açık bir oturum da sadece bir “tık” ile desteğinizi göstermiş oluyorsunuz. Özellikle özgür yazılım geliştiricilerinin büyük bir kısmının, yaptıkları işleri kullanıcıların destekleri sayesinde yaptığını düşünürsek bu ufak tefek desteklerin ne çok işe yaradığını tahmin edemezsiniz.

Ayrıca kendi siteniz, günlüğünüz ya da dünyayı yerinden sarsacak projeleriniz için de destek almak üzere siz de Flattr’a üye olup sitenize Flattr düğmelerinden yerleştirebilirsiniz.

Ayda 2 € hiçbirimize zarar vermez dostum.

16 March 2012 @ 09:08 PM

Yazdan bu yana Pardus Kurumsal 2 kullanıyorum ve şu an için değiştirmeyi düşünmüyorum. Bunun sebebi üşengeçlik de olabilir, KDE 3.5‘i sevmem de olabilir; bilemem ama idare edebildiğim kadar edeceğim. Bilindiği gibi Kurumsal sürümü Firefox 3.6 ile geliyor ve depolarda henüz güncel sürümü bulunmuyor ve ne zaman gelir Allah bilir. Firefox’un şu anki güncel sürümü 10.0.2 [...]

09 March 2012 @ 01:49 PM

Yazılım geliştirici olarak iş aramak garip biçimde hem çok kolaylaşıyor hem de çok zorlaşıyor. Zorlaşmasının nedeni gereken bilgi ve deneyim seviyesinin sürekli artması. Kolaylaşmasının nedeni ise şirketlerin yazılımcı ihtiyacının bu seviyeden daha hızlı biçimde yükselmesi.

Mesela Amerika gibi güçlü CS (Computer Science, Bilgisayar Bilimleri) bölümlerine sahip üniversitelerin olduğu ve bir yandan da yurtdışından yazılımcı ithal eden bir ülkede, iyi bir yazılımcı bulup işe almak beklenmedik kadar güç bir iş. İlk önce verdikleri astronomik rakamlarla Wall Street ve keyifli ortamıyla üniversiteler bu kitlenin kaymağını topluyor, daha sonra da Google, Apple, Microsoft, Facebook, vb gibi isim sahibi firmalar. Kalanları kapabilmek için de küçük startuplar daha "cool" olma ve gelecekte dünyayı ele geçirme umutları satmakta birbirleriyle yarışmaktalar.

Bu kıran kırana ortamın iş ve işçi arayışını hallice değiştirmiş olması şaşırtıcı değil.

İşverenler başvuru beklemek yerine iyi geliştiricilerin takıldığı ortamlarda araştırma yapıp buldukları potansiyel adaylara görüşme teklifi gönderiyorlar. Büyük çaplı olanlar üniversitelere yerleşip potansiyel sahibi öğrencilerden stajyer kapmaya çalışıyor. Araştırma ortamlarından birisi diğer geliştiricilerin sosyal ağları. LinkedIn gibi profesyonel sosyal ağ siteleri, StackOverflow, TopCoder gibi bilgi paylaşımı ve yarışmalar yapılan siteler, özgür yazılım projelerine ev sahipliği yapan GitHub, GoogleCode gibi siteler belli başlı kaynaklar.

Ancak kendinizi görünür kılmanın en kolay ve etkili yolu bir özgür yazılım projesine katkıda bulunmak. Bu konuda geçen sene başında Javascript'çilerin ismini tanıyacağı bir geliştirici, John Resig İşe alma söz konusu olduğunda, bir Github commit'ini herhangi bir CV'ye tercih ederim diye bir laf etmişti ve epey tartışma yaratmıştı. Bu kapalı kod üreten işlerde çalışanların çok işine gelen bir durum değil. Bir şirkette onbeş yıl çalıştıktan sonra elinizde başkalarına göstermeye izniniz olan herhangi bir örnek kodunuz olmayabilir. Ancak eşitsiz ve acımasız da olsa gidişat bu yönde, çünkü birisinin yazılım becerisini değerlendirmenin en kolay ve hızlı yolu yazdığı koda bakmak. Özgür yazılım projelerinde kişinin test ve belge üretme, diğer geliştiricilerle ve kullanıcılarla birlikte çalışma gibi çok daha önemli özellikleri de bir ayna gibi görülebiliyor.

Tabii ki her projenin görünürlüğü farklı derecede. İş ilanlarından güncel bir derleme yaparsak, mesela Nginx, haproxy, Hadoop, memcache, Redis, MongoDB, puppet, vb gibi özgür yazılımlar epey sık geçiyor. Dolayısıyla bunlar üzerindeki deneyim ve katkılarınız daha çok ilgi çekme şansına sahip. Yazılımların sayfalarında yada şirketlerin mesela performansla ilgili sunumlarında neler kullandıklarını daha yakından görebilirsiniz.

Bir şekilde bağlantıya geçtikten sonraki adım ön eleme. Burada genelde daha önce yaptığınız işler, şirketin neler yaptığı, işin ilginizi çekip çekmediği gibi daha klasik konular konuşulmakta ve mesela şirketin yazılımcılarından biriyle kısa süreli bir telefon görüşmesi yapıp teknik bilginiz değerlendirilmekteydi. Ancak son zamanlarda arttığını gördüğüm bir uygulama daha var. Size bir problem ve bu problemi çözmek için yazılmaya başlanmış bir program gönderiyorlar, birkaç saat içinde programın hatalarını ayıklayıp, yeni özellikler ekleyip, belki bazı kısımları daha düzgün şekilde yeniden yapılandırıp geri gönderiyorsunuz. Programın çalışması kolayca test edilebileceği için şirketin yazılımcılarının incelemesinden önce epey bir eleme yapılabiliyor.

Asıl görüşme kısmı ise neredeyse tamamen Google modeline dönmüş durumda. Yarım gün falan süren, tamamen teknik konulardan oluşan ve tahtada kod yazılan zorlu bir sınav. Ağaç ve graph yapıları, arama ve sıralama, karmaşıklık gibi teorik konular, bildiğiniz programlama dilinin en ince detayları, işletim sistemi, ağ ve bilgisayar mimarisi. Bazı firmalar bu konsepti yalnızca gördükleri kadarıyla taklit ettikleri için, anlamsız derecede zor yada adaletsiz sorular sorabilirler. Bazı firmalar ise üniversite CS eğitiminin üzerinde ve gerçekten etkileyici yanıtlar bekleyebilir. Burada başarılı olmak için günceli takip etmek gerekiyor. Bildiğiniz sıralama algoritmaları Quick, merge ve heapsort'tan ibaret olmasın. Ağaç deyince aklınıza binary tree değil, Suffix tree, R tree, Radix tree, Judy array falan gelsin.

Bu konuları öğrenecek bir dolu kaynak var internette. Mesela AI Class, Udacity ve ML Class özellikle istatistiksel yöntemler ve yapay zeka konusunda çok başarılı kaynaklar. Bir diğer yardımcı da yine özgür yazılımlar. Favori yazılımlarınızın hangi algoritmaları kullandığına baktınız mı hiç? Mesela bellekte bir kopyalama işlemini nasıl en hızlı yaparsınız? eğer glibc kodunu açıp memcpy fonksiyonuna baktıysanız cevabı görmüşsünüzdür :) Ya da mesela onbinlerce bağlantıyı aynı anda yönetebilen bir sunucu nasıl yazılır? Nginx, lighttpd ve Apache gibi özgür yazılımların içinde buna dair ipuçları olsa gerek değil mi?

Bütün bu tantana yalnızca almışken daha iyi elemanı alalım kaygısından ya da beğenilen bir şirkete girmeye çalışmaktan kaynaklanmıyor. Gelişen teknoloji ve artan kullanıcı sayısıyla birlikte işlenen veri inanılmaz boyutlara ulaştı ve bu veriden çıkarılacak anlamlı sonuçlara, en başta reklam sektörü tarafından, çok büyük paralar ödeniyor. Dolayısıyla daha hızlı, daha az kaynak kullanan, daha başarılı sonuç üreten ürünler aslan payını kapıyor. Burada rekabet hem algoritma seviyesinde, hem de o algoritmayı en ideal biçimde gerçekleyeceğiniz uygulama seviyesinde.

Bu düzeye yalnızca dört senelik üniversite eğitimiyle (hele hele ar-ge yapılmayan ve seviyesi düşük üniversitelerde) ya da hobi seviyesinde bir programcılık ilgisiyle gelmek mümkün değil. Mutlaka zorlu problemlerle karşılaşıp bunlara çözümler geliştirmeniz, bir yandan da teorik bilgilerinizi sağlamlaştırmanız lazım.

Böyle bir hedefiniz varsa, stajınızı, çalışacağınız şirketleri, yapacağınız kişisel projeleri dikkatle seçmeniz gerekli. Mesela yüksek maaşlı ancak rutin ve yıpratıcı bir işe girip, uzun bir süre çalıştıktan sonra oraya çakılı kalıp, daha iyi bir noktaya geçme şansınız kalmadığını farkedebilirsiniz. Yaptığınız işin başkaları tarafından görülebilir olmaması ve yeni şeyler öğrenmenizi gerektirmemesi çok tehlikeli kariyer riskleri.

05 March 2012 @ 08:32 PM

Çalıştığım şirkette epey bir süredir Agile (Çevik) yazılım geliştirme metotlarından biri olan Scrum (Ragbi oyununda takımın bir mesafeyi almak için kafa kol girişmesini ifade eden bir terim :) uygulanıyor.

Agile yaklaşımın temelinde gereklerin geliştirme süreci boyunca değişeceği, dolayısıyla yazılımın artımsal olarak kısa adımlarla geliştirilmesi, müşterilerin ve geliştiricilerin süreç boyunca etkileşimi, yazılımın her anında çalışabilir olması gibi bazı genel fikirler var. Scrum ise bu fikirlerden yola çıkıp geliştirme ve planlama sürecinin nasıl yürütüleceğini ayrıntılı olarak (ve süslü deyimlerle) tanımlayan bir yöntem.

Bu yöntemler hakkında detaylı bilgi internette bulunabilir, ben yalnızca deneyimlerimden yola çıkarak öznel görüşlerimi aktaracağım.

İlk olarak, Scrum geliştirme işinin teknik yönüyle ilgili çok az şey içeriyor. Kodlama standartları, sürüm kontrol, inşa, test, vb pratikleriniz olduğunu varsayıp devam edelim.

Scrum takımı, geliştiriciler, ürünün önceliklerini belirleyen bir product owner (ürün sorumlusu) ve Scrum süreçlerinin yürütülmesi, geliştiricileri bloklayan engellerin kaldırılması, varsa diğer takımlarla iletişim gibi işleri yapan ve belli aralıklarla değişebilen bir Scrum Master'dan (Scrum yöneticisi) oluşuyor.

Scrum süreci sabit sürelerle yapılan geliştirme hamleleri (sprint) şeklinde. Bu süre genelde birkaç hafta. Her sprint başında yapılacak işler planlanıyor ve sprint süresince bu planlama değiştirilmiyor. Tabii bu süre bazı işler için küçük bazıları için büyük. Scrum'ın buna çözümü, işleri kendi başına çalışan ve sorunun çözümünde bir miktar ilerlemeye karşılık gelen küçük adımlara bölmek ve her Sprint sonunda bir miktar çalışmayı ürüne katıp o adımı geçmiş olmak. Kağıt üzerinde mantıklı da gelse, uygulamada işler bu kadar basitçe adımlara ayrılamıyor elbette. Bazı durumlarda işi artımsal adımlara bölmek toplamda daha uzun zamanda bitmesine yol açabiliyor. Ara adımlarda çıkan ürünlerin kullanıcılara ulaşması da, bakım zorluğu yaratacaksa istenmeyen bir şey olabilir. Kimi zaman da sprint bitmeden bir özelliği yada hata düzeltmeyi ürüne katıp müşteriye sunmak isteyebilirsiniz. Dogmatik yaklaşmayıp bu tür durumlarda esnek davranabilirseniz sprint yönteminin genel olarak zararlı olmadığını düşünüyorum.

Her gün belirli bir saatte, ekipteki herkesin geçen gün ne yaptığını, bugün ne üzerinde çalışacağını ve devam etmesine engel olabilecek her türlü engeli anlattığı günlük toplantı (standup) yapılıyor. Bu toplantının ayakta ve aynı odada yapılması vb gibi bir dizi kural var ama siz şekilselliğe değil amaca bakın. Önemli olan kısa sürmesi, herkesin birkaç cümle söyleyip birbirinin yaptığından haberdar olması. Amaç ekibi onbeş dakkada senkronize edip, o gün başka toplantıların yapılmasına engel olmak! Scrum'ın pratikte en faydalı uygulaması bence bu.

Akla gelen her özellik ve geliştirme önerisi, user story (kullanıcı hikayesi) adı verilen ve genellikle "bir Gazeteci olarak kelime işlem programında sözcükleri sayabileceğim bir özellik istiyorum, böylece istenen uzunluğu aşmadan yazabileceğim" gibi birinci ağızdan yazılmış fonksiyonel iş tanımları olarak, backlog (yığılmış iş) adı verilen bir listeye ekleniyor. Sprint başında takım bu listeden o sprint süresince yapılacak işleri seçiyor. İşlerin fonksiyonel ve açık biçimde belirtilmesi (user story'ler işin tamamlanma koşullarını ve çeşitli testleri de içerebilir) faydalı bir yaklaşım, ancak backlog fikrini doğru bulmuyorum. Bu konuda Rework çok daha akıllıca bir yöntem öneriyor: Uzun listeler moral bozmaktan başka bir işe yaramaz. Eğer bir işi bir kenara yazmadığınızda unutuluyorsa zaten sandığınız kadar önemli ve yapılması gereken bir şey değildir. Müşteriler ile sürekli bir iletişiminiz varsa zaten size en öncelikli ve gerekli işi sürekli hatırlatacaklardır.

Burada bir sorun da, ürün kalitesini arttıracak ama müşteriye direk yansımayan ufak işleri sıraya almanın çok zor olması. Bunları ya kendi başınıza yapacaksınız, değerlendirmelerde gözükmeyecek ve bunlara harcadığınız zamanın hesabını veremeyeceksiniz. Ya da bunlara birer user story oluşturmak yada eldekilerden birine eklemek için hem zaman hem de ekibi ikna edip sıraya aldırmak için enerji harcayacaksınız.

Backlog'a atılan user story'ler takım tarafından zorluk ve tamamlanma sürelerine göre puanlanıyor. Bu puanlar o sprint'te başlanacak işleri belirlerken ve süreç boyunca burndown chart, velocity gibi süslü isimleri olmasına karşın aslında oldukça basit istatistikleri oluştururken kullanılıyor. Amaç takımın verimini ve işlerin yürüme hızını gözlemlemek ama burada detaylarına girmeyeceğim bir dizi kurnazca yöntemle yapılmalarına rağmen neredeyse hiç bir işe yaramıyorlar. Puanlama, eğer kendinizi kandırmıyorsanız, işe başlamadan bilemeyiz demekten ibaret. Diğer istatistikler ise elma ile armutu karşılaştırıyor.

Bu ölçme girişimleri ar-ge'yi teneke kutu üretimi sanan yöneticileri tatmin etmek için icat edilmiş olsa gerek. Onlara kötü bir haberim var, eğer projeyi en ufak detayına kadar kavrayabilecek kadar bilginiz yoksa bir ar-ge projesini yönetemezsiniz. İyi niyetliler sizi terkeder, kötü niyetliler metriklerinizi kandırır. Bu noktada maalesef velocity yıllar öncesinin kod satırı sayısı kavramından bir adım öteye geçebilmiş değil. Benim önerim şu: projeyi takip mi etmek istiyorsunuz, gidip commit eposta listesini okuyacaksınız. Anlamıyorum olup biteni diyorsanız da proje yönetmeyin lütfen!

Scrum kabaca böyle. Doğru uygularsanız faydalı olabilecek bazı pratikleri var. Bir bütün olarak almayıp, her pratik için bu doğru mu? ve benim durumuma uygun mu? diye sorgulamanızda fayda var. Şekilselliklerinden ve seremonilerinden ise kaçının derim, gülünç duruma düşmeyin.

Agile felsefesine daha uygun başka uygulamalar da mevcut. Bu yazının kapsamı dışındalar, o yüzden netten kendiniz araştırabilirsiniz. Ayrıca herhangi bir çelişki halinde Rework kuralları daima geçiş üstünlüğüne sahiptir :)

20 February 2012 @ 10:47 PM

Benim için her şey büyük bir raslantı zinciriyle başladı aslında..

Tanışma ve Staj Başvurusu (Ocak 2007 – Nisan 2007)

Önce yurtdışında Erasmus yapmaya karar verdim. Sonra gitmek istediğim okul ile kendi okulum arasında zorla anlaşma yaptırdım. Ocak 2007′de Fransa’nın Grenoble şehri’ne gittim. Derslerime başladım ve gördüm ki gerek derslerde gerek laboratuvarlarda kısacası her yerde Linux kullanılıyor. Eve döndüm, dizüstü bilgisayarıma Pardus 2007 kurdum. 6 ay Skype ihtiyacım dışında sadece Pardus 2007 kullandım.

Bir gece yattığımda “Keşke Pardus Projesi’nde staj imkanı olsaydı..” dedim. Uyandıktan sonraki 1-2 gün içerisinde Pardus’un ilk defa stajyer alacağını öğrendim. Heyecanlandım tabii. Bir yandan çok istiyordum bir yandan da elle tutulur bir Linux tecrübem olmadığından kabul edilme olasılığımın düşük olduğunu düşünüyordum. 1-2 hata bildirmiştim o kadar.

Neyse vakit kaybetmeden bir CV ile niyet mektubu hazırlayarak başvurdum (29 Mart 2007):

Sevgili Pardus Ekibi,

Öncelikle biraz kendimden bahsedeyim. Galatasaray Üniversitesi, Bilgisayar Mühendisliği 3.Sınıf öğrencisiyim. Geçen sene yaptığım başvuru sonucu, Ocak 2007′den beri Fransa’nın Grenoble şehri’nde okumaktayım. Haziran 2007′ye kadar sürecek bu değişim programı sonunda İstanbul’a dönecek ve 2 ay boyunca zorunlu yaz stajımı gerçekleştireceğim.

Doğduğumdan beri bilgisayarla bir şekilde ilişki içerisindeyim ve bundan oldukça memnunum ve halen ilk gün sahip olduğum heyecana sahibim. Bu heyecanımı da arkama alarak lisans eğitimimi de bilgisayar üzerine yapmaya karar verdim. Bilgisayar ve elektronik dallarına ait her konu başlığına ilgiliyim. Ancak özellikle bilgisayarın elektroniksel olarak tasarımı, işlemci organizasyonu, işletim sistemi tasarımı ve sinyal işleme konularına ilgi duyuyorum. Tamam bu konular hakkında inanılmaz bir bilgi birikimine sahip olduğumu söyleyemem ancak uğraşırken en çok zevk aldığım konu başlıkları bunlar.

2004 yılından beri Linux ile uğraşıyorum. Üniversite’nin ilk senesinde, okulun köklü gruplarından GSULinux tarafından verilen dersleri takip ederek ilk sene sonunda Staff kadroya dahil edildim. Lise yıllarımda çekinerek ama merakla baktığım UNIX dünyasıyla
pratik olarak tanışmam bu yolla oldu. Özellikle Gentoo işletim sistemini kurma çabalarım süresince oldukça deneyim kazandığımı söyleyebilirim. Bunun dışında 2003 yılından beri C programlama diliyle bir şekilde iç içeyim ve bundan oldukça memnunum.

Lafın kısası, stajımı pardus ekibinde yapmak istiyorum çünkü 2 aydır laptopumda kullandığım işletim sisteminin iyileştirilmesinde en ufak bir faydam olursa bundan oldukça gurur duyacağım. Kullanırken bile gurur duyduğum bu işletim sisteminin ileride ülkem için mükemmel bir iftihar kaynağı olacağını seziyorum. Stajımı geçen sene de TÜBİTAK UEKAE bünyesindeki optoelektronik laboratuvarında yaptım ve ortamı tanıyorum. Ekipteki herkesten bilgi ve birikimime katkıda olacağına inandığım bir ton şey öğreneceğimi biliyorum. Python ile maalesef çok fazla uğraşmışlığım yok. Sadece geçen yaz vakit bulduğumda biraz bakmıştım ancak tabi ki pratik yapmadığım için çok fazla bir şey hatırlamıyorum. QT kullanarak grafiksel arayüz de geliştirmedim. Öğrenmemin çok fazla zaman alacağını düşünmüyorum, yaza kadar vakit bulursam çalışmayı, kurcalamayı düşünüyorum. Aşağıya staj projeleri listesinden seçtiklerimi yazıyorum. Bunlar aralarında, zorluğuna ve bilgi ihtiyacına bakmaksızın, en çok ilgimi çekenler:

- Göç aracı
– Proxy Ayar Arayüzü
– Paket Yapım Aracı
– Diğer Linux dağıtımlarının GRUB’a eklenmesi.
– Grafik yapılandırma arayüzü

Özgeçmişim ektedir. Yapmam gereken stajın resmi süresi 2 ay olup (40 iş günü), Temmuz 2007′den, Eylül 2007′ye kadar olan sürede herhangi bir zaman diliminde gerçekleştirebilirim. Bilgilerinize arz ederim. İyi çalışmalar.

Kişisel cevap 24 Nisan 2007 tarihinde geldi:

(A.Murat Eren tarafından yazılan detaylı blog girdisi de okumaya değerdir.)

Staj (Temmuz 2007 – Ağustos 2007)

Staja başladıktan sonra farkettiğim şey çevremde Pardus ve Linux adına benden daha fazla şey bilen, ofisteki geliştiricilerle tanışan insanların olduğuydu. Ben derleme çiftliğine XMLRPC tabanlı bir iletişim katmanı eklemekle uğraştım, bunu yaparken de karşıma çıkan hataları düzelttim. Genelde Ekin Meroğlu ve S.Çağlar Onur ile çalışıyorduk, ben onların yanına gidiyor, bir şeyler soruyor, yanıtları not alıyor geri stajyer ofisine dönüyor bir şeyler yapmaya çalışıyordum.

Staj süresi çabuk geçti, bir sürü şey öğrendim, Anibal’in Mezarı’nı gezdim, bir sürü değerli insanla tanıştım, eğlendim falan derken 11 Eylül 2007′de Çağlar Jabber üzerinden “Bizimle yarı zamanlı çalışmak ister misin?” dedi. Teklifin doğum günüme gelmesi ilginçti. Kabul ettim.

Yarı Zamanlı Katkı (Ekim 2007 – Ağustos 2008)

Ekim 2007 – Haziran 2008 arası yarı zamanlı olarak projeye destek verdim. Otomatik yazıcı tanıma altyapısı üzerinde çalışıyordum vakit buldukça. İlk olarak Pardus 2008 sürümünde bu altyapıyı devreye almıştık ve kullanıcılara oldukça kolaylık sağlamıştık. Benimle beraber Gökçen Eraslan tam zamanlı, Fatih Aşıcı ise yarı zamanlı olarak işe başlamıştı.

Yarı zamanlı çalıştığım süre üniversitenin son sıfına denk geldiğinde aynı zamanda tez çalışmalarıyla boğuşmaktan Pardus’a yeterli vakit ayıramıyordum. Tezi tamamlayıp Haziran 2008′de mezun olarak ofise geldiğimde Erkan Tekman ile “Ben akademik bir şeyler yapmak istiyorum, yüksek lisans yapacağım, bir süredir de tez ile uğraşmaktan projeye vakit ayıramadım ve aramıza mesafe girdi” temalı bir konuşma yaptım ancak beni projede kalmaya ikna etti, akademik iznimi kullanarak yüksek lisans da yapabileceğimi belirtti. Ağustos 2008 itibariyle tam zamanlı olarak projede çalışmaya başladım.

Tam Zamanlı Katkı (Ağustos 2008 – Ocak 2012)

Ağustos 2008′de tam zamanlı bir geliştirici oldum. Aynı zamanda Boğaziçi Üniversitesi Biyomedikal Mühendisliği Bölümü’nde yüksek lisansa başladım. Ancak bazı kişisel ve takvimsel sebeplerden dolayı hem işin hem de yüksek lisansın beraber yürümeyeceğini anlayarak yüksek lisansı bıraktım.

Staj ve yarı zamanlı çalıştığım dönemlerde beraber katkı vermeye çok fazla fırsat bulamadığım Gürer Özen, İsmail Dönmez, S.Çağlar Onur birbirlerine yakın sayılabilecek zamanlarda projeden ayrıldılar. Çağlar’ın ayrılmasıyla bir anda çekirdek paketini elimde buldum. Çekirdek paketinin ve çekirdek sürücülerinin bakımını üstlendiğimde Pardus 2008 sürümü aktif olarak geliştiriliyordu ve 2.6.25 serisi çekirdek kullanıyorduk.

15 Kasım 2008 tarihinde çekirdeği 2.6.25.20 sürümüne yükselttim ve SUSE’den aldığım yamalarla çekirdeğe UDF desteği ekledim. Bu benim çekirdek paketine ilk güncellememdi.

Daha sonra Pardus 2009′u 2.6.31 serisiyle yayınladık. Kurumsal 2 sürümündeyse önce 2.6.32 serisini kullandık sonra ise 2.6.35 serisine geçiş yaptık. Pardus 2011′de ise 2.6.36 ve 2.6.37 çekirdeklerini kullandık.

Çekirdek ve sürücü bakımının yanında kararlı depoya aktarılmamış paketleri yavaş yavaş 2008 kararlı deposuna aktarmaya başladım. Bu esnada derleme hatalarıyla karşılaştım, onları çözmeye çalıştım, yama nedir öğrendim, yama buldum, yama yaptım. Bu süreç paket bakımı konusunda beni oldukça eğitti.

Zamanla Onur Küçük‘ün üzerinden yazıcı ile ilgili paketleri devraldım. Bunun yanında bazı temel kitaplıklar, tarayıcı desteği, yine Çağlar’dan kalan ses altyapısı, Pınar Yanardağ‘dan devraldığım Bluetooth altyapısı, HAL, udev, kablolu/kablosuz ağ altyapısı, falan derken şu an bakıyorum da 2011 kararlı deposunda 425 adet paketin bakıcısı olarak görünüyorum.

Bu süre içerisinde bana atanan ve daha sonra ÇÖZÜLDÜ olarak kapatılan hatalara baktığımda 586 sayısını görüyorum. Bu yaklaşık bir değerdir tabii ki, arada yanlışlıkla çözüldü olarak işaretlenen, bana atanan ancak benim çözmediğim hatalar da vardır mutlaka ancak ne kadar katkı verdiğime dair bir fikir vermesi açısından önemli.

Pardus Kurumsal 2

10 Aralık 2009 tarihinde, Proje Yöneticisi Erkan Tekman tarafından Geliştirici listesinde duyurulduğu üzere, Pardus Kurumsal 2 dağıtımının geçici sürüm yöneticisi oldum. Aslen Ekin’in yöneticiliğinde başlayan bu sürüm, Ekin’in askerlik görevi için projeden bir süreliğine ayrılmasıyla geçici olarak bana devredilmişti. Ekin’in askerden döndükten sonra sözleşmeli projeler sorumlusu olmasıyla, sürümün yöneticiliği asaleten bana devredilmişti.

KDE masaüstü ortamının artık bakımı yapılmayan ancak kararlı ve hızlı olan 3.5 serisinin kullanıldığı Pardus Kurumsal 2 sürümü için çok çaba sarfettik. Sürüm takviminde aksamalar olmadı değil ancak hep son ürünü daha iyi hale getirmek için yaşandı bu aksaklıklar. Bir kurumsal sürümde olması gerektiğine inandığımız unsurları iş gücümüzün ve kabiliyetimizin izin verdiği ölçüde son ürüne yansıtmaya çalıştık ve Şubat 2011′de sürümü yayınladık.

TÜBİTAK içerisinde de ürüne ilgi büyüktü. TÜBİTAK tarafından geliştirilen bir akıllı kart işletim sistemi olan AKİS desteğini eniyileştirmek için AKİS ekibiyle beraber çalıştık, Temmuz 2011′de Kurumsal 2 üzerinde oldukça kapsamlı bir AKİS desteği sağladık, sunumunu yaptık.

Yine EPDK, SKAAS gibi projelerden daha Kurumsal 2 sürümü çıkmadan gelen istek ve eksiklikleri son ürüne olabildiğince yansıtmaya çalıştık. Bu ekiplerle ortak çalışmalar yürüttük, birbirimize destek olduk.

Peki ne oldu?

Milliyet Gazetesi’nin 28 Ağustos 2011 tarihinde yayınladığı haberde de belirtildiği gibi Kamuda yeniden yapılanmayı düzenleyen ‘Kanun Hükmünde Kararname’lerle bürokraside yeni bir atama operasyonu daha gerçekleştirildi ve TÜBİTAK Başkanı Nükhet Yetiş görevinden alındı. Birkaç gün sonra ise BİLGEM başkanı Önder Yetiş istifa etti.

Tabii ki bu son yazımda siyasete bulaşmayacağım. Ağustos 2011′de başlayan ve hâlen devam eden yeniden yapılanma sürecini bu yazının okurları kendi algı ve yorumlama yetileri çerçevesinde değerlendireceklerdir.

Ancak,

bu 5 aydır devam eden süreç TÜBİTAK’ın başına bir çığ gibi indi. Bu çığdan çok fazla etkilenen ve hiç etkilenmeyen araştırmacılar, yöneticiler, projeler, birimler oldu.

FATİH Projesi’nde Pardus Projesi’ne beklenen ve ümit edilen değer asla verilmedi. Hükümetin bakanları Pardus hakkında “Pardus diye TÜBİTAK’ın geliştirdiği bir işletim sistemi var.” gibi trajikomik sözler sarfetti.

FATİH hakkında hiçbir umut ve gelecek görülmüyorken Pardus Projesi Ekim 2011 sonunda UEKAE’den BTE’ye geçirilip “Fatih için Pardus” olarak yeniden adlandırıldı. Acaba? dedik.

Birkaç gün sonra ise üst düzey bir yönetici enstitü çalışanları önünde “Microsoft bilgisayar başına 5TL lisans indirimi yapmış, zaten Ulaştırma Bakanı da geçen gün projeyi Microsoft’a vereceğiz dedi bana” gibi profesyonelliğe pek yakışmayan açıklamalarda bulundu.

Daha sonra yine üst düzey bir yöneticiden FATİH Projesi’nde Microsoft’a kök söktürdüğü için Pardus’a minnettar olunduğunu duyduk.

Böylece en azından ben “Fatih için Pardus” yeniden adlandırmasının oyalamadan başka bir şey olmadığını idrak ettim.

Etrafımızdaki tanıdığımız, saygı gösterdiğimiz, işini iyi yaptığını bildiğimiz araştırmacıların görevlerinden alınarak alt seviye görevlere gönderildiklerine şahit olduk. Basının ve dış dünyanın ise olan bitenden hiç haberi olmadı, olamadı.

Ben?

Bu yeniden yapılanma sürecinin Pardus için iyi bir şekilde sonuçlanacağına dair inancım çok azdı, o az olan inancım da katıldığım bazı toplantılar ve tanıştığım bazı yeni insanlar tarafından yok edildi. Ben de gittiği yere kadar projede devam etmeye, o esnada da elimden geldiğince hatalarla ilgilenmeye karar verdim. Kurumsal 2 için güncelleme paketi yayınladım, oyun alanımda çekirdeği 3.2 serisine çektim, bazı hataları düzelttim. Oyun alanımda systemd, dracut, kmod gibi yeni Linux teknolojilerinin paketlerini hazırladım olası bir yeni sürüm planı için. Bir yandan da devam etmekte olan yüksek lisans eğitimimle ilgili proje ve sınavlarla ilgilenmeye devam ettim.

Görevlendirme

29 Aralık 2011 tarihinde 1 aylığına Ankara’ya görevlendirdiğimi öğrendim.

Ben Ekim 2007′de Pardus Projesi’ne geliştirici olarak alındım, enstitüler ve projeler arası çalışacak taşeron bir yazılım geliştirici olarak değil. Ayrıca Ocak 2012 süresince finallerimin ve proje teslimlerimin olduğu da yönetim tarafından bilindiğine göre bu görevlendirmenin ne kadar iyi niyetli olduğu oldukça şüpheliydi.

Gittiği yer burasıymış dedim ve bu çığ altında kalmış kurumdan sıyrılarak ayrıldım.

Peki şimdi ne olacak?

Şu anda projede 11′i geliştirici olmak üzere 14 kişi çalışıyor. TÜBİTAK, Pardus Projesi’nin geleceği hakkında yakın zamanda bir çalıştay düzenleyecek. Ben davet edileceğimi bile düşünmediğim bu çalıştayın yapıcı değil yıkıcı olacağını düşünüyorum, umarım haksız çıkarım.

Başka bir dağıtım projesi var mı?

Ben hâlen evimde Pardus 2011 kullanıyorum ve Pardus’un diğer dağıtımlara göre avantajlarının olduğuna, daha kullanıcı dostu olduğuna ve PiSi paketleme altyapısının oldukça başarılı ve kullanışlı olduğuna inanıyorum. Bu yüzden Pardus’u tek başıma veya başkalarının da katkısıyla başka bir ad altında devam ettirmek istiyorum. Hatta bir süredir GitHub altında benim yaratmış olduğum bir depoda Pardus 2011 kaynak deposunun bir kopyası var. Yaptığım bazı çalışmaları arada sırada oraya commit ediyorum ancak ortada sadece biraz ilerlemiş bir depo var, ürün olmaya yakın hiçbir şey yok.

Ancak istemekle olmuyor bu iş. Ben ne kadar istiyorum desem de hem yüksek lisansım hem olası bir yeni iş hayatım bu yeni projeye verebileceğim katkı miktarını oldukça düşürecek. O yüzden biraz daha düşünüp ona göre konuşmak istiyorum.

Teşekkür

Öncelikle çabaladığı, savunduğu, hedeflediği her şey için muhteşem yöneticim Erkan Tekman’a,

sonra aklıma gelen kronolojide TÜBİTAK bünyesinde Pardus Projesi için katkı vermiş arkadaşlarım

Gürer Özen, Barış Metin, A. Murat Eren, Barış Metin, Faik Uygur, Onur Küçük, Ekin Meroğlu, S. Çağlar Onur, İsmail Dönmez, Görkem Çetin, Umut Pulat, Koray Löker, Bahadır Kandemir, Gökmen Göksel, Gökçen Eraslan, Fatih Aşıcı, Pınar Yanardağ, Taner Taş, Serbülent Ünsal, Ali Ulvi Tunç, Işıl Poyraz, Semen Cirit, Renan Çakırerk, Serdar Dalgıç, İbrahim Güngör, Eren Türkay, Erdem Bayer, Akın Ömeroğlu, Mete Alpaslan, Fatih Arslan, Meltem Parmaksız, Metin Akdere, Mete Bilgin, Mehmet Emre Atasever, Yasemin Yiğit Kuru, Hakan Şimşek, Uğur Eke, Gökhan Özbulak, Nihan Katipoğlu, Beyza Ermiş, Çağlar Kilimci, Mehmet Özdemir, Bertan Gündoğdu, Kaan Özdinçer ve Pamir Talazan’a,

yine TÜBİTAK bünyesinde çeşitli konumlarda çalışmış veya çalışmakta olan, bana bir şekilde bir şeyler katmış olduklarına inandığım Seda Polat, Fehime Bıyıklıoğlu ve Özmen Emre Demirkol’a,

64-Bit desteği için ÇOMÜ ve Necdet Yücel’e,

Artistanbul ekibinden tanıdığım Ali Işıngör, Seda Akay, Gizem Belen, İrem Çobanoğlu, Uğur Çetin ve tanımadığım diğerlerine,

Özgürlükİçin’in yaratıcıları ve yürütücülerine,

bize daima destek ve katkı veren tüm Pardus kullanıcılarına ve camiasına,

ve son olarak iyi kötü bizi arkadan ittirmiş ve bizi elinden geldiğince desteklemiş olduğunu şimdilerde daha iyi anladığım Önder Yetiş ve eski yönetime

teşekkür ederim.

Son olarak…

 ***

27 January 2012 @ 10:13 PM

Geliştirdiğiniz bir yazılımı insanların daha fazla faydalanabilmesi için kodları ile birlikte dağıtmak fikri. İlk duyduğumda biraz garip gelmişti, geçmesi 1-2 dakika sürdü.

Ardından işe koyuldum; önce paylaşımdan faydalanan tarafta yer aldım. Özgür yazılım geliştiren insanların paylaştığı kodları incelendim, bazı değişiklikler yaptım, işime yaramayan kısımları attım, paketledim ve sattım. Para kazanınca, kendimi kodlarından yararlandığım insana borçlu hissettim. Para teklif ettim, istemedi. Onun yerine onun bana yaptığı gibi benim de ona katkı vermemi istedi. Yazılım ile ilgili yanlış olduğunu düşündüğüm kısımları söyledim, birkaç hatayı düzelttim, bazı değişiklikler ile ilgili tartıştım ve bir şekilde yazılımı geliştirdim. Yeri geldi birbirimizi ikna edemedik, bir önceki sürümden sonra yollarımızı ayırdık. Yeri geldi işi gücü bırakıp bira içmeye gittik.

Özgür yazılımı yukarıda anlattığım gibi ele alıyorum ben. Ne üzerinde çalıştığım platformun özgürlüğü, ne de şu anda bu satırları yazdığım yazılım ile ilgili özgürlük detayları ilgilendirmiyor beni. Bugüne kadar yazdığım satır kod şu anda İnternet üzerinden erişilebiliyor, özgürce başkaları tarafından kullanılabiliyor ve yine bir şekilde birilerinin işine yarıyorsa bu benim için yeterli. Biraz daha açıklamak gerekirse; Windows üzerinde dahi uygulama geliştirebilirim (tercih etmem ama zorunda kalırsam geliştiririm) ve o uygulamayı özgür bir şekilde kullanılmak üzere insanlara dağıtabilirim. Bu benim için özgürlük dışı bir davranış olarak gözükmüyor. Hatta eski tartışmalara da taş atmak gerekirse; ben yazılım geliştirirken Jira dahi kullanabilirim; bu Pardus için doğru olmayabilir, projenin gereksinimleri, hedefleri vs. ile ilgili başka durumlar söz konusu olabilir ve özgür olmayan bir yazılım kullanarak özgür yazılım geliştirmek konusu tartışmaya açılabilir. Fakat kişisel olarak geliştirdiğim/geliştireceğim uygulamaları geliştirirken kullanacağım yazılımların özgür olup olmaması beni zerre ilgilendirmiyor.

Bunları buraya geçmişten bir not kalsın diye, 10 yıl aradan sonra kapalı kodlu yazılım geliştirmek zorunda olduğum için yazıyorum. Hiçbir zaman Richard M. Stallman gibi bir bakış açısına sahip olamadım, doğru olduğunu ya da yanlış olduğunu tartışmıyorum, fakat benim özgürlük bakış açımda sadece benim neyi nasıl yaptığım önemli. Ben herhangi bir insanın işine yarayacak bir uygulama geliştirdiysem, bunu özgürce kullanmasını, değiştirmesini ve hatta tekrar dağıtabilmesini garantilediysem bu bana yeterli geliyor.

Yani ben Windows üzerinde özgür bir yazılım geliştirebilir, kullandığım görselleri Photoshop ile hazırlayabilirim. Yine eklemek gerek; tercih etmem ama yapabilirim ve bu yazılımların özgürlüğü konusunda da herhangi bir endişe duymam.

12 January 2012 @ 11:38 AM

14 Aralık 2011 tarihi itibarı ile Tübitak/Bilgem’den ve en önemlisi hayatımın önemli bir yerinde duran Pardus projesinden çeşitli sebeplerle ayrıldım. Yaşamak için maalesef para kazanmanın şart olması ve benim de çalışmadan durmayı pek sevmeyen biri olmam sebebi ile özel sektöre geri dönmüş bulundum; 19 Aralık 2011′den beri Sigma R&D‘de yazılım geliştiricisi olarak çalışıyorum.

Genelde bilgisayar bilimleri ve bilgisayarlı görsel işleme ile ilgili işler yapıyoruz, %99′u eğlenceli işlerden bahsediyorum. Microsoft’un XBox 360 için geliştirmiş olduğu hareket algılama (derinlik, görsel veri) oyuncağı Kinect ve yakın zamanda birkaç firmanın da sunumunu yapacağı girdi aygıtlarını kullanıyoruz.

Sigma R&D’de daha önceden geliştirilmiş bir kütüphanemiz var; Sigma Natural Interface Library (SigmaNIL). Bu kütüphaneyi kullanarak kamera ve derinlik bilgisi sunabilen ve şu an için OpenNI tarafından desteklenen herhangi bir aygıttan gelen verilere dayanarak fiziksel hareketlere anlam kazandırabiliyoruz. Bu şu anlama geliyor; herhangi ek bir aygıt kullanmadan sadece hareket ederek bilgisayara istediğinizi yaptırabiliyorsunuz. Ben de genel olarak bu kütüphaneyi kullanabilen uygulamalar geliştirmekle uğraşıyorum. Görsel etkileşim içeren basit uygulamalar ya da oyunlar gibi. Yine Qt ile fakat bu sefer C++ kullanıyorum.

OpenNI açık kaynak bir API sunduğu için SigmaNIL’de OpenNI’ın desteklediği herhangi bir platformda çalışabiliyor. Belki hatırlayanlarınız vardır, Cebit 2011′de Pardus standında Pardus üzerinde bir oyun oynatmışlardı ;)

Şu an için herşey güzel gidiyor, devamında da öyle olmasını umuyorum. Özgür yazılımdan kopmadım fakat işim gereği geliştirdiğim uygulamaların bir kısmı kapalı kodlu olacak. Ekipçe özgür yazılıma pek uzak olmadığımız için zaman zaman geliştirdiğimiz bazı araçların kodlarını açacağımız kesin ;) Hatta geçtiğimiz günlerde ilk adımı ben attım.

12 January 2012 @ 11:30 AM

Pardus projesi Tübitak/Uekae’de birtakım çalışanlar ve bu çalışanların yaptıkları/yapacakları işlere inanan ya da gönül veren gönüllüler tarafından geliştirilen bir özgür yazılım projesidir. Özgür bir şekilde kullanılabilir, dağıtılabilir ya da değiştirilebilir.  Kendi içinde birçok alt proje barındırır. Dünya üzerinde birçok kaynaktan erişebileceğiniz özgür yazılımların dışında yukarıda bahsedilen insanlar tarafından geliştirilmiş teknolojileri vardır; paket yönetim sistemi, yönetim altyapısı, yönetim arayüzleri vs. [1] adresinden geliştirilmiş teknolojilere, [2] adresinden üzerinde birçok değişiklik/düzenleme vs. gerçekleştirilmiş diğer özgür yazılımların bulunduğu paket deposuna erişilebilir.

Pardus bugüne dek Türkiye’de gerçekleştirilmiş en büyük Özgür Yazılım projesidir.

Özellikle Türkiye’de yaşayan birçok insan için Özgür Yazılım ile tanışmanın sebebidir. Birçok insanın hayatını değiştirmiştir. Birçok yeni iş sahası ortaya çıkartmıştır.

~ * ~

Bir Özgür Yazılım projesi olarak gerçekleştirilmesine rağmen aynı zamanda Devlet desteği ile varlığını ortaya koyabilmiş bir projedir ve bu iki ayrı kavramın birbiri ile çatışmasından dolayı ortaya çıkmış hassasiyetin cezasını çekmiştir. Özgür yazılımın gerekleri ile Devlet’in gerekleri her zaman kesişememiştir.

~ * ~

“Türkçeye çevirmişler, sonra da biz yaptık diyorlar!

“Pardus Linux üstüne kurulmuştur, sıkıyorsa onu da yapsınlar!”

“Yeni bir şeye ne gerek var Debian çok güzel onu geliştirselerdi!”

… gibi söyleyen kişiler için çok büyük manalara gelen, fakat işin içinde olan insanlar için çok da öyle olmayan binlerce kalıp cümle ile eleştirildi Pardus. Eleştirilmesinde bir problem yok, zira eleştiriler insanlara nedenlerini anlatma, kendini düzeltebilme imkanı sağlar. Fakat eleştirmek için bir bilgi, birikim ve bikini gerekir.

~ * ~

Özgür Yazılım geliştirenler bilirler, e-posta listelerinde ya da irc kanallarında her an azar işitebilirsiniz. Bu hiç de sıra dışı bir olay değildir hele Türklere özel hiç değildir. Dünya üzerindeki bütün Özgür Yazılım geliştirenler için geçerlidir. Bunu dahi bilmeden bu tip davranışların sorumlusu bırakılmıştır Pardus ve Pardus Geliştiricileri. Doğru mudur, değil midir, herkes öyle yapıyor diye yapmak zorunda mıyızdır. Bunlar tabi ki tartışılabilir fakat bir şekilde özgür yazılımın doğası gereği bu iş böyledir.

~ * ~

Bunun dışında başka bir kesim daha vardır; tartışmak için gerekli altyapıya, bilgiye, birikime ve hatta bikiniye sahip olan fakat sadece tartışan. İşte bu tip insanlar genelde bizim ülkemize mensuptur. Bir ayrıntıyı da eklemek lazım; “sadece tartışan insanlar”. Dünya üzerinde tartışma kısmına kadar aynı olan fakat tartışma kısmını aştıktan sonra çokça övündükleri bilgi, birikim ve bikinileri ile gerçekten tartıştıkları noktada yeni bir akım yaratabilen insanlar. Biz özgür yazılımda buna çatallama (fork) diyoruz. Beğenmiyor musun? Dediğini yaptırmaya ikna edemiyor musun? O zaman çatallarsın! Bu dünyada bu şekilde çalışır, özgür olmanın dezavantajı ya da avantajı da budur.

~ * ~

Pardus projesinin içinde bulunmuş olmaktan çok mutluyum, kim ne derse desin artık pek umursamıyorum. İleride konuşmak için gerekli altyapıya sahip olsanız bile umursamıyorum. Biz çok güzel işler yaptık, çok yanlış işler de yaptık ama adım gibi eminim ki yaptığımız doğrular, yaptığımız yanlışlardan katbekat fazla.

~ * ~

Tübitak çalışanlarının açıklama yapmaması konusunda da bir not ekleyeyim; çalışanlar da ne olacağını, ne zaman neye karar verileceğini bilmiyor! Bu kararsızlığın sebebi maalesef projenin başarısızlığı ya da başarısı değil, Tübitak’ın kendi iç meselesi. Bu yüzden geriye iki seçenek kalıyor; ya çatallayacaksın Pardus’u ya da birilerinin keyfini bekleyeceksin. Her iki yolda da bekleyen birileri olacaktır, ben bundan eminim. Tabi her durumda yukarıdaki engeller karşınıza çıkacaktır.

~ * ~

Özgür Yazılımlar yok olmaz.

05 January 2012 @ 02:05 PM

Kaç kişinin aklına gelmiştir bilmem ama, yüze yakın kişinin “bu iş olmaz” ya da “bu iş böyle yapılmaz” dediğine şahit olmuşumdur Pardus’la ilgilendiğim altı sene boyunca. Bazıları işin içinde TÜBİTAK var diye, bazıları biz varız diye, bazıları da atılan adımları ve yapılanları doğru bulmadığı için konuştu, durdu.

Tekerleği yeniden icat etmeyin dediler herhangi bir dağıtımı temel almayacağımızı söyleyince, zamanında cesur bir hamle ile hiçbir dağıtımın yapmayacağı şeyi yapmak istedik ve “olmaz”ları dikkate almadık. Çok yetenekli olmasa da, sade ve kullanışlı araçlarımız oldu. Son baktığımda, bir geliştiricinin yüzlerce (abartı değil) paketin bakımını tek başına yapabildiği kadar basit bir paket yönetim sistemine sahiptik. KDE kullanan dağıtımlar arasında hala “en güzel KDE dağıtımı” olduğumuz söyleniyormuş, “Avrupa” görenler öyle diyor.

Başkalarının adımlarını izlemeliydik bazılarına göre, yeni bir yol denememeliydik. Debian’ı almalıydık, onu yaymalıydık. Onu başkaları da yapabilirdi, özel sektörden mesela. UEKAE bize ar-ge için fena olmayan bir bütçe (her iki sene için bir üst geçit parası) ayırmıştı, en kısa zamanda bir ürün ortaya çıkarma baskısı olmadan çalışma şansına sahiptik. Türkiye’deki şanslı ekiplerdendik yani. Birşeyleri araştırdık, yazılım geliştirdik ve ar-ge yapıyoruz dedik, çok tepki geldi. Deney tüplerimiz yoktu, ondan oldu hep.

Yoda “there’s no try” der ya, çeviriyi yanlış anlayanlar utansın, “deneyerek bulma” olamamalıydı. Laf edenlerin çoğunun Bilkent Linux ve LKD listelerini müdavimlerinden olunca dikkate aldık, ama yine de çoğunun dediğine uymadık. “Konuşması kolay, kodu görelim” (Talk is cheap, show me code” - Linus Torvalds) dedik, bozuldular. E-posta listeleri ve forumlar dışında hareketlerini göremediklerimize “kendilerine özgürler” ismini verdik. Her şey serbest, ihtiyacın olan her şey ortada. Durma, gidip yapsana?

Kızdık çoğuna, “Sen kendi projeni başlat, istediğin gibi yap, ya da git projeyi çatalla” diye sitem ettik; ama olay Türkiye’de geçiyor ya, onlar konuştu, biz işi kendi bildiğimiz gibi yapmaya, bol bol denemeye devam ettik.

Bazı zamanlar, istemeden veya farketmeden, katkısı olanları da bu gruba kattık, burada yanlış yaptık ama her tartışmanın ardından, onca laf söylendikten sonra hepimiz (biz, ve -sözde-onlar) yine aynı kümede toplandık.

Altı sene sonra, beş büyük dağıtımdan biri olamadık, sadece birkaç kuruma özgür yazılım sokabildik ama en azından denedik.

İki senede, bir üst geçit parasına.

03 January 2012 @ 09:00 PM

Bir yıla yakın süredir Amerika'da yazılımcı olarak çalışmaktayım. Çalıştığım şirket Princeton'dan akademik olarak ortaya çıkıp, önce bir startup oldu, daha sonra da büyük bir şirket tarafından satın alındı. Bu tür hikayeler yeni dünyada çok sıradan, girişimcilik günlük yaşamın parçası. Peki biz (yalnızca Türkiye değil, bütün Avrupa) bu kültürden ne kadar uzağız?

Silikon vadisinin gizli tarihi adlı bu video, Amerikan üniversitelerinin dünya savaşının peşinden savunma projelerinde yer almaya başlamasını, bu işlerin içindeki Frederick Terman gibi profesörlerin Stanford'a gelerek, öğrencilerin şirketler kurarak araştırmalarını ticarileştirmelerini teşvik etmesi, böylece vadinin HP, Intel, vb gibi ilk nesil teknoloji firmalarının ortaya çıkışını anlatıyor. Ortaya çıkan model çok özgün. Üniversite temel bilim araştırmalarının yapıldığı bir merkez görevini alıyor. Bu araştırmaları yapan öğrenci ve profesörler, işi somut bir ürüne dökmek istedikleri zaman dışarı çıkıp şirket kuruyorlar ve üniversite onlara araştırma sonuçlarının kullanımı için gerekli her türlü lisans ve kolaylığı sağlıyor.

Modelin başarısı, amacı insanlığın bilgi birikimini arttırmak olan araştırma çabaları ile, insanlığın bir ihtiyacını karşılamayı hedefleyen geliştirme çabalarını birbirinden ayırmış olmasında bence. Araştırma, önceden planlanamayan ve kısa vadede kâr getirmeyen, dolayısıyla bir zaman engeli taşımadan özgürce yapılabileceği bol kaynaklara ve ortama ihtiyaç duyan bir faaliyet. Geliştirme ise, gene planlaması çok zor da olsa, ihtiyaç duyacağı kaynakların gerekliliğini ispatlayabildiği ve tasarım sınırları dahilinde yürütüldüğü sürece ortaya daha başarılı ürünler çıkaran bir süreç. Akademisyenlerin özgürce bu iki dünya arasında geçiş yapabilmesi, doğru bilgilerin doğru ürünlere dönüşmesini çok destekleyen bir sistem.

Türkiye'de bu konudaki ilk sorun akademi ve özel sektör arasındaki büyük maaş uçurumu. Pek çok meslek gibi akademisyen maaşı da rahat bir hayat sürmeye yeterli değil, bu yüzden çoğu parlak genç özel sektörde bol mesaili dolayısıyla araştırma ya da boş vakit içermeyen bir işe girip akademiden tamamen kopuyor. Geçim sorunu yaşamayıp akademide kalabilenler ise devlet memurluğuna tabiyetten öyle kolay kolay şirket kurmak ya da ticari işlere girmek imkanına sahip değiller. Bu ekonomik nedenler üniversitelerdeki hocaların ve dolayısıyla eğitimin kalitesini de düşürüyor. Üniversite devletin verdiği paraya ya da zengin öğrencilerin harçlarına bağlı yaşayan bir meslek okulu pozisyonuna girince, buradan kendi başına ayakta durmayı öğrenmeden çıkan öğrenci de, kendine güvenden yoksun kalıyor. Tek marifeti zamanında dedesinin doğru bir araziyi satın almış olması ya da devlet tarafından zorla zengin edilmiş olmak olan uyduruk bir iş adamının yanında çalışmayı bile büyük bir hedef olarak görüyor. O adamla rekabet edebilecek bir iş kurmayı düşünmüyor bile.

Silikon vadisindeki model kurulduktan sonra, para kaynağı konusunda büyük değişimler geçirmiş. Savunma sanayi yerine normal tüketiciye yönelik ürünler geliştirmeye başlamış ve ilk başta kendi imkanlarıyla para bulan şirketler için bir sürü özel yatırımcı ve yatırım fonu ortaya çıkarak bugün Venture Capital denen girişim sermayesi piyasasını oluşturmuş.

Bu sektörü oluşturan neden tabii ki girişimlerin büyük kazanç getirme şanslarının yüksek oluşu. Ancak sektörün bu kadar büyümesinin nedeni sırf bu değil. Basit bir hesap yaptım, yaklaşık 10.000$ gibi bir miktardan daha büyük paralar için, bu parayı Amerika'dan Türkiye'ye yollamak, 3 aylık faize koyup sonra geri getirmek, tüm transfer ücretlerine rağmen, Amerika'da herhangi bir klasik faiz enstrümanına yatırmaktan daha kârlı. Faiz kazançları bu kadar düşük olunca, para sahipleri ya oturup somut bir iş yapmak, ya da parayı bu tür girişimlere yatırmak zorunda kalıyor. Bizde ise bırakın faizi, taksi plakası gibi absürd enstrümanlarla parayla para kazanmak varken parayı bir işe harcamak akıllıca bir hareket olmuyor (nasıl bu kadar yüksek faiz verebildiğimiz ise Türkiye ekonomisinin büyüdüğünü sananları yakın bir tarihte çok şaşırtacak ayrı bir hikaye).

Bu iki durumun oluşturduğu bir üçüncü durum daha var, o da girişimcilerin profili. Amerikan teknoloji şirketlerinin yatırımcı, kurucu ve üst düzey çalışanlarının büyük kısmı akademi ya da endüstriden gelen ve bağlarını koparmamış kişiler, zenginlik kaynakları ise hep teknolojik başarılar. Bu profilin getirdiği avantaj bu kişilerin zenginliklerini yeni girişimler için kullanma yüzdelerinin oldukça yüksek olması. Bu da gözü çalışanlarına iki saat daha fazladan mesai yaptırma, primlerini vermeme ve ar-ge harcamalarını mümkün olduğunca kısma derdinde olan feodal işadamı profiline göre büyük bir avantaj.

Türkiye'de "üniversite sanayi işbirliği" üzerine çok yazılıp çizildi. Bu konuda Tübitak gibi kurumlar kuruldu çalışmalar yapıldı. Cahit Arf'ın anılarında özellikle sanayicilerin Tübitak'a gelip şöyle teknik problemim var çözün diye istekte bulunmamalarından yakındığını hatırlıyorum. Yukardaki modeli gördükten sonra bunun niye yürümediğini anlamak kolay. Girişim o yönde çalışmıyor, yeniliği sizin yapıp müşteriye götürmeniz gerekli. Zamanla Tübitak da (özellikle son zamandaki mesela Feza Gürsey Enstitüsünün kapatılması gibi değişikliklerle) temel bilim desteğini azaltıp ürüne yönelik geliştirme yapan dolayısıyla çeşitli konularda özel sektörü de baltalayan bir yapı haline geldi. Teorik araştırmalar olmadan yapılan geliştirme yabancı ürünlerin ucuz benzerlerini yapmaktan öteye gidemiyor maalesef.

Son olarak tüm bu faktörler sağlanıp, bir başlangıç ivmesi sağlansa bile çok zamana ihtiyaç olacak, çünkü neredeyse bir yüzyılda ve sayısız başarı ve başarısızlıktan sonra edinilmiş bir kültüre sahip olmak kolay değil.

03 January 2012 @ 02:20 AM

Pardus projesinin, milli/ulusal/yerli işletim sistemi “macerası”nın, Türkiye’nin 60′lar ve 70′lerde yaşadığı yerli otomobil hareketlerine benzerliği konularında bu web günlüğü de dahil olmak üzere pek çeşitli yerlerde yazıldı, konuşuldu. Ben Pardus’un hikayesini Devrim arabalarından çok Anadol STC’ye benzetenler arasında yer aldım hep. Hatta Pardus-Devrim benzerliği kuranlara itiraz edip nedenlerini açıklamaya çalıştım. Biraz da bu nedenle, Devrim Arabaları filmi vizyona girip piyasaya çıkınca seyretmemeyi seçtim, bilinçli ve hatta kasıtlı olarak. Genç arkadaşlar “yahu bizim aynımız, herkes var, Serdar Hoca var, Umut bile var…” dediklerinde dahi merakıma ket vurdum, işi bir ilke meselesi düzeyine yükselttim, kendi kendime… Sonunda birkaç hafta önce filmin DVD’sini satın alıp izledim, durum onu gerektiriyordu artık… Gerçekten herkesler vardı, ben bile varmışımdı…

Fakat Pardus ile yerli otomobil girişimlerini karşılaştırma konusunda fikrim değişmedi, Pardus Devrim arabası değildi. Devrim arabalarına getirilen en önemli itirazlardan birisi, hatta çiçeği burnunda DPT’nin dahi söylediği yapılan işin seri üretime uygun olmadığı, çalışmanın genel fizibiliteden yoksun olduğu idi. Oysa 10 sene sonra yola çıkan Ekber Onuk ile Eralp Noyan ve arkadaşları özellikle ve öncelikle tasarlayacakları otomobillerin seri üretiminin yapılabilmesini, maliyetinin rekabetçi olmasını, kısacası projenin fizibilitesini gözönüne alıyorlardı. Sonunda tasarlayıp ürettikleri otomobilin nesli de bu tip sıkıntılardan değil, başka nedenlerle tükendi.

Biz de Pardus’u ilk düşünmeye başladığımız zamanlarda teknik konuları olduğu kadar iş modelini de şekillendirmeye çalıştık. İlk zamanlardan başlayarak “ekosistem” sözcüğünü dilimize doladık, “birileri Pardus’tan para kazanmalı ki milleti Pardus kullanmaya ikna etsinler” diye konuştuk. Daha Pardus 2007 piyasaya çıkmadan sektördeki donanımcı, yazılımcı, entegratör, eğitimci, sivil toplum örgütçü, akademisyen onlarca hatta yüzlerce kişinin kapısını çaldık; çoğunun ilk kez adını duyduğu Pardus’u, adını duyduğu ama ne olduğunu bilmediği Linux’u anlatmaya çalıştık, bu duydukları ve gördüklerinden bir iş fırsatı çıkarıp çıkaramayacaklarını sorduk, birlikte çalışma fırsatlarını araştırdık. 2006 yılı ortasında DPT’ye sunduğumuz, sonra hemen hç değiştirmeden 2008 yılında yeniden sunduğumuz ve 2010 yılından itibaren ciddi bir kaynak aldığımız proje önerisine ekosistem oluşturma işini, hem de başlıkta yer alacak şekilde yerleştirdik. Kısacası Pardus’u Anadol STC gibi tasarladık ve şekillendirdik.

Pardus’un projenin başlamasından yaklaşık 8,5, ilk ürünün yayımlanmasından yaklaşık 7 yıl sonra durumuna baktığımızda, bu tasarım ve şekillendirme ile çok da orantılı olmayan bir halde olduğunu görüyoruz. Teknik açıdan Pardus’u bir başarı hikayesi olarak görüyoruz, yalnız biz değil, Linux dağıtımı geliştirme işinden az buçuk anlayan herkes de (özellikle muasır medeniyettekiler) öyle görüyor. Oysa iş (business manasında) veçhesinde durumlar pek o kadar iç açıcı değil: Kurumsal pazarda yaygınlık, çözüm ortağı sayısı, ekonominin büyüklüğü, yatırımın geri dönüşü vb ölçütlere baktığımızda 7 yılda beklenen aşama katedilmiş durumda değil. Bu halin çeşitli nedenleri var, bana sorarsanız kimi açıklamalar, eksikler yanlışlar sıralarım. Ama sonuç değişmiyor, “in the tabele…”

Neticede ortada (eh, tamam “başarısızlık” demeyelim, ama) bir başarı eksikliği var. Pardus projesini bu rotasında yürütmeye devam ettirmenin hiç bir manası yok. Başka ve yeni bir yol bulmak, açmak, seçmek gerekiyor. Yine bana sorulduğunda söyleyeceğim, söylediğim kimi öneriler var; Pardus projesi için içsel ve dışsal kimi yeni unsurların devreye sokulacağı. Netekim söyledim de, yıllardır, aylardır ve son olarak da TÜBİTAK yönetim değişikliği ardından… Ancak yapılan değerlendirmelerde benim açıklamalarım, önerilerim, tekliflerim kabul görmedi; karar vericilerimiz Pardus projesini farklı bir şekilde yapılandırmayı tercih ettiler. Öyle sanıyorum ki Pardus için teknik ve iş alanında tercih edilen hareket tarzı önümüzdeki gün ve haftalarda Türkiye’de Pardus ve özgür yazılım için düşünen, konuşan/yazan ve çalışan kişi, grup ve kuruluşlar ile paylaşılacak.

Son 2,5 ay boyunca Pardus projesinin yönetilmesi görevim fiilen ortadan kalktı. Diğer projelerle ilgili iş ve sorumluluklarımı da 1 ay kadar önce tamamladım. Kısacası artık TÜBİTAK’ta yapacak bir işim kalmadı Uzun lafın kısası, 2 Ocak 2012 tarihi itibarı ile TÜBİTAK’taki görevimden ayrılıyorum, bu da bir “veda” yazısı… “Başlık nereden geliyor?” diyecek olursanız, daha önce projeden ayrılmış arkadaşların son günlük yazılarına bakıp “walla ne güzel başlık atmışlar, edebi ve hem de manalı” diye iç geçirişimin bir neticesi. Ve yazının başı bağlantı kuracak olursak Devrim Arabaları filminin beni çok etkileyen repliği: Celal Aga siyah Devrim arabasına biner, alkışlar arasında Meclis yoluna ilerlerler… 100 metre kadar ileride, kaçınılmaz olarak, aracın benzini biter, titreyerek durur. Mühendis çabalar, nafile. Celal Aga döner “ne oldu” diye sorar mühendise. Mühendis tükenmiş vaziyette yanıt verir: “benzin bitti paşam…” Üç sözcükte koca bir hikaye, son derece samimi bir de itiraf… İşte bana soracak olursanız “neden gidiyorsun?” diye vereceğim yanıt da bu üç sözcük, benzin bitti paşam… Yanlış anlaşılmaya; benzini biten Pardus projesi değil, kişi olarak bendeniz. Artık Pardus projesine verebileceklerimin sonuna geldiğimin bir ifadesi.

Pardus projesine hayatımın önemli bir kısmını verdim, belki de en verimli ve enerjili olduğum dönemini. Ürünün ve kimi bileşenlerinin adı dahil pek çok şeyde elim, dilim ve kafam var. Özgür yazılımın ne olduğunu, ne olması gerektiğini burada öğrendim; belki burada da öğrettim. Ben Pardus projesini şekillendirirken o da beni şekillendirdi. Pardus ile aramızdaki ilişki ve bağı anlatmak hayli zor, anlatmaya çalışmayacağım da… Pardus projesinin yoluna devam etmesi, benim yönetimimde yapamadıklarını yapması, iş alanında da bir başarı hikayesi haline gelmesi en büyük temennim. Sevgili kızım birkaç yıl sonra “okuma okulu”na gitmeye başladığında Pardus çalıştıran akıllı tahtalar ve tabletler kullansın istiyorum, Pardus onun için yalnızca babasının ve kendisinin tişörtlerindeki kedi kafası olarak kalmasın. Pardus ekibinde kalan, yeni gelecek olan, camianın parçası olan herkese vasiyetim bu: Pardus’u yaşatın ve benim götüremediğim yerlere götürün!

Önümüzdeki zamanda ne iş yapacağımı bilmiyorum. Bir süre dinleneceğim sanırım, hayli yoğun ve bir miktar sıkıcı geçti son 2 yılım ve özellikle son birkaç ayım… Sonrasında özgür yazılım çevresinde ve tercihan Türkiye’de bir işte çalışmak istiyorum (iş tekliflerine açığım ), yine tercihan bölgesel ve küresel etkiler yapabilecek bir pozisyonda. Tabi bir olasılık da 10 yıllık alan değiştirme periyotuma uyarak bilişim ile alakası olmayan bir alana transfer olmak, kim bilir! Sevgili Koray Löker’in önerisine uyup Pardus projesinin tarihçesini, doğru ve yanlışları belirleyerek, bizden sonra bu ormana dalacak gezgin ve maceraperestlere yol gösterecek şekilde, yazma/kaydetme kolektifini başlatmak ya da bir parçası olmak da aklımda… Bu web günlüğü hep canlı kalacak diye düşünüyorum, özgür yazılımla, okuduğum kitaplarla, sahip olduğum ve hiç olamayacağım dolmakalem ve saatlerle, kızımla yetiştirmeye çalıştığımız orkidelerle, yeniden çalmayı öğrenmeye çalışacağım basımla, gerçek okyanuslarda dolaştırdığım sanal yelkenlilerle ilgili şeyler yazmak için bir yere ihtiyacım hep olacak…

Pardus projesine nasıl katıldığımı, kimlerle çalıştığımı, ne kavgalar edip, ne hayallar kurduğumu, bu ekiple çalışmaktan nasıl keyif aldığımı anlatıp yol arkadaşlarımın cümlesine ismiyle teşekkür etsem, kimilerinden hellalik istesem bu yazı bitmez. İyisi mi ben de teamüle uyayım, “so long and thanks for all the fish” (balıklar için teşekkürler ve sağlıcakla!) deyip zaten haddinden uzun sürmüş bu yazıyı bitireyim!

31 December 2011 @ 09:00 PM

2 Ocak 2012 tarihi itibarı ile TÜBİTAK UEKAE’deki görevimden ayrılacağım için 4 yılı aşkın süredir Pardus projesi ile ilgili resmi duyurular için kullanmakta olduğum pravda pardus web günlüğü yayınına son vermektedir.

30 December 2011 @ 09:34 PM

İki ayı aşkın süredir Pardus projesinin akıbetini konuşuyoruz kendi bloglarımızda, forumlarda, sosyal medya sitelerinde. Maalesef herhangi bir resmi bir açıklama yapmadığımız için de kişisel görüş bildirmekten ileri gidemedi bu konuşmalar.

Koray’la birlikte bu bloga başlarken projede olan biteni anlattığımız bir yer olsun demiştik, hâlâ da aynı çizgide devam ediyoruz. Devam eden yeniden yapılanma süreci sonuçlanmış değil, yani çalışmalar devam ediyor. Yapılanma çalışmaları sürdüğü için, ilan ettiğimiz takvime göre Kurumsal 2.1′in çıkışını durdurduk. Ancak “Pardus projesi kapatılıyormuş” başta olmak üzere etraftan duyduğumuz laflar söylentiden ibaret. Proje kapatılmıyor, değişime ve dönüşüme uğruyor. Bu süreçte neler değişeceğini birlikte göreceğiz. Kararlar alındıkça, uygulamaya geçildikçe biz de yazıp sizleri bilgilendirmeye devam edeceğiz.

Yeni yılınız kutlu olsun.

30 December 2011 @ 01:11 PM

TÜBİTAK ve UEKAE’deki denge değişimi, Pardus projesini de etkiledi. Haziran ayından bu yana 10’dan fazla geliştiricinin işten ayrılması, projenin geleceğinden endişe duyulmasına sebep oluyor. Sadece kamu kurumlarının özgür yazılıma göçünü hedeflemekle kalmayan; ülkede bilgi birikimi oluşturmayı ve bir özgür yazılım ekosistemi kurma amacıyla yola çıkan bu küçük ama güçlü UEKAE projesinin akıbeti merak konusu.

Duyurulduğu 2010 Nisan’ından bu yana, dağıtım ismi, kullanılacak araçların özgürlüğü ve anonim katkı konusunda önemli tartışmalarla kendinden bahsettiren topluluk dağıtımı projesi Turkuaz, şu sıralar yola başka bir dağıtım ile devam etmeyi düşünüyor. Logo tartışmalarının yapılmasını beklerken, kullanılacak temel dağıtım ile ilgili bir duyuruyla karşılaşan gönüllüler uzun bir süre ortak bir noktada buluşamayacağa benziyor. 2012’nin ilk çeyreğinde yeni bir dağıtım bekleyen kullanıcıların bir süre daha beklemesi gerekecek.

Haftafa 100 saatten fazla toplam iş gücü sözü veren 20’den fazla geliştiricinin büyük kısmından haber alınamıyor. Camia her zamanki gibi dertli, bu sefer her zamankinden fazla.

27 December 2011 @ 09:22 PM

Araya bir sürü gelişme girdi, yazamadım.

Artistanbul’da epey hareketli günler yaşadığımızı söylemiştim. Bu hareketliliğin nedenlerinden biri, Artistanbul’un değişen ortaklık yapısı. Geçmişte Capitol Ogilvy Public Relations’ın müşteri direktörlüğünü yapmış olan sevgili Deniz Hazar, Artistanbul’un yeni ortağı oldu.

Deniz’in gelmesiyle şirket içinde pek çok değişikliği hayata geçirmeye başladık. Sözleşme metinlerimize kadar her şey yavaş yavaş değişiyor, ama asıl güzel gelişme, Artistanbul’un esaslı bir sermaye artırımına gitmesi oldu.

Artistanbul ailesine katılan bir diğer isimse Serkan Zihli. Aramıza katıldığı andan itibaren, Serkan iş yapma biçimimizi değiştirdi diyebilirim. Serkan sayesinde sıfırdan proje oluşturma ve sunum yapma yeteneklerimiz büyük ölçüde artmış durumda.

Geçen ay Özlem, Deniz, Serkan ve İrem ofise kapanarak, çok önemli bir konkurda bizi başarıya taşıdılar. Türkiye’nin en prestijli ajansları arasından sıyrılarak paydaşı olduğumuz bu projenin detaylarını, bir son dakika aksiliği olmazsa yakında paylaşıyor olacağım :).

Ve elbette en büyük haber…

Artistanbul’a bir kardeş firma geliyor! Yakında ayrıntılarını duyuracağımız bu firma için ofis yeri bakmaya başladık. Bu yeni şirkette Python, mobil uygulama geliştiricileri ve sistem yöneticilerine ihtiyacımız olacak.

Hatta fırsattan istifade, ilk iş ilanımızı yayınlayayım:

• PHP ve WordPress üzerine deneyimli,
• Linux ortamını tanıyan,
• Cihangir’de cici bir ofiste tam zamanlı olarak  çalışabilecek,

bir takım arkadaşı arıyoruz.

Aramıza katılmak isteyenler, gizem@artistanbulpr.com ile iletişime geçebilir :).

27 December 2011 @ 11:52 AM

Yaklaşık iki ay önce işlerin yoluna girebileceğini, ayrılmaların Pardus’un gelişimini etkilemeyeceğini anlatan; geçmişten bir çok örnek içeren bir nevi bir moral yazısı yazmıştım. O yazı da yazdıklarım hala geçerli tabi ki. Fakat yazının başlığından olsa gerek insanlar benim de Pardus’tan ayrıldığımı düşünmüş olacaklar dı ki, ayrıca bir de dipnot eklemiştim bir yere gitmediğime dair. Şimdi o dipnot yalan oldu, 14 Aralık 2011, benim Pardus ofisinde çalıştığım son gün oldu.

Neden ayrıldığımı soracak olursanız cevabım kısaca “sıkıldım” olacak, cevabımın nedenlerini bilenler biliyordur, bilmeyenler de bilmesin…

Bugün bu yazıyı yazdığımda Pardus ofisinden ayrılışımın ikinci haftasındayım. Neredeyse 6 yıldır aynı insanlarla, aynı konu üzerinde fakat her zaman farklı alanlarda çalıştım. Özgür yazılıma katkım o veya bu şekilde yine olacaktır fakat yeni işim (Sigma RD’de Kinect ile akla hayale sığmayacak teknolojiler geliştiriyoruz, dünyayı ele geçireceğiz) gereği eskisi gibi çalışamayacağım aşikar. Özgür yazılım camiasına, özgür yazılım kullanan insanlara bir yararım dokunduysa ne mutlu bana. Sağlıcakla kalın.

Bu paragraftan sonrakilerin hiçbirini okumasanız da olur, kendi kendime neler yapmışımın notlarını aldım sadece.

Özgür yazılıma elle tutulur ilk katkım 2002 yılında yaptığım ilk şenliğin afişiydi (şimdi bakınca berbat gözüken). Şenliğin devamında LKD sayesinde bir çok yerde standlar kurduk, sunumlara katıldık, insanlara özgür yazılımı anlattık.

O dönemlerde Murat Koç’un yönettiği FrontSite adlı şirkette yarı zamanlı çalışmaya başladım, Barış Metin ve Enver Altın ile birlikte çalışma fırsatı buldum.

Kerem Can Karakaş’ın önerisi ve o dönem (2004) Pc World  Genel Yayın Yönetmeni olan Güçlü Aydoğan’ın da desteği ile Pc World dergisinde açık kaynak köşesinde bir süre haber ve inceleme yazıları yazdım.

Bu dönem ve sonrasında da pek sevgili Ümit Bozkır, Arda Çetin ve adını hatırlayamadığım bir çok özgür yazılım gönüllüsü ile birlikte standlar kurduk, fuarlara katıldık, LKD’yi temsil ettik.

Yine bu dönemlerin sonuna doğru Penguen Yazılım bünyesinden Kosgeb desteği alan firmalara Linux’a giriş eğitimi verdim.

Bu arada üniversite bitmek üzereydi, staj yapmam gerekiyordu. 2006 yılında ki Özgür Yazılım günlerinde Erkan Tekman’a Pardus projesinde staj yapıp yapamayacağımı sordum, karşılığında aldığım “stajı boş ver gel yarı zamanlı ekibe katıl” cevabının ardından 2006 Nisan’ında Pardus serüvenim başlamış oldu.

O aralar sıkça ilgilendiğim web teknolojileri konusunda da kendimi geliştirebilmek için aynı zamanlarda Octeth’te PHP ile ilgilendim, Cem Hürtürk’ün de desteği sayesinde Octeth’in amiral gemisi OemPro için bir kaç özellik ekledim.

Sonra okul bitti, artık tam zamanlı olarak bir işe başlamam gerektiğinden 2007 yılında Tübitak Uekae’de Pardus Projesindeki çalışma hayatıma başladım…

2009 Ağustos ayında işe güce kısa bir ara verip 2010 Şubat’ında tekrar işe başladım. 14 Aralık 2011′de ise Tübitak günlerim sona erdi.

Pardus projesinde çalıştığım dönem boyunca bir çok alt projede görev aldım, sahipsiz olan bir çok gereksiz işi de yaptım. Yalı, Yönetici Ailesi, Grafikler, arayüzü olan hemen hemen her Pardus teknolojisine katkıda bulundum. Zaman su gibi geçti gitti. Çok güzel günlerdi, çok güzel insanlarla tanıştım arkadaş oldum. Yaptığım hiç bir şeyden de pişman olmadım. Çoh iyiydi yani.

26 December 2011 @ 02:28 PM

Bundan bir buçuk ay öncesinde The New Yorker dergisinde güzel bir yazıya denk gelmiştim. Maalesef paylaşılabilir bir yazı olmadığından sizlere sunamadım içeriğini. Yazı, bir süre önce kayınbabasını kaybeden ve ondan geriye kalan devasa bir kitaplık ve kitapları nasıl değerlendirmesi gerektiğini bilmeyen bir yazarın) anıları hakkında. Aşağıdaki resim bu kitaplığa ait:

Kayınbabasını öldükten sonra bu kitaplar miras kalıyor kendisine. Fakat bu büyüklükte bir kitaplığı ve haliyle kitapları saklayacak yeri olmayınca bunlarla neler yapabileceğini düşünmeye başlıyor.

Bundan yaklaşık iki yıl önce kitaplar ve kitaplıklar hakkında bir yazı yazmıştım: Kitaplar üzerine. Bu yazıyı Rands'ın "Kitaplıklar insanların özelliklerini, ilgi alanlarını ve kısacası hayatını sergileyen anıtlar haline gelmiştir. Yabancı bir eve girdiğimde ilk yaptığım iş kitaplığına bir göz atmak. Böylelikle anında bir çözümleme yapabiliyorum." yorumu üzerine yazmıştım.

Ben hâlâ bu şekilde düşünüyorum.

Fakat New Yorker'deki yazı, tam tersi bir bakış açısına yer vermiş. James Wood), kayınbabasının kitaplıklarını bir yere taşıyamayacağını anladığında satmaya karar verir. Fakat bir yandan kitaplara da göz atıyor, kayınbabası ile ilişkilendirmeye ve kitaplar üzerinden onun portresini çıkartmaya çalışıyor. Fakat bunda başarılı olamıyor. Kitapları araştırdıkça çizmek istediği resmin (mecâzı anlamda) aslında kayınbabası ile hiç ilgisi olmadığı ortaya çıkıyor. Bununla ilgili kısmı tekrar dergiden çıkartıp yazdım:

"We had a couple of breaks. An online bookseller, who deals in rare books and first editions, came and picked through what interested him, and filled his old Volvo with boxes. A few days late, an English bibliophile, who teaches philosophy at Queen's University, did the same. I enjoyed their obvious excitement, my enjoyment tempered by the sensation that the library was suffering death by a thousand cuts

For in any private library the totality of books is meaningful, while each individual volume is relatively meaningless. Or, rather, once separated from its family, each individual book becomes relatively meaningless in relation to the original collector, but suddenly newly meaningful as the totality of the author's mind..

.. In this strange way, our libraries are like certain paintings that, as you get closer to the canvas, become separate and unreadable blobs and daubs of paint.

And in this way, I began to thinks, our libraries perhaps say nothings very particular about us at all. Each brick in the wall of a library is a borrowed brick"

Sizce bir kitaplık bir kişiyi tarif edebilir mi ? Yabancı bir eve girdiğimizde kişinin kitaplığına göz atarak onun neyle ilgili olduğunu, neyi sevdiğini, neyle ilişkili olduğunu öğrenebilir miyiz?

15 December 2011 @ 11:40 PM

Pek yazı yazmadığım sevgili blogumdan da ve pek çok sevdiğim Pardus projesinden bugün itibari ile ayrılıyorum.

Kapanışı pek sevdiğim sefiller müzikalinin çok sevilen şarkısının sonu ile yapalım

I had a dream my life would be
So different from this hell I’m living
So different now from what it seemed
Now life has killed the dream I dreamed.

Geç gelen düzenleme…

Bundan sonra ara ara yazılarım şuradan takip edilebilir.

14 December 2011 @ 12:52 PM

Biraz farklı bir konuda kısa bir çalışma yaptım. İlginç bir macera olduğu için yazmak istedim.

12 December 2011 @ 07:18 PM

Dün birçok havacılık meraklısı insanın yanısıra otellerin ve havayolu şirketlerinin çeşitli havalimanlarına iniş yapacak olan uçakları görebildikleri, kule ile aralarında olan telsiz konuşmalarını dinleyebildikleri iststatus.com kapatıldı. Kapatılma sebebi ise “güvenlik”. Devlet Hava Meydanları İşletmesi, VIP uçakların içerisindeki yolcuların, uçak kodunun, havadaki pozisyonunun herkes tarafından açık olarak görülmesinin bir güvenlik zaafiyeti oluşturduğunu düşünmüş ve öyle görünüyor ki teröristlerin bir saldırı yaparak uçağı düşürmelerinden korkarak kapatılmasını sağlamış [0]. Bu düşünce tarzının yanlış olduğunu, kafamıza kuma gömmek olduğunu ve doğru olanın ne olduğunu bir şekilde DHMİ’ye anlatmak gerekiyor.

Konuyu daha iyi anlayabilmek için iststatus.com ‘un bu servisi nasıl sağladığına fazla teknik detaya inmeden bir bakalım. Radar sistemlerinin nasıl çalıştığını hepimiz az çok biliyoruz. Bir radar sinyali göndererek objelerden seken sinyali işleyip bu objelerin bize olan uzaklığını hesaplayarak objelerin konumunu belirleyebiliyoruz. Havacılıkta bu radara Birincil Radar (Primary Radar) deniyor ve genel olarak yedek olarak kullanılıyor. Ancak şöyle bir sorun mevcut, uçakların kuleye olan uzaklık bilgisinin yanısıra yerden olan yüksekliği, uçak kodu gibi bilgilerin de bilinmesi gerekiyor. Bunun için birincil radar yetersiz kaldığı için İkincil İzleme Radarı (Secondary surveillance radar) kullanılıyor. Basit olarak her uçak gerekli bilgileri içerisinde barındıran bir alıcı/verici (transponder) taşıyor. İkincil izleme radarı bir sinyal gönderip bilgi istediği zaman uçaklarda bulunan bu alıcı/verici gerekli bilgiyi kodlanmış (şifrelenmiş değil) bir biçimde 1090 MHz‘den yayınlıyor.  DHMİ’nin söylediğinin aksine şunu belirtmek gerekir ki bu bilgi uçağın içerisindeki yolcu bilgilerini kapsamamaktadır.

IstStatus‘un yaptığı şey zaten herkes tarafından görülebilen, şifrelenmemiş ve 1090 MHz’de gönderilen veriyi anlamlı bir veri haline getirip 3 dakika gecikme ile insanlara sunmak. Telsiz konuşmaları da tek bir kanal değil, birden fazla kanal dolaşılarak veriliyor. Bu kanallar, benim bildiğim kadarıyla, yer, yaklaşma, ve kule. Burada konuşulanlar ise tamamiyle havacılıkla ilgili ve anormal bir durum olmadığı sürece “TK 321, yüksekliğini aaa’ya çıkar, hızını bbb’ye düşür, baş kısmını da ccc’ye yönelt” şeklinde ve herhangi bir önemli bilgi içermiyor. Tekrar hatırlatmak gerekiyor ki bu telsizler de herkes tarafından rahatlıkla dinlenebilir.

IstStatus türünün tek örneği değil tabi ki. Dünyanın birçok yerinde, görünüllü insanlar evlerinin çatılarına basit bir telsiz anteni ve az önce bahsettiğim 1090 MHz’de yayınlanan veriyi anlamlı hale getirecek cihazı koyarak (ADS-B Receiver) insanlara havaalanında neler olduğunu sunuyor. Bunun çeşitli yararları mevcut. Birincil olarak havacılıkla ilgilenen çeşitli insanlar kuleyi takip ederek muhabere konusundaki bilgilerini genişletiyorlar. Bu, aynı zamanda kulede ya da uçakta meydana gelen bir olumsuzluk durumunda otokontrol sağlıyor. Bir diğer yararı ise oteller ve misafirlerini havalimanında karşılayacak olan oluşumlar bu sayfayı takip ederek uçağın nerede olduğuna bakarak araçlarını zamanında çıkarıyorlar ve havalimanındaki gereksiz trafik engellenmiş oluyor. Bunu, iststatus kapandığından beri Atatürk Havalimanında yaşanan araç trafiğinden anlayabiliriz.

Herhangi bir terörist eylemi gerçekleştirme planı olan bir insan, 3 dakika gecikme ile aldığı bilgiyi kullanmayacaktır ve daha sofistike düşünmesi gerekir. Elinde yaklaşık olarak 400-500€ maliyeti olan ADS-B alıcısı olan bir insan bu bilgileri zaten görebilecektir. Şu anda alınan karar kafamızı kuma gömmekten başka bir şey olmamakla birlikte otokontrolü ve havacılık meraklılarının çalışmalarını engellemektedir. Öyle görünüyor ki kuledeki insanlar ve DHMİ, bu otokontrolden rahatsız oluyorlar. Dilerim ki havacılık meraklıları, telsiz meraklıları ve bir şekilde iststatus’den yararlanmış insanlar bu konunun peşini bırakmaz.

[0] http://www.airporthaber.com/iststatus-susturuldu–36590h.html

12 December 2011 @ 07:09 AM

Bugün ofiste getchar(), putchar() fonksiyonları ile küçük ASCII denemeleri yapıyordum. Bunlara bakarken "char" veri tipi ile de biraz haşır neşir oldum. Beklemediğim bir kaç davranışla da karşılaştım. Aklımdan kalanları kısaca aktarmak istiyorum:

"char" veri tipi, C'nin basit veri tiplerinden sadece biridir. Diğerleri ise sırayla int, float, double ve void. Bu birincil veri tipleri de yine kendi aralarında bazı ön ekler alarak yeni veri tipleri oluşturuyorlar. Örneğin long int, short int, unsigned long int, vs.. gibi. Bu veri tiplerinin her birinin bellekte tuttukları miktar da farklıdır. Aşağıdaki tablo'da örneklerini görebilirsiniz (char ile ilgili kısım yanlış, önü göz ardı edebilirsiniz):

Gördüğünüz gibi her veri tipinin büyüklüğü farklı olabiliyor. Ayrıca aldıkları önekler (short ve long) sayesinde bunları küçültüp veya büyütebilirsiniz.

"char" veri tipi ise ailemizin en küçük veri tipi diyebiliriz. Kendisi aslında tıpkı "int" gibidir, yanı tam sayılar için tasarlanmıştır. Bu yüzden tam sayı hesaplamaları için de kullanabiliriz. Fakat C dili ile kod yazarken de C'nin dahili olarak desteklemesi gereken belirli bir karakter kümesi olması gerekiyor. Yoksa dünyada herkes kafasına göre bir karakter seti kullanabilirdi (hiragana, kiril, arapça, türkçe,vs..). Bu yüzden C standardında ASCII karakter seti kullanılınıyor. Her bir karakter de birer tam sayı olarak kaydediliyor. Örneğin "A" harfi ASCII'ye göre "65" sayısına denk geliyor. Hangi harfin hangi sayıya denk geldiğini ASCII tablosundan bakabilirsiniz.

Üç çeşit char veri tipi var, her birinin sahip olabileceği veriler ve isimleri şu şekilde:

• char --> Bilgisayar platformuna göre signed char veya unsigned char olabiliyor
• signed char --> [-128, 127]
• unsigned char --> [0, 256]

Yukarıdaki listeye bakarak iki çeşit "char" veri tipi var diye düşünmeyelim. Her biri kendince anlamı olan veri tipleridir. "char", "signed char" veya "unsigned char" adında üç çeşit karakter veri tipi var. "signed char" veri tipi ise gömüllü sistemlerde ya da bilimsel kodlarda çok sık kullanılınır, çünkü kendisi en az yer kaplayan ve negatif,pozitif sayılar kümesini içeren tek veri tipidir. Ama genel olarak insanlar her daim "char" veri tipini kullanıyor. Yani şu şekilde bir şey:

char a = 30;

Şimdi bu örnek hiç bir platformda sorun çıkarmayacaktır (ayrıca belirttiğim gibi char tam sayı saklayabilen bir veri tipidir). Çünkü hem "signed char" hem de "unsigned char" tam sayı aralığına uyuyor. Peki şöyle bir örnek yazdığımızda ne olacak:

char a = 255;

Burada okumayı bırakıp küçük bir deneme yapabilirsiniz. Muhtemelen iki türlü cevap gelecektir. Yukarıda değindiğim gibi "char" veri tipi bilgisayar platformuna göre değişiyor. x86 GNU/Linux ve Microsoft Windows'da "signed char" olabilirken, PowerPC ve ARM processors genellikle "unsigned char" olabiliyor. Bu yüzden:

• "signed char" ise a = -1 değerini alacak (neden -1 ? yazının sonunda açıklaması mevcut)
• "unsigned char" ise a = 255 değerini alacak

Görüldüğü gibi hiç beklemediğiniz sonuçlara yol açabilir sade bir "char" veri tipi. Bunun önüne geçebilmenin yolları var, en mantıklı ve güveniliri en baştan "signed char" veya "unsigned char" veri tiplerini kullanmak. Bunu bir alışkanlık haline getirmek iyi bir davranış olabilir. Başka bir seçenek ise derleyici sisteminin desteklediği parametrelerini kullanarak "char" veri tipini sınırlamak. Örneğin GCC ile derliyorsanız , -fsigned-char ve -funsigned-char parametrelerini kullanarak "char" veri tipinin etki alanını kısıtlayabilirsiniz.

Yazımın başında da değindiğim gibi getchar() ile denemeler yapıyordum. getchar() fonksiyonu veri tipi olarak "char" yerine "int" veri tipi dönderiyor. Yani klavye'den "A" tuşuna bastığınızda size "65" sayısını döndürecek. Peki neden "char" değil de "int"? Genel olarak getchar() fonksiyonu EOF ile birlikte kullanacak şekilde tasarlanmıştır. EOF sayesinde dosyanın sonunu öğrenebilme(end-of-line) ya da getchar() ile veri almayı durdurabiliriz (örneğin CTRL+D tuş kombinasyonu ile EOF yaratabilirsiniz). EOF'un değeri ise "-1" olarak belirlenmiştir. Bunu linux platformlarında /usr/include/stdio.h dosyasını açarak ~112 satır numarasına bakarak görebilirsiniz. Şöyle bir kod parçası vardır:

/* End of file character.
   Some things throughout the library rely on this being -1.  */
#ifndef EOF
# define EOF (-1)
#endif

Genellikle getchar() kullanırken insanlar "char" veri tipi kullandıkları için sorun oluşabiliyor. Aşağıdaki gibi bir kod parçası düşünün:

#include

int main (void)
{
  char a;
  while ((a = getchar()) != EOF)
      printf("%c\n", a);

  return 0;
}

Burada getchar() fonksiyonunun dönüş değeri için "char = a" veri tipi kullanılmıştır. Örneğin GNU/Linux makinede bu kodu derlediniz ve sizin "char" veri tipini "signed char" veri tipine dönüştü. Sonra bu kodu çalıştırdınız ve klavyeden verileri girmeye başladınız. Muhtemelen hiç bir sorunla karşılaşmayacaksınız. Çünkü "signed char" -128'den 127'ye kadar tüm tamsayı değerlerini alacaktır.

Fakat bu kodu ARM mimari bir platformda çalıştırınca "char" veri tipi "unsigned car" veri tipine dönüşecektir. Bu veri tipi de 0 ile 256 arasındaki tamsayı değerleri alıyor. Peki EOF burada hangi değeri alacak? Siz CTRL+D bastığınız an ya da bir dosyanın sonuna geldiğinizde geri dönen "-1" değeri 255'ye dönüşecektir(yazımın sonunda neden böyle olduğunu anlatacağım). Böyle olunca while döngüsü sonsuz bir döngüye girecek ve hiç çıkamayacaksınız. Yukarıda kod parçasında "int" ile tanımlanmış veri tipini "unsigned char" olarak belirtmemiz sorunu düzeltecektir. Düzeltme şu şekilde olacaktır:

#include

int main (void)
{
  unsigned char i;
  while ((i = getchar()) != EOF) 
      printf("%c\n", i);

  return 0;
}

Yukarıdaki kod parçası taşınabilinir ve daha güvenilirdir.

Yazıda sık sık "-1" <=> "255" dönüşümünü görmüşündüzdür. İki tür örnekle karşılaşmıştık:

• "char a = 255" değerinin "signed char" veri tipinde "-1" dönüşmesi
• "char a = EOF" değerinin(EOF = -1 ..) değerinin "unsigned char" veri tipinde "255" dönüşmesi

İlk örnek için devam edelim. 255 numarası ondalık sayı sistemi ile ifade edilmiştir. Fakat "unsigned" ve "signed" kavramları ikili sayı sistemine göre tasarlanmıştır. 255 sayısının ikili sayı sistemindeki değeri ise 1111 1111, yani 1 byte (8-bit) yer kaplıyor. Şunu not alın "1111 1111" ikili sayısı "signed char" olarak belirlinmiştir(doğrudan bu şekilde kaydediliyor). Fakat signed ikili sayıları 1 + 7 bit şeklinde belirleniyor. En soldaki ilk bit sayının negatif(1 ise) ya da pozitif(0 ise) olduğunu gösterir, kalan 7 bit ise sayının değerini gösterir. Bu yüzden örneğimiz şu şekilde:

1 111 1111 (negatif bir sayı ve sayımızın ikili değeri 111 1111)

Signed ikili sayıları tekrar ondalık sayısına çevirmek ise basit bir işleme bakıyor. Sayının "2's complement"ini almak. Bunu da kısaca tüm sayıları tersine çevirip, çevirdikten sonra +1 bir ekliyoruz. Devam etmeden önce kısa bir örnek yapalım:

101 1001

sayısını çevirelim. İlk önce her bir numarayı tersine çeviriyoruz

010 0110

ardından +1 bir ekliyoruz:

010 0111

Kısacası 101 1001 numarasının 2s complement eşleniği 010 0111 oluverdi.

Tekrar örneğimize geri döndüğümüzde, bizim elimizdeki numaranın "111 1111" tersini alıp "000 0000" +1 eklediğimizde "000 0001" sayısını elde edeceğiz. Bunun ondalık sistemindeki değeri de kısaca "1" dir. Fakat unutmayın ki bu sayı negatif bir sayıdır (en soldaki bir negatif olduğunu gösteriyordu). Bu yüzden sayımız "-1" olarak gözüküyor. Yani bizim meşhur "char a = 255" değerinin "signed char" veri tipinde "-1" dönüşmesinin sonucu diyebiliriz.

İkinci örneği siz okurlara bırakıyorum, bu sefer tersten gitmeniz gerekiyor ve elinizdeki sayı unsigned olacağından 255 sayısını elde edeceksiniz.

Hepsi bu kadar. Görüldüğü gibi küçük bir veri tipi dikkat edilmediğinde bir çok soruna aşabiliyor. Bununla ilgili başınızdan geçen senaryolar, sorularınız veya merak ettikleriniz varsa yorum kısmından sorabilirsiniz. Bir çok kaynaktan yararlanmıştım, aşağıdaki bağlantılardan detaylı bir şekilde bakabilirsiniz:

1. http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html
2. http://www.lix.polytechnique.fr/~liberti/public/computing/prog/c/C/CONCEPT/data_types.html
3. http://www.dreamincode.net/forums/topic/23249-trying-to-understand-signed-char-variable/
4. http://stackoverflow.com/search?q=signed+char

29 November 2011 @ 07:52 PM

Ursula K. LeGuin Mülksüzler‘de ses ve can verdiği Odo’nun mezar taşında kendine ait bir sözün kazılı olduğunu resmeder: Bütün olmak parça olmaktır; gerçek yolculuk geri dönüştür.

2008 Temmuz’u başında (epey de kötü ve yavanından) bir veda mektubu yazarak ilk gününden beri coşku ve heyecanla çalıştığım Pardus projesindeki profesyonel görevimden ayrıldığımı duyurmuş; aşağı yukarı iki sene sonraysa tekrar yuvaya dönmüştüm…

Odo’nun bütün olmak parça olmaktır lafı pek güzel tarif ediyor katılımcı, ortak hareket etmeye önem veren özgür yazılım ruhunu. Parlak, önemli, göze çarpan bir şeyler yapan biri olmadan, bütünün parçası olarak, bütünü var etmek, bütün olmak mümkün diye hissettiren, şahane bir üretim şekli.

Pardus da her zaman bunun keyifli, önemli ve güzel bir parçası olageldi. Fakat yoruldum. İnsanın kolay kolay birlikte çalıştığı herkesi tek tek dostu, arkadaşı bildiği, tanıdığı işler bulabileceğini sanmıyorum… Ama bunun yetmediği bir an geldi.

Bu duygu ve düşüncelerle boğuşmaya öyle ya da böyle bir son vermem gerekince… Birkaç yıldır kafamda dönüp duran başka bir projeye gerçekten başlayabilir hale geldiğimi düşününce… Değişiklik iyidir diye inanınca…

Bugün Tübitak’taki görevimden ayrılmak istediğime dair dilekçeyi verdim. Başlık S.Çağlar Onur’a, resim  Bahadır Kandemir’e birer selam…

Hepsi çok güzeldi. Keşke hiç bitmeseydi… Ama bitti. Bence gerçekten bitti…

28 November 2011 @ 08:55 PM

Dün LKD’den Merve Yalçın‘la birlikte Bala’daydık. Bala Lisesi, Bala Anadolu Lisesi ve Bala Atatürk Anadolu Teknik ve Meslek Lisesi’nden öğrencilere Özgür Yazılım, Linux ve Pardus anlattı Merve. Ben de kısaca Pardus’ta neler yaptığımızdan, eğer ilerde bize katılmak isterlerse bunun nasıl olabileceğinden bahsettim. Özellikle Endüstri ve Meslek Lisesi öğrencileri çok ilgililerdi. Gençlerle birlikte çalışmak, vakit geçirmek insana başka türlü bir enerji ve umut veriyor. Umarım dün hayatında ilk kez özgür yazılımla tanışan beyinler için de biz biraz umut vermişizdir.

Pardus’u bizden çok sahiplenen, gençlere tanıtmak için elinden gelen gayreti gösteren, organizasyonu yapan Selim Demirtürk’e burdan bir kez daha teşekkür ediyorum.

18 November 2011 @ 11:43 AM

Artistanbul’da bu aralar çok yoğunuz.

Bildiğiniz gibi değil, aramıza yeni isimler katılıyor, ofise masalar/dolaplar geliyor, büyük konkurlara çağrılıyor, kurumsallaşma yönünde güzel adımlar atıyoruz :). Her şey yolunda giderse, bir süre sonra Cihangir’deki çok sevdiğimiz ofisimiz artık yetmeyebilir, daha büyüğüne çıkmak zorunda kalabiliriz. Hatta belki de 2012′de yurtdışında bir ofis açarız, kimbilir?

İyisi mi, büyük haberlerin ayrıntılarını “bir süre sonrası”na saklayalım :).

(…)

Bu arada bizleri çok heyecanlandıran bazı yeni projelere de girmiş durumdayız. Bu projelerden yavaş yavaş bahsetmenin zamanı geldi sanırım.

Muhtemelen biliyorsunuzdur, Artistanbul ana faaliyet alanı “iletişim danışmanlığı” olan bir firma. Öte yandan bünyesinde yazılım geliştiricileri barındıran ve çeşitli yazılım projeleri geliştiren bir firma olarak, bir kurum kültürü olarak “özgür yazılımdan yana” bir tavır benimsiyoruz.

Son zamanlarda yolumuz, Türkiye’ye yatırım yapmaya hazırlanan bazı dünya devleriyle kesişmeye başlamıştı ve çeşitli işbirliği görüşmeleri yapıyorduk.

Bu markaların ilkini artık açıklayabiliriz: BlackBerry :)

Belki takip etmişsinizdir, BlackBerry’nin üreticisi Research In Motion firması, 1,5  yıl kadar önce QNX Software’i satın almıştı. QNX, BlackBerry’nin yeni nesil cep telefonları ve tabletlerinde kullanılmaya başlanacak olan BBX platformunun da çekirdeğini oluşturuyor.

Muhtemelen 2012′nin ilk çeyreğinden itibaren piyasaya çıkacak olan tüm BlackBerry telefon ve tabletlerde karşımıza BBX platformu çıkacak. Research In Motion firması, BBX’e yönelik geliştirme araçlarını özgür lisanslarla yayınlarken, pek çok özgür yazılım projesine desteğini de açıklamış durumda.

Önümüzdeki dönemde, BlackBerry cephesinden özgür yazılım dünyasına yönelik pek çok güzel haber gelmeye devam edecek :). Bu haberlerin Türkiye’yi ilgilendiren kısmının başlangıcını ben duyurayım:

BlackBerry ile birlikte Türkiye’nin aynı anda 6 ila 8 üniversitesindeki öğrenci gruplarıyla birlikte mobil projeler geliştireceğiz. Bir başka deyişle, 6 ila 8 üniversitede Unix tabanlı proje grupları oluşacak!

Yakında, daha güzel haberlerle karşınızda olacağız :).

15 November 2011 @ 06:36 AM

Yine uzunca bir aradan sonra benim için heyecan verici bir konuda blog yazmaya karar verdim. Yakın çevrem tarafından artık gündelik bir olay halinde kanıksanan uykusuzluk krizlerim boyunca geçtiğimiz haftalarda okuduğum bir olayı aktarmak istiyorum.

Önce sıkıcı özet ve bi çimdik tarih dersi

Malum Android cephesinde bir yandan özgür yazılım kullanan ve savunan pek çok kişiyi sevindiren gelişmeler olurken bir yandan da kara bulutlar bu büyük yazılım projesinin peşini bırakmıyor. Daha popüler olduğu için sürekli gündemde olan Apple ve OEM üretici davaları bir yana asıl büyük sorunlara gebe olacak kısım özellikle Java ile ilgili konularda Oracle ve Google arasında. Her ne kadar davayı gören yargıç sulhe imkan tanımak amacıyla davayı bir miktar ertelemiş bile olsa Android’in özellikle bu dava sonucunda yara alması kaçınılmaz gibi duruyor.

Benim ilgimi çeken konuysa Android’in bazı konularda GPL’in etrafından dolaştığı ve GPL’in katı copyleft kuralını ihlal ettiği iddiası oldu.

Malum Android’in kalbini şu an Linux çekirdeğinin 2.6 ailesi oluşturuyor ve blogu takip edenlerin bileceği gibi bu çekirdek GPLv2 ile lisanslanıyor. Bu sayede hepimiz özgürce bu çekirdeği kullanabiliyor, değiştirebiliyor ve değiştirdiğimiz halini dahi yeniden dağıtabiliyoruz. Çekirdeğin yazıldığı dil gereği çekirdek geliştiricileri yazılımın bütününü oluşturan değişkenleri, sınıfları ve diğer tanımlamaları header -başlık- dosyalarında tanımlayıp daha sonra bu dosyaları yazılımın genelinde kullanarak hem aynı tanımlamaları tekrar tekrar yapmaktan kurtuluyor hem de istedikleri değişiklikleri tek bir noktada uygulayıp tüm yazılım genelinde etkin olmasını sağlıyorlar. Bu teknik zaten yıllardır C, C++ gibi pek çok dilin temel özelliği olarak kullanılıyor.

Linux çekirdeği de yaklaşık 750 dosyadan oluşan bir header setine sahip. Bu dosyalar tıpkı bağlı oldukları yazılım gibi GPL ile lisanslanmış durumda. Bu header dosyalarında tanımı yapılmış fonksiyonlar ve tanımlamalar aslında bu çekirdeğin üst katmanlarında çalışan yazılımların sistem çağrıları yapması için de bir API sunması açısından son derece önemli. Bir sistem kaynağı kullanmak isteyen yazılımlar bu API’den faydalanarak çekirdeğe ve onun üstünden kullanmak istedikleri sistem kaynağına -örneğin bir donanıma- ulaşabiliyor. Linux dünyasında bu dosyalar “raw headers” olarak isimlendiriliyor ve aslında teamül bu dosyalar yerine başka bir kitaplık ile çekirdeğe sistem çağrıları gönderilmesi üstüne kurulmuş durumda.

1990lı yılların başında Linux ekibi çeşitli lisans çakışmaları önlemek ve geliştiricilerin daha rahat çalışmasını sağlamak amacıyla zaten bu header dosyalarının oluşturduğu gurubu forklamıştı. Daha sonra FSF tarafından GNU işletim sistemi için geliştirilen ve hepimizin tanıdığı GNU C Libary -glibc- yine bu ekip tarafından forklanıp uzun yıllar bakımı yapılmıştı. 1997 yılında FSF’in glibc 2.0 yayınlamasıyla bu kitaplıkla gelen özellikleri gören Linux ekibinin forklarını öldürmesi ve FSF’in glibc ağacına geri dönmesi ile glibc sistem çağrıları vb. teknik işler için özgür yazılım dünyasının değişmez standardı oldu.

Glibc’nin kernel header dosyalarının sunduğu API yerine bu kadar çok kullanılıyor olmasının teknik nedenleri bir yana en önemli nedeni GPL yerine LGPL ile lisanlanması. Bu lisans uyarınca bu kitaplığı, kitaplığın kendisinde değişiklik yapmadığınız ve kitaplığın kodunu yazılımla beraber dağıtmanız halinde kapalı kaynak kodlu projelerde de glibc kullanılmasının mümkün olması.

Hızlandırılmış tarih dersi sonrası günümüze gelelim. Yukarılarda bir yerde Android’in kalbinde Linux çekirdeği olduğunu söylemiştik. İşte bu çekirdeğin yönettiği donanıma kullanıcı seviyesinde çalışan yazılımların ulaşması için çekirdekle bu yazılımların arasında arayüz oluşturacak bir API gerekiyor. Elbette hemen aklınıza Google’ın da glibc kullandığı fikri gelecek olsa bile durun hemen heyecanlanmayın.

Google üç temel nedenle API sağlamak amacıyla glibc kullanmıyor. Bunun ilki özellikle glibc’nin çok fazla platform için geliştirilmesi nedeniyle gömülü sistemlere uymayan pek çok fonksiyonu bünyesinde barındırıyor olması. Sırf bu yüzden zaten glibc farklı isimler altında bu gömülü sistemler için forklanmış durumda.

İkinci neden üreticilere özelleştirdikleri Android sürümlerini ve cihazları belirli sürümlere, belirli operatörlere, belirli ayarlara kilitleyebilme özgürlüğünü sağlamak. Glibc her ne kadar LGPL olsa bile kitaplıkta yapılan değişikliklerin yayınlanması zorunlu olduğundan üreticilerin glibc kullanarak cihazları belirli ayarlara kilitlemesi mümkün olmayacak.

Üçüncü ve son nedense Google’ın bir ilke kararı. Google ileride yazılım geliştiricileri -burada kastettiğim uygulama geliştiricileri- çeşitli lisans ihlalleri iddialarından korumak amacıyla userspace seviyesinde hiç bir GPL -ve copyleft- lisanslı yazılım girmesine izin vermiyor. Bu yüzden glibc Android’de kullanılmıyor.

Bu adamlar ne yapıyor

Peki userspace alanında çalışan yazılımların çekirdekle çalışmasını sağlamak amacıyla Google’ın geliştirdiği çözüm ne diye merak ediyorsanız hemen söyleyelim. Çözümün adı -ve belki sorunun adı – Bionic!

Bionic temel olarak yazılımla çekirdek arasında sistem çağrılarını sağlamak amacıyla kullanılan arayüzü oluşturan bir kitaplık. Bu kitaplık yine bir özgür yazılım lisansı olan BSD lisansı ile yayınlanıyor. BSD lisansı bir copyleft lisansı olmadığından isteyenler bu kitaplığı kaynak kodunu vermeden ve ister açık isterse kapalı kaynak kodlu yazılımlarda kullanabiliyor.

Buraya kadar herhangi bir sorun yokken asıl dert burada başlıyor. Bionic, Google’ın sıfırdan başladığı bir proje değil aslında. Google ekibi Linux çekirdeğinin raw header dosyalarını alıyor ve bu dosyaları kendi tabirleri ile bir temizliğe tabi tutuyor. Bu “temizlik” neticesinde Google header dosyaları içinde yer alan ve konusu fikri mülkiyete dahil olabilecek -dolayısı ile GPL lisanslı – tüm içeriği  temizliyor ve geri kalan dosyaları bir kitaplık haline getirip Bionic ismiyle BSD lisansı ile yayınlıyor.

Bu temizleme betiği tüm header dosyalarını dolaşıp Android platformunda kullanılmayacak tüm tanımlama ve fonksiyonları, aynı zamanda header’lar içinde yer alan tüm yorumları, lisans bilgilerini siliyor. Bununla birlikte Android’in kullandığı tanımlamaları ve header dosyası içinde yer alan bazı makro ve fonksiyonlara ise dokunmuyor.

Lisans ihlali mi?

Bir fikri ürünün – örneğin yazılım- korunması ve eser sayılması için taşıması gereken temel özelliklerden birisi onu meydana getiren insanın özelliğini -kanun terimi ile hususiyetini- taşıması. Bu yüzden herhangi bir fikri çaba sarfedilmeden ortaya çıkan ürünler eğer onu meydana getirenin özelliğini taşımıyorsa eser sayılmazlar.

İşte bu noktada GPL ile lisanslanmış bir yazılımın, BSD ile yayınlanabileceğini ve bunun bir lisans ihlaline yol açmayacağını iki temel nedene dayandırılıyor. Tabi hemen bu söylenenlerin Google’ın resmi görüşü olmadığı sadece meraklı hukukçuların düşüncüleri olduğunu söyleyelim

Bunlardan ilki Google’ın temizlik betikleri ile hususiyet gösteren ve dolayısı ile eser olan bütün kodun, yorumların header dosyalarından çıkarması. Bu sayede geri kalan parçanın herhangi bir hususiyet göstermeyeceği ve bu yüzden lisanslanamayacağı düşüncesi.

İkincisi ise Amerika da konu ile ilgili daha önce verilmiş mahkeme kararları doğrultusunda oluşturulan bir kanı. 1992, 93 ve 2004 yıllarında farklı konularda verilen kararlar bu düşüncenin temelini oluşturuyor. En yeni karar olan 2004 kararında Lexmark yazıcılar için OEM kartuş üreten bir firma ürettiği kartuşlarda Lexmark’ın kartuş yetkilendirme kodunu -kartuşun orijinal olup olmadığını yazıcıya söyleyen 55 byte uzunluğunda kod- aynen kopyalamış ve kendi kartuşlarında kullanmıştı. Lexmark telif hakkı ihlali gerekçesi ile açtığı dava açmış ve dava kartuş üreticisi lehine sonuçlanmıştı.

Mahkeme temel olarak, üretilen bir kartuşun yazıcı ile çalışması için gerekli arayüzün oluşturulabilmesi için tek bir yol varsa bu yolun kullanılması için gerekli yazılımın kopyalanmasının adil kullanım olacağını ve telif ihlali yaratmayacağı kararını vermişti. Bu karar 1993 yılında ünlü -kime göre neye göre- Atari vs Nintendo davasında da benzer bir şekilde çıkmıştı.

Bu noktada Linux çekirdeği ile arayüz oluşturulması için mümkün olan tek yolun bu dosyaların kullanılması olduğu düşüncesiyle bu dosyaların GPL’e aykırı bir şekilde kopyalanması ve dağıtılmasının adil kullanım olacağı iddiası ortaya atılabilir.

İşte iş bu noktada benim diyecek yazılım uzmanı avukatı zorlayacak o güzel noktaya geliyor. Burada olası bir lisans ihlali söz konusu mu yoksa değil mi?

Aslında bionic’in her satırının tek tek incelenerek bu dosyalarda konusu fikri mülkiyete ait bazı kod parçalarının olup olmadığını incelemek gerekiyor. Özellikle bazı dosyalarda performansı arttırmak için header dosyalarında yer alan makroların korunması bana göre dosyalarda hala onu oluşturan kişinin hususiyetinin korunduğunun göstergesi.

Daha önemlisi ise tek tek dosya bazında incelemek yerine genel olarak yapılacak bir inceleme. Günümüzde artık sunduğunuz API’nın yazılımınızın ve hatta şirketinizin bir değeri haline geldiğini ve çoğu şirketin özel API’lerini korumak için önlem aldığını düşünecek olursak genel olarak tüm header dosyalarının oluşturduğu API’nın bir eser değeri taşımadığını söylemek çok doğru olmayacaktır.

GPL’in etrafından dolaşmak aslında herkes için son derece tehlikeli sonuçlar oluşturuyor. Bu sonuçlardan ilki isteyen birinin bionic kitaplığında yer alan tanımlamaları gerçekleyen bir yazılım geliştirmesi halinde Android’de yer alan çekirdeğin kapalı kaynak kodlu bir eşini oluşturması mümkün. Bu son derece teorik bir hikaye gibi görünse de pazarın büyüklüğünü düşünürsek neden olmasın dedirtecek bir durum.

İkinci tehlike elbette GPL ve onun kapsama alanı. GPL ile bu detayda oynamak onu workaround etmek için çeşitli yöntemler aramak bana kalırsa gelecekte özgür yazılım açısından gelecekte sıkıntılar doğurabilir.

Üçüncü tehlike ise elbette Android geliştiricileri için. Her ne kadar Google Bionic’i onlara korumak için üretmiş olsa bile bir gün Bionic’in GPL’i ihlal ettiği kanısına varılır ve doğal olarak Bionic GPL olmak durumunda kalırsa şu ana kadar Bionic’i kullanan tüm yazılımlar GPL olmak zorunda kalacak.

LKML listelerini takip edenler çekirdeğe yapılan sistem çağrılarının ve bu çağrıları yapan yazılımın GPL olması gerekmediğini bilirler fakat burada bu çağrıları yapan kitaplığın GPL olması durumunda bu kitaplığı kullanan yazılım GPL olmak durumunda kalacaktır.

Google şu anda belki yukarıda bahsettiğim belki başka nedenlere dayanarak “temiz” Boinc dosyalarının GPL olması gerekmediğine yönelik bir kumar oynamış durumda. Bu kumarın sonucu hepimiz için sürpriz sonuçlara yol açacak. Özellikle Oracle vs Google davasında mahkeme Oracle’ın Java API’sinin genel bir eser olarak korunabileceğine hükmederse benzer bir sonucu olası bir FSF vs Google davasında görebiliriz.

12 November 2011 @ 08:32 PM

Merhabalar,

Uzun bir süredir yoğunluktan+üşengeçlikten yazı yazmadım.

Geçenlerde bölüm hesabıma Drupal 7.9′u kurdum. Uğraştım, kurcaladım… Daha sonra silmek istedim. Gittim public_html dizinindeyken dedim ki:

1

rm -rf *

Bu bana güzel(!) bir hatayla döndü:

1

rm: cannot remove directory `sites/default/files/styles': Permission denied

Apache owner’lığı benden aldığı için herhangi bir işlem yapamıyordum:

1
2
3
4
5
6
7

~/public_html/sites/default/files > getfacl styles/
# file: styles
# owner: apache
# group: apache
user::rwx
group::rwx
other::r-x

Makinada root olmadığımdan chown, chmod, setfacl komutları tabi ki “Access denied.” olarak bana geri döndü. Yine apache ye sildirmem ya da sistem yöneticimize mail atmam gerekiyordu :)

Bu sorunu aşmak için şu yolu izledim:

PhpShell adında güzel bir proje var. Bu php scripti bize terminal komutlarını çalıştırmamıza yarayacak. public_html altında phpshell klasörünün içine dosyaları kopyalayıp web browserdan phpshell.php yi çağırdığımızda bize bash’i sunacak.

1
2
3
4
5

cd ~
wget http://downloads.sourceforge.net/project/phpshell/phpshell/2.2/phpshell-2.2.tar.gz
tar xvzf phpshell-2.2.tar.gz
mkdir public_html/phpshell
cp -R phpshell-2.2/* public_html/phpshell/

Şimdi kendimize bir kullanıcı yaratmamız lazım, güvenlik açığı oluşturmamak için default bir account koymamışlar. config.php dosyasını vim, emacs, nano vb. bir editörle açıp [users] satırının altına:

kullaniciadi = “sifre”

Şeklinde basitçe oluşturmanız yeterli. PhpShell aliases desteği var, ayrıca pwhash.php ile kendinize şifre generate ettirebilirsiniz (Şifrenizde : karakteri kullanmayın, ayrılmış karakter). Daha sonra web browserınızdan www.labadaluba.com/phpshell/phpshell.php adresine gittiğinizde az önce yazdığınız kullanıcı adı ve şifreyi kullanarak login olursunuz. Bundan sonrası size kalmış, ister setfacl ile izinleri değiştirin, isterseniz benim gibi “rm -rf” ile dizini uçurun :)

08 November 2011 @ 08:22 PM

Üç aylık bir aradan sonra bir kez daha aramızdan ayrılan arkadaşları ilan etmek için bir girdi yazıyorum. Geçtiğimiz dönemde Meltem Parmaksız UEKAE’de farklı bir projede çalışmak, Mete Alparslan Katırcıoğlu yurtdışında çalışmak, Onur Küçük özgür yazılım kariyerine Türkiye’de bir yeni girişimde devam etmek, Gökcen Eraslan da akademik kariyerine yoğunlaşmak için ekipten ayrıldılar. Hepsine Pardus projesine katkıları için teşekkür ediyor, gelecek çalışmalarında başarılar diliyorum.

TÜBİTAK UEKAE’nin mevcut personel politikası gereğince bu arkadaşların yerine ya da ekipteki diğer eksikleri gidermek için yeni alım yapamıyoruz (uzunca) bir süredir. Bu nedenle alışıldık “işe başlayanlar” bölümü yok bu kez…

Yine TÜBİTAK çapında yürütülmekte olan yeniden yapılanma çalışmaları kapsamında Pardus projesinde de kimi dış ve iç değişiklikler olacak önümüzdeki dönemde. Bu değişiklikler gerek görüldükçe, resmi kanallarla, TÜBİTAK tarafından kamuoyuna duyurulacak. Pardus kullanıcılarını etkileyecek takvim değişiklikleri vb. gelişmeler ortaya çıkarsa bunlar da e-posta listeleri aracılığıyla ilgililere iletilecek.

(Uzunca) Bir süre için Pravda Pardus’a son girdi olacak bu yazı…

02 November 2011 @ 08:48 PM

Veri Yapıları ve Algoritmalar (COMP231) dersinin bu haftaki projesinde sıralama algoritmalarının implementasyonu ve analizi yapılması istendi. Proje Quick sort ile beraber ders kitabı olarak kullandığımız Cormen’in Introduction to Algorithms kitabındaki Merge sort algoritmasının yazımını bize bırakmış ve Insertion sort ile beraber birtakım yardımcı fonksiyonları hazır olarak vermişti.

Güzel bir pazar günü başlangıcında quick sort’u yazıp diğer kısımlarını akşama bırakmış idim. Sanırım eğlence akşam vaktini bu işe ayırmamla başladı. Gece 10.30 – 3.30 arası Cormen’in Merge sort algoritmasını yazmakla,  toplamda 4 tane algoritmanın analizini yapıp anlamlı veri elde eden programcığı yazmakla ve gnuplot öğrenmekle geçti. Sonunda gnuplot ile sonucu elde ettim ancak twitter’da bahsettiğim üzere bir problem vardı. Gecenin o vaktinde artık ekrana bakacak halim kalmadığı ve proje teslimine 5 saat kaldığı için projenin o hali ile gönderip sabah labda bakmaya karar verdim.

Sabah problemi reb’e söylemem ile beraber durumun hocaların bulunduğu e-posta listesine atılması bir oldu :) Şimdi bulduğum sonucu ve olması gereken sonucu yan yana koyalım.

İlk analizde görüyoruz ki harika bir gariplikte O(n^2) çalışması gereken insertion sort O(n) çalışmakta. Normalde O(n . lgn) çalışması gereken merge sort neredeyse O(n^2) çalışıyor gibi görünüyor.

Tabi ki hata bu veriyi üreten kodda meydana geliyor. Sıralama algoritmalarının çalışmasında herhangi bir sıkıntı mevcut değil. Sakin kafa ile düşününce anlıyoruz ki durum tamamiyle mutation, yani bir dizinin (array) ortak kullanımından kaynaklanıyor. Alınan kahve oranı ve gecenin ilerleyen saatleri ile yazılan kod kalitesi arasında bir ilişki olabileceğini düşünürsek ilk veriyi üreten kodun kirli bir biçimde yazıldığına şaşırmamak gerek. Kod tek bir liste alıp o liste üzerinde tek tek sıralama algoritmalarını çalıştırıyor. Yani ilk sıralamadan sonra elimizde sıralı bir liste oluyor ve devamındaki 3 algoritma sıralı liste üzerinde sonuç veriyor. Durum böyle olunca, insertion sort çalışması gereken bir biçimde sıralı liste üzerinde O(n) zamanda çalışıyor. Merge sort sıralanmamış liste üzreinde ilk olarak çalıştırıldığı için onun dışındaki diğer algoritmalar da aynı şekilde sıralı listeler üzerinde sonuç veriyor.

Sabah veri üreten programığı düzgün bir biçimde yazdıktan sonra doğru olan yukarıdaki sonuçları elde ettim. Sağda görüldüğü üzere insertion sort O(n^2) zamanda çalışıyor ve diğer algoritmalar yok denecek kadar az bir sürede işlemi tamamlıyor. Soldaki grafikte ise kalan algoritmaların analizi mevcut. Görüldüğü gibi 25.000.000 elemanlı listeye kadar analizi mevcut ki bu kadar büyük bir rakamda insertion sort’u beklemek çok uzun süreceği için çıkarmak zorunda kaldım.

Yanlış veriyi üreten programcığı buradan görebilirsiniz. Farkedeceğiniz üzere getAnalysis metodu tek bir liste üzerinde işlem yapmakta. Düzgün ve temiz haline ise buradan ulaşılabilir. getAnalysis artık bir metod ve liste alarak, önce listeyi kopyalıyor, ardından da zamanı döndürüyor. Bu işlemi 4 algoritma için tekrarlayıp zamanlarını aldıktan sonra dosyaya yazdırıyorum.

Ne öğrendim? 

25 October 2011 @ 03:54 PM

Paylaşımlı kitaplıklar (shared libraries) linux dünyasının olmazsa olmazlarından bir kavram. Linux altında iş yapmış herkesin bir kere eli bulaştığını düşünüyorum. Web'de bununla ilgili kaynak çok. 1-2 gün önce IRC'de #pardus-gelistirici de bunu uzun uzadıya tartıştık hatta.Karmakarışık bir yapı vardı önümde (ldconfig, ld-linux.so, rpath, LD_PRELOAD, soname, linker, loader, etc..). Baktım olmuyor dün akşam araştırmaya koyuldum ve bulduğum her belgeyi okuyup bir resim ortaya çıkartmaya çalıştım. Burada yazılanlar bunların ve IRC'de not aldıklarımın birer yansıması. Merak etmeyin kimseyi ayrıntıya boğumayacağım, sadece gerekli olabilecek bilgileri sizlere sunacağım. Benim bir çok şeyi daha iyi anlamamı sağladı, umarım sizin de işinize yarar. Uzun bir yazı, haliyle teknik konular da içeriyor, öncesinden bir çay/kahve yapıp o şekilde okumanızı tavsiye ederim :) Başlayalım:

Paylaşımlı kitaplıklar nedir?

Paylaşımlı kitaplıklar adı üstünde bir çok uygulama tarafından kullanılacak şekilde tasarlanmıştır. Uygulama başlatıldığında bu paylaşımlı kitaplıklar yüklenip kullanılmaya başlanır. Bunun şüphesiz en güzel yanı, bir çok uygulamanın aynı kitaplığı paylaşabilmesi, bizlere esneklik sağlaması, az yer kaplaması, vs... Yani siz bir tane kitaplık yazıyorsunuz ve diğer tüm uygulamalar bundan faydalanabiliyor. Dezavantajı ise kararsızlığın çabuk bozulabilmesi. Bir uygulama libfoo.2.0.0 kitaplığın ihtiyaç duyuyorsa ve siz sisteminizde bunu kullanmaya karar verdiyseniz, o zaman eski sürümüne bağlı diğer tüm uygulamaları kırmış olursunuz. Çünkü diğer bazı uygulamalar libfoo.1.0.0 sürümüne ihtiyaç duyuyacak ve sistemde artık bunu bulamayacak.

Linux dağıtımları bunlara dikkat ederek sistemlerini güncel ve kararlı tutmaya çalışır. Örneğin "Python 2.7", "Xorg-Server 1.9.5", vs.. Sistem'de "Xorg-Server 1.10" sürümünü kullanmaya karar veriseniz buna bağlı tüm uygulamaları da tekrar gözden geçirerek güncellemeniz gerekecek. O yüzden dağıtımlar bu tarz işleri her yeni sürüm çıkışının başlarında yaparlar.

Burada gördüğünüz gibi sürüm numarası büyuk bir önem taşıyor. Linux altındaki bu sistem de tümüyle bu sürüm kavramını üzerine oturtulmuştur. Kitaplık isimleleri genel olarak "lib" öneki ile başlar. Örneğin libpng, libzlib, vs... Alt seviye C kitaplıklarında ise "lib" ön-eki bulunmaz. Bunlar genelikle /lib dizininde yer alır. Diğer genel kitaplıklar ise /usr/lib altına konulur (şimdilik böyle düşünelim, biraz sonra ldconfig ile daha ayrıntılı anlayacağım). Bu dizine şöyle bir göz attığımızda kitaplıkların birbirine benzeyen dosyalar olduğunu ve her birinin birbirine bağlı olduğunu görürsünüz. Aşağıda bunun bir örneğini görebilirsiniz (yazımda bu örneğe sık sık atıfta bulunacağım):

..
libagg.so -> libagg.so.2.0.4
libagg.so.2 -> libagg.so.2.0.4
libagg.so.2.0.4
libchoqok.so -> libchoqok.so.1
libchoqok.so.1 -> libchoqok.so.1.0.1
libchoqok.so.1.0.1
..

Peki bu numaralar nedir? Niye birbirine bağlı bu kadar dosya var? İlk bakışta kafa karışıklığına yol açsa da her birinin anlamı var.

Kitaplıkların adlandırılması

Yukarıda gördüğünüz kitaplıklar üç farklı türe ayırabiliriz. Bunlar şu şekilde:

• İlki "Real name" adını verdiklerimiz. Bunlar.so son-eki, sürüm numarası ve son olarak bir minör numarası(seviye inebilir) sahiptirler. Bizim örneğimizde bu "libagg.so.2.0.4" ve "libchoqok.so.1.0.1". Bunlar uygulama'nın çalıştırabilinir kodlarını taşır. Yani sisteminizde asıl işi yapanlar bunlardır. Bunları sistemden sildiğiniz veya değiştirdiğiniz an buna bağlı tüm uygulamalar kırılır ve çalışmamaya başlar.

• İkincisi "Soname" adını verdiklerimiz var. Bunlar .so son-eki, sürüm numarası(bu sürüm numarasına soversion da denilinir) sahiptirler. Örnek olarak "libagg.so.2" ve "libchoqok.so.1" . Soname'ler sistemdeki en kararlı sürüme bağlandığı için büyük bir önem taşır. Sistemdeki kararlılığı soversion tematiği ile sağlamaya çalışır. Soname diyebilmenin bir başka şartı ise "Real name"'lere sembolik bir bağ oluşturmaları. Yani yukarıda örneklerimize göre:

libagg.so.2 -> libagg.so.2.0.4
libchoqok.so.1 -> libchoqok.so.1.0.1

Soname'ler önemlidir çünkü sistemimiz her daim bunları görür. Yani bir uygulama çalıştığında yukarıdaki örnek için konuşursak, "libagg.so.2" kitaplığını yüklemeye çalışacaktır. Bu da bizim gerçek kitaplığımıza bağlı olacağından sorun oluşmayacaktır zaten. Bir uygulamanın hangi soname'lere ihtiyaç duyduğunu "ldd" komutu ile kolayca bakabiliriz. Mesela "choqok" uygulaması için bize şöyle bir çıktı verecektir:

# ldd /usr/bin/choqok | grep libchoqok
libchoqok.so.1 => /usr/lib/libchoqok.so.1 (0x00007f6252cff000)

Gördüğünüz gibi "choqok" uygulaması "libchoqok.so.1" soname'ine ihtiyaç duyuyor. Normal bir Linux dağıtımda binlerce kitaplık olabileceği için bu bağlama işlerini kolayca yapabilmemiz lazım. Tek tek elle yapmak yerine, ldconfig adındaki bir araç bunu bizim yerimize hallediyor. ldconfig kısaca sistem'deki "real-name" kitaplıklarını tarar ve gerekli "soname" bağlarını oluşturur. ldconfig sadece bununla yükümlü değil elbet. Kapsamlı ve önemli bir araç olduğu için birazdan buna tekrar değineceğim.

• Son olarak "Linker-name" olanlar var. Bunkar sadece .so son-ekini alırlar. Bizim örneğimizde bunlar "libagg.so" ve "libchoqok.so". Bunlar linker tarafından "link-time" zamanında kullanılınır. Yani bir uygulamaya derleyip, inşa etmeye çalıştığınız anlarda. Genel olarak soname'a bağ içerelirler. Ama bazıları doğrudan realname kitaplığına bir bağ içerir. Bizim örneğimizde:

libagg.so -> libagg.so.2.0.4
libchoqok.so -> libchoqok.so.1

Gördüğünüz gibi libagg.so realname dosyasına bir bağ oluşturuken, libchoqok.so soname kitaplığına bir bağ oluşturmuş. Bu bağları linker(ld uygulaması) kullandığı için genel olarak elle kendimiz yapmamız lazım. Burada şunu unutmayın, bu bağlantıları ldconfig yapmıyor, inşa sistemi tarafından (örneğin Autotools) ve ya kendiniz tarafından yapılıyor. Bir uygulamanın hangi kitaplığa bağlı olduğuna kısaca siz karar veriyorsunuz. Örneğin libagg.so.2.0.4 kitaplığını yeni bir sürümü çıktı, geliştirici doğrudan en soversion'u yükselti ve bunu libagg.so.2.0.5 yaptı. Şimdi siz geldiniz bunu sisteminize kurdunuz. Bir uygulamayı derlemeye başladınız, libagg.so'ya ihtiyaç duyuyor. Peki şimdi sorayım size, hangi sürüme linklenmesini istiyorsunuz? Evet tamamen size bağlı, eğer yeni özellikleri istiyorsanız, yeni sürüme bağ oluşturursunuz:

libagg.so -> libagg.so.2.0.5

Ama gördüğünüz gibi burada aslında minör bir sürüm değişikliği var. Bu yüzden çoğu zaman "linker-name"'ler real-name yerine soname'e bağ oluştururlar. Çünkü bu tarz küçük değişiklikler yüzünden inşa sırasında sorun çıkmaması gerekiyor. Verimli bir durum anlayacağınız, her seferinde bu bağları güncellemeniz gerekmeyecek.

ld-linux.so ile kitaplıkların yüklenmesi ve çalıştırılması

GNU/Linux sistemlerinde ld.so ve ld-linux.so adında iki tane "loader" vardır. Bunlar paylaşımlı kitaplıkların yönetimini sağlar. ld.so kitaplığı a.out çalıştırabilir dosyaların kitaplıklarını yönetirken, ld-linux.so ELF türündeki çalıştırabilir kitaplıkları yönetir. Günümüzde genel olarak tüm çalıştırabilinir dosyalar ELF türündedir. Bazen ld-linux.so ismi ld-linux-x86-64.so olarak da anılıyor. Isimler değişebilir ama genel olarak bu şekilde olurlar.

Elinizdeki çalıştırabilir dosyaya (binary) başla dediğinizde, ilk önce ld-linux.so devreye girer, tüm kitaplıkları tarar ve bulduklarını taramaya başlar. ldd komutu bildiğiniz gibi bir dosyanın ihtiyaç duyduğu paylaşımları kitaplıkları listeler. Aslında tek yaptığ şey ld-linux.so'ya haber vermek. Listemeyi "loader"ın kendisi yapar. Aşağıda tipik bir ldd çıktısını görebilirsiniz (libao.so.2.1.3 kitaplığı için):

# ldd /usr/lib/libao.so.2.1.3
linux-vdso.so.1 => (0x00007fffe93b2000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fcc248e1000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fcc246dd000)
libc.so.6 => /lib/libc.so.6 (0x00007fcc2436c000)
/lib/ld-linux-x86-64.so.2 (0x00007fcc24d30000)

Burada gördüğünüz gibi "/lib/ld-linux-x86-64.so.2" kitaplığı gözüküyor. Bu yukarıda anlattığım loaderin kendisidir. Buna ihtiyaç duyuyor. Ardından diğer ihtiyaç duyduğu kitaplıkları listelemeye başlar. Peki nasıl ve hangi sıralamaya göre listeliyor ? Yani sistemde o kadar kitaplık varken hangisini seçiyor ? Bunu da belirli ve önemli bir sıralaması var (ELF dosyaları için). Sıralama şu şekilde:

1. Çalıştırabilir dosyanın başlık kısmındaki DT_RPATH değişkenine göre (DT_RUNPATH aktif edilmediyse)
2. LD_LIBRARY_PATH çevre değişkenine göre. Bunu loader ile değiştirebilirsiniz (örneğin: /lib/ld-linux.so.2 --library-path $KİTAPLIK_DIZINI)
3. Çalıştırabilir dosyanın başlık kısmındaki DT_RUNPATH`değişkenine göre.
4. /etc/ld.so.cache önbellek dosyasına göre. Bu dosyayı ldconfig adındaki uygulama oluşturuyor.
5. /usr/lib ve /lib dizinlerine göre

Yukarıdaki maddelerin her biri dizinleri gösteren değişkenler ya da doğrudan dizinlerdir. Tüm bunların dışında bir de LD_PRELOAD değişkeni var. Bunu kullanırsanız yukarıdaki tüm maddeleri ezmiş olabilirsiniz, ama burada büyük bir dezavantaj ise LD_PRELOAD değişkenin sadece birer dosya ismi aldığıdır(absolute path). Yani dizin veremiyorsunuz. Bu yüzden çoğu zaman LD_LIBRARY_PATH kullanmak isteyeceksiniz.

RPATH değişkeninin dejavantajları ve zararları

Şimdi ldconfig'e gelmeden önce rpath mevzusuna bir el atalım. RPATH` istenmeyen eski bir teknolojidir. Linker'e (yani ld) "-Wl,-rpath, $(KİTAPLIK_DIZINI)" parametlerini ekleyerek açabilirsiniz. Rpath, yukarıdaki liste'de da görüldüğü gibi listenin en tepesinde ve doğrudan çalıştırabilir dosyanın içinde "hardcoded" olarak yer alıyor. Yani siz ne yaparsanız yapın, uygulama hep RPATH'deki dizine bakmaya çalışacak. Bunu değiştirmenin imkanı da yok (chrpath gibi uygulamalar dışında). Bu da bizim paylaşımlı kitaplıklarla anlattığımız her şeyin hiç bir işe yaramayacağını gösteriyor.

Pardus'ta RPATH mevzusunu ciddiye alıyoruz. Depo'da şöyle bir göz atarsanız bununla ilgili onlarca yama bulabilirsiniz. Bu yamalar genelikle -rpath değişkenini kaldırır ve gerekli değişiklik yapılır. RPATH'ı düzeltmenin bir başka yolu ise –enable-new-dtags paramtresini linkere eklemek. Yani şu şekilde: "-Wl,-rpath, $(KİTAPLIK_DIZINI), -enable-new-dtags". Bunu yaptığınız vakit, DT_RPATH dışında DT_RUNPATH değişkenini de aktif hale getiriyoruz. Loader yüklendiğinde DT_RUNPATH 'i görür görmez DT_RPATH değişkenini pasif hale getirir. Bu da bizim işimizi kolaylaştırıyor. Yukarıdaki sıralamaya bakarsanız, DT_RUNPATH değişkeni üçüncü sırada olduğunu görürsünüz. Yani artık LD_LIBRAY_PATH değişkenini gönül rahatlıyla kullanabiliriz.

ldconfig ile paylaşımlı kitaplıkların yönetimi

Tüm bunların dışında bir de ldconfig var. Şu ana kadar yazdıklarımda sıkça karşımıza çıktı. ldconfig komut satırında verilmiş parametreleri, /etc/ld.so.conf dosyası içeriğini ve güvendiği dizinleri tarayarak gerekli sembolik bağları ve /etc/ld.so.cache belleğini oluşturur.  Sırayla bunlarına üzerinden gidelim

• Parametre olarak. ldconfig'e doğrudan bakması gereken dizinleri parametre olarak verebilirsiniz. Örneğin:

ldconfig -n /home/pars/lib 

Bu komut sadece /home/pars/lib dizinine bakar. Yani güvenli dizinleri ve /etc/ld.so.conf hiçe sayar. Anı kurtarmak veya bir şey denemek için kullanabilirsiniz. Sistemi yeniden başlatırsanız eski haline geri döner

• /etc/ld.so.conf dosyası. Bu dosyanın içeriği her dizin bir satır ile ifade eder. Örneğin:

/usr/x11/lib
/opt/lib
..

Bunun dışında içeriği şu şekilde de olabilir: "include /etc/ld.so.conf.d/*.conf". Pardus'da mesela bu şekilde kullanıyoruz. Tüm dizinlerimiz /etc/ld.so.conf.d/ dizini içindeki dosyalar içinde saklı. Bu dizinin içeriği şu şekilde:

10-local.conf
20-java_jre.conf
20-xulrunner.conf
21-java_jdk.conf
..

Bunları açıp inceleyebilirsiniz.

• Güvenli dizinler. Yukarıdaki dosyalara incelediyseniz /lib ve /usr/lib dizinleri nerede diye kendinize sorabilirsiniz. Bu dizinler ldconfig olarak öntamlı kabul edilen güvenli dizinlerdir. O yüzden bunları eklemenize gerek yok.

ldconfig buradaki dizinlerden soname -> realname sembolik bağlarını oluşturur. Bu kitaplıkları bir önceki yazımda anlattım. Bunun dışında /etc/ld.so.cache adında bir önbellek. Bir çok uygulama açılıp/kapanacağı için hızlı bir mekanizma sunuyor. Yazımın başında da bahsettiğim gibi loader'imi (ld-linux.so) bu dosya'ya da bakıyor.

Bu önbellek dosyası her yeni kitaplık ile güncellemesi gerekiyor. Yani ldconfig'i tekrar çalıştırmanız gerekiyor. Pardus kullanıyorsanız bunları sizin için otomatik olarak yapıyoruz. Pardus'ta ldconfig "baselayout" paketinde yer alan bir çomar betiği ile her kurulan paketle birlikte çalıştırılır. Sizin hiç bir şey yapmanız gerek kalmıyor anlayacağınız :)

--

Paylaşımlı kitaplıklar ile ilgili çok kapsamlı bilgiler mevcut. Burada anlatıklarım ve yazdıklarım işin temelini oluşturuyor. Örneğin C ile yazdığınız bir uygulama'da bunları nasıl kullanacaksınız ? Bunu gibi sorular biraz da ileri seviye konuları olduğu için şimdilik burada bırakıyorum. Belgeyi yazarken yararlandığım döükmanlar aşağıda listelenmiştir (ingilizce).

Umarım yazdıklarım kitaplıklarla ilgili bilinmezlikleri gidermiştir. Sorularınız, eleştirileriniz veya düzeltilecek yerler varsa yorum kısmında belirtirseniz sevinirim :)

Kaynaklar:

1. http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
2. http://www.ibm.com/developerworks/library/l-shobj/
3. http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
4. http://cs.nyu.edu/~xiaojian/bookmark/linux/ld_so%20%20Dynamic-Link%20Library%20support.ht
5. http://blog.lxgcc.net/?p=15

22 October 2011 @ 05:24 AM

Pardus Gönüllüleri

Geçtiğimiz hafta, 6-9 Ekim 2011 tarihleri arasında, Tüyap Fuar ve Kongre Merkezi’nin ev sahipliği yaptığı, Avrasya’nın bir numaralı Bilişim, Teknoloji ve İletişim Platformu CeBIT Bilişim Eurasia‘da PARDUS destekçisi ve gönüllüsü olarak yer aldım. 17 ülkeden 1078 firma, 121.349 ziyaretçinin yer aldığı fuarda en çok ilgi çeken standlar arasında yer alıyordu PARDUS standı. İzlenimlerimden kısaca bahsetmek istiyorum.

Öncelikle bu sene diğer senelerin aksine katılımın ücretsiz olduğunu belirtmek isterim. Bu katılımcı sayısını ve katılımcıların statüsünü ne denli etkiledi bilmiyorum ancak Pardus standı her daim kalabalıktı. Stand’tan ayrılıp fuarı çok fazla gezemediğim için daha çok buradaki deneyimlerimi anlatacağım.

Oldukça keyifliydi gerçekten. İnsanlara Pardus’u anlatmak, tepkilerini görmek, çeşitli insanlarla diyalog kurmaya çalışmak gerçekten farklı bir deneyim oldu benim için. Daha önce hiç Pardus’u duymamış, hatta ne olduğu hakkında bir fikri olmayan insanlar da oluyordu, şu anda kullanmakta olup deneyimlerini, izlenimlerini hatta sorunlarını anlatmaya gelen de. Daha önce Pardus’u hiç duymamış, Milli İşletim Sistemimiz olduğunu, Türk mühendisler tarafından geliştirildiğini öğrendiklerinde heyecan duyan insanları görmek oldukça keyifli ve güzeldi. Bunların yanında yalnızca eleştirmeye, polemiğe girmeye gelen insanlar da vardı tabii. Biz ülkece neden böyleyiz anlamıyorum.Destek olmak, kendi yaptığımız şeylerle gurur duymak yerine hep bir muhalefet olma derdindeyiz. Bizim de iyi şeyler yapabileceğimize inanmak istemiyor bazıları. Çamur atmak, eleştirmek her zaman kolaydır. Olay elini o taşın altına koyabilmekte.

Devrim Arabaları filminde geçtiği gibi “Türkiye de hiç bir başarı cezasız kalmaz!”

Ancak bilişim dünyasının içinde olup da Pardus’u duymamış insanları görünce anladım ki bu işin daha fazla tanıtımı, reklamı yapılmalı, olayın ciddiyeti, güzelliği daha fazla anlaşılmalı. Çoğu kurumda dışa bağımlılığı önleyen, özgür, yenilikçi bir iş yapılıyor. Bunun değeri biraz daha görülüp anlaşılmalı. Bunu daha ileriye taşımak, daha iyi bir hâle getirmek bizim elimizde.

Öyle ya da böyle yorucu, bir o kadar da güzel hafta sonunun ardından bu işi de sorunsuz ve başarıyla bitirmenin verdiği keyifle oradan ayrılmak güzeldi. Pardus’u kullanın, destekleyin, anlatın. Neden mi? Özgürlük için, Güvenlik için, Yenilik için..

18 October 2011 @ 07:30 PM

Pardus projesinde çalışmaya 2006 yılında başladım, Bahadır Kandemir ile birlikte aynı gün işe girdik. Çalışmaya başladığımızda bir çoğunuzun yakından tanıyacağı isimler Barış Metin, Onur Küçük, İsmail Dönmez, A.Murat Eren, A.Erkan Tekman, Gürer Özen, Görkem Çetin, S.Çağlar Onur, Eray Özkural, Umut Pulat, Serdar Köylü, Mehmet D. Akın ve Koray Löker ekipte yer alıyordu. Şu anda iş yerinde sadece Koray Löker ve A.Erkan Tekman var bu ekipten tanıdığım.

Biz işe girdikten sonra bu ekipteki insanlar yavaş yavaş ayrıldı, yerlerine yenileri gelmeye başladı. Faik Uygur, Ekin Meroğlu, Pınar Yanardağ, Ali Erdinç Köroğlu, Gökçen Eraslan, Ozan Çağlayan, Eren Türkay, Fatih Aşıcı, Mete Alpaslan, Işıl Poyraz, Semen Cirit, Serbülent Ünsal, Ali Ulvi Tunç, Taner Taş, Gökhan Özkan… Sonra onlardan da bir çoğu gitti, geriye sadece Ekin Meroğlu, Ozan Çağlayan, Eren Türkay, Ali Ulvi Tunç, Semen Cirit ve askerden döndüğünde aramıza geri dönmeye karar verirse Fatih Aşıcı kaldı.

Ben askere gittim geldim, 2010 başında yeni ofiste işe başladım. İşe başladığımda aramıza yeni insanlar katılmıştı; Renan Çakırerk, H.İbrahim Güngör, Akın Ömeroğlu, Serdar Dalgıç, Mehmet Emre Atasever… İşe başladıktan sonra yeni gelenler de oldu; Yasemin Yiğit Kuru, Hakan Şimşek, Uğur Eke. Sonrasında ekip büyümeye devam etti; Metin Akdere, Fatih Arslan, Beyza Ermiş, Çağlar Kilimci, Gökhan Özbulak, Mehmet Özdemir, Meltem Parmaksız, Erdem Bayer ve Mete Bilgin aramıza katıldılar. Ve en son katılımla Nihan Katipoğlu, Bertan Gündoğdu, Kaan Özdinçer ve Pamir Talazan ekipteki yerlerini aldılar.

Ne çok insan geçmiş değil mi Pardus ofisinden? (Sayamadıklarım kusura bakmasın, öptüm kıps)

Neyse, konuya biraz geçmişten başlamış olsam da aslında son durumdan bahsetmek istiyordum. Geçmişi hatırladık fena olmadı ;)

En son sevgili dostum Gökçen Eraslan, akademik dünyanın altını üstüne getirecek genç bilim adamı olmak üzere aramızdan ayrıldı. Ondan önce 10 yıldan fazla zamandır tanıdığım ağabeyim (iki~üç yaş var aramızda ama adam ağabey gibi:)) Onur Küçük, özgür yazılıma başka alanlarda da katkı verebilmek üzere 2004′ten beri çalıştığı Pardus’tan ayrıldı. Daha öncesinde de yine çok sevgili dostum Bahadır Kandemir ve Mete Alpaslan Living in America şarkısını seslendirmek üzere eski ekipten Barış Metin, Gürer Özen ve S.Çağlar Onur‘un da çalıştığı Verivue‘da işe başladılar. Erdem Bayer askere gitti. Meltem Parmaksız Tübitak içerisinde başka bir projede çalışmaya başladı.

Artık ofiste karşı masamda Bahadır yerine Bertan oturuyor. Çözemediğim soruları sorup kafasını ütülemeye gittiğim Onur‘un yerinde Nihan, Gökçen‘in yerinde henüz kimse oturmuyor. Meltem için de durum aynı. Çağlar, Mete‘nin yerine geçmekle kalmayıp bilgisayarını bile sahiplenmiş :)

Hiçbir şey eskisi gibi değil, olmayacak da, olmaması gerekiyor zaten. Bunların hepsi yeni yeni başlangıçlar yapmak, tazelenmek, toparlanmak, ayağa kalkıp geleceğe tekrardan bakabilmek için ortaya çıkan fırsatlar aslında. İşte bu yüzden elimizdeki fırsatları değerlendirmek zorundayız, ne kadar zorlanırsak zorlanalım sonuna kadar mücadele etmeliyiz.

Ben özgür yazılıma inanan biriyim, özgür yazılım ile birlikte insanların daha çok şey keşfedebileceklerine, ulaşamadıkları yerlere ulaşabileceklerine inanıyorum. Ne güzeldir ki yukarıda adı geçen insanların hepsi de öyle ya da böyle özgür yazılıma katkı vermiş, verdikleri katkı sayesinde insanlara yol göstermeyi başarabilmiş insanlar. Hepsi harika insanlar, umarım çok mutlu ve çok başarılı olurlar.

Sözün özü, bu ekip Pardus’u geliştirmeye, özgür yazılıma katkı vermeye, daha çok insana özgür yazılımı sevdirmeye devam edecek. Bu ekip bunu daha önce yaptı yine yapacaktır!

ps. Başlık biraz yanlış anlaşılmış olabilir, ben henüz bir yere gitmiyorum fakat yeni bir başlangıç için bir yere gitmeye gerek yok onu biliyorum ;)

18 October 2011 @ 07:57 AM

Zeki Bildirici Linux gezegenindeki bir blog yazısında, Fatih projesinden bahsedip, bu projede özgür yazılım kullanılması için mücadele etmeye bir çağrı yapmış.

Bu konudaki diğer yazılarda da ıskalanan bazı önemli noktalar gördüm. Projenin olası dört katmanı üzerine kendi düşüncelerimi açıklamaya çalışacağım.

Donanım, bu işin en alt katmanı. Akıllı tahta ve tabletlerden bahsediliyor. Bu katmanda belli bir teknoloji seçimi yapmanın yada tek tip ürün kullanmanın aptalca olduğunu düşünüyorum. Çünkü bu aletler her gün gelişiyor ve giriş sistemleri (dokunmatik ekran, hareket algılama, ses tanıma, vb) ile görüntüleme sistemleri (lcd, e-ink, kıvrılabilir ekranlar, vb) sürekli devrimsel değişiklikler geçirdiği için tek bir modele yada aygıta çakılı kalıp güncelleşememek tehlikesi var.

Bu alanda üretimi yerli yapmanın bir faydası olacağına inanmıyorum. Sonuçta herkes gidip işlemciyi ve ekranı Samsung, vb den alacak. Çin kalkıp iPhone'u biz ürettik diye böbürlense kargalar bile güler, ama Türkiye'de araba montajı yapmayı bir başarı sanıyoruz. Bu çağda değerli olan şey üretim değil tasarım, onu da donanım alanında yapmak çok büyük kaynak ve zaman ve elimizde hiç olmayan bir know-how istiyor. Malesef devlet ar-ge kaynaklarını temel bilimlerden çekip, ürün üretimine yönelik ve aslında özel sektörün yürütmesi gereken alanlara aktarıyor. Fizik, kimya ve biyoloji gibi temel bilimlere yatırım yapılmayınca da mesela yeni bir ekran teknolojisi gibi bir şeyin yerli olarak ortaya çıkması imkansız.

En mantıklı yol, tek tip aygıt üzerinde standartlaşmayıp, belli özelliklere (işlem kapasitesi, ergonomi, sağlamlık, fiyat) uyan birden fazla tedarikçiyi kullanmak. Yerli üretici elbette güzel olur ama devlet enerjisini bunu bu katmanda değil de daha üst katmanlarda sağlamaya yönlendirmeli.

İşletim Sistemi, gene bu projenin önemsiz ve alt katmanlarından biri. Temel giriş çıkış işlevlerini, çoklu çalışma ve ağ iletişimi imkanlarını sağlayan herhangi bir sistem yeterli olur. Ancak tek bir üreticiye bağlı kalmamak ve en önemlisi farklı donanımlara kolayca aktarabilmek açısında mutlaka bir özgür yazılım seçilmeli.

Bu katmandaki en mantıklı seçim Linux. Özellikle gömülü sistemlerdeki yaygınlığı, kolayca özelleştirilebilmesi ve bilgi birikiminin tamamen özgür olması nedenleriyle. Teknik destek alınabilecek Tübitak gibi bir devlet kurumu da olduğu göz önüne alınırsa, Pardus projesi bir Linux dağıtımı olarak en doğru seçim gibi görünüyor.

Yazılım altyapısı işin en önemli noktası. Herhangi bir iPad benzeri aleti çocuğun eline verince iş bitmiyor. Mesela ders içeriği çocuğun elindeki alete nasıl yüklenecek, güncelleme ve düzeltmeler nasıl dağıtılacak, sınav ve ödevler, istatistiki bilgiler bu aletlerden toplanıp merkezi bir sistemde nasıl analiz edilecek, ders anlatımı sırasında aletin uygun içeriği göstermesi nasıl sağlanacak, ders ve yardımcı içerikler hocalar tarafından nasıl üretilecek, bu işlerde hangi araçlar ve formatlar kullanılacak. Bunlar küçük ölçekte bile kolay olmayan, MEB ölçeğinde ise çok zor problemler. Bir de mesela ses tanıma ve ses sentezi gibi teknolojilere Türkçe desteği verilmesi gibi büyük çaplı ve önemli işler var.

Varolan teknolojiler bu iş için elverişli değil. PDF bu aygıtların ekranlarına uygun bir format değil, Flash kapalı olması yanında yeni giriş sistemlerini desteklemiyor, öğrencilerin video dersleri izlemesini isterseniz, bu videoyu alette depolamanın ayrı problem, ağdan sunmanın ayrı problem olduğunu göreceksiniz.

İşte asıl katma değerin olduğu (çünkü dünyada kimsede böyle bir sistem yok), ve yerli imkanlarla başarabileceğimiz (çünkü yazılım için büyük mali kaynaklar ve üretim tesisleri değil, doğru vizyon ve yetenekli yazılımcılar gerekiyor yalnızca) alan burası.

Bunun yürütücüsü kim olur bilemiyorum. Devlet kurumlarında yazılım geliştirme konusunda bir birikim yok. Pardus'un sürekli kaybettiği ve yerlerine yenisini koymadığı deneyimli elemanları ve daha halen devam eden yönetim yanlışlıkları da işin bu tarafını başaramayacaklarını gösteriyor. Özel sektörden biri yaparsa devlete satamaz, yada şöyle diyelim, devlete satabilecek olan özel sektör bu işi doğru dürüst yapamayacağı gibi yapmak niyetinde de olmaz. İhaleyi zaten ucuza almış, ilk yapacakları iş kârı arttırmak için işi en ucuza yapmaya çalışmak. Malesef ar-ge ucuza getirmeye çalışarak yada şark kurnazlığı ile yapılabilecek bir iş değil.

İçerik kısmı ise MEB'in halledeceği bir iş. Burada benim katabileceğim tek fikir, klasik kitap içeriğinin bu işe uygun olmadığı. Hipermetin (HTML, vb) bile ideal çözüm değil. En güçlü içerik, mutlaka çokluortam içeren ve etkileşimli bir deney ortamı sunan bir sanal dünya olacaktır.

Bu konuda bazı üniversitelerin güzel girişimleri var. Mesela Sebastian Thrun ve Peter Norvig'in yapay zeka derslerini 24 saatte 80.000 kişi çalışmış. Derslerin anlatımları tabiki çok güzel ve ara sorular ve sınavlarla zenginleştirilmiş. Bu tür eğitim teknolojilerinin en büyük avantajı alanının en iyisi kişiler tarafından büyük emek harcanarak bir kere oluşturulacak derslerin az bir maliyetle ve coğrafi engelleri aşarak çok sayıda kişiye ulaştırılabilmesi.

16 October 2011 @ 10:30 PM

Previously on Cebit 

Benim anlatmak istediğim bir çok şeyi Camia Koordinatörümüz Nihan ve Gönüllü Koordinatörümüz. Onur  bloglarında gayet güzel anlatmışlar. Ben de tekrardan bu güzel etkinliği beraber geçirdiğim herkese teşekkür edeyim.
GSM firmaları sponsorluktan çekildiğinden beri gitgide sönükleşen fuarın en güzel standının Pardus'unki olduğunu rahatlıkla söyleyebilirim.  Bu yıl geçen seneye ek olarak standımızda akıllı tahta, Sigma RD ekibinin geliştirdiği Pardus üzerinden Kinect aracılığı ile hareketleri algılayan bir doğal arayüz, Pardus üzerinde çalışan bir telsiz sistemi ve oyun alanımız vardı. Bu duruma birde girişin ücretsiz hale gelmesi eklenince fuar boyunca standımız oldukça kalabalık ve ana-baba günü seviyeleri arasında bir yoğunluk yaşadı. Ancak bizde özellikle hafta sonu 20 kişinin üzerinde bir kadroyla orada olunca ziyaretçilere yetebildik. Hatta stand oldukça kalabalıkken bile yardım edecek insan bulamadığım oldu.
Aslında fuarın geneli hakkında arkadaşlarımdan pek farklı şeyler söyleyemeyeceğim için biraz değerlendirme yapayım ve ilginç olaylardan bahsedeyim.
Geçen sene CD'lerin erken bitmesinden sonra Nihan'ın ortaya koyduğu yeni DVD dağıtma politikası gayet başarılıydı ve bu sene DVD'lerimiz fuar sonuna yetebildi.
Standda sürekli yetkili birinin olması da çok güzel bir gelişmeydi. Böylece Pardus ile kurumsal boyutta ilgilenen hemen hemen hiç kimseyi geri çevirmedik.
Onun dışında daha çok basılı materyalimiz olsa sanki daha iyi olurdu özellikle geçen seneki kurulum belgesini içeren posterler çok iyiydi.
Kendi adıma konuşacak olursa geçen 1 senede Linux topluluğu içinde kazandığım tecrübe sayesinde insanların sorularını fazla zorlanmadım.
Sistem yönetimi ile ilgilenmediğim için sunucu sorularında biraz zorlandım. Orada genelde Caner imdadıma yetişti. Onun dışında ekran kartı 2011'de çalışmayan ve açtığı hata kaydına cevap alamadığını söyleyen beyfendiye yardımcı olamadığıma çok üzüldüm.
Tv kartım çalışır mı, Excel'deki x fonksyonu LibreOffice'de var mı gibi spesifik sorular karşısında yapacak pek fazla bir şeyim yoktu.


Fuar kapanırken muzaffer futbol takımı edasında çektirdiğimiz fotoğrafı da ekleyeyim.



Soldan sağa ayaktakiler: Ebubekir Akgül, Tuncer Çolak, Merve Karabulut, Nihan Katipoğlu, Filiz Günel, Nesrin Kalender, Sinem Oğuz, Uğurcan Ergun, Kaan Özdinçer, İsmail M. Gökbulut, Uğur Eke, Zeynep Dikici

Soldan sağa oturanlar: Ülgen Sarıkavak, Murat Savaş, Caner Başaran, M. Sami Gürpınar, Murat Açıkgöz, Pamir Talazan, Onur Güzel, Ekin Meroğlu

Fotoğrafta olmayan isimleri de aklımda kaldığı kadarıyla buradan ben yazayım Gökmen Göksel, Fatih Arslan, Serdar Dalgıç,Mete Bilgin,Akın Ömeroğlu, Eren Türkay, Koray Löker, Zeki Bildirici, Samedhan Karameşe,Umut Albayrak,Fırat Zencirci, Hüseyin Özkan

Hepinize tekrardan teşekkür ederim. İyi ki varsınız.

PS: Fuar boyunca yaşanan ilginç geyikleri ve epic failleri da ayrı bir yazıda toplamak istiyorum.

15 October 2011 @ 11:55 PM

Pardus camiasının iyi bildiği CeBIT Eurasia Bilişim Fuarı 2011 geride kaldı. Geçtiğimiz hafta 6-7-8-9 Ekim tarihlerinde biz de Pardus olarak TÜBİTAK standında yerimizi aldık, ziyaretçilerimizle buluştuk. Neler yaptığımızı yeni web sitemizden bugün yarın okuyabilirsiniz. Bugün bu yazının sebebi özel teşekkürler :) Onur kendi yazısında çok güzel toparlamış aslında. Ben de daha fazla gecikmemek adına tüm kurumsal engeller bir yana yazıyorum hemen :) Nasılsa genel fuar izlenimlerini konuşmaya devam ederiz.

Gelenler biliyor, dört gün boyunca öyle nadir anlarda sakinledi ki stant daha çok Koray’ın deyimiyle otobüste gibiydik :) Bu yoğunlukta ziyaretçilerle ilgilenen gönüllülerin olmadığını bir an düşündüm de… Yok vazgeçtim, kâbus gibi bir şey olurdu. İşte bu sebepten gönüllülerin koordinasyonuyla ilgilenen Onur’a ne kadar teşekkür etsem az.

Ben, Koray ve Uğur tüm süreçte ne iş gerekiyorsa onu yaptık. Ve tüm bu süreçte Akın ve Ekin deneyimlerini paylaştılar, takıldığımda yardım ettiler.
Devran stant tasarımı yapan firmayla iletişim kurdu, Zeynep stant görsellerimizi tasarladı. İbrahim oyunları seçti, yükledi hazır hale getirdi. Telsiz ve Radyo Amatörleri Cemiyeti (TRAC) Genel Başkanı Aziz Bey ve Eren, dört gün boyunca bizimle birlikte çalıştılar.

Şimdi hatırlayamadığım (ve muhtemelen daha uzun süre bir şey ifade etmeyecek) birtakım teknik ve detaylı sorularda hemen yönlendirdiğim arkadaşlarım, Mete, Semen, Serdar, Çağlar, Gökmen, Fatih, Bertan, Kaan ve Pamir sayesinde ziyaretçilerin özel teknik soruları birinci elden cevaplandı. Benim için destekleri çok önemliydi, tekrar teşekkür ediyorum.

Gülderen hanım yemeklerimizi ayarladı. Servislerimizi ayarlayan Murat bey, broşürlerimizi basan Ömer bey, stant malzemelerini taşıyan Ayhan bey, bizi  dört gün boyunca bizi taa Gebze’den Beylikdüzü’ne kadar taşıyan Mehmet ve Salih beyin sayesinde işler hep yolunda gitti.

Nerdworking Erdem (Dilbaz), SigmaRD Eray (Berger) ve Cem (Keskin) kendi rutinleri öyle olsa da :) bu kez de bizim için uykusuz kalıp çalıştılar. Dört gün boyunca “Amaan xbox’ı koymuşlar işte, bi numarası yok ki bunun” gibi yorumlar karşısında hevesleri kırılmadan el becerilerimizi geliştirmeye yardım ettiler :)

Son olarak Merve, Tuncer, Sami, Filiz, Nesrin, Zeynep, Ülgen, Uğurcan, Murat, diğer Murat :), Sinem, Caner, Ebubekir, Emrah, Fırat, Göktuğ, Hüseyin, İsmail, Samedhan ve Umut’a bir kez daha teşekkür ediyorum. Kimi uzak şehirlerden geldi, kimi okulu astı, kimi hasta yatağından geldi, kimi daha yeni Pardus’la tanışmasına rağmen hiç yabancılık çekmedi, kimi akıllı tahtaya kimi de oyun sehpasına yapıştı ayrılmadı. Hepsi ayrı ayrı renk kattı, güzel işler yaptı. Şimdi değerlendirme zamanı herkesden yorumlarını almaya çalışıyorum, daha güzel etkinlerde görüşmek üzere.

Emeği geçen herkese çok teşekkür ediyoruz.

Soldan sağa ayaktakiler: Ebubekir Akgül, Tuncer Çolak, Merve Karabulut, Nihan Katipoğlu, Filiz Günel, Nesrin Kalender, Sinem Oğuz, Uğurcan Ergun, Kaan Özdinçer, İsmail M. Gökbulut, Uğur Eke, Zeynep Dikici

Soldan sağa oturanlar: Ülgen Sarıkavak, Murat Savaş, Caner Başaran, M. Sami Gürpınar, Murat Açıkgöz, Pamir Talazan, Onur Güzel, Ekin Meroğlu

11 October 2011 @ 01:15 PM