Colordiff ile diff çıktılarını renklendirin

Svn ile çalışırken sıklıkla yaptığımız şeylerden birisi çalışma dizinimizde değişiklik yaptığımız dosyaların orjinal halleri ile değişiklik yaptığımız halleri arasındaki farkı gözden geçirmek (özellikle değişikliklerimizi depoya commit etmeden önce svn st ve svn diff komutlarını son bir defa daha çalıştırmak kazanılması gereken iyi bir alışkanlık). svn diff komutu hiç bir renklendirme yapmadığından, bu komutun çıktısının okunabilirliğini de  düşük buluyordum. svn diff‘in çıktısını svn diff | vi - komutu ile vim’e yönlendirerek, vim’in standard girdiden aldığı bu veriyi daha okunabilir sunmasından dolayı yaptığım değişiklikleri bu şekilde kontrol ediyordum. Ancak bu komutun ardından da her defasında editörü kapatmak zorunda kalmanın pek de verimli bir çalışma şekli olmadığını itiraf etmeliyim. Bir de colorsvn paketi var ama o da sadece dosyaların durumlarındaki değişiklikleri renklendiriyor, mesela svn up dediğimizde eklenen, değişen, silinen dosyaları renklendiriyor, diff çıktısı yine siyah-beyaz.

Herşey okunabilirlik için diyerek, svn altında çalışırken dosyalarda yaptığımda değişiklikleri standard çıktıda renklendirerek gösterecek bir şeyler ararken colordiff ile karşılaştım. diff komutu için Perl kullanılarak yazılmış bir ara yazılım (wrapper) olan colordiff, diff çıktılarını bize daha şirin halde gösteriyor. Kullanımı da oldukça basit: Herhangi bir diff komutunun çıktısını pipe ile colordiff’e yönlendiriyoruz. Örneğin:

diff dosya1.py dosya2.py | colordiff

ya da

svn diff pspec.xml | colordiff

svn diff ile colordiff kullanımı

Ekran çıktısında da gördüğünüz gibi değişiklik yapılan dosya adı sarı, eklenen satırlar mavi, çıkarılan satırlar da kırmızı ile renklendirilmiş. Bu sayede hangi dosyaların değiştiğini, dosyalarda ne gibi değişiklikler olduğunu daha rahat görebiliyoruz. /etc/colordiffrc ayar dosyasını düzenleyerek, dosyalar üzerinde gerçekleştirilen değişiklikleri ifade eden renk şemalarını istediğimiz gibi değiştirebiliriz. Kullanıp faydalı bulunca, paketini de yapayım dedim ve colordiff bugün geliştirme (devel) deposuna girdi.

Özellikle SVN ile çalışırken çok faydalı olacak bu araç için, daha pratik olması açısından, ~/.bashrc dosyasına, paketin README dosyasındaki örnekten yola çıkarak, aşağıdaki fonksiyonu ekledim. Bu sayede çalışma dizinimizdeki değişiklikleri tek bir komut ile listeleyebilmemiz mümkün:

svndiff() { svn diff "${@}" | colordiff }

Tabi değişikliklerin hemen etkin olabilmesi için yukarıdaki komutun ardından

source ~/.bashrc

komutunu çalıştırmayı unutmayalım.

pardus kategorisine gönderildi | , , ile etiketlendi | 1 yorum

Pardus Serüveni…

Daha üniversitenin ilk yıllarında, hatta ilk aylarında, geliştirici ekipten S. Çağlar Onur ve Ali Erdinç Köroğlu’nun katılımıyla gerçekleştirilen bir etkinlikle Pardus’un geliştirilme sürecini başından itibaren takip etme imkanımız olmuştu. Takip eden Mayıs ayında da aynı heyecanla ODTÜ’deki Özgür Yazılım Şenliği‘ne katılmıştık Çanakkale’den bir otobüs dolusu öğrenci olarak.

