Pozitif PC editor blogu

Öğleden sonra filan bilgisayarcı bir arkadaşa uğradım. Mağazası var, işleri sürekli büyütüyor. Şimdi amacı, "markalı" bilgisayar satmak. Kendi markasını yaratmaya çalışıyor.

Doğal olarak ilk muhabbet işlemciler üzerine döndü; AMD, 3 çekirdekli Phenom işlemcilerle nereye oturacak, yani Quad Core Intel Core’a kafa tutabilir mi, yoksa ancak Intel Core Duo ile mi kapışır, ya da yeni nesil 8 çekirdekli Intel işlemciler nasıl bir performans gösterecek…

Sonra ekran kartlarına girdik; uzun zamandır ilgilenmediğim bir konu olduğu için pek fikir yürütemedim. 8800 GT çıkıyormuş, hatta belli başlı firmalar bağlantıları yapmışlar, falan filan.

Elbette konu kaçınılmaz olarak Linux’a, Pardus‘a, Pozitif Linux’a ve elbette 32 bit-64 bit dağıtımların kıyaslanmasına geldi.

Arkadaşım iyi bir OEM dağıtım aradığını söyledi; "bulursan bana da haber ver" dedim. Azıcık şaşırdı; çünkü bu konu hakkında derin bir bilgisi yok. Özellikle driver desteğinden ve Linux dağıtımlarının açılış sürelerinin uzunluğundan yakındı. Fazla vaktim olsaydı, bir hayli anlatacaktım ama neredeyse üç gündür uyumadığımdan ve dışarıda çay içemediğimden eve dönmek zorunda kaldım.

OEM dağıtımdan kastı şuydu aslında: bir laptop ya da hazır/markalı/toplama bilgisayara kurduğunda, tüm donanımı algılayıp driver’ları yükleyecek, sorunsuz çalışacak ve sistem de hızlı açılacak.

Bu pek de olası birşey değil. Aslında olası; birileri 30-40.000 dolar verirse(!) bu işi yaklaşık 1 senede rahat rahat halledebilirim. Bu noktada biraz tipik problemlere bakmak gerek.

Dünyada OEM dağıtım hazırlayan vendor’lar var; bunlardan en bilineni şüphesiz Canonical, yani Ubuntu. Dell ile ballı bir anlaşma yaptılar. Şimdilik, ucuz Dell dizüstü ve masaüstü makinalar artık Ubuntu Linux ile geliyorlar. Hatta Micheal Dell’in kendisi de Ubuntu kullandığını söylemiş. Bilemem; tek bildiğim Micheal Dell’in de, Mark Shuttleworth’un da pazarlama dahileri oldukları.

SUSE (Novell) de, sanırım IBM (artık Lenovo) için dağıtım hazırlıyor. Herkesin derdi aynı; kurulum hızlı ve sorunsuz olsun, sistem hızlı açılsın…

Türkiye’de Armador Bilişim bunu Crea ve Datron markaları ile yapıyor. Ama şu sıralar çıkan Datron’lar Freedos yüklü geliyorlar. Eskiden Datron Turkix ile geliyordu, zaman zaman yerden yere vurulan ve adı hiç anılmayan Emre Sokollu’nun projesi. Pardus’tan seneler önce, Turkuaz’dan seneler sonra çıkmasına rağmen, ilk dağıtım Pardus’muş gibi bir hava var.

Gelecek Linux ise nedense bu alana girmedi, neden girmediğini de merak ederim. Doğrusunu isterseniz, nasıl ayakta kalabildiklerine de şaşıyorum. Herhalde bunda yapılan eski anlaşmaların önemli payı vardır.

Teorik olarak, sabit bir bilgisayarı (yani donanım aynı kalacak) Linux ile Windows’tan çok daha hızlı açmak, hatta masaüstünü bile daha hızlı çalıştırmak mümkün. Üstelik, bunu Attansic gibi ethernet sürücüsü yüklenirken ıslık çalan kernel modülleri ile başardım. Ama en ufak birşeyi değiştirirseniz, sistem boot etmeyecek, kernel panic verecek.

