Birçok konuda bu tip tartışmalar yaşanır, bazen sadece fanatiklik bile bir tarafın seçilmesinde etken olabilir (doğru olmayabilir ama olur). Ben bunun dışında biraz gerçeklerden bahsetmek istiyorum:

• Özellik Kümesi
  • Qt sağladıkları ile birlikte tam bir geliştirme kütüphanesi, sadece grafik arabirim için değil en alt seviyede ihtiyaçlar için bile bir destek sunuyor. Veritabanı, Ağ, Web, XML … uzayıp giden kocaman bir özellik kümesini sunuyor. Öyle ki sadece Qt kullanarak koskoca bir masaüstü ortamı yazmak mümkün. Tam olarak neler içerdiğine [1] adresinden bakılabilir.
  • GTK+ ise Qt’ye göre çok daha az sayılabilecek bir özellik listesine sahip, fakat bu noktada GTK+’ın geliştirilmesindeki asıl sebebin arabirimler olduğu unutulmamalı. Arabirim dışında kalan işler için gerekli özellikler GLib altında geliştiriliyor (GTK+, Glib üzerinde), Qt’nin sunduğu kadar geniş bir yelpazeye sahip olmasa da yeterince uzun bir özellik kümesi var. Daha detaylı bir liste API dokümanlarından [2] incelenebilir.
  • Qt C++ ‘a ek olarak kolayca anlaşılabilecek sinyal slot mekanizmasını beraberinde getiriyor, GTK+ ise C üzerinde nesneye dayalı bir yaklaşım sergilemeye çalışırken anlaşılması zor bir hale geliyor.
• Görünüm
  • Qt Native QT uygulamaları, QGtkStyle[3] ile birlikte GTK+ temalarını (simge temaları dahil) kullanabilir hale geliyor, bunun dışında Qt Windows ve Mac Os X üzerinde de doğal görünüm sağlayabilen ortak tek kütüphane. QGtkStyle Qt tarafından sağlanıyor.
  • GTK+ Sadece kendi tema stillerini destekliyor, GTK-Qt-Engine [4] ile (GTK dışında geliştirilen gönüllü bir çalışma) bütün Qt temalarının desteklenmesi söz konusu olamıyor. Windows ve Mac Os X için herhangi bir desteği yok, kendi temaları ile çalışmaya devam ediyor. Ayrıca tema noktasında iş sadece görsellik ile bitmiyor, butonların sıralaması, layout düzeni gibi işler de temaya bağımlı olarak değişebiliyor (Qt’de İptal en sağ altta, GTK+’da Tamam en sağ altta gibi) QGtkStyle bu farklılıkları gözetebiliyor, GTK-Qt-Engine’in böyle bir yeteneği yok.
  • Ayrıca tema noktasında iş sadece görsellik ile bitmiyor, butonların sıralaması, layout düzeni gibi işler de temaya bağımlı olarak değişebiliyor (Qt’de İptal en sağ altta, GTK+’da Tamam en sağ altta gibi) QGtkStyle bu farklılıkları gözetebiliyor, GTK-Qt-Engine’in böyle bir yeteneği yok.
• Altyapı
  • Qt C++ ile geliştirilmiş ve C++ ile tam uyumlu bir API sunuyor. Nesneye Dayalı bir dilin bütün nimetlerinden faydalanıyorlar (bütün objeler QObject nesnesinden, bütün grafik arabirim nesneleri QObject nesnesinden türemiş QWidget nesnesinden türüyor, …)
  • GTK+ Qt’nin aksine C ile yazılmış ve kendine has bir API yapısına sahip. Fakat C++ için yazılmış bir wrapper ile (GTKmm) Qt’nin sahip olduğuna benzer bir hiyerarşi düzenine sahip. GTK+ nesneye dayalı bir yapı için, GObject nesnesinden miras alarak türüyor.
• Belgelendirme
  • Qt eksiksiz bir API belgesi ve bunu yanında süreçleri profesyonelce yazılmış bir bilişim kitabı tadında anlatan nasıl yapılır belgelerine sahip. Bu belgeler Qt tarafından sağlanıyor ve Qt paketleri ile birlikte erişilebilen Asisstant adlı uygulama ile ya da web üzerinden sunuluyor. Aynı zamanda Qt uygulamaları için doxygen formatında yazılmış açıklama metinlerinen QHelpEngine ile yardım belgesi üretmek mümkün hale geliyor.
  • GTK+ ‘da Qt’de olduğu gibi detaylı bir belgelendirme arşivine sahip değil, API belgeleri GTK tarafından çevrim içi sunuluyor olsa da, çevrim dışı belgelere 3.parti yazılımlar ile erişebiliyorsunuz.
