Я являюсь рядовым линукс-пользователем и поэтому не стоит от этой статьи ожидать очень умных ходов или нестандартных программистских решений. Все по мануалам. Но раз результат достигнут, значит кому-то кроме меня это может оказаться полезным.

О том, как заставит ноутбук работать под линуксами как можно дольше, написано немало, в том числе и на хабре. В какой-то степени я еще раз соберу все советы воедино, от очевидных до обскурных, заодно опишу несколько проблем и решений, которые у меня оказались достаточно «индивидуальными».

Устанавливал я Ubuntu 10.10 на ноутбук Acer Aspire Timeline 5810TG. Эта машина обладает экраном в почти 16 дюймов и относительно производительным железом, зато батарея достаточно емкая, чтобы ставить с ней личные рекорды.

Именно так называлась работа, представленная мной на Балтийском научно-инженерном конкурсе, и принёсшая мне очаровательную бумажку с римской единичкой, а также новенький ноутбук.

Работа заключалась в распознавании CAPTCHA, используемых крупными операторами сотовой связи в формах отправки SMS, и демонстрации недостаточной эффективности применяемого ими подхода. Чтобы не задевать ничью гордость, будем называть этих операторов иносказательно: красный, жёлтый, зелёный и синий.

Долгое время я мучился ужасно медленным удаленным логином на свои Ubuntu сервера (все 2 ). Ужасно медленно в данном случае — 2-3 секунды. Не то чтобы это было совсем фатально, но когда логин через ключ — хочется чтобы все работало мгновенно — в конце концов, у нас не 486SX.

Длительное гугление приводило только к стандартным решениям:

1. UseDNS no в /etc/ssh/sshd_config — ускоряет логин в случае тормозного DNS. В моём случае стоял локальный кеширующий DNS, потому и так все было быстро.
2. Принудительное указание IPv4 в SSH клиенте — особо не помогло, видимо не у всех тормозит

И на askubuntu.com вопрос c bounty уныло провисел долгие недели без ответа…

О назначении модуля можно догодаться из названия. О HandlerSocket говорят много и на разных языках (в основном на японском, английском и последнее время немного на русском).
Модуль NGX_HTTP_HANDLERSOCKET_JSON_MODULE обращается к данным MySQL через протокол HandlerSocket и отдает данные в формате JSON. Область применения AJAX.
Исходники

О конфигурации, особенностях и ограничениях можно почиать ниже.

Бывает при выводе информации требуется ее декорировать для лучшего восприятия, нередко оформление сопровождается в том числе и текстом. При выделении и копировании этой информации, оформление копировать не нужно, т.к. нужна только сама информация, и желательно в исходном виде. То есть при копировании часть выделенного текста не должна попадать в буфер обмена.
В моем случае это исходный код, который сопровождается нумерацией строк, так нагляднее и есть возможность сослаться на строку кода. Однако, если мы хотим скопировать часть кода, то он должен копироваться без номера строки.
Многие highlighter'ы этим грешат, при копировании кода копируют в том числе и номера строк. Выходят из ситуации по разному: либо используют хитрую верстку, при которой возможно несовпадении нумерации со строками (можно заметить на github например), или используют специальную кнопку, которая показывает в отдельном окне код без форматирования. Мне показались эти подходы неудовлетворительными, потому решил найти другое решение.
В данной заметке я опишу решение, к которому в итоге пришел. Решение, конечно, частное, но может кому то оказаться полезным в решении собственных задач.

Введение

Наконец-то мне удалось заполучить отладочный комплект eZ430-Chronos от компании Texas Instuments, который представляет собой полноценные спортивные наручные часы, которые построены на базе процессора CC430F6137, имеющего на борту беспроводной интерфейс передачи данных и множество других полезных плюшек.

Возможности

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

Отладочный комплект содержит:

• Спортивные наручные часы;
• Беспроводную точку доступа с USB-интерфейсом для связи с PC;
• Отладочный интерфейс eZ430 с USB для прошивки и отладки встроенного микроконтроллера;
• Диск с документацией и программным обеспечением;
• Микроотвертку для демонтажа;
• Два запасных винтика;
• Буклет с краткой инструкцией.

Помимо процессора с поддержкой беспроводной передачи данных, на борту часов находятся датчик температуры, датчик давления (высотомер) и 3-осевой акселерометр.

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Четвёртая часть. Предыдущие части: Первая, вторая, третья.

В этой главе: блочные устройства: физические и виртуальные; образы дисков, хранилища.

С точки зрения управления машинами это самая содержательная часть. Даже управление сетью (следующие части) проще, чем диски. Причина проста — дисковые устройства в виртуализации — самые сложные абстракции.

Прежде чем перейти к фактическому описанию, перечислим свойства дисковых устройств:

• Они хранят информацию.
• У них есть свободное место для будущей информации.
• Они не связаны с конкретным компьютером и могут переключаться между компьютерами.
• Они позволяют записывать, читать информацию.
• Они позволяют стирать старую информацию и записывать новую поверх старой.

Каждая строчка из этого списка — отдельное свойство, требующее отдельной реализации (для сравнения у сетевого интерфейса свойств всего два: они могут принимать и отправлять информацию).

Для виртуализации эти свойства разделены в две группы: первая, связанна с хранением информации. Вторая — связанна с доступом к месту хранения информации.

Очевидно, что доступ (процесс доступа) тесно связан с виртуальной машиной. А процесс хранения — нет. Хранить мы можем и без того, кто пишет, а вот писать без того, кто хранит — не можем. Впрочем, вы не можем так же писать информацию и без того, кто пишет, таким образом процесс доступа тесно связан как с виртуальной машиной, так и с хранилищем информации.

Сегодня, в эпоху Web 2.0, когда контента на сайтах становится все больше и больше, перед разработчиками встает задача реализации полнотекстового поиска.

Вариантов немного:

• использовать виджеты от разработчиков поисковых систем (Google, Яндекс, etc): легко внедрить, привычный для пользователя интерфейс, поддержка морфологии, исправление слов по словарю, возможно более быстрая индексация сайта поисковыми системами, но, как правило ограниченные возможности по настройке и неизбежное запаздывание индексации;
• использовать встроенные в СУБД средства (например FULLTEXT-индекс для MySQL): достаточно легко внедрить, актуальный поисковый индекс, полный контроль над настройкой и внешним видом, но, чаще всего очень низкая производительность на больших объемах данных, отсутствие учета морфологии, либо, в худшем случае, полное отсутствие подобных средств в СУБД;
• использовать отдельную библиотеку/систему полнотекствого поиска.

Третий вариант кажется самым лучшим, ведь он сочетает достоинства двух других вариантов. Правда и здесь не обошлось без недостатков — библиотека требует установки, иногда даже запуска демона (например Sphinx), что может быть неприемлемо.

Решений существует масса, у каждого есть свои достоинства и недостатки. Я бы хотел подробнее остановиться на относительно малоизвестной библиотеке Xapian.

Примерно два года назад я арендовал у одного немецкого хостера не очень мощный сервер на базе Centos 5.2. На нём живут несколько вебпроектов, приносящих некоторую прибыль, и поэтому, я стараюсь присматривать за ним по мере возможности.
На Centos есть стандартный анализатор логов Logwatch, который запускается ежедневно по крону, анализирует содержимое /var/log, делает сводный отчет и присылает его по электропочте. В один прекрасный день я обнаружил в этом отчете запись:

--------------------- yum Begin ------------------------ 
 
 Packages Installed:
    lzo2 - 2.02-3.el5.rf.i386
    dnstracer - 1.8-1.2.el5.rf.i386
    openvpn - 2.0.9-1.el5.rf.i386

---------------------- yum End -------------------------

В тот момент меня она очень смутила, так как в предыдущий день на сервер я не логинился и тем более ничего не устанавливал. Первое, что пришло в голову — сервер был скомпроментирован. Себя я считал уверенным пользователем Linux, однако я растерялся. Благо в тот момент в icq был мой бывший коллега, лучший системный администратор, которого я знаю, и просто очень хороший человек.
Он помог быстро проверить систему. В результате у меня сформировалось краткое HowTo о том, как быстро проверить свой сервер на предмет взлома. Уверен, что многим Храброчитателям оно будет полезно. Предполагается, что пользователь знаком с консолью Linux/Unix.

