Linux Gezegeni

Erhan Ekici: Ne onlar başka tanrının çocukları, ne de biz…

Per, 23 Eki 2008 22:48:01 +0000

“Ne senden fazlayım / Ne senden az / Aynı macerada ayrı biraz / Gözle biçim biçim / Kalple anlar içim / Ayrı gayrı olmaz / Sen yoksan ben hiçim Aç kardelen aç / Dağın olayım, suyun olayım / Göğün olayım aç Her çiçeğin kar altından / Güneşe giden masalında / Yaşamak yeniden tazelenir / Yeniden anlamlanır [...]

Tonguç Yumruk: Eve gitsem de güzel müzikler dinlesem

Per, 23 Eki 2008 22:47:56 +0000

...diyorsanız, ama ne dinleyeceğinizi bilemiyorsanız işte size bunun için güzel bir ortam. Bu site tamamen "Yahu bu albüm güzelmiş, blog'a yazmalı" diyipte yazamadığım günlerin neticesinde ortaya çıkmış bir ortam. Her türlü arıza veya öneri için tongucyumruk <salyangoz> fazlamesai.net adresinden kontak kurmak mümkün tabii. Kod mu? Kod da yakında açılıyor. Bizi izlemeye devam edin.

Murat Hazer: Agile Yazılım Geliştirme ve Scrum

Per, 23 Eki 2008 22:47:53 +0000

Hepimiz içinde bulunduğumuz projelerde çeşitli sorunlarla karşı karşıya kalıyoruz. Bu sorunlar projelerin zamanında bitirilememesine, müşterinin isteklerine uymayan yazılımlar üretilmesine ve hatta projelerin başarısız olmasına bile sebep olabiliyorlar. Ben kişisel olarak projelerin gidişatına ciddi etkilerde bulunan sorunların kaynağının geleneksel yazılım geliştirme süreçleri olduğunu düşünüyorum. İşte bu yazımda başlıktan da anlaşılabileceği gibi yazılım geliştirme süreçlerinden kaynaklanan sorunlara çözüm olarak üretilen Agile Yazılım Geliştirme'den ve Scrum'dan kısaca bahsedeceğim.

Projelerde karşılaştığım sorunlardan konumuza uygun olanları şu şekilde sıralayabilirim;

