Множество стоек, каждая плотно упакована серверами, маршрутизаторами, коммутаторами и прочими kvm'ами.
Нужен какой-нибудь удобный способ рулить всем этим хозайством, быстро подключаться к нужному оборудованию и
производить его настройку. Прямо чтобы пара кликов мышью и оп — перед тобой консоль нужного коммутатора.

Для мониторинга наших подопечных мы используем Zabbix.
Так почему бы не приспособить сей дивный инструмент и для этой задачи.
Ведь было бы очень удобно ткнуть в карте Zabbix на нужную стойку, перейти на её подкарту и, выбрав железку,
запустить локальный ssh/telnet/vnc клиент на своем компьютере.

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

И так, вектор атаки изменился и поисковики замерли в ожидании нового вброса мыслеобразов…
Спустя некоторое время я уже четко представлял как буду решать задачу — напишу клиент-серверное приложение!
На моем компьютере будет ждать команд серверная часть, а на сервере мониторинга, при клике по ссылке, будет запускаться клиент и передавать нужную команду.

Результатом изысканий стало кроссплатформенное приложение, работает как на Linux, так и на Windows.
Эпопея проб и ошибок на пути к заветной цели ждет вас под хабракатом.

Мне стало интересно какого размера станет база транзакций Bitcoin на реальных объемах. Т.е. представим, что Bitcoin стал официальной валютой России.
Для примера я взяла такую статистику центрального банка России.
В целом, точные цифры неинтересны, нам важны порядки значений.
Допустим, 2013 год — 5 млрд. операций. Одну bitcoin-транзакцию сделаем минимальной — равной 1кБайт.

Итак, 5 000 000 000 * 1000 = рост базы 5ТБайт/год для одной страны.

Интересно, успеет ли закон Мура по персональным накопителям данных за развитием Bitcoin? Готов ли Bitcoin в роли децентрализованного инструмента к таким объемам? Не приведет ли слишком дорогостоящая поддержка майнинга к централизации майнеров и ослаблению системы?

Хотелось бы услышать мнение хабравчан по этому поводу.

В последнее время набирают популярность различные NoSQL базы данных. Эта статья начиналась как изучение особенностей графитовой графовой базы данных Neo4j. Но, в процессе подбора информации, мне захотелось систематизировать информацию о NoSQL решениях и о графовых базах данных, в частности.
В ходе этого небольшого исследования, были выбраны для подробного рассмотрения СУБД, успешно применяющиеся в области Web. И, поскольку в тегах присутствует «PHP», я выбирал СУБД, которые уже можно использовать с этим языком.

iptables — интерфейс к файрволу Linux (netfilter). При большом количестве правил iptables нагрузка может быть достаточно высокой и создавать проблемы. В этой заметке я постараюсь описать, что влияет на производительность iptables и как ее повысить.

Создатели движка Godot опубликовали исходный код под свободной лицензией MIT, так что теперь любой желающий может использовать его для создания собственных 2D- и 3D-игр. Авторы программы утверждают, что Godot предоставляет богатый набор функций и новый подход к разработке игр, что в совокупности «позволяет разработчикам-одиночкам и группам работать более эффективно, чем когда-либо». Они также отмечают простоту и лёгкость освоения программы: язык программирования похож на Python.

Думаю, мало кто из готовящихся к своему первому интервью, при приеме на первую работу в должности (pre)junior программиста, ответит на этот вопрос отрицательно. Или хотя бы усомнится в положительном ответе. Конечно, такая простая структура данных с прямым доступом по индексу — никаких подвохов! Нет, в некоторых языках типа JavaScript или PHP массивы, конечно, реализованы очень интересно и по сути являются много большим чем просто массив. Но речь не об этом, а о «традиционной» реализации массивов в виде «сплошного участка памяти». В этом случае на основании индексов и размера одного элемента просто вычисляется адрес и осуществляется доступ к соответствующему значению. Что тут сложного?

Довольно часто на сайтах е-коммерса нас просят реализовать фильтры. Хороший фильтр — довольно дорогая игрушка. Вообще, они не всегда уместны — пользователю проще посмотреть глазами на список, чем разбираться в логике разработчика фильтра. Конечно, если в этом списке не так много элементов. Скажем, не больше 200 в каждом разделе. Ниже в виде проверочного списка для наших QA, я зафиксировал некоторые требования, которые мы настойчиво внедряем на своих проектах с этого года. Стандартизация, ептэ.

Эти требования разумны. Часть из них трудно реализуема. Часть — очевидна. Часть — зависит от контекста. Но в целом они довольно универсальны. Если будут какие-то вопросы по конкретным пунктам — велкам в комментарии.

Часть первая

Продолжаем

Продолжаем создание кластера, начатое первой части.
На этот раз я расскажу про настройку кластера.

В прошлый раз мы закончили на том, что началась синхронизация DRBD.
Если мы в качестве Primary сервера для обоих ресурсов выбрали один и тот же сервер, то после завершения синхронизации должны в /proc/drbd увидеть примерно такую картину:

# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@debian-service, 2013-04-30 07:43:49
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:190397036 dw:190397036 dr:1400144904 al:0 bm:4942 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:720487828 dw:720485956 dr:34275816 al:0 bm:3749 lo:468 pe:0 ua:0 ap:0 ep:1 wo:d oos:0

Самое интересное поле тут ds:UpToDate/UpToDate, означающее что и локальная и удаленная копия актуальны.

После этого переведем ресурсы в secondary режим — дальше ими будет управлять кластер:

# drbdadm secondary VM_STORAGE_1
# drbdadm secondary VM_STORAGE_2

Pacemaker

Итак, менеджер кластера.

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

Disclaimer. Монолог ниже является стенограммой выступления одного из докладчиков на одной из айтишных конференций. Автор поста всего лишь публикует его здесь с разрешения докладчика.

Всем привет!

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

Меня зовут Сергей. Чтобы сказать про себя «я плохой докладчик», нужно хотя бы им, докладчиком, быть. Я вообще не оно. Свою первую и одну из последних презентаций я провел в 18 лет в Испании, перед аудиторией человек в 100. Мой весьма средний на тот момент английский синхронно переводили на испанский, народ зевал и почесывал репы, ожидая когда ЭТО недоразумение закончит блеять и объявится кофебрейк.

Сказать что мне было стыдно — это ничего не сказать, красный как рак, я свалил вторым выходом, забился в свой номер и боялся показаться на глаза. Всякие public professionals типа Карнеги сказали бы «позор!» и «never again!». Для себя я решил — все что угодно, хоть жигулевское пиво по пятницам, только не публичные экзекуции

К чему это я? Многие, глядя на ИТшников, путают скромность со стеснительностью. Да и фиг с ними. Главное — чтобы мы сами не путали. Я — стеснительный, поэтому буду смотреть в пол и читать по бумажке. Я бы выпил, конечно, для смелости, граммчиков сто (а лучше сто пятьдесят), но организаторы запретили. Ну что, пусть фигово, зато честно!

Я владелец компании П, в которой мы уже лет 13 или 14 занимаемся разработкой всякой фигни, про которую никто не слышал. Не имея таланта делать что-то красивое и эстетичное, мы довольствуемся подводной частью айсберга: софт-свитчи и клиенты для IP-телефонии, аппаратно-программные решения для высоконагруженных систем обработки контента, системы имперсонализации web и e-mail для виртуального присутствия, облачное видеонаблюдение, несколько справочных и торговых интернет-порталов, ну и еще пара проектов в стадии стартапа, говорить о которых рано, потому что стыдно

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

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

Несколько минут назад на главной странице официального сайта OpenSSL вместо контента высветилась надпись:

TurkGuvenligiTurkSec Was Here @turkguvenligi + we love openssl _

Как не трудно заметить, был произведен дефейс. Об этом сообщил в твиттере, судя по всему сам автор взлома, под ником Turkguvenligi.
Подробностей о методах взлома пока не сообщается. На данный момент функционал сайта восстановлен, посмотреть измененную копию можно на зоне: http://zone-h.org/mirror/id/21425720 или в веб архиве.

Обновление: в OpenSSL подтвердили факт дефейса, а также заверили, что проверка файлов не выявила каких-либо изменений.

Всем программистам рано или поздно приходится передавать данные. Ни для кого не секрет, что библиотек сериализации в Java существует примерно >9000, а в C++ они вроде и есть, а вроде их и нет. К счастью для большинства, несколько лет назад появился Google Protobuf, который принёс достаточно удобный способ определять структуры данных и быстро завоевал всенародную любовь. Это была фактически первая, доступная широким массам библиотека, позволяющая гонять по сети готовые структуры данных, не связываясь при этом с чем-то вроде XML. На дворе был 2008 год.

Вернёмся немного назад. В 2006 году простой индийский программист (как бы подозрительно это ни звучало!) Анил Мадхавапедди, один из самых известных сейчас в мире OCaml-разработчиков и автор свежевышедшей книги Real World OCaml, защищал в Кембридже кандидатскую диссертацию. Именно о ней я сегодня вам и расскажу.

Анил сразу пошёл дальше, чем Google. Он сразу подумал, для чего люди обычно пересылают по сети какие-то формализованные структуры данных? Чтобы реализовать какой-то протокол. А что такое протокол? Это какой-то конечный автомат. А где мы можем взять хороший пример сложного, хорошо спроектированного и проверенного временем протокола? Да прямо в обычном сетевом стеке! Итак, были взяты набор сетевых структур данных и протоколов: Ethernet frame, IPv4, ICMP, TCP, UDP, SSH, DNS и DHCP и постановка задачи: большая часть этих протоколов (особенно SSH и DNS) реализуются, что называется «руками», а хочется, чтобы не было типичных для C переполнений буфера, все переходы совершались автоматически, это всё можно было верифицировать, и чтобы работало быстро, а не как обычно.

