kuşağım tüm gençler gibi aptal ve cömertti, elimizdeki her şeyi veriyor, karşılığında hiçbir şey beklemiyorduk. Şimdi bizden geriye hiçbir şey kalmadı… Latin Amerika toprağında yatıyor cesetlerimiz*,

Öncelikle #hadron kanalından _paco_‘ya senelerdir bize  sağladığı her türlü destek(slogan gibi) için,

Gürkan Gür‘e yaptığı tüm paketler, sayısız hata çözümleri, belgeler ve fikirleri için,

Erdem Artan’a lpms’e yolladığı yama, paketler, hata çözümleri için,

Ceyhan Molla‘ya yeni logoyu çizdiği için,

Arch Linux geliştiricileri ve topluluğuna hazırladıkları sade paketler, init sistemi ve diğer irili ufaklı kod parçaları için,

Gentoo Linux‘a emeği geçenlere hazırladıkları harika dağıtım Hadron’a esin kaynağı olduğu için,

Linux From Scratch geliştiricilerine hazırladıkları eşsiz kaynak için,

Teşekkür ederim.

Hadron 1.0′ı aşağıdaki bağlantıdan indirebilirsiniz, okumanız için Gürkan pek çok belge de yazdı.

İndirme Adresi:

http://hadronproject.org/get-hadron/

Belgeler:

http://hadronproject.org/wiki/index.php/Main_Page_en

Bu arada, sürümü geçtiğimiz aylarda hayatını kaybeden Dennis Ritchie‘ye ithaf ettik. Kendi çapımızda saygı duruşu yapalım dedik.

Neyse, afiyetle…

Optimus, dediğim gibi, iyi bir teknoloji aslında ama Nvidia’nın Windows dışında bir platforma destek vermemesi nedeniyle bizler için ciddi bir problem olarak ortada duruyor. Bu teknolojiyi Windows üzerinde çalıştığı gibi GNU/Linux üzerinde çalıştıracak araçlar yok; zira Xorg biraz yetersiz kalıyor ve Nvidia destek vermiyor ama bazı hacky çözümler var.

Bu arada Nvidia Xorg’u ve Waylandı desteklemek gibi bir planı olmadığını açıklamış.

Bumblebee/Ironhide denen bir araç var. Hiç kullanmadım ama garip, kötü bir program olduğu söyleniyor. Fazla incelemedim… Aklınızda bulunsun.

Benim yaptığım şey, grafik donanımına çok fazla ihtiyacım olmadığından, nVidia çipi kapatmak oldu. acpi_call denen bir çekirdek modülü ile bu işi kolayca yapabiliyorum.

Bu arada lspci çıktısının ilgili kısmı şöyle:

01:00.0 VGA compatible controller: nVidia Corporation Device 0df5 (rev ff)

Bahsettiğim çekirdek modülü ise şurada ikamet ediyor:

https://github.com/mkottman/acpi_call

Derlemeniz gerekiyor, derlemek için de çekirdek kodlarına sahip olmanız gerek. En azından Gentoo‘da ve Hadron‘da işler öyle yürüyor. Diğer dağıtımlarda kernel-headers denen paketleri kurmanız gerekebilir. Araştırın…

Bu arada acpi_call dağıtımınızın deposunda da olabilir. Gentoo’da var mesela.

Eğer elle derliyorsanız şöyle bir yol izlemeniz gerekecek:

1- Kodu çekin:

$ git clone git://github.com/mkottman/acpi_call.git

2- Kod dizinine geçin:

$ cd acpi_call

3- Derleyin:

$ make

4- Çekirdek modülünü uygun bir yere kopyalayın. Şöyle olabilir:

/lib/modules/3.1.4-hadron/misc/acpi_call.ko

# cp acpi_call.ko /lib/modules/3.1.4-hadron/misc/acpi_call.ko

Evet, çekirdek modülünüz acpi_call.ko

Bu kopyalama işlemini yapmadan da modülü çalıştırabilirsiniz. Şöyle ki:

# insmod ./acpi_call.ko

Eğer kullandığınız çekirdeğin modül dizinine attıysanız ki yapmanız gereken de budur, şu komutu çalıştırmanız gerekiyor:

# depmod -a

-a yerine -A da kullanabilirsiniz sanırım. Eğer bu komutu çalıştırmazsanız modprobe komutu ile modülü yükleyemezsiniz.

5- Modülü yükleyin:

# modprobe acpi_call

dmesg çıktısında şu sonucu gördüyseniz başardınız demektir:

# dmesg | tail -f

[15337.338344] acpi_call: Module loaded successfully

Dikkat ettiyseniz GitHub‘dan çektiğiniz kodun içinde test_off.sh diye bir betik var. Bu betiği çalıştırarak bazı ACPI çağrılarını deneyebilirsiniz. Bu konularda detaylı bilgi modülün README dosyasında var.

Yukarıda bahsettiğim kartı kapatmak için şu komutu kullanıyorum:

# echo '\_SB.PCI0.PEG0.PEGP._OFF' > /proc/acpi/call

Çalıştırdıktan sonra dmesg | tail -f komutunun çıktısı şöyle oldu:

[15739.540423] acpi_call: Calling \_SB.PCI0.PEG0.PEGP._OFF

[15739.540648] acpi_call: Call successful: 0×0

İşe yaradı gördüğünüz gibi. Zaten fanın susmasından da işe yaradığını anlayabilirsiniz.

Açmak içinse şu komutu kullanıyorum:

# echo '\_SB.PCI0.PEG0.PEGP._ON' > /proc/acpi/call

Kapattıktan sonra /proc/acpi/call dosyasına gidip baktığımda içinde 0×0 yazdığını görüyorum. Kartı açınca da 0×1 yazıyor olmalı.

Bumblebee denen yazılımı kullanarak Nvidia kartı anlık olarak kullanabiliyorsunuz bildiğim kadarıyla. Ama ben hiç denemedim.

Bu konularla ilgili olarak şu kaynakları inceleyebilirsiniz:

http://hybrid-graphics-linux.tuxfamily.org/index.php?title=ACPI_calls

http://linux-hybrid-graphics.blogspot.com/

http://en.gentoo-wiki.com/wiki/X.Org/nVidia_Optimus

Son verdiğim bağlantıdaki bilgileri kullarak orta vadede kendi programımı yazarım gibi geliyor ama şimdilik böyle iyiyim!

Bu arada çekirdek güncellemesi yaparsanız acpi_call‘ı yeniden derlemeniz gerekebilir. En azından onu yeni çekirdeğinizin modül dizinine almanız gerekir. Modülün hangi sürüm için geçerli olduğunu şu komutla anlayabilirsiniz:

# modinfo acpi_call.ko

filename:       acpi_call.ko
license:        GPL
depends:
vermagic:       3.1.4-hadron SMP preempt mod_unload modversions

Eğer minor sürüm geçişleri ise, 3.1.3 > 3.14 geçişi gibi, yeni çekirdeğin modül dizinine almanız yeterli olur. 3.0′dan 3.1.4′e geçiyorsanız yeniden derlemeniz gerekir.

Şu an da aslında böyle bir durumdayım. Blog yazısı yazasım var ama yazamıyorum… Eskiden ne yazardım? Alabildiğine özgür yazılım geyiği… Aslında  ben bloga ara verdikten sonra tekrar açma kararı verirken artık sadece teknik yazılar yazarım diyordum. Ama o kadar  teknik bir  adam olmadığımdan bu hedefi pek tutturamadım. Zaten geriye dönüp bakarsanız bu süreçte pek “teknik” yazılar yazmadığımı hatta dikkate değer bir metin üretmediğimi de görürsünüz sanırım.

Hatta bu metnin de pek dikkate değer bir şey olmadığını buraya kadar okuduysanız anlamışsınızdır ya neyse… Devam edeyim.