Linux yüklü bir bilgisayarı hızlı açmak için yapılması gereken bir dizi iş var. Sağdaki soldaki iddiaların aksine, InitNG, Upstart (artık Ubuntu ile standart geliyor) gibi init sistemleri mucize filan yaratmıyor. Bazı akıldışı rakamlar veriliyor ama, bu sayılar başlangıçta birçok servisin başlatılmamasından kaynaklanıyor. Eh, yazıcıyı taktığınızda çalışmıyorsa, bluetooth servisini elle başlatıyorsanız, bunun hiçbir kıymeti yok. Çünkü saydığım şeyleri Windows ve Mac OS X zaten yapabiliyor otomatik olarak. Kısacası, bunlar gerçek hayatta işe yaramayan basit hilelerden ibaret.

Hızlı açılan sistem için, basit olarak şunlar gerekli:

-Gereksiz tüm fazlalıkları atılmış ve doğru şekilde derlenmiş minik bir kernel. Eğer sabit bir sistemi 1-1.2 MB üzerinde bir kernelle açmaya çalışıyorsanız, bunu bir OEM Linux dağıtıcısı olarak yapıyorsanız, siz bu işi bilmiyorsunuz.

-Bunu embedded sistemlerde yapıyorum, OEM sistemlerde de yapmak mantıklı geliyor: kernel çıktılarını ekrana basmamak. 1 saniyeye yakın faydasını gördüm (sisteme bağlı olarak)

-Bazı log servislerini kapatmak. Bu hem daha hızlı bir masaüstü, hem daha iyi açılış süresi demek.

-Hızlı bir dosya sistemi. Tercihim Ext2 olur. Şu an bütün disklerim, sistemin bulunduğu partition hariç, XFS.(Son baktığımda XFS’i kernele gömülü olarak derleyemiyorsunuz, bu yüzden sistemi XFS bir partitiondan açmak olası değildi) Bazılarında bir ReiserFS fanatikliği olsa da, inanılmaz derecede yavaş.

-Burası en önemli kısmı: son derece iyi optimize edilmiş bir initramfs. Eğer OEM bir Linux dağıtımı yaptıysanız ve initramfs 4 MB’dan büyükse, initramfs’in ne olduğu hakkında bile bilginiz yok! 2.5-3.5 MB arası ise daha yolunuz var. Çoğu sistemi 2 MB civarı initramfs ile açmak mümkün. Bu aşamada çok zaman kaybı oluyor, çünkü CPIO arşivi olan initramfs’i açmak en iyi işlemciyi bile süründürüyor (boru değil, neredeyse 3-3.5 kat sıkıştırma var ve bahsettiğim dosyaların çoğu kolay sıkışan metin bazlı dosyalar değiller)

-Aşırı optimize edilmiş init scriptleri. Burası da mayın tarlası; ama aynı zamanda optimize edilmiş bir Linux sisteminde bile en az 5-6 saniye kazanabilirsiniz.

-"Hardcore" diyebileceğim compiler switch’ler ile, minimum yeterlilikte derlenmiş bir busybox ya da muadili. Şansınız varsa, 1 saniye kazanabilirsiniz.

-Elbette X ve startkde scirpti de, son aşamada sistem açılışının hızını etkiliyor.

Daha abartılı yöntemler de var; bunlardan biri LinuxBIOS. Linux kernelini BIOS’a yazıyorsunuz. Yalnız boyut sınırlaması dışında, desteklenen anakartların sayısı da çok ama çok az. Sadece embedded X86 geliştiricileri için önerebileceğim, sofistike, zor ve sorunlu bir uygulama.

Gelgelelim, üzerinde Ubuntu çalışan Dell dizüstü ve masaüstü makineleri çok merak ediyor ve incelemek istiyorum; çünkü yapılan optimizasyon düzeyini merak ettim. Henüz gerçek anlamda belli bir donanım platformu için optimize edilmiş bir dağıtım da görmedim.

