Şoför ilanları Yazılım Geliştiricisi ilanları gibi olsaydı

http://blog.jitbit.com/ adresinde gayet güzel bir yazı gördüm. Yazı dediğim şey aslında kurmaca bir iş ilanından ibaret.Çeviriyi kendim yaptım yamulduğum yerlerde düzeltmekten çekinmeyin.


İş tanımı: Şoförlük


İş gereksinimleri:  Profesyonel seviyede araba,yük vagonu,otobüs,kamyon,troleybüs,tramvay,metro,traktör,kepçe kullanabilmek ayrıca NATO ülkelerinde kullanılan modern hafif ve ağır tankları kullanabilmek


Ralli ve ekstrem sürüş becerisi (Zorunlu)
Formula-1 tecrübesi (Tercih edilir)


Dünyaca ünlü üreticilerin pistonları,motorları,şanzımanları,ateşleme sistemleri,dahili bilgisayarları,ABS,ABD,GPS ve araç içi ses sistemlerini tamir etme becerisi ve tecrübesi (Zorunlu)


Araba boyama tecrübesi (Tercih edilir)


Başvuracakların BMW,General Motors ve Bosch firmalarından iki seneden eski olmamak kaydıyla sertifika almış olmaları gerekmektedir.


Ücret: Saat başına 35-45 TL (Mülakat sonucuna bağlı olarak)


Eğitim: Mühendislik mezunu


Altta 3 ila 5 yıl arası Honda Civic kullanma tecrübesi  gibi bir yorum vardı oda çok hoşuma gitti ayrıca paylaşmak istedim.
NOT: Blogger'in yazım aracı font ve renklerde fena sapıtabiliyor o konuda affınıza sığınıyorum.

24 Mayıs 2011

Posted In: Gezegen, programlama

akif beki’nin hezeyanları

Sevgili Akif Beki; Marguerite Yourcenar “Hayatın bize rüya kadar saçma gelmemesinin nedeni alışkanlıktır” demiş ya, sakın bu filtreleme / sansür uygulamalarının size rüya kadar saçma gelmemesinin (çok doğal gelmesinin) nedeni de alışık olduğunuz biat kültürü olmasın?

17 Mayıs 2011

Posted In: btk, Genel, Gezegen, internet, internetime dokunma, sansür, serbest, yasaklar

LinuxTag Berlin – 3’üncü gün

Bugün LinuxTag’daki yine çeşitli ana temalar vardı. Ben de “Cross-distro” temasıyla ilgili seminerlere katıldım. Genel olarak bugünkü konular çok daha güzeldi. Yine bazı sunucuların konuşma yeteneği yüzünden verimsiz geçenler de vardı (anlatamadılar pek). Aşağıda girdiğim konuşmalar mevcut. Konuşmalar sırasında olabildiğince yazmaya çalıştım.

“Cross-distro” bir çok dağıtımın beraber çalışmasını sağlamak için ortaya atılan bir terim. Bildiğiniz gibi her dağıtımın kendine has paket yöneticisi var, kendine has tekonolojileri var, farklı hedefleri var vs… Örneğin paketleri yaparken bir uygulama için her dağıtım ayrı bir isim kullanabiliyor. Çoğu zaman başkasının yaptığı işi tekrar tekrar yapıyoruz. Neden her dağıtımda isim farklı mesela ? Ya da bir paket’in lisansını belirlerken neden zorluk çekiyoruz, halbuki bazı dağıtımlar çoktan bu bilgiyi buldu ve paketlerine yerleştirdi.

Bu gibi sorunları ortadan kaldırmak için ve gelecekte ortak bir payda’da oluşmak için yavaştan tüm dağıtımlar “cross-distro”‘ya önem vermeye başlamış. Bunun en güzel örneğin Gnome 3’de yaşandı, openSuse ve Fedora’daki geliştiriciler beraber çalışıp güzel bir Gnome 3 ortaya çıkardılar.

Her neyse bu kadar ön bilgi yeter, başlayalım sunumlara :)

*** Pushing for more cross-distro collaboration ***

Sunumu veren openSuse Booster’lerinden Vincent Untz. Dağıtımlar arasındaki iletişim eksikliğinden dem vurdu. Kimin ne yaptığını çoğu zaman bilmiyoruz. Çünkü ortak bir paydada buluşulmuyor. Mesela neden yüzden fazla dağıtım var ? Bunun çok olduğunu söylüyor. Ve çoğu zaman hepimiz aynı şeyleri yapıyoruz.

Beraber çalışma ve farklılaşma iki ayrı kutup. Buna iyi karar vermek lazım. Cross-distro için son 10 yıldır neler yapıldı ? Freedesktop kuruldu, freedesktop adı altında bir takım standartlar yazıldı ve buna uyulmaya sağlandı. Desktop Summit altında toplantılar yapılıyor her sene, Gnome ve Kde geliştiricileri bir araya geliyor. Herkes mühendis olduğu için arkadaşca geçiyor ortam. Verimli olduğundan bahsetti.

Bazen kötü örnekler de olabiliyor. Mesela gnome-system-tools uygulaması. Her türlü işi yapıyor fakat zamanında Ubuntu dışında kullanan çok az insan oldu. Gnome’cılar tarafından çıksa da, bu uygulama ayarları kendine has formatı ile kaydediyordu. Halbuki her dağıtım farklı ayarlama dosyalarına sahip. Bunun dışında uygulamaların açıklamalarını ortak bir web sitesinde çevirmeye çalışılmış. Fakat yine zaman darlığından çok fazla kademe elde edilmemiş. Bunun dışında LSB de bir çok kişi tarafından adapte edildi, ama hiç biri içine sinerek yapmadı bu işi.

Bunu önüne geçilebilinri, upstream ile omuz omuza çalışmak gerekiyor. Gnome 3 konusunda Suse ve Fedora çok iyi çalışmış. Bunun meyvelerini şimdi topluyorlar. Güvenlik açıkların kapatılması ile ilgili dağıtımlar güzel bir iş birliği içinde olduğundan bahsetti. AppStream projesi başlatıldı (toplantı yapmışlari Debian, Fedora, Suse, Ubuntu katılmış, çok güzel geçtiğinden bahsetti). Ayrıca “Licesing Summit” adı altında lisans çalışmaları için bir toplantı düzenlendi. Systemd projesini de örnek gösterdi, dağıtımlarla konuşularak yapıldığı için herkes tarafından kabul görmüş (örneğin systemd öntanımlı dosyaları bulamadığı zaman, başka dosyaları okumasına imkan veriyor, yani hiç bir şey hardcoded değil, bu yüzden her dağıtım tarafından kolayce adapte edilebilir hale geliyor)

Cross-distro için neler yapılabilinir ? Destek konusunda çok sıkıntılı olduğunu söyledi. Mesela Suse çıkardığı dağıtımlar için 5 senelik destek veriyor, fakat üzerindeki Gnome sürümü 5 sene destek sağlıyor mu ? 2-3 sene sonra yeni bir sürüme geçtiklerinde Suse ne yapacak ? Gnome ve Kde bu konuda bir yol bulabilir diyor kendisi.

Paket yapımı hakkında belgeler mevcut, herkesinki farklı, örneğin Debian bu konuda çok sağlam temmeler atmış. Suse ve meiga örnek almış,ama Fedora örnek almamış. Desktop summit adı altında masaüstü dağıtımları buluşuyor, neden bir Distro summit olmasın diyor ? Sadece dağıtımların buluştuğu ve ortak kararlar alındığı bir konferans.

Dipnot: Konuşmasında sık sık Fedora’dan bahsetti. Fedora ve Suse’nin Upstream ile ne kadar içli dışlı çalıştığından bahsetti. Ama Ubuntu’nun tam tersine hiç bir şey yapmadığını ve Upstream ile pek çalışmadığından bahsetti. (Bunu sadece Suse’ciler değil, Fedora’cılar da sık sık söyledi)

Bunun dışında genel izlenimim (diğer konuşmalardan da yola çıkarak) dağıtımların artık kendine has teknoloji yaratmayı bırakmalarıdır. Artık herkes bir teknoloji belirleyip ona destek veriyor. Upstream dediğimiz de bu, yani örneğin systemd gibi bir şeyi yeniden yazmak yerine, doğrudan systemd’ye destek vermeye çalışıyor herkes. Gnome 3’de bunun çok meyvesi toplanmış. İleriki senelerde bu ciddi şekilde artacak. Yavaştan buraya adapte olmalıyız. Yoksa ileride çok sıkıntı yaşayacağız. (Fedora ile ilgili bir konuşma’nın notları da mevcut, onda bu daha belirgin ve ne demek istediğimiz daha iyi anlayabilirsiniz, 4’üncü gün yazısından okuyabilirsiniz.)

*** How automated testing helps distributions ***

Bu sunumu openSUSE test takımından **Bernand Wiedermann **sundu. Test yapmak ve test senaryoları oluşturmak da her dağıtımın olmazsa olmaz bir parçası. Test ekipleri bu işleri kolaylaştırmak için bir takım otomatikleştirme işlemlerine giriyor. Bernand da otomatik test yapma konusunda kendi deneyimlerini anlattı.

Dağıtımlar çok kompleks yapılar, her daim bir şey değişiyor. Küçük bir değişim bile çok büyük felaketlere yol açabiliyor. Ayrıca başka bileşenleri de bozabiliyor.

Düşük kaliteli yazılımlar istenmiyor. Çünkü düşük kaliteli yazılımlar morali bozuk testçiler ortaya çıkartıyor. Bunlar da bu yüzden yaptıkları işi kötü bir şekilde yapıyorlar. Test’leri kötü bir şekilde ele alıyor. Bunun sonuncunda da yine kalitesiz yazılımlar ortaya çıkıyor.Halbuki test sürecini iyileştirmenin herkese faydası var. İyi bir test süreci iyi yazılımlar ortaya çıkacaktır. Kaliteli yazılımlar da mutlu testçilere yol açıyor. Mutlu testçiler de kaliteli test süreci ortaya çıkartıyor ve döngü bu şekilde devam ediyor.

OpenSuse bu süreci iyileştirmek adına otomatik test süreçi geliştiriyor. http://openqa.opensuse.org/ adresinden bakabilirsiniz. Bernand’ın kendi oluşturduğu bu framework ile çeşitli test senaryorları yapılabiliyor. Bunların arasında:

  • baştan kurulum·

  • bir sürümden başka bir sürüme güncelleme (2009.2’den 2011 gibi)

  • yazılım testleri

  • regression testleri

  • benchmarking

Ama testler sadece hataların varlığını gösterir, saklı bir sürü hata hala yerinde duruyor ve sayıyor.

Kendisi sonra bir demo gösteriyor. Openqa adresinden tüm süreçler gözüküyor. Her adımın ekran görüntüsü adım adım alınıyor ve web sitesinden bakılabiliniyor. Eğer bir hata olduğunda ekran görüntüsünü alıp paketçiye yolluyor. Ciddi şekilde efor edilmiş güzel bir site ortada duruyor. İyice incelemek gerekiyor.

Bunun dışında başka özgür otomatik test yazılımların olduğundan bahsetti. Bunlar da KVM-autotest, Sikuli ve Selenium

Sununmdan sonra Bernand’a farklı ekran kartları (marka ve model çeşitliliği) ile testler nasıl yapıldığını sordum. Kendisi de bu otomatik test işinin ilerlediğini, şu an için genel olarak yukarıda da bahsedilen senaryolar düşünülmüş. Mesa ile ilgili test’lerde zaten çok hata aldığını ve yol alması gerektiğini söyledi.

Bernard’ın sunum içeriği çok güçlü idi. Fakat kendisi anlatma konusunda pek iyi olmayan arkadaşlardan biri idi. Bence bu tarz işleri konuşmayı iyi yapan insanlar yapması gerekiyor. LinuxTag’da çok şahit oldum buna çünkü, çok güzel ve içeriği kaliteli sunumlar, boş yere heba oldu.

*** Sharing Open Source License and Copyright Data with SPDX *** Bu sunumu da HP’den Martin Michimayr verdi. Konu dağıtımlardan çok kurumsal yazılımlar ve ekosistemini ilgilendiriyor gibi idi (yani enterprise uygulamalar için). Yine de bir iki güzel bilgiler içeriyordu.

Temel sorun şu: Özgür yazılımların sunduğu lisans bilgileri her daim eksik, yanlış ve taşınabilinir şekilde değil (özellikle taşınabilinir konusunda vurgu yaptı). Buna bir örnek olarak, yazılımların içindeki dosyaları verebiliriz. Bazı dosyalar GPL veriliyor, bazıları LPGL olarak veriliyor. Tüm program türlü türlü lisanlar karmaşık şekilde dağıtılıyor.

Bununla bitmiyor, bu yazılım farklı program yazılım bileşenlere dahil olabiliyor (örneğin bir dağıtıma girebiliyor, dağıtımın lisans gerekliliği ile paketin sunduğu lisans gereklilikleri arasında uyumsuzluk mevcut).·

Bu gibi sorunların önüne geçmek için SPDX adı altında bir standart geliştirilmeye çalışılıyor. Bu format bir yazılım paketinin bileşenleri, lisansları ve yükümlülükleri hakkında temel bir iletişim sağlamayı amaçlıyor.

Bundan sonrası SPDX’in yapısı ve nasıl kullanabileceği hakkında idi. SPDX gibi seçenekler düşenenler SPDX’in sitesinden daha fazla bilgiye ulaşabilir.

*** Project Bretzn ***

Bu sunum Kde geliştirici ve Kde-look gibi sitelerin tümümün bakımını ve liderliğini yapan Frank Karlitscheck tarafından yapıldı. Ön bilgi olarak, Bretzn’in temel hedefi kolay bir paket yapımı ve paket dağıtımı sunmak.

Frank başlıyor, soruyor bize, bizi ne motivite ediyor ? Şu anki durumumuz nasıl ? Yazılım geliştirici tarafından yazılıyor. Ardından bir inşa sistemi seçilerek onunla birlikte farklı mimariler için derleniyor. Derlendikten sonra bunun web sitesine koyuyoruz, yavaştan arkadaşlara tanıtıyoruz. Bununla yetmiyor, gidip twitter, facebook gibi sosyal mecraları da kullanıyoruz. Yazılım kullanıcılar tarafından benimsendikten sonra bir dağıtıma aldırtmaya çalışıyoruz. Dağıtım da doğrudan kararlı depoya almıyor, ortalama olarak 8 ay bekliyoruz kararlı dağıtıma girmesi için.·

Tüm bunları yaptık, şimdi artık birilerin kullanmasını umabiliriz :)

Bretzn tüm bunları **10 dakikaya **indirmek gibi idiallı bir sözle çözmeye çalışıyor.

Bretzn bir Qt Creator eklentisi. openSUSE’nin obs sistemi ve Meegoo’nun build servisi ile entegre çalışıyor (bir fikir edindiniz mi ?). Bu gibi servisler ile entegreli çalıştığı için cross-compile işini bunlar hallediyor. Paketi bu servisler inşa ettikten sonra, yine Bretzn tarafından başka servislere yollanıyor. Burada başka servislerden kastım Uygulama Mağazaları. Yavaş yavaş, Apple’nin AppStore örneği gibi Linux camiasında da bu tarz siteler açılıyor. Bunlara örnek olarak Meego Garage, openSuse AppStore, openDesktop.org gibi yapıları söyleyebiliriz.

Yayınladıktan sonra da yine yukarıda bahsettiği liste, rss, twitter, facebook gibi yayınlama kanalları da kullanılarak “reklam” yapma durumu mevcut.

Şöyle bir baktığımızda Bretzn’in aslında OBS sistemine birer frontend olduğunu ve paketlerin de bizim Pisido gibi araçlar gibi kolayca yapılmasını sağlamak. Fakat buradaki asıl amaç, paket yapmaktan ziyade paketi yayınlamak ve tanıtmak. Ben hala Pisido,pisiyap gibi programların paket yapmak için mantıklı araçlar olduğunu düşünmüyorum. Bunu da yine burada farkettiğim için soru hakkımı ele alarak Frank’a şu soruyu sordum :

“Paketlerin 10 dk’da yapılmasından ve yayınlanmasından bahsettiniz, halbuki Bretzn yapısı sanki %10 paket yapımı, %90 da paket tanıtımı ve yayımı. Örneğin sizin bu projeniz ile bir Apache, Chromium, Firefox gibi paketler yapmak mümkün mü ? Sizce mantıklı geliyor mu ?

Kendisi de hemen gülümsedi ve haklı olduğumu, Bretzn’in aslında bu tarz programlar için olmadığı, daha çok basit programlar için olduğundan bahsetti. Paket yapımını ve geliştirmesini yine kendimiz, düzgün işleyen süreçlerle yapmamız gerekiyor, daha sonra yaptığımız paketin inşa dosyalarını bretzn sistemi ile diğer inşa sistemlerine yüklememiz gerekiyor (OBS gibi).

Bretzn güzel bir proje’ye benziyor. Biraz beklemek lazım, tutar mı tutmaz mı emind değilim, zaman gösterecek :)

*** OBS - OpenSuse Build Service ***

Bununla ilgili ilk gün eski Pardus geliştiricilerinden** İsmail Dönmez **ile güzel bir konuşmamız olmuştu. Kendisi şimdi openSuse’de Booster olarak göreviyor alıyor. Birinci elden OBS ile ilgili bilgiler edindim diyebilirim. Bunları Geliştirici listesinde paylaşmıştım, fakat buraya da ekleyeyim, geliştirici listesini takip etmeyenler olabilir.

Bu birinci gün İsmail Dönmez ile ilgili elde ettiğim bilgiler dışında, bugün edindiğim kısa kısa bilgiler şunlar idi. Kısaca OBS’yi anlatmaya çalışayım. OBS, openSuse tarafından geliştirilen bir sistemin genel adıdır. Temel amacı, geliştiricilerin kolay bir şekilde paketlerin yapması ve esneklik sağlamaktır. Örneğin bir geliştirici paketi derliyor ve depoya almaya çalışıyorsa türlü türlü sorunlar ile karşılaşabiliyor. Mesela bağımlılık eksik olabilir ya da bir mimaride çalışabilirken başka bir mimaride sorun yaşayabilir (32bit 64bit farklılığı gibi).

OBS’i şu an kullanan 21 bir tane dağıtım varmış. Evet openSuse tarafından geliştiriliyor, ama kodları açık ve dileyen kendi paket sistemine göre değiştirebiliyor. Opensuse bunun için bir web arayüzü de yapmış: https://build.opensuse.org/. OBS’nin bunun dışında OSC adı altında bir konsol arayüz uygulaması ve açık bir API’si mevcut (yani OBS için farklı uygulamalar geliştirebilirsiniz, yukarıda bahsettiğim Bretzn buna bir örnek).

Sununmda sonrasında benim İsmail Dönmez ile yaptığım 1-2 saatlık workshop ile ilgili bilgiler mevcut idi. Birinci gün yaptığımız bu workshop ile bilgiler de şu şekilde (geliştirici listesinde paylaştığım yazının aynısı):

İki ana bileşen var, bir OBS (OpenSource Build Service) ve OSC (OBS için konsol frontendi). Bunların kodu açık ve kullanılabilinir halde. OBS sisteminin bir de web arayüzü mevcut.

OBS sistemini ya Suse’nin kendi sunucularını kullanarak üye olabiliyorsunuz, ya da kendimiz sunucuları kurup kullanabiliyoruz. Her iki türde de OBS’de bir takım değişiklikler yapmamız gerekiyor. Bizim buildfarm.py’yi adapte etmemiz gerekiyor mesela, pspec.xml’e parser yazmak gerekiyor. Bunları yapabilmek için de Perl bilgisi gerekiyor çünkü OBS sistemi Perl ile yazılmış. Örneğin OSB’yi kurduk ve OSC de kullanır halde. İşlevler nedir, ne yapabileceğiz, neye derman olacak derseniz, onlar da şunlar.

OSC aslında git-vari bir fronted (ozan daha çok svn’e benziyor dedi, ki haklı da :)), bazı komutlar şu şekilde:

  • osc co home:farslan

  • osc commit -m “Initial release”

  • osc delete home:farslan chromium-browser

  • osc up

Örneğin commit ettikten sonra, daha önce yine OSC ya da web arayüzden belirlediğiniz mimarilere göre derlemeye başlıyor. Herhangi bir commit’de doğrudan derlemye başlıyor. Bunu neye göre yaptığını sorduğumda, SUSE’cilerin bağımlılıklara göre ayarlardıklarını söyledi. Yani örneğin ben vim’e bir commit yaptım, gcc’ye de başkası bir commit yaptı. O zaman sıraya ilk gcc giriyor.··

Build başlamadan önce her bir build aşaması için sanal makine oluşturuluyor. Makine’de haliyle hiç bir bağımlılık mevcut değil, on-the-fly bağımlılıkları kuruyur (bizim farmdaki gibi herşeyi kurulu değil yani). Yani vim için bir değişiklik mi yaptım, osc ile commit ettim örneğin, OBS gidip benim için yeni bir sanal makine kurup derlemeye başlıyor. Güzel olan ise osc ile doğrudan farm’da derlenen çıktıları görebilmemiz, hatalara müdahele edebilmemiz.

Burada aklıma takılan, bazı paketlerin derleme işlemi zaten çok uzun sürüyor (örnek: chromium-browser), öntanımlı olarak her sanal makine de aynı olduğundan uzun sürebilir. Fakat bunun da önüne geçebiliriz. OBS tarafı bizim elimizde olduğunda, doğrudan ayrı cluster’ler oluşturabiliriz. Böylelikle derleme süresi uzun süren paketlere daha güçlü bir sanal makine imkanı verebiliriz mesela. Bunların hepsi bizim elimizde.

Genel olarak geliştiricilerin ev dizinleri oluyor home:farslan gibi. Bir de ayrı dizinler mevcut openSUSE:Factory (bizim devel), openSUSE:11_4 (bizim stable), vs.. Geliştirici sıkıntısı olmadığından Factory’de yüzlerce paketçi ve bunların paketleri mevcutmuş. Peki bunların koordinesi nasıl oluyor ?

Mesela chromium’un yeni bir sürümü çıktı. Ben bunu openSUSE:Factory’de güncelledim. Derlendi ve bana gerekli bilgileri verdi. Fakat bazen bir paketi güncellerken onlarla beraber başka paketleri de derlemem gerekiyor (ABI kırıldı). O zaman ilk önce asıl paketi (mesela chromium) home:farslan dizinine kopyalıyorum. Sonra da diğer paketleri kopyalıyorum. Burada tıpkı bizim playground gibi düşünebilirsiniz. Fakat buradaki farklı olan, sizin yaptığınız değişikliklerin de doğrudan benim home:farslan’a yansımasıdır. Yani mesela ben cups’u kopyaladım buraya, Ozan’ın bundan sonra yapacağı tüm commitler de bana yansıyacak. Ama bu da bir opsiyona bağlı, kopyalareken seçenek sunuluyor, istediğimde değişiklikler yansayacak, istemediğimde yansımayacak.

Şimdi tüm paketleri aldım, güncelledim iyice. Bunları stable’e merge edeceğim değil mi ? Doğrudan OBS’nin arayüzünden bir review isteği yolluyorum. Review isteği yolladıktan sonra benim yaptığım tüm commitler ve değişiklikler (paketlerle ilgili olanlar) doğrudan review ekibine gidiyor.

Review ekibi hem otomatik botlardan oluşuyor hem de insanlarda. Otomatik botlar yapılan değişiklerin kod düzenine kontrol ediyorlar (bizim ismail.py gibi). Bunun dışında legal-team de mevcut, bu takım da sadece lisans bilgilerine bakıyor. Bu review ekibi içinde paketin bakıcısı da mevcut (başkasının paketini değiştirdiğini mesela), ayrıca bir de openSuse:11_4 sürüm yöneticileri mevcut. Bunlardan hepsinden ACK alması lazım.··

Yani bu adamlar bir nevi bizim Commit listesini takip ediyorlar ve yapılan değişikleri review ediyorlar. Onların görevi bu. OBS’nin bir güzel yanı ise, ACK aldığınız paketi otomatik olarak sizin ev dizininzden silmesi. Yani paket’den onay aldığınızda sizin ev dizinizdeki bununla ilgili tüm paketler siliniyor (bu da yine opsiyone bağlı)

Bu merge ve review kısımları bizde bir çok yere, özellikle paket reviewlerine uygulanabilinir. Ciddi avantaj sağlayacağını düşünüyorum. *****

Evet bu kadar. Bunların dışında systemd ve dracut sununmlarına da girdim. Fakat oradan aldığım notlar çok dağınık ve güzel bir blog yazısı temsil edecek şekilde değil. Önümüzdeki günler bu notları düzenleyebilirsem bu iki şey hakkında da yazmayı düşünüyorum.

17 Mayıs 2011

ARDrone

Okulda üzerinde çalışacağım (en azından çalışmaya çalışacağım) cihazı sizlere de tanıtmak için bir yazı yazmak istedim.
Adını başlıktan da anlayabileceğiniz gibi cihazın adı ARDrone. Peki nedir bu ARDrone ?
ARDrone en kaba ifadeyle dört pervaneli uzaktan kumandalı bir helikopter (İngilizcesiyle quadrotor veya quadricopter bu araçlardan Avatar'ı izlediyseniz veya Crysis oynadıysanız görmüşsünüzdür). Ama çok önemli bir farkla normal modellerin aksine radyo dalgalarıyla değil  Wi-Fi ağları sayesinde kontrol ediliyorlar. Diğer model araçlardan bir başka ilginç farkı ise kullanmak için spesifik bir kumandaya ihtiyaç yok resmi olarak iOS işletim sistemine sahip herhangi bir cihazdan kontrol edilebiliyorsa da açık kaynak SDK (Geliştirme lisansını okudum özgür yazılım değil gerçek anlamda açık kaynak) sayesinde herhangi bir kişisel bilgisayardan kontrol edilebilme özelliğine de sahip. Aslında ARDrone'un klasik uzaktan kumandalı modellerle aynı kefeye koymak da pek mümkün değil. Hatta ARDrone'u bir UAV (İnsansız Hava Aracı) olarak adlandırmak bence daha doğru. Çünkü onu kullanırken amaç uçurabilmek değil. Zaten üzerindeki bilgisayarla kullanıcının işini çok kolaylaştırıyor. Altındaki kamera ve ultrason alıcı ile yüksekliğini belirleyerek otomatik olarak inebiliyor veya kalkabiliyor komut verilmediğinde sabit bir yükseklikte durabiliyor. Ayrıca önünde de bir kamera bulunuyor bu sayede çok rahat kontrol edebiliyorsunuz.Aklınıza madem uçurmak çok kolay ne zevki kalır diye haklı bir soru gelebilir. ARDrone zaten arttırılmış gerçeklik (augmented reality) oyunları için tasarlanmış bir araç. Arttırılmış gerçeklik oyunları derken şunu kastediyorum. ARDrone'un ön kamerası belirli işaretleri algılayabiliyor. Bu algılama olayı sırasında kumandada belirli animasyonlar gösterecek oyunlar tasarlanabiliyor. (Mesela ARDrone bir işaret algıladığı zaman kumanda ekranıında ona ateş ettiğinin gösterilmesi,birden fazla ARDrone'un it dalaşı yapması vs.) Araç iç ve dış mekan uçuşlarına uygun hatta bu nedenle iki farklı gövde ile geliyor.
ARDrone SDK ve yazılım geliştirmeye ayrıca değinmek istiyorum ama önce ARDrone özelliklerini vereyim.
Özellikler

  • Geçici dijital Wi-Fi bağlantı (Wi-Fi router’a gerek yoktur). 
  • Menzil: 50 metreye kadar
  • 2 video kamera ile iPod touch® / iPhone®/ iPadTM ekranına canlı görüntü
  • Otomatik stabilizasyon ve tam pilotaj yardımı (6 metreye kadar yükseklik)
  • iPod touch® / iPhone®/ iPadTM üzerinde acemi ve uzman modu ile dokunmatik kontrol arayüzü
  • Maksimum hız: 5 m/s; 18km/h
  • Bağlantı için maksimum yükseklik: 50 metre
  • Çalışma süresi: 12 dakika
  • Güvenlik sistemi: 
  • Kapalı mekân uçuşları için EPP gövde
  • Temas halinde otomatik pervane kilitleme
  • UL2054 batarya
  • Acil durumda motorları durduran kontrol arayüzü
  • Ebatlar:
  • Kapalı mekân uçuşları için koruyucu gövde ile birlikte: 52,5x51,5cm Ağırlık: 420 g
  • Dış mekân uçuşları için şekillendirilmiş gövde ile birlikte: 45x29cm 
  •         Ağırlık: 380 g

  • Radyo dijital bağlantı
  • Geçici moda gömülü ve yapılandırılmış entegre Wi-Fi b/g modülü 

  • Video
  • Ön kamera: Geniş açı kamera
  • VGA kamera (640x480 pixel), 93° geniş açı diyagonal objektif, CMOS sensör
  • Şifreleme ve iPod touch® / iPhone® / iPad™’a görüntü akışı
  • Düşman aracını algılama
  • Çekim doğrulama
  • Tahmini mesafe
  • Mesafe algılama: 5 metre
  • Engel algılama
  • Engel konumunu hesaplama
  • Sanal nesne konumunu hesaplama
  • iPod touch® / iPhone® / iPad™ ekranına video aktarımı

  • Dikey kamera: Yüksek hız kamerası
  • QCIF kamera (176x144 pixels), 64° diyagonal lens, CMOS sensör
  • Yatay hız değişikliği hesaplama: 60 fps
  • Şifreleme ve iPod touch® / iPhone® / iPad™’a görüntü akışı

  • Otomatik pilot
  • Otomatik kalkış ve iniş
  • Kapalı ve dış mekânda otomatik sabit nokta (Rüzgâr hızı < 15km/h, Yükseklik < 6 metre 
  • Otomatik yükseklik ve hız ayarı (6 metreye kadar)
  • Kapalı (hassas) ve açık hava (hız) uçuşları için 2 komut modu

  • iPod touch® / iPhone®/ iPad™’de dokunmatik kontrol arayüzü
  • Acemi(2 komutlu) ve Uzman (1 komutlu) modlar
  • AR.Drone’u kumanda etmek için iPod touch® / iPhone®/ iPad™ ivmeölçerini kullanır
  • iPod touch® / iPhone® / iPad™’in hareketlerini kopya eder (ileri-geri, sol-sağ)
  • Motorları durdurmak için acil durum düğmesi

  • Tam Ataletsel Ölçüm Birimi
  • MEMS 3 eksen ivmeölçer
  • MEMS 2 eksen XY ve 1 eksen Z jirometre
  • Açısal hız tahmini
  • Sapma, eğim ve yuvarlanma açısı tahmini
  • Ölçüm frekansı: 200 Hz
  • Patentli anti-vibrasyon sistemi

  • Ultrason yükseklikölçer
  • Emisyon frekansı: 40kHz
  • 6 metre menzil
  • Ölçüm frekansı: 25 Hz
  • Başka bir AR.Drone’dan gelen ultrasonik sese karşı sistem 

  • On-board bilgisayar
  • CPU Parrot P6 ARM926 çekirdek 32bits-468MHz
  • Gömülü Linux platformu
  • 128 MB DDR RAM
  • 128 MB flash memory
  • Wi-Fi ya da USB üzerinden gömülü yazılım güncelleme
  • Havacılık yapısı
  • Yüksek verimlilikte pervaneler (Parrot AR.Drone için özel tasarım)
  • Karbon tüp yapısı
  • Fiber-takviyeli PA66 plastik
  • Kapalı mekân uçuşlarında pervaneleri koruyan EPP gövde
  • Dış mekân uçuşları için şekillendirilmiş EPP gövde

  • Motor ve enerji
  • Değiştirilebilir 4 fırçasız motor (3 500 rpm, Güç:15W)
  • Fırçasız motorlar için 4 kontrolör (dijital komut)
  • Lityum polimer batarya (3 gözlü, 11,1V, 1000 mAh) UL2054
  • Batarya şarj süresi: 90 dakika
Özelliklerine baktığımızda üzerinde şu an kullandığım cep telefonundan (Samsung Corby Pro) daha güçlü bir donanım barındıran ARDrone'u bir RC araç değilde UAV olarak olarak adlandırma isteğimin anlaşılabileceğini düşünüyorum. Ayrıca ARDrone'un günümüz teknolojisinin en büyük sorunlarından biri olan güç sorunundan  nasibini aldığını görüyoruz.Üzerindeki 1000mAh batarya ile sadece 12 dakika gibi bir ortalama uçuş süresi var.
Batarya daha yüksek kapasiteli başka bir tanesiyle değiştirilmediği sürece uçuş ömrü oldukça kısa.
Bu kadar yetenekli bir aracın bir geliştirme ortamı olarak da kullanılabilmesi için üretici firma Parrot bir açık kaynaklı bir SDK yayınladı. Bu SDK ARDrone'un Redmine sayfasından edinilebilir. Geliştirici sözleşmesini onayladıktan sonra SDK'yı ve yüz sayfalık developer guide'ı indirebiliyorsunuz. Önce sözleşme hakkında biraz bilgi vereyim. Parrot kendi fikri mülkiyet haklarını korumak için koyduğu bir kaç maddenin [mesela kodu tekrar dağıtırken Parrot'un telif hakkı bilgisini eklemek,geliştirilen yazılımların reklamında Parrot ismini kullanmama vs.]yanında geliştirdiğiniz yazılımın tüm fikri mülkiyetini geliştiriciye bırakıyor. SDK'nın kullanım amaçlarıyla ilgili bazı kısıtlamalar da mevcut. Şahsi fikrim sözleşmenin gayet makul maddeler içerdiği ve geliştiriciye ağır kısıtlamalar getirmediği yönünde. Sıfırıncı özgürlüğü sunmasa bile genel anlamda özgür yazılım esaslarına da pek ters düşmüyor. Parrot kaynak koda erişim, kaynak kodu düzenleme,dağıtma gibi temel özgürlüklerini geliştiricilere sunuyor.
Dökümantasyonda ARDrone'un genel yapısından,SDK hakkında kısa bir özet,API fonksyonları,temel komutlar,bilgi akışı yönetimi,drone ayarları gibi teknik bilgilerin yanı sıra Linux,Windows işletim sistemlerinde programlama ile ilgili temel veriler yer alıyor. Gerçi geliştirici sözleşmesini onaylamadan dökümanların indirilememesi olayını mantıklı bulmadım.
Peki indirdiğimiz SDK'nın içerisinde neler var.
ARDroneLIB : ARDrone ile ilgili kütüphane ve API'leri içerir.
ARDroneTool : ARDrone'un yönetimi ile ilgili hazır araçları içerir.
İPhone örneği.
Ayrıca ARDrone yazılımlarının farklı platformlarda geliştirebileceği gibi soket programlamayı destekleyen farklı programlama dilleri ile geliştirebileceğini öğrendim.
Sorularınız ve sorunlarınız varsa ARDrone API forumuna başvurabilirsiniz. Aynı zamanda ARDrone ile ilgili bir topluluk sitesi olan http://www.ardrone-flyers.com/ adresi de mevcut.

16 Mayıs 2011

Posted In: Gezegen, KOÜ Bilgisayar Müh., programlama

Evinizdeki sunucu için kendinizi fişlemeniz gerekiyor!

Evimdeki sunucu için yaptığım BİMER başvurusuna ...tib.gov.tr adresinden yanıt geldi nihayet ve beklediğim gibi faaliyet belgesi alarak kendi kendimi fişleme yapmam gerekiyormuş, almazsam yönetmeliğin 4.maddesine göre internetim kesilecek. Ayrıca 5651'e göre log kaydı alıp 6 ay saklamam da gerekiyor.

Yanıt şöyle;

Sayın YETKİLİ,

İnternete açık hizmet ve içerikleri barındıran sistemleri sağlayan/işleten
gerçek veya tüzel kişiler yer sağlayıcıdır. Yer Sağlayıcılığı hizmetini
ticari olarak yapmasa bile web sitelerini kendi sunucularında barındıran
gerçek veya tüzel kişilerin Yönetmelik gereğince Yer Sağlayıcılığı
Faaliyet Belgesi almaları gerekmektedir.

Bu durumda sizinde Yer Sağlayıcı Faaliyet Belgesi almanız gerekmektedir.

Yer Sağlayıcılığı Faaliyet Belgesi almak için;
1) http://faaliyet.tib.gov.tr/yetbel/ adresinden kayıt olarak sisteme
giriş yapıp buradaki uygun elektronik formun eksiksiz doldurulması
suretiyle başvuruda bulunmak,
2) Ek 5'te örneği olan dilekçeye Elektronik ortamda doldurulan başvuru
formunun çıktısı eklenerek “Bilgi Teknolojileri ve İletişim Kurumu
– Telekomünikasyon İletişim Başkanlığı / İncek mah. Boztepe sok.
NO:125 06836 Gölbaşı ANKARA adresine gönderilmesi gerekmektedir.
3)Tüzel kişilerin (Anonim ve Limited Şirketler) ayrıca şirketin Ticaret
Siciline tescil edildiğini belirten son altı ay içinde alınmış Ticaret
Sicil Kaydı aslı veya noter tasdikli sureti ile Şirketin imza sirküleri
aslı veya noter tasdikli suretini de göndermeleri gerekmektedir. (Yer
Sağlayıcı Faaliyet Belgesi ücretsizdir.)