• Tasarım Araçları
  • Qt Designer adından bir arabirim tasarımcısı ile birlikte geliyor, bu tasarımcı aynı zamanda Qt Creator uygulaması içine gömülü bir şekilde çalışarak tam bir geliştirme ortamı sunuyor. Designer XML tabanlı bir tasarım dosyası üretiyor ve bu dosya hazır araçlar sayesinde desteklenen diller için hazırlanmış kodlar haline getiriliyor. Ayrıca designer mevcut Qt nesneleri dışında dışarıdan geliştirmiş olduğunuz nesnelerin de arabirimi üzerinden kullanılmasına olanak sağlıyor.
  • GTK+ Glade ile birlikte arabirim tasarımı işini hallediyor, Glade GtkBuilder formatında Qt’dekine benzer bir şekilde desteklenen dillere çevirilebilecek bir tasarım dosyası üretiyor, bu dosyalar yine benzer araçlar ile desteklenen diller için üretiliyor.
• Performans
  • Bu konuda net bir sonuç ortaya koymak pek mümkün olmuyor, bu süreci alt kümelerine; çizim, bellek yönetimi, yüklenme süresi, çözülme süresi vs. şeklinde bölerek değerlendirmek gerek. Zira Qt yapılan iş ile ilgili bir çok bileşeni kendi sağlıyor olsa da GTK+ ile dışarıdan bir çok bileşeni kullanmak gerekiyor. Bu noktada performans değerlendirmesini net bir biçimde yapmak çok zor bir hale geliyor.
  • Genel kanı GTK+’ın Qt’ye göre daha hafif olduğu olsa da Qt’nin özellikle 4.4 sürümünden sonra bellek yönetimi ile ilgili yapmış olduğu yenilikler ile bu durumun geçerliliğini yitirdiği gözleniyor.
  • Daha önce yapılmış polygon çizimleri ile ilgili bir performans testini [5] adresinde bulabilirsiniz.
• Çeviriler
  • Qt kendi çeviri yönetim sistemine sahip fakat Gettext kütüphaneleri ile birlikte de kullanılabiliyor. Bütün Qt nesneleri Unicode destekliyor ve soldan-sağa <> sağdan-sola diller arası geçiş için bütün arabirim otomatik olarak yön değiştirebiliyor.
  • GTK+ herhangi bir çeviri yönetim sistemine sahip değil fakat Gettext kullanılarak çevirilebilir arabirimler tasarlamak mümkün.
• Test
  • Qt Arabirim ya da arabirimden bağımsız süreçlerin birim testlerini yapabilmek için bir test kütüphanesi sunuyor (QTestLib)
  • GTK+ için böyle bir özellik mevcut değil
• Programlama Dilleri
  • Qt C++ ile geliştiriliyor ve doğal hali ile C++ destekliyor. Bunun yanı sıra Qt için hemen hemen bütün dillerde kullanılmak üzere bağlayıcılar (binding) geliştirilmiş. Ayrıca Qt ECMA script (JavaScript) destekliyor. Ayrıca kendine has QML adında hızlıca uygulama geliştirebileceğiniz bir platform daha sunuyor.
  • GTK+ C desteği ile geliyor fakat Qt’de olduğu birçok bağlayıcı GTK+ için de mevcut. Bağlayıcılar konusunda Qt’den hemen hemen bir eksiği olmamasına rağmen, GTK+ ile JavaScript şimdilerde mümkün gözükmüyor.
• Çokluortam
  • Qt çokluortam işlerini Phonon ile hallediyor (Qt’nin içerisinden geliyor) birçok arkaucu (backend) destekliyor; mplayer, vlc, gstreamer, xine. Phonon arka uçlar için ortak kulanılacak bir katman, arka uçlar sisteme göre değişiyor ve bu arka uçlar Qt tarafından değil, çalıştığı sistem tarafından sağlanıyor. Ayrıca çokluortam dosyaları üzerinde (efekt ekleme gibi) işlem yapmaya da olanak sağlıyor.
  • GTK+ Gstreamer kullanıyor ve arka uç olarak sadece Gstreamer’ı destekliyor. Arka uç Gstreamer’ın kendisi GTK+ tarafından sağlanıyor.
