Re: Утилиты в стиле true unix way
В Чтв, 07/01/2010 в 18:37 +0300, Alexey Pechnikov пишет:
> 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 и
UNIX :)
> $ 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...
Напишите чтото типа:
ldd /bin/ls
linux-gate.so.1 => (0xb80e1000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb80c1000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb80a7000)
libacl.so.1 => /lib/libacl.so.1 (0xb809f000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7f58000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7f3f000)
/lib/ld-linux.so.2 (0xb80e2000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7f3b000)
libattr.so.1 => /lib/libattr.so.1 (0xb7f36000)
а потом пишем сюда (в рассылку) отчёт о том что 'ls' это НЕ ЮНИКС ВЭЙ
ибо у него есть зависимости.
> > теперь о postgre: postgre я выбрал как UNIX way изза его модульности и
> > расширяемости. И ничего плохого в модуле поддержки XML не вижу. Это
> > кстати тоже UNIX way - человеко читамемые файлы (!!!)
>
> Покажите того человека, для кого они читаемые. Более того, они и для
> машинной обработки неудобны. Unix way - это plain text. И замена
> текстовых конфигов на xml приводит только к росту сложности программ
> (нужен дополнительный парсер) и увеличению числа ошибок в них.
То есть вот тут вы говорите о том что "XML" это не "plain text" ???
> > и в полнотекстном
> > поиске ничего плохого не вижу. я его долго ждал. Да и как это отразилось
> > на качестве - я не понимаю.
>
> В ядре СУБД? Так, что для включения этого самого поиска была
> модифицирована треть всего кода системы (см. примечания к релизу)?
> Вас обманули, не этого вы ждали.
Честно говоря в коде pg не колупался.
Тем не менее осмелюсь выразить некоторые сомнения насчёт того что для
включения поиска модифицирована треть всего кода системы. Думаю это
преувеличение.
> > Да и о фичах... у меня щас две версии PG
> > крутятся: 7.4 и 8.1 и ОЧЕНЬ хорошо что разработчики не спешат в каждой
> > версии кардинально трогать ядро. 8.4 я под нагрузкой не щупал.
>
> Проблемы многолетней давности в планировщике запросов, который работает
> существенно хуже, чем в SQLite, позиционируемой как замена файловому
> хранилищу, регулярные секьюрити-баги, невозможность восстановить базы из
> дампа, созданного регулярными средствами, только недавно исправленные
> проблемы с unicode-символами и т.п. - вот лишь некоторые из многих.
> Если у вас в БД используется одна-единственная таблица для хранения лога,
> вы этих проблем можете и не видеть, но для такой ситуации постгрес просто
> не требуется.
>
> Что касается тестов производительности, так и вовсе ситуация удручающая:
> http://geomapx.blogspot.com/search/label/PostgreSQL
> Это и синтетические тесты, и на реальных задачах. Есть еще целая охапка
> проблем, о которых я здесь не упоминаю, т.к. там и тестировать нечего -
> например, постгрес при обращении к view обсчитывает все поля возвращаемых
> записей, включая невыбранные в запросе! Как следствие, view в постгресе - не
> работают, поскольку их эффективность на реальных задачах стремится к нулю.
тут вообще без комментариев. я не считаю возможным серьезно сравнивать
версионник pg и sqlite с блокировкой на уровне таблиц. Это всеравно что
сравнивать bash и KDE, хотя и то и то служит для запуска программ. Так
вот (Вы не поверите) в bash команда ls выполняется быстрее запуск
конкваера в KDE.
--
Oleg Tsymaenko <tsyma@lafox.net> TSYM1-UANIC
Reply to: