for pkg in $(shell grep ^Package debian/control | awk '{print $$2}') ; d o \ if dh_shlibdeps -p $$pkg -- -O | grep -q libssl; then \ echo "$$pkg links to openssl" ;\ exit 1 ;\ fi ;\ done6. debian/control dosyasının ikinci satırında bulunan Build-Depends bölümüne libssl-dev'i ekleyip Build-Conflicts bölümünden çıkartalım. 7. Son olarak aşağıdaki komutla yeni paketlerimizi oluşturalım. $ dpkg-buildpackage -rfakeroot Bu komutu kullanabilmek için sistemde gcc, libltdl3-dev, libssl-dev, libpam0g-dev, libmysqlclient15-dev, libgdbm-dev, libldap2-dev, libsasl2-dev, libiodbc2-dev, libsasl2-dev, libiodbc2-dev, libkrb5-dev, snmp, autotools-dev, dpatch, libperl-dev, libtool paketleri kurulu olmalı. Her şey yolunda gitmişse (bilirsiniz, bazen gitmez) kısa süren bir işlemden sonra sekiz adet .deb paketiniz oluşmuş olmalı. Ben yukarıda bahsettiklerimi sparc işlemcili bir makinada testing üzerinde yaptım. Oluşan paketleri ftp.comu.edu.tr adresine koydum. Umarım birilerinin işine yarar. Kaynak: Building Debian FreeRadius package with EAP/TLS/TTLS/PEAP support
26 Mart 2008 Çarşamba
Debian için EAP/TLS/TTLS/PEAP desteği olan freeradius paketi hazırlanması
Daha önce de yazdığım gibi debian depolarında bulunan freeradius paketlerinin EAP/TLS/TTLS/PEAP desteği bulunmuyor. Nedeninin Openssl lisansı olduğunu da yazmıştım. Buna rağmen dağıtım olarak debian kullanmak isteyen ve kaynak koddan kurmak istemeyenler için yapılacak işlemleri buraya yazayım istedim.
0. Aşağıdaki işlemlerin hepsini root olmayan bir kullanıcı ile yapmanız gerekiyor.
1. Gerekli kaynak dosyaları indirelim. Kullandığınız debian'a göre farklılık gösterse de üç dosyayı indirmeniz gerekiyor.
Stable için freeradius_1.1.3-3.dsc, freeradius_1.1.3.orig.tar.gz ve freeradius_1.1.3-3.diff.gz. Freeradius'un son sürümünün 2.0.3 olduğunu göz önüne alırsanız 1.1.3 oldukça eski sayılır. Bana soran olursa testing daha kabul edilebilir bir versiyon olan 1.1.7'yi sunduğundan onun kullanılması daha mantıklı olabilir. Testing için indirilecek dosyalar şöyle: freeradius_1.1.7-1.dsc, freeradius_1.1.7.orig.tar.gz ve freeradius_1.1.7-1.diff.gz. Böyle bir iş için unstable kullanmak isteyene link vermek gerekmez diye düşünüyorum. Stable ve Testing için de güncel sürümlerin burada verilenler olup olmadığını elbette kontrol edeceğinizi varsayıyorum.
2. İndirdiğimiz dosyaları açalım:
$ dpkg-source -x *.dsc
$ cd freeradius-*
Bu komutu çalıştırabilmek için sistemde dpkg-dev paketinin kurulu olması gerekiyor.
3. Oluşturulan dizine geçerek debian/rules dosyasında --without-rlm_eap-* olan satırları --with-rlm_eap-* olarak değiştirelim.
4. Bir kaç satır altta --without-openssl olan satırı da --with-openssl yapalım. Bu satır stable sürümünde yok.
5. Yine aynı dosyada geçen aşağıdaki satırları silelim:
24 Mart 2008 Pazartesi
elveda last.fm
Yaklaşık bir ay kadar önce last.fm üyeliğimi ayda 3$ vererek yükseltmiştim. Az önce de dinlediğim şarkıların bir yerde depolanması fikri birden pek saçma göründü gözüme ve last.fm üyeliğimi iptal ettirdim. Halbuki sadece oradan irtibatım olan tanıdıklarım da vardı.
Hayatım hep ani vedalarla doludur benim.
Hayatım hep ani vedalarla doludur benim.
21 Mart 2008 Cuma
OpenSSL ve GPL
İki gündür yazdıklarımın temelinde OpenSSL'in kendi lisansının GPL ile uyum sorunu var. OpenSSL'in sayfasında sıkça sorulan sorulan sorulardan biri şöyle:
Can I use OpenSSL with GPL software?
On many systems including the major Linux and BSD distributions, yes (the GPL does not place restrictions on using libraries that are part of the normal operating system distribution).
On other systems, the situation is less clear. Some GPL software copyright holders claim that you infringe on their rights if you use OpenSSL with their software on operating systems that don't normally include OpenSSL.
If you develop open source software that uses OpenSSL, you may find it useful to choose an other license than the GPL, or state explicitly that "This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed." If you are using GPL software developed by others, you may want to ask the copyright holder for permission to use their software with OpenSSL.
Konuyla ilgili Mark McLoughlin'in kısa bir yazısı buradan okunabilir.
Can I use OpenSSL with GPL software?
On many systems including the major Linux and BSD distributions, yes (the GPL does not place restrictions on using libraries that are part of the normal operating system distribution).
On other systems, the situation is less clear. Some GPL software copyright holders claim that you infringe on their rights if you use OpenSSL with their software on operating systems that don't normally include OpenSSL.
If you develop open source software that uses OpenSSL, you may find it useful to choose an other license than the GPL, or state explicitly that "This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed." If you are using GPL software developed by others, you may want to ask the copyright holder for permission to use their software with OpenSSL.
Konuyla ilgili Mark McLoughlin'in kısa bir yazısı buradan okunabilir.
20 Mart 2008 Perşembe
Neden paket yapmalı?
Dün yazdığım uzun yazıya gelen yorumlardan sonra anladım ki uzun da olsa yeterince açık olmamış yazı. Yazının sonunda "Aslında bu paketleme işini Cem de yapar ama o zaman kaynak koddan kurmaktan ne farkı olur ki?" dediğimde aslında tam da söylemek istediğimi söylememişim. İşin doğrusu elbette bir fark olur ama benim o yazıda avantaj diye bahsettiğim gibi programın güncellenmesi işini outsource etmemiş oluruz demek istemiştim. Bunu saymazsak elbette programı kaynak koddan kurmak yerine paketini hazırlayıp onu kullanmanın başka avantajları var. Koray,sağolsun aşağıdaki avantajları postayla göndermiş bana:
* Paketi depoya dahil edersiniz, sizin dışınızda insanlar da gerektiğinde müdahale edebilir ve kullanabilir..
* Program paketli olarak kurulduğu için bir sorun olduğunda de-install etme işlemi başta olmak üzere her şey sisteme entegre gelişir ve başınız daha az ağrır...
* Paketin iki satırında yapılan bir değişiklik, api/abi tutarlılığı korunan bir güncelleme için yeterli olur, hiç uğraşmazsınız...
Bunlara ilave olarak paket hazırlamanın, hazırlayana da faydalı olacağını unutmamak lazım. Yeni bir şey öğrenmenin (hele de pardus'la ilgili) artıları elbette büyük.
Bu iki yazının ardından:
* rlm_eap_tls.so dosyası için debian'a değil onu uygun lisansla lisanslamayanlara kızıyorum.
* freeradius ve ev ahalisini Cem paketleyecek, İşbaran güncelleyecek.
* Henüz Cem'in durumdan haberi yok ;) (artık olmuştur herhalde).
* Üniversitede böyle akıllı çocuklarla çalışmak pek güzel.
19 Mart 2008 Çarşamba
debian, paket, ssl, radius ve izmir kordon üzerine
İlk linux kullanmaya başladığım yıllarda (nedense) dağıtımların hazırladıkları paketleri kullanmak yerine her şeyi kaynak koddan derlerdim. Çoğunlukla dağıtımların paketlediklerinden farklı ihtiyaçlarım da olmazdı oysa. Hatta kernel.org'u sürekli takip eder ve yeni duyurulan her çekirdeği sunucularımızda derler ve kullanırdım. Apache, php, mysql gibi programların kaynaktan kurulması vakayı adiyeden bir şeydi bizim için. Serdar, Murat ve Faruk iyi hatırlayacaklardır o günleri. Bu elbette vakit alıcı bir süreçti ama zaten ilk öğrenme dönemlerinde olduğumuzdan en ağır yükte olduğu zaman bile işlemcisinin %5'ini kullanan sunucular için ev yapımı çekirdeğin performansa ne katkısı olur diye düşünmüyordum hiç.
Aradan yıllar geçti (gerçekten bir kaç yıl sürdü bu dönem), dağıtımlar daha iyi dağıtımlar oldular (aslında dediğim gibi; zaten iyiydiler, mevzu o değildi;) ), kurduğum sunucuların ve onların üzerinde koşan yazılımların sayısı arttı ve belki en önemlisi ben yoruldum ya da aklım başıma geldi. Madem dağıtımı kuracak kadar güveniyorum dedim (evet, bir dönem LFS ile bile uğraştım) kendime, neden onların hazırladıkları paketlere güvenip kullanmayayım? Önceden, dağıtımların paketlerinin generic olduğu yönünde bir çekincem olurdu ama varsın genel olsundu paketler, sanki ben derlediğimde Demir Bükey gibi mi derliyordum onları? Hem gerçekten öyle derlenmeye ihtiyacı olan kaç program vardı ki? Redhat bir sürü okumuş çocuk çalıştırırken onlara güvenmemek mantıklı değildi (artık). Hem Deniz Hanım bile dağıtımların paketlerini kullanmayı öneriyordu.
Bu radikal sayılacak kararlardan sonra kademeli olarak dağıtımların paketlerini kullanmaya başladık. Tabi heyecanlı gençler arada gentoo kullanıp, bir gün süren program derleme seanları yapıyorlardı. Bu tercihten gördüğüm en büyük fayda kazandığım zamanım oldu. Hali hazırda bir çok ekip benim ihtiyacım olan programların güncel sürümlerini, açıklarını, yamalarını takip ediyor ve hazırladıkları paketleri depolarına koyuyordu. Bütün bunları bir komutla sisteme kurmak harika bir şeydi (hala öyle). Uzun sayılabilecek süreler boyunca redhat kullandım, hala kullandığım sunucularım var. Bedava indirilebilirken bile redhat 6.2 satın almıştık hatırlıyorum, hala da arada bir alıyoruz. Daha sonra ağırlıklı olarak debian kullandım.
Debian'a geçince paket yönetiminin ne olduğunu anladım çünkü redhat kullanırken, eskiden, bir rpm dosyasını kurmak istediğinizde bilmem_ne.so.3 dosyasının sisteminizde bulanamadığı hatasını alırdınız, o dosyayı içeren rpm paketinin ne olduğunu bulduktan sonra bir de bakardınız o da kurulmak için başka dosyalara ihtiyaç duyuyor. Bu silsile böyle devam ederken günün sonunda aslında ne kurmaya çalıştığınızı bile unutacak durumda eve dönebilirdiniz. Ama debian'da sihirli sözcük apt-get vardı (hala var). apt-get install ıvır-zıvır dediğinizde istediğiniz programı ve onun ihtiyaç duyduğu saz arkadaşlarını alır getirir ve kurardı (uzun süredir başka dağıtımların da benzer işler yaptığını biliyorum elbette). İşin doğrusu program kurmak genelde basit bir iştir, zor olsa bile internette mutlaka açıklayıcı belgeleri bulunur. Bu yüzden, bence, paket denilen şeyin (Akgül hocanın deyimiyle) elini kirletmekten korkmayan birine getirisi program kurmayı kolaylaştırmak olamaz. Program kurmanın zor olmaması bir yana, zaten sunuculara da gün aşırı program kurmazsınız. Tamam bu kurulum işlinde zaman kazandırır ama esas zamanı güncelleme de kazanırsınız. Sunucuya programlar seyrek kurulur ama sık güncellenir (en azından göreceli olarak).
Programları kaynak koddan kurmak ve güncellemek yerine dağıtımların paketlerini kullanınca üzerinizdeki büyük bir işi outsource etmiş olursunuz. Paket kullanmanın önemli avantajlarından biri de kurduğunuz programların, ihtiyaç duydukları diğer programların, kütüphanelerin, yapılandırma dosyalarının ve diğer ıvır zıvırın nerede olduğunu bilmesidir.
Her ne kadar bazıları (kendilerince haklı sayılabilecek sebeplerle) beğenmese de debian ve onun paket yönetim sistemi iyi çalışır, kararlıdır, güven verir. Tamam; kararlı olanı biraz eskidir.
Henüz bir sunucuda değil ama günlük işlerimi yapmak için dizüstü ve masaüstü bilgisayarlarımda kullandığım Pardus'un PiSi'sinin bir özelliğini kullandığımı söyleyemem. Kurulumda paket seçimi olmadığından, sonra da grafik arayüzü kullanıp güncelleme yapıp yeni paket kurduğumdan aa şunu daha iyi yapıyormuş ya da şunu şöyle yapsaydı keşke diyemiyorum. Şimdilik bir yamuğunu görmediğimi yazabilirim sadece.
Uzun süredir yeni bir şeyin sunucusunu kurmadan, olanları hayatta tutup vaktimi doktora tezime ayırdığımdan (asla yeteri kadarı olmuyor) sunucu tarafında işler ne durumda bilmiyordum. Her ne kadar pardus'un sunucu sürümü çıkmamış olsa bile kurmamız gereken radius sunucusu için pardus'u kullanabiliriz belki diye düşünmüştüm. Yukarıda yeterince açıkladığımı düşündüğüm sebeplerden deposunda freeradius paketi olmadığından ben yine eski dostum debian'a döndüm. apt-get install ne_gerekiyorsa dememize rağmen yapılandırma sırasında aldığımız hatalar deli etti bizi; ne openssl.cnf dosyası, ne CA.pl ne de CA.all sanki debian paketinden çıkmış gibi değildi. Dosyaların içine baktığımda openssl'in yolunun /usr/local altında arandığını şaşırarak gördüm. Eğer programları kaynak koddan kurarsanız bunlar gibi dosyaların generic olması sizi şaşırtmaz ama debian'ın openssl paketinden çıkan dosyada path doğru olmalı diye bekliyor insan. Şaşırmış olsak da gerekli değişiklikleri yapıp, kurulum için kullandığımız NASIL belgesindeki talimatları takip edip kurulumu tamamladık.
Son iş olarak freeradius'un doğru çalışıp çalışmadığının test edilmesi aşamasını az önce yaptım ve gerçekten şaşırdım. Önce aldığım hatayı yazayım:
Kurulumda bir hata almamama rağmen burada hata çıkması canımı sıksa da google'da ilk aramada doğru ve kısa cevabı bulacağımdan emindim. Bulduğum yanıtlardan biri bu örneğin. Tıklamaya üşenenler için yazayım: rlm_eap_tls.so dosyasının lisansıyla ilgili problem olduğundan debian'la birlikte gelmiyormuş. Hadi canım bu kadar da olmaz, aradan geçen zamanda işler değişmiştir diyerek, debian'ın paket deposunda yaptığım aramanın sonucu: Sorry, your search gave no results.
Firefox'un logosu özgür değil diyerek iceweasel'e bile sıcak bakmış biriyimdir aslında ama buna da yuh diyorum artık. Kolayca tahmin edileceği gibi bu .so dosyası olmadan istediğim işi yapamayacağım. Debian'da bu dosyayı kendi paketine dahil etmemiş. İnternette herkes kaynak koddan kurmayı önermiş ama o zaman bir dağıtımı kullanmanın anlamı benim için çok azalıyor (sistemin diğer bileşenleri hala dağıtımın paketlerinden oluşuyor).
Sabah bir dağıtım seçip bütün yaptıklarımızı kaynak koddan kurup tekrarlayacağız maalesef. Figen, Şule ve Mehtap memnun olacaktır bu işe ama ben çok sinir oldum.
Belki de Pardus'daki arkadaşlara yazıp freeradius ve saz arkadaşlarını paketlemelerini istemek mantıklı olabilir. Aslında bu paketleme işini Cem de yapar ama o zaman kaynak koddan kurmaktan ne farkı olur ki?
İnsan bazen bu işleri bırakıp İzmir kordon'da kafa dinlemek istiyor.
Aradan yıllar geçti (gerçekten bir kaç yıl sürdü bu dönem), dağıtımlar daha iyi dağıtımlar oldular (aslında dediğim gibi; zaten iyiydiler, mevzu o değildi;) ), kurduğum sunucuların ve onların üzerinde koşan yazılımların sayısı arttı ve belki en önemlisi ben yoruldum ya da aklım başıma geldi. Madem dağıtımı kuracak kadar güveniyorum dedim (evet, bir dönem LFS ile bile uğraştım) kendime, neden onların hazırladıkları paketlere güvenip kullanmayayım? Önceden, dağıtımların paketlerinin generic olduğu yönünde bir çekincem olurdu ama varsın genel olsundu paketler, sanki ben derlediğimde Demir Bükey gibi mi derliyordum onları? Hem gerçekten öyle derlenmeye ihtiyacı olan kaç program vardı ki? Redhat bir sürü okumuş çocuk çalıştırırken onlara güvenmemek mantıklı değildi (artık). Hem Deniz Hanım bile dağıtımların paketlerini kullanmayı öneriyordu.
Bu radikal sayılacak kararlardan sonra kademeli olarak dağıtımların paketlerini kullanmaya başladık. Tabi heyecanlı gençler arada gentoo kullanıp, bir gün süren program derleme seanları yapıyorlardı. Bu tercihten gördüğüm en büyük fayda kazandığım zamanım oldu. Hali hazırda bir çok ekip benim ihtiyacım olan programların güncel sürümlerini, açıklarını, yamalarını takip ediyor ve hazırladıkları paketleri depolarına koyuyordu. Bütün bunları bir komutla sisteme kurmak harika bir şeydi (hala öyle). Uzun sayılabilecek süreler boyunca redhat kullandım, hala kullandığım sunucularım var. Bedava indirilebilirken bile redhat 6.2 satın almıştık hatırlıyorum, hala da arada bir alıyoruz. Daha sonra ağırlıklı olarak debian kullandım.
Debian'a geçince paket yönetiminin ne olduğunu anladım çünkü redhat kullanırken, eskiden, bir rpm dosyasını kurmak istediğinizde bilmem_ne.so.3 dosyasının sisteminizde bulanamadığı hatasını alırdınız, o dosyayı içeren rpm paketinin ne olduğunu bulduktan sonra bir de bakardınız o da kurulmak için başka dosyalara ihtiyaç duyuyor. Bu silsile böyle devam ederken günün sonunda aslında ne kurmaya çalıştığınızı bile unutacak durumda eve dönebilirdiniz. Ama debian'da sihirli sözcük apt-get vardı (hala var). apt-get install ıvır-zıvır dediğinizde istediğiniz programı ve onun ihtiyaç duyduğu saz arkadaşlarını alır getirir ve kurardı (uzun süredir başka dağıtımların da benzer işler yaptığını biliyorum elbette). İşin doğrusu program kurmak genelde basit bir iştir, zor olsa bile internette mutlaka açıklayıcı belgeleri bulunur. Bu yüzden, bence, paket denilen şeyin (Akgül hocanın deyimiyle) elini kirletmekten korkmayan birine getirisi program kurmayı kolaylaştırmak olamaz. Program kurmanın zor olmaması bir yana, zaten sunuculara da gün aşırı program kurmazsınız. Tamam bu kurulum işlinde zaman kazandırır ama esas zamanı güncelleme de kazanırsınız. Sunucuya programlar seyrek kurulur ama sık güncellenir (en azından göreceli olarak).
Programları kaynak koddan kurmak ve güncellemek yerine dağıtımların paketlerini kullanınca üzerinizdeki büyük bir işi outsource etmiş olursunuz. Paket kullanmanın önemli avantajlarından biri de kurduğunuz programların, ihtiyaç duydukları diğer programların, kütüphanelerin, yapılandırma dosyalarının ve diğer ıvır zıvırın nerede olduğunu bilmesidir.
Her ne kadar bazıları (kendilerince haklı sayılabilecek sebeplerle) beğenmese de debian ve onun paket yönetim sistemi iyi çalışır, kararlıdır, güven verir. Tamam; kararlı olanı biraz eskidir.
Henüz bir sunucuda değil ama günlük işlerimi yapmak için dizüstü ve masaüstü bilgisayarlarımda kullandığım Pardus'un PiSi'sinin bir özelliğini kullandığımı söyleyemem. Kurulumda paket seçimi olmadığından, sonra da grafik arayüzü kullanıp güncelleme yapıp yeni paket kurduğumdan aa şunu daha iyi yapıyormuş ya da şunu şöyle yapsaydı keşke diyemiyorum. Şimdilik bir yamuğunu görmediğimi yazabilirim sadece.
Uzun süredir yeni bir şeyin sunucusunu kurmadan, olanları hayatta tutup vaktimi doktora tezime ayırdığımdan (asla yeteri kadarı olmuyor) sunucu tarafında işler ne durumda bilmiyordum. Her ne kadar pardus'un sunucu sürümü çıkmamış olsa bile kurmamız gereken radius sunucusu için pardus'u kullanabiliriz belki diye düşünmüştüm. Yukarıda yeterince açıkladığımı düşündüğüm sebeplerden deposunda freeradius paketi olmadığından ben yine eski dostum debian'a döndüm. apt-get install ne_gerekiyorsa dememize rağmen yapılandırma sırasında aldığımız hatalar deli etti bizi; ne openssl.cnf dosyası, ne CA.pl ne de CA.all sanki debian paketinden çıkmış gibi değildi. Dosyaların içine baktığımda openssl'in yolunun /usr/local altında arandığını şaşırarak gördüm. Eğer programları kaynak koddan kurarsanız bunlar gibi dosyaların generic olması sizi şaşırtmaz ama debian'ın openssl paketinden çıkan dosyada path doğru olmalı diye bekliyor insan. Şaşırmış olsak da gerekli değişiklikleri yapıp, kurulum için kullandığımız NASIL belgesindeki talimatları takip edip kurulumu tamamladık.
Son iş olarak freeradius'un doğru çalışıp çalışmadığının test edilmesi aşamasını az önce yaptım ve gerçekten şaşırdım. Önce aldığım hatayı yazayım:
rlm_eap: Failed to link EAP-Type/tls: rlm_eap_tls.so: cannot open shared object file: No such file or directory
Kurulumda bir hata almamama rağmen burada hata çıkması canımı sıksa da google'da ilk aramada doğru ve kısa cevabı bulacağımdan emindim. Bulduğum yanıtlardan biri bu örneğin. Tıklamaya üşenenler için yazayım: rlm_eap_tls.so dosyasının lisansıyla ilgili problem olduğundan debian'la birlikte gelmiyormuş. Hadi canım bu kadar da olmaz, aradan geçen zamanda işler değişmiştir diyerek, debian'ın paket deposunda yaptığım aramanın sonucu: Sorry, your search gave no results.
Firefox'un logosu özgür değil diyerek iceweasel'e bile sıcak bakmış biriyimdir aslında ama buna da yuh diyorum artık. Kolayca tahmin edileceği gibi bu .so dosyası olmadan istediğim işi yapamayacağım. Debian'da bu dosyayı kendi paketine dahil etmemiş. İnternette herkes kaynak koddan kurmayı önermiş ama o zaman bir dağıtımı kullanmanın anlamı benim için çok azalıyor (sistemin diğer bileşenleri hala dağıtımın paketlerinden oluşuyor).
Sabah bir dağıtım seçip bütün yaptıklarımızı kaynak koddan kurup tekrarlayacağız maalesef. Figen, Şule ve Mehtap memnun olacaktır bu işe ama ben çok sinir oldum.
Belki de Pardus'daki arkadaşlara yazıp freeradius ve saz arkadaşlarını paketlemelerini istemek mantıklı olabilir. Aslında bu paketleme işini Cem de yapar ama o zaman kaynak koddan kurmaktan ne farkı olur ki?
İnsan bazen bu işleri bırakıp İzmir kordon'da kafa dinlemek istiyor.
17 Mart 2008 Pazartesi
Pardus 2008 izlenimleri
Pardus sürümlerinin yıllarla ilişkilendirilmesi iyi olmadı bence. Böyle yapılınca herkes üç aydır nerede kaldı Pardus 2008 diye soruyor. Tahminim geliştirici ekibin üzerinde de bir baskı oluyordur bu takvim konusu. Sürümlere numara vermek de sıkıntılı bir süreç aslında; slackware gibi 12. sürüme kadar bu sayıları takip etmek yerine başka nasıl bir sıra izlenebilirdi diye düşündüğümde aklıma değişik bir şey geldi (bunun uygulanabilir olup olmaması pardus'u ilgilendirmez elbette).
Hatırlarsınız eskiden çekirdeğin ikincil sürüm numarasının tek veya çift olması onun kararlı veya geliştirme sürümü olduğunu gösterirdi. Pardus (veya başka bir yazılım) da sürüm numarasını asal sayı olarak kullandığında kararlı sürümü, asal olmayan sayı olduğunda ise ara sürümlerden biri (2007.2 gibi) olduğunu göstermek üzere kullanabilirdi. Sayı doğrusunun başlarında asal sayıların sıkça bulunduğu söylenebilir ama Pardus'un da ilk duyurulduğunda çok ara sürümü yoktu. Hem illa ki birden ikiden başlanacak diye de bir durum yok. 2007'ye nasıl atlanabiliyorsa mesela 23'e de atlanabilirdi. Bu yöntem Lynx lynx gibi telaffuzu mümkün olmayan kod adlarından daha ilginç olurdu bence.
Bu acayip ;) isimlendirme önerimin haricinde de bir önerim var (bunları niye buraya yazıyorsun diyenleri muhabbet için Çanakkale'ye beklerim).
Pardus'un kutulu satın alınabilir bir hali olmalı artık. Tamam ucuz olsun ama kutulu, sahici, legal bir ürün olduğunu gösterir bir hali olmalı Pardus'un. Bir kişiye, kuruma pardus'u önerdiğinizde, kurmaya gittiğinizde elinizde korsan cd gibi kopyalanmış cd bulunması güvensizlik doğuruyor. Slackware'i, openoffice.org'u kutulu satın alabiliyorsak bunun bir nedeni olmalı. Hele openoffice.org internetten daha kolay indirilebilir, işe boyut olarak bakarsak. Ama bu bir güven oluşturma politikası olarak düşünülmeli bence.
Bütün ekibe muhabbetle...
Hatırlarsınız eskiden çekirdeğin ikincil sürüm numarasının tek veya çift olması onun kararlı veya geliştirme sürümü olduğunu gösterirdi. Pardus (veya başka bir yazılım) da sürüm numarasını asal sayı olarak kullandığında kararlı sürümü, asal olmayan sayı olduğunda ise ara sürümlerden biri (2007.2 gibi) olduğunu göstermek üzere kullanabilirdi. Sayı doğrusunun başlarında asal sayıların sıkça bulunduğu söylenebilir ama Pardus'un da ilk duyurulduğunda çok ara sürümü yoktu. Hem illa ki birden ikiden başlanacak diye de bir durum yok. 2007'ye nasıl atlanabiliyorsa mesela 23'e de atlanabilirdi. Bu yöntem Lynx lynx gibi telaffuzu mümkün olmayan kod adlarından daha ilginç olurdu bence.
Bu acayip ;) isimlendirme önerimin haricinde de bir önerim var (bunları niye buraya yazıyorsun diyenleri muhabbet için Çanakkale'ye beklerim).
Pardus'un kutulu satın alınabilir bir hali olmalı artık. Tamam ucuz olsun ama kutulu, sahici, legal bir ürün olduğunu gösterir bir hali olmalı Pardus'un. Bir kişiye, kuruma pardus'u önerdiğinizde, kurmaya gittiğinizde elinizde korsan cd gibi kopyalanmış cd bulunması güvensizlik doğuruyor. Slackware'i, openoffice.org'u kutulu satın alabiliyorsak bunun bir nedeni olmalı. Hele openoffice.org internetten daha kolay indirilebilir, işe boyut olarak bakarsak. Ama bu bir güven oluşturma politikası olarak düşünülmeli bence.
Bütün ekibe muhabbetle...
13 Mart 2008 Perşembe
12 Mart 2008 Çarşamba
Çanakkale Fen Lisesi Linux Semineri
Dün Çanakkale Fen Lisesinde Linux ve Özgür Yazılımlardan bahsettiğim bir seminer verdim. 88'de Fen Lisesinden mezun biri olarak ilk defa bir Fen Lisesinde konuşmak heyecan verici oldu benim için. Aradan geçen 20 yılda yatılı okulların bardakları bile değişmemiş ;) Öğrencilerin, her ne kadar eğitim sistemi onları testlerle boğsa bile, hala anlatılanlara şüpheyle yaklaşan, itiraz eden, yeni bir şey anlatanın yetkinliğini sorgulayan halleri beni yıllar öncesine götürdü. Hayatın karmaşası arasında insanın içine su serpen bir gün oldu benim için.
5 Mart 2008 Çarşamba
Kaydol:
Kayıtlar (Atom)
izlediklerimden öğrendiğim bir şeyler var
İzlediğim ilk büyük konser 1990'ların başında Ankara'da Zülfü Livaneli konseriydi. Henüz Sovyetler Birliğinin olduğu zamanlardan bah...
-
Bu yıl kabul edilen bizim çocuklar: Ahmet Göksu - Native Graphics Backend for FreeType Demos on macOS Ali Haydar - Implementation of a g-k ...
-
Bu yıl kabul edilen bizim çocuklar: Bora Sabuncu - Remote Control Emre Çelikten - Web Data Collection for Language Modeling Gökçen Eras...
-
Bu yıl kabul edilen bizim çocuklar: B. Arman Aksoy - Idea 15: Work on the Pathway Database Converters for the Expansion of Pathw Berker ...