• İletişim Desteği
  • Qt Dbus ve IPC destekliyor
  • GTK+ sadece Dbus destekliyor
• Lisans
  • Belki de bu tartışmanın eskiden kullanılan en önemli vurgusu Qt’nin lisans durumydu, fakat Nokia satın aldıktan sonra Qt’nin lisansını LGPL olarak değiştirdi, bu noktada GTK+ ile Qt arasında özgürlük açısından herhangi bir fark bulunmuyor fakat Qt için ücreti karşılığında profesyonel destek alabiliyorken GTK+ için hala böyle bir destek alamıyorsunuz.
  • Ayrıca işin Python tarafında Qt’nin LGPL olmasının ardından pyGtk düşüşe geçmiş.

Sonuç

Açıkçası bu listeyi çok daha fazla uzatmak mümkün. Bir yerde durmak gerekiyordu :).

Benim kişisel görüşüm Qt’den yana; size tam bir çözüm sunuyor ve bu tam çözümü sunarken her süreç birbirine benzer işliyor, Qt içeren bir C++ kodunu çok hızlı bir şekilde Qt içeren bir Python kodu haline getirebiliyorsunuz. Nesneye dayalı geliştirilmiş olmasının verdiği esneklik ve uyum, üstüne bir de çok detaylı belgelendirme, rahat okunabilir kodlar eklenince Qt açık ara lider benim için fakat ikisi ile de mükemmel uygulamalar geliştirmek mümkün.

Bu konu ile ilgili yaptığım araştırma sırasında karşılaştığım/kaynak aldığım bazı yazılara [6] [7] [8] [9] adreslerinden ulaşılabilir.

Not: GTK+ ile ilgili yazdıklarımda eksiklerim/yanlışlarım olabilir, kesinlikle bu konuda yorum bırakmaktan çekinmeyin.

[1] http://doc.qt.nokia.com/4.7/classes.html
[2] http://library.gnome.org/devel/references#api-platform
[3] http://labs.qt.nokia.com/2008/05/13/introducing-qgtkstyle/
[4] http://kde-look.org/content/show.php?content=9714
[5] http://zrusin.blogspot.com/2006/10/benchmarks.html
[6] http://techfreaks4u.com/blog/?p=953
[7] http://ldn.linuxfoundation.org/article/application-development-framework-choices-gtk-vs-qt
[8] http://www.jbkempf.com/blog/post/2007/02/10/Qt4-Interface
[9] http://www.caddd.org/2010/03/qt-vs-gtk.html

Pardus’u diğer dağıtımlardan farklı kılan en önemli özelliklerinden biri de PiSi , Pardus’un Paket Yönetim Sistemi.

Bir çok sunumda da savunduğumuz bir argüman var; PiSi sadece paket yönetiminde değil, paketleri geliştirmek için sunduğu kolay kullanım ile de diğer paket yönetim sistemlerinden sıyrılıyor.

Paketlerin sisteme kurulması, güncellenmesi, kaldırılması ya da daha derinlerde bağımlılıklarının çözülmesi, paketlerin sıkıştırılması gibi işleri yaparken ne kadar hızlı ve verimli olduğu şüphe götürmez bir gerçek. Paket geliştiricileri için ise Python ve XML sayesinde paket geliştirme sürecinde diğer paket yönetim sistemlerine göre büyük avantajlara sahip.

Python’un tartışılacak pek bir yanı yok, hali hazırda kendisine rakip olabilecek pek bir ürün de yok zaten (ruby’nin vs. nin başımızın üstünde yeri var ama Python daha bi can yani :)) Fakat paketlerin önemli bilgilerini içeren dosyaların hepsi XML formatında. Bu dosyaların XML olmasının birçok avantajı var; herhangi başka bir formata dönüştürmek, hali hazırda bir çok kütüphane kullanarak bu dosyaları işlemek, dosyanın denetimlerini gerçekleştirebilmek ya da dosyanın tasarımında bir değişiklik yapmak oldukça basit. Gelgelelim XML’in çok önemli bir dezavantajı var; insanlar için yazması ve okuması zor bir format XML. Günümüzde henüz paketleri geliştiren mükemmel makinelerimiz olmadığına göre, insanlar önem sıralamasında en üstte :)

