Подумати тільки, Лінуксом я займаюся вже більше десяти років. Я до сих пір пам’ятаю віддані мені «на погратися» диски з Red Hat 7.2. Ммм, як же то було цікаво й незрозуміло =). Не дивно, що принцип «just for fun» спрацював. І досі працює. І переріс у професію.

А ще я майже вісім років без дуалбута. Той вечір також добре пам’ятаю. Там була SuSE 9.2, і спокійний голос тоді ще живого Бурачека по телефону говорив мені, що все буде добре.

Усе буде добре.

Оскільки більшість процесорів зараз — багатоядерні, арчеводу в радість використовувати кілька потоків, щоб дії виконувалися швидше.

Наприклад, якщо підправити /etc/makepkg.conf, можна заставити пакети не тільки компілюватися швидше:

MAKEFLAGS="-j4"

а ще й збиратися в тарболи з використанням паралельних алгоритмів стиснення:

COMPRESSGZ=(pigz -c -f -n)
COMPRESSBZ2=(pbzip2 -c -f)
COMPRESSXZ=(pixz /dev/stdin /dev/stdout)

Звісно, відповідні пакунки pbzip2, pigz, pixz треба окремо доставити в систему.

А ще можна скористатися отаким скриптом, щоб однією командою extract відразу розпакувати потрібний архів, причому також паралельно.

Дуже зручно.

Якщо ваш сервачок з Астеріском сидить за лінуксовим NAT’ом, а на самому маршрутизаторі треба переключатися між основним каналом і резервним (з різними зовнішніми IP-адресами), не забудьте давати команду

sudo conntrack -F

щоб клятий Астеріск не повісив SIP-транки з написом «Request sent».

Після перегляду слайдів Пітера Енвіна з лінуксової конференції в Барселоні про генератори псевдовипадкових чисел в Лінуксі поставив собі rngd. І от що можу показати:

На KVM’і нерівномірність ентропії трохи вирівнялася, але суттєвих змін не сталося.

На Xen’і згладжування скачків прослідковується більш виражено, але рівень не змінився також.

А от на реальному сервері ентропія виросла разів у сім. От де профіт. Правда, разом із цим виросло на 2% навантаження на CPU.

Це буде пост-колекція посилань на відгуки про конференцію OSDN — 2012 від її учасників.

І трохи слів від мене.

Конференція мені сподобалася. Я був радий віддати на неї цілий день. Доповіді, звісно, цікаві не всі, відвертий треш був про безпеку, а також про базу даних db4o — я не знаю, як таке і так можна було розповідати. Інше було хоча б адекватне, а перше місце свого власного рейтингу віддаю доповіді Новодворського про те, де зараз наш опенсоурс, і куди йому треба йти. Друге місце — Костюку із класною презентацією про мобільні інтерфейси. Маржан, як завжди, розповідав про оновлення, причому з демонстрацією, що було особливо класно, тому поставимо цю доповідь на третє місце.

Жаль, що було мало старих знайомих, але тих, хто був, я був дуже радий бачити.

Звісно, від мене буде фотозвіт, але, певно, трохи потім. Як розгребу фотки.

Я тут готую нову фотогалерею, то на фотки доводиться натравлювати оцей скрипт перед їх вивантаженням для змінення розмірів і проставлення копірайтів.

Для пришвидшення цього процесу (оскільки в мого ЦП таки ж 2 ядра) був задум якось це діло розпаралелити, і я поки не знайшов нічого кращого для шелл-скриптів, ніж prll.

Наткнувся на новину. Ось цитата.

With Herrmann communicating with Lennart, they came up with some ideas, including the use of Wayland as a system-wide compositor for handling all video input. One of his ideas is having a global deaemon on a DBus like system to register/deregister clients and clients can request changing the currently active VT.

Що цікаво, подібний механізм я реалізував у SunCore, мікроядерного спадкоємця StreamOS, два роки тому. Код консольного сервера можна подивитися тут.

Hetzner прислав мені отаке:

During the night of 30.06.2012 to 01.07.2012 our internal
monitoring systems registered an increase in the level of
IT power usage by approximately one megawatt.

The reason for this huge surge is the additional switched
leap second which can lead to permanent CPU load on Linux
servers.

Обожнюю їх. 1 мегават!

Один із підконтрольних мені серверів — реальна залізяка, на якій налаштовано NTP. Мені як інженеру телекомунікацій, який прослухав курс про синхронізацію, цікаво спостерігати за такими от графіками.

Показники з часом майже наближаються до ідеальних. Це відбувається тому, що сервер за цей період працював без перезавантажень і без якихось ексцесів. Як тільки щось зависне, або доведеться перезавантажувати машину, показники попливуть.