Поскольку никто не будет читать диссертацию, сразу скажу: это более чем удалось. По результатам работы были написаны референсные реализации DNS и SSH-сервера и произведено сравнение с BIND и OpenSSH. OCaml-реализации давали по сравнению с традиционными прирост производительности от незначительного, до почти двухкратного. Кроме того была найдена ошибка в RFC на SSH (рабочая группа была уведомлена и RFC исправлен). О том, что было сделано, и как с этим жить, читайте под катом.

Другие публикации в этом цикле

Часть 2. Сколько мегабит/с можно пропустить через зрительный нерв и какое разрешение у сетчатки? Немного теории
Часть 3. Знакомьтесь — лазер по имени Amaris. Переезды и первое пробуждение VisuMax
Часть 4.1 Возвращаем зрение. От очков до эксимерного лазера
Часть 4.2 Возвращаем зрение. От очков до эксимерного лазера

Эта статья открывает цикл, посвященный сфере высоких технологий в медицине, а именно в офтальмологии. Я думаю, что хабрасообществу будет интересно увидеть то, что скрывается за кулисами современной офтальмологической клиники. Я думаю, что для многих не секрет, что одним из наиболее эффективных способов коррекции зрения является Femto LASIK-технология. Основная задача фемтосекундного лазера — выкраивание роговичного лоскута — флэпа. Это крайне важный и ответственный этап лазерной коррекции зрения.

Сегодня мы рассмотрим необычный unboxing. Я думаю, что все читатели Хабрахабра уже привыкли к частым обзорам новых телефонов/планшетов/%devicename%. Но именно сегодня мы займемся распаковкой куда более внушительного «гаджета». Это — один из самых новых представителей фемтосекундных лазеров — VisuMax от фирмы Zeiss. Это очень радостное событие для нашей клиники — лазер позволит выполнять коррекцию нарушений рефракции с очень большой точностью по очень многим показаниям. Этой статье предшествовала огромная работа по выбору наиболее подходящего решения для нашей клиники, обучение инженеров, врачей и много чего еще. Сразу хочу предупредить — я врач по образованию, но постараюсь максимально полно раскрыть технические детали и нюансы. Не обижайтесь, если допущу какие-то ошибки — буду рад любым вашим замечаниям.

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

Судя по всему, у сторонников конспирологических теорий о рептилоидах фальшивых полетах человека на Луну в ближайшие годы появится очень много работы :) Дело в том, что NASA выложило в открытый доступ целых 17000 фотографий, сделанных в рамках программы «Аполлон» — всего цикла. В числе выложенных фото есть и очень известные снимки, и те, которые многие из нас увидят впервые.

Эта статья навеяна топиком «Как и насколько быстро вы считаете в уме на элементарном уровне?» и призвана распространить приёмы С.А. Рачинского для устного счёта.
Рачинский был замечательным педагогом, преподававшим в сельских школах в XIX веке и показавшим на собственном опыте, что развить навык быстрого устного счёта можно. Для его учеников не было особой проблемой посчитать подобный пример в уме:

В понедельник утром за неделю до Нового Года этот вопрос, думаю, актуален для многих.

Есть куча статей на эту тему. Вот основные советы:

• Начинайте с самой сложной задачи
• Сделайте первый шаг — продолжать будет уже легче
• Составьте план и неукоснительно ему следуйте
• Занимайтесь любимым делом
• Не отвлекайтесь

Всё просто. Закройте Хабр и приступайте к работе!

Только почему-то на меня все эти советы не действуют. Вроде правильные вещи люди говорят, но — не работает. Кстати, на тему «Почему не получается заставить себя работать?» тоже есть статьи. В них проблема описывается с точки зрения психологии и предлагаются решения вроде «избавьтесь от внутренних противоречий и страха перед неудачей». Наверное, если это сделать, то всё получится, но где найти эту волшебную кнопку «Избавиться от...»?

Если вам понадобится алгоритм сортировки массива, который:

• Работал бы гарантированно за O(N*log(N)) операций (обменов и сравнений);
• Требовал бы O(1) дополнительной памяти;
• Был бы устойчивым (то есть, не менял порядок элементов с одинаковыми ключами)

то вам, скорее всего, предложат ограничиться любыми двумя из этих трёх пунктов. И, в зависимости от вашего выбора, вы получите, например, либо сортировку слиянием (требует O(N) дополнительной памяти), либо пирамидальную сортировку (неустойчив), либо сортировку пузырьком (работает за O(N²)). Если вы ослабите требование на память до O(log(N)) («на рекурсию»), то для вас найдётся алгоритм со сложностью O(N*(log(N)²) — довольно малоизвестный, хотя именно его версия используется в реализации метода std::stable_sort().

На вопрос, можно ли добиться выполнения одновременно всех трёх условий, большинство скажет «вряд ли». Википедия о таких алгоритмах не знает. Среди программистов ходят слухи, что вроде бы, что-то такое существует. Некоторые говорят, что есть «устойчивая быстрая сортировка» — но у той реализации, которую я видел, сложность была всё те же O(N*(log(N)²) (по таймеру). И только в одном обсуждении на StackOverflow дали ссылку на статью B-C. Huang и M. A. Langston, Fast Stable Merging and Sorting in Constant Extra Space (1989-1992), в которой описан алгоритм со всеми тремя свойствами.