Google Summer of Code 2015

Bu yıl kabul edilen bizim çocuklar:

Berker Peksağ - ScrapingHub: Improve Scrapy's Python 3 support
Cihad Güzel - Support Sitemap Crawler in Nutch 2.x
Furkan Kamacı - Spark Backend Support for Gora (GORA-386)
Halil İbrahim Şimşek - Giving HTML5 Support For Apache Nutch 2.x
Mesut Özdoğan - Kitchen Activity Games Proposal
Tamer Taş - Lightweight Cloud Instance Contextualization Tool
Yiğit Demirağ - Vectorization of Philox CBRNG and VecGeom via Agner FOG's Vector Class Lib.


Meraklısı için: 2006200720082009201020112012, 2013, 2014

28 Nisan 2015

Posted In: Gezegen, gsoc, haber

Linux Stajı Sonucunda


12 Mart sonunda Outreachy (OPW) kış dönemi stajları sona erdi. Ben bu süreçte bellek yönetiminde, THP (transparent huge page) kodları üzerinde çalıştım. Birlikte çalıştığım danışmanımın istersen bir süre daha birlikte çalışmaya devam edebiliriz demesiyle şimdi hala devam ediyorum :).

Staj sürecinde sadece okunur sayfalar, sıfır içerikli sayfalar (zero page, bellekte henüz eşleme yapılmamış sadece okuma isteği almış ve veri içermeyen sayfa) ve swap cache üzerinde çalıştım. Swapteki veriler için birini stajdayken diğeri stajdan sonra olmak üzere iki yama hazırladım. İkisininde ortak yanı do_swap_page kısmında takılıyor olmaları ^_^. Sistem bazen askıda kalıyor, bazen boot aşamasında bile bir panik oluyor gibi problemleri var hala. Koddaki sayaçların değerini daha iyi görebilmek için tracepoint yazdım. Tracepointi de ayrı bir yama olarak göndereceğiz. Askıda kalma problemleri için en iyi yöntemler ise serial console ya da netconsole kullanmak. Geçen gün Sarah Sharp'ın günlüğüne bakarken burada bir netconsole yazısı gördüm :). Askıda kalma olayı genelde spinlocklarda bir hata yaptıysak oluşuyor.

Outreachy'de, Linux Vakfı kendi stajerlerini 5 dakikalık kısa konuşma yapmak için Linuxcon'a davet ediyor. Ben Dublin'de olana katılacağım, Seattle'da olan biraz fazla uzak. Zaten bu ara hangi etkinliğe gitmek istesem hep Dublin'e denk geliyor, aslında ben mümkün olduğunca başka şehirler seçmeye çalışıyorum :).

Nisan başında lwn.net'te stajımla ilgili bir yazı yayınlayacaktık, yazının taslağı hazır, sanırım swaplerle olan işler bittikten sonra onları da ekleyip yayınlayacağız.

Bu staja alınmam benim için biraz sürpriz gibi oldu. Necdet hocanın hadi Ebru başvursana demesiyle başvurdum ve çok iyi oldu, çok da güzel oldu :).

Mezuniyetimden beri evden çalışıyorum, bu biraz değişik oldu. Muhtemelen bir ay daha evdeyim, sonra bir süre çekirdeğe ara verip başka işlere bakıp, sonrasında tekrar döneceğim :). Çekirdek üzerinde çalışmanın diğer alanlara göre daha fazla dikkat gerektirdiğini düşünüyorum. Çünkü bir yerde hata yaparsam o değişikliği geri almak daha uzun sürüyor, daha fazla şeyi kontrol etmem gerekiyor.

Staj sürecimde işini çok iyi yapan insanlarla birlikte çalıştım. Rik, 12 senedir Linux üzerinde çalışıyor. Bunun ilk duyduğumda bir yutkunma .. :).

Aslında üniversiteye başladığımdan beri hep işini çok iyi yapan, hayran olduğum insanlarla bir aradayım. "Harika insanlarla birlikte çalıştım" diyebilmek, bu hayattaki en güzel şeyler arasında ilk sıralarda yer alır. Çomü'de bilgi işleme gitmeye başladığımdan beri ben de bu sözü söyleyebiliyorum ve iş hayatında da böyle devam eder diye ümit ediyorum :).

