meseleyi güzel özetlemişsiniz. linkini verdiğiniz vidyo çok önemli. aldığım rastgele notlar:

- rob pike'ın bellek yönetimi konusunda yaptığı vurgular var. şimdilik basit bir "mark 'n sweep" kullanıyorlar fakat (yanlış aklımda kalmadıysa) IBM'in geliştirdiği bir algoritmadan bahsetmiş ona geçeceklerini söylüyor.

- başarım olarak C ile (gcc) kıyaslandığında %10'luk bir fark var diyor. bunu rahatlıkla tolere edebileceklerini de söylüyor. tabii o bahsettiği yeni garbage collector bu farkı daha da aşağıya çekebilir. ayrıca implementasyon daha çok yeni. (derleyiciyi bootstraping nedeniyle C'de yazmışlar, Go'ya geçtiklerinde iş biraz daha değişebilir.)

- ayrıştırıcı kısmında başlangıç olarak lex & yacc kullanılmış, o kısmı da geliştireceklerini söylüyor.

- çok doğru bulduğum bir tasarım seçimi. string'e ek olarak map (yani hash, dict, associative array artık ne derseniz) yapısı builtin olarak dilin içinde. hakikaten olmazsa olmaz bir şey bu.

- çok hoş closure örnekleri var. closure birinci sınıf vatandaş.

sözdizimine gelince. bir ölçüde katılıyorum size. o parantezsiz ifadeler göze tuhaf geliyor hakikaten. fakat tuvalin o kısmında "terse" kodları seven bir "ken thompson" dokunuşu görüyorum (FAQ'da da okudum bir yerde, hatırlamıyorum). "ambiguation" yoksa sözdizimini sade tut durumu var. tuş sayısını azaltmaya çalışmışlar. benzer bir tuhaflık deklarasyonlarda var, tipi sona yazıyorlar. ama bütün bunlar alışılabilir ve anlaşılabilir şeyler.

- genel olarak şunu hissettim: unix'i düzeltseydik plan9 olurdu, 2009'da C'yi düzeltseydik Go olurdu. rob pike'ın bir Limbo'su vardı ama burada işe ken thompson net olarak girmiş. tabii bu lafın müşterisi değilim henüz, biraz daha incelemem lazım. C dili günümüzün mevcut CPU tasarımlarını, çok çekirdekler bir yana, yazılımsal olarak en gerçekçi temsil eden dil ve bu durumun kısa vadede değişmesi de zor. ama Go'daki goroutine'ler, channel'lar da önemli... multicore açısından yani.

70'lerin 2-3 kişilik yaratıcı bell&labs ekipleri efsanedir hakikaten. bu adamlar (rob pike, ken thompson) önemli adamlar. şahsen ben ellerinden ne çıksa severek yerim.

son olarak... walter bright'ın D'sini de ilgiyle takip ediyorum. ama burada daha modern bir yapı söz konusu. biraz daha mainstream olurlar umarım (her iki dil de)...

plan9 yani...

http://vistasmalltalk.wordpress.com/2007/03/02/google-limbo-inferno-and-plan-9/

efsane geri dönüyor galiba...

bu yazıyı çok beğendiğimi söylemiştim di'mi?

Windows beta sürümü:

http://dl.google.com/update2/installers/ChromeSetup.exe

Kurup deneyenler bilgi verirse güzel olur...

açık kaynakçı birine de bu yakışır...

* I disagree. I'm going to put my cards on the table and say I'm not an "Open Source" person, I'm a Free Software person.

GPL3 ve Linus'un itirazları bağlamında mı böyle söylüyorsunuz, tam anlayamadım. GPL1 veya GPL2 dışında seçebilecekleri başka bir resmi FSF kökenli lisans yok. GPL3 henüz draft aşamasında.

Evet işte benim meramım da o , haber olarak bakıldığında ikincisi ne kadar çarpıcı duruyor değil mi? :-)

Seçilen lisans bir detay sadece.