Bunu izleyen dönemlerde Pardus için daha çok kullanıcı ve dolayısıyla tüketici konumundaydım. Ta ki, 2009 yazına kadar. Özgür yazılımı yaygınlaştırmak ve desteklemek amacıyla öğrencilere staj imkanı sağlayan Pardus’ta 2009 ağustos ayında staj yaparak hem geliştirici ekibi hem de projeyi daha yakından tanıma fırsatını elde ettim.

Pardus’a katkı verme süreci, Necdet Yücel‘in 2009 temmuzunda duyurduğu ve takip eden ekim ayında kendisinin danışmanlığında başladığımız “Pardus’un 64-bit Mimarisine Port Edilmesi” bitirme projesi ile devam etti. Ulusal dağıtımımızın 64-bit mimarili işlemciler üzerinde de koşabilmesi için gerçekleştirdiğimiz çalışmalar, TÜBİTAK ve Çanakkale On Sekiz Mart Üniversitesi arasında imzalanan işbirliği protokolü ile Pardus tarafından da resmen desteklenerek, Pardus’un kullanabileceği bir ürün halini aldı. Ayrıca bu çalışmaları bir düzineye yakın üniversitede çeşitli etkinliklerde anlatmaya çalışarak, yaptığımız işin benzeri üniversite-Pardus işbirliği çerçevesinde, başka projelerin de teşviki olabileceğini ümit ettik, hala ediyoruz.

Ve, 21 haziranda On Sekiz Mart Üniversitesi, Bilgisayar Mühendisliği bölümünden mezun olarak lisans eğitimime noktayı koymuş oldum. Geçen Eylül ayında da TÜBİTAK/UEKAE’de Pardus geliştiricisi olarak işe başladım.

Çanakkale hakkında da birkaç şey söylemeden edemeyeceğim. “Özgür yazılımcının yeşerdiği topraklardan biridir ÇanakkaleNecdet Hoca‘mızın deyimiyle. Projeye ve özgür yazılıma hatırı sayılır katkı vermiş ÇOMÜ‘lü abi ve ablalarımızın yaptıklarını duymak, onları takip etmek her zaman heyecanlandırmıştı bizi. Tıpkı daha öncekiler ve Pardus 64-bit’te olduğu gibi, ÇOMAK projesinin de duyurulması ile beraber ÇOMÜ’de bu geleneğin daimi olacağından emin olmak gurur verici.

Kategorilenmemiş kategorisine gönderildi | Yorum bırakın

Java Applet Policy

Java eklentisi, tarayıcılarda appletler çalıştırılırken kullanıcının sistem kaynaklarına erişimi güvenli kılmak için Security Manager kullanıyor. Bu özellik ile zarar verici içeriğe sahip ya da güvenilir olmayan kaynaklardaki appletlerin bilgisayarınıza erişimi kontrol altına alınıyor.

Bu konuyu araştırma ihtiyacı ise Yapay Zeka ve Uzman Sistemler dersinde geliştirdiğimiz bir oyun projesi üzerinde çalışırken doğdu. Proje hakkında kısaca bahsetmek gerekirse, projemiz iki kişilik bir strateji oyunu. Her takımın 4 farklı tipte 8′er adet kahramanı bulunuyor ve her karakter için farklı hareket ve savaşma yetenekleri tanımlanıyor. Örneğin; ‘Ok’ karakterimiz sağ-sol-yukarı-aşağı yönlerde 1 birim ilerleyerek, etrafındaki yine aynı yönlerdeki 4 kare birimlik çember içerisindeki düşman karakterlerin canlarından 4′er puan düşürebiliyor. Hamlelerin minimax algoritmasının gerçekleştirimi ile hesaplandığı projede değerlendirme fonksiyonu olarak takımdaki tüm kahramanların rakip takım kahramanlarına olan uzaklıkları toplamı ile takımların kalan toplam güçlerinin farkı kullanıldı.

Oyunu oynayabilmek için ise bir sunucuya bağlanılıyor ve yapılan hamleler sunucu tarafından kontrol ediliyor. İşte bu noktada sunucuya bağlanma ve appletlerin karşılıklı çalıştırılabilmesi için ya appletlerimizi güvenli olarak imzalamamız gerekiyor ya da policy dosyaları tanımlayarak appletin kaynağını belirtip, o kaynaktan çalışan applete sistemimiz üzerinde yapabileceği işlemler için izinler tanımladığımız bir kayıt oluşturuyoruz. Eğer tanımlamazsak Java konsolu bizi şöyle bir hata ile karşılıyor:


Biz projemizde appletler için policy kayıtları oluşturmayı tercih ettik ve kısaca bunun nasıl yapıldığından bahsedeceğim.

Policy kaydı düz metin dosyalarıdır ve tanımlanan kuralları herhangi bir metin editörüyle açıp görüntüleyebilirsiniz. Basit bir policy kaydının içeriği şöyledir:

grant codeBase "http://www.example.com/projects/applets/applet1/" {

 permission java.io.FilePermission "/home/metin/-", "read";

 permission java.io.FilePermission "/home/metin/-", "write, delete";

};
grant codeBase "file:/home/metin/NetBeansProjects/-" {

permission java.util.PropertyPermission "user.home", "read";

};

İlk kayıt dosyası http://www.example.com/projects/applets/applet1/ kaynağında yer alan kodlara, sistemizde yolu

/home/metin

olarak verilen kullanıcı dizinine (ve onun alt dizinlerine) erişim (okuma, yazma ve silme) hakkı veriyor. İkinci kayıt dosyası ise kendi bilgisayarımızda yer alan

/home/metin/NetBeansProjects

dizini altındaki tüm kodlara kullanıcı dizini için okuma yetkisi veriyor.

Bu kayıt dosyalarını oluşturmak için Java ile beraber gelen, grafik arayüzüne sahip

policytool

aracını kullanmak hem zaman kazandırıyor hem de söz dizimi hataları ve bunlardan kaynaklanan hatalar ile uğraşmaktan bizi kurtarıyor. Konsoldan

policytool

komutunu verdiğimizde bizi aşağıdaki ekran karşılıyor:

Add Policy Entry yardımıyla yeni bir policy girdisi oluşturuyoruz. Edit Policy Entry varolan policy girdilerimizi düzenlememizi sağlarken, Remove Policy Entry seçeneği de, adından anlaşılacağı gibi, listelenen policy girdilerinden istediğimizi silmemizi sağlıyor.
Şimdi hızlı bir şekilde bir applet uygulamasına izinler tanımlamak için yeni bir policy girdisi oluşturuyoruz. Add Policy Entry seçeneğine tıklayınca şu ekran ile karşılaşıyoruz:


CodeBase satırı çeşitli izinler tanımlayacağımız kodların kaynak adresini temsil ediyor. Burada tanımlanan yol internet üzerinde yer alan bir kaynak adresi olabileceği gibi sistemizde yer alan bir dizini de gösterebilir.

AddPermission seçeneği ile bu yeni policy kaydımız için yeni izinler tanımlayabiliyoruz. Bu noktada farklı izin tipleri olduğundan ve her izin tipi için de çeşitli seçenekler tanımlandığını belirtmek istiyorum. Bunları kısaca açıklamak gerekirse:

  • Permission : Önceden tanımlanmış izinlerin listesi.

    FilePermission

    ,

    SocketPermission

    ,

    NetPermission

    vb. Tüm izinleri kapsayan

    AllPermission

    da tanımlıdır.

  • Target Name: Seçtiğimizi izinlere yönelik öntanımlı hedefler listelenir. Örneğin;

    RuntimePermission

    için

    exitVM

    ,

    stopThread

    ,

    getstackTrace

    seçenekleri tanımlıdır.

  • Actions: Seçilen izin tipine özel tanımlanmış, yapılabilecek eylemlerin listelendiği seçenektir. Örneğin; dosyalar ile ilgili izin olan

    FilePermission

    için, dosyaları okuma, dosyaya yazma, dosyayı çalıştırma, dosya silme eylemleri tanımlanmıştır (

    read

    ,

    write

    ,

    delete

    ,

    execute

    ).

Şimdi projemize geri dönelim. İstemcilerin sunucu ile iletişim kurabilmeleri için projemizin yer aldığı dizini gösterip, bu dizinde yer alan kodlara