26 Nisan 2015

Posted In: bellek yönetimi, çekirdek, comu, Gezegen, Gnome, linux, opw, outreachy, staj

Google ProtoBuf Optimization Trick

Unique Tag numbers 1-15 require one less byte to encode than higher numbers, so as an optimization you can decide to use those tags for the commonly used or repeated elements, leaving tags 16 and higher for less-commonly used optional elements. 

Each element in a repeated field requires re-encoding the tag number, so you use lower number than 16 you do not store unnecessary space for elements of repeated field. Repeated fields are particularly good candidates for this optimization.

23 Nisan 2015

Posted In: google, optimization, protobuf, protocol-buffers

Sistem Yönetiminde Güvenlik Odaklılık

Geçenlerde, Linux Akademi‘nin blogunda sistem yönetimi ve güvenlik odaklılık üzerine şöyle bir yazı paylaşmıştım:

Teknolojik gelişmelerdeki hız ve değişim bu ekosistem içerisinde yer alan herkes için alışkanlıkların değiştirilmesini ve bu yeni gelişmelerin yol açtığı yeni iş yapış şekillerine evrilinmesini şart koşuyor. Bu kaidenin ne oranda hayata geçirildiği ise vizyonun şekillenmesi için bir ölçüt teşkil ediyor. Bu yeni dinamikler neticesinde her geçen gün eskinin klasik sistem yönetim anlayışını bir kenara bırakıp yeni metodolojilere daha çok adapte ediyoruz kendimizi.

Hemen herşeyin “manual” yürüdüğü, kapalı ve rutine bağlanan eski iş yapış şekilleri, yeni disiplinlerin türemesi ile daha çok araç, gerecin kullanıldığı ve herşeyi otomatize etmeye dayalı ve insan faktörünü olabildiğince aza indirgeyerek kendi kendini idame ettirebilen, dirençli ve esnek altyapılar kurgulama ve bunları “yönetme” şekline dönüştü. Durum böyle olunca yani herşey daha basitleşmiş gibi görünürken, bu basitliğin arkasını dolduran dinamiklerin daha komplike hale gelmiş olması, eski sistem yönetimi anlayışını yerle bir ederek, daha çok araştırmaya ve mühendisliğe dayalı başka tür bir sistem yönetimi anlayışına evrildi. -Dünya bu yeni yaklaşıma uzun süre önce geçmiş olmasına rağmen-, bizim ülkemizde de bu yaklaşımın etkileri gün geçtikçe daha fazla gözlemlenebilir bir hal alıyor.


Devamini okuyun: Sistem Yönetiminde Güvenlik Odaklılık


Cagri Ersen tarafından Syslogs adresinde yayınlandı. | Permalink | Etiketler:

21 Nisan 2015

Posted In: Genel, security

Etiketler:

wait.h

Birden fazla process ile çalışan kod yazarken bazen wait() / waitpid() sistem çağrılarını kullanmak gerekebilir, bu sistem çağrıları child process yaratan parent process’lerin child’ların bitmelerini beklemek için kullanılır. Örneğin bir child process bir dosyaya yazma yapıyorsa ve parent process daha sonra bu dosyadan okuma yapacaksa önce child’ın tamamen sonlanmasını beklemesi gerekir çünkü child henüz daha dosyaya yazmayı bitirmemişken parent’ın bu dosyadan okuması hatalı sonuçlara yol açabilir.

wait()’in kullanılabilmesi için yazılan kodun en üstüne “#include <sys/wait.h>” satırının eklenmesi gerekir. Ancak bazı kodlarda bu satırın “#include <wait.h>” şeklinde yazıldığını da gördüm. Peki hangisi doğru? diye /usr/include dizini altına bakınırken aslında iki dosyanın da sistemde varolduğunu öğrendim:

$ find /usr -iname 'wait.h'
/usr/include/wait.h
/usr/include/x86_64-linux-gnu/sys/wait.h

Birbirinin sembolik linki olmayan bu iki farklı dosyanın içeriklerine baktığımda ise sys/wait.h olanı içersinde bir .h dosyasından bekleyebileceğim tanımlarla karşılaşmışken ilk wait.h dosyasının içeriğinin güldürecek kadar basit tutulduğunu gördüm:

$ cat /usr/include/wait.h
#include <sys/wait.h>

Muhtemelen BSD, Solaris, Linux vs gibi farklı platformlar arasındaki kod uyumluluğu artırmak için alınmış bir önlem olsa gerek.

20 Nisan 2015

Posted In: Gezegen Yazıları, linux, process, programlama, wait

Linux Çekirdeğine Tracepoint Eklemek

Linux kaynak kodunda değişiklik yaptıktan sonra, bunları izlemek için farklı yollar var. Ben henüz çok değişik bir şey kullanmadım. Bu zamana kadar hep printk ile kern.log'a aktarıp, sonra grep, wc, tailsplit gibi komutlarla inceleme yapıyordum. Aslında çok farklı şeyler kullanırım sanmıştım :) ama danışmanım ilk olarak bu yöntemi önerdi.

kern.log'u incelemek sandığım kadar rahat olmuyor, her adımda kodun patlamadığından emin olmalıyım. Bu yüzden bir sürü şey yazdırıyorum, gerçi panik olduğunda otomatik olarak loglara düşüyor ama bazı askıda kalma durumlarında düşmeyedebilir. Birde her testten sonra log dosyasını boşaltıyorum sonra içinden bir şeyler parse etmek zorlaşıyor, sadece 1 test için dosya boyutunun 15M olduğunu hatırlıyorum. kern.log'u boşaltmak için bir yöntem olarak "sudo tee /var/log/kern.log < /dev/null", bunu kullanabiliriz. Hiç boşaltmadan test yapmaya devam ettiğimde dosya boyutu .. ^_^. Elbette inceleme yapılamayacak kadar büyük oluyor diye bir düşüncem yok ama zorlaştırmasak iyi olur.

Uzunca bir süredir yaptığım değişikliklerde beklenmedik sonuçlar görüyorum, aslında beklenmedik sonuçlar görmek elbette en beklendik şey :P, ilk zamanlar test yaparken her testte farklı bir sonuç görürdüm. Danışmanımın emin misin bunu gördüğüne, o zaman şunu da ekle demesine neden olmuşumdur, sonra başka bir testte ben yanlış bakmışım problem o değilmiş şeklinde döndüğüm çok olmuştur :). Ancak bu sefer öyle olmadı, ben uzunca bir süre hep aynı beklenmedik sonucu aldım. Bu durumda oluşabilecek ihtimaller, 1- ben yanlış bakıyorum, 2- pteleri swapten çektiğim halde hala bir şeyler onların swapte gibi loglanmasına neden oluyor, bunun nedeni belleği mantıklı kullanmak ya da tekrar swape gitmesi gerekirse daha az işlem yapmak istemeleri olabilir.

Test yaparken 800M'lık verinin üzerindeki değişimlere bakıyorum, büyük sayfalar 2M olarak tutuluyor. Tek bir büyük sayfa için 512 kere (normal sayfalar 4kB) döngü yapılıyor, benim de her döngüde 15 satıra yakın yazdırdığımı düşünürsek, bu durumda loglarda gözümden bir şey kaçmamıştır demek pek mümkün değil :). İşte tam bu gibi problemler için tracepoint'ler var.  Tracepoint eklediğimiz her fonksiyon için bir kez çalışıyor, aslında değişkenlerin son değerini, kodun sonuna printk ekleyerek de yazdırabiliriz. Ancak bu yöntem boş yere kern.log'u dolduruyor ve kendi testlerimiz için eklediğimiz printk'lar ile birlikte upstream'e yama gönderemeyiz zaten, yani göndermesek iyi olur :). Tracepointler; printk ekledim, eklemeyi unuttum (bir daha derle), upstreame göndermeden önce printk'ları kaldır bir daha derle - test et gibi şeyleri önlüyor. Tracepoint kodu yazıyoruz ve bir kere derliyoruz, sonra eğer o değişkenlerin değerine bakmak istersek perf aracı ile testleri çalıştırıyoruz ve değerleri görüyoruz :).

Tracepoint Nasıl Tanımlanır?

Daha önceden tanımlanmış tracepoint kodlarını inceleyebiliriz. Birde lwn.net'te çok açık anlatan yazılar var. Örneğin vmscan.c'deki birkaç fonksiyon için tracepoint ekleyeceğiz. Bunun için  include/trace/events/'de vmscan.h dosyası oluşturmalıyız. Tracepoint yazmak için yapmamız gerekenler: 1) temel tanımlamaları yapmak, 2) TRACE_EVENT() tanımlamak, 3) TRACE_EVENT içerisinde belirttiğimiz fonksiyonu kaynak kodda çağırmak.

#undef TRACE_SYSTEM
#define TRACE_SYSTEM vmscan

#if !defined(_TRACE_VMSCAN_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_VMSCAN_H

TRACE_EVENT(....
                             .....
);

#endif /* _TRACE_VMSCAN_H */
#include <trace/define_trace.h>

Şimdi TRACE_EVENT() içeriğini tanımlayalım:
TRACE_EVENT(name, proto, args, struct, assign, print)
name: Kaynak kod içerisinde çağırılacak fonksiyonun adı.
proto: Fonksiyon için prototip.
arg: Fonksiyonun alacağı değişkenler.
struct: Tracepoint içine geçen verilerin depolanması için yapı.
assign: Değişken ataması yapmak için kullanılıyor.
print: Değişkenleri yazdırmak için kullanılıyor.

Yazdırmak istediğimiz değişkenler sadece struct shrinker *shr ve unsigned long lru_pgs değişkenleri olsun:

TRACE_EVENT(mm_shrink_slab_start,
    /* proto */
    TP_PROTO(struct shrinker *shr, unsigned long lru_pgs),
    
    /* arg */
    TP_ARGS(shr, lru_pgs),

   /* struct */
    TP_STRUCT__entry(
        __field(struct shrinker *, shr)
        __field(unsigned long, lru_pgs)
    ),

    /* assign */
    TP_fast_assign(
        __entry->shr = shr;
        __entry->lru_pgs = lru_pgs;
     ),

     /* print */
     TP_printk("shr = %p,  lru_pgs = %ld",
                       __entry->shrink,
                       __entry->lru_pgs)
);

TRACE_EVENT içerisinde mm_shrink_slab_start şeklinde belirttiğimiz fonksiyonu, vmscan.c dosyasından, önüne trace_ ekleyerek bu şekilde çağırıyoruz: trace_mm_shrink_slab_start(shr, lru_pgs); Bu değişkenler için sırasıyla proto, arg, struct ve assing'ı tanımladık. Daha sonrasında print ile yazdırma kısmını ekledik.

vmscan.h dosyasının tüm içeriğine buradan bakabilirsiniz. Dosya içerisinde event_class, define_event gibi tracepoint'leri gruplayarak tekrara düşmeyi önleyen makrolar kullanılmış. Ben henüz bunlara gerek duymadım. Tracepoint kullanmak için yukarıda belirttiğim 3 temel maddeyi yapmak yeterli.

                   http://lwn.net/Articles/379903/

17 Nisan 2015

Posted In: çekirdek, Gezegen, linux, test etme, tracepoint

Başka Bir Teknoloji Mümkün

2012 yılında Ege Üniversitesi’nde düzenlenen, enerji, bilişim ve tarım alanındaki alternatifler üzerine bir çalıştayda yanıtlamıştık “Başka bir teknoloji mümkün mü?” sorusunu.  O dönemde çalıştay hakkında yazdıklarıma şuradan ulaşılabilir. Tayfun Özkaya hocanın önayak olduğu ve oldukça güzel geçen bu çalıştayın ardından, çalıştayda konuşulup tartışılanları kitap haline getirme fikri doğdu. Uzun çabalardan sonra 2015 yılının Mart ayında nihayet “Başka Bir Teknoloji Mümkün” kitabımız daha da zenginleştirilmiş olarak raflardaki yerini aldı. 

Kitapta çalıştayın takipçisi olarak sürdürülebilir enerji politikaları, yerel tohum ve GDO, özgür bilgisayar yazılımları gibi konular ele alınmakta. Buna ek olarak Adrian Smith, Jean Robert ve Philip J. Vergragt’ın Türkçe’ye çevrilmiş yazıları bulunmakta. Bazen insanların doğayı nasıl tahrip ettiğine, uygulanan yanlış enerji politikalarına, insan sağlığını hiçe sayan tarım ürünlerine, tekelleşmiş yazılım firmalarına bakıp da iç geçirdiğiniz oluyorsa ve kendi kendinize “Bu böyle ne kadar daha gidecek, yok mu bir çözümü?” diye soruyorsanız bu kitabı beğenebilirsiniz. Çünkü yanıtlamaya çalıştığımız “Başka bir teknoloji mümkün mü?” sorusunun yanıtını en baştan veriyoruz: “Evet, başka bir teknoloji mümkün!”

kitap_baskateknolojiKitabın içindeki bölümler ise şöyle:

1- “Başka Bir Teknoloji Mümkün mü?” Sorusu Üzerine Kısa Bir Deneme
Duygu Kaşdoğan

2-Teknoloji Sürdürülebilir Hayata Nasıl Katkıda Bulunabilir?
Philip J.Vergragt

3- Teknoloji ve Mühendislik Bilimlerinin Kavramsal Tarihi Üzerine
Prof. Dr. Beno Kuryel

4- Bilgisayar ve Özgürlük: Özgür Yazılımlar
Özlem Özgöbek

5-Teknolojik Determinizm ve Teknolojinin Toplumsal Denetimi
Dr. Baha Kuban

6- Özgür Tohumlar ve Tarım
Prof. Dr. Tayfun Özkaya

7-Alternatif Teknoloji
Jean Robert

8-Biyolojik Mücadele, Şirketlere mi Topluma ve Doğaya mı Hizmet Edecek?
Prof. Dr. Tayfun Özkaya

9- Alternatif Teknoloji Hareketi: Çerçeve Analizi ve
Teknoloji Geliştirme Üzerine Müzakereler
Adrian Smith

10- İklim Değişikliği ve Karbon Kilitlenmesi
Dr. Baha Kuban

11-Satılık Bilim İnsanları Aranıyor
Prof. Dr. Tayfun Özkaya

12- SORU VE CEVAPLAR

13 Nisan 2015

Posted In: linux, Özgür yazılım

Half-Life 3 Hakkında Bazı Tahminler

Okuduğum bazı haberlerde Valve’in Half-Life 3’ü kendi oyun konsolunun (Steam Machine) tanıtımını yapabilmek için SteamOS ile aynı anda ilk önce SteamOS’a özel olarak çıkartması, daha sonra bunu takip eden birkaç ay sonra ise Mac ve Windows platformlarına getirmesi olasılığına değiniliyor.

Tux_Freeman_by_EnPsyane

Konuyu takip eden herkes SteamOS işletim sisteminin temellerinde GNU/Linux’un yattığını bilir; yani Half-Life 3’ü ilk önce Ubuntu, Mint gibi Linux kullanıcılarının oynayacak olması anlamına geliyor bu. Bundan on sene önce, bilemedin hadi beş sene önce tüm dünya “Linux’ta oyun oynanmaz” diyip geçerken artık günümüzde dünyada oyuncuların neredeyse GTA5 heyecanıyla beklediği Half-Life 3’ün ilk önce Linux’ta oynanabilecek olması olasılığı gayet sevindirici. Tamam Half-Life 3 çok büyük olasılıkla bir özgür yazılım olmayacaktır ama yine de Linux’un tanınırlığını artırmak için gayet mantıklı bir hamle olacaktır.

“Half-Life 3 mü geliyormuş?” demeyin bu arada; Rockstar’ın GTA5’i duyurduğu ilk günden bu yana PC’ye de getireceği ne kadar belliydiyse HL3’ün şu an geliştirilmekte olduğu ve gelecek bir tarihte oyuncularla buluşacağı da o kadar net, sadece henüz anons etmiyorlar tarihini.

Resim kaynağı: http://enpsyane.deviantart.com/art/Tux-Freeman-14014474

13 Nisan 2015

Posted In: Gezegen Yazıları, half-life 3, linux, linux oyunları, steam, steam machine, valve

Gradle ile Proje İnşası Semineri

