Herhangi bir kısıtlamaya, zorlamaya bağlı olmaksızın düşünme veya davranma, herhangi bir şarta bağlı olmama durumu.

Çok sevdiğim ama verdikleri tepkilere anlam veremediğim, söylediklerini ve ima ettiklerini bir türlü anlayamadığım birkaç Pardus Geliştiricisi, bundan böyle projenin içinde olmayacaklarını açıkladılar. Onların arkasından bir kaç kişi daha gitti. Bunun yanında birçok dostumda gidenlerin haklı olduğunu “onlar haklı” pankartları ile desteklediler.

Üzüldüm, hem de çok üzüldüm. İki gündür, bir türlü kendimi toparlayamadım. Yazılanlardan sonra, geliştiricilerin ayrılmasından çok yazılanlara üzüldüm.

UEKAE ‘de çalışan geliştiriciler ile dışarıdan gönüllü destek veren geliştiriciler arasında ortaya çıkan/çıkartılan bu durumun temelinde; -bana kalırsa- sürekli birlikte olan bir ekibin sahip olduğu yoğun iletişimin, sürekli ayrı olan bir ekiple birleştirilememesi yatıyor. Buna bir çözüm bulunabilir mi, bende bilmiyorum.

~ * ~

Yazdığımız bütün kodlar, paket bilgi dosyaları, betikler vb. her şey halka açık, yani biz Özgür Yazılım üretiyoruz. Hem de Türkiye’de hiçbir zaman olmadığı kadar. Ve bunu – emsalleri ile karşılaştırdığınızda – az sayıda insan gücü ile yapıyoruz.

Pardus’un bir Özgür Yazılım olmasının büyük artıları da var tabi;

Evet, Gönüllü çalışanlarımız var \\o/ Yukarıdaki grafikte 2006-2009 yılları arasında uludag deposuna yapılan gönderilerin oranları yer alıyor. Görüldüğü üzere üretilen Teknoloji’nin önemli bir kısmını UEKAE ‘de çalışan geliştiriciler üretiyor. Bu teknolojileri üretebilmek için gerekli paketlerin hazırlanmasında da %76′ya %24 gibi benzer bir oran, pardus deposunda bulunuyor. (Bunları biz daha çok çalışıyoruz demek için yazmadım, sadece durumu anlatabilmek için yazdım. Zira bizim daha çok çalışmamız tabi ki doğru olanı.)

~ * ~

Pardus 2008 ve sonrasında yapılacak işleri yazıp mevcut durumumuzu takip edelim diye ve daha “şeffaf” olabilelim diye, bir “Proje Yönetim” aracı arayışına girmiş idik. O dönemlerde yapılan tartışmalardan bir sonuç çıkmamıştı (ki gelistirici listesinde yapılan tartışmalardan bir sonuç çıkması “mucize“). Bizde yine o dönemlerde, tam olarak nerede gördüğümüzü hatırlayamadığım bir yerden esinlenerek, bir yapılacak işler dosyası hazırladık. Belirli bir düzene sahip bu dosya üzerine yapılacak işleri ve işin durumunu giriyorduk vs. Tabii ki 2011 sürecinde, artık bu ilkel yöntemin de işe yaramamaya başlaması ile birlikte, “Proje Yönetim” aracı arayışları yeniden alevlendi. Özgür yazılım projelerinin en büyük sorunu, herkesin her daim konuşması fakat iş bir proje için çalışmak olduğunda sessizce beklemesidir. Herkes konuşur ama bazıları çalışır. Ve biz o bazılarının yaptığı çalışmalara muhtacız. Yine bir çok insan konuştu, bazıları iş yaptı ve Jira adında bir yazılım kullanmaya karar verdik. Yaptığımız araştırmaların sonucunda, Özgür Yazılımlar için kullanılması ücretsiz fakat özgür olmayan bir lisansa sahip olan Jira ‘da karar kıldık. Bu listedeki diğer projeler gibi. (Aralarında Özgür Yazılımların da bulunduğu kabarık bir liste).

Bu kararı verirken bir yanlış yaptık; gönüllü geliştiricilerin de kullanacağı bir yazılım için kendi kendimize karar verdik. Kararı kendi kendimize vermiş olmamızın yanında, bir de Neden Özgür bir alternatifini seçmediğimiz için, geliştiricilerimiz haklı veya haksız olarak şikayetlerini dile getirdiler. Hatamızın farkına varıp bir çözüm üretebilmek adına, ısrarla savunulan, Özgür lisansa sahip Redmine ‘ın gereksinimlerimizi karşılayacak kıvama getirilebilmesi için bir ortam hazırlamaya ve elimizden geldiğince bu konuda destek olmaya, bu süreç işlerken de Jira ile devam etmeye karar verdik.

Bu kararımızı açıklayınca ardı arkası kesilmeyen, bazıları hakaret seviyesinde birçok ithamda bulunarak bazı geliştiricilerimiz projeyi bırakacaklarını açıkladılar.

~ * ~

Hala üzgünüm ve şaşkınlık içerisindeyim ve hala anlayamıyorum.

Özgür Yazılımın bir güzelliği de istediğiniz zaman bırakıp gidebilme özgürlüğü.

Keşke böyle olmasaydı ama herkesin yolu açık olsun..

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 ?

Peki Pardus geliştiricileri genelde ne zaman geliştiriyorlar Pardus’u ? Normal şartlar altında; yani Tübitak çalışanlarını işçi olarak ele alırsak ve bu iş için Tübitak tarafından ayrılan mesai zamanlarına bakarsak; Pazartesi-Cuma günleri arasında saat 08:00′dan 17:00′a kadar olan süre ortaya çıkıyor. Pardus sadece bu süre zarfında geliştiriliyor olsaydı şimdi nerede olurdu ?

Çok soru sordum açıkçası biraz da “bilimsel“* gerçeklere bakalım;

Yukarıdaki grafikte 2006-2009 yılları arasında uludag deposuna yapılmış tüm gönderilerin (commit) gün içerisinde gönderim sıklıkları ifade ediliyor. Grafiğe göre özellikle mesai saatlerinde gerçek bir yükseliş var fakat önemli nokta hemen hemen her günün her saatinde Pardus ofisinden birilerinin çalıştığını gösteriyor. Mesai saatleri ile diğer saatlerin oranına bakarsak;

Sanırım dediklerim daha iyi anlaşılıyor :) Aynı incelemeyi Pardus deposu için yaptığımızda olayın çok daha güzel bir yanı ortaya çıkıyor;

Evet, mevcut paketlerin çoğunu mesai saatleri dışında, yani çalışanların kendilerine ait olan saatlerde yapmışız. Çıkardığım grafiklerden daha bir çok ilginç sonuçta çıktı tabi;

• Uludag ve Pardus deposuna en çok 2009 yılında gönderi yapmışız.
• Katkıcı deposuna en çok gönderi ise 2007 yılında yapılmış.
• 2006 ve 2007′de Pardus deposunu neredeyse sadece mesai saatleri dışında kullanmışız
• Her yıl git gide mesai saatlerindeki çalışma performansımız gözle görülür bir şekilde artmış
• Katkıcı deposu 2009 yılında diğer gün ve saatlerden çok farklı olarak en çok Çarşamba günleri saat 22 ‘de kullanılmış
• Uludag deposuna yapılan gönderilerin %82.24′ünü Tübitak çalışanları, %17.76′sını gönüllü çalışanlar yapmış
• Pardus deposuna yapılan gönderilerin %76.53′ünü Tübitak çalışanları, %23.47′sini gönüllü çalışanlar yapmış
• Katkıcı deposuna yapılan gönderilerin %62.84′ünü gönüllü çalışanlar, %37.16′sını Tübitak çalışanları yapmış
• Tüm depolarda ortak olarak en çok gönderiler 16 sularında mesai bitiminden hemen önce yapılmış
• Tüm depolarda ortak olarak en az gönderi 6 ile 7 sularında yapılmış (doğal olarak)
• Tübitak çalışanlarının en verimli olduğu saatler mesai içerisinde 14,15 ve 16 saatleri

Tüm bu veriler ile ilgili ayrıntılı grafikler [1] [2] [3] adreslerinde. Sayfalarda alttaki açılır kutulardan değişik depo/yıllara göre grafik ürettirebilirsiniz. (Kullandığım Svg çizim kütüphanesinde bazı problemler olabiliyor; sayfayı yenilemeniz yeterli)

* İşin bilimsel kısmı bu verilerin hepsini “svnlog” çıktısından aldım, kullanılabilecek hale getirmek için bir betik yazdım ve grafik kütüphanesinin anlayabileceği şekle çevirdim.

Siz hareket ettikçe sizin hareketinizden enerji alan ve yapıldığı teknolojiye bağlı olarak ya içerisindeki pili şarj eden ya da içindeki zemberek sayesinde mekanik olarak kurma işlemini gerçekleştirerek çalışmaya devam eden saatler. İngilizcesi “Automatic Watches” olunca Türkçesi biraz anlam karmaşasına yol açıyor olsa da başka mantıklı bir çeviri gelmedi aklıma..

