суббота, 19 февраля 2011 г.

XPRA - "screen" для X-клиентов

xpra, или X Persistent Remote Applications - это приложение, которое позволит подключаться к запускаемым с его использованием X-клиентам (графическим программам) удаленно или локально, не опасаясь обрыва связи или смерти X-сервера. Эдакий “screen” для графических приложений, который и правда чем-то напоминает обычный screen для терминала.

Итак, как это работает?
  1. Устанавливаем xpra. (свежие ебилды, репозитории со свежачком)
  2. Запускаем xpra на каком-либо свободном дисплее:
    xpra start :1
    xpra list - показывает активные дисплеи xpra
  3. Запускаем наше приложение:
    DISPLAY=:1 someguiapp
  4. Идем на удаленную машину... запускаем ssh с X-forwarding:
    ssh -X username@hostname
  5. Делаем xpra attach:
    xpra attach
  6. Видим свое приложение и работаем с ним.
После этого можно повторять шаги 4-6 с любой машины (включая ту, на которой мы запустили xpra, правда для этого не нужно никуда подключаться по ssh).


Есть правда у него существенный недостаток - у меня в нем совсем не работает ввод кириллицы, да и некоторые приложения совсем плохо работают по сети через X-протокол (ну то есть, может они и хорошо работают, но для этого нужна гигабитная сеть %)). Ну и второе - такое как в tmux, а именно одновременное отображение и работа приложения на двух и более серверах, тут невозможно.

пятница, 18 февраля 2011 г.

Узнать время в другом часовом поясе

Кросспост с ЛинСовет

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

$ date
Fri Feb 18 10:22:53 EET 2011
 
$ TZ="America/Chicago" date 
Fri Feb 18 02:22:53 CST 2011
Узнать название зоны поточнее всегда можно в каталоге /usr/share/zoneinfo.

четверг, 10 февраля 2011 г.

Немного "бенчмарков"

Как-то недавно я задался желанием купить свежий быстрый процессор от Intel и в преддверии этого искал и читал кучу бенчмарков. Появилось и желание проделать свой собственный, но так как мы, линуксоиды, не владеем кучей стандартных бенчмарков я вспомнил, как быстро компилилось 2.6.9 на одном из серверов, когда хотелось проверить стабильность системы. Так что я решил взять одну и ту же версию ядра и собрать ее с make allmodconfig на самых разных системах.
И вот что получилось:

https://spreadsheets.google.com/ccc?key=0AprkJoujHYK8dERmZF9aLTI4SFhTWjBWd2J5LWlTVEE&hl=en#gid=0

Выводов пока немного. :)
1. Благодаря наличию в i7 2600 технологии HyperThreading мне удалось протестировать процессор и с ней и без нее. Разница в убывании времени компиляции довольно значительна - около 20%, что, безусловно, совсем не мало, так что, пожалуй, если вы часто собираете ядро, вам Hyperthreading пригодится.
2. Чем "боянистее" процессор, тем он медленнее. Это хорошо заметно по убыванию времени компиляции по сравнению с временем выхода процессоров в свет. Вплоть до 20 раз между 2003 и 2011 годом :). Также можно найти тест одного из товарищей на мобильном i7 720QM, который даже на меньших частотах обгоняет старенький XP 2200+ не в ожидаемые 4-8 раз (по числу ядер и потоков), а в целых 10.
3. Частота процессора и шин может влиять на время компиляции значительно. Это стало ясно после разгона XP2200+ с 1800 до 2025 МГц по шине (с 133 до 150 Мгц), а именно на 12%, отчего время компиляции снизилось на целых полчаса (~16%). Частота памяти же тут ничем не влияла, хотя и была попытка переключать DDR266 в DDR400, благо такая возможность была в чипсете nForce2). Но, несмотря на это, разогнанный до 4.2 ГГц Core i7 не дал лучших результатов, возможно, пропускной способности одноканальной памяти не хватило.
4. В разных ядрах/компиляторах результаты разные. Так получилось, что тест на T7250 проводился сначала в Funtoo (64-битный), а потом с Live CD Ubuntu 10.04 (32 бита), просто из интереса, дает ли прирост 64-битная архитектура при компиляции ядер. Так как результат оказался в 5 минут в пользу 32-битной системы было заподозрено неладное - и 64-битный LiveCD Ubuntu 10.04 тоже оказался быстрее на те же 5 минут.
5. Не всегда больше ядер - быстрее сборка. :) Opteron 8220 при вдвое меньшем числе ядер серьезно обставил 4 Xeon E7340 (хотя, ну может быть, дело в RT-ядре на последнем). Влияет "качество" ядер и частоты.

Немного справки:
Ядро было 2.6.36.3.
Компилировалось тестируемой архитектурой под нее же.
Конфигурация ядра получалась командой make allmodconfig
Памяти было достаточно чтобы пренебречь дисковыми тормозами.
Каждый тест проводился после чистой распаковки ядерного тарболла.
Учитывалось только время компиляции.

Если кому-то захотелось тоже прогнать компиляцию и поделиться результатом, скрипт примерно такой:
#!/bin/bash

KERNEL_TAR=kernel.tar.gz
KERNEL_URL=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.36.3.tar.bz2
KERNEL_DIR="linux-2.6.36.3"

CPU_CNT=`grep -c processor /proc/cpuinfo`
# Here you can change number of jobs
JOBS=$CPU_CNT 
#JOBS=$(( $CPU_CNT * 2 )) 
echo "Running test usung $CPU_CNT processors and $JOBS jobs"

if [ ! -e "$KERNEL_TAR" ] ; then
    wget "$KERNEL_URL" -O"$KERNEL_TAR"
fi

if [ -e "$KERNEL_DIR" ] ; then
    rm -rf "$KERNEL_DIR"
fi

tar xf "$KERNEL_TAR" && cd $KERNEL_DIR && 
make allmodconfig &&
time (make -j "$JOBS" > ../build.log 2>&1) 
if [ $? -eq 0 ] ; then  
 cd .. &&
 rm -rf "$KERNEL_DIR" 
 echo Include this data to report too: 
 gcc --version
 uname -a
 grep "model name" /proc/cpuinfo | head -1
 echo $CPU_CNT threads
else  
 cd ..
 echo build failed. You can look into build.log to find cause.
fi


Требуется наличие подключения к интернету, около 4 ГБ свободного места на диске, make, компилятор и другие программы для сборки ядра.

И если решите запускать через sh "xxxx.sh", убедитесь, что ваш /bin/sh - bash, иначе результаты time будут отличаться от тех, которые публикую я.