Telekomünikasyon İletişim Başkanlığı

Çok şükür ki fişleme ücretsiz yapılıyormuş, ne kadar rahatladım bilemezsiniz. Ancak yönetmeliğin 14.maddesine göre sitemde (jabber veya medya sunucum olsa bile bir sayfa açmam gerekiyor) telefon numarası gibi iletişim bilgilerimi yayınlamak zorundayım aksi halde 10.000-TL'ye kadar para cezası beni bekliyor.

16 Mayıs 2011

Posted In: internet, lkd_gezegen, Özgürlük için

özgürlük paketlere sığdırılamaz

bilgi teknolojileri ve iletişim kurumu'nun 22 Ağustos 2011 tarihinde devreye alacağı yeni internet filtreleme paketleri zaten yasaklarla boğuşan türkiye internet kullanıcıları için daha sevimsiz gelişmelerin ve sansürün yolunu açıyor.

15 Mayıs 2011

Posted In: Genel, Gezegen, internet

Özgürlükiçin.com’da yeni dönem nasıl başladı ve neler yaşadık

2011 Nisan ayı ile birlikte Özgürlükiçin.com'da yeni bir dönem başladı biliyorsunuz, bunu önce Ali Işıngör'ün günlük yazısından ve sonrasında Pardus proje yöneticisi Erkan TEKMAN'ın 24 Mart tarihli günlük yazısından öğrenmiştik. Nisan ayı ile başlayan bu süreçte neler olup bittiği ile ilgili bir not düşülmesi için kısa bir özet geçmek istedim bugün.

Yukarıda bağlantısını verdiğim günlük yazılarını okumayanlar için özetlemek gerekirse Özgürlükiçin.com, Pardus'un topluluk ilişkilerini yönetmek amacıyla ve hizmet alımı yoluyla görevlendirdiği özel bir firma tarafından destekleniyordu. Bu firma e-derginin yayına hazırlanması, Ajans Pardus'un hazırlanması, CD Gönder hizmeti, sitedeki beyin ve tema aracının geliştirilmesi, tanıtım amaçlı seminer ve etkinliklerin düzenlenmesi gibi çeşitli faaliyetler yanında sitenin bakımı ve işletilmesiyle ilgileniyordu. Pardus, Nisan ayı itibariyle tüm bu faaliyetleri artık bir firma eliyle değil kendisi yapmaya karar verdi.

Ancak burada benim gözüme çarpan şey proje yöneticisinin "camia ilişkileri işini 2011 yılı Nisan ayından itibaren kendimiz yapmaya karar verdik." diyerek yukarıda saydığım faaliyetleri "camia ilişkileri" olarak tanımlaması veya "camia ilişkileri" içerisinde yukarıdaki faaliyetlerin kast edilmiyor olmasıydı. Hangisinin doğru olduğunu bilmiyorum ama camia ilişkileri ile topluluk faaliyetleri farklı şeylerdir.

Ancak bir şekilde bu ikisinin Nisan ayı öncesinde aynı kabul edildiği ve Nisan ayı sonrasında topluluk faaliyetlerinin camia ilişkileri içerisinde düşünülmediğini gördük.

Her neyse, proje yöneticisinin yazısından Pardus'un camia ilişkileri için "Camia Koordinatörü" (CK) ünvanlı iki kişiyi görevlendirdiğini de öğrendik. CK'lardan Koray LÖKER 25 Mart tarihli günlük yazısında üstlendiği sorumluluğu "Pardus’a yer ve önem veren, bir biçimde katkıda bulunan gönüllüler ve proje arasında bağlantı noktası oluşturmak." olarak özetledi.

Yani çalışma kapsamı sadece Öİ değildi, ancak "Bu deneyimin bir bölümü de, yıllardır projenin desteğiyle yürüyen Özgürlük İçin topluluğunun sürdürülebilirliğini sağlamak olacak." diyerek Öİ topluluk faaliyetlerinin sürdürülmesine de katkı vereceklerini belirtti. Bunun bir gereği olarak Öİ'deki Ajans Pardus'un 57.sayısı CK'lar tarafından hazırlandı ve belki de pek çok kullanıcı Öİ'de bir şeylerin değiştiğini ancak bu şekilde fark etti.

Ancak sadece kullanıcılar değil Öİ yöneticilerinin pek çoğu da yaşanan değişimi anlamakta zorlanıyordu, çünkü uzun yıllardır Öİ'nin nasıl işlediği konusu gündeme gelen bir konu olmamıştı, kısa bir dönem hariç. 2009 Sonunda Öİ için yapılan ihale sürecindeki aksama Öİ faaliyetlerini durma noktasına getirmişti, o günlerde yazdığım bir günlük yazısında bu durumu anlatmıştım ve sanki bu günlerin bir provası gibiydi. Hatta forumlarda Pardus projesinin sona erdiğine dair yorumlar bile okuduk o günlerde. Bu yorumların nedeni de Öİ ve Pardus arasındaki organik bağ ve Öİ'nin resmi destek sitesi olma ünvanıydı. Her neyse, o günler kısa sürede unutuldu ve Öİ pek tartışılmadı.