Özgür Yazılım ve Linux Günleri 2015, İstanbul Bilgi Üniversite’sinde gerçekleşti.

Bu etkinliğe ben de “Gradle ile Proje İnşası” başlıklı sunumum ile katıldım.

Konu Özeti

Gradle, Java dünyasının popüler inşa sistemlerinden biridir. Popüler inşa sistemleri Ant ve Maven ile uyumlu olmakla beraber, bir programlama dili Groovy ile yapılandırılması sağlanarak esnek bir sistem sunar. Gradle’ın getirdiği yenilikler, bağımlılık yönetimi, derleme ve paketlemenin nasıl yapıldığı, esnek yapısı, maven ve ant ile kıyaslanması, task’ların nasıl yazıldığı, avantajları ve dezavantajları konular örneklerle anlatılmıştır.

Sunum dosyasına aşağıdaki bağlantılardan ulaşabilirsiniz:

Slideshare

9 Nisan 2015

Sparse Nasıl Kullanılır?

Sparse, Linux çekirdeğine katkı verirken kullanılabilen araçlardan biri. Linus Torvalds tarafından yazılmış statik kod denetleyicisi ve bir süredir de bakımını Josh Tripplett yapıyordu.

Normalde çekirdek derlemesi yaparken almadığımız hataları/uyarıları Sparse'ı etkinleştirerek alabiliriz. Peki Sparse bize ne tür hatalar döndürüyor? Makro kullanımlarındaki yanlışlıklar, tip dönüşüm hataları, static & extern gibi anahtar kelimelerin kullanımlarında yanlışlık varsa ya da bir fonksiyon üretildiği ve hiç kullanılmadığı durumlarda uyarı veriyor.

Kurulum için sparse paketini kurmak yeterli ya da depodan çekerek de kurabiliriz. Temel kullanımı ise şu şekilde: make C=2 drivers/staging/wlan-ng/ 

Sparse'ı kullanabilmek için çekirdek hakkındaki en temel veri tiplerini, makrolarını bilmek gerekiyor. Eğer static, extern ifadelerindeki kullanımları düzeltmek gerekiyorsa o fonksiyonların nerelerde çağrıldığına, hangi başlık dosyasında tanımlandığına bakıp düzeltme yapmak gerekiyor. Ben sparse'ı ilk kullanmaya başladığımda bu yazıyı okumuştum, zaten okumamla birlikte oldu o zaman, beni evden beklerler demem bir olmuştu :). Sparse ile katkı vermeye başladığımda da artık beni evden beklemiyorlar demeyi unutmadım tabi ^_^.

Sparse kullanırken veri gösterimlerindeki hataları da alabiliriz. Eğer driver Makefile dosyasında endian kontrolleri etkinleştirilmediyse, sparse kullanırken  make C=2 CF="-D__CHECK_ENDIAN__"  drivers/staging/wlan-ng/  şeklinde bayrağı aktif etmeliyiz.

Verileri big endian ya da little endian şeklinde göstermek tasarımcıya göre değişen bir şey. Veri biçminde anlaşabilmek için işlemcinin kullandığı yerel biçimden driverın kullandığı biçime dönüş yapmak gerekebiliyor. Bunun için cpu_to_le16(), ya da le16_to_cpu() fonksiyonları var. Bu fonksiyonlar little endian 16 bit olan veriler için. Veri gösterimiyle ilgili fonksiyonlara buradan ulaşabilirsiniz. Birde burada örnek var, gayet yararlı olduğunu düşünüyorum :). Burada temel problem fonksiyonların aldığı değişkenler ya da atama işlemlerinde meydana gelen tip uyumsuzlukları. Bu gibi durumlarda değişkenin tipini değiştirmek ya da dönüştürme işlemini kaldırmak gerekiyor. Ya da driverın özelliklerinden ve kodu inceleyerek, veri aktarımı olurken hangi biçime dönüştürülmesi gerektiğini anlayabiliriz. Ağlarla ilgili olan driverlarda big endian gösteriminin kullanılması gibi.

6 Nisan 2015

Posted In: endian, Gezegen, kernel, linux, make, sparse

Twitter Auto Publish Powered By : XYZScripts.com