server kurulumu
merhaba http://www.howtoforge.net/perfect_setup_debian_etch bu adresteki tutorial den serveri kurdum. üzerine ispconfig kurdum. server şu an problemsiz çalışıyor. ispconfig'in stabil çalışması ve güvenirliliği konusu hakkında bilgim yok. Bu şekilde internete açmam güvenli olurmu olmaz mı ? bu siteden tüm bunları tutorial a dayalı yaptım. - Web Server: Apache 2.2 - Database Server: MySQL 5.0 - Mail Server: Postfix - DNS Server: BIND9 bu server ların yönetimi konusunda daha detayıl bilgi edinmek istiyorum. önerebileceğiniz bir kaynak, site var mı ? yardımlarınızı bekliyorum. şimdiden teşekkürler.
Re: Midnight Commander + file sorunu
On Thu, 2008-01-10 at 16:48 +0200, Cafer Şimşek wrote: > [EMAIL PROTECTED]:~/Work$ (LANG=C; time file maillogs.sql.gz) > maillogs.sql.gz: gzip compressed data, was "maillogs.sql", from Unix, > last modified: Thu Nov 22 15:28:55 2007 > > real0m0.027s > user0m0.020s > sys 0m0.004s > [EMAIL PROTECTED]:~/Work$ time file maillogs.sql.gz > maillogs.sql.gz: gzip compressed data, was "maillogs.sql", from Unix, > last modified: Thu Nov 22 15:28:55 2007 > > real0m0.259s > user0m0.240s > sys 0m0.000s Benim sistemimde de benzer şekilde türkçe utf-8 de file daha yavaş çalışıyor: [EMAIL PROTECTED]:~$ time file nautilus-debug-log.txt nautilus-debug-log.txt: ASCII English text real0m2.366s user0m2.364s sys 0m0.016s [EMAIL PROTECTED]:~$ export LANG=C [EMAIL PROTECTED]:~$ export LC_ALL=C [EMAIL PROTECTED]:~$ time file nautilus-debug-log.txt nautilus-debug-log.txt: ASCII English text real0m0.060s user0m0.056s sys 0m0.000s -- Erçin EKER UIN:82166138 jabber:[EMAIL PROTECTED] .''`. : :' : Born to use Debian. `. `' GPG KeyID: 3DD6DF91 `-Fingerprint: BA95 1DDD 8961 665B 8536 B942 8D43 3EF0 3DD6 DF91 signature.asc Description: This is a digitally signed message part
Re: Midnight Commander + file sorunu
Merhaba, * Cafer Şimşek [2008-01-10 16:48:57+0200] > Sanırım doğru düşünüyorsunuz. Türkçe'ye özel bir durum. Bu Ubuntu 7.10 > üzerindeki testler. > > [EMAIL PROTECTED]:~/Work$ (LANG=C; time file maillogs.sql.gz) > maillogs.sql.gz: gzip compressed data, was "maillogs.sql", from Unix, last > modified: Thu Nov 22 15:28:55 2007 > > real0m0.027s > user0m0.020s > sys 0m0.004s > [EMAIL PROTECTED]:~/Work$ time file maillogs.sql.gz > maillogs.sql.gz: gzip compressed data, was "maillogs.sql", from Unix, last > modified: Thu Nov 22 15:28:55 2007 > > real0m0.259s > user0m0.240s > sys 0m0.000s > [EMAIL PROTECTED]:~/Work$ file --version > file-4.21 > magic file from /etc/magic:/usr/share/file/magic > [EMAIL PROTECTED]:~/Work$ Bu denemeler için çok teşekkürler... > Sürüm 4.12 ile de test ettim (VMWare üzerinde çalışan FreeBSD 6.2 ile) > onda böyle bir sorunla karşılaşmadım. FreeBSD üzerine sürüm 4.21'i > yükleyip denedim ve sonuç: Çok daha büyük bir fark. > > Yani bu sorun 4.12 sürümünde yok, onu garantilemiş olduk. Hız farklarının (çok baskın olmayan) bir nedeni de taranan "magic" dosyasının boyutu. Debian'da bu dosyanın diğer dağıtım ve/veya işletim sistemlerine göre daha büyük olduğunu tahmin ediyorum. $ du -h /usr/share/file/magic.mgc 1.1M/usr/share/file/magic.mgc Diğer paketlerin kendisine bağımlı olmasından dolayı file ve (aynı kaynaktan üretilen) libmagic1 önemli paketler. $ apt-cache rdepends | wc -l 71 Bağımlı paketlerin arasında debhelper, libtool, intltool, defoma, exim4-base gibi önemli paketler de var... -- roktas
Re: Midnight Commander + file sorunu
Recai Oktaş <[EMAIL PROTECTED]> writes: > Merhaba, > > Bir kaç zamandır dikkatimi çeken bir sorunla bugün ilgilenme fırsatı > buldum. Benzer sorundan muzdarip olanlara da yararlı olabilir düşüncesiyle > buraya yazayım dedim. > > Midnight Commander, nam-ı diğer "mc" sık kullandığım bir programdır. Bu > sık kullandığım programda en sık yaptığım işlem de F3 (veya Enter) tuşu ile > dosyalara bakmak veya F4 ile düzenlemek. Gel gelelim makinede tam tarihini > hatırlayamadığım bir güncellemeden beri mc'deki bu göz atma ve düzenleme > işlemlerinde, özellikle büyük dosyalarda, olağanüstü bir yavaşlık oluyordu. > Örnek vermem gerekirse, 170K civarı bir dosyaya (1.4GHz'lik Pentium M > işlemcili makinede) F3 ile bakınma işlemi yaklaşık 9 sn sürüyordu. > > strace(1) ile programın ne iş çevirdiğini inceledim ve bu bakınma/düzenleme > işlemlerinde mc'nin dosya tipini tayin etmek için file(1) komutunu fork > ettiğini farkettim. Yani (en azından bu makinede) sorun file(1) komutunda: > > $ du -h iri.tex > 172Kiri.tex > > $ file --version > file-4.21 > magic file from /etc/magic:/usr/share/file/magic > > $ time file iri.tex > iri.tex: LaTeX 2e document text > > real0m9.232s > user0m8.865s > sys 0m0.016s > > Görüldüğü gibi file(1) kararını ~9 s'de veriyor! Süreç zamanı ağırlıklı > olarak "user" tarafında olduğundan bunun çekirdek ile alakalı olmadığını > düşünebiliriz. Sorun Türkçe'ye özel mi? Merhaba, Sanırım doğru düşünüyorsunuz. Türkçe'ye özel bir durum. Bu Ubuntu 7.10 üzerindeki testler. [EMAIL PROTECTED]:~/Work$ (LANG=C; time file maillogs.sql.gz) maillogs.sql.gz: gzip compressed data, was "maillogs.sql", from Unix, last modified: Thu Nov 22 15:28:55 2007 real0m0.027s user0m0.020s sys 0m0.004s [EMAIL PROTECTED]:~/Work$ time file maillogs.sql.gz maillogs.sql.gz: gzip compressed data, was "maillogs.sql", from Unix, last modified: Thu Nov 22 15:28:55 2007 real0m0.259s user0m0.240s sys 0m0.000s [EMAIL PROTECTED]:~/Work$ file --version file-4.21 magic file from /etc/magic:/usr/share/file/magic [EMAIL PROTECTED]:~/Work$ Sürüm 4.12 ile de test ettim (VMWare üzerinde çalışan FreeBSD 6.2 ile) onda böyle bir sorunla karşılaşmadım. FreeBSD üzerine sürüm 4.21'i yükleyip denedim ve sonuç: Çok daha büyük bir fark. Yani bu sorun 4.12 sürümünde yok, onu garantilemiş olduk. [...] Sevgiler -Cafer
Midnight Commander + file(1) sorunu
Merhaba, Bir kaç zamandır dikkatimi çeken bir sorunla bugün ilgilenme fırsatı buldum. Benzer sorundan muzdarip olanlara da yararlı olabilir düşüncesiyle buraya yazayım dedim. Midnight Commander, nam-ı diğer "mc" sık kullandığım bir programdır. Bu sık kullandığım programda en sık yaptığım işlem de F3 (veya Enter) tuşu ile dosyalara bakmak veya F4 ile düzenlemek. Gel gelelim makinede tam tarihini hatırlayamadığım bir güncellemeden beri mc'deki bu göz atma ve düzenleme işlemlerinde, özellikle büyük dosyalarda, olağanüstü bir yavaşlık oluyordu. Örnek vermem gerekirse, 170K civarı bir dosyaya (1.4GHz'lik Pentium M işlemcili makinede) F3 ile bakınma işlemi yaklaşık 9 sn sürüyordu. strace(1) ile programın ne iş çevirdiğini inceledim ve bu bakınma/düzenleme işlemlerinde mc'nin dosya tipini tayin etmek için file(1) komutunu fork ettiğini farkettim. Yani (en azından bu makinede) sorun file(1) komutunda: $ du -h iri.tex 172Kiri.tex $ file --version file-4.21 magic file from /etc/magic:/usr/share/file/magic $ time file iri.tex iri.tex: LaTeX 2e document text real0m9.232s user0m8.865s sys 0m0.016s Görüldüğü gibi file(1) kararını ~9 s'de veriyor! Süreç zamanı ağırlıklı olarak "user" tarafında olduğundan bunun çekirdek ile alakalı olmadığını düşünebiliriz. Sorun Türkçe'ye özel mi? $ (export LC_ALL=en_US.UTF-8; time file iri.tex) iri.tex: LaTeX 2e document text real0m3.190s user0m3.092s sys 0m0.008s Biraz öyle görünüyor. Devam edelim... $ (export LC_ALL=C; time file iri.tex) iri.tex: LaTeX 2e document text real0m0.076s user0m0.060s sys 0m0.000s Sonuç: $ echo "9.232/0.076" | bc 121 121 katlık bir fark! Öyle anlaşılıyor ki file(1)'ın bu yeni sürümlerinde öncelikle UTF8 ile alakalı ve Türkçe işin içine girdiğinde katmerleşen bir sorun var. Burada verdiğim rakamları (mümkünse farklı dağıtımlarda) siz de doğrularsanız memnun olurum, hata raporu geçmeden önce emin olalım. Geçici bir çözüm olarak aşağıdaki adımları uyguladım: $ cp /usr/bin/file /usr/bin/file.exec $ cat >/usr/bin/file #!/bin/sh LC_ALL=C exec /usr/bin/file.exec "$@" (bu noktada Ctrl-D tuşluyoruz) Tabii bu çözümün yan etkileri olacaktır mutlaka. Yine de önceden 9 s'de açılan bir dosyayı saniye altında açmak için buna değer... -- roktas