12 Nisan'da CK'lardan Koray LÖKER Öİ yöneticileri posta listesine gönderdiği bir mesaj ile yöneticileri bir IRC toplantısına çağırdı. Ancak neler olup bittiğini anlamakta zorlanan yöneticilerin sorularıyla tartışma uzadı gitti ve toplantı yapılamadı. Tartışmalara bakınca Öİ katkıcıları ile CK'ların birbirlerini anlama, anlatma ve ortadaki durumu çözümleme konusunda farklı bakış açılarını ve oluşan kaosu görebilirsiniz. CK'lar açısından herşeyin çok net göründüğü yöneticiler açısından ise öyle olmadığı ortaya çıktı.

Bunun nedeni Öİ'nin yıllar içerisinde oturttuğu yönetim organizasyonunun bel kemiği olan firmanın artık olmaması ve bu firmanın yerine geçeceği beklenen CK'ların gerçekte görevlerinin bu olmamasıydı. Yani Öİ'de ayakta duran bir yönetim organizasyonu yerine geriye bağımsız gönüllü yöneticiler kalabalığı (veya tenhalığı) kalmıştı. Öİ Adına insiyatif alacak kimse yoktu. CK'lar süreçleri destekliyordu ama görevleri Öİ adına insiyatif almak değildi.

Sonuç Öİ'nin yönetimsiz kalması ve süreçlerin aksaması oldu. Ben Pardus projesinin plansız hareket etmiş olmasının tüm bunlara neden olduğunu düşünüyorum. Yeni bir organizasyon kurulup süreçleri üzerine almasına zaman tanınmadan eski organizasyonu ortadan kaldırmak bir planlama olamaz.

Bu tartışma içerisinde Öİ'nin teknik altyapısı da gündeme geldi ve Pardus'un bu konuda bir görevlendirme yapmadığını şu mesaj'ın son paragrafı ile anladık. Yani Öİ sitesinin geliştirilmesi ve hata çözümleri şimdilik yapılmayacak demekti bu, kısaca kaderine terk edilmişti veya bu konu hiç düşünülmemişti bile. Bence bu çok önemli bir sorundu ve tekrar gündeme getirerek çözüm arayışını sürdürmek istedim, ancak çok üzerine düşülmediğini anladım.

Nasıl bir organizasyon kurarız nereden başlarız diye düşünmeye, tartışmaya devam ettiğimiz bir dönemde, 6 Mayıs'ta, Pardus'un Öİ için daha büyük bir değişiklik yaptığını listeye düşen yeni bir mesajla öğrendik. Koray bey "Öİ'yi Pardus'un sponsor olduğu bir portal olarak tanımlayıp, sponsorluk sürecini yapılandıracağız. 'Resmi forum/portal' ifadesi hiçbir yerde kullanılmayacak." diyerek Öİ'nin resmi Pardus destek sitesi ünvanının sona erdiğini duyurdu.

Yani artık bir X sitesi ile Öİ arasındaki tek fark Pardus'un Öİ'ye sponsor olması ancak bunun gerekçesi belli değil, yani Pardus neden X sitesine değil de Öİ'ye sponsor oluyor bilmiyoruz.

Yıllar önce bana Öİ'de forum yöneticiliği teklifi geldiğinde kabul etmemeyi görevden kaçmak olarak algılamıştım, bunun nedeni Öİ'nin resmi destek kanalı olmasıydı. Bu nedenim ortadan kalkınca 2 yıldan fazladır sürdürdüğüm forum yöneticiliği görevini de sürdürmeyeceğimi bildirdim.

Aynı mesajdaki "Öİ süreçlerine aktif olarak katılmayıp, sponsor olarak durmaya karar verdik" ifadesiyle artık Öİ süreçlerinin de tamamen gönüllülere devredildiğini öğrendik, tabii başka bir değişiklik yapılmazsa.

Evet gelişmeler böyle ve Öİ'nin bugünkü durumu şu; süreçleri işletecek bir yönetim organizasyonu bulunmayan bir topluluk ve teknik olarak bakımı ve geliştirilmesi yapılmayan Pardus sponsorluğundaki gayrı-resmi bir site.


15 Mayıs 2011

Posted In: lkd_gezegen, öi_gezegen, pardus

Office Belgelerini Dönüştürme

Öyle zamanlar olur ki ofis dökümanlarımızı başka formatlara çevirmek isteriz. Eğer bir kaç dosyamız varsa elimizde sorun değildir. Ancak çoksa ne yapacağız? Windows için ne yapacağız bilmiyorum :D ama linux unuz varsa işiniz kolay;

unoconv sizin için anahtar kelime. Kullanımı basit bu araç uno(openoffice,libreoffice) bağlantısını kullanarak çevirme işlemini başarı ile gerçekleştirebiliyor.

Şimdilik * Red Hat,Debian,Fedora,Mandriva,Ubuntu Lucid,OpenSUSE için paketleri bulunuyor. Ancak diğer dağıtımlarda kullanmak da çok zor değil. (Pardus Kurumsal 2 için olumlu sonuç aldım)

Kullanımı oldukça basit olan araç için şu komutlar yeterli olacaktır.
$ unoconv --listener
$ unoconv -f pdf *.odp *.odt (bu komut ile de dizinde bulunan tüm odp ve odt formatlarını pdf ye çeviriyoruz)

Nasıl? güzel değil mi?

Kim bilir belki bir hayır sever pardus için paketini yapar. :) Acaba kim bu yüce insan :D

:: pdf odp odt doc docx ppt dönüştürme ::

14 Mayıs 2011

Posted In: linux, pardus, Program Tanıtımı, ubuntu

İnternet, filtreler, sansür ve yasaklar…

Son zamanlarda çok fazla tartışılan TİB tarafından getirilen filtrelemeyle ilgili bir şeyler yazmak istedim.

İnternetteki haber sitelerinde, televizyonlarda gazetelerde bu konu çokça tartışıldı çokça yazılıp çizildi. Tartışılması çok güzel  ama bana göre bu konudaki genel problem insanların meseleyi tam anlamıyla anlamayarak eleştirmesi yada savunmaya çalışması ve meseleyi bütün olarak görmekten çok kendilerini ilgilendiren parçalarına bakmaları. Kimi insanlar youtubeun yasaklanıp yasaklanmayacağının derdinde. Kimileri acaba bir gün facebooku da kapatabilirler mi diye korkuyor. Kimisi internetten pornografik içerikleri takip edemeyeceğinin derdine düşmüş. Bazı insanlar blogların yasaklanıp yasaklanmayacağıyla ilgileniyor. Aslında ilgilerin dolayısıyla korkuların farklı olması gayet doğal. Herkesin kendi istediği şeyi savunması da öyle. Ama her zaman için meseleyi bir bütün olarak görmekte fayda olduğunu düşünüyorum. Böylece bizi ve ülkemizi ne şekilde etkileyeceğini daha net görmüş oluruz.

Başlangıç noktası olarak sanırım en uygun şey bu kararın kendisini okumak olur. Buradan ulaşabilirsiniz. Fakat kararın tamamını doğru şekilde anlayıp yorumlayabilmek için hem teknik olarak yeterli seviyede bilgiye hem de ne dediğini düzgün anlayıp ne şekilde kullanılabileceğini kavrayabilmek için belirli miktarda hukuk bilgisine ihtiyaç duyuluyor. İkisinin kesişimi pek de büyük bir insan topluluğunu kapsamadığından tek başına kararı okumak yeterli olmayabiliyor. Benim görüşüm açıkçası okuduğum yorumlarla şekillendi. Zaten bu konuda en güzel içeriği de sosyal medyada gördüm şimdiye kadar.

Ön bilgi olarak DNS ile uygulanan yasaklar hakkında kısaca bir bilgi verip nasıl çalıştığını ve DNS değiştirerek bu yasakalrı nasıl aştığımızı açıklamaya çalışayım (Bu konuda zaten bilgi sahibi olanlar aşağıdaki paragrafı atlayabilirler):