Bu problemi çözmek için XML düzenleyecek araçlar yazmak üzere tarihi birçok projemiz mevcut. Fakat ne bu projeler bir türlü mutlu bir sona ulaşabildiler, ne de çoğu “geek” dediğimiz sınıfa giren paketçilerimiz bu araçları kullanmaya sıcak bakmadı. Paket bakıcılığı ile pek uğraşmıyor olsam da bende bu araçlar yerine Vim kullanmayı tercih ediyorum. Bu kadar paket varken ve PiSi ile paket geliştiren bir çok paketçi varken, bu konuda bir değişiklik yapmakta pek kolay değil. Ayrıca değiştirmeye karar verdiğinizde XML’in sağladıklarını sağlayacak birşey bulmak ve PiSi’nin bu formattan anlayacak hale gelmesini sağlamak (PiSi ile birlikte buildfarm ve arkadaşları gibi büyük bir topluluk da bu değişimden nasibini almalı) pek kolay bir iş değil.

Konuyu bir-iki haftadır birazda geyik unsuru olarak aramızda konuşurken (daha sonra geliştirici listesinde de konuşuldu bir kuple), kullanabileceğimiz alternatif veri taşıyıcı formatları araştırdık; JSON, YAML ve hatta şahsen ben kendim Google’ın kendi işlerinde kullanmak üzere tasarladığı protobuf projesini dahi inceledim. Fakat aralarında en mantıklısı ve XML’e en yakın özellikleri sağladığı gibi asıl problemimize (kolay okunan ve yazılan bir format istiyoruz !) de tam çözüm olacak tek alternatif YAML gibi gözüküyor (evrenin herhangi bir yerinde daha iyisi varsa yorum olarak ekleyin). PiSi’nin proje lideri Fatih ve Pardus 2009 Sürüm Yöneticisi Onur ile birlikte konuyu konuşurken çok daha eğlenceli dosya formatları geliştirdik lâkin Dünya henüz buna hazır değil :)

Mevcut bir pspec.xml ile yeni ortaya çıkan pspec.yaml arasındaki okunulabilirlik ve yazılabilirlik ise sanırım gayet net;

YAML gibi bir formatı seçmekle iş bitmiyor ne yazık ki; PiSi’nin YAML anlayacak hale getirilmesi, bu işin (deyim yerindeyse) en “pis” yeri. Bu işi şu anki iş yükümüzle ve düşündüğümüz şekli ile (PiSi’nin XML ile ilgili kısımlarını tamamen YAML’a geçirmek) yapmak neredeyse imkansız olduğu için bu konu geyik olarak kapandı diye düşünüyordum ki; bir bardak mojito imdadıma yetişti;

XML’in avantajı kolay olarak başka formatlara çevirilebilmesi ve XML için kullanılabilecek en hızlı Python kütüphanelerinden Piksemel ve YAML için gerekli PyYaml kullanarak, pspec.yaml gibi bir dosyayı PiSi’ye işlemesi için vermeden önce PiSi’nin anlayabileceği XML formatına çevirmek gayet kolay olacaktı oysa ki :)

pisi-yaml‘ın kendisi burada, denemek için örnek bir paket ise burada mevcut. Tabi bunlardan önce PyYaml paketini kurmanız gerek. Gerekli dosyaları çektikten sonra kde-odf-thumbnailer paketini pspec.yaml‘dan derletmek için kde-odf-thumbnailer dizininde;

# ./pisi-yaml.py build pspec.yaml

Derleme bittikten sonra pspec.yaml dosyasının XML’e çevirilmiş haline .pspec.xml dosyasından göz atabilirsiniz.

Pardus 2011′de YAML ile yazılmış paketlerimiz olur belki kim bilir ?

Evet, süpriz!

Geçen yıl PyGuguk adında bir guguklu saat yaptığımı hatırlıyorum. Tabi amatör bir uygulamaydı. Beklerken ana döngüyü bölemediği için donup kalıyordu ve kapatmak imkansızdı. Kontrolcu projesi ile uğraşırken öğrendiğim QThread ve Guguk için gereken QTimer ile artık guguklu saatimiz donmuyor, güzelce ötüyor.

Ses çalmak için Phonon kütüphanesini kullanıyorum. Fakat nedense Pardus’daki PyQt’de Phonon desteği yok. O yüzden Pardus için eğer Phonon kütüphanesini bulamazsa PyGame’e geçebilecek.

Guguk projesi ne yapıyor, her saat başı saat kadar ötüyor ve bir pencere çıkarıp size ‘Guguk!’ diyip saati söylüyor. Ayrıca guguklama işlemini durdurup susup oturmasını sağlayabilirsiniz.  Başlattığınızda siyah G harfi kırmızı oluyor ve çalışmaya başladığını haber veriyor.

Guguk projesini şuradan bulabilirsiniz.

Ve diğer süpriz:

Artık yazılarımın aynısı İngilizce olarak da bulabilrsiniz. Tamamen kendim çevirmeye çalıştım. Kelime kelime olmasa da anlamlarının aynı olduğundan emin olabilirsiniz.

Dil bölümünden dil değişikliği yapabilirsiniz.

Örnek1: Simple Example

a = 2print a,7,'eve'

Örnek2: Factorial

def myFactorial(n):    if(n<1):        print 'end of the computation'        return 1    return n * myFactorial(n-1)

print myFactorial(5)

Örnek3: Double Factorial

#Seval Unver 2009-10-08def myDoubleFactorial(n):    if(n <= 0):        print 'end of the computation'        return 1

    if(n % 2 == 1):        if(n <= 1):            print 'end of the computation'            return 1        return n * myDoubleFactorial(n-2)

    if(n % 2 == 0):        if(n < 1):            print 'end of the computation'            return 2        return n * myDoubleFactorial(n-2)

    return 0

print myDoubleFactorial(5)

Örnek4: Split

#Seval Unver 2009-10-08def mysplit(word, split):    list = []    part = ''    for x in word:            if not (x == split):                part += x            else:                list += [part]                part=''

    list += [part]                return list        

print mysplit('eb334mlpjiefwxuhbnlaxz7xknxnjn','x')

Örnek5: Chritsmas Tree

#Seval Unver 2009-10-08def xtree(star, length):    var = ''    for row_number in range(1,length):        for y in range (1,length-row_number+1):            var +=" "        for z in range (1, 2*row_number):            var +=star        print var        var = ''

xtree('*',4) 

***

Bu yıl KDE ve Gnome vakfının birçok sponsorun da desteği ile birlikte düzenlediği Desktop Summit ’09 için biraz önce Kanarya Adaları‘na geldik Gökçen ile birlikte. 03-11 Temmuz arasında olacak, Akademy ve GUADEC katılımcılarının bir arada yer alacağı etkinliğin son günleri ise İspanyolca sunumlar ile öncelikli Kanarya Adaları sakinleri ve İspanyol ziyaretçilere adanmış olacak.

KDE 4 ile bu seviyede bütünleşmiş başka bir Linux dağıtımının olmadığını düşünürsek, Pardus’un bu etkinliğe katılıyor olması gayet heyecan verici ;)

Pardus bu sene de kabul edilen projeler arasında :) Yeni heyecanlar, yeni insanlar bizleri bekliyor; 2005 yılından beri 100 ülkeden 2500 öğrenci bu öğrencilere hocalık yapan 2500 mentor (sorumlu) kod aşkına Google tarafından destekleniyor ve özgür yazılım dünyasına hatırı sayılır katkılar sağlıyor. Bu büyük çalışmanın içinde yer alıyor olmakta bütün Pardus ekibi için ayrı bir mutluluk :)

İlgilenebileceğiniz projelerin bir listesi burada, GSOC 2009 resmi sitesi burası ve burada da kabul edilen projelerin bir listesi yer alıyor.

Malum Pardus 2009 ile ilgili çalışmalarımız hızla sürüyor, mevcut araçların KDE 4 ve Teknolojileri ile uyumlu bir şekilde çalışması için ilk adımı Servis Yöneticisi için atmıştım, sıra masaüstünde en çok kullandığımız araçlardan biri olan Ağ Yöneticisi’ne geldi; bakalım bizleri neler bekliyor:

Ekran görüntüsüne tıklayarak eğlenceli ve teknoloji kokan bir kaydı izleyebilirsiniz ;) Ayrıca burada da Ağ Yöneticisi Veri Motoru ile ilgili bir kayıt mevcut ;)

(Henüz geliştirilme aşamasında olduğunu unutmayın)

Amerika kıtasındaki KDE geliştiricilerinin daha rahat katılabilmesi için KDE Vakfı Akademy etkinliği ile birlikte ikinci bir etkinlik daha yapmaya karar verdi, her 6 ayda bir; önce Akademy(Avrupa’da) sonrasında ise Camp KDE(Amerika’da) etkinliği gerçekleştirilecek. “KDE 4.0 Sürüm Etkinliği” adı ile ilk kez geçen sene, “Camp KDE” adı ile de ikinci kez bu yıl gerçekleşen etkinliğe Gökçen ile birlikte katıldık (hala buradayız :))..

Bu yılki etkinlik bir hafta sürüyor ve Jamaika‘da gerçekleştiriliyor. Buradaki takvimden de görebileceğiniz gibi ilk iki gün seminerler ardından planlanmamış (BoF) seminerler ve KDE geliştirme günleri yapılacak. Bende Marcus D. Hanwell(Gentoo) ile birlikte Pazar günü (bu arada doğum günümdü Pazar :)) “KDE ve Dağıtımlar” başlıklı bir sunum yaptım (pdf) , Marcus öncelikle Gentoo’da KDE paketlerini nasıl yaptıklarını, ne tip problemlerle karşılaştıklarını ve bunlarla ilgili buldukları çözümleri anlattı. Ardından bende Pardus için geliştirdiğimiz araçları ve 2009 sürümü için neler planladığımızı anlattım. Güzel geçti, 2009′da kullanılmak üzere geliştirdiğim Servis Yöneticisi ve Plasmoid’ini pek bi beğendiler, bizde mutlu olduk tabi :)

Bu arada 2009 ile ilgili aklınızda birşeyler oluşması adına şu videoyu izlemenizi tavsiye edeyim ;)

Bir süredir sevgili Doruk ısrarla Yalı ile kurulum yaparken ortaya çıkabilecek olası CD okuma problemleri vesilesi ile kurulumun yarıda kesilmesinden dert yanmakta, belirli aralıklarla kulağımı çınlatmakta idi. En bir eski yazılımların dahi desteklediği bu basit özellik adına bir şeyler yapılması gerektiğine dair son yazdıkları [#] sevgili Faik‘i pek bir hislendirmiş olacak ki, bu konuyu basit bir halde nasıl çözebileceğini düşünmeye başladı.

Yapmış olduğumuz “Pair programming” seansının ardından işi Yalı’da çözdük :)

Kendi görüşümü yine de eklemeden geçemeyeceğim; CD okuma problemlerinde tekrar deneme yapmanın ne kadar işe yarayacağından hala şüpheliyim ve fakat belki bir gün birinin işine yarar bu özellik belki kimbilir..

Efendim malumunuz Türkiye’deki en süper özgür yazılım projesi olan Pardus için çalışmaktayız ;) Tabi proje özgür olunca daha bi mutlu oluyor insan :)

Peki bu özgür yazılım nasıl bir şeydir ki bu kadar insan bundan bahsediyor ? Gelelim naçizane örneğimize;

Pardus’un popüler bir uygulaması olan ve ilk kez Suse için geliştirilen Sysinfo için (Pardus kullananlar bilir, diğerleri de araştırsın) birkaç değişiklik yaptık; çeşitli düzenlemeler, fixler vb. Sysinfo’nun ilk geliştiricisinin tasarladığı disk bölümlerini gösterme kısmı hoşumuza gitmedi. Biraz css, biraz c++ (evet sysinfo c++ ile yazılmış html üreten bir uygulama :) ) güzel bir hale getirdik. Sürüm sonrasında kde-apps.org’taki sysinfo’nun suse dışındaki diğer dağıtımlara göre paketlenmesi fırtınasına dayanarak Pardus’taki değişiklikleri göstermek adına bir tane de Pardus Sysinfo girdisi yarattım. Bir ya da iki gün geçmedi ki bizim yaptığımız değişiklikler diğer dağıtımlar için olan Sysinfo paketlerine de girivermiş :) Çok ama çok basit bir örnek olsa da paylaşmak adına özgür yazılım böle bişi ;)

Not: Tabi hala özgür yazılım projelerinde veritabanı parolalarının nasıl saklandığını bilemiyoruz (!)

Not2: Üsttekinden daha önemli; yeni dönem stajyerlerimiz de geldiler arı gibi çalışıyorlar ;)