Re: Утилиты в стиле true unix way
Hello!
On Thursday 07 January 2010 15:54:26 Oleg Tsymaenko wrote:
> К счастью мне даже после вашего поста кажется что mutt в отличии от
> kmail это UNIX way. И уж точно это _НЕ_ "монстрообразная" программа.
>
> Я не понял того что написано ниже. например почему использование в mutt
> своей системы шифрования вместо openssl это плохо и не по юниксовому.
>
> Я вижу UNIX-way в первую очередь как много мелких узкоспециальных
> программ которые легко комбинировать во чтото сложное. Во вторую очередь
> это способ комбинации: каналы.
>
> теперь о том как я использовал mute: я использовал внешний текстовый
> редактор(vim), внешний просмотрщик(w3m), внешний шифровальщик(openssl),
> внешний проверщик орфографии(aspeel), внешнюю адресную книгу(abook),
> внешний spam-фильтр(spamassassin) и даже внешний доставщик
> почты(fetchmail). Плотно пользовался каналами.
>
> (!) Вот такая сборка кубиков IMHO и есть UNIX way (!)
Вы серьезно _утверждаете_, что mutt состоит из компонентов,
взаимодействующих через пайпы?
$ ldd `which mutt`
linux-gate.so.1 => (0xb7769000)
libncursesw.so.5 => /lib/libncursesw.so.5 (0xb76fe000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb76d5000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb762d000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7605000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7602000)
libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb7565000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb754e000)
libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0xb7548000)
libidn.so.11 => /usr/lib/libidn.so.11 (0xb7516000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb73cf000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb73cb000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb73c4000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb73c1000)
libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb73ab000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7392000)
/lib/ld-linux.so.2 (0xb776a000)
libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7382000)
libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb737e000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7369000)
libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb72f4000)
Для сравнения:
$ ldd /usr/sbin/qmail-smtpd
linux-gate.so.1 => (0xb78c5000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7757000)
/lib/ld-linux.so.2 (0xb78c6000)
И далее:
veter@veter-laptop:/dev$ ls -lh `which mutt`|awk '{print $5}'
723K
$ ls -lh /usr/sbin/qmail-smtpd|awk '{print $5}'
32K
Посчитаем: 723K/32K=22. Факты вещь упрямая, mutt еще какой монстр.
Note: надо же ухитриться программу с десятками зависимостей причислить
к unix way...
> теперь о postgre: postgre я выбрал как UNIX way изза его модульности и
> расширяемости. И ничего плохого в модуле поддержки XML не вижу. Это
> кстати тоже UNIX way - человеко читамемые файлы (!!!)
Покажите того человека, для кого они читаемые. Более того, они и для
машинной обработки неудобны. Unix way - это plain text. И замена
текстовых конфигов на xml приводит только к росту сложности программ
(нужен дополнительный парсер) и увеличению числа ошибок в них.
> и в полнотекстном
> поиске ничего плохого не вижу. я его долго ждал. Да и как это отразилось
> на качестве - я не понимаю.
В ядре СУБД? Так, что для включения этого самого поиска была
модифицирована треть всего кода системы (см. примечания к релизу)?
Вас обманули, не этого вы ждали.
> Да и о фичах... у меня щас две версии PG
> крутятся: 7.4 и 8.1 и ОЧЕНЬ хорошо что разработчики не спешат в каждой
> версии кардинально трогать ядро. 8.4 я под нагрузкой не щупал.
Проблемы многолетней давности в планировщике запросов, который работает
существенно хуже, чем в SQLite, позиционируемой как замена файловому
хранилищу, регулярные секьюрити-баги, невозможность восстановить базы из
дампа, созданного регулярными средствами, только недавно исправленные
проблемы с unicode-символами и т.п. - вот лишь некоторые из многих.
Если у вас в БД используется одна-единственная таблица для хранения лога,
вы этих проблем можете и не видеть, но для такой ситуации постгрес просто
не требуется.
Что касается тестов производительности, так и вовсе ситуация удручающая:
http://geomapx.blogspot.com/search/label/PostgreSQL
Это и синтетические тесты, и на реальных задачах. Есть еще целая охапка
проблем, о которых я здесь не упоминаю, т.к. там и тестировать нечего -
например, постгрес при обращении к view обсчитывает все поля возвращаемых
записей, включая невыбранные в запросе! Как следствие, view в постгресе - не
работают, поскольку их эффективность на реальных задачах стремится к нулю.
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Reply to: