Личный Firefox Sync

Для синхронизации браузерной информации я использую Firefox Sync. Но совсем недавно замучили проблемы синхронизации. Постоянно появлялась ошибка, что сервер не доступен, хотя на сайте mozilla не было сообщений о каких-то ошибках и неполадках в работе сервиса. Сейчас кстати есть:

The Firefox Sync service is undergoing some load issues, if you are experiencing problems please wait and try again soon. We are working on it presently.

Помучившись так недельку, я решил поднять личный Firefox Sync сервер на своем псевдо сервере. Быстренько нашел ebuild'ы для gentoo. И, вуа-ля, у меня рабочий сервер для синхронизации. Еще я написал init скрипты и выложил свой overlay на github. Если кому-то нужно — пользуйтесь на здоровье.

Плюсы которые обнаружил во время использования личного Firefox Sync сервера:

• Нет проблем с доступом, точнее их я могу решить сам. Более того, так как я единственный пользователь своего сервера, то нет проблем с загруженностью. А вот доступной поддержки для Firefox Sync не нашел. Признаюсь не сильно и искал.
• Фактически нет ограничения на размер хранимых данных. Стандартный 5-ти мегабайтный предел я умудрился превысить.

Оптимизация компиляции для нескольких компьютеров (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 же успешно работает.

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 пересесть. Какие еще хорошие варианты?