У каждого из нас, полагаю, в любимом браузере постоянно открыты несколько вкладок одновременно. Не раз бывают случаи, что и заголовка вкладки не видно — лишь favicon'ки. Но часто они информации, кроме как отображения логотипа сайта, не дают. И, наверное, зря. Но мы постараемся и здесь использовать это место (целых 16px*16px!) так, как хотим. По крайней мере, будем знать, как это можно сделать.

До сих пор на хабре еще никто не упоминал о такой удобной подсистеме ядра linux, как inotify и использовании ее в автоматизации работы системного администратора. Хотелось бы восполнить этот пробел.

Что такое inotify

Inotify — это подсистема ядра Linux, которая позволяет получать уведомления об изменениях в файловой системе. Т.е. простыми словами — эта штука дает нам информацию о создании или изменении любого файла или директории в используемой файловой системе.
Inotify появилась в ядре аж в версии 2.6.13 и прошла проверку временем. Для ее использования написано несколько утилит, работу с одной из которых мы и рассмотрим.

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

Как же автору игры, Notch'у, удалось добиться подобного сходства его случайных «миров» с земными просторами? В этом топике я как раз и рассмотрю один из способов построить искусственный ландшафт такого рода (и вскользь упомяну пару других способов), а также расскажу о моем небольшом усовершенствовании этого алгоритма, позволяющем значительно увеличивать размеры ландшафта без заметных потерь в производительности.

Внутри вас ждет несколько схем и красивых картинок, довольно много букв и ссылка на пример реализации алгоритма.

Среди топиков на Хабре я нашел лишь руководство по программированию на Python для платформы S60. Являясь счастливым обладателем N900 и фанатом Python я решил это исправить.

Как Вы мониторите ошибки в своем Django проекте?

В Django есть стандартный механизм мониторинга ошибок, который отсылает уведомление о возникновении ошибки с подробной информацией на указанный email. Вещь, бесспорно, полезная. В письме содержатся все сведения об ошибке: название ошибки, где она произошла, откуда был переход на страницу и т.д. Но в этом есть один большой минус — когда проект крупный и ошибок становится достаточно много, то количество писем с уведомлениями об ошибках становится таким, что большая часть из них просто игнорируется.

Таким же вариантом пользовались и мы, пока не открыли для себя Sentry.

ptrace (от process trace) — системный вызов в некоторых unix-подобных системах (в том числе в Linux, FreeBSD, Max OS X), который позволяет трассировать или отлаживать выбранный процесс. Можно сказать, что ptrace дает полный контроль над процессом: можно изменять ход выполнения программы, смотреть и изменять значения в памяти или состояния регистров. Стоит оговориться, что никаких дополнительных прав при этом мы не получаем — возможные действия ограничены правами запущенного процесса. К тому же, при трассировке программы с setuid битом, этот самый бит не работает — привилегии не повышаются.

В статье будет показано, как перехватывать системные вызовы на примере ОС Linux.

Вступление

Предполагается, что читатель этого руководства, уже знаком с gen_server и gen_fsm поведениями, взаимодействиям посредством TCP сокетов с использованием модуля gen_tcp, активным и пассивным режимами сокетов, и принципом «OTP Supervisor».

OTP предоставляет удобный инструментарий для создания надежных приложений. Отчасти, это осуществляется путем абстрагирования общей функциональности в поведения, такие как gen_server и gen_fsm, которые связаны иерархией cупервизоров OTP.

Существует несколько известных шаблонов TCP сервера. Тот, который мы собираемся рассмотреть включает в себя один слушающий процесс и процесс создания нового FSM процесса на каждого подключившегося клиента. Хотя существует поддержка TCP соединений в OTP через gen_tcp модуль, не существует стандартного поведение для создания неблокирующего TCP сервера опираясь на принципы OTP. Под неблокирующим сервером мы подразумеваем, что слушающий процесс и FSM-процесс не должны делать каких-либо блокирующих вызовов и быстро реагировать на входящие сообщения (например, изменения в конфигурации, перезапуск и т.д.), не вызывая таймауты. Обратите внимание, что блокировка в контексте Erlang означает блокировку процесса Erlang, а не процесса операционой системы.

В этом руководстве мы покажем, как создать неблокирующий TCP сервер, используя gen_server и gen_fsm, которые предоставляют контроль над поведением приложения и полностью удовлетворяют принципам OTP.

Читателю, который не знаком с OTP, рекомендуется обратить внимание на руководство Джо Армстронга о том, как построить отказоустойчивые сервера с использованием блокирующих вызовов gen_tcp:connect/3 и gen_tcp:acceept/1 без использования OTP.

Часть 2
Часть 3

В этом цикле статей я поделюсь тем, что я узнал опытным путем о том, как Mochiweb обрабатывает большое количество открытых соединений, и покажу, как создать Comet-приложение, используя Mochiweb, где каждое соединение зарегистрировано в маршрутизаторе. Мы закончим рабочим приложением, которое в состоянии справиться с 1000 000 параллельных соединенией, и узнаем, как много памяти нам для этого потребуется.

В части первой:
• Создание простого Comet — приложение, которое посылает клиентам сообщение каждые 10 секунд.
• Настройка ядра Linux для поддержки большого количества соединений.
• Создание тестирующей утилиты для создания большого количества соединений.
• Определение необходимого количества памяти.

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

Предполагается, что Вы знакомы с bash, и немного с Erlang.

Вступление

C системой Аллена меня познакомили около двух лет назад. Начинал пользоваться вариантом Васи Кислого с помощью HTC Touch Pro, но глючность девайса сильно мешала освоить систему, а сам «Успеватель» не давал необходимого уровня понимания. С GTD пришлось на время расстаться.

С того момента многое изменилось. Количество дел и задач, требовавших внимания, значительно увеличилось. Как и уровень ответственности за неудачные или запоздалые решения. Необходимость в помощнике стала настолько значительной, что приводила к реальному эмоциональному дискомфорту.

Попытки вести мобильную версию системы в Nokia E63 с помощью «Активных заметок» привели к покупке книги Дэвида Аллена, переработке статьи В. Кислого, приобретению стабильно работающего, хоть и старенького HTC P3400 (а потом и более современного продукта от HTC) и введению бумажной, физически ощутимой части этой системы.

Итогом переработки стала строгая вариация за моим авторством на тему Дэвида Аллена в обработке Васи Кислого. Благодаря ей, работа стала занимать не больше 3-х часов в день. Но за это время я успеваю сделать действительно много.

Следуя этим принципам, я прихожу на работу к 11-12 часам, работаю плотно и не отвлекаясь до 15 часов. В 15 часов ухожу в зал потаскать железки, прихожу в офис к 17-30, прорабатываю за полчаса все накопившееся с 15 часов. И еду домой.

Пока я не разобрался и не адаптировал под себя систему Аллена, мой рабочий день не ограничивался 8 часами в офисе. Приходилось работать еще вечером дома.

Кому интересно, прошу под кат.

Начало здесь.

Накопители

Прежде чем описывать инструменты, необходимо показать карту информации.

1. Вне человека — хаотичная.
2. В накопителе — хаотичная, но собранная в одном месте.
3. В человеке, его записях, файлах — отсортированная.

Чтобы легче понять, как информация вне человека может быть хаотичной (ведь она поступает по упорядоченным каналам: почта, телефон и т.д.) представьте: Вы сидите за столом, а вокруг толпой стоят люди, которые что-то требуют от Вас, толкаются между собой за право получить от Вас ответ раньше другого… Крик, шум, суета.

По факту, так и есть в обычной жизни, просто это скрывается за вроде бы упорядоченным поступлением данных. Всем нужно, чтобы именно на их запрос ответ был дан, как можно раньше. Как можно раньше был выполнен именно их заказ. Немедленно, сейчас!

Многие знают, что за такими запросами стоит не действительно срочная потребность, а сумбурность мысли. Человек не всегда может осознать, к какому же сроку ему нужны те или иные данные? Зачастую, они кричат «срочно!» только потому что им хочется , а не потому что они действительно нуждаются.

Чтобы справиться с хаосом, Дэвидом Алленом был придуман простой инструмент — накопитель.