red5, rtmp ve flash ile ilgili öğrendiklerim

uzun zamandır bloğumu ihmal ettiğimi farkettim, ve işin ilginci son 5-6 aydır red5 ile yatıp red5 ile kalkan bir insan olarak nedense hiç red5 ile ilgili bir girdi yapmamışım. öğrendiklerimi tek bir girdide toplayıp acısını çıkarayım dedim.

öncelikle rtmp açık bir protokol değil, dolayısıyla red5 bir tersine mühendislik ürünü, facebook'un bile red5 tercih ettiğini düşünecek olursak oldukça da başarılı bir ürün. bu arada adobe 2009 yılının ortasında rtmp belirtimlerini açacağını duyurmuş olmasına rağmen henüz açmadı.

rtmp bağlantıları tcp soketleri üzerinden kuruluyor, neden udp değil anlamış değilim, tcp'nin kayıpsızlığı canlı video aktarımlarında biraz sıkıntı yaratıyor. yetersiz bağlantılarda gecikmeler kaçınılmaz hale geliyor. gelen yayına (stream) müdahale edemiyorsunuz, sadece izleyenlere giden yayında paket düşürebiliyorsunuz ki elinizi koda bulaştırmadan bu paket düşürme işlerini yapamıyorsunuz.

elinizi koda sokma sıkıntısı ölçeklendirme ve red5'den red5'e yayın aktarma konusunda da var. ölçeklendirme için terracotta kullanıyor insanlar[1], sunucudan sunucuya yayın aktarma işi için de örnek kod bulmak mümkün değil, teoride nasıl yapılabileceğini e-posta listesinde bulmak mümkün[2], yani kolları biraz sıvamak şart bu işlere girmeniz gerekirse.

red5 ön tanımlı olarak, 5080'den http, 1935'den rtmp, 8443'den rtmps ve 8088'den rtmpt sunuyor. bu durumda şirketlerin güvenlik duvarlarına takılıyorsunuz doğal olarak. çoğu yerde sadece 80 portuna izin veriliyor. biz vidi için red5 üzerinden axis ile hem bir webservisi sunuyoruz hem de rtmp hizmeti sunuyoruz. yani en az 2 port açmamız gerekiyordu aynı sunucu üzerinde. bu engeli de vidi uygulamasının web.xml'inde bazı servlet ayarları yaparak aştık[3].

rtmpt aslında http'den başka bir şey değil. yayın verileri peşpeşe http paketleri olarak aktarılıyor. dolayısıyla aynı port üzerinden hem webservisini hem rtmpt sunmak için şu servlet ayarlarını eklemeniz yeterli:

<servlet>
  <servlet-name>rtmpt</servlet>
  <servlet-class>org.red5.server.net.rtmpt.RTMPTServlet</servlet>
  <load-on-startup>1</load>
</servlet>