SocketPermission

izni ve bu izin için

accept

,

connect

,

listen

,

resolve

eylemlerini gerçekleştirebilme hakkı tanımlıyoruz. Bu izinleri içeren policy kaydımızı da ev dizinimizde

.java.policy

şeklinde kaydederek uygulamamızı tarayıcı üzerinde istemciler birbiriyle iletişim kuracak şekilde çalıştırabiliriz.

Kategorilenmemiş kategorisine gönderildi | Yorum bırakın

II. Pardus Günleri

Pardus Tanıtım ve Geliştirme Günleri’nin ikincisi bu sene Bilkent Üniversitesi‘nde düzenlendi.

Özgür yazılım ve Pardus dolu sunumların yer aldığı etkinlikte, Tübitak/UEKAE ekibi Pardus teknolojileri ve karşılaştırmalı Pardus ile katılımcıları Pardus hakkında bilgilendirirken, “Nasıl Pardus Geliştiricisi Olunur ?” ile bu özgür yazılım hareketinin aktif bir parçası olma metodlarından bahsettiler. Bununla birlikte yazılımları test etme ve Pardus’ta test süreçlerinin ele alındığı sunum ile bir diğer “Nasıl katkı veririm ?” sorusunun cevabı verilmeye çalışıldı.

“Özgürlük İçin” ekibi ise Pardus’ta topluluk süreçlerinin ele alındığı sunumu ile özgür yazılım camiasında topluluk olmanın önemini anlattılar.

Meltem ve Mete ile beraber biz de “64-bit Pardus’un Öyküsü” başlıklı bir sunum gerçekleştirdik. Akademik Bilişim ve Bilmök etkinliklerine nazaran daha az teknik olmasını planladığımız bu sunumda, daha çok bu özgür yazılım projesinin nasıl ortaya çıktığı ve üniversiteler ile Pardus’un ortak bir çalışma ve işbirliği içerisinde nasıl yer alabileceği hakkında fikir vermeye çalıştık. Projenin ortaya çıkışı, karşılıklı görüşmeler ve çalışmaların ilerleyişinden bahsettiğimiz bu etkinlik ile benzeri projeleri teşvik edebilmeyi umuyor ve yakın gelecekte daha fazla işbirliği örnekleri görmeyi ümit ediyoruz.

Bu etkinlik için sınav vb. sorumlulukları içerisinde koşturarak, uykusuz kalıp özveri ile çalışan Bilkent ekibine teşekkürler.

Bir sonraki özgür yazılım etkinliğinde görüşmek üzere …

Kategorilenmemiş kategorisine gönderildi | Yorum bırakın

Akademik Bilişim ’10 İzlenimleri

Bu yıl on 12. si düzenlenenen Akademik Bilişim Muğla’da gerçekleştirildi. 3 gün boyunca Muğla Üniversitesi’nde özellikle üniversitelerdeki bilgi teknolojileri üzerine ilgili konular hakkında seminer, sunum, açık oturum benzeri birçok etkinlik gerçekleştirildi.

3 gün süren etkinlikler boyunca Meltem ve Mete ile beraber bizim de bir sunumumuz oldu. Ekim ayından itibaren üzerinde çalıştığımız Pardus’un 64-bit mimariye port edilmesi sürecini elimizden geldiğince anlatmaya çalıştık. Bir daha ki sunum, bu sene 26-27-28 şubatta Konya’da düzenlenecek olan Bilmök 2010′da artık :)

Katıldığım etkinliklerden akılda kalan bazı notları aktarmak istiyorum. Özgür yazılımın kamu kurumlarında aktif olarak kullanımı ile ilgili katıldığım açık oturumda üniversitelerde özgür yazılıma geçiş konuşuldu. Pek eğlenceli yöntemlerden bahsedildi; özellikle Adıyaman Üniversitesi bu konuda oldukça etkileyici ve yaratıcı hikayeler paylaştı :) Geçiş sürecinde ise karşılaşılan en ciddi problem bireysel dirençti; insanların alışkanlıklarını değiştirmeye çalışmak ve özgür yazılımla tanıştırıp kullandırmaya teşvik etmek gerçekten özveri isteyen bir iş.

