From: Serdar Koylu (serdarkoylu@fisek.com.tr)
Date: Tue 10 Sep 2002 - 13:09:45 EEST
Selamlar..
10 Sep 2002 03:04 EEST tarihinde yazmışsınız:
>
> Selam arkadaşlar,
>
> Konu uzadıkça uzadı bende de birşeyler yazmak isteği uyandırdı gecenin bu
> vakti,
:)))
> -----------------
>
> Bu "Büyük Firmanın Büyük Ürünü" kavramını tv de koç bilgi sistemleri
> grubunun başındaki adam da böyle söylemişti. (Sanırım firma ismi tam olarak
> buydu). Dediği şuydu, "Artık biriki kişinin bir araya gelip büyük işler
> yapabilmesi mümkün değil !".. Kanımca bu tespit, IBM in "insanlar evlerinde
> bilgisayarı ne yapacak" diyen müdürünün talihsiz beyanı kadar talihsizdi
> bence.
Haklisiniz. Microsoft'ta sanirim yeterince buyuk bir firma. Becerebildigi ise ortada. Firma bile olmayan Linux gene ortada. Elbette konuya teknoloji olarak yaklasiyorum. Eger MS'nin pazarlama imkanlarinin 1/10'u Linux'un elinde olsaydi MS fare ureticisi olarak kalabilirdi.
>
> Şimdi bu "ulusal işletim sistemi" kavramının da insanoğlunun toplam üretim
> kabiliyetini zedeleyeceği yönünde bir fikrim var. Neden evrensel işletim
> sistemi yerine ulusal işletim sisteminin peşine düşülmüştür acaba ? Güvenlik
> gerekçesiyle mi ? Prestij için mi ? Nedir yani ? Burada bu sisteme aday
> gösterilen Linux un bugünkü durumundan şüphe mi edilmektedir ? Yada bu
> işletim sistemine adam gibi uygulamalar yazmak varken gidip kernel
> geliştirmek, yada sağdan soldan uygulama toplayıp paketlemek daha mı
> akılcıdır ? Binlerce insanın desteğini arkanıza almak varken, "ulusal
> işletim sistemi" adına marjinalleşmek ne kadar mantıklıdır ?
Benim gozumde bu fark evrensel bir sistemin ulusal olcekte yeniden yapilandirilmasidir. Bilhassa bir isletim sistemi icin oncelikle evrensel olmak gibi bir mecburiyet zaten var. Isin ulusal kismi ise, isletim sisteminin teknik kabiliyetlerinden ziyade milli servete olan katkisina goredir. Milli servet, ekonomi, isgucu, milli guvenlik, know-how gibi bilesenlerden olusur. Bir sistemin ulusal olabilmesi icin ulke sinirlari icinde uretilebilmesi yeterli sart degildir. Oncelikle burada milli servet olarak belirttigim butune kendisinin dogrudan katkisi olmasi gerekir. Diger yandan ulusal isteklere daha uygun olmasi sarti da var.
> Birde şu özgün Linux dağıtımı felsefesi.. Bir paket yöneticinin süper
> olması, eğer o paket yönetici için uygun paketler yoksa hiçbir işe
> yaramayacaktır. Bugün onbinlerce uygulama .rpm ve .dep olarak nette mevcut.
> rpm ve dep paketlerini yöneten paket yöneticileri geliştirildiğinde mevcut
> uygulamalar bugünkülerin nerdeyse binde biri bile kadar değildi. Şimdi işler
> daha da zorlaştı. Peki geliştirilen bu yeni paket yöneticisi için bu kadar
> paketi kim hazırlayacak ve kim güncel tutacaktır ? Bu bağlamda bakıldığında
> amiyane tabirle ... yarıştırmaktan öteye gitmeyecek bir davranıştır. Kendi
> özgün yazılımlarını yazabilecek insanlara, oturun kardeşim şu şu paketleri
> hazırlayın dediğinizde ciddi bir insan gücü israfına neden olacaktır.
Konu sadece basitce paket yoneticisinden ibaret degil. Konu transparent olarak calisan ve bir makineler grubu olarak degil, gercek bir sistem olarak calisan bir network gelistirmek. Bu bir vizyon. Bu sonuca ulasacagiz. Nerede hangi adimi atmamiz gerektigini, nerede ne yapmamiz gerektigini biliyoruz. Uzun soluklu bir is. Bu surecte elbette ara urunlerde cikacak. Fakat nihai urunler piyasada yer aldiginda komple bir networku tek bir sistem gibi kullanabileceksiniz. Yani sizin bilgisayariniz, ali beyin bilgisayari gibi kavramlar ortadan kalkacak. Sisteminizin her bilesenine ayni guvenlik politikalarini, ayni islevleri saglayacaksiniz. Dahasi bu vizyon Windows, BSD, Apple gibi diger isletim sistemlerini de kapsiyor.
Paket yoneticisi burada basitce bir paketi elde et, icerigini extract edip uygun dizinlere koy yaklasimindan daha otede yer aliyor. Paket bir component. Sistemde herhangi bir yerde bulunan X paketi kolayca baska bir hosta transparent olarak transfer edilebilir. Update ve yeni program kurulmasi islevleri tamamen otomatizedir. Dahasi, merkezi bir sunucu tum networkun paket yonetim isini ustlenebilir. Merkezi sunucu, kendi networku icin gereken paketleri kolayca internetten alip gercek servislere yukleyebilir. Dahasi, bir makinedeki bir paketi (component) baska bir makineye transfer edebilir.
Bizim sisteme yaklasimimiz farkli. Bu nedenle yeni bir paket yoneticisi zorunluluk oldu. Elbette ilk asamada tum paketler sadece bizim tarafimizdan uretilecek. Fakat, bir paket sunucudan paket alip yuklemek icin oradan bir paket indirmiyorsunuz. Basitlestirilmis bir XML ile oradan paket bilgisini istiyorsunuz. Ardindan gelen bilgiye bakarak size gereken diger bilesenleri tespit ederek onlari yukluyorsunuz. Devaminda sizin mimariniz icin gereken dosyalari aliyorsunuz. Yani, internetten bir TAR indirip acma olayi yok. Paket yonetici programi da bunu simule eden bir alt seviye sistemle, buna client olan bir frontend'den ibaret. Bu noktada performans kazanci icin, ikisi tek bir ELF icinde ve native C fonksiyonlari ile calisiyorlar. Ama paket sunucu ve client ayni mantikla calisiyor. Her an client ve sunucu tasinan structures icinde bilginin bir XML kopyasini tutuyorlar. Tum erisim tipik XML tree ile yapiliyor. Paketin icerigi ise XML taglari yerine descriptorler kullanan, boylece performans kazanci saglayan bir
yapida.
GPACKAGER ile hic bir zaman koskoca bir dosyayi download etmiyorsunuz. Dahasi aradaki baglantiyi saglayan CLIRP altyapisi sizi redirect edebilir. Yani siz, A serverinden paketin X bilesenini alirken B serverinden Y bileseneni alabilirsiniz. Paket kurulumu bittiginde, ornegin, Web sunucu kurmussaniz, bu sunucuya erismek icin gereken firewall konfigurasyonu dahi (local firewall degil, sistemin ana firewall'i) hazirlanmis oluyor.
Bilmem anlatabiliyormuyum. Bizim yaptigimiz sistemde aslen RPM ve DEB Gibi bir paket yaklasimi yok. Ozellikle sancisiz update ve kurulum icin gelistirilen tamamen farkli bir model var. Diger yandan bu model icinde paketler sadece bir component. Ayni sekilde, kullanicilar, virtual host'lar, mailboxlar, veritabanlari vs. hepsi birer baska component. Paket indirmek demek, serverdeki bir componenti kendinize transfer etmek demek. Yani siz, paket kurar gibi kullanicilari baska bir makineye transfer edebilirsiniz. Ayni altyapiyla, ayni platformla. Sonra da aginizdan size gereken componenti arayip bularak onlari kullanabilirsiniz. Yani, sistemde 15 tane farkli yerde, farkli kullanci veritabanlari olabilir PAM'in kullanacagi. Siz, transparent olarak bunlardan herhangi birindeki kullanici olarak login olabilirsiniz. bunu yaptiginiz andan itibaren, sizin tum kaynaklariniz, hangi makinenin basinda olursaniz olun, sizin emrinize amade olacaktir. Cunku CLIRP bilesenleri transfer etmek kadar, onlari uzaktan kullanabilmeni
z icinde gerekenleri size sunar. CLIRP ne ? Hep soyluyoruz :
Component Location Inspection and Retrieval Protocol. Bize en cok gereken aslinda su .NET LI, Java (RMI) gibi bir sey. Ama Linux zaten yeterince platform bagimsiz. Gidip bir virtual machine olusturacak boyle bir girisime gerek yok. Dahasi go-mono ekibi ve Java ekibi zaten bu isi yeterince iyi yapiyor. Ama .NET'in ahmak sisteminde daha fazlasini ortaya koymus oluyoruz. CLIRP icin WebServices sadece bir componenttir. Oysa, CLIRP icin bir CPU'da bir componenttir. Dahasi siz, servis olmayan seyleride component olarak tarif edebilrisiniz, bunlari saklayabilirsiniz. Yani, diyelim ki otomobil lastigi uretiyorsunuz. Bunu bir component olarak tarif eder koyarsiniz. CLIRP transfer protokolleri bu lastigin sizde mevcut oldugunu bulur, istemciye gonderir. Istemci satin almak istediginde allocation yapar, size ve bankaya. Bankada bulunan para X gun icin bloke edilmis olacaktir. Siz kargoya lastigi verirsiniz, kargo sirketi token'i alir, durum lastik satici tarafindan bankaya bildirilir. Kargo aliciya ulasinca, token bank
aya geri doner ve banka odemeyi yapabilir. Kisaca detaysiz anlatiyorum. Boylece internette kredi karti numaranizi dileyen herkese gonul rahatligi icinde verebilirsiniz. Size teslim onayi olmadan paraniz bloke durumundan cikamaz. Tek gereken husus, satici, alici, banka ve kargonun CLIRP ile calisiyor olmasidir. Diyelim ki bir film satin aldiniz internetten, seyredeceksiniz. Kac saatini seyrettiyseniz o kadarinin parasi otomatikman duser hesabinizdan. QoS yeterli degilse bir kurus odemezsiniz. Bir download satin aldiniz. Download bitmeden para odemezsiniz. Benzeri bir ton sey. Eger component kurallarina uygun olarak urunlerinizi sunabilirseniz, CLIRP gereken tum bilgi islem altyapisini size sunar. Bu CLIRP'in bir diger yuzu. Bu nedenle CLIRP platformu, veri transferinden guvenlige, kullanici dogrulamadan paket eklemeye her sey icin yeni bir yaklasim getiriyor. Bu nedenlede kendi paket yoneticisi sadece bir detay. Kendi auth, veri transfer, secure connection, tunneling vs. protokolleri var. Dahasi yapisi gereg
i bunlar arasinda bir gateway olarak kullanilabiliyor. cunku aslen bu protokollerde bir component. XML-RPC, SOAP'tan farkli olarak XML ile veri tasinmiyor. XML CLIRP islemcisi, her XML tagi icin farkli bir processor kullaniyor. Yani TAG'lar islenecek veriyi tasidigi kadar, yapilacak islemide tasiyor.
Sanirim bu kisa (!?) aciklama aslinda bir paket yoneticisi ile bir kac sistem bilesenini toplamaktan daha fazlasini yapmaya calistigimizi gostermeye yeterlidir. Mozaik serisinde, sistem gercekten koklu bir suru seye sahit olacak. Dogal olarak bu durumda piyasadaki hic bir dagitima ve isletim sistemine uyumlu olmayacak. O kadarki, bir kaynak kodu indirip kurmaya calismaniz bile mumkun olmayacak. Kodu derledikten sonra sistem icin bir component'e cevirmeniz lazim. Aksi halde onu calistirdiginizda sistem guvenlik bilesenlerinin aniden sistemi (host degil, tum sistem) yuksek guvenlik seviyesine cekmesine, yeni programiniza bir trojan muamelesi yapilarak, once host'unuzun her taraftan deny olmasina, ardindan onu oldurmek icin, makineyi kapatmakta gecerli olmak uzere her seyin denenmesine yolacarsiniz. Makine CLIRP CICL emergency modunda kendini acar, yuklediginiz programin uzerine 0x90 doldurup daha sonra siler. Ve sistem yoneticisi run-a-way eventi yollamadan yeniden servis vermeyebilir. TCP/IP guvenlikte sinift
a kalmis bir sistem. Bizim uyguladigimiz, bir sistemin tum sistemin icinde bir bilesen olmasi yaklasimi, bu kadar yuksek guvenlik seviyesini zorunlu kiliyor maalesef.
> İlk önce emeğe saygı ve hoşgörü göstermek gerekiyor bence. Bugün Nilgün
> hanımın gönderdiği adresteki o metni okuyunca, bu topluluğun içindeki
> birçoklarını tarif ettiğini, sadece Türk modeli bazı durumları tarif
> edemediğini görüyorum. En temel Türkiye'li insan davranışı olan, çalışanın
> daha az çalışan tarafından, yada daha fazlaca görüleni çok çalışanın çok
> çalışan tarafından acımasızca eleştirilmesi durumu sözkonusu ve ilgili yazı
> bunu açıklayamıyor ve açıklayamaz da. Atasözümüz olan "Birlikten kuvvet
> doğar", sanki bizim dışımızdaki insanlar için söylenmiş bir söz gibi geliyor
> bana. Bir diğerimizin yanlışını ve eksiğini görmek ve yermek, çoğu zaman iyi
> yönlerini övmekten çekici geliyor. Sık sık yaşanan "sen bunu dedin, ben bunu
> dedim" kavgalarının taraflarına baktığınızda, ya nasıl böyle bir tartışmanın
> içine düşer bu nadide insanlar demekten de kendimi alamıyorum.
Su sirada, sahsen benim, oncelikle eksiklerimi gorecek insanlara ihtiyacim var. Kufur etmekte dahil istediginiz herseyi soyleyin. Gucenmeyecegime soz veriyorum. Yeterki yanlislarimizi eksiklerimizi gosterin.
Saygi ve sevgiler..
-----------------------------------------------------------------------
Liste üyeliğiniz ile ilgili her türlü işlem için
http://liste.linux.org.tr adresindeki web arayüzünü kullanabilirsiniz.
Listeden çıkmak için: 'linux-request@linux.org.tr' adresine,
"Konu" kısmında "unsubscribe" yazan bir e-posta gönderiniz.
-----------------------------------------------------------------------