<servlet-mapping>
  <servlet-name>rtmpt</servlet>
  <url-pattern>/fcs/*</url>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>rtmpt</servlet>
  <url-pattern>/open/*</url>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>rtmpt</servlet>
  <url-pattern>/close/*</url>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>rtmpt</servlet>
  <url-pattern>/send/*</url>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>rtmpt</servlet>
  <url-pattern>/idle/*</url>
</servlet-mapping>

iletişimi ssl ile şifrelemek için yaptığımız çalışmalarda da anladık ki aslında rtmps diye bir şey yok, rtmps=rtmpts=https demek mümkün. ssl işinde baya zorlandık, 0.7.4'de çalışmayınca 0.8 sürümlerine geçtik, orada da çalışmadı, bir düzine deneme sonrası sadece 0.8-RC2 versiyonunda çalıştırmayı başarabildik. bu versiyonun üstünde de altında da problemler yaşadık.

flash player tarafında ise, uygulama tasarımına girişmeden flash kısıtlarını araştırmak da fayda var. örneğin flash'ın izin kutucuklarının boyutu sabit, bu boyutun altında bir flash yaratırsanız kullanıcı kamerayı kullanma iznini veremiyor, ve eğer kullanıcı hatırla kutucuğunu işaretlememişse her flash için bu izni ayrı ayrı vermesi gerekiyor. eğer ekranda flashın tamamı gözükmüyorsa flash üzerindeki herhangi bir düğmeye tıklayamıyorsunuz. tam ekran yapma gibi işlevleri kullanıcı bir yere tıklamadıkça yapamıyorsunuz. bir de flash'i içine entegre ettiğiniz siteden başka bir alan adından sunacaksanız atmanız gereken epey bir takla var, flash'ın güvenlik politikası ile ilgili belgeleri bir okuyun derim ben. böyle ufak detaylar uygulama tasarımını tamamen değiştirebiliyor.

sunucuyla flash istemciler arasındaki komut iletişimi için shared object yerine uzak fonksiyon çağrılarını kullanmakta fayda var, red5'in shared object gerçeklemesinde sıkıntılar var.

bunun dışında geliştirme ortamı olarak linux üzerinde çalışan insanlar olarak actionscript yazmak da çok zorlanmadık, flex3sdk ve derlemeler için ant kullanımı yeterli oldu. ama ince çizimler yapacağım, tasarımla uğraşacağım diyorsanız linux çok doğru bir tercih değil.

red5'i kapalı devre sistemler için kullanıp kullanamacağımızı görmek için kalite konusunda sınırıları zorlama durumunda da kaldık, gördük ki flash player ile dvd kalitesine (480 satır) kadar çıkmak mümkün. dvd normalde 7-8 mbit/s'lik bir bant genişliği gerektiriyor, red5'de ise bant genişliği kontrollerini aktif hale getirmeden 1mbit/s'lik upload hızını aşamıyorsunuz, bant genişliği kontrollerini aktif hale getirebilmek için de biraz kod yazmanız gerekiyor.

yalnız 480 satırdan sonra flash oynatıcı çatlamaya başlıyordu. bir de flash oynatıcı ile görüntüyü sadece h.263 veya vp6 kodlayabiliyorsunuz. flash oynatıcı h.264 kodlayamıyor ama oynatırken h.264'u çözebiliyor. veri miktarını azaltmak için h.264 kullanmak elzem. bu arada xuggler[4] ile gelen yayını dağıtmadan kodlamasını değiştirmek mümkün. ama biz gönderirken h.264 gönderelim dedik flash oynatıcı dışında neyle yayın gönderebiliriz diye araştırdık. rtmp'nin belirtimlerinin kapalı olmasından olsa gerek pek bir alternatif yoktu. yaptığımız araştırmalarda rtsp'nin çok yaygın kullanıldığını gördük. eğer rtmp yayınını rtsp'ye dönüştüren bir ara uygulama olsa baya artacak alternatif sayısı aslında.

vlc 0.9 sonrasında rtmp izleme desteği geliyordu, ama sunucuya görüntü gönderilemiyordu. bu arada vlc'nin red5 ile çalışması için vlc kodunda bazı kontrolleri kaldırıp yeniden derlememiz gerekti. vlc ile flash oynatıcıdan çok daha başarılı bir görüntü akışı elde ettik, ama çok daha fazla gecikme gibi bir bedeli vardı. gecikmenin tam nedenini anlayacak kadar bakamadık henüz. görüntü aktarımı için java'yla yazılmış bir kod bulduk, ama yeterince olgun olmadığını düşündüğümüz için tercih etmedik. sonunda adobe flash media encoder kullanmak durumunda kaldık, bu da windows bağımlılığı anlamına geldiğinden hiç istemediğimiz bir durumdu. bu arada adobe flash media encoder ile red5'e rtmpt üzerinden yayın aktarmak için red5'te "content type" ile ilgili bir kontrolü kaldırıp yeniden derlememiz gerekti.

kalite denilince kodlamadan ziyade görüntüyü taşıdığınız arabirimler önem kazanıyor. red5'e görüntü aktarmak için bilgisayarınızın görüntü kaynağını webcam olarak algılaması gerekiyor. eğer bir yakalayıcı (capture) kart kullanırsanız televizyona verebildiğiniz herhangi bir görüntüyü (bir televizyon kanalını, bilgisayar ekranı görüntüsünü, veya composite çıkışı olan herhangi bir kamerayı, dvr kameraları) kullanabilirsiniz. burada veriyi sayısal olarak taşımak önemli (hdmi, dvi). anolog olarak ise sadece component arabirimi hd kalitesine (1080 satıra) izin veriyor. yalnız yakalayıcı kartlarda yüksek çözünürlük, sayısal arabirim dediğinizde fiyatlar biraz uçuyor.

şimdilik aklıma gelenler bu kadar, sonradan birşeyler hatırladıkça bu girdiye eklemeyi düşünüyorum. bir de yukarıda üstün körü geçtiğim yerlerden açılmasını istediğiniz varsa yorum bırakırsanız gerekli ekleri yapabilirim.

[1] http://www.terracotta.org/confluence/display/wiki/Red5+and+Terracotta+POC
[2] http://osflash.org/pipermail/red5_osflash.org/2007-December/017650.html
[3] http://gregoire.org/2009/01/28/rtmpt-and-red5/
[4] http://www.xuggle.com/xuggler/

flowplayer bwcheck eklentisi için red5 örneği

şuradaki rtmp örneğini red5 üzerinde çalıştırabilmek için tüm flowplayer'i anlamam gerekti, internette sadece yarım yamalak bilgiler bulabildim, yaşadığım süreci başkaları için hızlandırabilmek adına yaptığım ayarları paylaşayım dedim:

index.html:

<html>
<head>
<script type="text/javascript" src="flowplayer-min.js"></script>
</head>
<body>
<div id="info">click below to see most appropriate video to your bandwidth</div>
<a class="rtmp" id="red5"><img src="img/showme.png" /></a>
<script language="JavaScript">
$f("red5", "swf/flowplayer-3.1.0.swf", {
log: {
filter: 'org.flowplayer.bwcheck.*',
level: 'debug'
},

clip: {
url: 'skyandice.flv',
urlResolvers: 'bwcheck',
live: true,
provider: 'rtmp'
},

plugins: {

bwcheck: {
url: 'swf/flowplayer.bwcheck-3.1.0.swf',
netConnectionUrl: 'rtmp://red5ip:1935/bwcheck',
bitrates: [40, 150, 400, 700, 1000],
serverType: 'red5',
rememberBitrate: false,

onBwDone: function(url, chosenBitrate, bitrate) {
var el = document.getElementById("info");
el.innerHTML = "Your speed is: " +bitrate+ "<br />Video file served: " +url;
}
},

rtmp: {
url: 'swf/flowplayer.rtmp-3.1.0.swf',
netConnectionUrl: 'rtmp://red5ip:1935/oflaDemo'
}
}
});
</script>
</body>
</html>

kullanilan dosyalar:

http://static.flowplayer.org/img/player/btn/showme.png # img altina
http://static.flowplayer.org/video/skyandice-40.flv
http://static.flowplayer.org/video/skyandice-150.flv
http://static.flowplayer.org/video/skyandice-400.flv
http://static.flowplayer.org/video/skyandice-700.flv
http://static.flowplayer.org/video/skyandice-1000.flv
# skyandice*.flv'ler /usr/lib/red5/webapps/oflaDemo/streams altına (artık siz nereye kurduysanız)
http://flowplayer.org/releases/flowplayer.bwcheck/flowplayer.bwcheck-3.1.0.swf
http://flowplayer.org/releases/flowplayer.rtmp/flowplayer.rtmp-3.1.0.swf
http://flowplayer.org/releases/flowplayer/flowplayer-3.1.0.zip
# flowplayer-3.1.0.swf, flowplayer.controls-3.1.0.swf, flowplayer-3.1.0.min.js de bu zip dosyasından geliyor
# tum swfler swf dizini altına

bir de http://red5ip:5080/installer adresinden bwcheck ve oflaDemo uygulamalarını kurmuş olmanız gerekiyor.

umarım birilerine faydası dokunur.

anarşik bir iş ortamında iş yapabilmek

zeitin'de demokrasinin de ötesinde anarşik bir düzen daha doğrusu düzensizlik hüküm sürüyor şu sıralar, anarşinin son bulduğu tek nokta ise öncelik listemiz, parkyeri'ndeyken bölüm sorumluları ve şirket ortakların bir araya geldiği eşgüdüm toplantılarında her bölüm için o haftanın öncelikli işlerini çıkarmaya çalışırdık. zeitin'de sayımız az olduğundan, herkesin katıldığı haftalık şirket toplantıları yapmaya başlamış ve eşgüdüm işini de bu toplantılarda halletmeye çalışmıştık, ancak anerşik yapımız bu toplantıların devamlılığını getirmemize engel oldu, ve muhtemelen küçük bir şirket için en uygun olan yönteme kendiliğinden bir yönelim yaşadık, işlerin önceliklendirilmesi işini bir kişi kendi başına yapar duruma geldi, şu anda da bu işi giray abi üstlenmiş durumda.

bu hafta, önceliklerimizin dışında bir işle uğraşınca alper'den tepki aldım. anarşinin getirdiği yan etkilerden biri de bu, kimden ne zaman nasıl bir tepki alacağınızı tahmin etmek çok kolay değil. sonradan öğrendim ki alper de aynı işe talipmiş ve giray abilerle konuştuğunda işin önceliği engeline takılmış.

hiyerarşik bir düzende veya kuralların belli olduğu bir yerde herhangi bir hareketinizin sonuçlarını tahmin etmek biraz daha kolaydır, en azından mutlu etmeniz gereken insanlar bellidir. anarşik bir toplumda ise herkesin mutlu olmasını sağlamanız gerekiyor, bu da fazla ideal bir durum, pratikte çok mümkün gözükmüyor. dolayısıyla ortamda şikayetler eksik olmuyor, her an illa biri birilerinden veya bir durumdan şikayetçi, ve şikayetleri yönetmediğimizden, ilginiz olsa da olmasa da, ister istemez her şikayetten etkileniyorsanız. "ilginiz olsa da olmasa da" sözü aslında zeitin için çok yanlış, çünkü zeitin çalışanı iseniz her işle doğal olarak ilgili olduğunuzu kabul etmişsiniz demektir.

bugün zeitin'de sahip olduğumuz özgürlüklerin dünya üzerinde hiç bir şirket çalışanına sunulduğunu sanmıyorum, buna google da dahil. insanlar parkyeri'nin ve zeitin'in google'dan esinlendiğini düşünüyor, eğer benzetileceksek google'dan çok "SUN"'a benzetilmemiz bence daha doğru, benim uzaktan algıladığım "SUN" çok daha okul gibi tasarlanmış ve çalışan insiyatifinin ön planda tutulduğu bir şirket. google ise daha çok "mış gibi" yapan bir şirket. "don't do evil" diyip, android telefonlarda google hesabını zorunlu kılan, dağıtım gücünü tekel oluşturmak için kullanan bir şirket. "çalışanlarımıza zamanlarının %20'sinde istedikleri işi yapma özürlüğü tanıyoruz" diye reklam yapan, ama bu %20'de yapacağınız işi müdürünüze onaylatmanız gerektiği detayını pek paylaşmayan, içeride müdür gibi kavramların hüküm sürdüğü bir şirket. chrome ve chromium diye biri açık biri kapalı kaynaklı iki ayrı proje açıp tek taraflı faydaya dayalı bir camia gücü oluşturma peşine düşmüş bir şirket. bu gibi hareketler google'in samimiyetinden şüphe ettiriyor insanı.

zeitin olarak debian tercih etmemizin sebebi de bu, gerçekten özgürlüğü varoluş sebebi olarak koruyabilmiş tek dağıtım, genelde diğer dağıtımlar camia gücünü kullanmaya çalışan, başka amaçlarla yola çıkmış, çıktıkları yol özgür yazılımlarla kesiştiği için özgür yazılıma destek olan, pek çok konuda google'un yaptığı gibi "mış gibi" yapan dağıtımlar.

zeitin'in kurucularını tanıyan ve zeitin'in kuruluşuna şahit olma şansı yakalamış bir insan olarak, zeitin'in çalışan mutluluğu ve özgürlüğü üzerine kurulmuş bir şirket olduğuna, bu iki unsurun herşeyin önünde tutulmuş olduğuna birinci elden tanığım. umarım hep böyle kalabilir.

yalnız "özgürlük eşittir mutluluk" demek doğru değil, özgürlüğü başarılı olma sebebi olarak göstermek de doğru değil. ama hem özgür hem başarılı olunabilir.

herkesin özgür olması demek anarşi demek, anarşilerde huzursuzluk oluşması doğal, bu huzursuzluklara çözüm demokrasi olabilir, yalnız demokrasiyi zeitin'e çok uyarlayamıyoruz çünkü demokrasi beraberinde yasaları getiriyor, yasa demek yasak demek. (gerçi başbakanımız en son türban mevzularında "artık yasaklar ülkesi olmayalım" gibi ilginç demeçlerde bulunmuştu, ya başbakanın bir yanlışı var ya benim, bildiğim kadarıyla yasaklarla yönetilmeyen herhangi bir ülke yok, tek yaptığımız ülkeleri yasakları koyuş ve uygulayış şekline göre sınıflandırmak)

yasa ve yasakların ters tarafı zamanla hiç duymadığın bilmediğin kurallara tabi hale gelmen. bunu çözüm de yasaları yazmayıp töreler gibi yazılı olmayan kurallarla ilerlemek, uygulama konusunda da toplumsal yaptırımlara başvurmak, yani mahalle baskısına izin vermek. bu durumda "bir yasayı duymadıysan o yasa yoktur" kuralı işler.

bu son örnekte, önceliklerimizin dışına çıkarak törelerimize karşı gelmiş oldum sanırım, karşıma da ilk çıkan alper oldu, beni destekleyen kimse çıkmadığından mahalle baskısını da yemiş oldum. ancak herşeye rağmen başladığım işi bitirmekte ısrar ettim, "ya bu işi yaparım, ya da işime son verirsiniz" diye çıkışınca engelleri aşmış oldum, muhtemelen ay sonunda başarım değerlendirmemin olumsuz etkilenmesi gibi son bir yaptırım daha yiyeceğim, bir daha böyle bir şey yapmamam için (şu an başarım değerlendirmesi işini de giray abi üstlenmiş durumda, bu cezayı verip vermeme kararını verecek insan da kendisi dolayısıyla)

yapacağım iş sürüm çıkma yöntemimizi değiştirecekti, parkyeri zamanlarından beri sürümlerin deb paketi olarak çıkılmasını, sürümlerimizi ve bağımlılıklarını koyabileceğimiz bir debian depomuz olması gerektiğini savunan bir insan olarak, yeni şirkette daha insanlar alışkanlıklarını oluşturmadan bu işin halledilmesi gerektiğini düşünüyordum, bu yüzden benim için oldukça öncelikli bir işti. giray abi işin önceliği konusunda benimle aynı fikirde değildi, ancak giray abinin öncelikleriyle ilerleyecek olsam muhtemelen 6 yıl beklemem gerekecekti (parkyeri'nin 6 yıldır debian kullanan ama debian deposu olmayan bir şirket olduğunu düşünecek olursak).

bu çok kritik bir işti, çünkü anarşik bir toplumda doğru zamanda doğru yerde yazacağınız ufak bir betik, bir araç ya da belirleyeceğiniz bir çalışma yöntemi, yeni bir "töre"'nin doğmasını tetikleyecektir. bu ilk bakışta zor koşma gibi bir yöntem gibi gözükse de aslında pek değil, çünkü eğer insanları saçma bir yönteme zorlarsanız kabullenmeyeceklerdir, direnç göstereceklerdir. tabi bunun çalışması için de akıllı ve sorgulayan insanlarla çalışmak gibi bir ön koşul gerekiyor. yalnız yöntem belirlemek yeterli değil, arkasında durmak da gerekiyor töreleştirebilmek için. bir süre sürüm işleriyle kendim ilgileneceğim, belirlediğim yöntemleri insanlara göstereceğim, eleştirlerini alacağım, yöntemlerin iyice olgunlaşması ve başkalarının da aynı yöntemleri kullanmasını sağlamak için mücadele edeceğim. zaten doğru bir şey yapıyorsam insanlar kısa zamanda benimseyecektir.

zeitin yeni bir şirket olduğundan, henüz insanlar sürüm hazırlama konusunda bazı alışkanlıklar oturtmamış olduğu için işim biraz daha kolay olacak. eğer zaman geçmesine izin verseydim sadece mantıklı bir yöntem önermem yetmeyecekti, aynı zamanda insanların eski alışkanlıklarını kırmak için çok zorlu bir mücadeleye girişmem gerekecekti ve muhtemelen başaramayacaktım.

bir diğer yöntem ise, işe girişmeden önce herkesi ikna etmek olabilirdi. bence bu yöntem çok masraflı, toplantı gibi ön koşullar gerektiriyor, toplantılarda herkezden bir anda yaptıkları işlerden uzaklaşıp sizin yaptığınız işe sizin kadar odaklanmalarını bekliyorsunuz, ben bunu gerçekten başarabilene şahit olmadım açıkcası. bir de bu yöntemde fikri öneren ile uygulayan farklı insanlar oluyor genelde, dolayısıyla önerilerin yeterince olgunlaşmaması gibi bir risk taşıyor.

eğer anarşik bir toplumda iş yapacaksanız, öncelikle yaptığınız işe inanmanız gerekiyor, motivasyonunuzu iyi belirlemeniz ve sağlam temellere oturtmanız gerekiyor, çünkü insanların tepkilerinin motivasyonunuzu kırmasına izin vermemelisiniz, başladığınız işi bitirmek gibi bir prensip edinmiş olmanız da işinize yarayacaktır.

insanların motivasyonunuzu kırmasına izin vermemeniz gerektiği gibi kendiniz de başkasının motivasyonunu gereksiz bozacak laflar etmemeniz gerekiyor. amacı olmayan cümlelerden uzak durmalısınız, ama amaçlı cümlelerinizi de sakınmamanız gerekiyor, yoksa şirket istemediğiniz bir yöne doğru kayabilir, desteklediğiniz töreleri yıpratıcı hareketlerden kaçınmanız önemli (gerçi alper'le yaşadığımız son örnekte buna uyamadım, çünkü yaptığım hareketin getirisi götürüsünden çoktu), bir de birinin hata yaptığını düşünüyorsanız mutlaka yüzüne karşı söylemeniz lazım, kendini düzeltme şansı tanımak için, ancak bunu yaparken kendinizin de hatalı düşünüyor olma ihtimalini göz önünde bulundurmanız şart. bu lafına dikkat etme meselesi o kadar da kolay değil, kurduğum cümlelerde kendime bir nebze hakim olabilsem de biri ters bir laf ettiğinde karşı saldırıya geçme gibi yenemediğim bir refleksim var, bu anlarda biraz şevk kırıcı olabiliyorum sanırım.

açıkcası zeitin'de çok huzursuz olduğum anlar olmadı değil, kafam rahat olsun da özgür olmayım dediğim anlar da oldu. ancak dönüp baktığımda görüyorum ki 3 ayda vidi gibi bir ürün çıkarabilmişiz ki aynı ölçeklerde kurumsal bir şirkete parasıyla aynı işi yaptırmaya kalksanız muhtemelen 1 sene de çıkacak bir ürün, 1 sene iyimser bir tahmin bile olabilir. daha duyurusunu yapmamış olduğumuz ve çok ses getireceğine inandığımız gokada adlı projemizde de yolu yarılamış durumdayız, şu anda bu proje kapsamında geliştirdiğimiz "thinclient" çözümünü şirket içerisinde kullanmaktayız.

yani görünen o ki anarşiyle, törelerle bir şekilde bir şeyler ortaya çıkarabiliyoruz, bir yazılımcı olarak bu başarı hissi, "bir şey ürettim" hissi çok önemli. umarım yakın zamanda ürünlerimizin satışını da başarabilir ve şirketimizin devamlılığını sağlayabiliriz.

vim'le log renklendirme

logları "tail -f LOGDOSYASI | ccze -A" komudu ile takip etmeye alışmış insanlar olarak, sonradan logu bir editörle açtığımızdaki renksizlik epey gözlerimizi rahatsız ediyordu. bekir, sağolsun, vim için bir renklendirici yazdı, rahatladık. şuradan indirdiğiniz dosyayı ~/.vim/syntax dizinine koyup (eğer dizin yoksa, yaratın), bir log dosyasını vim ile açıp, ":set syntax=log" derseniz dünyanız renklenecektir. eğer her defasında ":set syntax=log" demek istemiyorsanız ~/.vimrc dosyanıza "au! BufRead,BufNewFile *log set filetype=log" satırını eklemeniz yeterli. özetle şudur:

#!/bin/sh
mkdir -p ~/.vim/syntax
cd ~/.vim/syntax
wget --no-check-certificate https://svn.bdgn.net/public/test/bekir/.vim/syntax/log.vim
echo "au! BufRead,BufNewFile *log set filetype=log" >> ~/.vimrc

neden git kullanır insan?

şirkette subversion'dan git'e geçilmesi ardından yaşanan yoğun git karşıtlığı nedeniyle bir süredir git'i savunmak durumunda kalıyorum zaman zaman, ama çok da başarılı olduğum söylenemez, ben de savunmamı yazılı hale getirmeye karar verdim, belki böyle daha ikna edici olabilirim.

aslında şurada git'in diğer versiyon kontrol sistemlerine göre üstünlükleri oldukça detaylı açıklanmış.

kişisel tercih sebeplerimi özetlemem gerekirse:

* geliştirmenin bir kısmını teslim etmeye izin vermesi.
* 'git add -p' komuduyla çalıştırılan etkileşimli teslim modu.
* dallarla çalışmayı olağan hale getirmesi.
* geçmiş teslimleri birleştirme/bölme, teslim mesajını sonradan düzenleme gibi geçmişe yönelik işlemlere izin vermesi.
* ana depo ile klonlanan depo arasında bir farkın olmaması, daha doğrusu bir ana depo olmaması.
* başkasının yerine teslim edebilme olanağı sunması.
* "git-am" ile teslimlerin eposta yoluyla paylaşımının kolaylaştırılması.

bekir zamanında parkyeri'nde rcs'den svn'e geçildiğinde, insanların "nasıl yani, bir dosya değiştiğinde tüm deponun revizyonu mu değişecek" şeklinde tepki gösterdiklerinden bahsetmişti. git'e geçerek dosya dosya teslim edebilme özelliğimizi geri kazanmış olduk, hatta daha da fazlasını yapabilir hale geldik, artık hunk hunk teslimler yapabiliyoruz. yani değil dosya dosya, dosyada yaptığımız değişikliklerin bir kısmını bile teslim edebilir hale geldik.

git'te 3 aşamalı bir teslim anlayışı var. "git add" ile yaptığınız değişiklikleri önce "index"'e teslim ediyorsunuz; sonra "git commit" ile çalıştığınız dala; en son olarak da başka bir ana depo söz konusu ise "git push" ile, başka bir ana dal söz konusu ise "git merge" ile son teslimi yapmış oluyorsunuz.

svn'de "svn commit" ile tek aşamada yapılan bir işi niye böyle zorlu bir hale getirdik diye deliren insanlar olabiliyor bu durumda. öncelikle bu 3 aşamada yapılan işi, "svn commit"'in yaptığı işe denk saymak çok yanlış. geçmişte uzun zamanlı bir geliştirme yapacaksam (örneğin 1 haftalık) svn-rcs karışık kullanımına yöneliyordum. svn'den çektiğim depoyu aynı zamanda bir rcs deposuna çevirerek geri almayacağımdan emin olduğum değişiklikleri rcs deposuna teslim ediyordum, ve rcs diffleri üzerinden geliştirmeye devam ediyordum. aksi takdirde yama 1 haftada çok büyüyordu ve gözden geçirme olanaksız hale geliyordu. tabi svn-rcs karışık kullanımı bu derdimi çözüyor olmasına karşın hayatıma yeni dertler sokabiliyordu. git bu açıdan ilaç gibi geldi diyebilirim, bence gayet şık çözmüşler meseleyi. artık geliştirme esnasında ne zaman kopuk ve sonucundan emin olmadığım bir yola yönelecek olsam, "git add" ile kaybetmek istemediğim değişiklikleri öncelikle index'e alıyorum, koda korkmadan dalabiliyorum, baktım yolun sonu iyi değil, "git co ." ile anında temiz noktaya geri dönüş yapabiliyorum. 3 günlük bir geliştirme yapacaksam, her gün akşam "git add" ile yaptığım işi gözden geçirip varsa kalıcı kod, teslimlerimi yapıyorum, böylece 3 gün sonunda kocaman bir yama gözden geçirmektense bu işi gün gün yaparak gözden kaçırma durumunu en aza indirgemiş oluyorum.

"git add -p" index teslimlerini etkileşimli bir hale getirerek insanın işini epey bir kolaylaştırıyor. hunkları teker teker önünüze getirerek kabul edip etmediğinizi soruyor. tüm hunkların üzerinden geçerek kalacak kodları "index"'e ekliyorum, düzeltme gereken yerlerde arka planda değişiklikleri yapıyorum, hunklar bittikten sonra yeni düzeltmelerin teslimi için işlemi tekrarlıyorum, en sonunda sadece atılacak değişiklikler geriye kalıyor, "git co ." komuduyla bu kodları atıyorum.

svn-rcs karışık kullanacağına svn'de bir dal açsaydın da rahat etseydin diye düşünebilirsiniz, onu da denedim ancak svn'de dal kullanımı hiç de dökumanlarda yazıldığı gibi pratik bir şey değil. herşeyden önce dalı açma sebebim trunk'da yapamayacağım işleri dalda yapabilmek. peki bir insan trunk'da ne yapamaz? sonradan silme ihtimali olduğu kodların teslimini yapmaktan çekinir mesela, ya da tek satırlık teslimlerle ilerlemeyi tercih etmezsin genelde teslim logunu kirletmemek için. dalda bütün bunları yapabiliyorum artık güzel, geliştirmemizi bitirdik, geldik yaptıklarımızı trunk'a geçirmeye. bu aşamada benim yaptığım, dalı açtığım noktayla geldiğim son nokta arasındaki farktan hazırladığım yamayı trunk'a uygulamaktı. böylece dalda yazdığım çöp kodları ve tek satırlık teslimleri trunk'a almamış oluyordum, ancak o zaman da dal ile trunk arasındaki bağ kopuyordu, "svn merge" komudunu hiç kullanmaz oluyordum yani gerçek anlamda dal açmış olmuyordum aslında. svn'de dal açmış olmamın svn-rsc karışık kullanımına göre yarattığı tek fark geliştirmede geldiğim son noktayı ve geçtiğim aşamaları diğer insanlarla da paylaşabiliyor olmamdı. aslında "svn merge" hiç kullanmıyor da değildim, trunk'da yapılan değişiklikleri dala almak için tek yönlü bir şekilde kullanıyordum, onda da her defasında "svn merge -rX:Y" dediğimde X dahil oluyor muydu olmuyor muydu diye sürüncemede kaldığımı hatırlarım. dalda yaptığım değişikliklerden hazırladığım yamayı trunk'a uygulayıp teslim ettikten sonra, dalı trunk'la eşit hale getirme meselesi var tabi bir de. onun için de dalda, çatalladığım ilk revizyona döndükten sonra, o revizyon ile trunk'taki son revizyon arasını, geri aldığım dala "svn merge" ile birleştirirdim. bütün bu işlemler çok külfetli geldiğinden kısa sürede svn'de dal kullanımından vazgeçmiş, svn-rcs karışık kullanımına geri dönmüştüm.

peki svn'de dalla çalışmak problem de git de değil mi? pek değil, git'in tüm kurgusu dalların birleştirilmesi üzerine kurulu olduğundan tüm dal işlemleri gündelik hale geliyor, kısa sürede svn'de uzak durmaya çalıştığınız bir sürü şeyi çoktan refleks haline getirmiş oluyorsunuz. bir de git'te, "git rebase" diye bir komut var, yukarıda saydığım tüm problemleri tek kalemde çözüyor. bir daldan çatallayarak yeni bir dal oluşturdunuz, bu sırada ana dalda insanlar değişiklik yapmaya devam ediyor, bu değişiklikleri açtığıniz dala almak için "git rebase ANADAL" demeniz yeterli. ve artık açtığınız dalda korkmadan dilediğinizi özgürce yapabilirsiniz, çünkü git ile geçmişi de değiştirmeniz mümkün, yaptığınız tek satırlık teslimleri birleştirerek tek bir teslim haline getirebilirsiniz, geçmiş teslim mesajını değiştirebilir, "git cherry-pick" komudu ile başka dallarda hoşunuza giden değişiklikleri nokta atışı ile kendi dalınıza geçirebilirsiniz.

svn'de geçmişte değişiklik yapabilmeniz için svnadmin gibi bir komuda ve bazı izinlere ihtiyacınız olur, git'te ise bir depoyu klonladığınızda ana depoyu yerelinize çekmiş olursunuz. ana depo üzerinde yapabileceğiniz her işi yerelinizde de yapabilirsiniz. deponun geçmişinde bir şey değiştirebilmeniz için sistem yöneticilerine "şu değişikliği yapabilir misiniz?" diye e-posta atmanız gerekmez.

parkyeri'nde gözden geçirmeleri eposta ile yapardık, geliştirmenizi tamamladığınızda "[YAMA]" etiketli bir epostayla yamanızı yayınlardınız, herhangi biri gözden geçirip teslim edebilirsin dedikten sonra yamayı gönderen teslimi gerçekleştirirdi, eğer biri birşeyi beğenmezse yamayı gönderen gerekli değişiklikleri yapar ve tekrar bir yama gönderirdi. eğer süreç şu şekilde olsa bence daha etkin bir çalışma yöntemi olurdu. geliştirmesini bitiren yamayı yayınlar, bir diğer kişi yamayı kendi deposuna uygular, problemli bulduğu yerlerde istediği değişiklikleri yapar ve teslimi gerçekleştirir. bu şekilde aynı yamanın ufak değişiklikler yüzünden 8 defa gönderilmesi derdinden de kurtulmuş oluyoruz. bir de yama gözden geçirmek için eposta üzerinden hızlıca bir göz atmak çok uygun bir yöntem değil, gözden kaçırmalara çok açık, yamayı yerelinize uygularsanız ister istemez testini de yapar halde bulacaksınız kendinizi, bu da gözle yakalayamadığınız hataları yakalayabilmenizi sağlayacaktır, örneğin yamaya eklenmesi unutulmuş bir değişiklik varsa, veya ayar dosyasında yapılması gereken bir değişiklik yamaya eklenmemişse testiniz patlayacağından anında durumun farkına varabilirsiniz.

yalnız bu çalışma yönteminde, svn'de başkasının yerine teslim yapamadığınızdan değişikliklerin sahiplik bilgisinin kaybedilmesi gibi ciddi bir dert var. git'te ise istediğiniz kişi bilgileriyle teslim yapmanız mümkün. ve özellikle "git am" komudu ile teslimlerin eposta ile paylaşımı çok pratik bir hal aliyor, tek bir komutla eposta'daki yamayı yerelinize teslim edebiliyor ve yerelinizdeki teslimleri eposta haline getirebiliyorsunuz.

sonuç olarak bence git üzerine gerçekten kafa yorulmuş ve güzel tasarlanmış, kişisel olarak yasadığım bir çok derde çözüm oldu. git diğer versiyon kontrol sistemlerinin sunduğu özellikleri sağladığı gibi daha da fazlasını sunuyor. o yüzden git kullanan bir insan herhangi bir versiyon kontrol sistemini kullanabilir, ama tersinin doğru olduğunu söylemek zor. bu nedenle diğer versiyon kontrol sistemlerine alışmış ve halinden memnun olan insanlar yadırgayabiliyorlar, işlerin gereksiz karmaşıklaştırıldığını düşünüyorlar. bence karmaşıklaştırılıyor olsa bile gereksiz karmaşıklaştırılmıyor, yukarıda saydığım ve benim kendimce daha karmaşık çözümler ürettiğim bir sürü problemi çok güzel çözmüş. aslında birşeyi karmaşıklaştırdığı görüşünü de paylaşmıyorum, sadece farklılaştırıyor, ve alıştıktan sonra gündelik kullanımda diğer versiyon kontrol sistemlerinden daha fazla veya daha az yormuyor diye düşünüyorum.

özetle bence git doğru seçim.

sürücülerle nereye kadar!

macbook'ta debianı adam etmeye çabaladığım şu sıralar bir kez daha kendimi sürücülerle boğuşurken buluverdim. askerliğim boyunca uğraştığım TSK'nın win2k bilgisayarları sağolsun; karşılaştığım türlü dertler, ticari bir işletim sistemi tercih etsen bile bu sürücü belasının kurtulamayacağın bir illet olduğunu bir kez daha hatırlatmış oldu bana.

herşeyden önce anlamadığım, insanoğlunun bilgisayarını başka bir şirketten, işletim sistemini başka bir şirketten almaya nasıl ikna olmuş olduğu. adam bir donanım satıyor ve bu donanımın başka bir şirketin ürettiği yazılım olmadan hiçbir anlamı yok. sadece bilgisayarlar değil, örneğin bir ağ kamerası aldınız, bunu kullanabilmek için bir bilgisayarınızın, bir de sorunsuz calışan bir işletim sisteminizin olması gerekiyor (ki bu sıradan bir windows kullanıcısı için kurulumdan sonraki 3-4 aya tekabül ediyor, sonrasında sistem çatırdamaya başlıyor), belki o zaman ağ kameranız size hizmet vermeye lütfedebilir, tabi o da üreticiler kullandığınız işletim sistemi için bir sürücü yazmışlarsa.

bence bu işler bir noktada yanlış bir yola sapmış, IBM'in PC standardını serbest bırakması bir kırılma noktası olabilir. herşeyden önce cihazlar çalışmak için neden dış bir işletim sistemine ihtiyaç duyuyorlar, neden kendi işletim sistemleri kendi üzerilerinde gelmiyor?

unix, ilk zamanlarda dosya yönetmekten başka bir amacı olmayan bir sistem, ve günümüz işletim sistemleri bu sistem üzerine oturtulmuş durumda. unix'te birinci kural "herşey bir dosyadır.", yani bilgisayarınıza taktığınız ethernet arabirimi de, ağ kamerası da sistem için birer dosyadan başka bir şey değildir. çıkış için dosyaya birşey yazılır, giriş için dosyadan birşeyler okunur. cihazlarin sürücüleri de bu dosyaya yazma-okuma işlemlerini cihazın anlayacağı dile tercüme eder. yani aslında bilgisayar dediğimiz şey iki kavramdan ibarettir: "giriş-çıkış", "kodlama-çözümleme". 1900'lerde de bu böyleydi, 3000'lerde de bu böyle olacak.

ama umarım 3000'lerde hala sürücülerle uğraşıyor olmayız. yıl 3000'de bir uzay gemisine bindiğimde yanımda getirdiğim bir aygıtı kullanabilmek için uzay gemisi bana sürücü CDsi sorarsa o gemiyi yakabilirim.

neyse ki şu sıralar bell labs plan9 projesi ile unix'te sapılan "herşeyi dosyaya benzetme" yolundan dönme çabası içerisinde. yeni işletim sistemi için model olarak internet seçilmiş. bu da insana gelecek için biraz umut aşılıyor.

herhangi bir donanımı çalışır hale getirmek bir adsl modemi çalışır hale getirmekten daha zor olmamalı, gerekli bağlantıları yaptıktan sonra tarayıcımdan bir adrese girmeliyim ve karşıma ayarlar sayfası çıkmalı, gerekli ayarları yaptıktan sonra cihaz çalışır hale gelmeli.

bir uzay gemisindesiniz, evdeki sevdiklerinize son halinizin fotoğrafını göndermek istiyorsunuz, ve çevrenizde bir sürü akıllı aygıt var, bu aygıtların aklında da sadece 2 soru var: "girdileri nereden alacağım?", "çıktıyı nereye vereceğim?". kodlama-çözümleme ile ilgili soruların cevapları doğumlarında veya sonradan, donanım veya yazılım olarak beyinlerine kazınmış durumda. sizin ihtiyacınız olan bir ağ kamerası, fotoğrafı kaydetmek için bir dosya sunucusu ve mesaj göndermek için bir e-posta sunucusu.

ve şimdi kullanacağınız aygıtların sorularına cevap verelim:

ağ kamerası ayar sayfasında: görüntü dondurulduğu anda çıkışını dosya formatında, şu ayarlarda şu adresteki dosya sunucusuna gönder, girişin şu klavye üzerindeki şu kısayollar; şu kısayolda görüntüyü dondur, şu kısayolda görüntü akışına devam et.

dosya sunucusu ayar sayfasında: girişinde şu ağ kamerasından akan verileri kabul et, şu adrese şu dosya ismiyle kaydet ve şu e-posta sunucusuna şu ayarlarla gönder.

e-posta sunucusu ayar sayfasında: girişinde şu dosya sunucusundan akan verileri kabul et, transfer tamamlanınca çıkışın şu eposta adresi.

eğer fotoğrafın kaydını tutmak istemiyorsanız o zaman dosya sunucusunu hiç kullanmayabilirsiniz, ağ kamerasını doğrudan e-posta sunucusuna bağlayacak şekilde ayarlarınızı değiştirmeniz yeterli olacaktır.

ama ne yazık ki günümüzde bu tip ölçeklendirmelere gitmek, kolayca bileşen değişikliği yapabilmek çok mümkün değil. çünkü ürettiğimiz aygıtların bir PC olmadan bir anlamları yok, PC'lerin efendi diğer aygıtların köle olduğu bir düzende yaşıyoruz, elimizdeki cihazı ancak PC'mizin gücünün izin verdiği ölçüde kullanabiliyoruz. halbuki iş paylaşımı ve haberleşmeye dayalı bir tasarım üzerine ilerlenmiş olsa, her cihazı çalıştığınız sistemden bağımsız olarak gerçek gücünde kullanmak mümkün olacaktı, belki de işletim sistemi diye birşey olmayacaktı.

sun'in vizyonunda da söylendiği gibi "ağ demek bilgisayar demek!", inşallah.

cinnet sonrası debian'a dönüş

macbook'la ikinci senemi doldurmak üzereyim, geçenlerde ağ trafiğimdeki bazı şüpheli hareketlerden kıllanıp snort+base ile bir takip edeyim dedim ne oluyor ne bitiyor. base, gd bağımlılıkları olan bir php uygulaması, leopard ile gelen php'nin ne yazık ki gd desteği yok idi, internette biraz bakındığımda gd desteği için yeni bir php derlemem gerektiğini fark ettim. mac'te en kıllandığım durumlardan biri bu, bir sistemin içinde gelen bir şeyler var, bir de onların yetmediği yerde darwin-ports'tan kurduğun şeyler, sisteminde 2şer tane gcc, 2şer tane php olabiliyor. bu da sistemi patlamaya hazır saatli bomba haline getiriyor, path'de ön sırada olan uygulamanın yanlış kütüphaneyi kullanması gibi sıkıntıların yol açabileceği, teşhisi zor problemlere davetiye çıkarılmış oluyor.

bu fevri kızgınlık sırasında, şöyle döndüm bir kendime baktım. 2 yıl içerisinde, ağ trafiğindeki şüpheli hareketlerden kıllanan, türkiye'de yaşadığı için itunes store'dan alışveriş yapamadığına üzülen, apple'in çıkardığı her ürünün reklamlarını vs. pür dikkat izleyen bir adam haline gelmişim. steve jobs'un rüzgarına kapılarak huzurumdan olmuşum.

şöyle bir "ps" çektim konsolda, bir sürü ne yaptığını bilmediğim işlem koşuyor bilgisayarımda, geçenlerde kendine xmonad kurmuş, sisteminde toplasan 20 işlemin koştuğu bekir çocuğu geldi aklıma ve bilgisayarım üzerindeki kontrolu yitirdiğim hissiyatına kapıldım.

bu düşünce silsilesi sonrası getirdiğim cinnet sonrası macbook'uma debian kurma kararı aldım. yalnız o kadar da cinnet geçirmemişim sanırım ki tüm diski formatlamak yemedi, çift işletim sistemi çözümüne yöneldim.

kurulumu tamamlayıp, yeni debianımı açtığımda uzun yıllar sonrası memlekete geri dönüşünde ilk işi toprağı öpmek olan gurbetçi pisikolojisine büründüm bir an için. mac'e geçtiğimde compiz, xgl yeni yeni çıkan kavramlardı, arkadaşlardan görüyordum ama içinde yaşama şansı bulamamıştım, diyebilirim ki memleket görmeyeli çok değişmiş. herhalde istanbul'a döndüğünde ilk kez gördüğü boğaziçi köprüsünden geçerken değişen istanbul üzerinde göz gezdiren gurbetçi ile aynı hissiyat içindeydim bu noktada da.

yalnız çok zaman geçmeden memleketin bozuk yolları, gündelik dertleri gözüme batar oldu. tanınmayan donanımlar ve masaüstündeki genel bir yavaşlık hali. macbook o kadar ağım-şahım bileşenlere sahip olmayan bir bilgisayar olmasına rağmen macosx işletim sistemi ile gerçekten çok üstün bir başarım sergileyebiliyor. bu da insanın makineden beklentisini arttırıyor sanırım.

ubuntunun kendi bilgisayarını ürettiği, ya da bir çinli üreticinin bünyesindeki düzgün yazılımcı ekibiyle üretilen bilgisayar için kullanılacak linux dağıtımı üzerinde gerçek anlamda bir eniyileme çalışması yapabileceği günleri iple çekiyorum. her bilgisayarda koşsun diye yazılan yazılımların, özel bir donanım üzerinde koşulmak üzere yazılmış macosx işletim istemiyle rekabet edebilmesi oldukça güç aksi takdirde.

neyse sanırım geri dönüşüm o kadar da hızlı gerçekleşemeyecek, biraz daha araştırma yapıp, çekirdeği macbook'a göre derleyip, bir iki ayar ile sıkıntılarımı aşabileceğim umuduna sahibim. televizyona ve dış monitore sorunsuz görüntü verebilme, skype'i kameralı olarak sorunsuz çalıştırabilme aşmam gereken öncelikli sıkıntılar.

bu arada mac kullanıcılarına snort+base'i tavsiye ederim, başarılı bir nasıl belgesini şurada bulabilirsiniz. arkadaş hemen quicktime'in vs.'in yaptığı hareketleri yakalıyıverdi.