teknolojinin çok hızlı gelişmesi ve bu yeniliklerin projeye uygulanamaması
müşterilerin proje başlangıcında büyük resmin tamamını yani bütün gereksinimleri ortaya koyamamaları
müşterilerin gereksinimlerinin çok çabuk ve sık değişmesinden dolayı müşterilerin güncel ihtiyaçlarına cevap veremeyen bir yazılım ortaya çıkması
projelerin yönetiminin gittikçe daha zor ve karmaşık hale gelmesi (bir yazılım geliştirme sürecinde 102 ayrı role'un olduğunu duymuştum)

Dünyanın her köşesindeki yazılım geliştirme takımı gibi bu sorunlarla karşılaşan 17 profesyonel Amerika'nın Utah eyaletinde çözüm üretebilmek, müşteri memnuniyetini arttırabilmek ve başarısız olan projelerin oranını düşürmek için 2001 yılının Şubat ayında bir araya geliyorlar ve aşağıdaki manifestoyu ortaya koyuyorlar;

The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Copyright 2001, the Agile Manifesto authors

(daha fazla bilgi için agilemanifesto.org)

Manifestonun açıkca belirtiği gibi Agile geliştirme sürecinin amacı; plan, dökümantasyon, proses ve araçlardan ziyade müşteri memnuniyeti, çalışan yazılım, uyumlu yazılım geliştirme takımı ve müşteri isteklerinde oluşan değişikliklere göre kısa zamanda geliştirilebilecek yazılımlar üretmek (buradan Agile yazılım geliştirmenin plansız, dökümansız yazılım geliştirmeyi teşvik ettiği sonucuna varmamak gerekiyor çünkü Agile yazılım geliştirme sadece bunlardan daha önemli kavramların olduğunu vurguluyor). "Agile yazılım geliştirme" süreçlerin, dökümanların ve dizaynların proje başlangıcında tümüyle tanımlanmasını değil, geliştirme aşamasında karşılaşılan ve değişen koşullara göre gerekli kararların verilmesi gerektiğini savunuyor.

Scrum'u Agile yazılım geliştirme metodunun yukarıda bahsettiğimiz presiplerine uygun olarak geliştirilmiş ve tasarlanmış bir metod olarak tanımlayabiliriz. (Diğer metodlardan XP ve Lean Software Development hakkında detaylı bilgilere buradan ve buradan ulaşabilirsiniz). Scrum diğer agile yöntemleri gibi çok fazla kuralı olmayan, sadece belirli prensipleri olan ve kolayca projelere uygulanabilecek bir yöntem.

Scrum'un genel akış şeması;

Scrum'ı sadece yazılım geliştirmek için değil hayatta karşılaşabileceğiniz her türlü olaya uygulanabilecek bir yöntem olarak düşünebilirsiniz. Şimdi kısaca yukarıdaki şemada geçen kavramları genel bir Scrum planlaması ve akışı içinde adım adım anlatmaya çalışacağım.

1- Roller (Roles)

Ürün Sahibi (Product Owner)
Scrum Yöneticisi (Scrum Master)
Takım Üyesi (Team Member)

2- Toplantılar (Meetings)

Sprint Planlama (Sprint Planning)
Sprint gözden geçirme (Sprint Review)
Günlük Scrum toplantısı (Daily Scrum)

3- Kavramlar (Artifacts)

Ürün gereksinim dökümanı (Product Backlog)
Sprint dökümanı (Sprint Backlog)
Sprint kalan zaman grafiği (Burndown Chart)

Projenin başlangıç adımı olarak yazılım gereksinimlerinin (requirements, features) ürün sahibi tarafından ürün gereksinim dökümanına yazılmasını düşünebiliriz. Bu dökümanın sahibi ürün sahibidir ve gereksinimleri önceliklerine (priority) göre sıralar. Ürün sahibi bu dökümana yazılım geliştirme süresince eklemeler ve çıkarmalar yapıp öncelikleri değiştirme hakkına sahiptir. Böylece ürün sahibi değişen ihtiyaçlarına uygun olarak bir yazılıma sahip olma şansını yakalamış olur.

Gereksinimler belirlendikten sonra yazılım geliştirme takımı Sprint planlama toplantısında bir sonraki Sprint'de geliştirilmek üzere ürün gereksinim dökümanından ürün sahibinin belirlediği yüksek öncelikli gereksinimleri seçerek Sprint dökümanına aktarırlar. Bu toplantıya Scrum yöneticisi, ürün sahibi ve takım üyeleri katılırlar ve Sprint süresi en az 2 en fazla 4 hafta olarak belirlenir.

Sprint planlama toplantılarını Scrum yöneticisi yönetir. Scrum yöneticisinin asıl görevi Scrum'un temel prensiplerinin projeye uygulanmasını, bu prensiplerin takım üyelerince doğru şekilde anlaşılmasını sağlamaktır. En önemli görevi ise Sprint süresince takımı dışardan gelebilecek etkilere karşı korumak ve takımın ihtiyaçlarını karşılamaktır.

Scrum her Sprint'in sonunda mutlaka ürün sahibine kullanabileceği bir yazılım sağlamayı hedefler, bundan dolayı planlanan Sprint süresi (2-4 hafta) asla uzatılmaz. Fakat eğer bir gereksinim belirlenen Sprint süresi içerisinde gerçekleştirilemeyecekse bir sonraki Sprint'e aktarılabilir. Ve aynı şekilde eğer Sprint süresi bitmeden Sprint dökümanındaki gereksinimlerin hepsi tamamlanmışsa ürün gereksinim dökümanından yeni gereksinimler Sprint dökümanına aktarılabilir.

Sprint planlama toplatısında belirlenen gereksinimler takım üyelerince küçük görevlere (tasks) bölünerek takım üyelerine geliştirilmek üzere atanır. Scrum takımı geleneksel yazılım geliştirme süreçlerinden farklı olarak kesin rollere (architect, tester, developer, disagner vb.) sahip değildir. Scrum takımındaki bütün üyeler çapraz görevlerde yer alabilirler, böylece kodun tek bir kişiye bağımlılığı riski ortadan kaldırılmış olur. Sprint dökümanının sahibi bu sefer ürün sahibi değil yazılım geliştirme takımıdır, dolayısıyla bu dökümana ürün sahibi değil takım üyeleri katkıda bulunurlar.

Sprint dökümanına aktarılan gereksinimlerin tahmini geliştirme süresi saat bazında takım üyelerince belirlenir ve Sprint boyunca sürekli olarak tahmini bu zamanlar güncellenerek Sprint kalan zaman grafikleri (burndown chart) oluşturulur. Böylece Sprint süresince ürün sahibi ve scrum yöneticisi Sprint'in genel gidişi hakkında bilgi sahibi olur, aynı zamanda takım elemanları da kalan iş sürelerini ve harcadıkları zamanı takip edebilirler.

Scrum'un belki de verimliliği artıran en önemli kavramlarından biri de günlük Sprint toplantılarıdır. Bu toplantılar her gün belirli saatlerde farklı bir takım üyesinin liderliğinde ayak üstü yapılır ve en fazla 15 dakika sürer. Bu toplantılarda her takım üyesi şu 3 soruya cevap verir;

Dün ne yaptım?
Bugün ne yapacağım?
Önümde olan engeller ve karşılaştığım sorunlar neler?

bu toplatılara herkesin zamanında ve davet edilmeden katılması ve uzun sürmemesi çok önemlidir. Bu toplatılar sayesinde takım üyelerinin her biri diğer üyelerin nelerle uğraştığını öğrenme fırsatını edinirler ve çalışacakları işleri diğerleriyle paylaştıkları için işlerine daha iyi konsantre olabilirler.

Her Sprint'in bitiminde ortaya konulan ürün hakkında geri besleme alabilmek için yazılımla alakalı her türlü kişiye (Ürün sahibi, pazarlama, diğer takımlar vs.) açık Sprint gözden geçirme toplantısı yapılır. Bu toplantının amacı yazılımın ürün sahibinin gereksinimlerine uygun olarak geliştirildiğinden emin olmaktır. Bu sayede müşterinin gereksinimleri bir şekilde yanlış anlaşılmış ise bu farkedilir ve bir sonraki Sprint'de bu hataların önüne geçilir.

Bu adımlar ürün sahibinin ürün gereksinim dökümanına yazdığı, zaman içinde geliştirip, değiştirdiği gereksinimler bitene kadar tekrarlanır.

Umarım burada anlattıklarım Agile ve Scrum hakkında bir fikir sahibi olmanızı sağlamıştır. Özellikle Scrum'un projelerinizdeki başarı oranlarını ve kişisel olarak verimliliğinizi arttıracağına inanıyorum. Scrum ve Agile ilgili deneyimlerinizi ve sorularınızı paylaşabilirseniz sevinirim.

Scrum ile ilgili daha detaylı bilgilere aşağıdaki linklerden ulaşabilirsiniz.

Kaynaklar:
http://agilemanifesto.org/
http://www.pragprog.com/titles/pad/practices-of-an-agile-developer
http://en.wikipedia.org/wiki/Agile_software_development
http://www.ibm.com/developerworks/rational/library/08/0701_ellingsworth/
http://scrum-master.com/en/default.aspx
http://www.scrumalliance.org/

Erol Soyöz: Mercurial

Per, 23 Eki 2008 22:47:12 +0000

PHPMagazine'de, CVS, SVN v.b kaynak kod yönetim araçları yerine, daha gelişmiş ve basit olan Mercurial'in kullanımına teşvik etmek için bir yazı hazırlanmış. Okunabilir de, okunduktan sonra uygulanabilir de.

Nesimi Acarca: QTicari Beta-1

Per, 23 Eki 2008 22:47:10 +0000

QTicari, modüler otomasyon sisteminin beta-1 sürümü kullanıma hazır. Bu sürüm ile birlikte projenin lisansı da, GPLv3 olarak değiştirilmiştir. (Alpha-1 GPLv2 idi)

Projeye destek olmak için :

http://www.nesimia.com/projects/qticari#donate adresine tıklayıp bağış yapabilir.
Yeni modül yada belge yazabilir.
Tavsiye edebilir.
Olmadı, bir hayır duası edebilirsiniz.

İlk seçenek tercihimizdir. :-)

Projenin kaynak kodları ve ekran görüntüleri için:
http://www.nesimia.com/projects/qticari adresine tıklayabilirsiniz.

Şuan proje içerisinde iki adet modül, barkod ve ticari modülleri tümleşik olarak gelmektedir. Bu modüller hakkında kısaca bilgi vermek gerekirse;

Ticari: Bünyesinde; cari, stok, kasa, fatura gibi temel muhasebe modüllerini barındıran paket.
Kullanım belgeleri için:
http://forums.nesimia.com/index.php?9 adresine tıklayın.

Barkod: Barkod etiket tasarımı yapıp, çıktı alabilmenize yarayan modül.
Kullanım belgeleri için:
http://forums.nesimia.com/list.php?15 adresine tıklayın.

Ayrıca;

Kurulum ve yapılandırma belgeleri için:
http://forums.nesimia.com/list.php?8 adresine tıklayın.

Forumlar için :
http://forums.nesimia.com/index.php?5 adresine tıklayın.

Ali Erkan İMREK: Pardus'a katkı yapmak

Per, 23 Eki 2008 12:48:48 +0000

Pardus, 2007 sürümüyle beraber geniş kitlelere ulaşmayı başarabildi, ben 2008 sürümünün, 2007'den 2007.3'e kadar olan yükselen kalite ivmesini devam ettiremediğini düşünüyorum ama bu kullanıcı kitlesinin genişlemesini etkilemedi. Bunda mevcut kullanıcıların Pardus ile bir gönül bağı kurmuş olduğunu ve yeni kullanıcılar açısından da Ulusal Dağıtım fikrinin çekiciliğinin önemli rol oynadığını düşünüyorum. Bu kadar hızlı büyüyen bir toplulukta da projeye katkı yapmak isteyen her seviyeden kullanıcı olması beklenen bir durumdur.

Kullanıcıların az bir kısmının Linux konusunda tecrübeli ve yetkin kişilerden oluştuğu büyük çoğunluğunda AWB (Ağır Windows Bağımlılığı) olan kullanıcılar olduğu forum ve e-posta listelerinden anlaşılıyor. Bu çoğunluğun belgelendirme, çeviri ve hata raporlama konusunda planlı bir şekilde bilinçlendirilmesi gerektiğini düşünüyorum. AWB'den dolayı bu durumdaki kullanıcıların pek çoğu Linux dağıtımlarını birilerinin bir yerlerde kendi halinde kodladığı kendisinin de sadece inidirp kurup kullanacağı bir sistem olarak görüyor. Katkı konusunu da program yazmak olarak anlıyor. Bu konuda wiki sayfalarında belgeler var isteyen gider okur denilebilir ancak ben wiki sayfalarını sadece ne aradığını ve nerede bulacağını bilen kişilerin okuduğunu düşünüyorum. Bu durumda Pardus ekibince kullanıcılara tek adres olarak gösterilen özgürlükiçin sitesinin "Katkı" konusunda yol gösterici, bilinçlendirici ve özendirici yeni bölümleri ve projeleri olması gerektiğini düşünüyorum. Özgürlükiçin bugüne kadar hep içeriden dışarıya bir bilgi akışını sağlama yönünde gelişti, en son "Beyin" projesiyle dışarıdan içeriye akışı sağlayan bir gelişme sağlandı. Artık bundan sonraki adımların özelde "Katkı" konusunda ve genelde dışarıdan içeriye yönelik olması gerekiyor.

Bunları yazmama neden olan şey aslında ileri seviye bir kullanıcının aşağıdaki adreste gördüğüm pisi paketleri [1] , bu arkadaş Pardus'u kullanmış, kullanmakla kalmamış katkı da yapmış. Ama bu paketleri Pardus deposu yerine kişisel sayfasında yayınlamış. Acaba neden Pardus deposuna girmemiş, katkı için başvurmamış mı? başvurmak istemiş bilgi mi bulamamış? geri mi çevrilmiş? diğer dağıtımlar için yaptığı paketlere bakınca Pardus için de iyi bir katkıcı olabileceğini ama neden Pardus'un bu kişiyi kazanamadığını merak ettim. Daha korkunç bir soru acaba bu kişi gibi kendi halinde paketleme yapan kaç kişi var?

Pardus'un bir contrib deposu var ancak bu depoya herkes paket gönderemiyor, bu konudaki teknik konuları bilmiyorum ama contrib deposunun en az temel depo kadar formalite taşıdığını ve test süecine tabi olduğunu sanıyorum. Ben resmi depolarda olmayan paketlerin bulunduğu (belki kullanıcıların kendi yaptığı programlar için) kullanımı tamamen kullanıcıların sorumluluğunda olacak testleri ve bakımı kullanıcılar tarafından yapılacak ama Pardus sunucularından hizmet verecek daha özgür bir depo hayali kuruyorum.

Bu konuda zaten www.pardus-linux.org sitesi açtığı depo ile önemli bir adım atmıştı, ben bu depoların ve sitelerin ülkemizde ve Dünya'da daha da çoğalmasının Pardus'a her zaman fayda sağlayacağını düşünüyorum. Ama bu konularda öncülüğü Pardus ekibinin yapmasını da bekliyorum.

Belki yazılacak daha çok şey vardır ama aklıma gelenleri hızlıca yazdım.

[1] http://www.maccusfoto.nl/maxmenu/rpms.html

Enver Altın: The death of the dollar?

Per, 23 Eki 2008 07:45:00 +0000

From BBC Business, on his corner Prof. Ngaire Woods provides a good easy-read overview of the global economic status-quo and speculates on potential consequences of redistribution of economic power following the turmoil. Definitely worth reading. I don't have much to say, because I agree wholeheartedly.

Serkan Kaba: Türkçe yerel ile hatalı çalışan programlar

Per, 23 Eki 2008 07:00:30 +0000

Java’da daha önce pek çok kez karşılaştığım bir hatayı Python ile yazılmış olan Bazaar’da da yaşayınca buraya yazmak istedim. Java ve muhtemelen Python da büyük küçük harf çevrimlerinde aktif yerelin özelliklerini dikkate alıyor. Ancak bunun gerekmediği hatta istenmediği durumlar olabiliyor. Bunlara örnek olarak kod üreticiler verilebilir. Türkçe’deki I->ı ve i->İ çevrimi nedeniyle bazı programlar hatalı [...]

Bora Güngören: Mac OS X'de GCC kurulumu

Per, 23 Eki 2008 03:35:00 +0000

2000-2001 dönemlerinde Apple'ın kendisi de derleyici olarak GCC kullanmaya başladığı için Mac OS X'de GCC kurmak oldukça kolay bir şey. Yapmanı gereken ilk şey Apple Developer Connection sitesine üye olmak. Burada geleneksel bir form dolduruyorsunuz. Apple'ın merak ettiği önemli bir şey herhangi bir üniversitede öğrenci durumunuz olup olmadığı. Arkasından geliştirici olarak ne yaptığınızı soran çok basit ve çok hoşuma giden bir anket hazırlamışlar. Programlama dili ve benzeri detaylara hiç girmemişler. Kimin için, hangi tür yazılımları hangi işletim sistemlerinde yazdığınızı öğrenmek onlara yetiyor.

Bir kez Apple Developer Connection (ADC) üyesi olunca, çok çeşitli araçları indirebiliyorsunuz. Bunlar arasında Mac OS X çekirdeği için hata ayıklayıcı gibi şeylerden türlü türlü SDK'lara kadar çok farklı paketler var. Elbette benim esas ilgimi çeken XCode aracı. Yalnız dikkat edilecek bir şey var. Bu araç ekleri vs ile yaklaşık 1.2 GB boyutundaki bir paket ile geliyor. Yani tek başına GCC kurmak isteseniz dahi, önce bütün araç paketini çekmeniz sonra da kurulum sırasında sadece GCC'yi çekmeniz gerekiyor.

Uzun bir indirme ve bir kaç tıklama sonrasında XCode'u kurunca /usr/bin/gcc adresinde GCC kurulmuş oluyor.

Enver Altın: Makine Mühendisleri Odası İstanbul Şubesi'nde Özgür Yazılım sohbeti

Çar, 22 Eki 2008 08:18:00 +0000

Haberler her yerde, yeni LKD Seminer Çalışma Grubu ekibi azmetmiş, kendilerine teşekkür ediyorum.

Bugün, 22 Ekim saat 19:00'da Makine Mühendisleri Odası İstanbul Şubesi'nde Özgür Yazılım konusunda biraz sohbet edeceğiz. Katılım herkese açık, adres ve kayıt için gerekli bilgiler MMOIstanbul.org'da.

Alper Kanat: Subversion, Bazaar ve GIT Üzerine..

Çar, 22 Eki 2008 01:12:45 +0000

raptiye'yi Bazaar üzerinde sunduğumu daha önceki yazılarımdan birinde söylemiştim. Işık Üniversitesi Kulüpler Sunucusu'nda, Parkyeri'nde, Arch Linux Türkiye projelerinde ve kendi yaptığım işlerin bir kısmında Subversion tercih ediliyor. Bunun dışında bir çok sürüm yönetimi sistemi var elbet ve bunlardan en önemlilerini (GIT, Mercurial) araştırdıktan sonra Bazaar kullanmaya karar verdim. Bu yazıda bu konuyla ilgili dikkatimi çeken ve önemli bulduğum şeyleri paylaşmaya çalışacağım. Bir çok insanın sürüm yönetimine kavram olarak yabancı olduklarını düşündüğümden çok kısa bir şekilde onu da açıklamak istiyorum.

Sürüm Yönetimi Sistemleri Nedir?

İngilizce'de Version Control System (VCS) olarak geçen, dilimizde iyi anlatabilmek için yukarıdaki gibi uzun olan sürüm yönetimi, bazı yerlerde revizyon yönetimi gibi de kullanılıyor. Sürüm Yönetimi'ni, yazılımın aşama aşama geliştirildiğini düşünürsek, bu aşamaları kayıt altında tutan, istenildiğinde geri dönülmesine olanak tanıyan, aşamalar arasında neler olduğunu kolaylıkla gösterebilen yazılımlar olarak özetleyebiliriz. Geliştirici'nin hayatını kolaylaştırdığı kesin! Bu yazılımlardan neler beklendiğini maddeler halinde yazarsam sanırım daha iyi anlaşılacaktır:

Kodda yapılan tüm değişimler birer revizyondur.

Revizyonlar arasında değişen dosyalar, dosyalardaki değişiklikler (gerekirse yama olarak) kolayca görüntülenebilmelidir.

Herhangi bir revizyondan sonra işler yanlış gittiyse, o revizyona kadar olan kısım geri alınıp hiç bir şey olmamış gibi devam edilebilir.

Herhangi bir dosyada yapılan değişiklikler kodun geri kalanından bağımsız olarak geri alınabilmelidir.

Birlikte çalışılan projelerde, diğerlerinin yaptığı değişiklikleri alabiliyor olmalı ve bunu yaparken de olabildiğince az (mümkünse sıfır) çakışmaya izin vermelidir.

Ek maliyetler getirmemeli, hızlı ve kolay olmalıdır. Mümkünse her platformda çalışmalıdır.

Tüm bunlar bir arada düşünüldüğünde geliştiricinin işlerini kolaylaştıran ve hızlandıran etmenler.. Bu ihtiyaçlara cevap verebilmek adına kullanılabilir durumda bir sürü sürüm yönetimi yapan yazılım var. En meşhuru olan CVS'in, doğal gelişim süreci içinde yetersiz gelmeye başladığı ortaya çıkınca ortaya Subversion çıkmış. Şu anda bir çok ihtiyacı görüyor gibi görünse de ileride yetersiz kalacağını görenler Bazaar, GIT ve Mercurial gibi alternatifler geliştirmişler. Gelin; bu sistemlerin yukarıdaki maddelere ek olarak getirdiklerine bakalım:

Sürüm yönetimi için çevrimiçi olmak gerekmemeli! Teslimat (commit), Birleştirme (merge), tarihçe gibi işlemler için herhangi bir sunucuya bağlanmak gerekmemeli.. Kısaca merkezi sisteme hayır!

Kod tabanı dağıtık bir yapıda olabilir ve insanlar birbirlerinden değişik kısımları ya da kodun tamamını alabilirler.

Her kopya, sürüm kontrolüne ait tarihçe vb. kritik önem taşıyan bileşenleri barındırır.

Her kopya aslında yeni bir daldır (branch)!

Birleştirme işlemi acı vermeyen, sürekli yaptığımız; hatta zevk veren bir işlem olmalıdır!

Çevrimdışı çalışma = hız!

Büyük şirketlerde sıkça rastlanan "kod çalışana ve tüm testleri geçene kadar teslim edemezsin!" mantığı yüzünden tüm değişikliklerin tek ve kocaman bir yama olarak gönderilmesi sorunlara yol açabiliyor. Bunun yerine yerel ve küçük küçük teslimatlar yapabilir; daha sonra değişiklikler ana sunucuya teslim edilebilir hale geldiğinde her değişiklik birer revizyon olacak şekilde ana sunucuda yerini alır. Böylece yapılan büyük bir değişiklikte bile atomik değişiklikler geri alınabilir ve rahatlıkla düzeltilebilir.

Peki Alternatifler Neler?

Bunları ve daha fazlasını yapabilen uygulamaların bulunduğu kümeye Dağıtık Sürüm Yönetimi Sistemleri (Distributed Version Control Systems) deniyor. Linus Torvalds, Linux çekirdeğinin geliştirilmesinde kullanılan BitKeeper ile ilgili sorunlar yaşanmaya başlanınca bu konuya kendi çözümünü getirip GIT adında bir yazılım yazmış. Dağıtık Sürüm Yönetimi ve GIT hakkındaki düşüncelerini paylaştığı şu video'nun epey yararlı olduğunu söyleyebilirim.

Mercurial'ı Arch Linux Türkiye projelerini yönetmek için Samed BEYRİBEY'in önerisiyle denemeye başladık. Başlarda fazla araştırmadığım için oldukça yabancı gelmiş ve ısınamamıştım. Tıpkı GIT gibi "commit", "checkout" vb. alıştığımız anahtar sözcükler yerine başka sözcükler tercih ediliyordu ve bu da kafa karıştırıcı oluyordu. Mercurial, sırf bu yüzden dumur olan insanlara kolaylık olması amacıyla bu sözcükleri içinde bulunduruyor yine de.. Bir süre denedikten sonra bir hayli karışık geldiğinde kullanımından vazgeçtik ve böylece Mercurial defteri kapanmış oldu.

GIT, şu anda bir hayli revaçta olan bir yazılım.. Bir çok özgür yazılım projesi tarafından tercih ediliyor ve sayıları giderek artıyor. Benim GIT'i tercih etmememdeki en büyük sebepler şöyleydi:

GIT içerisindeki kodu sunmak için bir sürü ayarla uğraşmak istemedim.

GIT'in getirdiği terminoloji öğrenmesi zaman alacak gibiydi.

Dökümantasyonu Bazaar kadar açık ve rahat okunabilir değil.

Herhangi bir web servisi ile alakası yok.. (Bazaar'ın LaunchPad desteği gibi..)

Boş dizinlerin sürüm yönetimi içinde bulunamaması ve içine boş birer dosya koyma zorunluluğu hoşuma gitmedi.

Platform bağımsız değil. Windows'da çalışmıyor. (ya da desteği henüz yetersiz)

Öte yandan araştırmamı daha çok Bazaar ve GIT karşılaştırması yapan yazılar üzerinde yoğunlaştırmıştım. Bazaar'ın hoşuma giden özellikleri şöyle:

Kodunuzu sunmak için herhangi bir sunucu kurmanıza gerek yok. Zaten varolanlar ile birlikte zaten bir hayli seçeneğiniz var:
- bzr://,
- sftp:// (SSH),
- ftp://, http:// (webdav),
- file:// (yerel dosya sistemi)

Dökümantasyonu (özellikle anlatımı) ve sitesi oldukça etkileyici..

LaunchPad desteği sayesinde tek bir komutla servisle etkileşim halindesiniz.

Boş dizinler de (doğal olarak) sürüm yönetimine dahiller.

Linux, Mac OS X ve Windows'da sorunsuz olarak çalışabiliyor.

Bazaar'la ilgili beni en çok etkileyen şey kodumu sunmak için çok fazla uğraşmama gerek olmamasıydı. Varolan kodumu sürüm yönetimi altındayken kullandığım ağ sunucusu ile sunmam yeterli! Örneğin raptiye'nin kod tabanını nginx ile sunuyorum (http://code.raptiye.org) ve Bazaar kullanan bir kişi http:// protokolü üzerinden kodu dallandırabiliyor!

Bir çok kişi Subversion kullanımına; dolayısıyla da merkezi sisteme alışık olduğundan Bazaar'ı bu şekilde yapılandırıp yarı-dağıtık bir model ile kullanabilirsiniz. Uzaktaki kodu yerelinize indirip (dallandırıp) tüm değişikliklerinizi çevrimdışı olarak kendi bilgisayarınızda yapabilir, dilediğinizce farklara bakıp, tarihçeyle ilgili işlem yapabilir, yerel teslimatlar yapabilirsiniz. İşiniz bittiğindeyse kodun son halini sunucuya gönderebilirsiniz. raptiye'de tek kişi çalıştığım için şu anda bu modeli sıkça uyguluyorum. Biraz da kullanımdan örnek verirsem daha iyi olacak sanırım..

Öncelikle kodu kendi yerelimde dallandırıyorum:

bzr branch http://code.raptiye.org/raptiye/main/ raptiye

Daha sonra bir takım değişiklikler yapıp yaptıklarımı gözden geçirmek için şu komutu veriyorum:

bzr diff|vi -

bzr diff komutu yaptıklarımın son revizyon ile farkını gösterirken "|vi -" komutu ise çıktıyı VI adlı editöre yönlendirir. Bu şekilde yaptıklarımı renkli ve daha okunabilir olarak izleyebiliyorum.

Yaptıklarımdan memnun kaldım ve teslim etmek istiyorum:

bzr ci

ci komutu commit komutunun kısaltması bu arada.. Bu komut sayesinde orjinal kodun kendi yerelimdeki dalında ilk teslimatımı yapmış oldum. Bu değişiklikleri ana sunucuya atmak istersem:

bzr push

komutunu kullanmalıyım. Bu komutu ilk kez kullanıyorsanız kodun yükleneceği yeri de belirtmelisiniz:

bzr push sftp://user@domain.com/home/code/raptiye/main/

Bu noktada önemli bir konuya değinmekte de fayda var. Performans kaynaklı sebeplerden dolayı bzr push komutu uzaktaki sunucunun yalnızca tarihçesini günceller ancak kod üzerinde gerekli olan değişiklikleri yapmaz. Bu değişiklikleri yapmak için sunucu üzerindeki kod tabanında bzr up komutunu çağırmalı ya da bunu sizin için yapan bir eklentiyi indirip yerelinize kurmalısınız.

Proje üzerinde birden fazla kişi çalıştığında sunucu üzerinde her geliştirici için bir hesap açmak istemeyebilirsiniz. Bu durumda ağ sunucusunda http protokolü üzerinden belli kişilere erişim izinleri tanımlayarak teslimat yaptırabilirsiniz. nginx üzerinde webdav yerine wsgi ayağı kullanılıyor ancak wsgi, nginx'in geliştirilme hızına yetişemediğinden ben çalıştırmayı beceremedim. (nginx'i, wsgi desteğiyle derlemekten bahsediyorum -- wsgi tarafında yamalar var ama onlar bile eski..)

Bundan sonraki projelerde Bazaar benim sürüm yönetimi için tercih etmeye devam ettiğim yazılım olacak. Eminim benimkini kolaylaştırdığı gibi sizlerin de hayatını kolaylaştıracaktır.

Özgürlükiçin.com: Test Takımı Sizi Çağırıyor!

Sal, 21 Eki 2008 14:27:00 +0000

Özgür yazılım süreçlerinde kullanıcıların katkı verebileceği birçok alan bulunmakta. Bu alanlar doğrudan kod yazmak ya da bileşen geliştirmek olabileceği gibi kod yazmayı bilmeyenlerin de katılabileceği pek çok işi de içeriyor. Çeviri, grafik desteği, hata bildirimi, belgelendirme çalışmalarının yanı sıra hem kendinizi geliştirebileceğiniz hem de Pardus'a katkı verebileceğiniz önemli bir alan daha var: Test süreçleri.

Test süreçlerinde görev almak için yüksek bir bilgi gereksinime gerek yok. Bununla birlikte test süreçleri, kullanılan yazılımları daha iyi öğrenmenizi, işlevlerinden haberdar olmanızı ve bu sayede bilginizin artmasına da yardımcı olur. Test süreçlerine katılmak, aynı zamanda özgür yazılım dünyasında geliştirme süreçlerinin nasıl işlediğini görebilmek ve ilerde bir Pardus geliştiricisi olmak için de iyi bir başlangıç noktası oluşturur.

Pardus Projesi'nde de tüm özgür yazılım projelerinde olduğu gibi test süreçleri son derece önemseniyor. Özgür yazılım bileşenleri her ne kadar çok sayıda geliştirici tarafından incelense de hatalar içermesi ya da bazı donanımlarla uyumlu çalışmaması olasılığı kaçınılmazdır. Pardus Geliştiricisi Serbülent Ünsal'ın liderliğini yaptığı Pardus Test Takımı ise gerek sürüm öncesi gerekse sürüm sonrası testlerle bu hataların en aza indirilmesini ve Pardus kullanıcılarının daha iyi bir bilgisayar deneyimi yaşamasını amaçlıyor.

Pardus Test Takımı, test süreçlerini iki aşamada yürütüyor. Bunlardan ilki sürüm testleri. Yeni Pardus sürümleri çıkmadan önce test takımı ile paylaşılan Pardus Test ve Geliştirici Sürümleri, Test Takımı tarafından o sürüm için hazırlanan test kılavuzlarının yönlendirmesi ile test ediliyor Bu testlerin sonunda ortaya çıkacak muhtemel sorunlar Test Takımı üyeleri tarafından test e-posta listesine bildirilir ve bu bildirimler ışığında sorunların çözümü sağlanarak daha kararlı ve daha fazla donanımla uyumlu Pardus sürümlerinin kullanıcılara buluşması sağlanılır.

Test Takımı'nın işi sadece sürüm öncesi testleri ile sınırlı değildir. Test Takımı, sürümlerin çıkmasını takip eden süreçte yapılan güncellemeleri de test ediyor. Bu testler sayesinde Pardus kullanıcılarının kullandığı kararlı depolara güncellemeler girmeden önce testlerinin yapılması ve güncellemelerin bir soruna yol açması durumunda bu sorunların tespit edilmesi sağlanıyor. Güncellemeler önemlerine ve sistemin kararlılığına olan etkilerine göre gruplara ayrılmış olup, bazı paketlerin güncellemeleri çok detaylı bazı paketlerin güncellemeleri ise daha az detaylı olarak test edilmektedir.

Haberimizin başında da belirttiğimiz gibi, Test Takımı'na katılmak için yüksek bir bilgi birikimine ve donanım ihtiyacına gereksiniminiz yok. Bilgisayarınızda oluşturacağınız sanal makinelerle ya da test süreçlerine tahsis edeceğiniz bir bilgisayar ile test takımına katılmanız mümkün. Bunun için başlangı düzeyinde Pardus kullanmayı bilmeniz yeterli.

Biz de Özgürlükİçin olarak bundan sonra Test Takımı'na verdiğimiz desteği daha da artırarak, test sürecine mümkün olduğunca daha fazla katkıcımızın dâhil olmasını amaçlıyoruz. Eğer siz de Pardus'un oluşumuna katkı vermek istiyor ama nereden başlayacağınızı bilmiyorsanız, hemen bu adreste yer alan formu doldurun ve psts _at_ pardus.org.tr adresine yollayarak gün geçtikçe büyüyen ve Pardus için çok önemli bir süreci yürüten Test Takımı'na katılın. Özgürlükİçin Forumlarında da test süreçleri ile ilgili fikirlerinizi paylaşabilirsiniz.

Özgürlük için... Pardus'u Test edin!

Hakan Uygun: Ekonomik Krize Çözüm : Özgür Yazılım

Pts, 20 Eki 2008 22:38:20 +0000

Hepimizin malumu ekonomik kriz kapıda. Şirketler kemer sıkma politikalarına başladılar. Bir sürü blogda krizin olası etkileri ve bunlarla nasıl baş edilir yazısı yayınlanıyor.

TechCrunch iki haftadır web 2.0 şirketlerinin durumları ve aldıkları önlemler üzerine yazılar yayınlıyor. Aynı şekilde webrazzi‘de krizin genelde internet sektörü özelde ise Türkiye internet sektörü üzerine etkisini incelemiş…

Krizle baş etme konusunda en ilginç yaklaşımlardan birini startupların piri Paul Graham sunuyor :”If nuclear winter really is here, it may be safer to be a cockroach - Eğer nükleer kış geldiyse, en güvenlisi hamam böceği olmaktır”. Yeni bir iş başlatmak ( startup ) için en uygun zamanın kötü ekonomiler olduğunu söylediği makalesinde küçük ve masrafları az olan bir işletmenin kötü ekonomilerde hayatta kalma şansının diğerlerinden daha fazla olduğunu ifade ediyor.

Kısaca herkesin söylediği : Maliyetlerinizi ne kadar düşürürseniz nakit problemleri ile o kadar az uğraşırsınız, dolayısı ile kriz süresince yaşarsınız.

İşte tamda bu noktada özgür yazılım işletmelere büyük olanaklar sunmakta. Sahipli yazılımların binlerce dolara mal olduğu bir ortamda bilişim ihtiyaçlarını özgür yazılım çözümleri ile giderip, bir yandan maliyetleri düşürürken bir yanda da teknolojik olarak rakiplerin önüne geçilebilir.

Bu konuda özgür yazılım avantajlarını anlatan örneğin şu makaleye ya da şu blog‘a bakılabilir. Ayrıca özgür yazılım alternatifleri için bu sayfaya, Türkiye’de geliştirilen özgür yazılımlar için ise bu sayfaya bakılabilir.

Umarım bu krizi kazasız belasız atlatmanın ötesine geçip daha da güçlenerek çıkarız.

Hakan Uygun: Internet, Radyo ve Diğer Şeyler

Pts, 20 Eki 2008 13:35:01 +0000

Bir süredir, alışkın olduğum, daimi internet bağlantılarından uzak yaşamak durumunda kalıyorum. Müşteri ofislerinde, toplantılarda, şehir içinde ortalık da dolaşırken internet erişimi ciddi bir problem oluyor. Uzun bir zamandır neredeyse daimi internet erişimi olan biri olarak hemen tüm iletişim ihtiyacını internet ve e-posta ile gerçekleştirirken birden bire uzak kalınca bocaladım. Bir dolu şey aksamaya başladı.

Çözüm olarak mobil internet erişimlerini düşünmeye başladım. Karşıma çıkan bir kaç alternatif arasından Nokia E71‘i tercih ettim. Artık e-posta ve internet erişimi ( biraz pahalıya gelse de ) elimin altında.

Bu acil iletişim problemini çözünce başka bir sorun ile karşı karşıya kaldım. Taşınabilir bilgisayarımda hiç mp3 yok, çünkü last.fm dinliyordum. Diğer şeylerle birlikte internet kopunca last.fm’i de kaybettik Çözüm gene E71 oldu. Fakat last.fm’i hala çok arıyorum. Çalan parçadan hoşlanmazsanız bu şarkıyı geç diyemiyorsunuz, en fazla yapabileceğiniz radyo kanalını değiştirmek, ki bu halde bile çoğu zaman hoşlanmadığınız başka parçalara denk geliyorsunuz

Sözün kısası “İnternet Yaşamdır” diyorum…

Serkan Altuntaş: Samsung ML-1610 Mono Laser Printer

Paz, 19 Eki 2008 20:36:35 +0000

Babam acilen bir lazer yazıcıya ihtiyaç duyunca bugün aşırı değerli dolara rağmen Samsung ML-1610 Mono Laser Printer aldık. Hatta o kadar acilen lazımdı ki şehirdeki Bimeks ve iki Teknosa’da bu modelden kutusu açılmamış tek bir ürün bile kalmadığından benim hiç yapmayacağım bir şeyi yapıp teşhir ürününü aldık. Gerçi karlı da çıktık. Normalde kutuyla gelen %60 [...]

Necati Demir: Ülkemden Şahit Manzaraları - I

Paz, 19 Eki 2008 16:44:00 +0000

Dikkat: Gerçek Bir Olaydır!

40 yaşlarında bir adam, 1 yaşını henüz doldurmuş çocuğu için dışarı süt almaya çıkmıştır. Mahallede bir bağrışma duyar, yaklaşır. Bir kavga gürültü vardır, olay biterken jandarma sorar: "şahit misin?". "Evet" cevabını veren adam o akşam evine dönemez. O akşam nezarethanede kalır, ertesi gün cezaevine gönderilir. Anlamamıştır, şahit olmaya gelmişti sadece. 45 gün sonra duruşma var derler, 45 gün cezaevinde kalmak zorundadır. 45 gün sonra da heyecan içinde çıkacağını düşünmektedir, ne de olsa sadece şahit olmaya gelmişti. Ve mahkeme günü gelip çatmıştır, çıkıp çocuklarını görecektir artık. Zaten, cezaevindeki görüşlerde de karısına, "çocuklara dikkat et" deyip durmuştu, özlemişti anlaşılan. Ama, o gün hakim mahkemeyi 1 ay erteler. Özlemle sarılma umutları bir anda sönmüştür Sebepsiz yere 1 ay daha 4 duvar arasında yaşamak zorunda kalacaktır.

Enver Altın: A brave new world

Paz, 19 Eki 2008 07:54:00 +0000

End of an era marks the beginning of another one. With enormous sculpted success standing right behind me, I've recently quit Cellenity to explore what else the future has to offer.

On the way back home I stumbled upon the tail of this guy:

I spent the time and fuel that I'd normally be wasting around rush-hours Istanbul traffic on shows like Cebit Eurasia and Autoshow. Quick sum: Cebit is incrementally better every year, but Autoshow was spectacular. I've had the privilege to peek inside the Megane Coupe Concept, I shook hands with a member of the team who designed Sakarya University's 100% solar-cell racing car. Although fun, the rest was usual: short skirts, leg ladies, inefficient internal combustion engines, ugly car designs, little-to-no steps forward in evolution of transportation. Hybrids and electric vehicles receiving more attention was encouraging.

What comes next, I'll be blogging.

Murat Hazer: JBoss Seam kitapları ....

Cum, 17 Eki 2008 23:24:13 +0000

Bir önceki yazımda JBoss Seam'in klasik Java Enterprise Development (JEE)'a kazandırdığı çeviklikten, programlama modeline, metodolojisine getirdiği devrim niteliğindeki özelliklerinden bahsetmeye çalıştım. Yeni bir teknoloji öğrenmenin en iyi yolunun o konu hakkında yazılmış kaliteli kitap(lar)ı okumak olduğunu düşünenlerdenim. Bu yazımda da Seam hakkında yazılmış kitapları ve bu kitaplar hakkındaki düşüncelerimi paylaşmaya çalışacağım.

"Seam in Action" Seam'i en kapsamlı şekilde anlatan, okunması rahat ve bol örnekleri olan bir kitap. Manning yayınevinin diğer kitapları gibi bu kitap da oldukça kaliteli ve çok iyi edit edilmiş. Bu kitabı Early Access seviyesinden beri takip ediyorum ve her sayfasından yeni bir şeyler öğrendim diyebilirim. Ayrıca referans kitabı olarak kullanılabilecek şekilde kapsamlı olduğu için başucu kitabı niteliğinde. Fakat kitap Seam'e ilk başlayanlar için biraz ağır gelebilir onun için biraz deneyim kazanıldıktan sonra okunmalı. (5/5)

Apress yayınevinden çıkan "Beginning JBoss Seam" özellikle yeni başlayanlar için çok yararlı diyebilirim. Özellikle Seam'in getirdiği yeniliklerden Bijection ve Web Conversation kavramının temellerini başarılı ve kolay anlaşılır bir şekilde anlatıyor.
(4/5)

Seam'in 1.x versiyonu sürecindeki geliştiricilerinden Michael Juntao Yuan'ın yazarlığını yaptığı "JBoss Seam: Simplicity and Power Beyond Java" bu kitap yine Seam'e yeni başlayanlar için güzel bir kaynak. Şu anda satışta olan versiyon Seam 1.x sürümünü kapsıyor fakat yakın zamanda Seam 2.x'i kapsayan yeni sürümü yayınlanacak.
(4/5)

Apress yayınevinden çıkan diğer bir kitap "Practical JBoss Seam Projects". Henüz bu kitabı okumaya zamanım olmadı fakat okuma listemde üst sıralarda. Okuyan arkadaşlar fikirlerini paylaşabilirlerse çok sevinirim.
(?/5)

Seam'in ve Hibernate'in yaratıcısı olan Gavin King'in yazarlığını yaptığı "Java Persistence with Hibernate"'in son ünitesi Seam'e ayrılmış. Seam'in ortaya çıkış sürecini ve temel özelliklerini yaratıcısının kaleminden okumak isteyenler mutlaka göz atmalılar.
(5/5)

Necdet Yücel: Akademik Bilişim 2009

Cum, 17 Eki 2008 00:21:46 +0000

XI. Akademik Bilişim Konferansı bu yıl Şanlıurfa'da Harran Üniversitesinde yapılacak. Yakında Akgül Hocanın aktif katılım çağrısını alırsınız ama ben şimdiden haber vereyim dedim.

Her yıl olduğu gibi bu yıl da Konferans düzenlenmeden önce ev sahibi üniversitede bir toplantı yapılacak; 31 Ekimde Harran'da olacağız. Nereye gideceğiniz konusunda fikriniz olsun diye fotoğraflar eklerim ;)

Ahmet Yıldız: Geri Sayım Başladı

Per, 16 Eki 2008 22:18:21 +0000

Fatih Arslan: Bardağın yarısı boş mu yoksu dolu mu?

Per, 16 Eki 2008 21:00:40 +0000

Bur meşhur sorunun bir çok cevabı var. Msn iletisinde şunları yazmıştı geçen bir arkadaşım:

To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.

Benim çok hoşuma gitmişti. Aklıma takılmış olacak ki web’de oradan oraya zıplarken bir yerde şu harika cümleyi gördüm:

The physicists say the glass is neither. It is completely full, half with water, the other half with air.

Ardından bugün okulda arkadaşımı gördüm ve bunu söylemiştim. Sonra başardık konuşmaya, başkaları ne derdi acaba diye düşünüyorken kendi aramızda, ben de o arada atladım ve “Filizof ne derdi ? ” diye sordum Biraz sessizlik oldu, düşünürken şunu deyiverdim:

Hangi bardak ?

Bu da böyle bir anımdı bugün. Bu bardağın yarısı boş mu dolu mu sorusu bu arada bilimsel olarak kullanılan bir metotmuş. Adı da Litmust Testi. Psikoloji’de bir insanın en basitinden iyimser mi kötümser mi düşündüğünü belirtmek için yarıyormuş. Bu yöntem ile çok farklı düşünen insanları da görmek mümkün oluyor , örneğin yukarıdaki mühendis örneği gibi.

Bu testi farklı amaçlarla da kullanabiliyoruz, örneğin bir bardaki barmen-müşteri ilişikisi. Barmen bardağı her zaman tam dolu, yarı dolu, çeyrek dolu,… şeklinde görüyor etrafı, fakat bardaki müşteriler için tam tersi, onlar tam boş, yarım boş, çeyrek boş,… şeklinde görüyorlar etraftaki bardakları.

Copyleft - Fatih Arslan - Arslanlar Şehri, 2008. | Permalink | Yorum(1)

LKD YK: Eylül Ayı Üye Bülteni Yayınlandı

Per, 16 Eki 2008 20:02:32 +0000

Linux Kullanıcıları Derneği’nin yapmış olduğu çalışmaların konsantre bir şekilde anlatıldığı aylık bülteni bu kez Eylül ayı için dernek üyelerimizden Seyfi Genç hazırladı. Bülten tüm üyelerimizin e-posta adreslerine gönderildi.

Gönderim sırasında Temmuz ayında olduğu gibi ufak çaplı bir kaza da yaşadık, e-postalara Reply-To yerine yanlışlıkla BCC (gizli karbon kopya) satırı eklenmesi nedeniyle yönetim kurulu listesinin moderatörleri Alper ve Doruk’un posta kutularına bir anda 1000′e yakın e-posta doldu… Neyse en azından bu sefer liste arşivleri kurtuldu :) (züğürt tesellisi)

Hakan Uygun: Google Chrome, Özgür Yazılım ve Amerikan Ticaret Kanunları

Per, 16 Eki 2008 18:06:04 +0000

webrazzi‘den okuduğum habere göre Google Chrome uygulamasını Suriye, İran ve Amerikan Ticaret Kanunu’na göre ambargolu bir çok ülkeden indirilmesine kapatmış. Gene aynı haber içerisinde Google’ın Adsense için her hangi bir yaptırım uygulamadığı söyleniyor. Yazıda ticari bir hizmetin kapatılmayıp, ücretsiz bir yazılımın kapatılması üzerinde duruluyor…

Bense başka bir noktaya takıldım. Özgür yazılım lisanslarının Ticaret Kanunları çerçevesinde nasıl değerlendirileceği.

Sonuç ürün üzerinde Amerikan Ticaret kanunları çerçevesinde bir ambargo söz konusu olabilir, sonuçta Google bir pazar olarak Amerika ve kanunlarla uğraşmak yerine zaten bir pazar olarak görmediği ülkeler için ambargoyu uygular. Kaynak kodlara ulaşılması, derlenmesi ve ilgili kanunların geçerli olmadığı başka ülkeler üzerinden tekrar yayınlanması ise engellenemez. Tam bu noktada düşündüğüm ise çeşitli kanunlarla özgür yazılım ürünü kaynak kodlarımızında yasaklanması söz konusu olabilir mi? Son durumunu bilmiyorum ama bir dönem Amerikan kanunları nedeniyle şifreleme algoritmaları açısından bir dolu sorun yaşanıyordu…

Bir de aklıma takılan acaba Amerika tarafından ambargolu ülkeler acaba bir fork yaparlar mı?

Aslında, dünyanın bu kadar küçüldüğü, sınırların bu kadar belirsizleştiği bir ortamda bir şeylerin kanunlarla sınırlandırılmaya çalışılması konusunda sorulacak o kadar fazla soru ve tartışılacak konu var ki…

Necdet Yücel: Fazıl Hüsnü Dağlarca

Çar, 15 Eki 2008 23:08:13 +0000

Türk şiirinin büyük ismi Fazıl Hüsnü Dağlarca 94 yaşında zatürre tedavisi gördüğü hastanede yaşamını yitirdi.

FTP ekibi: OpenOffice 3.0 Çıktı

Çar, 15 Eki 2008 13:16:24 +0000

OpenOffice 3.0 çıktı, yansımızda da yerini aldı.

İndirmek için:

Ayrıca OpenOffice Türkiye web sayfasında ek bilgiler bulabilirsiniz.

- yansı ekibi