Mekanik olanlar ortalama 1-2 gün boyunca durdukları yerde çalışmaya devam edebilirler. Pil şarj eden modeller ise genelde 1-2 gün sonrası uyku konumuna geçerek mekanik aksamı çalıştırmak yerine sadece saatin bilgisini dijital olarak tutarlar ve herhangi bir hareket ile şarj edilmelerini takiben mekanik aksamı gerçek zamana göre güncellerler.

Eski işlerimi toparlarken, okunmamış maillerimi okurken fark ettim ki Türkiye’deki otomatik özgür yazılım saatini harekete geçiren ve onu sürekli olarak şarj eden bir ekip ile çalışıyorum (Zorunlu hizmetin ardından bugün işte ilk günüm..) Sadece bu ofiste çalışan insanlardan bahsetmiyorum; hata giren, yorum yapan, saati çok hızlı şarj edeyim derken hızını alamayan ama her yönüyle bir şekilde bir sonraki adım için enerji üreten insanlardan bahsediyorum.

Özgürlükİçin‘in hazırladığı PodCast‘i dinledim biraz önce; resmen duygulandım yahu -arada Pardus Piyango talihlileri de açıklandı – :) Sonrasında Beyin‘de gezindim bir süre; gerçekten ele alınabilecek o kadar güzel yeni fikir var ki..

Sevgili Necdet Yücel‘e ve 64bit ekibindeki tüm arkadaşlara da 64bit Pardus sürümü için gösterdikleri müthiş çaba içinde ayrıca büyük bir teşekkür etmek istiyorum, zira özgür yazılımlarda yapılacak işler için konuşmak çok kolaydır fakat bir şeyler yapmak, işleri sonuca bağlamak her zaman sıkıntılı olur.

Bakalım ilerleyen günlerde zembereği gerebilmek için neler yapacağız..

Bakış açılarımız değişiyor, alışkanlıklarımız değişiyor, teknoloji bazen ayak uyduruyor bazen bize yön veriyor.

3 sene öncesine kadar dokunmatik cihazlar yanlış tasarımlarının kurbanı kalemlerle birlikte pek bir kullanışsızdılar ama teknolojiktiler (!). Sonra birileri dokunmatik bir cihazın gerçekten dokunulabilir bir şey olmasını akıl etti ve gerçekleştirdi. iPhone mobil dünyayı sağdan sola geçirdi. Sadece o incecik, dokunulabilir, kompakt donanımı ile değil, üzerinde çalıştığı müthiş donanımın hakkını veren yazılımları ile de çok büyük bir değişime sebep oldu.Mobil dünyanın donanım üreticileri iPhone‘a bakarak donanım üretmeye başladılar. Yazılım üreticileri mobil MacOsX ‘i temel aldılar. Büyük abiler mobil yazılım pazarına girmeye karar verdi vs. vs.

Mobil pazarın en önemli oyuncusu Nokia bile Apple‘ın mükemmel bir şekilde gerçeğe dönüştürdüğü bu yaklaşımı yeni yeni keşfetmeye başladı.. Binlerce modele sahip olmasına rağmen hiçbir Nokia modeli iPhone’un yakaladığı başarıyı yakalayamadı.. Hatta birkaç yüz tanesi bile tek başına iPhone ile başa çıkamadılar..

Teknoloji durmuyor ya yerinde hani değişiyor, yeniliyor ya kendini.. E-book (elektronik kitap) denilen, başta pasif monochrome ekranları, elektronik mürekkebi ile geldi. Önce gerçek kağıttan kitapların en büyük oyuncusu Amazon el attı e-book işine.. Kindle’ı çıkarttı kısmen başarılı oldu.. Ekran okuma için gerçekten çok başarılıydı, müzik dinleyebiliyordunuz ve internete girebiliyordunuz siyah-beyaz.

Apple ?

Durmadı tabi, tablet bir bilgisayar çıkaracağı söylentileri dolaşmaya başladı.. Bir sürü tasarımcı olası iTablet tasarımlarını ortaya attılar (isim bile çelişkili idi iTablet, iSlate ..). Artık Apple’ın tasarım yaklaşımını anlamış olacaklar ki (sadece basit) ortaya atılan olası tasarımların hemen hemen hepsi dün Steve Jobs‘ın biz Dünyalılara duyurduğu iPad ile hemen hemen aynıydı.

