Как скрыть от посторонних конфиденциальную информацию?
Самое простое – зашифровать.
В Интернет и Интранет-сетях шифрацией данных управляет протокол SSL/TLS.
Солдат спит, служба идет.
Однако иногда возникает необходимость выполнить обратное – расшифровать перехваченный трафик.
Это может потребоваться как для отладки работы приложений, так и для проверки подозрительной сетевой активности.
Или в целях изучения работы SSL/TLS (очевидные, вредоносные цели не обсуждаются).

Как и при каких условиях можно расшифровать дамп SSL/TLS трафика в Wireshark?
Попробуем разобраться.

По долгу службы мне часто нужно находить все пересечения между текстами (например, все цитаты из одного текста в другом). Я достаточно долго искал стандартное решение, которое бы позволило бы это делать, но найти его мне так и не удалось — обычно решается какая-то совсем или немного другая задача. Например, класс SequenceMatcher из difflib в стандартной библиотеке Питона находит самую длинную общую подпоследовательность в двух последовательностях hashable элементов, а потом рекурсивно повторяет поиск слева и справа от нее. Если в одном из текстов будет более короткая подпоследовательность, которая содержится внутри уже найденной (например, если кусок длинной цитаты где-то был повторен еще раз), он ее пропустит. Кроме того, когда я загнал в него «Войну и мир» и «Анну Каренину» в виде списков слов и попросил для начала найти самую длинную подпоследовательность, он задумался на семь минут; когда я попросил все совпадающие блоки, он ушел и не вернулся (в документации обещают среднее линейное время, но что-то в прозе Льва Толстого, по-видимому, вызывает к жизни worst-case квадратичное).

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

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

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

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

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

Постановка вопроса

Недавно, во время собеседования в одну крупную компанию мне задали простой вопрос, что такое Load Average. Не знаю, на сколько правильно я ответил, но лично для себя пришло осознание, что точного ответа я на самом деле и не знаю.

Большинство людей наверняка знают, что Load Average — это среднее значение загрузки системы за некоторый период времени (1, 5 и 15 минут). Так же можно узнать некоторые подробности из данной статьи, про то, как этим пользоваться. В большинстве случаев этих знаний достаточно для того, что бы по значению LA оценивать загрузку системы, но я по специальности физик, и когда я вижу «среднее за промежуток времени» мне сразу становится интересна частота дискретизации на данном промежутке. А когда я вижу термин «ожидающие ресурсов», становится интересно, каких именно и сколько времени надо ждать, а так же сколько тривиальных процессов надо запустить, что бы получить за короткий промежуток времени высокий LA. И главное, почему ответы на эти вопросы не дает 5 минут работы с гуглом? Если вам данные тонкости так же интересны, добро пожаловать под кат.

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

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

Основной модуль конструктора Lego Mindstorms EV3 может работать с прошивкой leJOS, позволяющей запускать Java-приложения. Специально для этого Oracle выпустил и поддерживает отдельную версию полноценной Java SE.

Нормальная JVM позволила мне использовать встроенный в нее протокол Java Management Extensions (JMX), чтобы реализовать удаленное управление роботом-манипулятором. Для объединения управляющих элементов, показаний датчиков и картинок с установленных на роботе IP-камер используется мнемосхема, сделанная на платформе AggreGate.

Одной из важных технологий любой серьезной системы мониторинга сетей является метод обнаружения связей сетевых элементов на 2-м и 3-м уровне модели OSI.



С точки зрения алгоритмов эта задача является одной из самых интересных встреченных нами во время разработки нашей системы.

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

При внедрении систем мониторинга и управления IT-инфраструктурой часто приходится сталкиваться с «нестандартными» устройствами. Нередко про такое устройство наверняка известно только то, что оно поддерживает SNMP. Подключение его к проекту придется начать с ответа на вопрос о том, какую информацию о себе оно предоставляет. Обычно для этого проводится полный опрос устройства, и полученные данные анализируются на предмет выявления полезной информации… Но тут, как говорится, есть нюансы. В этой заметке я расскажу об одном таком — о разработанном нами алгоритме быстрого определения «поддерживаемых» устройством MIB-модулей.

000. Предыстория

В 1959 году Н. П. Брусенцов разработал для МГУ уникальную вычислительную машину «Сетунь». Она была основана на троичной системе счисления и хотя элементная база была частично двоичной, что приводило к перерасходу деталей, машина зарекомендовала себя как экономичная и надёжная. Сегодня троичную машину можно увидеть разве что в музее, двоичный код победил.

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

Современные компиляторы очень хорошо умеют оптимизировать код. Они удаляют никогда не выполняющиеся условные переходы, вычисляют константные выражения, избавляются от бессмысленных арифметических действий (умножение на 1, сложение с 0). Они оперируют данными, известными на момент компиляции.
В момент выполнения информации об обрабатываемых данных гораздо больше. На её основании можно выполнить дополнительные оптимизации и ускорить работу программы.
Оптимизированный для частного случая алгоритм всегда работает быстрее универсального (по крайней мере, не медленнее).
Что если для каждого набора входных данных генерировать оптимальный для обработки этих данных алгоритм?
Очевидно, часть времени выполнения уйдёт на оптимизацию, но если оптимизированный код выполняется часто, затраты окупятся с лихвой.
Как же технически это сделать? Довольно просто — в программу включается мини-компилятор, генерирующий необходимый код. Идея не нова, технология называется “компиляция времени исполнения” или JIT-компиляция. Ключевую роль JIT-компиляция играет в виртуальных машинах и интерпретаторах языков программирования. Часто используемые участки кода (или байт-кода) преобразуются в машинные команды, что позволяет сильно повысить производительность.
Java, Python, C#, JavaScript, Flash ActionScript — неполный (совсем неполный) список языков, в которых это используется. Я предлагаю решить конкретную задачу с использованием этой технологии и посмотреть, что получится.

Привет, Хабр!

Если раньше мы смотрели на проекты «умного дома» с интересом, но несколько со стороны, то сейчас, после выхода Black Swift в публичное поле, нам самим стали приходить вопросы и предложения по использованию его в качестве базы для «умного дома» — и естественно, я не мог не уделить отдельное внимание этой теме.

Результат меня расстроил, и я хотел бы поговорить об этом.

Проекты «умного дома» сейчас рождаются (и умирают) как грибы — но, к сожалению, в большинстве случаев они обусловлены не осознанием недостатков уже существующих решений, а самим фактом наличия технологических платформ, на которых что-то такое можно построить. Это хорошо видно по Хабру: по мере популяризации того или иного решения проходит волна очередных «беспроводных розеток» на нём. Так было с NRF24LE1, сейчас такая же волна идёт с ESP8266. Некоторые многообещающие проекты за свою жизнь успевают поменять по две-три платформы — в зависимости от текущей моды и наличия под рукой кого-нибудь, кто может на одной из них что-нибудь спаять.

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

Я пока не буду трогать какие-то серьёзные проблемы «умных домов», а поговорю о том, почему и какие технологии стоит рассматривать в качестве основы — чтобы не объяснять в комментариях в пятидесятый раз, почему я не считаю встраивание Wi-Fi в каждую розетку ни необходимым, ни разумным решением.

Ах да, чуть не забыл КДПВ. Вот:



Она не про «умный дом», а про то, что Black Swift можно найти на MWC на стенде Imagination Technologies. А теперь давайте про «умный дом».

Главным рабочим инструментом увлечённого своим делом программиста является ноутбук. Ты не привязан к конкретному офисному столу, да и вообще к офису, если на то пошло. Ноутбук для программиста и рабочее место, и центр развлечений, и окно в мир сеть. Но такая свобода имеет один недостаток: ноутбук вещь не маленькая, в карман не положишь. Можно, конечно, носить его в сумке через плечо, но это не слишком удобно: надо придерживать рукой, поддергивать соскальзывающий ремень, да и сама сумка получается широкой и жёсткой. В общем, чемодан без ручки. Совсем другое дело — рюкзак. Руки свободны, нагрузка распределена равномерно и гораздо комфортнее, ничего не болтается сбоку. Да и ноутбук защищён от всяких коллизий не в пример лучше. Неудивительно, что рюкзаки сегодня столь популярны среди всех слоёв населения, не только среди программистов. А уж в дальних поездках и перелётах рюкзаки вообще вне конкуренции. Поэтому стоит уделить особое внимание выбору модели, которая удовлетворяет всем вашим нуждам, эстетическому вкусу и анатомическим особенностям. Так что если вам приходится носить ноутбук, а ваш текущий рюкзак надоел или чем-то не нравится, или вы только подумываете перейти на рюкзак, то рекомендуем посмотреть эту подборку. Возможно, подберёте для себя интересную модель.

