Большой расход памяти imagemagick!

Никак не могу разобраться, как это происходит. И из-за чего!

Первоначальная задача была конвертировать около 200 jpeg файлов в pdf. Использовал imagemagick:

convert *.jpg converted.pdf

При этом convert затратил память около 2-х Гб и повесил комп (т.к. у меня оперативка + swap = 2 Гб). При этом общий объем изображений не превышает 50 Мб. Думал сначала, что вся проблема связанна именно с конвертацией в pdf. Но аналогичная ситуация возникает при попытке конвертирования достаточно большого количества любых файлов.

При конвертировании 20 jpg файлов convert занимает 400 Мб! Это вообще нормально?

Оптимизация компиляции для нескольких компьютеров (distcc и ccache)

Решил провести небольшое исследование о влиянии программ distcc и ccache на скорость компиляции. Поводом стала небольшая заметка о ускорении компиляции и собственно наличие 2-х компьютеров, работающих под gentoo в одной сети с почти одинаковыми процессорами (Celeron 2100 и Celeron 1800).

Настройка данных программ достаточно подробно описана в handbook'е и на сайте gentoo. На них останавливаться не буду.

Скорость компиляции проверялась при сборке pidgin версии 2.5.3. Процесс сборки представляет собой разархивацию исходников, конфигурацию, компиляцию, составление бинарного пакета и его установку в систему. Представленные программы направлены только на ускорение компиляции.

• Время сборки без distcc и ccache: 13:12;
• Время сборки с distcc: 10:14;
• Время сборки с distcc и ccache: 7:08;

Как видно плюсы использования рассматриваемых программ есть. Особенно хороша ccache, но она сокращает время компиляции только при повторном процессе. distcc же возможно лучше себя проявит при большем количестве компьютеров в сети, но провести подобные эксперименты на данный момент не могу.

С ccache за довольно большое время использования при сборке различных программ проблем замечено не было. А вот с distcc были некоторые трудности. Например, возникали ситуации, когда 2-ой компьютер не успевал выполнить посланную задачу из-за некоторых перегрузок или нехватки свободной памяти, что замедляло или вешало процесс. Также для некоторых программ действие distcc вообще нулевое из-за принудительной компиляции в один поток (make -j1). Ну и также встретились программы, которые вообще отказались собираться с distcc.

В итоге на данный момент из-за указанных недостатков я distcc не пользуюсь. ccache же успешно работает.

Отказать SCIM!

Намучился тут с утрица с настройкой scim. В результате отказался от этого дела! Основная причина недовольства этой программой — отсутствие нормальное поддержки compose. Во-первых, scim не поддерживает настройки из ~/.XCompose. А, во-вторых, так и не удалось мне добиться хоть какого-нибудь результата работы compose в Qt.

Кстати, если для emacs, как советуют, отключать использование xim, то compose там тоже прекращает работать.

Portage 2.1.6 и KDE 4.1.3

Решил поставить себе одну из последних тестовых версий portage, а именно 2.1.6. Подобная мысль возникла, так как уже появилось достаточно много ebuld'ов, использующих EAPI2. В том числе и kde-4.1.3, который и хочется наконец-то потестить!

Portage

Первое, что сразу каким-то образом бросилось в глаза: portage качает в фоне! Супер! Пока происходит сборка одного пакета, в фоне подкачиваются исходники следующих. При этом обнаружил это я по неожиданной интернет активности компьютера, а не по надписи в начала работы emerge:

>>> Starting parallel fetch

Мелочь, но тоже заметная: сборка, установка и удаление пакета отделены друга от друга. Точнее говоря изменено их текстовое оформление. Но тогда уже странно следующее: если обрыв установки пакета происходит на этапе Installing, то логичнее, на мой взгляд, было бы продолжить с него после emerge --resume. Но этого не происходит, пакет хочет пересобираться заново. Так что проще установить сначала собранный пакет, а потом заново перезапустить emerge.