Aslında ben yazı yazmayı pek sevmem, pek yetenekli de değilimdir bu konuda. Şu an olduğu gibi; 3 aydan fazla olmuş lan yazmayalı, çok da canım sıkıldı ne yazsam moduna girince ya da yazacak ciddi bir şeyim olduğu zaman yazıyorum ki yazacak ciddi bir şeyim olmadığından şu an anlamsız bir laf salatası okuyorsunuz.

Yazı yazmayı pek sevmediğim gibi kısa yazılar yazmayı da sevmem. Yazınca uzun yazar, kafa şişiririm. Kafa şişirmenin en güzel yolu da sanırım Hadron‘dan bahsetmekle olur.

Hemen alttaki girdiyi 20 Ağustos günü yazmışım. Yani hesaplamalarıma göre 3 aydan biraz fazla bir zaman olmuş. Aslında bu zaman dilimi bizim yaptığımızın ölçeğinde bir iş için zaman bile değil. Hele ki 1.85 kişiyle çalışıyorsanız.

O yazıyı yazdığımdan beri okumuyorum ama sanırım lpms’e yönelik planlardan, BSD’ye port etme girişimlerimden ve sürümün ne zaman çıkacağından bahsetmiştim. Sürüm konusundaki planımı, tahminimi pek tutturamadığım aşikar. Ama bu konuda kabahatli değilim. İş, okul, özel hayat derken tabii Hadron yavaş ilerliyor. Bu konuda  yapacak bir şey yok…

Geçen 3 ayda lpms’i baya baya adam ettim. Artık ona pek tırsmadan 1.0 diyebiliyorum. Changelog yazmayı pek sevmediğimden buraya dökülmeyeceğim ama; koda ve commitlere bakan ya da hiç uğraşmayıp doğrudan bana soru soranlar bu konuda bayağı bilgi alabilirler.

Gürkan sağ olsun iş bulmadan önceki bunalım dönemlerinde bayağı paket yaptı. Sayesinde depoda varlığından haberdar olmadığım paketler var. Tahmin ettiğim kadarıyla depoda şu an 600 civarı farklı paket var. Masaüstüne ulaşmanız için sadece biraz şanslı olmanız ve gerektiği yerlerde bana ya da Gürkan’a ulaşmanız yeterli olacaktır. Masaüstü demişken, sonu “box” ile biten bir kaç pencere yöneticisi haricinde LXDE ve XFCE4 depolarda olmayan kullanıcılarını bekliyor. Duyrulur…

Buraya kadar ~350 kelimelik laf salatası yapmayı başardım. Kayda değer hiç bir şey anlatmadım ve eğer buraya kadar okuduysanız hayatınızdan bir on dakika çaldım. Neyse, daha fazla uzatmadan sürüm sonrası Hadron 64 bit branchı için ve ileri düzey(lüks de denebilir) lpms yetenekleri için çalışacağımı da açıkladıktan sonra bu yazıyı bitireyim.

* Başlık araktır. Meraklı arkadaşlar araştırıp ne olduğunu bulabilir. Eğer ki içinizde bir hank varsa hoşça vakit geçirebilirsiniz.

Mayıs ayından beri Hadron cephesinde olan en iyi şey geliştirici sayısının 1′den 3′e çıkması oldu sanırım. Gürkan Gür ve Erdem Artan artık Hadron’a aktif katkı veriyorlar. Gitorious‘daki RSS beslemesinden neler yaptıklarını görebilirsiniz.

İkisinin birden paket yapmaya ve varolanlara bakmaya başlamasıyla üzerimdeki yük gayet azaldı. Azaldı derken boşa çıktığımı düşünmeyin. Temmuz ayından itibaren çalışıyorum, kendime ve Hadron’a ayırdığım zaman da bir hayli azaldı. Herşeyi bir arada düşündüğünüz zaman ~600 kadar paketi ve paket yöneticisini tek başıma yapmış kadar yoruluyorum, neyse.

Artık paketlerle daha az ilgilendiğim için Hadron’a ayırdığım vakti lpms üzerine yoğunlaştırıyorum. Hata kayıt sitemizden de görebileceğiniz gibi üzerimde şu an 30 kadar hata var ve bunların çok büyük bir kısmı lpms ile ilgili ya hata düzeltmesi ya da özellik isteği.

Sırası gelmişken lpms’de neler yaptığımı ve neler yapmayı planladığımı anlatayım:

lpms son rootfs sürümündeki atasının aksine şu an çok daha gelişkin ve olgun. Sanırım satır sayısı iki katına kadar çıktı ve pek çok yeni özellik ekledim. Bunlar irili ufaklı şeyler, bazılarını ben bile hatırlamıyorum ama bağımlılık çözme işlerini halleden lpms modülündeki commit sayısı lpms’e yaptığım toplam commit sayısının üçte birine yakın olabilir. Hala hataları var; zira oldukça karmaşık bir iş yapıyor. Sıkıntıları devam edecektir.

Geçen hafta sonu Hadron mesaimin bir kısmını lpms’i OpenBSD‘ye port etmeye harcadım.  Gerekli modifikasyonları yaptıktan sonra, sorunlar olsa da, OpenBSD üzerinde Hadron paketlerini derlemeyi/kurmayı başardım. Yani lpms, BSD ailesinden bir UNIX sistem üzerinde de çalışabilen bir paket yöneticisi şu an. Muhtemelen orta vadede sadece ben kullanabilirim ama; lpms’i Linux ve BSD sistemler üzerinde çalışabilen “evrensel” bir paket yöneticisi yapma hedefimi de açık etmiş olayım burada.

lpms paketleri kaynaktan derleyerek sisteme kuruyor biliyorsunuz. Bu bizim UNIX sistemi kullanma tarzımız ve bu konuda iyi bir paket yöneticisi çıkarmaya çalışıyoruz. Ama bazen binary paket lazım olabiliyor ve lpms şu an binary(bildiğiniz deb ya da rpm paketleri gibi) kuramıyor. Bu bir eksiklik evet ama; lpms’in konsepti paketleri kullanıcının bilgisayarı üzerinde derleyerek, hem herkesin istediği gibi bir sistem elde etmesini hem de ileri düzeyde işlemci optimizasyonlarının yapılmasını sağlamak üzerine kurulu. Gentoo ya da BSD’de ciddi deneyimi olanlar bu konuları bilirler zaten.

lpms’in gelecek sürümlerde binary paketleri kurup kaldırabilmesini ve hatta binary depoları oluşturup yönetebilmesini planlıyorum. Bu sayede hibrit bir paket yöneticisi ortaya çıkarmış olacağız. Ama Hadron hiç bir zaman binary paket deposu sağlamayacak. Bu özelliği 3. şahıslar ya da projeler kullanacak.

Bir diğer hedefim ise Debian‘daki debconf‘un bir benzerini lpms için yazmak. Bu konu henüz tasarım tahtasında bile değil. Orta vadede mümkün, muhtemelen 2012 yılı içinde çalışacağımız bir konu olacak.

Tüm bunları gerçekleştirdiğim zaman modern altyapılar kullanan BSD tarzı bir UNIX sistem yaratma konusundaki hevesimi biraz daha tatmin etmiş olacağım.

En son ve en çok arzuladığım iş ise Hadron’un altyapılarını tamamen Python 3‘e taşımak. Grafik arayüzlü araçlar gibi bizim açımızdan tamamen anlamsız hedeflerimiz olmadığı için GTK+ gibi şeylerin Python 3 tarafından desteklenmiyor olması umrumda değil ama sandboxing uygulaması olarak kullandığımız catbox C ile yazılmış bir Python 2 uygulaması olduğu için geçiş yapamıyoruz. Aslında catbox’u Python 3′e taşımak altından kalkamayacağım bir iş değil. Ama yeterince C ve bu dille Python modülü yazma tecrübem olmadığı için zorlanabilirim. Ve sonradan çıkacak hataların da faturası canımızı çok yakabilir. O yüzden girişmiyorum ama; Python 2.7.2 ile Python 3′teki tüm yenilikleri kullanarak kod yazıyorum, o da ayrı bir mesele.

Dökümantasyon işi de fena gitmiyor. Gürkan Hadron’la ilgililenmeye başladıktan sonra benim yazdıklarımı güncelleştirerek İngilizceye çevirdi. Dökümanlar HadronWiki’de duruyor. Girip okuyabilirsiniz.

Her Hadron yazısına eklediğim gibi buna da projenin sayfalarını ekleyeyim. İlgilenmek isteyen olursa hiç çekinmesin buyursun. Freenode üzerindeki #hadron kanalında ilgili birilerini bulma olasılığınız çok yüksek.

Hadron Projesi Anasayfa

HadronWiki

Bu gizemli şey hakkında yeterince bilgi sahibi olan insan sayısı azdır. Çünkü normal şartlarda uğraşacağınız ya da uğraşmak isteyeceğiniz bir seviyede çalışmaz. Onunla muhatap olmak için özel bir durumda olmanız gerekir.

Initramfs, kısaca ufak bir UNIX kök dosya sistemidir. Çoğu ev kullanıcısı için olmasa da olur ama işler biraz karmaşıklaşınca; mesela şifrelenmiş dosya sistemi kullanıyorsanız ya da bir çalışan CD(live CD) kullanıyorsanız, sistem açılırken initramfs aşamasını mutlaka geçmişsinizdir.

Peki ne işe yarar? Aslında çok basit: işletim sisteminizi açılışa hazırlar. Normalde Linux çekirdeği kök dosya sisteminizi bağlayıp sistemi açması için işleri init‘e devreder; fakat yapamayacakları da vardır. Klasik bir initramfs, gereken modülleri yükler(dosya sistemi modülleri gibi), dosya sistemlerini bağlar(şifrelenmiş, şifrelenmemiş ya da lvm gibi), açılış sürecini özelleştirir(boot splash gibi) ve şu an aklıma gelmeyen pek çok şeyi yapar.

Initramfs’in minyatür bir UNIX dosya sistemi olduğundan bahsettim. Eğer bir şekilde açılış esnasında debug moduna düşmüşseniz initramfs içinde gezinmiş olma ihtimaliniz vardır. GNU/Linux’da ya da başka bir UNIX benzeri işletim sisteminde, terminali açtığınızda ne görüyorsanız aynısını initramfs içinde de bulabilirsiniz. Fakat burada aklınıza bazı kritik sorular gelmeli: tüm bunlar nasıl oluyor? Henüz dosya sisteminin bağlanmadığı, temel C kitaplıklarının ve diğer hayati şeylerin olmadığı bir çalışma alanında nasıl oluyor da tüm UNIX araçlarına erişebiliyorsunuz?

Cevabı oldukça basit: BusyBox

Busybox hemen hemen tüm UNIX komutlarını, hatta dpkg, vi gibi araçları bile bünyesinde barındıran bir araçlar bütünü. Geniş bir kullanım alanına sahip. Elinizdeki Android yüklü telefondan, masanızdaki modeme kadar hemen her yerde ona rastlamak mümkün.

Busybox mükemmel ama rakipsiz de değil; klibc denen bir araç daha var ama pek tercih edilmiyor BusyBox’ın yanında.

Dağıtımınızın depolarından BusyBox’ı rahatlıkla kurabilirsiniz. Eğer böyle yaparsanız çok şey kaçırırsınız, BusyBox’ın aynen Linux çekirdeğinin metin tabanlı ayar arayüzüne benzeyen bir ayar arayüzü var. Deneyimsiz biri için onu sıfırdan ayarlamak, tabii, biraz zor olacaktır ama hazır bir ayar dosyası(.config) bulup kurcalarsanız nasıl güzel bir şey olduğunu hemen anlarsınız.

Çoğunuzun bildiği gibi, Linux çekirdeği açılış için temel işlemleri yaptıksan sonra görevi init‘e devreder ve olaylar gelişir. Araya initramfs girince işler biraz değişiyor. Hoş, çekirdek görevi yine init adında bir betiğe devrediyor bu sefer de.

Initramfs içinde yer alan init betiği bahsettiğim tüm açılış işlerini yürütüyor. Yaptığı işe göre çok karmaşık da olabilir çok basit de. Birazdan ufak ama çalışan bir örneğini göreceksiniz.

Asıl anlatmak istediğim kısıma geleyim: initramfs nasıl elde ediliyor?

Basitçe, 2-3 komutla temel düzeyde bir initramfs inşa edebilirsiniz.  Önemli olan çekirdeğinizin niteliği ve hazırladığınız init betiği.

Çekirdeğinizin niteliği önemli; çünkü birazdan hazırlayacağımız dosya sisteminde çekirdek modülleri ile ilgili bir şey bulunmuyor; fakat dosya sistemlerini bağlayan -sürücüler çekirdeğe gömülmemişse- ya da donanım sürücüleri yükleyen bir initramfs inşa ederseniz çekirdek sürücüleri ile uğraşmak zorunda kalacaksınız.

Önce dosya sisteminin temel yerleşimini oluşturalım:

# mkdir -p initramfs/{bin,sbin,etc,proc,sys,lib,dev}

initramfs diye bir dizin altında çalıştığımıza dikkat edin!

Şimdi sıra yukarıda bahsettiğim BusyBox’ı yerleştirmekte. Burada dikkat etmeniz gereken çok önemli bir nokta var. Kullandığınız BusyBox statik bağlanmış olmalı; yani her şey tek bir ikili(binary) dosya altında tutulmalı. Eğer dinamik bağlanmış olursa gereken kitaplıkları /lib altına kopyalamak durunda kalırsınız. Bu da biraz can sıkıcı olur.

BusyBox derlemenizin statik mi dinamik mi olduğunu anlamanın basit bir yolu var:

# file /bin/{bb,busybox} | grep static

BusyBox bb ya da busybox adıyla sistem yolunda bulunabiliyor. Almanız gereken sonuç şöyle:

/bin/busybox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.27, stripped

Aynı komutu, söz gelimi bash için uyguladığımda bakın ne sonuç alıyorum:

/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

Yeterli açıklamayı yaptığımıza göre BusyBox’ı yeni dosya sistemimize kopyalayabiliriz:

# cp /bin/busybox initramfs/bin

BusyBox minyatür sistemimizin her şeyi. Henüz ortalıkta hiç bir şey yokken kabuk görevi görmesi için bir bağlantı oluşturmamız gerekiyor:

# ln -s busybox initramfs/bin/sh

Şimdi sıra açılış sürecini programladığımız betiği sisteme yerleştirmeye geldi. Görebileceğiniz en basit ama çalışan -benim sistemde çalıştı- init betiği aşağıda duruyor.

mount -t proc proc /proc
mount -n -t sysfs sys /sys
mount -o remount,rw /

/bin/busybox --install -s

mdev -s

exec /bin/sh

Betik basitçe /proc ve /sys dosya sistemlerini bağlıyor. Ardından da temel UNIX komutlarıyla(/bin/ls /bin/mv gibi) BusyBox’ın linklenmesini sağlıyor. Evet, initramfs altında tüm komutlar BusyBox’a çıkan linkler!

Yukarıdaki 3 satır kodu init diye bir dosya içinde initramfs dizini altına yerleştiriyoruz. Daha sonra onu chmod +x initramfs/init komutu ile çalıştırılabilir hale getirmeniz gerekiyor.

Şimdi gelelim “inşa” meselesine:

$ cd initramfs
$ find . | cpio -H newc -o > ../initramfs.cpio
$ cd ..
$ cat initramfs.cpio | gzip > initramfs.igz

Bu komutlarla initramfs.igz diye bir dosya üretmiş oluyoruz. Daha sonra onu GRUB ya da her ne kullanıyorsanız initrd gibi bir satıra eklemeniz gerekiyor. Eğer işler iyi giderse hiç bir özelliği olmayan bir UNIX komut satırı ile başbaşa kalacaksınız.

Onunla neler yapabileceğiniz size kalmış. BusyBox glibc ve uClibc ile derlebilen bir program. Biraz uğraşarak bir “tiny” Linux dağıtımı geliştirmek çok eğlenceli olabilir. Öyle değil mi!

—

Bu arada, çekirdeğinizin initramfs desteğinin olmasına dikkat edin. Eğer hazır derlenmiş bir çekirdek kullanıyorsanız destek vardır. Benim gibi ne zaman bir binary dağıtım kullandığını unutmuş biriyseniz şunu bilmenizde fayda var:

General setup --->
[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support

Aklınızda bulunmasında fayda var. Initramfs’i çekirdeğe de gömebilirsiniz. Bunun için aşağıdaki ayara sahip olmanız gerek.

General setup --->
(/usr/src/initramfs) Initramfs source file(s)

/usr/src/initramfs yukarıda çalıştığımız dizini temsil ediyor. Bu şekilde ilerlerseniz çekirdeği derlediğinizde initramfs otomatik olarak oluşturulacak ve bzImage dosyasına gömülerek kullanılacaktır.

—

İleri okumalar:

• http://en.gentoo-wiki.com/wiki/Initramfs
• http://jootamam.net/howto-initramfs-image.htm

Fazla uzatmayayım. Kodlar şöyle:

#!/usr/bin/env python

conf = """

# [falanca] ayarları kategorize etmek için kullanılabilecek bir notasyon
[General]

foo = True

command = /usr/bin/foo_command --prefix=/usr

# bu bir yorum satiri

"""

class ReadConfiguration(object):
    def __init__(self):
        for atr in conf.strip().split('\n'):
            if not atr.startswith("[") and not atr.startswith("#"):
                if len(atr.split("=")) > 1:
                    data = atr.split("=")
                    self.__dict__[data[0].strip()] =  "=".join(data[1:]).strip()

Biraz savruk ama neyse…

Kod oldukça basit. Python’un öntanımlı ayrıştırıcısı gibi .ini benzeri ayar dosyalarını ayrıştırıyor. Fakat bu kodun, bence, güzelliği kullanımının çok basit olması. Değerleri(örnekte foo, ve command) ReadConfiguration sınıfının metodlarıymış gibi(son satıra dikkat) atıyor. Bu sayede fazladan bir çabaya gerek kalmadan, ayar dosyasına bir değer girdiğinizde hemen kullanmaya başlayabiliyorsunuz.

Şöyle yani:

import readconfiguration

rc = ReadConfiguration()

print(rc.foo)

print(rc.command)

if rc.foo:
    print("It Works!")

Bunu ufak bir betik gibi düşünecek olursak şöyle bir sonuç elde edebiliriz:

burak@hadron-dev ~ $ python3 conf.py
True
/usr/bin/foo_command --prefix=/usr
It Works!

Sınıfın buradaki hali sadece bir demo. Şu an lpms’de daha farklı bir hali çalışıyor. Şu an ki haline daha fazla kontrol ve herhangi bir yerden herhangi bir ayar dosyasını okuma yeteneği eklenebilir, eklenmelidir. Ayrıca .ini tarzı ayar dosyası meselesini de kolayca aşabilir, kendi keyfinize göre bir tarz da belirleyebilirsiniz.

Kod Python-2.7.1 ve 3.2.0 sürümlerinde çalışıyor.

Hatalar varsa bildiriniz!

Pek çoğunuzun bildiği gibi ben Hadron diye bir şey geliştirmekteyim. Kendisi bir özgür yazılım olup, eskiden Live Linux olayına biraz farklı bir açıdan bakmaya çalışan bir dağıtımsı idi. 1.5 yıllık geliştirme faliyeti, sonuncusu herkes tarafından beğenilen 3 sürüm ve yapılan onca reklamın ardından, bana ciddi geri bildirim yapan kullanıcı sayısı 10′u bulmayınca ve bir live dağıtım olarak Hadron’u kendim de kullanamayınca, onunla ilgilenmek çok tatsız bir hal almaya başladı. Zaten Alpha sürümün çıkışından aylar sonra yeni sürüm için çok az adım atmıştım. Malum, motivasyon sıkıntısı…

Uzun lafın kısası artık bildiğiniz ve kullandığınız ya da muhtemelen hiç ciddiye almadığınız Hadron’u geliştirmiyorum. Eğer ben onu sevmiştim diyen varsa kodlara erişebilirler hala.

Neyse, aslında anlatmak istediğim şey bu değildi benim. Şubat ayında bildiğiniz Hadron’u geliştirmeyi bıraktıktan sonra kendi kafama göre bir sistem geliştirme düşüncesi zihnimde belirdi. Tamamen benim istediğim tarzda, Gentoo benzeri bir dağıtım hazırlamaya çalışmak çok eğlenceli bir fikir gibi geldi. Hala da öyle düşünüyorum… Tabii bu kararı alırken Yasin‘in gaz vermesinden de yararlandım.

Şu an elimde kendi kendine yetebilen bir taban sistem var. Dağıtımın adı hala aynı, paket yöneticisinin adı da hala aynı.  lpms şu an Portage’ın ilk sürümlerine benziyor ama tamamen Python ile yazıldı. Paket formatının ve paket yöneticisinin kullanımının çok basit olmasına çalıştım elimden geldiğince. Açıkçası, inşa betiklerini yorumlayacak bir ortam kodlamak ve kontrol kurmak bayağı eğlenceli ve öğreticiydi. Artık Python’u daha iyi kullanıyorum.

Her ne kadar kendim için geliştiriyorum desem de Hadron’la ilgilenen insanların olması ve hatta benimle birlikte 3-5 kullanıcı/geliştirici bulunması beni memnun eder. Eğer katkıda bulunmak ya da kullanmak isterseniz benimle irtibata geçin. Freenode üzerindeki #hadron kanalında beni bulma ihtimaliniz oldukça yüksek. Eğer bulamazsanız purak et hadronproject nokta org adresine bir mesaj bırakın. En kısa zamanda geri dönmeye çalışırım.

Konuyla ilgileniyorsanız http://hadronproject.org/ adresine bir bakınız. İndirmek için ise http://hadronproject.org/get-hadron/ adresine bakabilirsiniz. Sitede nasıl geliştirici olabileceğinize dair bilgiler de var. Ayrıca HadronWiki‘de nasıl paket yapılacağına dair bilgiler de bulunuyor. Bu arada, siteye yazdıklarım çok aceleye gelmiş şeyler. Hatalar olabilir, affola.

İnsanın emek verdiği ve kamu malı olarak sunduğu bir ürünü sıkıntı ve çekingenlikle duyurması da çok tatsız bir durum. Okuduklarınızı yazarken deneyimledim.

Not: Bu sefer de uzun olmuş.

1- Bilgisayar biliminin temellerini bilin.

Program yazarken kullandığımız programlama dillerinin ve tekniklerin bir teorik temeli var. Veri yapıları, algoritmalar, nesne yönelimli programlama, tasarım örüntüleri(design patterns) gibi konularda iyi kötü teorik bilgiye sahip olun. Hatta zamanınız varsa ve gerçekten ilgi duyuyorsanız daha fazlasını da çalışabilirsiniz. Bu madde benim gibi Bilgisayar Mühendisliği ya da yakın dallarla okul bazında alakası olmayanlar için çok önemli; çünkü yaptığınız işin temelini bilmelisiniz.

2- Kullandığınız dilin temel özelliklerini iyi bilin.

Bir programlama dilinde etkin kod üretebilmek için onun inceliklerini bilmeniz gerekir. Python özelinde konuştuğumuza göre kaynak da gösterebilirim. Resmi Python dökümanlarındaki bazı kısımlar ve bazı kaynak kitaplar işinizi görebilir.

http://docs.python.org/release/3.1.3/tutorial/index.html
http://docs.python.org/release/3.1.3/howto/
http://diveintopython3.org

3- Düzenli olarak kod yazın.

Eğer bir dili öğreniyorsanız, onu düzenli olarak kullanmalısınız. Bu sizi zinde kılar. Tıpkı bir sporcu gibi; sürekli çalışırsanız o dili, dolayısıyla programlamayı da zamanla özümsersiniz. Size 10 günde ya da 3 haftada programlama ya da programlama dili öğreteceğini iddia eden kitaplara, kaynaklara kanmayın. Programlama yeteneğiniz, zeka ve deneyim gerektiren tüm diğer işlerde olduğu gibi zamanla gelişir.

4- İyi yazılmış kodları okuyun.

Sizden daha zeki ve muhtemelen daha uzun zamandır program yazan insanlar vardır kesinlikle. Onların yazdıkları kodları okuyun. Github, Gitorious, Google Code ve Sourceforge gibi kaynaklarda pek çok proje var. İlginizi çekenlerin ve kaliteli kod içerdiğine inandıklarınızın kodlarını edinin ve okuyun. Kod roman okur gibi okunmaz elbette ama sadece baksanız bile bir göz aşinalığı edinirsiniz. Ayrıca yapabiliyorsanız koda ufak tefek müdahalelerde bulunup nasıl çalıştığını gözleyin. Bu sizi motive eder.

Son dönemde dikkatimi çeken ve bolca kaliteli Python kodu içeren PyPy projesi var mesela. İnceleyin, gerçekten çok ilginçtir… Ayrıca Python’un kendi kodunu da inceleyebilirsiniz. Kodun C kısmından bahsetmiyorum; saf Python’la yazılmış modülleri inceleyin. Bizzat Python geliştiricileri ve katkıcıları tarafından yazılmış kodlar ve gayet güzeller.

5- Temiz ve standartlara uygun kod yazın.

İster Özgür Yazılım geliştirin ister sahipli, kodlarınız mümkün olduğunca okunaklı ve standartlara uygun olmalıdır. Bu durum Özgür Yazılım projeleri için daha da önemli; çünkü sizden başkaları da programınızı geliştirmek isteyebilir. Sadece yazdıklarınızı anlamak bile yeterli bir beyinde verimli fikirler oluşturabilir. Ayrıca programınızı nasıl dağıtırsanız dağıtın kodun kirli ve standart dışı, yani kalitesiz, olması zamanla projenizi öldürebilir.

Meşhur PEP 8, Python’un stil rehberi gibidir. Onu okuyun.

http://www.python.org/dev/peps/pep-0008/

Bu da Google‘ın Python hakkındaki tavsiyeleri. Google gibi Python’u çok yoğun olarak kullanan kaliteli bir firmanın dediklerine kulak asmak gerekir.

http://google-styleguide.googlecode.com/svn/trunk/pyguide.html

6- Yarım yamalak öğrenmeyin.

Kullandığınız dilin bir özelliğini keşfettiğinizde, o konu hakkındaki her şeyi araştırın ve bulduğunuz bilgiyi elinizden geldiğince özümseyin. Bir şeyi yarım yamalak bilmek çok tehlikelidir.

7- Daha fazlasını öğrenin.

Özellikle benim gibi orta düzey bir programcıysanız öğreneceğiniz çok şey vardır. Yazdığınız program muhtemelen çok daha güzel ve zekice yazılabilir. Sürekli araştırın, yeni özellikler ve teknikler öğrenip onları kullanmaya çalışın.

Şöyle bir veri yığınını XML formatına dönüştürmek istiyorsunuz diyelim ki:

source = "bash"
pkgname = "bash"
version = "4.2"
summary = "The standard GNU Bourne again shell"
homepage = "http://tiswww.case.edu/php/chet/bash/bashtop.html"
dependency = "ncurses"

Oluşturmak istediğimiz XML formatı da tam olarak şöyle:

<package source="bash">
    <name version="4.1_p7">bash</name>
    <summary>The standard GNU Bourne again shell</summary>
    <homepage>http://tiswww.case.edu/php/chet/bash/bashtop.html</homepage>
    <dependencies>
        <dependency>ncurses</dependency>
    </dependencies>
</package>

Bu işi yapacak Python kodu ise:

import xml.etree.cElementTree as iks

source = "bash"
pkgname = "bash"
version = "4.2"
summary = "The standard GNU Bourne again shell"
homepage = "http://tiswww.case.edu/php/chet/bash/bashtop.html"
dependency = "ncurses"

root = iks.Element("package")
root.set("source", version)

name_tag = iks.SubElement(root, "name")
name_tag.set("version", version)
name_tag.text = pkgname

summary_tag = iks.SubElement(root, "summary")
summary_tag.text = summary

homepage_tag = iks.SubElement(root, "homepage")
homepage_tag.text = homepage

dependencies_tag = iks.SubElement(root, "dependencies")
dependency_tag = iks.SubElement(dependencies_tag, "dependency")
dependency_tag.text = dependency

print(iks.tostring(root))

ElementTree’den bahsederken cElementTree kullanmama dikkat edin. cElementTree, tahmin edebileceğiniz gibi ElementTree’nin C ile gerçeklenmiş hali. Hız açısından her zaman C ile yazılmış modülleri tercih edin. Python 2 serisindeki pickle/cPickle ikilisi de buna bir örnek teşkil ediyor.

Kodu açıklamak istiyorum ama; açıklanacak fazla birşey de göremiyorum. Gayet sade ve anlaşılır. Biraz açıklama yapayım yine de: XML yapısındaki ilk girdiyi(örnekte root yani, “package”) oluşturmak için Element metodunu kullanıyoruz. Daha sonra alt girdiler oluşturmak içinse SubElement metodu devreye giriyor. attribute atamak için set metodu kullanılırken girdilere değer vermek için(doğru bir ifade mi?) text metodunu kullanmak yeterli oluyor. Bu kadar basit bir kodu nasıl açıklayacağımı pek bilemedim gördüğünüz gibi…

Aslında önemli bir nokta var. ElementTree, tüm olumlu özelliklerine rağmen XML dosyaları oluşturmak konusunda biraz sıkıntılı. Yukarıdaki kod bloğunun nasıl çıktı verdiğine bakalım:

<package source="4.2"><name version="4.2">bash</name><summary>The standard GNU Bourne again shell</summary><homepage>http://tiswww.case.edu/php/chet/bash/bashtop.html</homepage><dependencies><dependency>ncurses</dependency></dependencies></package>

Oluşturacağınız XML dosyasını insanlar okuyacaksa çok talihsiz bir çıktı bu. İşin kötüsü; kitaplık, girintileme sorununu çözmek için bir fonksiyon da sağlamıyor. Sorunun çözümü ElementTree’nin internet sitesinde bir yerlerde yatıyor. Aşağıdaki fonksiyonu koda eklediğimizde çıktı başta verdiğim XML yapısı gibi düzgün görünecek.

def indent(elem, level = 0):
    i = "\n" + level*"  "
    if len(elem):
        if not elem.text or not elem.text.strip():
            elem.text = i + "  "
        #if not elem.tail or not elem.tail.strip():
        #    elem.tail = i
        for e in elem:
            indent(e, level+1)
            if not e.tail or not e.tail.strip():
                e.tail = i + "  "
        if not e.tail or not e.tail.strip():
            e.tail = i
    else:
        if level and (not elem.tail or not elem.tail.strip()):
            elem.tail = i

Çıktıyı ekrana yazdırmadan önce root değişkeni bu fonksiyondan geçmeli. Yani:

.....
..
indent(root)
print(iks.tostring(root))

Girintilemenin doğru yapıldığını göreceksiniz.

ElementTree’nin benim burada anlattığımdan kat kat fazla yeteneği var. Orjinal dökümantasyonu inceleyerek bolca bilgi edinebilirsiniz. Benimkisi biraz “böyle bir şey de var himm” denilecek türden bir yazı oldu. Ufak bir bilgi notu gibi…

Şuna benzer bir modülü(foo.py) kullanacağız diyelim ki:

# -*- coding: utf-8 -*-
def ben_bir_metodum():
    print("Bu bilgi ne işe yarar ki?")

def ben_de_bir_digeri():
    print("Benim çok işime yaradı bugün!")

Fonksiyonları/metodları çalıştıracak kod parçası ise şu:

# -*- coding: utf-8 -*-
import foo

# diyelim ki çağıracağımız metodları da biliyoruz
for mtd in ('ben_bir_metodum', 'ben_de_bir_digeri'):
    metod = getattr(foo, mtd)
    metod()
    print("-----")

Yukarıdakinin çıktısı şöyle olacak:

Bu bilgi ne işe yarar ki?
-----
Benim çok işime yaradı bugün!
-----

Fonksiyon isimlerinin döngüye giriş sırasıyla oynayarak fonksiyonların çalıştırılma sıralarını da değiştirebilirsiniz.

Bu basit bilgi bugün çok işime yaradı!

Hemen her dilde de ayrıştırıcısı da var. Hem de birden fazla. Python’da da 3-5 tane ayrıştırıcısı var mesela. Bunların arasından -bence- en iyisi ElementTree kitaplığı. Hem oldukça basit hem de oldukça hızlı.

Python’un interaktif kabuğunu açıp şu komutu verelim:

>>> import xml.etree.cElementTree as iks

Bu arada, ElementTree’nin C ile yazılmış bir gerçeklemesi de olduğundan hız için onu kullanmayı tercih ediyorum. Şimdi şöyle bir XML yapısını ayrıştırmak istediğimizi düşünelim:

<package source="bash">
    <name version="4.1_p7">bash</name>
    <summary>The standard GNU Bourne again shell</summary>
    <homepage>http://tiswww.case.edu/php/chet/bash/bashtop.html</homepage>
    <dependencies>
        <dependency category="sys-libs">ncurses</dependency>
    </dependencies>
</package>

Bu dosyayı spec.xml adında olarak kabul edelim ve ayrıştıralım.

>> data = iks.parse("spec.xml")

ElementTree onu hafızaya aldı, şimdi sıra ayrıştırmada. Diyelim ki etiketinin taşıdığı veriyi almak istiyorsunuz:

>>> a = data.find("name")

Bu kod parçası data‘nın işaret ettiği veri içerisinde name etiketini araştırıyor. Eğer öyle bir etiket yakalayamazsa; a, None değerini alıyor. Biz yakaladığı durumu inceleyelim. Öncelikle tag metodu ile etiketin adını alalım:

>>> a.tag
'name'

Aslında burası biraz opsiyonel. Programın doğru veriyi alıp almadığını kontrol etmek için kullanılabilir. Etiketin taşıdığı veriyi almak içinse text metodunu kullanın:

>>> a.text
'bash'

Dikkatlice bakarsanız name etiketinin bash’dan başka bir başka veri daha taşıdığını görürsünüz. Bunlara attribute deniyor.

>>> a.attrib
{'version': '4.1_p7'}

attrib metodu ile onları da avlıyoruz. Eğer birden fazla attribute olsaydı onlar da yukarıdaki sözlüğün içinde yer alacaklardı.

Diğer etiketleri de yukarıdaki biçimde avlıyabilirsiniz. Sadece dependencies etiketi biraz farklılık arzediyor. Öncelikle dependencies etiketini araştıralım. Eğer bulunamazsa yine None değeri dönecek.

>>> a = data.find("dependencies")


dependencies etiketi alt etiketlere sahip olduğu için onun içinde de dependency etiketini aramamız gerekecek.

>>> a.findall("dependency")
[<Element 'dependency' at 0xb70ee590>]

Birden fazla bağımlılık olabileceği için dependency etiketini findall() metodu ile kontrol ettiğime ve geri dönen veri tipinin bir liste olduğuna dikkat edin. İlk örnekte de findall() kullanabilirdik ve yine bir liste dönerdi.

Aynı etiketten birden fazla varsa onların hepsini birden avlamak için şöyle pratik birşey kullanabilirsiniz:

>>> b = [(depend.text, depend.attrib) for depend in a.findall("dependency")]
>>> b
[('ncurses', {'category': 'sys-libs'})]

ElementTree’nin parse() metodunu kullanarak yapabilecekleriniz çok basit bir şekilde böyle. Yine ayrıştırma için kullanabileceğiniz iterparse() metodu da var.

>>> p = iks.iterparse("spec.xml")
>>> p
<iterparse object at 0xb7362acc>
>>> for i in p:
...     print(i)
...
('end', <Element 'name' at 0xb70ee890>)
('end', <Element 'summary' at 0xb70ee4e8>)
('end', <Element 'homepage' at 0xb70ee470>)
('end', <Element 'dependency' at 0xb70ee308>)
('end', <Element 'dependencies' at 0xb70ee398>)
('end', <Element 'package' at 0xb70ee458>)

Gördüğünüz gibi find metodu kullanmaya gerek kalmadan tüm etiketleri yakaladı. Dönen listelerin ikinci üyesinden yukarda bahsettiğim metodları kullanarak veri çekebilirsiniz.

Bu arada, anlatımı Python-2.7.1 kullanarak yaptım. Py3k için, bildiğim kadarıyla hiçbir fark yok.

Cevap oldukça basit:

script = open("script.py").read()
objects = {}
exec compile(script, "error", "exec") in objects
print(objects.keys())

script.py ise şöyle temsili birşey:

#!/usr/bin/env python

bu_bir_string = "bana string derler"

def bir_fonksiyon(parametre):
	print(parametre)

def bu_da_bir_digeri(parametere):
	print(">>> "+parametre)

İlk kod blogunu çalıştırınca şöyle bir çıktı elde edeceksiniz:

$ python calistir1.py
['__builtins__', 'bir_fonksiyon', 'bu_bir_string', 'bu_da_bir_digeri']

Gördüğünüz gibi; objects sözlüğünün tüm üyelerini bir listeye aldı. __builtins__‘i hariç tutarsak diğerlerinin tümü programcının tanımladığı fonksiyon ve değişkenler. Bunların hangisinin fonksiyon hangisinin sözlük, liste vb. şeyler olduğunu çeşitli tekniklerle kontrol edebilirsiniz. Şimdi de yukarıdaki metodla içe aldığımız Python betiğini nasıl ana program içinden çalıştıracağımızı görelim.

#!/usr/bin/env python

script = open("calistir.py").read()
objects = {}
exec compile(script, "error", "exec") in objects

for obj in objects.keys():
	if obj == "__builtins__":
		continue
	if type(objects[obj]) == str:
		print(objects[obj])
	else:
		objects[obj]("Python harika bir betik dili!")

Bunu çalıştırınca şöyle bir çıktı veriyor:

$ python calistir1.py
Python harika bir betik dili!
bana string derler
>>> Python harika bir betik dili!

Gördüğünüz gibi yakaladığını çalıştırdı. Fonksiyonları çalıştırmak için objects[obj]() kullandığıma dikkat edin. Hangi nesnenin bir fonksiyon hangisinin string hangisinin liste ya da başka bir veri tipi olduğunu ayırdetmenin pek çok yolu olabilir. Ben ayaküstü bir tane uydurdum. Ayrıca akışı da istediğiniz gibi kontrol edebilirsiniz.

Bu arada kodlar Python-2.x için geçerli. Python-3.x serisinde exec fonksiyonunun sentaksı farklı.

Okulun can sıkıcı olan etabını tamamladığıma göre sevdiğim işlere geri dönme vakti de geldi, en azından hakkettim bunu!

Bu arada Hadron Alpha çıkalı neredeyse 5 ay oluyor. Yeni sürüm vakti geldi de geçti bile. Ama ortada yarım yamalak bir lpms var, gerisi yok! Gerçi zaman bulursam, büyük bir hızla, işleyen bir lpms ortaya çıkarabilirim ama Beta‘nın Alpha‘nın çizgisini yakalaması beni biraz yoracak gibi. Bu arada bir sürü test kullanıcısına ihtiyacım olacak. Umarım bu sefer ISO’daki teşekkür listesine adını yazacabileceğim daha fazla test kullanıcısı olur. Öte yandan şu belgeyi de hala geliştiriyorum. Merak edenler varsa bakabilirler.

Çok uzak olmayan bir zamanda yeni ıvır zıvırlarla dönerim!

Vala’nın ortaya çıkışının, bence, GNOME geliştiricileri için mantıklı ve faydalı sebepleri var. GNOME/GTK+, C ile geliştirilen yazılımlar ve bu dilde kod yazmanın oldukça meşakatli bir iş olduğunu sanırım bir çoğumuz biliyordur. Hele ki GNOME gibi komple bir sistemi ortaya çıkarmanın zorluğu tartışılamaz…

Aslında C ile nesne yönelimine yaklaşmak için GObject denen bir sistem çok önceden geliştirildi ve söz konusu projelerde yoğun olarak kullanıldı ama C’nin yoruculuğu ve GTK+’nın insanı delirten yapısı bir yana, GObject’in kendisi bile öğrendiğim kadarıyla bir işkence aleti! Bu problemleri çözmek için Jürg Billeter ve Raffaele Sandrini Vala denen, bence, çok tatlı bir dil geliştirdiler.

Lafı fazla uzatmadan Vala’nın neye benzediğine bakalım; her zaman olduğu gibi bir “Merhaba Dünya!” uygulaması yazarak yapalım bunu:

void main() {
    print("Merhaba Dunya!\n");
}

Bu örneği şu şekilde de yapabiliriz. Bu sefer Vala’nın nesne yönelimli özelliklerini kullanıyoruz:

class MerhabaDunya:Object {
    void selamla() {
        stdout.printf("Merhaba Dunya!\n");
    }

    static void main(string[] args) {
        var dunyayi = new MerhabaDunya();
        dunyayi.selamla();
    }
}

Dilin genel itibariyle Java/C# sentaksına çok yakın olduğunu farketmişsinizdir.

Bu yazdıklarım Vala Nedir? yazısından öte bir anlam taşımadığından dilin genel özellikleri ve yukarıdaki satırların ne yaptıkları hakkında konuşmayacağım. Ama bu kodu nasıl derleyeceğinizden bahsedebilirim; öncelikle Vala derleyicisini(aslında bir önişlemci) kurmanız gerekiyor. Kurduktan sonra basitce şu komutu verebilirsiniz.

valac merhaba.vala

Bu komut ilk Vala kodlarımızı önce C koduna dönüştürecek daha sonra ise GCC ile derleyerek makina koduna dönüştürecek. ./merhaba komutunu kullanarak programın size “merhaba” demesini büyük bir zevkle(!) izleyebilirsiniz.

Vala derleyicisi biraz gcc ve saz arkadaşlarına benziyor. -o parametresi ise oluşan ikili dosyaya kendi isteğinize göre bir isim verebilirsiniz.

valac -o isim_verdim merhaba.vala

Vala kodunun C koduna dönüştürüldüğünden bahsetmiştim, eğer neye benzediğini merak ediyorsanız -C parametresini kullanabilirsiniz.

valac -C merhaba.vala

Ben bu komutu nesne yönelimli Vala örneği için kullandım. Tam 100 satırlık bir GObject kullanan C kodu üretmiş, oldukça karışık bir kod olduğunu da söylemem gerek. GObject ve C ile GNOME uygulaması geliştirmek istemezdim! GNOME’un neden çok yavaş geliştirildiğini şimdi daha iyi anlıyorum.

Şimdi de ilk verdiğimiz örneğin(3 satırlık “Merhaba Dünya” programcığı) C koduna bakalım; gayet anlaşılır duruyor.

/* sample2.c generated by valac 0.10.1, the Vala compiler
 * generated from sample2.vala, do not modify */
#include <glib.h>
#include <glib-object.h>

void _vala_main (void);

void _vala_main (void) {
	g_print ("Merhaba Dunya");
}

int main (int argc, char ** argv) {
	g_type_init ();
	_vala_main ();
	return 0;
}

Son derece sade(GObject kullanılan C kodu için!) ve tanıdık öyle değil mi! Tabii yine biraz GObject bulaşmış durumda.

Bu kadar teknik mumbo-jumbo size yettiyse Vala’nın ne kadar kullanılabilir olduğundan ve şu ana kadar nerelerde kullanıldığından bahsedelim.

Vala, ilk cümlemde oyuncak olarak nitelememe rağmen oyuncak bir dil ya da deneysel bir çalışma değil. Tamamen gerçek ihtiyaçlar üzerine geliştirilmiş, Java/C# sentaksını kullandığı için bence pek çok sorunu önceden aşmış bir dil. Onunla her türlü uygulama geliştirebilirsiniz. Masaüstü uygulamalarından komut satırı araçlarına varıncaya kadar hemen herşey… Ama bildiğim kadarıyla masaüstü uygulamaları geliştirecekseniz GTK+ kodlamak zorundasınız…

Ayrıca doğrudan C koduna dönüştürülerek derlendiği için Python, C#, Ruby vb. dillerde elde edeceğiniz performanstan daha fazlasını elde etmeniz gayet normal. Bu konuyla ilgini tatminkar bir belge aşağıdaki  adreste var.

http://code.google.com/p/vala-benchmarks/wiki/BenchResults

Vala’yı bugüne kadar kimler kullandı ve hayatımızı nasıl etkileyecek derseniz:

• Yorba Vakfı tarafından geliştirilen GTK+ temelli masaüstü uygulamaları Vala ile geliştiriliyor. Bu yazılımlardan birini tanıyor olma ihtimaliniz çok yüksek, çünkü o Ubuntu’nun son sürümünde önemli bir öntanımlı program; Shotwell!
• Ubuntu, bildiğiniz gibi, bir sonraki sürümünde(11.04) GNOME’u öntanımlı masaüstü olarak kullanmaktan vazgeçerek kendi geliştirdiği, GNOME tabanlı, Unity masaüstünü kullanmaya karar verdi. Unity Vala ile geliştiriliyor ve şu ana kadar farkettiğim en önemli Vala projesi. Canonical’in, Ubuntu’nun geleceği için bu kadar önemli bir projeyi geliştirmek için Vala’yı tercih etmesi sanırım bu dilin geleceği hakkında sağlam bir fikir veriyordur.

Tüm bunlara rağmen sorunlar da yok değil.

• Adam akıllı bir dökümantasyon yok. Bu çok önemli bir sorun. Çünkü uygulama geliştirmek için bu dili öğrenmek isteyenler ya da benim gibi heveslilerin kapsamlı ve güvenilir bilgi alabileceği bir kaynak yok. İnternet üzerinde bölük pörçük bir takım tutoriallar ve kod örnekleri var. Onlar da yeterli değil zaten. Vala ile ilgileniyorsanız ve daha önceden programlama deneyimiziniz yoksa, özellikle C# ve Java’da, Vala’yı unutabilirsiniz. Kendinize başka bir dil bakın!
• Vala çok genç bir dil olduğundan internet üzerinde bu dili bilen insan sayısı çok çok az. Bu önemli çünkü Vala ile yazılım geliştirirken o adamlara ihtiyacınız olacak!
• Yine çok genç bir dil olduğu için bilinen IDE’ler ve Emacs, VIM gibi editörler tarafından pek desteklenmiyor. Gedit ve MonoDevelop için eklentiler var sanırım. Bu arada Valide isminde(cidden!) bir IDE’si var. O da Vala ile yazılmış.
• Esas olarak GObject ile sorunlar yaşayan GNOME geliştiricileri için geliştirildiğinden onunla herşeyi çok rahat bir biçimde yapamayabilirsiniz.

Artılar eksileri götürünce benim için oldukça ilginç, eğlenceli ve hoş bir dil kalıyor geriye. Şu an kısıtlamaları olsa da gelecekte nasıl bir noktaya evrileceğini kestirmek güç. Zaman gösterecek…

Vala hakkında daha fazla bilgi edinmek için dökümantasyon sayfasını inceleyebilirsiniz.

Hadron hiç kimsenin umrunda olmayan geleceksiz bir proje olabilir, ki sanırım öyle, ama henüz ölmüş değil. Yakın bir gelecekte de ölecek gibi durmuyor benim için.

Okulun bu dönem can sıkıcı olması ve benim kafa dinlemeye ihtiyaç duymam Hadron’un gelişimini yaklaşık 2-2.5 aydır durma noktasına getirdi. Ama elimde bir sonraki sürümün nihai planları var!

Düşüncelerimi temize çekmek adına ufak bir belge oluşturdum. Onu Google Docs üzerinde tutuyorum. Aslında Hadron’un wikisinde de tutabilirdim ama oraya yazmak pek keyifli gelmiyor bana…

Hadron Beta İçin Fikir Defteri dediğim bu belgede sistem genelinde yapmayı planladığım tüm geliştirme faliyetlerini özetledim. Onu sürekli güncel tutacağım. Yani içeriği her an değişebilir; yeni bilgiler eklenebilir ya da bazı maddeler çıkarılabilir.

Bu plana ne derece sadık kalacağımı ve yeni sürümün ne zaman çıkacağını hiç sormayın. İş zor, ama hiç ilgi görmeyen bir işe emek vermek çok daha zor! Süreç uzayabildiği kadar uzayabilir…

Belgeyi okumak için tıklayın.

Herşeye  bir ara vermek gerçekten iyiydi, size de tavsiye ederim.

Şu an tek canımı sıkan şey eski yazıların akıbetinin ne olacağı; bir çoğu güncelliğini yitirdi aslında. Belki bazılarını gözden geçirip tekrar yayınlarım… Şimdiden kestirmek güç.

Yakında yeni ıvır zıvırlarla dönerim…

Portage ağacını güncelledikten sonra aşağıdaki komutu verip dpkg ve debootstrap‘ı kuruyoruz. Bilmeyenler için anlatalım: dpkg, Debian’ın paket yönetim sistemidir. debootstrap ise dpkg kullanarak bir Debian sistem hazırlamayı sağlayan betiktir.

# emerge dpkg debootstrap

Bu komutla dpkg’yi derliyoruz.  İşin Gentoo bağlantılı kısmı bu kadar. Eğer zaten Debian kullanıyorum ben diyorsanız sadece debootstrap kurmanız yeterli olacaktır.  Bu noktadan sonrasında Gentoo yok, sisteminizde sadece Debian ya da bir türevi varsa rehberi izlemeye devam edebilirsiniz. Aşağıdaki komutu kullanın:

# apt-get install debootstrap

Debian altında da işimizi hallettikten sonra sıra kurulum yapacağımız yeri seçmeye geliyor. Ev dizininizdeki bir klasöre Debian kurabilirsiniz. Ya da kök dizinindeki herhangi bir yere… Ben açıp çatır çatır kullanırım diyorsanız disk bölümünü bağladığınız yeri debootstrap’a hedef göstermeniz gerekli. Ben ev dizinimdeki debian dizinine Debian GNU/Linux kuracağım birazdan

# cd ~
# mkdir debian
# debootstrap --arch=i386 lenny debian http://ftp.us.debian.org/debian

Son verdiğim komuta dikkat edin. Ben Debian’ın lenny kod adlı kararlı sürümünü kuruyorum. Eğer diğer sürümleri kurmak istiyorsanız onun kod adını yazın. 3. parametre olan debian ise kurmak istediğimiz dizinin adı. Yani siz ne seçtiyseniz o olacak. /mnt/sda7 gibi bir ifade de yer alabilirdi orada. Son parametre ise depo adresi. Güncel ve hızlı bir depo seçmeye özen gösterseniz iyi olur. --arch ifadesi ise sistem mimarisini gösteriyor. Ben i386 kurmayı tercih ediyorum. amd64 falan da seçebilirsiniz ama 32bit çekirdek ile chroot kullanamaz ve sistemi açamazsınız.

gnu ~ # debootstrap --arch=i386 lenny debian http://godel.cs.bilgi.edu.tr/debian
I: Retrieving Release
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://godel.cs.bilgi.edu.tr/debian...
I: Retrieving adduser
I: Validating adduser
I: Retrieving apt
I: Validating apt
I: Retrieving apt-utils
I: Validating apt-utils
I: Retrieving aptitude
.
.
.
I: Base system installed successfully.


Çıktılar böyle uzar gider…

debootstrap işini hallettikten sonra bizim işimiz bitmiyor. Şu an elimizde sadece bir Debian taban sistemi var. Üzerine bir sistem inşa etmeden önce onu adam etmemiz gerekecek. Çekirdek kurulumu ve bir kaç ayarlama gibi işlerimiz var. Tüm bunlardan evvel proc ve sys dosya sistemlerini bağlayalım.  Daha sonra chroot komutu ile yeni Debian’ımızı kullanmaya başlayalım. Bu noktada hala Gentoo kullanıyorum…

# mount /proc debian/proc -t proc
# mount sysfs debian/sys -t sysfs
# chroot debian /bin/bash

chroot’dan sonra gelen debian ifadesi değişebilir. Siz sistemi nereye kurduysanız oranın adresini yazın. /mnt/sda7 gibi. Şimdi şu komutu verin, ortam değişkenlerini güncelleyelim:

# source /etc/profile

Artık çekirdeği kurabiliriz. Aşağıdaki komutla bu yazıyı yazdığım gün kullanılan en güncel Debian Lenny çekirdeğini kuruyorum. Siz 2 yıl sonra bu yazıyı okuduğunuzda daha güncel bir çekirdek kuracaksınız ve dolayısıyla komutu değiştirmeniz gerekecek yeni çekirdek sürümüne göre.

# apt-get install linux-image-2.6.26-2-686

i686 mimarisine göre derlenmiş çekirdeği kurduğuma dikkat edin!

Meselenin ana hatları böyle, bundan sonrası için internetteki kaynakları incelemelisiniz. Geriye X.Org ve masaüstü ortamı kurulumu kaldı zaten.  chroot’dan çıkmadan önce root parolanızı mutlaka belirleyin! Eğer ayrı bir disk bölümüne kurulum yaptıysanız menu.lst dosyasında değişiklik yaparak yeni Debian’ı açabilirsiniz. Ayrıca kendinize güzel bir sources.list dosyası hazırlamanızı öneriyorum. Mümkünse non-free depoları kullanmayın!