Bu konuya daha sonra devam edeceğim ve özellikle 32-64 bit konusuna biraz değinmek amacındayım. Merak ettiklerinizi yorum olarak yazarsanız, ikinci yazıda bu konulara ağırlık veririm ve daha yararlı olur.

Popularity: 7% [?]

Bu Yazıyı Paylaşın

Gece KDE4′ü compile etmeye çalıştım; ancak "oh, tamam oldu" derken, kdebase’de hatalar meydana geldi.

Bunun üzerine, KDE 4′ü denemek için OpenSUSE tabanlı live CD’yi indirmeye karar verdim.

Öncelikle, KDE4′de çok önemli bazı mimari değişiklikler olduğunu kısaca açıklamakta fayda var. Bunların bir kısmı, halen sürümde olan KDE 4 Beta 2′de yoklar. Örneğin, icon cache özelliği. icon cache ile, tüm uygulama simgeleri merkezi bir dizinde tutulacak ve örneğin SVG tabanlı simgeler bir kez pixmap formatına çevrildikten sonra, bu dizinden yüklenerek kullanılacaklar. Eğer yüksek bir RAM’e sahipseniz, uygulamalar simgeleri RAM’de tutacaklar. Bu çok iyi bir haber; çünkü Windows Explorer ile KDE’yi kıyasladığımızda, KDE 3.x serisinde simgelerin sinir bozucu derecede yavaş yüklendiklerini görüyorduk. Tekrar hatırlatayım; bu özellik henüz beta sürümünde yok. Google summer of code programınca desteklenen icon cache, önemli bir yol almış olsa da, muhtemelen 4.1 sürümüyle birlikte gelecek. Bunun anlamı şu; 11 Aralık’ta çıkacak kararlı KDE 4.0′ı kuranlar bile, icon cache özelliğine henüz kavuşamayacaklar.

Şimdi kısaca KDE4 ile gelecek bazı anahtar teknolojilere bakalım:

QT4.x

Trolltech’in geliştirdiği ve daima KDE’nin temel taşı olmuş QT kütüphanelerinde önemli mimari değişiklikler var. Trolltech ve KDE geliştiricileri, QT tabanlı programların yeni kütüphaneler sayesinde %20 civarı daha hızlı çalışacaklarını söylüyorlar. Aslında, bu değişikliklerin görünen kısmı. Windows’a da çok uzun süredir göz kırpan Trolltech, yeni kütüphanelerle çok daha taşınabilir QT tabanlı yazılımlar geliştirilebilmesini sağlamak amacında. Nitekim, artık KDE’nin bile Windows üzerinde çalışmasının "rivayet" olmaktan çıkıp, gerçek olacağı söyleniyor. Genel olarak bakarsak, bunun Linux’un masaüstünde yayılması açısından önemi büyük. Örneğin, Linux’a geçmeyi planlayan şirketler, Windows üzerine KDE kurarak bu geçişi kullanıcılar açısından daha "acısız" gerçekleştirebilecekler.

Bunun dışında, QT ve Plasma’da iç içe geçen bazı görsel efektler var; örneğin seçilen linklerin hafifçe parlamaları gibi.

Plasma

Kullanıcı açısından gerçek bir devrim yaratacak yeni altyapının adı Plasma.

Plasma, pekçok yeni özellik getiriyor. Bunlardan ilki, widget’lar. SuperKaramba’dan ve Apple Mac OS X’den bidiğimiz widget’lar, masaüstüne yerleştirebileceğiniz küçük program parçacıkları. Örneğin, RSS beslemelerini gösteren bir widget’i masaüstüne koyduğunuzda, artık Akregator gibi programa ihtiyaç duymadan, masaüstünden bu beslemeleri takip edebiliyorsunuz.

Altyapı olarak SuperKaramba için yapılmış widget’lar ilk aşamada sorunsuz çalışacaklar; ancak Plasma ekibi Mac OS X Dashboard, hatta Opera tarayıcısı için yazılmış widget’ları bile KDE 4 ile uyumlu hale getirmeye çalışıyor. Kısacası, artık birçok programı çalıştırmak yerine, widget’lar aracılığıyla çıktılarını masaüstünden takip edebileceğiz. Buna bir kez alışınca, bilgisayar kullanma hızımızın ve verimimizin büyük ölçüde artacağını söylemek mümkün.

Phonon

Yeni çokluortam API’si. Aslında burada kullanıcının direk fark edeceği bir değişiklik yok-bu API’ler sayesinde programcıların işi son derece kolaylaşacak. Örnek vermek gerekirse, Phonon sayesinde, bir pencere içinde video oynatmak istiyorsanız, Xine, Mplayer ya da GStreamer motorlarından hangisini kullanacağınıza karar vermenize gerek kalmıyor. Phonon API’leri, daha alt düzey işlemleri basitleştirerek size sadece görevleri tanımlama gibi işlemleri bırakıyor. Bunun iyi yanı şu: QT kütüphanesi kullanarak bir program yazdığınızda, aynı program Phonon API’lerinden faydalanarak her işletim sistemi için farklı motorları tarama gereksinimini ortadan kaldırıyor. Sözgelimi, KDE/Linux üzerinde çalışan programınız Xine kullanırken, aynı program Windows üzerinde çalıştığında Media Player motorunu kullanıyor. Bunu siz tanımlamak zorunda değilsiniz; Phonon sistemle "konuşarak" kendi karar veriyor.

Solid

Bu da, aynı Phonon gibi, kullanıcıya değil, geliştiriciye yarayan bir özellik. KDE4′ü derlemeye çalışırken HAL, Bluetooth ve Network Manager ile "konuşabildiğini" gördüm ama, iddialara göre, Solid sayesinde tüm donanıma tek bir API sayesinde hükmedebileceksiniz.

Gerek Phonon, gerek Solid, aslında Windows’ta yıllardır bulunan DirectX gibi abstraction layerlar ile aynı işi yapıyor. Kısa vadede kullanıcılar bu yeni API’lerin nimetlerini göremeyecekler; -zira bu API’leri kullanan yeni sürümlerin çıkmasını beklemek gerek- ama uzun vadede program geliştirme çok kolaylaşacağı için -en azından eskiye göre!- çok daha kaliteli GNU/Linux programları görebileceğiz. Zaten Windows’un oyun alanındaki egemenliği de, DirectX’in grafik programlamayı çok ama çok büyük oranda kolaylaştırması ile oldu.

Telepathy / Empathy / Decibel

Bu API’ler sayesinde, iletişim protokolleri kullanıcı ve programcılar için daha "şeffaf" hale gelecekler. Decibel, bunların arasında en uzun mesafe katetmiş olanı; Telepathy ise freedesktop.org ve Ubuntu tarafından üzerinde ağırlıklı durulan bir proje. Decibel, KDE 4.1 ile gelecek, diğerlerinin durumu ise belirsiz diyebiliriz.

Kross

Kross, bir script altyapısı. Kendi başına bir dil değil; Ruby, Phyton, Falcon ve ECMAScript (eski Javascript) gibi diller için yazılan scriptlerin şeffaf olarak çalıştırılmasını sağlayacak. Herhalde artık Kommander scriptleri yerine Kross scriptleri göreceğiz; hatta zaman içinde Perl scriptleri bile Kross destekleyen dillerle yazılarak sistem bakımı-yönetimi daha kolay ve merkezi bir hale gelecek.

Compositing

Composite eklentisi yepyeni ve bomba gibi bir şekilde dönüyor! XGL-AIGLX gibi efektler, artık KDE içinde entegre olarak gelecekler. Şimdiye kadar gördüğüm demolar çok etkileyici. Bu projelerden kod alındığı zaten açıklandı, ancak KDE takımı tarafından yapılanlar çok açık değil. Hemen hemen tüm Compiz efektleri şu an KDE içinde entegre vaziyette, olmayanlar da planlama aşamasında.

Popularity: 8% [?]

Bu Yazıyı Paylaşın

Hani hayatında tek satır kod yazmamış adamlar, “kardeşim açık kaynak, kodu aç bak hemen anlarsın” diye Linux forumlarında sallarlar ya (kod yazmış olsa onu demez zaten!) bu meseleye uzun süredir takılmıştım.

Zaman zaman “kodu açıp bakıyorum”. En son xrandr’ın koduna baktım; çok şahaneydi tadından yiyemedim.

Doğrusu, çoğu açık kaynak kodlu projeden çok daha okunur bir koddu.
Fakat, açık kaynak kodlu projelerin çok ciddi bazı problemleri var. Bunlardan biri, programcıların “zeki görünme” çabası. Böyle bir durum henüz bizde yok. (Kod yokki üstüne konuşup yorum yapalım!). Dünyada da fazla var diyemem; ama çok ciddi projelerde bile bazı sivriler çıkıp “ineğe bak, öle mi yazılır lan o kod” diye ahkam kesiyor. Dolayısıyla, programcılar daha zeki görünmek için acaip karmaşık şeyler yazıyorlar. Programlama dillerinin çoğu, çok basit bir işi çok karmaşık göstermenize izin verecek esnekliğe sahipler; olmadıkları zamanlarda bile birileri öyle göstermenin yolunu kolayca bulabiliyor.

Gereğinden karmaşık yazmanın sadece bu kadar basit bir nedeni olmadığını düşünüyorum.Örneğin, bir sürücü kodunu ne kadar karmaşık yazarsanız, kodu açmanız durumunda rakipleriniz ne yaptığınızı anlayıp kendi ürünlerine uyarlamakta o kadar gecikirler. Yani işin biraz da maddi yönü sözkonusu. Bugün Çin, Hindistan gibi ülkelerde merdiven altı kart üreten ve oturup sürücüsünü de kendisi yazan adamlar var. İnanması güç ama gerçek.

Açık kaynak kodlu yazılımın bir diğer düşmanı da, kullanıcı ve geliştirici açısından, yetersiz dökümantasyon. Artık ciddi projelerin çoğunun yeterli dokümantasyonu mevcut. Hem geliştirici, hem de kullanıcı için. Öte yandan, örneğin KDE projesi için çok ama çok ciddi kaynak sıkıntısı var.  Örneğin, yapılandırma dosyalarındaki hangi ayarın ne işe yaradığını anlatan tek sayfa yazı bulamazsınız. Bazı basit ayarlarla ilgili bilgi var; ama açıkçası Pozitif Linux’da resmen reverse engineering yaptım. Bu esnada, elimde KDE ile ilgili ciddi bir doküman kaynağı da oluştu; hatta üşenmeyip masaüstünde bunun için basit bir WIKI bile oluşturdum; ama defterler hala duruyor:)

Compiler ya da Interpreter’lar çok zeki değildir. Çok basit ama farkı çok somut görebileceğiniz bir örnek vereyim: örneğin, 1′den 100′e kadar olan sayıları bir For döngüsü içinde toplamak yerine, sırayla toplarsanız, kodunuz çok daha hızlı çalışır. While kullanırsanız, for’dan da yavaş bir sonuç alırsınız. Bazen, bazı dillerle gelen hazır kütüphaneler de ayağınızı kaydırır; örneğin Python ile sistem bilgilerini API aracılığıyla almak, shell’den komut çalıştırıp -örneğin lspci- çıktısını almaktan genelde daha uzun sürer.

Kısacası, çoğu özgür yazılımın giderek özgürlükten uzaklaştığını düşünüyorum; sanki kodu giderek karmaşık hale getirerek, çok az insanın anlayabileceği, “elitist” bir yaklaşım içine giriyorlar. Kod içindeki açıklamalar yok olmaya başlıyor, kodlar uzuyor, kimi zaman bloklama yapmak gibi zahmetlere filan bile girilmiyor. Üstelik, bu çok “hince” bir yaklaşım. Çünkü hem “kodlar açık işte” diye insanları çekiyorlar, sonra da anlamasınlar diye ekstra çaba harcıyor, hatta muhtemelen programların olması gerektiğinden daha yavaş çalışmalarına neden oluyorlar.

Popularity: 4% [?]

Bu Yazıyı Paylaşın