DNS(Domain Name System) Türkçe’ye “alan adı sistemi” olarak çevrilebilir. Tarayıcılarınızda sitelere girmek için kullandığınız (genellikle sonu com,net,org gibi olan) adres çubuğuna yazdığınız metinler aslında internet üzerindeki bir verinin adresini temsil eder. Fakat ulaşmak istediğiniz sunucu bu isimle doğrudan anlamlı değildir. (bilgisayarcı insanlar sayıları metinlerden daha anlamlı bulmuşlardır hep) İnternette bilgisayarları birbirinden ayıran ve bağlantı kurulmasını sağlayan IP sistemidir. İnternete bağlı bilgisayarların bir IP adresi vardır. Sizin ulaşmak istediğiniz siteler de bir IP adresine sahip sunuculardır. Sizin DNS olarak girdiğiniz numara da aslında bir IP adresidir. Yaptığı iş ise sizin verdiğiniz isimdeki siteye hangi ip adresinden erişilebileceğini söylemektir.

Peki DNS kullanarak bir site nasıl yasaklanır? Aslında basit… Siz yasak olan bir siteye erişmeye çalıştığınızda sizi o siteninki yerine başka bir adrese yönlendirir. Standart olarak size sağlanan DNS sunucuyu kullandığınızda genellikle bu yüzden yasakla karşılaşırsınız. DNS sunucusunu değiştirmek yada host dosyasını değiştirmek gibi yöntemler sizi doğru adrese yönlendirerek bunu etkisiz kılar.

22 Ağustosta yürürlüğe sokulması planlanan uygulama internet servis sağlayıcılarına (Telekom, Superonline, vs…) bir merkezi denetim getiriyor. Yasak olan siteler merkezi bir veri tabanında belirli durumda olacak ve insanların kullandığı pakete göre bu sitelere erişilmesi sınırlandırılacak. Fakat DNS yasağından farklı olarak yanlış adrese yönlendirmeye gerek kalmadan o IP adresiyle olan iletişimi tamamen engellediği için DNS değiştirme yöntemi işe yaramayacak. O siteye doğrudan erişmek mümkün olmayacak. Fakat hiçbir şekilde erişilemeyeceği konusu doğru değil. “Avcı nice al (hile) bilirse ayı onca yol bilir.” demişler =) Fakat problemimiz zaten bu değil.

Bu konuda söylenen temel şey standart paketin şu anki durumdan farksız olduğu ve abartıldığı yönünde. Ama bence bu savdaki temel yanlış, şu anki durumda mahkeme kararıyla engellenmiş sitelere erişmediğimiz varsayımı üzerine kurulmuş olması. Yani paketiniz standart paket olsa dahi bir sitenin erişime kapatılmasında bir engel yok. Karardaki orjinal ifade “mevcut mevzuata uygun” şeklinde. Fakat mevcut mevzuat kavramı kararnamedeki bir çok ifade gibi biraz muğlak. Yani herhangi bir sitenin bir sebepten dolayı mevcut mevzuata uygun olmadığı düşünülürse yasaklanmış olacak.

Diğer bir mesele de bu yasakları bir şekilde aşmanın cezalandırılmasına zemin hazırlaması. Aslına bakılırsa doğrudan kararnamede bu konuya değinilmemiş. Fakat internet servis sağlayıcılarla yaptığımız sözleşmelerde bunun sözleşmeye dahil edilmesi ve bu konuda yaptırım uygulanması söz konusu. Fakat mahkeme kararıyla engellenen bir siteye erişildiğinde bunun hukuki anlamda suç kabul edilip edilmeyeceği konusunu bilmiyorum. Hukuk onusunda bilgili bir arkadaş bizi aydınlatırsa da iyi olur. Benim açımdan hala muğlak olan mevzulardan birisi.

Bir de yasak kelimeler listesi mevzusu var. Alan adı isimlerinde belli kelimelerin kullanılmasını yasaklayan bir uygulama var. İlk bakışta çok saçma görünmese de listenin içerisinde “haydar, Yasak, hayvan, baldız, girl, hikaye,sıcak, nefes, şişman, teen, yerli” gibi sözcüklerin olması bu listeyi hazırlayanların nasıl bir ruh hali içinde olduğu konusunda beni düşündürdü. Bu kelimelerin sadece düşündükleri anlamda kullanılabileceğini düşünüyorlarsa en masum ifadeyle “akılları fesat”.

Özetlemek gerekirse kullanıcıların güvenliğini sağlamak için bir hizmet olarak ortaya atılıyor bu filtre uygulaması. Ama asıl mesele böyle bir hizmeti istemeyenlerin de mecburi olarak bazı sitelere erişim derdinden kurtarılarak zorunlu olarak bir hizmet verilmesinde ve erişimlere merkezi bir denetleme getirilmesinde. İnternet erişimlerini çeşitli şekillerde sınırlandırmak için bir çok uygulama mevcut. Bu hizmeti isteyen kişiler zaten kullanıyorlar. Bunu genelleştirmek ve standart pakette bile belirlenen belli sitelere erişmeyi engellemek en genel tabiriyle yanlış bir uygulama.

İnterneti kitap ve dergilerle aynı mantığı kullanarak denetlemek gibi bir durum söz konusu. Daha önce youtube,blogger, wordpress yasaklarında gördüğümüz gibi bir kişinin kendisi zararlı bulmadığı halde belli yerlere erişmekten “korunduğu” bir sistem ve mantık var maalesef. Bir şekilde bir gerekçe bulunarak erişilmesi istenmeyen yerlere erişimi engellemek de kaygı duyulan noktalardan biri. İnsanlar doğal olarak yaptığı yazdığı çizdiği şeylerin yada okumak görmek istediği şeylerin başkalarının görüşüne göre “uygunsuz” olduğu için yasaklanacağı fikrinden rahatsız.

Bu konuda rahatsızlık duyanları bir şekilde kendi sitelerinde, kullandığı sosyal ağlarda tepkisini dile getirmeye ve internet özgürlüğünü savunan uygulamaları desteklemeye davet ediyorum. 15 Mayıs’ta da yurdun bir çok yerinde bir yürüyüş olacak.

En geniş kapsamıyla bu hareketi sadece istediğimiz sitelere girmek için değil aynı zamanda çevrimiçi ortamdaki özgürlüklerimizi korumak ve geliştirmek için desteklemeliyiz.

Yararlı bir kaç bağlantı aşağıda:

Eklemek yada düzeltmek istediğiniz noktaları lütfen iletin.

14 Mayıs 2011

Posted In: 15 Mayıs, 22 Ağustos, bilgisayar, btk, hayat, internet, LinuxGezegen, özgürlük, sansür, teknik, tib, yasak

LinuxTag Berlin – 2’inci gün

Bu sabah GPU ile ilgili bir workshop’a girecektim. Fakat sunacak olan kişi ortada olmadığı için ertelendi. Şöyle bir plana bakarken, LiMuX sunumunu gördüm (bugünkü sunumlar pek güzel değil açıkcası). Neyse buna girdim, LiMuX’un release manager’i Robert Jaehne’den başladım dinlemeye. Aldığım notları sizlerle paylaşayım dedim:

LiMuX, München belediyesi tarafından Windows’tan Linux geçiş için yapılan anlatşmalardan ortaya çıkan bir dağıtım. Genel bilgiler şu şekilde:

  • 2006’da bu işe başlamışlar (geliştirme)

  • Devlet işi olarak görüldüğü için camia unsuru hiç yok

  • Temel olarak Debian ile başlanmış, sonra Ubuntu’ya geçilmiş. Paketlerin %90 doğrudan Ubuntu’dan alınıyormuş

  • Kurum içinde kullanılan özel yazılımın bağımlılıklarını kendileri paketlemişler. Hatta bazı uygulamalar için Firefox 2.0 sürümünü paketlediklerini söylediler. Yani geliştiriciler bir uygulamanın çalışması için gerekli olan ne varsa yapmışlar (bir paketin farklı sürümlerini paketlemek gibi)

  • Belirli güvenlik kıstasları var (her istemciye virus scanneri kurmak, spesifik haklar vermek (flash bellekleri kullanmak gibi), vs..)

  • Kullanıcı senkronizasyon’a önem verdiklerini söylediler (Mail, Browser, fakat nasıl yaptıkları hakkında bir şey söylemediler.

Bundan sonra yıl yıl hangi aşamalardan geçtiklerini, ne sorunlar yaşadıklarını, neler öğrendiklerini anlattılar:

2008: Sürüm takviminden 6 ay sonra yayınlamışlar dağıtımı. Son ürün de bir sürü hata mevcutmuş. Bir çok memnun olmayan kullanıcılarına sahiplermiş. O aralarda Debian kullandıklarından tam Sarge/Etch güncellemesine denk gelmişler. Kullanıcılardan ciddi istekler varmış (hataların çözümleri konusunda). Çıkardıkları sürümler özellik bazında imiş (feature based). Bunların önüne geçebilmek için zaman bazlı sürüm çıkartma planına geçmişler. Gelen istekleri önceliklerine göre ayarlamışlar. Her yeni sürüm geliştirmesi için özellikleri baştan bırakmışlar (yani feature frezze olduktan sonra hiç bir şeye bulaşmamışlar).

2009: Zaman bazlı sürümler çok önemli hale gelmiş, kullanıcı istekleri de mevcut fakat kaliteli değil. İsteklerin çok önemli olduklarını anlamışlar. Geliştiriciler her gelen isteği yapmaya çalışmış (fakat bunun yanlış olduğundan bahsetti, biri X uygulamayı isteyebilir, ona sormak gereken şey ise neden X uygulamayı istiyorsun ?). Bu işin üstesinden gelebilmek için “Anforderungsanalyst” almışlar. Türkçesi tam olarak ne bilmiyorum, ama “İstek analisti” olabilir. Bu kişi de sadece isteklerle ilgilenip, onların yapılabilirliğini gösteren, kullanıcın isteklerini inceleyen, düzenleyen biri. İstekler için de kullandıkları araç da TRAC imiş.

2010: Bir çok güzel işler yapıldığını fakat kimsenin duymadığından bahsettiler. Etrafta hep negatif söylemler kalmış (insanlar hala 2008 yılındaki geç kalmalardan bahsediyorlarmış). Aslında çok bilgi var etrafta, fakat bu herkesin çok bildiği anlamına gelmediğinden bahsetti. İnsanları bilgilendirmek de gerekiyor. Peki hangi bilgileri kimler istiyor ? Bunlar da belirlenmeli. Dökümentasyon çok var ama dağıtık (çoğunlukla SVN depolarında sağda solda duruyormuş). Bunun dışında “son kararı” veren bir mecraları olmadıklarını ve bu yüzden sıkıntı yaşadıklarını belirti ( Yönetim bir şey diyormuş, kullanıcılar başka bir şey diyormuş, geliştiriciler ayrı bir şey diyormuş). Bu da uzun vadede zarar veriyor, “son karar” mecrasının eksikliğini hissetmişler. Kullanıcıları grup grup ayırmışlar(?), ve bunlarla da zamanında iletişime geçilip bilgilendirme yoluna gidilmiş. Son karar verme mecrası(mekanizması) oluşturmuşlar. En son da 500 sayfalık bir PDF hazırlamışlar, admin dökümentasyonu, ama bunu kimin için, ne için yazdıklarından bahsetmedi.

2011: Geliştirici == Testci gibi bir durumları varmış (bunun yanlış olduğundan dem vurdu). Belirli bir test zaman düzelgesi yokmuş, yani testler rastgele yapılıyormuş, geliştiriciler bazen yapıyor bazen yapmıyordu. Bazı testler gerçek dünya koşulları ile hiç uyuşmuyormuş. Bunun dışında kullanıcılar her şey “sürüm notlarından” öğreniyormuş, bir önceki yıldan kalan bir alışkanlık, çoğu zaman sıkıntı oluyormuş. Belli başlı sorunları var, neler ?

  • Kimse test yapmak istemiyor (özellikle de geliştiriciler, kod yazmayı daha çok seviyorlar)

  • Hatanın önemi yanlış kişiler tarafından değerlendiriliyor (duruma göre sıkıntı yaratıyormuş)

  • Müşteri için planlama güvenliği yapılmamış (?)

  • Kurum içinde kullanılan kritik uygulamalarda bir takım hatalar çok geç farkedilmiş (olmaması gerekiyormuş kesinlikle)

Bunu düzeltmek için neler yapmışlar ?

  • Kalite planı oluşturmuşlar (was, wann , wie), yani örneğin Release notlarında olması gerekenler çok daha öncesinden konuşumul ve müşteriye söylenmiş

  • Bağımsız ve tecrübeli bir test takımı kurulmuş (6 kişi, tam zamanlı)

  • Kullandıkları araçlar : testlink / TRAC

  • “Harte definitionen für bug schwerer grade” gibi bir şey yazmışım. biraz karmaşık bir cümle, çevirisinden ziyade ne anlama gelebileceğini tam bilemiyorum, yine de şu şekilde bir şey: “Çok kritik hatalar için sınır belli tanımlar”. Tam olarak ne demek istediğini bilemedim ama :)

2012: Bir sonraki Ubuntu LTS güncellemesini yapacaklar (şimdi kullandıkları 10.04) Yeni bir arayüz olabilirmiş. Tam teşeküllü 8000 istemci kullanılacak Geliştiricilere ihtiyaçları varmış.

Bu kadar, sonra soru sorma safhasına geçildi. Çok az soru soruldu. Bir tanesi şu şekildeydi: “Kurumlardaki yaş ortalaması çok değişken. Windows’tan Linux’a geçişte hangi yaş grubu nasıl tepki verdi ?” Cevap ise şu şekilde: “Kişisel olarak bununla karşılaştım, özellikle yaşlı insanlar (50 yaş üstü) hayatlarında bir çok değişim görmüş insanlar, o yüzden olgunlukla davranıyorlar, ama 5-10 senedir çalışan yeni nesil ile sık sık fikir ayrılığına giriliyor.

Ben de bir soru sordum kendilerine, dedim ki geliştriciye ihtiyacınız varmış, peki şu anki durumunuz nedir ? Ne kadar geliştirici çalışıyor ekibinizde ? diye sorduum. O da bana, 8 geliştirici çalıştığını, bunlardan biri yönetici işleriyle uğraştığını, birinin (kendisinin) sürüm yöneticiliğini yaptığı (ama geliştirme yapamadığını daha çok kağıt işleri ve yardım,fikir danışma işleri yaptığını söyledi), bir de yukarıda bahsettiğim “istek analisti”. Geriye kalan beş geliştirici de çok yoğun çalışıyormuş.

Test ekipleri 6 kişi, geliştirici ekipleri de 8 kişi. Oran baya yüksek :) Evet bu kadar, yeni başka şeyler öğrenirsem yine paylaşırım.

**Kişisel düşüncem: **LiMuX ekibi var olan ve yapılmış işi (Ubuntu 10.04) kendi isteklerine göre konfigure ediyorlar. 8 Kişilik ekip ile pekala bunu yaparlar. Muhtemelen Ubuntu’daki her güncellemeyi doğrudan alıyorlardır. Test ekibi de sadece kurum içinde kullanılan özel yazılımlar için test durumları hazırlıyorlardır. LiMuX ekibi depo’da “temiz” kod gibi bir kavramdan uzak gibiler, bunu sunum’da özellikle Firefox 2.0 paketlediklerini anlattıkları vakit anladım. Mesela uygulamanın Firefox 4.0 ile çalışmasını sağlamak yerine Firefox 2.0 paketleyip o şekilde çalıştırmışlar. Tabiki iç yüzlerini bilmiyoruz, yanılıyor da olabilirim.

LinuxTag diğer sunumlar:

Bundan sonra bir tane Debian sunumuna girdim. Debian Proje Lideri çok güzel bir şekilde Debian’ın genel yapısını ve kültürünü anlattı. Kendisi de Fransa’da doktora bitirmiş 32 yaşında biri. Ama her konuyla Debian ve Linux kültürüne hakkim idi. Fransız olmasına rağmen İngilizceyi çok akıcı bir şekilde konuşuyordu. Kendisinin adı Stefano Zacchiroli idi. Google’de aratıp daha fazla bilgi alabilirsiniz.

Debian sunumunda salon tıklım tıklım idi. Bilindik şeyler anlattı Stefano, ne kadar çok fork edildiklerini, hatta forkların forku olduklarını. Kendilerinin çok kaliteli işler yaptıklarını, tüm paketçilerin kendi alanlarında birer yazılım uzmanı olduklarını vs… Salon’da sanki herkes bir vefa borçu ödüyormuş gibi izliyordu. Debian’ı genel olarak insanların sevdiğini gördüm. Her dağıtımdan insan vardı. Birleştirici bir unsurları var gerçekten

Bunun dışında da “Nasıl hata çözülür” diye bir sunuma katıldım. Biraz ileri seviye bir şey beklerken, aslında benim çokça yaptığım ve sizlerle de paylaştığım yazıların çok daha basit bir şekli idi. Biraz hayal kırıklığına uğradım ama olsun artık bu kadar :)

Bir sonraki yazımda çok da güzel konular yer alacak, özellikle OSB ile ilgili güzel bilgiler edindim. Okumanızı tavsiye ederim :)

14 Mayıs 2011

Twitter Auto Publish Powered By : XYZScripts.com