Hiç sanmıyorum. Özgür yazılım camiasındaki tepkiler göz önüne alındığında Sun'ın CDDL teşebbüsünün başarısızlığa uğradığı, bu lisansa (Joerg Schilling gibi kerameti kendinden menkul bazı tipler dışında) itibar edilmediği ortada (bk. FSF'in "CDDL'i tavsiye etmiyoruz" uyarısı, CDDL'in DFSG uyumlu olmaması vb.). Konu hakkındaki bir çok haber ve blogda gözlediğim önemli bir noktayı atlamayalım: öyle anlaşılıyor ki Sun sadece teknik anlamda özgür ("GPL uyumlu" olarak okunabilir) bir Java istemiyor; aynı zamanda Java'nın sosyokültürel olarak da özgür yazılım camiası tarafından kabul görmesini (Tim Bray'in ifadesiyle "C++'ın yerini almasını") istiyor. Bu yaklaşımı çok takdir ediyorum tabii. Darısı OpenSolaris'in başına...

Bazı notlar:

• AVM2 kodunun yaklaşık olarak 130KLoc olduğu belirtilmiş. Benzer katkılarla kıyaslanamayacak ölçüde büyük olan bu rakam, Mozilla grubuna kuruluşundan bu yana yapılmış en büyük kaynak kod katkısı.
• Gerçi haberde dikkatli bir dil kullandım, aksi anlam çıkmaz ama yine de bir Flash geliştiricisinin web günlüğünden alıntıyla bir noktayı açık kılalım. AVM2'nin implement ettiği ActionScript 3, gayr-ı resmî ECMAScript 4 ile tam uyumlu. Resmileşmesine ramak kalmış bu tip standartlarda 1 yıl içerisinde sadece minör değişiklikler olacağı hesaba katılırsa şu an Mozilla CVS'inde bulunan kodun neredeyse JavaScript2 olduğu varsayılabilir.
• Bir başka okunası web günlüğü Mozilla direktörlerinden Frank Hecker'in günlüğü. Bu gelişmenin (gerek AVM2'nin vadettiği x[2-10]'luk AJAX performansı, gerekse dilin yeni özellikleriyle) Web'in geleceği açısından ne denli önemli olduğu çok güzel anlatılmış; "disruptive innovations vs sustaining innovations" ayrımına dikkat.

Benim basitçe bu işten anladığım şu, yanıldığım yerler varsa lütfen düzeltin. Bir araştırmacı Osmanlıca metinlerin mevcut Türkçe klavyelerle de girilebilmesine imkan sağlayan bir transliteration veya daha da özelleştirirsek romanization standartı geliştirmiş (TSE tarafından kabul gören[1]) ve bu standarta uygun bilgiişlem ortamının hazırlanması gerekiyor; meselâ bir XKB klavye eşlemi, klavye giriş yöntemi ("input method"), translitere alfabeyle yapılacak sıralamalarda kullanılacak LC_COLLATE'i de içeren bir yerel (locale) tanımı: ot_TR gibi ... Bunun dışında bahsedilenlerin, misâl Osmanlıca metinlerin OCR ile taranarak bu standart uyarınca latin harflerine translitere edilmesi gibi irikıyım projeleri ayırıyorum, bence onlar çok daha kendi başına işler. Eğer durum buysa konuya "Osmanlıca karakter seti desteği" yerine yukarıda saydığım unsurları da toparlayan biraz daha şümullu bir isim vermek daha uygun olabilirdi. Doğru mu anlıyorum?

[1] Bu belgeye şu an erişemiyorum, abonelik işlemini bir türlü yapamadım.

Şöyle bir değerlendirme yapılmış. Fuzuli yorumlar da olacaktır şüphesiz, ama her yorumu dinlemek lazım...

Birilerinin mağduriyeti üzerine saçma sapan laflar edip dolaşıyorsunuz ortada... Önce kendinize yöneltin o "yakışıyor mu" sorusunu... Fesüphanallah... Yani torba değil ki büzesin...

Hmm... Stallman'ın, tarihsel değeri olan bu yazısında kullandığı başlık (ayrıntıya girilmeden okunup geçilirse) biraz yanıltıcı olabiliyor (ki o dönemin şartlarında RMS'in bilinçli olarak böyle bir başlık seçtiği ortada). Günümüzde (özellikle *BSD türevi işletim sistemlerinde) yaygın şekilde kullanılan revize edilmiş/"3 ibareli" BSD lisansı GPL uyumlu, sorunsuz ve helâl bir özgür yazılım lisansıdır. "BSD lisansı" denildiğinde hemen hemen daima reklam ibaresinin çıkarıldığı bu revize edilmiş hali anlaşılır.

Karistiramama isi garip. Neden karistiramiyorsunuz ki? Sonucta GPL ile lisanslanmis kisima ek bir kisitlama koymazsaniz, ve onun uzerine bina ettiginiz yazilim parcalarini da GPL veya uyumlu bir lisans ile lisanslarsaniz... Neden yazilimin geri kalaniyla bir sorun olsun ki?

Bu tarif ettiğiniz senaryoyla bir sorun olmaz zaten. "GPL veya uyumlu bir lisans" demişsiniz, bu kısım kritik. (Muhtemel bir celsede öne sürülebilecek) lisans uyumluluğunu neye göre belirleyeceğiz? İşte bu tür şeylere bakarak... Özellikle de tespit edilen küçük (fakat hukuksal olarak önemli) pürüzler politik veya maddi çıkarlarımıza hizmet edecekse (politik kısmı meselâ RMS'e, maddi kısmı bir ticari oluşuma karşı gelebilir).

Soyle diyeyim: mesela TeX'in lisansinda bir banner sarti var. Onun uzerine bir yazilim insa ettiniz ve GPL ile uyumsuz bir lisans sectiniz diyelim. Daha sonra guzel bir scientific ofis arayuzu yapip onu GPL ile lisansladiniz diyelim: GPL ile lisansli olmayan kismi GPL'li kisim uzerine degil, GPL'li yazilim ogelerini diger parcaya bagimli olusturdunuz. En azindan bu ozel durumda bir sorun olmamali. Yaniliyor muyum?

GPL uyumlu olmayan cüzle karıştırılan eseri GPL olarak lisanslayamazsınız. Ama eser sahibi sizseniz birkaç şey yapabilirsiniz: GPL dışında bir lisans kullanırsınız, GPL'de uyumsuzluk çıkaran bölümü çıkarıp ismi artık GPL olmayan bir lisans seçersiniz (efektif olarak ilkiyle aynı) veya GPL'deki "istisna" hükmünden yararlanıp GPL uyumsuz kısımlarla bağlamak için "istisna ibaresi" koyarsınız[1]. Verdiğiniz bu örnekte eserin size ait olması önemli bir unsur, sorunlar çıksa bile çözülebilir. Ama şöyle bir senaryoda biraz zor: Başlangıcından itibaren GPL olarak geliştirdiğiniz ve başkalarından da aynı şartlar altında katkı alan bir projeniz var. Yani eserin telif sahibi sadece siz değilsiniz artık. Günün birinde falan kitaplığı kullanmaya kalkıştığınızda o kitaplığın GPL uyumlu olması gerekiyor. Veya (yapılan bir hukuksal taramadan sonra belirlenen) telif sahiplerinden de onay alarak lisansı topyekün değiştirebilir veya GPL'in "istisna" ibaresini işletebilirsiniz.

P.S. Hukukçu değilim, yukarıdaki cümlelerde geçen "yapamazsınız/edemezsiniz"leri "ben böyle anlıyorum" olarak yorumlayın. :-)

[1] Örnek: http://en.wikipedia.org/wiki/GPL_linking_exception

Ayrıca (daha farklı senaryolar için) GPL FAQ'ya da göz atabilirsiniz.

(Tonguç'un açıklamasına ek olarak) Eski BSD lisansında bulunan reklam ibaresi GPL'in 6 maddesinde ifade edilen şarta ihtilaf ediyor:

6. Yazılım'ı (veya onu baz alan herhangi bir ürünü) yeniden dağıttığınız her defada alıcı, ilk ruhsat sahibinden otomatik olarak Yazılım'ı bu şartlar ve kayıtlar dahilinde kopyalamak, değiştirmek ve dağıtmak için ruhsat almaktadır. Alıcının burada verilen hakları kullanmasına ek bir takım kısıtlamalar getiremezsiniz. Üçüncü şahısları bu Lisans mucibince hareket etmeğe mecbur etmek sizin sorumluluk ve yükümlülüğünüz altında değildir.

Reklam ibaresinin korunması şartı yukarıda işaretlenen bölüm uyarınca ek bir kısıtlama olarak yorumlanıyor. Pratik sıkıntıyla sonlanan zincir: reklamlı BSD lisansı GPL uyumlu olmaktan çıkıyor --> GPL uyumsuz bir lisansa sahip bir eser cüzünü, GPL bir cüzle karıştıramıyorsunuz. Misal, böyle bir lisansa sahip bir yazılımda GPL bir kitaplık kullanamıyorsunuz. Ortada basit ama pratik sonuçları olan teknik (hukuksal) bir sorun var yani.

Niçin sunucularında stable'ın çekirdeğini kullanmıyorlar?

Nedenini bilmiyorum, ama sanıyorum (en azından bu saldırı öncesine kadar) makul görünen bir gerekçesi vardır. gluck.debian.org ağır yüklere girebilen, iri kıyım bir makine. İhtimal o ki bu makinenin sıradan olmayan donanımı ve/veya başarım gereksinimleri yeni bir çekirdek gerektirmişti. 1000 civarında DD bu sunucuya giriş yapıyor. Yani ortada önemli bir "local exploit" tehlikesi var. Bu ve Kasım 2003'deki saldırılar hep bu yöntemle gerçekleştirildi. Önceki saldırıdan edinilen deneyimin (yapılan bir takım düzenlemelerle) bu saldırının daha hafif atlatılmasına yardımcı olduğunu düşünüyorum. Saldırının çabuk tespit edilmiş olması, "şeffaflık" düsturunca açık duyuru yapılması ve kısa sürede sorunun giderilerek sunucunun tekrar hizmete sokulması hususları dikkate alındığında Debian adminlerinin başarılı bir sınav verdikleri kanısındayım.

Bir ihtimal o sunucuda stable da kullanılmıyor olması ki o daha ilginç... :)

Kısaca hayır. Görev kritik sunucularda Sarge kullanmaya devam edin.

Tercihlerinize (Gentoo, FreeBSD) ve o seçenekleri size sunanlara saygı duyuyorum. Fakat mümkünse tercihleriniz için daha akılcı dayanaklar geliştirin veya böyle bir şey mümkün değilse ("mutlak" bir nesnel üstünlük belirlenemiyorsa) "tercihim budur, ötesi yok" demekle yetinin. 1000'in üzerinde kullanıcının giriş yaptığı bir sunucuyla (gluck.debian.org) kendi makinenizi karşılaştırarak böyle çıkarımlara gitmeyelim lütfen. Mesela verdiğiniz "basit kullanışlı ama güvensiz apt" örneğiyle bu problemin hiçbir alakası yok.

13 Temmuz 19:54:52 +0200 tarihli duyuru aşağıda.

------------------------------------------------------------------------

The Debian Project                                http://www.debian.org/

Debian Server restored after Compromise          debian-admin@debian.org

July 13th, 2006                 http://www.debian.org/News/2005/20060713

------------------------------------------------------------------------


Debian Server restored after Compromise


------------------------------------------------------------------------

The Debian Project                                http://www.debian.org/

Debian Server restored after Compromise          debian-admin@debian.org

July 13th, 2006                 http://www.debian.org/News/2005/20060713

------------------------------------------------------------------------


Debian Server restored after Compromise


One core Debian server has been reinstalled after a compromise and services have been restored.  On July 12th the host gluck.debian.org has been compromised using a local root vulnerability in the Linux kernel.  The intruder had access to the server using a compromised developer account.


The services affected and temporarily taken down are: cvs, ddtp, lintian, people, popcon, planet, ports, release.



Details

-------


At least one developer account has been compromised a while ago and has been used by an attacker to gain access to the Debian server.  A recently discovered local root vulnerability in the Linux kernel has then been used to gain root access to the machine.


At 02:43 UTC on July 12th suspicious mails were received and alarmed the Debian admins.   The following investigation turned out that a developer account was compromised and that a local kernel vulnerability has been exploited to gain root access.


At 04:30 UTC on July 12th gluck has been taken offline and booted off trusted media.  Other Debian servers have been locked down for further investigation whether they were compromised as well.  They will be upgraded to a corrected kernel before they will be unlocked.


Due to the short window between exploiting the kernel and Debian admins noticing, the attacker hadn't had time/inclination to cause much damage.  The only obviously compromised binary was /bin/ping.


The compromised account did not have access to any of the restricted Debian hosts.  Hence, neither the regular nor the security archive had a chance to be compromised.


An investigation of developer passwords revealed a number of weak passwords whose accounts have been locked in response.


The machine status is here:  


Kernel vulnerability

--------------------


The kernel vulnerability that has been used for this compromise is referenced as CVE-2006-2451.  It only exists in the Linux kernel 2.6.13 up to versions before 2.6.17.4, and 2.6.16 before 2.6.16.24.  The bug allows a local user to gain root privileges via the PR_SET_DUMPABLE argument of the prctl function and a program that causes a core dump file to be created in a directory for which the user does not have permissions.


The current stable release, Debian GNU/Linux 3.1 alias 'sarge', contains Linux 2.6.8 and is thus not affected by this problem.  The compromised server ran Linux 2.6.16.18.


If you run Linux 2.6.13 up to versions before 2.6.17.4, or Linux 2.6.16 up to versions before 2.6.16.24, please update your kernel immediately.



About Debian

------------


Debian GNU/Linux is a free operating system, developed by more than thousand volunteers from all over the world who collaborate via the Internet.  Debian's dedication to Free Software, its non-profit nature, and its open development model make it unique among GNU/Linux distributions.


The Debian project's key strengths are its volunteer base, its dedication to the Debian Social Contract, and its commitment to provide the best operating system possible.




One core Debian server has been reinstalled after a compromise and services have been restored.  On July 12th the host gluck.debian.org has been compromised using a local root vulnerability in the Linux kernel.  The intruder had access to the server using a compromised developer account.


The services affected and temporarily taken down are: cvs, ddtp, lintian, people, popcon, planet, ports, release.



Details

-------


At least one developer account has been compromised a while ago and has been used by an attacker to gain access to the Debian server.  A recently discovered local root vulnerability in the Linux kernel has then been used to gain root access to the machine.


At 02:43 UTC on July 12th suspicious mails were received and alarmed the Debian admins.   The following investigation turned out that a developer account was compromised and that a local kernel vulnerability has been exploited to gain root access.


At 04:30 UTC on July 12th gluck has been taken offline and booted off trusted media.  Other Debian servers have been locked down for further investigation whether they were compromised as well.  They will be upgraded to a corrected kernel before they will be unlocked.


Due to the short window between exploiting the kernel and Debian admins noticing, the attacker hadn't had time/inclination to cause much damage.  The only obviously compromised binary was /bin/ping.


The compromised account did not have access to any of the restricted Debian hosts.  Hence, neither the regular nor the security archive had a chance to be compromised.


An investigation of developer passwords revealed a number of weak passwords whose accounts have been locked in response.


The machine status is here: 



Kernel vulnerability

--------------------


The kernel vulnerability that has been used for this compromise is referenced as CVE-2006-2451.  It only exists in the Linux kernel 2.6.13 up to versions before 2.6.17.4, and 2.6.16 before 2.6.16.24.  The bug allows a local user to gain root privileges via the PR_SET_DUMPABLE argument of the prctl function and a program that causes a core dump file to be created in a directory for which the user does not have permissions.


The current stable release, Debian GNU/Linux 3.1 alias 'sarge', contains Linux 2.6.8 and is thus not affected by this problem.  The compromised server ran Linux 2.6.16.18.  


If you run Linux 2.6.13 up to versions before 2.6.17.4, or Linux 2.6.16 up to versions before 2.6.16.24, please update your kernel immediately.



About Debian

------------


Debian GNU/Linux is a free operating system, developed by more than thousand volunteers from all over the world who collaborate via the Internet.  Debian's dedication to Free Software, its non-profit nature, and its open development model make it unique among GNU/Linux distributions.


The Debian project's key strengths are its volunteer base, its dedication to the Debian Social Contract, and its commitment to provide the best operating system possible.

Hepsini çevirme imkanım yok. Önemli kısım şu görünüyor:

Şu anki kararlı sürüm, Debian GNU/Linux 3.1 'sarge', Linux 2.6.8 çekirdeğini içeriyor ve dolayısıyla bu güvenlik açığından etkilenmiyor. Saldırının gerçekleştiği sunucuda Linux 2.6.16.18 çekirdeği bulunuyor.

Kusura bakmayın ama sapla samanı fena halde karıştırıyorsunuz. Bu bir "trademark" konusu "copyright" değil. Belirli bir kurumu/tüzel kişiliği (ki mutlaka şirket olması gerekmiyor; kar amacı gütmeyen bir dernek veya vakıf da olabilir) temsil etme/simgeleme yönüyle logolar öyle "özgürce" kullanılamaz.

Tam ümidi kesmişken yazı geldi. Eline sağlık! Her zamanki gibi çok eğlenceli bir şenlik değerlendirmesi olmuş.

Hmm, GWT'yi açmışlar (Apache 2.0 lisanslı). Doğrudan Javascript yerine Java kullanmaları ilginç (GWT ile Javascript'e derliyorlar).

Uyarı için teşekkürler! İlgili parantez arası için şöyle bir düzeltme yapalım: "(herşeyden önce lisans, kaynak kodda yaptığınız değişikliklerle birlikte tekrar dağıtıma [redistribution] izin vermiyor)"[1,2].

[1] Özgür Yazılım Nedir? => Özgürlük 3

[2] Açık Kaynak Tanımı => 3. Türetilmiş Eserler

1 Nisan'ı bilemem de asıl bomba 24 Mart'ta patladı: VIM'in babası Bram Moolenaar (gider ayak VIM7'yi de duyurarak) Google'a transfer oldu.

Hamiş: Hmm, Gmail arayüzündeki klavye kısayollarına dikkat! :-)

Harika bir konu! Makale de fevkalade. Ellerinize sağlık!