NOT: Bu güvenlik açığını başka şekilde hallettiğim için buradaki control kısmına sadece sufficient yazmam yeterli oldu. Ama yine de aşağıdaki yazıyı bırakıyorum.


Biraz önce yazdığım yazıdaki kodu kontrol ederken akıl almaz bir güvenlik açığı ile karşı karşıya geldiğimi öğrendim. Açık şu: Sistemdeki herhangi bir kullanıcı parola yazmadan giriş yapabiliyor. Bunun sebebi yazdığım metot her türlü SUCCESS döndürmesi. Bunun yerine hata döndürse bu sefer başka sorunlar ortaya çıkacak.

Bu şekilde aklıma /etc/pam.d/ nin içerisinde bir şeyleri değiştirmek geldi. man pam.d yaparak kolları sıvadım. Ve çözüm:

auth [user_unknown=ok success=done new_authtok_reqd=done default=ignore] pam_python.so guestlogin.py

İkinci yazdığımız sufficient yerine bunları yazıyorum. Şu an daha iyi durumda.

Şimdilik aklıma gelen düzeltme yapılması gereken yerlerden birisi de bu durumda her bilinmeyen/kayıtlı olmayan kullanıcı için SUCCESS döndürmesi. Bunun kontrolünü python betiğinin içerisinde uygulamam gerekiyor.

Hazırlamakta olduğum guestlogin projesinde şimdilik giriş yapılabiliyor ve /home/ dizininin altında guestX şeklinde bir dizini ev dizini olarak gösteriyordu.

Geçici ve parolasız girilen bir hesap için fazlasıyla tehlikeliydi. Bunun için tmpfs ve mktemp komutlarını araştırdım. Tabi bir de kullanıcıyı ev dizini olmadan oluşturmaya baktım.

Öncelikle ev dizini olmadan kullanıcı oluşturmak gayet kolay. Komutumuz:

adduser -M kullanici_adi

şeklinde. -M ev dizini olmadan yarat anlamına geliyor.

mktemp komutu ile /tmp/ dizini içerisinde rasgele bir klasör oluşturuyoruz. Bunu da

mktemp -td guestX.XXXXXX ile yapıyoruz. Buradaki guestX bildiğimiz gibi misafir kullanıcıya vermiş olduğum geçici kullanıcı adı. Noktadan sonraki 6 tane X ise rasgele oluşturacak 6 rakam-harf karışımına denk geliyor. Yani oluşturulan dizin /tmp/guest6.6jHx4f gibi bir şey oluyor.

Buraya kolay bir şekilde gelmiştim fakat önümde biraz araştırmam gereken bir konu vardı. mktemp komutu o XXXXXX leri doldurup stdout a gönderiyordu bunu. Bunu da benim bir şekilde bir değişkene atayıp o dizini tmpfs ile bağlayıp bir de o kullanıcıya atayıp ev dizini yapmam gerekiyordu. Geliştiricilerden Serdar'ın yardımıyla birlikte python ile bunu yapmak için subprocess'leri araştırdım.

Dosyanın başına import subprocess yaptıktan sonra :

procOutput = subprocess.Popen(["mktemp -td %s.XXXXXX" % username], shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
homeDir = procOutput.communicate()[0][:-1]

satırları ile çözüme ulaştım. Burda yaptığım iş tam olarak alt bir süreç başlatmak. yanına yazdığım diğer argümanlar sayesinde stdout ve stderr'i okuyabilecektim.

bu Popen fonksiyonunun geri dönüş değerini bir değişkene atadıktan sonra communicate() fonksiyonu ile bakabiliyordum. Aslında bu bile sonucu bir değişkene atamak için yeterliydi fakat sonuç şu şekildeydi:

('/tmp/guest5.d6E3gh\n', None)

bu haliyle benim işimi görmüyordu. Bunun de küçük bir düzenleme yaptım. İlk baştaki lazım olduğu için communicate() den sonra [0] ı kullandım. O değişkenin içinde de en son karakter \n olduğu için [:-1] ile en son karakteri attım. Sonuç olarak elimde sadece

/tmp/guest5.d6E3gh

kaldı ve bu benim için yeterli bir bilgiydi. Bunu homeDir değişkenine atadıktan sonra bunu tmpfs ile bağladım. Bunu da:

os.system("mount -t tmpfs -o mode=700 none %s" % homeDir)

ile sağladım. Sırada ise kullanıcıyı oluşturma, bu dizini kullanıcıya verme ve onun ev dizini haline getirmek vardı. Kullanıcının sistem tarafından verilmiş adını (guestX olan) username değişkenine daha önceden attığım için aşağıdaki komutlar bunlar için yeterli oldu.

os.system("useradd -M %s 2>> /var/log/guestacc.log" % username)
os.system("chown %s:%s %s" % (username, username, homeDir))
os.system("usermod -d %s %s" % (homeDir, username))

Burda dikkatinizi çeken bir şey de 2>> olmalı. Normalde >> komutu ile stdout'u başka bir dosyaya yönlendirebiliyoruz ama stderr yine ekrana düşüyor. stderr'in dosyaya yazılması için 2>> ekliyoruz.

Başlangıç ayarlarını bu şekilde halletmiştim bir de çıkışta da bu dizini umount edip, kullanıcıyı ve ev dizinini sistemden silmem gerekiyordu. İlk olarak /etc/pam.d/system-auth dosyası üzerinde kullanıcı çıkış yaparkan bir metotun çalışması için bir ekleme yapmam gerekiyordu. Bu da:

session sufficient pam_python.so guestlogin.py

satırı idi. Bu satırı:

session required pam_unix.so

satırının hemen üstüne ekledim. Bu satırı eklediğimde ek olarak:

pam_sm_open_session

ve

pam_sm_close_session

metotları çalışıyordu. Benim işime yarayan ise close_session metotuydu.

Bu metot içinden kullanıcı adını pamh.get_user(None) ile aldım fakat burada os.environ['HOME'] komutu işe yaramıyordu. Bunun için de :

homeDir = os.path.expanduser("~%s" % username)

komutunu çözüm olarak buldum.

Diğer umount işlemlerini de normal bir şekilde devam ettirdim. Ve kod daha iyi bir durumdaydı.

Şimdilik yapmam gerekenlerden biri /tmp/ nin içersinde öyle bir dizin olsa bile mktemp komutu guestX.XXXXXX dizinini oluşturmayıp ona bağlamamı sağlıyorsa bu bir güvenlik açığı olur. Bunun bir araştırmasını yapıp, gerekirse oraya bir kontrol koymak olacak.

Bugün halihazırda tamamlamış olduğum kod üzerinde bir kaç iyileştirme yaptım. README, AUTHORS ve COPYING dosyalarını düzenledim.

Yaptığım iyileştirmeler, eğer yapılandırma dosyasında değer atanmamış ise varsayılan değerleri kullanacak. Başlangıçta eğer sistemde guest_name isminde bir kullanıcı var ise modülü çalıştırmayacak, guest_group isminde bir grup yok ise bunu oluşturacak ve en önemlilerinden birisi ise ev dizinini bağlarken noexec özelliği ile bağlamak.

noexec bize önemli derecede güvenlik sağlıyor. Bu özellik sayesinde kullanıcı bağlandığı ev dizini içerisinde ikilik dosya çalıştıramayacak. Aynı zamanda da kendisi de ikilik dosya yazıp bunu çalıştıramayacak.

Varsayılan değerleri kullanma kısmını da, yapılandırma dosyasını okurken bir hata oluşursa except bloğuna geçip aktarıyor ve hata ayıklama (debug) modunda ekrana dosya okunamadı diye hata veriyor ya da değerleri okurken boş çıkar ise onun varsayılan değerlerini aktarıyorum.

Kullanıcının varlığını ise pwd.getpwnam() ile sorguluyorum. Bunu try-except bloğu içerisinde yapıyorum. try içerisinde bu başarılı olur ise geriye başarısız diye değer döndürüyor, eğer başarısız olur ise except bloğuna geçiyor ve burada da hiç bir şey yapmadan normal koda devam ediyor.

Grubun varlığını da grp.getgrnam() ile sorguluyorum. Yok ise yine hata ayıklama modunda ekrana grup bulunamadı, grup oluşturulacak yazıyor ve grubu "groupadd %s" % guest_group ile oluşturuyorum.

Ayrıca daha önceden /etc/pam.d/ içerisindeki dosyalardaki control yerine uzun uzun yazılar yazıyorduk. Sadece sufficient yazmak yeterli şu an. Daha önceden de yazdığım yazıda bunu düzelteceğim.

Bahadır'ın aklındaki bir proje olan /etc/pam.d/ içerisindeki yapılandırma dosyalarını düzenleme projesini biraz araştırdım ve bunu Ubuntu'da yapmakta olan birileri olduğunu öğrendim.

İstek ise şu adreste: https://blueprints.launchpad.net/ubuntu/+spec/pam-config-framework

Ayrıca 2003 yılında da http://www.mail-archive.com/debian-wnpp@lists.debian.org/msg18384.html adresinde belirtildiği gibi istenmiş fakat zaman aşımından kapanmış.

Ubuntu'daki bu projeyi hazırlayan arkadaşa eposta yolladım. Bana bu paketin Ubuntu ve Debian için pam içerisine koyduklarını söyledi. Bunu biraz daha araştırıp Pardus'a uygulanabilirliğini araştırmayı düşünüyorum.

Sırada bir de PiSi paketi yapmak var. Daha önceden almaya karar verip paketini yaptığım paketleri düzenleyip ve yeni alacağım paketleri belirleyip bunlar üzerine çalışmalar yapacağım.

Yani Pardus 2010 Yaz Stajı, benim için tam hızıyla, zevkli, heyecanlı, öğretici yani her şeyiyle çok güzel devam ediyor.

Pardus’un 2010 yılı staj programının 2. dönemi 2 Ağustos’ta başladı. Pardus Gezegeni staj dönemlerinde pek bir sessiz oluyor ama svn deposundaki hareketlerden UEKAE’deki ofiste stajını sürdüren arkadaşların çalıştığını görebiliyoruz. 2. dönem stajını ArtistanbulPR’da yapacak talihliler de Orçun ve benim.

Görevimiz Özgürlükİçin’in Tema bölümünü yenilemek ve büyük pay da Orçun’a ait. Kendisi 2 haftadır üzerinde çalışıyor ve oldukça güzel bir iş çıkarıyor. Onun işi tamamlamasıyla beraber Tema bölümüne RESTful bir API ekleyeceğiz. Aslında bu API’i Özgürlükİçin 3.0′ın yapılacak listesine eklemiştim fakat yeni Tema uygulamamızın Pardus’un masaüstü hizmetleri ile iletişimini sağlayan KNewStuff (eski adıyla GHNS) özelliği için yazmamız gerekiyor.

Orçun benden daha sık blog yazdığı için kendisini şuradan takip edebilirsiniz. Blog yazma konusunda darısı stajını UEKAE’deki ofiste yapan arkadaşların başına diyerek danışmanlarına ve kendilerine taş atarak bitireyim..

Pardus’un 2010 yılı ilk dönem stajyerlerinden stajını ofisimizde yapan arkadaşlarımız Engin Manap ve Ufuk Uzun stajlarını başarı ile tamamladılar. Başarı ile tamamlamak ne demek bilmiyorum ama klasik bir giriş yapmak adetini bozmak istemedim.

4 hafta boyunca ofisimizde bizlerle birlikte çalıştılar, yeni bir programlama dili öğrendiler ve o dil ile yazılmış bir framework kullanarak Özgürlükİçin kullanıcılarının fikirlerini Pardus projesine ulaştırmakla yükümlü Beyin uygulamasını yenilediler.

Aslında sadece yenilemediler, bir çok eksiğini düzeltip yeni özellikler eklediler. Bu esnada bol bol eğlenip Pardus ve özgür yazılım üzerine sohbetler ettik. Ne yalan söyleyeyim benim bir stajyerden beklentilerimi karşılamakla kalmayıp fazlasını yaparak staj ve stajyerler hakkındaki önyargılarımı fazlasıyla kırdılar.

Geçtiğimiz günlerde beyin2 adını verdikleri django uygulaması Özgürlükİçin’deki selefi ile değiştirildi ve kullanıcılara sunuldu. Kullanıcılardan gelen tepkilere bakılırsa ortaya çıkan uygulamayı tek beğenen bizler değiliz

Kendi ağızlarından stajlarını UEKAE yerine Artistanbul ofisinde yaptıkları için kendilerini şanslı hissettiklerini de duyduğumuza göre yazımızın dilekler kısmına geçebiliriz

UEKAE’deki Pardus ofisinde ve Artistanbul ofisinde stajını tamamlayan arkadaşlarımıza kariyerlerinde başarılar diliyor, Pardus ve özgür yazılım dolu geçirdikleri bu kısa süreli yakınlaşmanın uzun sürmesini istiyoruz.

Önümüzdeki haftalarda Artistanbul ofisinde çalışacak ikinci dönem stajyerlerinin hangi konu üzerinde çalışacaklarını ve neler yapacaklarını da yazarım

Adım adım neler yaptık anlatacağım demiştim, blog yazma konusunda istikrarsız olduğumu bildiğinizden inanmamışsınızdır tahminen. Yarı dönem değerlendirme formuna birkaç paragraf yazarken bile araya türlü türlü aktiviteler sokarak “yazma” işinden kaytaran ben, artık “macroblogger” olduğuma göre oturum adam gibi bir değerlendirme yazısı yazmak zorunda oluyorum değil mi? Evet, buyrun:

GSoC koordinatörü (yine) Renan hızlı, temiz ve sessiz bir iş çıkararak 3. kez yaz stajına kabul edilmemizi sağladı. Biz onu kod yazıyor ya da birileriyle yazışıyor sanıyorduk, meğer teklif metni yazıyormuş gizli gizli. Yaz döneminin büyük bir kısmında ofis dışında olmayı planlayan (ilk aylarda iş, sonraki aylarda tatil için) bir geliştirici olarak bu sene de GSoC danışmanlığı yapmayacağını düşünen ve yanılan bendeniz, 2. kez danışman olarak buldum kendimi. Danışman olduğum Jain Basil‘in ilgisi ve proje gözden geçirmenin en az kod yazmak kadar eğlenceli gelmeye başlaması, 2 aya yakın zamanı keyifli geçirmemi sağladı.

Proje, ev dizinindeki (şimdilik sadece KDE) ayar dosyalarındaki değişiklikleri takip etme, değişiklikleri yedekleyebilme, paylaşabilme ve geri alabilme için gerekli altyapının hazırlanmasını ve arayüzlerin yazılmasını kapsıyor. Detaylar için Jain Basil’in günlüğüne göz atabilirsiniz. “Bir ayar değiştirdim ama neredeydi unuttum, nereden geri alıyorduk bunu?” diyenler için kurtarıcı olacağından eminim.

Jain başvuruda bulunmadan, kodlamaya başlamadan önce yapılması gereken herşeyi yapmış, bunu başvuru mektubunda göstermiş ve başvuruları değerlendiren geliştiricilerin “E sadece kod yazmak kalmış, seçelim bu arkadaşı” demesini sağlamıştı. Aktif geliştirme süreci boyunca Jain iyi bir geliştirici olduğunu gösterdi, takvime uydu ve ilk dönemde geçer notu aldı.

SVN kayıtlarını ve Jain’in İngilizce günlüğünü takip etmeyenler için yaptıkları hakkında bir özet şöyle:

• ~/.kde dizinini kullarak bir yerel GIT deposu oluşturan bir servis yazdı.
• Dizindeki her değişikliği KDirWatch ile takip etme ve değişiklikleri GIT deposuna gönderme desteği ekledi.
• Değişiklikleri görme ve geri almak için gerekli kitaplık metodlarını yazdı.
• 2. dönem geliştireceği arayüz için örnek bir tasarımı depoya gönderdi.

SVN kayıtlarına, kodlara, geliştirici günlüğüne ya da yukarıdaki özete bakarak “ne var bunda, ben de yaparım bunu” diyenlerdenseniz, sizi bir sonraki sene yapılacak olan yaz stajına bekleriz. Proje geliştirmek zor değil. Enerjiniz, hevesiniz, zamanınız ve bu işi yapmak için tutkunuz varsa bu ekipte size de yer var. Selamlar.

UEKAE’deki 2010 stajının ilk dönemi bugün sona erdi. Barış Akkurt, Mehmet Burak Aktürk, Doruk Altan, Caner Başaran, Deniz Gürsel, Eda Okur, Neslihan Şirin Saygılı ve Gökhan Göktürk stajlarını yıldızlı pekiyi ile tamamladı. Özgürlükİçin’in yeni fikir arayüzünü -UEKAE’den çok uzaklarda- Cihangir’deki Artİstanbul ofisinde geliştiren Ufuk Uzun ve Engin Manap bizimle fazla vakit geçiremeseler ve fotoğrafta yer alamasalar da, UEKAE’yi ziyarete geldikleri 2 gün boyunca yaptığımız Django sohbetlerinde “yıldızlı pekiyi”yi hakettiklerini gösterdiler.

Ayrıntıları yazmak, staj koordinatörü Renan‘ın hakkı. Geçen sene stajyerdi, bu sene staj koordinatörü oldu; hallerinden en iyi anlayan geliştirici olduğundan belki, bu görevi en iyi şekilde yerine getirdi. Üşenmeden hazırladığı “Pardus Yaz Stajı” kitapçığı ve tanıtım sunumu bazı geliştiricileri “bizim zamanımızda neredeydin Renan” diye sitem ettirdi, o kadar iyi oldu.

Başlıktaki cümle bugün ofisten ayrılmadan evvel, tatile çıkanlara ve geliştirici adaylarımıza güle güle derken çıkıverdi ağzımdan. Pek sevdim, her staj dönemi (ve belki Pardus eğitimi) sonrası bol bol kullacağım bir laf olacak sanırım.

Görüşmek üzere.

Artık ofisimizde 2 yeni arkadaşımız var, Engin Manap ve Ufuk Uzun. Kendileri 2010 yılının ilk dönem Pardus Stajerleri.

Benim danışmanlığımda Özgürlükİçin’e kağıt kesikleri arabirimi yazacaklar. Kağıt kesikleri en basit manasıyla dağıtımda bulunan fakat engelleyici özellikte olmayan küçük ve genellikle kozmetik hatalara deniyor. Kullanıcılarda kafa karışıklığı yaratan yazım hataları ya da hatalı, anlaşılabilir olmayan çevirilerden tutun da varlığıyla küçük işlemleri kolayca halletmeye yarayacak ve kolayca entegre edilebilecek özelliklere kadar her türlü hata bu sınıfa dahil.

İlk günümüzü Ubuntu’nun bu işi nasıl yaptığı ve Özgürlükİçin altyapısında kullandığımız Django çatısı üzerine sohbet ederek geçirdik. Planımızı ilk haftanın sonunda ellerimizi kirletip kod yazacak şekilde yaptık. Tahminlerimize göre 2. haftanın başında deneme yayını ve sonunda da nihai yayına geçebileceğiz.

Gözünüzü Özgürlükİçin’den ayırmayın

Şimdi kemerlerinizi bağlayın ve masalarınızı kapatın, kısa ve hızlı bir yolculuğa çıkıyoruz.

Beklenen an geldi. 255 stajyer adayı arasından 20 stajyerimizi günler ve saatler süren oylama sürecinden sonra nihayet seçtik.

Kimler seçildi?

Ad Soyad	Okul
Adil Güneş AKBAŞ	Yeditepe Üniversitesi
Ahmet AYGÜN	İstanbul Kültür Üniversitesi
Alper TOKGÖZ	İzmir Ekonomi Üniversitesi
Barış AKKURT	İstanbul Teknik Üniversitesi
Caner BAŞARAN	Mersin Üniversitesi
Deniz GÜRSEL	İstanbul Bilgi Üniversitesi
Doruk ALTAN	İstanbul Ticaret Üniversitesi
Doruk Destan SARPKAYA	Yeditepe Üniversitesi
Eda OKUR	Boğaziçi Üniversitesi
Engin MANAP	Çanakkale 18 Mart Üniversitesi
Gökhan GÖKTÜRK	Sabancı Üniversitesi
Gökhan YILMAZ	İzmir Ekonomi Üniversitesi
Halid ALTUNER	Fatih Üniversitesi
Hakan UYSAL	Hacettepe Üniversitesi
Mehmet Burak AKTÜRK	İstanbul Ticaret Üniversitesi
Mesutcan KURT	Çanakkale 18 Mart Üniversitesi
Neslihan Şirin SAYGILI	İstanbul Teknik Üniversitesi
Orçun AVŞAR	Çanakkale 18 Mart Üniversitesi
Ufuk UZUN	Sakarya Üniversitesi
Utku ULUŞAHİN	Başkent Üniversitesi

Stajyerleri nasıl seçtik?

Oylamalar, stajyer alım sürecini hızlandırmak için yazdığım bir stajyer oylama arayüzünde gerçekleşti. Arayüzde bilgileriniz, cv’niz ve kodlarınız incelendi ve altlarındaki forum tadında ortama yorumlar yapıldı ve puanlarınız verildi. En yüksek puanı alan ilk 20 aday staja katılmaya hak kazanmış oldu. İkinci 20 aday ise gelememe ihtimali olanların yedekleri olarak kaydedildi.

Hangi kriterlere göre stajyer seçtik?

Oylama sürecinde en çok dikkat ettiğimiz kriterler şunlardı:

• Bildiğiniz programlama dilleri
• Yaptığınız okul ve okul dışı projeler
• Bildiğiniz programlama dillerinin seviyesini gösteren ve projelerinizin ispatı olan kod örnekleri
• İş/Staj tecrübeleriniz
• Başarılarınız

Oylama sürecinde dikkat ettiğimiz diğer özellikler:

• Pardus’la veya genel olarak Linux ile daha önceden ilgilendiğinizi gösteren kanıtlar: Blog, makale, çeviri, kod.. vb.
• Pardus’a olan katkılarınız: Yama, çeviri, hata girdisi, seminer.. vb.
• Özellikle Python bilgisi. Ayrıca Qt, C, C++ bilgisi
• Genel olarak Pardus teknolojilerinden ne kadar haberdar olduğunuzu gösteren ipuçları: Çomar, Müdür, Pisi.. vb.

İstatistik mi dediniz?

Tek bir adayın doldurduğu formu gözden geçirmek, cv’sini derinlemesine incelemek ve kod gönderenlerin kodlarını tek tek açıp inceleyip anlamaya çalışmak her geliştirici için ortalama 15 dakika sürdü.

Yani bütün öğrencileri oylamak, her geliştirici için yaklaşık:

255 * 15 = 3825 dakika

3825 / 60 = 63.75 saat

sürdü.

63.75 saati de geliştirici sayımızla çarparsanız sanırım toplamda ne kadar emek verdiğimizi kestirebilirsiniz.

Hangi üniversiteden kaç kişi başvurdu?

Bu sene en çok İstanbul Teknik Üniversitesi’nden başvuru aldık. Geçen senelerin başvuru şampiyonu Kocaeli Üniversitesi bu sene ikinci sıraya düştü. Aşağıda üniversitelerin istatistiğini görebilirsiniz. Açılan pencerede sağ tıklayıp resmi görüntüle derseniz daha rahat okunan bir boyutu açılacaktır. Diğer üniversitelerden de önümüzdeki senelerde katılım bekliyoruz. Tanıtım, gezi ve şenliklerimizin bunda etkili olacağını düşünüyorum.

Kadın – Erkek Oranı

Geçen yıllarda başvuran kadın sayısı %10 iken bu sene %20′lere çıkmış durumdayız. Gurur verici bir gelişme. Computing Research Association‘ın yaptığı bir araştırmada, dünyada bilgisayar bilimleriyle uğraşan kadınların sayısının 1980′lerde %40 iken günümüzde %20 lere düştüğü tespit edilmiş (Ben buna Britney Spears Effect diyorum). Dünya’da %20 lerdeyken stajyerlerimiz arasında %10 idi ve şu anda  %20, yani Dünya normlarına yetiştik. Umarım daha iyi bir tablo da görürüz ileriki senelerde. Belirtmekte fayda var: kabul edilen öğrenciler arasında bu oran ne yazık ki %15 e düşüyor.

Kaç kişi kod gönderdi?

Yaptıkları projeleri ispatlayabilen adaylar oyalamada nispeten daha başarılı oldular. Kod göndermeyenlerin bir kısmının okul ödevlerini göndermekten çekindiklerini düşünüyorum. Aslında biz kod gönderin derken yazdığınız herhangi bir kodu kastediyoruz. Yani okul ödevleriniz de buna dahil. Kod görmek istememizin amacı hem yaptığınız projeleri incelemek (hem de gerçekten yazıp yazmadığınızı anlamak) ve kod yazım tekniğinizin ne aşamada olduğunu görmek. Örneğin kullandığınız kitaplıkları, algoritmaları, sınıfları, metotları ve yazım stilinizi incelemek ne kadar çabuk adapte olabileceğinizi ve hangi aşamada olduğunuzu az çok ortaya çıkarıyor. Bu noktada önemli bir uyarı yapmak istiyorum; staj yaptığınız diğer şirketlere ait kodu gönderirken lütfen dikkatli olun, kodu olabildiğince kırpmaya çalışın. Şirkete özel bilgileri ve gizlilik anlaşması yaptığınız kodları göndermeyin.

Adaylar için Python ve Qt bilmek çok büyük bir artı oldu. Pardus’ta geliştirilen projelerin çok büyük bir kısmının Python ile yazıldığını hatırlatayım (Kaptan, YALI, Network Manager, Display Settings, Packet Manager, PiSi, Müdür, Servis Plasmoid’i…). Python’a başlamak için hep bu kaynağı öneriyoruz.

Söylemekte fayda var; seneye bütün adaylara kod gönderme zorunluluğu getirmeyi planlıyoruz. Başvurmayı planlayanlar şimdiden ufak tefek çalışmalarını bir kenarda biriktirebilir.

Kaç kişi blog yazıyor?

Öğrendiklerini zaman buldukça başkalarıyla paylaşan öğrencilerin bizi daha çok etkilediğini söyleyebilirim. Blog yazmaya çalışın ve bilgilerinizi başkalarıyla paylaşın. Blog istatistiğimiz de şöyle:

Sorunlar?

Her işte olduğu gibi bu işte de bizi yavaşlatan en önemli şeyler özensiz doldurulmuş formlar, belirli bir formata uyulmadan hazırlanmış cv’ler ve bir sürü proje yazdığını iddia edip bunları ispatlayabilecek bir kod örneği göndermeyenler idi.

Böyle adayların hemen hemen hepsini Google’da arayarak çok fazla zaman kaybettiğimizi düşünüyorum. Arama sebebimiz ise; kendini yeterince iyi ifade edememiş öğrenciler olabileceğini düşündüğümüzdendi. Bir el de biz atalım dedik, yaptıkları işleri ve kim olduklarını küçük çapta araştırdık. Ama bu yalnızca bu sene için geçerli hatırlatayım.

Seneye çok daha geniş bir form ve zorlu sorular sizleri bekliyor olacak.

Seçilemedim şimdi ne yapmalıyım?

Stajyer olarak seçilemeyenlerin üzüleceği hiçbir şey yok. Hala Pardus’a katkı verebilirsiniz.

• Pardus ekibi ile iletişime geçin. Neler yapabileceğinizi sorun ama önce şunları yaptığınıza emin olun:
• İlgilendiğiniz Pardus e-posta listelerine üye olun (yakında e-posta listelerinin ne işe yaradığını anlatan bir yazı yayımlayacağım)
• Pardus’ta karşılaştığınız her hata için hata girdisi ekleyin.
• Çözebileceğinizi düşündüğünüz hatalar için yama hazırlayın ve yamayı bize gönderin. (Bu süreci anlatacağım bir yazı da yazacağım)
• Bol bol döküman okuyun (Linux, Operating Systems, Python, Qt ve bulabildiğiniz Pardus dökümanları)
• Pardus üzerinde program yazmaya çalışın. (Pardus üzerinde Python ve Qt kullanarak nasıl yazılım geliştireceğinizi anlatan bir yazı dizisi hazırlayacağım)
• Pardus geliştiricilerinin blog’larını takip edin
• Özgürlükİçin sitesini takip edin
• irc.freenode.net üzerinden #pardus kanalına girerek diğer kullanıcılarla etkileşime geçin. (Freenode bütün dünyada açık kaynaklı uygulamalar geliştiren organizasyonların iletişim için kullandığı bir IRC sunucusudur. bkz. http://freenode.net)
• Pardus’u diğer kullanıcılara tanıtın

Ayrıca:

Kendinize mutlaka bir CV hazırlayın. (Mümkünse nasıl CV hazırlanır üzerine biraz araştırma yaparak)

Unutmayın Pardus’a katkı vermek kendinize de katkı vermektir. Bu yolda öğreneceğiniz bilgiler kariyeriniz için paha biçilemez olacaktır ayrıca açık kaynaklı projelere yaptığınız her katkıyı CV’nize gururla yazabilirsiniz.

Bitti mi?

Şimdilik yazı burada sona eriyor. Yukarıda belirttiğim gibi sıradan bir Pardus kullanıcısından, Pardus geliştiriciliğine giden yolu anlatan yazı dizileri hazırlayacağım.

Staja katılmaya hak kazanan herkesi tebrik ediyorum.

Harika bir yaz bizi bekliyor olacak.

Share and Enjoy:

Bu yazı, staj başvurusunda bulunmak isteyenler ve Özgürlük İçin Podcast'teki staj ipuçları bölümü sonrası gözü korkanlar için. Staj başvurusunda bulunmak istemiyorsanız, Öİ Podcast'i dinlemediyseniz ya da gözünüz korkmadıysa bu yazısı okumayabilirsiniz :)

Geçen sene, staj duyuruları sonrası "Programcılar CV'leri Nasıl Okur?" başlıklı bir karikatürden bahsetmiş, başvuru yapanların nelere dikkat etmesi gerektiğini göstermeye çalışmıştım. Bugün yayınlanan Podcast'i dinlerken, karikatürün gereğinden fazla ciddiye alınabileceğini fark ettim. Sevgili Seda (Akay) ve Gizem (Belen), karikatürdeki "işletim sistemi ya da derleyici yazdıysanız puan kazanırsınız" derken, duyduklarım beni bile ürküttü. Geçen sene o karikatürü günlüğümde yayınlamam ve Gizem'e "geçen sene gönderdiğim karikatürde güzel tavsiyeler var" demem o kadar da iyi bir fikir değildi sanırım.

İşletim sistemi ya da derleyici yazmadıysanız, 3+ programlama dili bilmiyorsanız, bilgisayar kulübüne başkanlık yapmadıysanız, yarışma kazanmadıysanız korkmayın. Benim çizmediğim bir karikatür bu, bazı maddelerini çok beğendiğim için eklemiştim günlüğüme. Okunmasını tavsiye ederim (hâlâ), ama çok fazla da ciddiye almayın. "Pardus'a staja girmek, TÜBİTAK sınavını geçmekten zor" diye söylenmeyin, yok öyle bir şey :)

Ek: Karikatürü, Podcast'e konu olsun ve ziyaretçi sayım artsın diye yayınladığıma dair iddialar asılsızdır :)