Один из самых привлекательных моментов в присоединении к стартапу — получение опционов (прав на приобретение определенной доли в стартапе по фиксированной цене). Это предоставляет право владения долей компании и помогает сбалансировать интересы руководства и сотрудников. Впрочем, один аспект в обыкновенном пакете опционов вызывает горячие дискуссии между сотрудниками и руководителями, и этот аспект — годовой порог (cliff). Мы в Alconost перевели для вас статью, в которой понятно и практично написано о клифф-вестинге, опционах и рисках, связанных со всем этим.

Есть вещи, от которых, попробовав раз, невозможно отказаться. Я говорю о хороших наушниках, хорошем телефоне, удобном ноутбуке и о хорошей сумке. Да-да, именно о сумке. Мы тратим много времени на выбор самого-самого прекрасного и производительного девайса, а потом кладем его в первый попавшийся рюкзак или портфель. И живем, не подозревая, что может быть иначе. В то время как правильная, продуманная сумка может принести немногим меньше удовольствия и пользы, чем дополнительная память или более быстрый процессор.

Помните пост «Что хабровчане носят с собой», где народ хвастался содержимым своего рюкзака? Меня, если честно, больше интересовало не содержимое, а то, в чем народ носит свои вещи. Вот так, к слову, выглядела одна из наиболее интересных вещей — фотосумка Boomburum.



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

Компания Google просит власти штата сертифицировать беспилотные автомобили по результатам виртуальных, а не настоящих тестов. Для этих целей в Google разработан продвинутый симулятор в стиле «Матрицы», пишет The Guardian. Симулятор содержит все автодороги штата, модели автомобилей, водителей и пешеходов — каждого со своим автономным маленьким «интеллектом».

Беспилотные автомобили Google проехали в симуляторе уже более 6 млн километров, сталкиваясь с реальными дорожными ситуациями, такими как подрезающие автомобили, вихляющие велосипедисты и непредсказуемые пешеходы.

Сегодня я хотел бы рассказать о еще одном компьютере в моей домашней коллекции, а именно о ПЭВМ АГАТ-9.

Этот 8-ми разрядный персональный компьютер был разработан в Научно-исследовательском институте вычислительных комплексов СССР (НИИВК). Разработка велась в 1981-1983 годах под предводительством главного конструктора Анатолия Фёдоровича Иоффе. И как всегда за основу был взят компьютер заграничного производства — американский школьный компьютер Apple II.

ПЭВМ АГАТ серийно производился с 1984 года и был впервые представлен на выставке CeBit 84. Последняя серия компьютеров АГАТ была выпущена в 1993 году, и, по информации из разных источников, в некоторых школах использование Агатов в учебном процессе продолжалось по меньшей мере до 2001 года.

ПЭВМ АГАТ выпускался в нескольких модификациях. В зависимости от комплектации и конструктивных решений предусмотрено несколько модификаций: АГАТ-4, АГАТ-7, АГАТ-8, АГАТ-9.

АГАТ-4 был выпущен в виде небольшой опытной партии и довольно быстро вышел из употребления. Чуть дольше продержался АГАТ-7, отличавшийся от своего прародителя большим объемом памяти, наличием НГМД и другими незначительными усовершенствованиями. Венцом творения отечественных производителей стал АГАТ-9, который обладал улучшенной системой управления памятью, дополнительными режимами отображения графики, и, самое главное, имел вполне удовлетворительную совместимость с программным обеспечением компьютера Apple II+ 64 K.

Понадобилось мне на днях сделать бэкап (около 75 гигабайт разных файлов) на внешний жесткий диск, да вот незадача — отформатирован он в файловую систему NTFS — вроде бы другие операционные системы давно пишут на нее без проблем, а в MacOS пришлось использовать «свое решение».

И так, изучив, то что мне предлагает google, выяснилось что надо купить либо Paragon NTFS, либо Tuxera NTFS, либо использовать бесплатное решение.

После ряда экспериментов, выяснилось, что наиболее простой способ — это поставить пакет ntfs-3g из MacPorts и подменить /sbin/mount_ntfs

Система портов MacPorts была у меня давно установлен (я ставил из него mc, wget и другие полезные утилиты, к которым привык в ОС Linux, такие как pwgen, например).

На чистой системе его нет — следовательно его необходимо установить согласно инструкциям на www.macports.org — скачать и запустить скрипт установки.

Далее, установим osxfuse и ntfs-3g

sudo port install osxfuse ntfs-3g

И чтобы была полная автоматизация, то есть автоматически монтировался носитель (а не вручную) подменяем mount_ntfs

sudo mv /sbin/mount_ntfs /sbin/mount_ntfs.orig
sudo vi /sbin/mount_ntfs

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

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис

Привет, username!

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