По просьбе Сергея Аношина (aka Eremite) сделал блок выводящий последнии 10 записей для Mosquito BM. Если встречается запись без заголовка, то она пропускается.

скачать блок (Надеюсь все знают как gz распаковать)

Утилита top умеет показывать только те процессы чей PID указан в качестве параметра, но указывать при необходимости PID несколько проблемотично, по той простой причине что надо их узнать. Честно говоря, меня это несколько напрягало, поэтому решил это у себя исправить.

#!/bin/sh
for i in $@; do
        NAMES="$NAMES -C $i"
done
if [ "$NAMES" == '' ]; then
        echo 'Введите имена процессов'
        exit 255
fi
PIDS=`ps -o pid --no-heading $NAMES | xargs echo -n | tr ' ' ','`
if [ "$PIDS" == '' ]; then
        echo "процесс \"$*\" не найден"
        exit 1
fi
top -p $PIDS

Сей простой скрипт позволяет указывать в параметрах к нему имена процессов и вызывает top с соответсвующими PID.

UP: Ещё одна классная полезняшка alias psgrep='ps aux | grep $(echo $1 | sed "s/^\(.\)/[\1]/g")'

Требовательность. Особенно учитываю что у многих хостингов есть лимиты на нагрузку (а ещё и плагины). Но большая проблема заключиется в неоптимизированности самого wordpress. К тому же с версии 2.6 разработчики вообще убрали файловый кэш, что приводит к тому что сервер выполняет много php кода (а там его действительно очень много) "вхолостую". К тому же при увелечении посетителей требуется всё больше и больше памяти, что зачастую может привести к смене не только тарифного плана но и хостера. В общем для блогов с низкой посещаемостью вполне.

Запросов к БД. Надо всегда держать в голове что вордпресс получает данные до того как их выводит, поэтому для своего вывода потребуются дополнительные запросы к БД.

Избыточность. Если сделать что-то хоть сколь-нибудь нетривиальное приходится лезть внутрь WP, но из-за большого объема этого мускульного блого-движка на php довольно трудно в него сходу вникнуть.

Архитектура. Имхо, система при загрузке должна загружать только один файл (по возможности, естественно) ядра, т.е. то без чего система не может функционировать, остальное по необходимости. В Wordpress же все файлы не зависимо ни от чего почти все библиотеки и файлы (Вот отсюда-то в большинстве своем и требовательность WP до ресурсов). Да и организация файлов несколько странновато - зачем, к примеру, выносить весь код группировать в одном файле по тематике функций - если функций немного то это вполне, но в WordPress их уйма (привет ./wp-includes/formatting.php в 1400 строк и прочее)

Система шаблонов. Несмотря на огромное количество уже готовых шаблонов делать свой это мучение (хотя в Drupal муторнее), причем мучение только из-за кучи плагинов - а без плагинов WP не шибко из общего ряда блог-движков выделяется (разве что простотой и удобством админки).

Почти всё выше перечисленное решается апдейтом тарифного плана или своим VDS (или серевером), ну и изучением и некоторым привыканием к внутренностей WP.

Теперь немного плюсов. Для меня плюсов немного, зато они довольно большие - это огромное комьюнити а так же уйма готовых плагинов и шаблонов. Причем система плагинов довольно простая - что может быть проще хуков и фильтров? ну разве что их объединение, дабы не плодить похожие сущность)

Вот решил опубликовать уже давно портированный плагин для Mosquito BM (на форуме сказали что такой плагин не помешал бы). Собственно из названия уже понятно что этот плагин делает. Правда кроме этой функции он ничего не делает, т.е. при добавлении поста он отправляет аналогичный пост (но без тегов) в указанный в настройках ЖЖ-аккаунт, при редактировании пост в LJ не редактируется, cut и lj-cut для ката в блоге так же корректно обрабатываетя и в ЖЖ.

Cкачать плагин

К слову сказать, в ЖЖ этот блог больше не импортируется, вот так вот совпало с опубликованием плагина.

В общем обновил Arch. Всё бы хорошо, но новые иксы теперь по умолчанию включен Input hotplugging и благодаря этому смена раскладки в иксах прописанная в /etc/X11/xorg.conf не заработала.

Не мудурсвуя лукаво, тупо прописал в конфиге

Section "ServerFlags"
	Option "AutoAddDevices" "False"
EndSection

что бы настройки брались из иксов. В общем всё заработало, но ленивая пытливость повела меня в соответствующую статью на ArchWiki и на форум.

В итоге обнаружилось что хотплагом заведует hal, т.е. теперь для иксов приходится ещё и писать правила для hal. В общем тихий ужас.
Вместо пары строк в xorg.conf

Option	    "XkbLayout" "us,ru(winkeys)"
Option	    "XkbOptions" "grp:caps_toggle"

теперь должна быть портянка вида

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
 <device>
    <match key="info.capabilities" contains="input.keymap">
      <append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
    </match>
    <match key="info.capabilities" contains="input.keyboard">
      <merge key="input.xkb.rules" type="string">base</merge>
      <merge key="input.xkb.layout" type="string">us,ru(winkeys)</merge>
      <merge key="input.xkb.options" type="string">grp:caps_toggle</merge>
     <append key="input.xkb.options" type="strlist">grp:switch</append>
     <append key="input.xkb.options" type="strlist">grp_led:caps</append>
    </match>
  </device>
</deviceinfo>

в файле /etc/hal/fdi/policy/10-keymap.fdi или /etc/hal/fdi/policy/10-x11-input.fdi (в ArchWiki об этом)
Честно говоря даже не уверен что сия портянка будет работать, пробывать было не то что лень, а даже было как-то ужасно неприятно проделывать сии манипуляции сомнительного для меня достоинства. Ну не надо мне портить человекочитаймый xorg.conf кучкой не читаемых правил в hal (Слава роботам!!!) ради того что бы я мог не перегружая иксов переторкивать мышу и клаву, поэтому оставил xorg.conf приведенную выше строку. Возможно кому-то такие функции нужны, ну что же в добрый путь изучения правил HAl'a

В гномокедах, по слухам надо выбрать, Evdev-managed keyboard в Keybord model, ибо теперь c hal использовуется драйвер evdev.