Yine aynı etkinlikte üniversitelerde yapılan birçok işin kesin kurallarla belirlenmiş olması, dolayısıyla bunların neredeyse birbirinin aynı olmasına rağmen, her üniversite kendi başına aynı sorunu tekrar tekrar çözmeye çalışıyordu. Ve bunların birçoğundan ‘özgür yazılım’ olarak bahsedilmesine rağmen, neden aynı şeyler yeni baştan yazılıyordu. Oysa bunları herkesin erişebileceği bir yerde paylaşarak, bu iş için harcanan emeği daha başka işler için ya da bu işin daha da geliştirilip daha iyi hale getirilmesi için harcamıyorduk? Bu görüşler doğrultusunda çözüm için yakın bir gelecekte üniversitelerin bu konuda bir araya gelerek ortak karar alması ve bununla ilgili uygulamaları gelebilir.

Bir diğer eğlenceli sunum da Bilgi Üniversitesi’nden Chris Stephenson hocadan geldi : “How should we teach programming – How we shold not teach programming ?” Programlamaya farklı açılardan bakan ve bunu ilginç üslubu ile aktaran Chris hoca, programlamayı öğretmek üzerine konuştu. Bilgisayar programlamayı anlatan kitapların üç aşağı beş yukarı birbirinin kopyası olmasından bahsetmesi ve özellikle asıl öğretilmesi gereken konuların kitaplarda “okuyucuya bırakılması” da bir diğer tartışma konusuydu. Java programlama dili de sunum boyunca adından sıkça söz ettirdi.

Akademik bilişim hem bilgi hem de pek değerli dostlar edinme açısından yıl içerisinde kaçırılmaması gereken organizasyonlardan biri. Başta Mustafa Akgül ve Ethem Derman hocalar olmak üzere değerli insanlarla tanışma fırsatı bulduğum için de kendimi şanslı hissediyorum. Etkinliğin hazırlık aşamasını da düşündüğümüzde, bu müthiş organizasyonun hayata geçirilmesinde emeği geçen herkese buradan teşekkürler.

Kategorilenmemiş kategorisine gönderildi | Yorum bırakın

Akademik Bilişim ’10 İzlenimleri …

bu sene mugla da 12. si düzenlenen akademik bilişim etkinliğine Necdet Hoca, Meltem, Mete ile birlikte ”pardus’un 64bit mimariye port edilmesi” başlıklı konuşma ile katıldık.

konuşulan konulardan birisi de kurumsal olarak pardus’a göçtü. burada konuşulanları kısaca özetlemek gerekirse kurumların özgür yazılıma geçişinin en sancılı kısımları :
- bireysel direnç
- yeni bir şey öğrenme istememe, alışkanlıkların değiştirilememesi
- yeterli destek alamama

* 64 bitte veri adres yol genişlikleri

Kategorilenmemiş kategorisine gönderildi | Yorum bırakın

Pardus 64bit Kurulan CD Alfa

Kurumsal2 sürümünü baz alarak 64bit mimariye port etme çalışmalarını sürdürdüğümüz Pardus’un ilk kurulan CD alfa sürümü [1] adresinde yerini aldı. Öncelikle bunun bir geliştirici sürümü olduğu unutulmamalıdır. Hata ve isteklerin geribildirimleri ile daha da iyileştirilecek olan bu sürümü sırasıyla beta, RC ve final sürümleri takip edecek.

Kurulan CD’yi eğer sisteminiz üzerinde güvenli bir şekilde denemek için sanal makine kullanmayı tercih ederseniz, [3] deki yazıya bir göz atmak faydalı bilgiler sağlayabilir.

Pardus 64bit sürümünün geliştirme süreci ve çalışmalarımız hakkında tecrübelerimizi paylaşmak için, bu sene Muğla Üniversitesi’nde gerçekleştirilecek olan Akademik Bilişim-2010 etkinliğinde küçük bir seminerimiz olacak [4]. Oraya da bekleriz ;)