Также новый portage похоже научился разрешать конфликт, связанные с блокировками одним пакетом других, которые были установлены. В общем приглючило, или действительно он сам удалил, что надо, и установил, что надо.

Также раньше на сколько помню перекрытия пакетов (collisions) приводили к перезаписи новыми файлами и сообщению об этом, если не установлена опция collision-protect. Сейчас же по-умолчанию процесс установки прекращается!

Чувствую, что замечено будет еще куча различных нововведений. И вообще надо документацию полистать.

KDE 4

Ну и пара слов о kde4. Интересно, что он устанавливается теперь по FHS стандарту, а не в /usr/kde/${SLOT}, как раньше. За то куда устанавливать отвечает USE-флаг kdeprefix. Только вот не понимаю: как лучше-то? Собственно из-за этого и произошло несколько проблем с перекрытием пакетов (collisions) во время установки.

Второй раз уже смотрю на 4-е кеды… Но никак они меня не впечатляют. Подтормаживают на моем компьютере. Многие вещи не удобны и не доделаны. Многих привычных по 3-им кедам вещей нет. Настройки немного сократились такое ощущение. Плюсом у меня все это дело криво собралось, и почти все меню во всех kde-приложениях назывались No Text.

Поразил amorok в плане своей нефункциональности! Может быть что-то там и красиво, но не хватает нормальной работы с плеерами, очереди и еще чего-то. Коме того, он упал через 5 минут его использования. Что есть совсем не хорошо! Также нету настройки БД. Не смог импортировать БД со старого amarok'а.

В итоге откатился на kde 3.5.10. Но вот последнее время все чаще в голову приходит мысль перейти на что-нибудь легковесное. в планах попробовать на fluxbox пересесть. Какие еще хорошие варианты?

Tramp и root на сервере

Задача

С помощью emacs tramp-2.1.14 редактировать файлы под root'ом на сервере, на котором запрещен прямой логин root'а через ssh.

Решение

Добавляем в файлы настроек emacs'a:

(add-to-list 'tramp-default-proxies-alist
             '("\\`server\\'" "\\`root\\'" "/ssh:user@%h:"))

Здесь server — это сервер на котором надо изменить файлы, user — пользователь под которым вам разрешен доступ на server.

Теперь возможно получить root-доступ, открыв необходимый файл следующим образом и введя где необходимо пароли:

/su:server:/path/to/file

Или, если у вас на сервере настроен sudo, делаем так:

/sudo:server:/path/to/file

Tramp и Screen

Как-то раз решил, что мне удобно, чтобы при подключении к серверу через ssh включался screen. Для этого в .bashrc пользователя на сервере было добавлено следующее:

if [ -z "$STY" ]; then
   exec screen -dR
fi

Но оказалось, что при таком раскладе не возможно редактировать файлы через emacs tramp, так как он не может работать через screen. Было найдено следующее решение. Изменить выше представленные настройки вот так:

if [ -z "$STY" ] && [ "$TERM" != "dumb" ]; then
   exec screen -dR
fi

Теперь все отлично работает! Заходим через ssh и сразу же открывается screen. И с редактированием файлов через tramp никаких проблем.

Krusader не показывыает русские буквы через fish

Обнаружил такую вот, ранее не замечаемую, ошибку. Оказывается, что krusader отображает файлы с русскими именами через ssh, используя неверную кодировку. И соответственно он их неправильно записывает. Из консоли ssh отлично все показывает и копирует.

P.S. Все оказалось более интереснее... Konqueror тоже показывает подобную фигню! Значит дело в Кедах?

P.P.S. Уря! Решилась проблема! Нашел все таки меню Select Remote Charset!

Как узнать какой процесс использует мои файлы? lsof!

Вот случайно наткнулся в книжке на программку, которая позволяет узнать, какие процессы в данное время используют указанные файлы. Это программка lsof! Странно, что она не входит в system-набор программ, которые устанавливаются по умолчанию. Очень удобно, например, узнать какие процессы мешают нормальному отмонтированию диска или флешки.