Yine yaptılar. Steve Jobs efsanevi tanıtımı sırasında iPad’in yerini şu şekilde tarif etti; “herkesin telefonu ve dizüstü bilgisayarı var, biz bunların yanına üçüncü bir teknoloji yerleştirmeyi hedefledik ve sanırım başarılı olduk“.

Steve Jobs işe geri döndükten sonra ilk olarak büyük yanlışı düzeltti Intel‘e geçti. Masaüstü ve Dizüstünde çok değerli olan bu adımı yenilenmiş gri-siyah tasarımlı iMac‘ler izledi. iPod‘un başarısını ve gelişimini söylemeye gerek yok herhalde :) Arada o müthiş tasarımcılarının elinden MacBook Air çıktı.. iPhone ile dokunulabilen efsaneyi yarattıktan sonra yine yeni bir efsane ile aramızda. FSF‘nin dediği gibi iBad olabilir özgürlük için; ama teknolojinin bu kadar gelişmiş olması heyecan verici.. Hep Apple yapıyor olsa da ben mutlu oluyorum :)

Görüşmek üzere…

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 ;)

Asıl sürüme ne kaldı ki :)

Yenileri de geldi:

3-4 gün önce geldi yeni bilgisayarım, Pardus 2009 test deposundan devşirme bir sistem kurdum, SD Kart dışında herşey kurulumun ardından çalıştı, herhangi bir iş yapmama gerek kalmadı :)

Günlük olarak kullandığım diğer yazılımları da kurduktan ve bir müddet kullandıktan sonra Yalı testleri için bir sanal makine kurmam gerekti; VirtualBox’ı derledim depodan, test isolarımı bağladım ve sistemi açtım… Kurulum süresince dikkatimi çeken yavaşlığı o sırada arka tarafta derlenme sürecindeki paketlere bağladım, fakat iş gittikçe tatsızlaşmaya başlıyordu… Sonra ofistekilerle soruna bakarken, Bahadır VirtualBox’ın sağ alt köşesindeki VT (Virtualization) simgesinin pasif olduğunu fark etti …

İşlemci tarafından desteklenen bu özelliğin BIOS’tan Sony tarafından kapatıldığını ve açılması için herhangi etik bir yol olmadığını ve bu konuda geçerli bir sebeplerinin de olmadığını öğrendiğimde bir titreme oldu bende :) Tabi bunu kabullenmek ve güzelim işlemcinin güzelim özelliğinden mahrum kalmak ayıp olurdu :)

Google’da bu konuda bir şeyler aradığınızda benim gibi dert yanan bir sürü insana rastlayabilirsiniz. Sağolsunlar kendi aralarında tartışıp Sony’ye bile şikayet mektupları yazmalarına rağmen Sony tarafından herhangi bir olumlu tepki alamamışlar. Fakat bazı insan evlatları BIOS’un bunu değiştirmek için herhangi bir arabirimi olmamasına aldırmadan, BIOS’un mevcut ayar dosyasını dump ederek gerekli değişiklikleri yapıp geri yükleme yöntemini kullanmış ve başarılı olmuşlar :)

Değişiklik yaptıkları modellerin arasında benim TZ398U yoktu haliyle :) biraz araştırdıktan sonra hangi anahtar değerini değiştireceğimi buldum ve artık VT desteği ile çok daha hızlı bir şekilde sanal makine kullanabiliyorum :)

Adımları kısaca açıklamak gerekirse;

1. DOS için bu adresten FreeDos’un 8Mb’lık minik isosunu indirip bir CD’ye yazın,
2. BIOS dump için gerekli program symcmos’u buradan indirin,
3. CD ile boot ettikten sonra “symcmos -v2 -LDUMPDOSYASI.TXT” ile BIOS ayarlarınızın bir kopyasını alın,
4. Sonra bu dosyada modelinize göre uygun anahtarı bulup 0000 olan değerini 0001 yapın *,
5. Kaydettiğiniz dump dosyasını yine aynı aracı kullanarak “symcmos -v2 -UDUMPDOSYASI.TXT” komutu ile BIOS’a geri yazın, bu kadar :)

* Ayrıntılı bir anahtar tablosu bu adreste bulunuyor, genelde TZ serileri için 0363 doğru anahtar değeri.

Katılımcıların temel Python/Qt programlama bilgisine sahip olması, mümkünse KDE 4 ile tanışmış olması ve GNU/Linux kullanıyor olması bizim için yeterli ;) Atölye’nin de diğer tüm şenlik etkinlikleri gibi ücretsiz olduğunu fakat kişi sayısının da sınırlı olduğunu belirteyim.