Gerek Pardus geliştirici ekibi gerek gönüllüler olmak üzere, çalışmalarımız sırasında yardımcı olan, özgür yazılıma gönül vermiş tüm arkadaşlara teşekkür ediyoruz.

[1] http://members.comu.edu.tr/nyucel/Pardus-C2-x86_64-alfa.iso
[2] http://members.comu.edu.tr/nyucel/Pardus-C2-x86_64-alfa.iso.SHA1SUM
[3] http://m-akdere.blogspot.com/2010/01/virtualbox-64-bit-host-uzerinde-64-bit.html
[4] http://ab.org.tr/ab10/ozet/177.html

Kategorilenmemiş kategorisine gönderildi | Yorum bırakın

Pardus64 üzerinde birkaç performans testi

Kurulabilir CD’sine doğru yol aldığımız Pardus64 üzerinde birkaç performans testleri yapmak istedik. Daha kök dosya sistemini (RootFS) çıkarmadan yaptığımız [1] adresindeki testlerin üzerinden oldukça zaman geçti ve o günden bu yana sisteme birçok bileşen eklenerek depodaki [2] paket sayımız 4 haneli rakamları buldu. Bu yüzden yeni bir test yapmak iyi bir fikir gibi geldi.

Verilerin imza ve şifreleme işlerini gerçekleştiren GnuPG ile ses ve görüntü mevzularında (özellikle format dönüştürme) pek yetenekli olan ffmpeg uygulamalarını test ettim.

Test ortamımdaki bilgisayarın şöyle özellikleri var:

* Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz

* 2.5 GB RAM

Uygulamaların sürüm numaraları da şöyle :

* ffmpeg-0.5.1_20091020-62

* gnupg-2.0.11-26

İlk testi ffmpeg ile 701 MB ‘lik .avi dosyasını .mpg formatına dönüştürerek gerçekleştirdim. Çevrilen dosyanın özellikleri:

$ ffmpeg -i input.avi

Seems stream 0 codec frame rate differs from container frame rate: 23.98 (65535/2733) -> 23.98 (24000/1001)

Input #0, avi, from ‘input.avi’:

Duration: 02:06:36.21, start: 0.000000, bitrate: 773 kb/s

Stream #0.0: Video: mpeg4, yuv420p, 528×288 [PAR 1:1 DAR 11:6], 23.98 tbr, 23.98 tbn, 23.98 tbc

Stream #0.1: Audio: mp3, 48000 Hz, 2 channels, s16, 128 kb/s

At least one output file must be specified

FFMpeg çalışma zamanı (sn):

$ time ffmpeg -i input.avi output.mpg


Bu çıktılar bize ffmpeg uygulamasının 64bit Pardus üzerinde 32bit Pardus’a göre %18 gibi bir oranda daha hızlı çalıştığını gösteriyor.

İkinci testi 687 MB’lik Pardus.iso dosyasını gnupg ile şifreliyerek gerçekleştirdim:

GnuPG Çalışma Zamanı :

$ time gpg –encrypt –recipient ‘Metin Akdere’ pardus.iso

Bu çıktılar ise bize GnuPG uygulamasının 64bit Pardus üzerinde 32bit Pardus’a göre %24 gibi bir oranda daha hızlı çalıştığını gösteriyor.

Sonuç şu ki; 64bit ile hem daha büyük bellek uzayına hem de gözle görülür bir performans artışına sahip oluyoruz; ama 64 bitte uygulamalar 32 bite göre iki kat hızlı çalışacak gibi bir durum yok :) Performansı etkileyen bir çok parametre var; işlemci mimarisi bunlardan sadece birisi. Çalıştırdığımız komutların veri bağımlılığı var, kontrol bağımlılığı var. Ne çok büyük bellekler, ne de çok güçlü işlemciler tek başına sistemin performansı üzerinde etkili değil; uygulamaların da sistemi en verimli kullanacak şekilde yazılmış olması gerekiyor. Daha önceki test çalışmamızda paralel programlanan uygulamaların gerçek bir performans farkı ortaya koyduğuna şahit olduk.

Pardus64 çalışmalarındaki son durumdan da bahsetmek istiyorum. Elimizde 1700 civarında 64bite taşınmış paket sayısı var. Sadece system.base ve system.devel’den oluşan kök dosya sisteminin ardından, kurulan CD için çalışıyoruz. Ayrıca, 64bite port sürecinde paketlere yapılan tüm değişiklikleri bir betikte toplama gibi bir çalışmamız da var. Bu sayede aynı depo ve farklı derleme çiftlikleri ile farklı mimariler için (şimdilik en azından 32/64 bit) paketler oluşturulabilecek diye planlıyoruz.

[1] http://nyucel.blogspot.com/2009/11/64-bit-pardusun-ilk-performans-test.html
[2] http://x86-64.comu.edu.tr

Kategorilenmemiş kategorisine gönderildi | Yorum bırakın

Kurulabilir CD’sine doğru yol aldığımız Pardus64 üzerinde birkaç performans testleri yapmak istedik. Daha kök dosya sistemini (RootFS) çıkarmadan yaptığımız [1] adresindeki testlerin üzerinden oldukça zaman geçti ve o günden bu yana sisteme birçok bileşen eklenerek depodaki [2] paket sayımız 4 haneli rakamları buldu. Bu yüzden yeni bir test yapmak iyi bir fikir gibi geldi.

Verilerin imza ve şifreleme işlerini gerçekleştiren GnuPG ile ses ve görüntü mevzularında (özellikle format dönüştürme) pek yetenekli olan ffmpeg uygulamalarını test ettim.

Test ortamımdaki bilgisayarın şöyle özellikleri var:

* Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz

* 2.5 GB RAM

Uygulamaların sürüm numaraları da şöyle :

* ffmpeg-0.5.1_20091020-62

* gnupg-2.0.11-26

İlk testi ffmpeg ile 701 MB ‘lik .avi dosyasını .mpg formatına dönüştürerek gerçekleştirdim. Çevrilen dosyanın özellikleri:

$ ffmpeg -i input.avi

Seems stream 0 codec frame rate differs from container frame rate: 23.98 (65535/2733) -> 23.98 (24000/1001)

Input #0, avi, from ‘input.avi’:

Duration: 02:06:36.21, start: 0.000000, bitrate: 773 kb/s

Stream #0.0: Video: mpeg4, yuv420p, 528×288 [PAR 1:1 DAR 11:6], 23.98 tbr, 23.98 tbn, 23.98 tbc

Stream #0.1: Audio: mp3, 48000 Hz, 2 channels, s16, 128 kb/s

At least one output file must be specified

FFMpeg çalışma zamanı (sn):

$ time ffmpeg -i input.avi output.mpg

Bu çıktılar bize ffmpeg uygulamasının 64bit Pardus üzerinde 32bit Pardus’a göre %18 gibi bir oranda daha hızlı çalıştığını gösteriyor.

İkinci testi 687 MB’lik Pardus.iso dosyasını gnupg ile şifreliyerek gerçekleştirdim:

GnuPG Çalışma Zamanı :

$ time gpg –encrypt –recipient ‘Metin Akdere’ pardus.iso

Bu çıktılar ise bize GnuPG uygulamasının 64bit Pardus üzerinde 32bit Pardus’a göre %24 gibi bir oranda daha hızlı çalıştığını gösteriyor.

Sonuç şu ki; 64bit ile hem daha büyük bellek uzayına hem de gözle görülür bir performans artışına sahip oluyoruz; ama 64 bitte uygulamalar 32 bite göre iki kat hızlı çalışacak gibi bir durum yok :) Performansı etkileyen bir çok parametre var; işlemci mimarisi bunlardan sadece birisi. Çalıştırdığımız komutların veri bağımlılığı var, kontrol bağımlılığı var. Ne çok büyük bellekler, ne de çok güçlü işlemciler tek başına sistemin performansı üzerinde etkili değil; uygulamaların da sistemi en verimli kullanacak şekilde yazılmış olması gerekiyor. Daha önceki test çalışmamızda paralel programlanan uygulamaların gerçek bir performans farkı ortaya koyduğuna şahit olduk.

Pardus64 çalışmalarındaki son durumdan da bahsetmek istiyorum. Elimizde 1700 civarında 64bite taşınmış paket sayısı var. Sadece system.base ve system.devel’den oluşan kök dosya sisteminin ardından, kurulan CD için çalışıyoruz. Ayrıca, 64bite port sürecinde paketlere yapılan tüm değişiklikleri bir betikte toplama gibi bir çalışmamız da var. Bu sayede aynı depo ve farklı derleme çiftlikleri ile farklı mimariler için (şimdilik en azından 32/64 bit) paketler oluşturulabilecek diye planlıyoruz.

[1] http://nyucel.blogspot.com/2009/11/64-bit-pardusun-ilk-performans-test.html

[2] http://x86-64.comu.edu.tr

Kategorilenmemiş kategorisine gönderildi | Yorum bırakın

Virtualbox : 64 bit host üzerinde 64 bit guest

Bu yazının asıl amacı kısa bir süre önce duyurduğumuz Pardus64′ü [1] sanal makineler üzerinde kullanmak isteyen kullanıcılara, bunu denemeden önce bilinmesi faydalı olabilecek bazı detaylar hakkında bilgi verebilmektir.

Sanallaştırma, kullandığımız işletim sistemi çalışıyor haldeyken aynı anda başka başka işletim sistemlerini de koşturmamızı sağlayan bir teknoloji. Çalışan tüm bu işletim sistemleri (guest) üzerinde koştukları bilgisayarın (host) aynı donanımını paylaşır. Performans ise donanım ile yakından ilgili. Sanallaştırma denilince akla ilk gelen uygulama Virtualbox olmakla beraber Xen, VMVare de diğer sanal makine uygulamaları arasındadır.

Pardus64′ü sanal makine üzerinde deneyebilmek için öncelikle işlemcinizin donanımı sanallaştırabilme özelliğini test etmeniz gerekiyor:

egrep ‘(vmx|svm)’ –color=always /proc/cpuinfo

Eğer, yukarıdaki komut bir çıktı veriyorsa işlemciniz sanallaştırma teknolojisini destekliyor. Sanallaştırmayı destekleyen işlemci modellerinin listelendiği [2] linki ziyatret edebilirsiniz. Bununla beraber Pardus64 için işlemcinizin 64 bit işletim sistemi koşturabilme yeteneğinin de olması gerekiyor. Bunu öğrenmek için aşağıdaki komut ile işlemci bayrakları arasında “lm” değerini arıyoruz:

grep ‘ lm ‘ /proc/cpuinfo

‘lm’ ‘Long Mode’ ifadesini belirtiyor, bu da işlemcinizin 64 bit olduğunun göstergesi oluyor.

Bu noktadan sonra 64 bit bir dağıtım üzerinde Virtualbox kurduktan sonra isterseniz sanal bir disk [3] oluşturarak isterseniz de tüm diskinizi sanal makineye göstererek [4] (daha önceden ayrılmış bir disk bölümüne Pardus64′ü yerleştirdiğinizi varsayıyorum) Pardus64 bulunan disk bölümünü boot edebilirsiniz. Unutmayınız ki 32 bit host üzerinde sanallaştırma teknolojisi ile sadece 32 bit guest koşturabiliriz; 64 bit hostlar üzerinde ise hem 32 bit hem de 64 bit guestler koşturabilmemiz mümkün.

Son olarak elinizdeki dağıtımın 32 bit ya da 64 bit çekirdek kullandığını “uname -m”komutunun çıktısından anlayabilirsiniz: x86_64 ise bol Pardus64′lü günler dileriz :)

[1] http://members.comu.edu.tr/nyucel/pardus-corporate2-rootfs-0.42.tar.bz2

[2] http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors

[3] http://www.virtualbox.org/manual/UserManual.html#storage

[4] http://www.virtualbox.org/manual/UserManual.html#rawdisk

Kategorilenmemiş kategorisine gönderildi | Yorum bırakın