Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

Применительно к с++03 существует “правило трех”, с появлением с++11 оно трансформировалось в “правило 5ти”. И хотя эти правила по сути являются не более чем неформальными рекомендациями к проектированию собственных типов данных, но тем не менее часто бывают полезны. “Правило ноля” продолжает ряд этих рекомендаций. В этом посте я напомню о чем, собственно, первые 2 правила, а также попробую объяснить идею, стоящую за “правилом ноля”.

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

Традиционно, большая часть статьи будет посвящена теории, а скучные скрипты — в конце статьи. В качестве субъекта для экспериментов будет использоваться Steam, хотя написанное применимо к любому приложению, включая веб-браузеры.

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces

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

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

В этих условиях возникает большое желание оставить один на один конкретное приложение и заданный сетевой интерфейс. Один. Сконфигурированный для нужд только этого приложения.

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

В данной статье речь пойдёт о высокоуровневом взгляде на компоновку. Где ищутся разделяемые библиотеки на Linux, BSD*, Mac OS X, Windows, от которых зависят приложения? Что делать с обратной совместимостью? Как бороться с адом зависимостей?

Имитационное моделирование с использованием методов Монте-Карло в наше время используется практически во всех областях операционной деятельности, где требуется многократное принятие решений по итогам анализа поступающих из внешнего мира данных. При этом важную роль начинает играть качество, производительность и доступность генераторов случайных чисел, использующихся для придания абстрактному методу черт реальной задачи, решаемой специалистом. Как я недавно выяснил, этот вопрос начинает играть решающее значение при переходе к параллельному программированию… Вы тоже столкнулись с этой проблемой, и хотите знать, как в Windows можно быстро получить массивы случайных чисел с нужным распределением?

Средства для резервного копирования информации можно разделить на несколько категорий:
— Для домашнего/офисного применения (резервирование важных документов, фотографий и пр. на NAS либо в облако);
— Для средних и крупных (offline) предприятий (резервирование важных документов, отчетности, баз данных и пр. как на серверах так и на рабочих станциях сотрудников);
— Для малых веб-проектов (резервирование файлов и баз данных с хостинговой площадки либо VPS/VDS на удаленный хост (или наоборот));
— Для крупных веб-проектов с распределенной архитектурой (почти то же самое, что и на offline-предприятиях только с учетом работы в глобальной сети, а не локальной, и как правило с использование open source средств).

С программными продуктами для дома и офиса все достаточно просто есть масса решений как открытых так и проприетарных, от cmd/bash скриптов до решений известных производителей ПО.
В enterprise секторе все достаточно скучно есть масса программных продуктов которые давно и успешно работают на многих предприятиях, в крупных банках и пр, рекламировать никого не будем. Многие из этих продуктов хорошо упростили жизнь системных администраторов, за достаточно «скромные деньги» по меркам некоторых предприятий.
В данной статье более подробно рассмотрим open source решения для резервного копирования веб-проектов разного масштаба, а также проведем тест на скорость резервирования файлов.
Статья будет полезна веб-мастерам, небольшим веб-студиям, ну и возможно даже бывалый админ найдет здесь что-то полезное.

Как вы, наверное, догадались, эта статья посвящена lock-free очередям.

Очереди бывают разные. Они могут различаться по числу писателей (producer) и читателей (consumer) – single/multi producer — single/multi consumer, 4 варианта, — они могут быть ограниченными (bounded, на основе предраспределенного буфера) и неограниченными, на основе списка (unbounded), с поддержкой приоритетов или без, lock-free, wait-free или lock-based, со строгим соблюдением FIFO (fair) и не очень (unfair) и т.д. Подробно типы очередей описаны в этой и этой статьях Дмитрия Вьюкова. Чем более специализированы требования к очереди, тем, как правило, более эффективным оказывается её алгоритм. В данной статье я рассмотрю самый общий вариант очередей — multi-producer/multi-consumer unbounded concurrent queue без поддержки приоритетов.

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

К сожалению, статья будет достаточно тяжелая для обычного прикладного программиста, не интересующегося тематикой защиты ПО, но тут уж ничего не поделать.

Для более или менее адекватного восприятия статьи потребуется минимальные знания ассемблера (его будет много) а так-же навыков работы с отладчиком.

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

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

В качестве реципиента, по совету одного достаточно компетентного товарища, я выбрал немножко старый (но не потерявший актуальности, в силу качества исполнения) keygenme от небезызвестного Ms-Rem.

Вот первоначальная ссылка, где он появился: http://exelab.ru/f/index.php?action=vthread&forum=1&topic=4732
А потом он попал вот сюда: http://www.crackmes.de/users/ms_rem/keygenme_by_ms_rem/
Где данному keygenme был выставлена сложность 8 из 10 (*VERY VERY* hard).
Хотя, если честно, это слегка завышенная оценка — я бы поставил в районе 5-6 баллов.

Пожалуй, начнем.

Статья не о том, чем заняться, пока собирается проект.

Фраза «Шаблоны — полноценный, тьюринг-полный, язык» часто воспринимается с недоверием. Это же просто обобщающая возможность современных языков программирования, откуда там вычислительные возможности? Так думал и я. Теперь хочу переубедить остальных, попутно объясняя принципы работы шаблонов для начинающих, вроде меня.

Мое понимание шаблонов впервые пошатнулось после прочтения главы «Метапрограммирование» из книги о С++ от создателя С++ — показалось, что они действительно могут быть полноценным языком программирования внутри языка программирования. Во всяком случае, там точно есть рекурсия. Но лучший способ доказать себе что-то — попытаться сделать, что мы и сделаем.

Существует множество реализаций легендарной игры «Жизнь» Джона Конвея, безумных и не очень. Но все они имеют общий фатальный недостаток: каждая итерация Жизни вычисляется непосредственно во время работы программы. Попробуем это исправить.

Думаю, большинству хабрапользователей хоть раз да приходилось кодировать видео. Возможно, вы хотели посмотреть свежую серию любимого сериала в метро, а ваш смартфон или иное портативное устройство никак не хотело играть этот кодек, или SmartTV отказывался декодировать звук в видеофайле, либо же вы застряли в 2004 и транскодировали H.264 в MPEG-4 для вашего старого DVD-проигрывателя. Или же, например, сжимали невероятного размера видео, снятое фотоаппаратом, во что-то более-менее приличное по размеру. Наверняка вы замечали, что это не самый быстрый процесс.

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

Что вообще следует понимать под распределенным кодированием видео? В моем представлении, есть 2 разных задачи:

1. Кодирование большого количества видеофайлов на множестве компьютеров одновременно
2. Кодирование одного видеофайла по частям на множестве компьютеров одновременно

Первая задача подразумевает наличие большого количества видеофайлов, сильно больше, чем компьютеров, на которых их можно кодировать, и довольно легко автоматизируется с использованием CLI-кодировщиков, например, HandBrake или FFmpeg и любых средств автоматизации, которые поддерживают распределение, вроде GNU Parallel или PPSS (к слову, о нем мало кто знает, рекомендую!).

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

В предыдущих своих заметках я описал основу, на которой строятся lock-free структуры данных, и базовые алгоритмы управления временем жизни элементов lock-free структур данных. Это была прелюдия к описанию собственно lock-free контейнеров. Но далее я столкнулся с проблемой: как построить дальнейший рассказ? Просто описывать известные мне алгоритмы? Это довольно скучно: много [псевдо-]кода, обилие деталей, важных, конечно, но весьма специфических. В конце концов, это есть в опубликованных работах, на которые я даю ссылки, и в гораздо более подробном и строгом изложении. Мне же хотелось рассказать интересно об интересных вещах, показать пути развития подходов к конструированию конкурентных контейнеров.
Хорошо, — подумал я, — тогда метод изложения должен быть такой: берем какой-то тип контейнера — очередь, map, hash map, — и делаем обзор известных на сегодняшний день оригинальных алгоритмов для этого типа контейнера. С чего начать? И тут я вспомнил о самой простой структуре данных — о стеке.

Вступление

Говорят, ребенку в школе понадобится цветной принтер и сканер. Да и самому хотелось уже на что-то поменять разваливающийся черно-белый лазерник 1996 года выпуска. Критериями выбора стали: цветность, лазерная технология (перерывы между печатью могут достигать месяцев), автоподатчик оригиналов для сканера и копира, автоматическая двусторонняя печать и Wi-Fi, чтобы поставить этот ящик в дальнем углу. По этим характеристикам подобралась какая-то громадина за 25+ килорублей, что показалось неразумным. И вдруг на работе выдали пару подарочных карт одного известного розового магазина, и пришло ощущение, что надо покупать. К сожалению, в его ассортименте было всего три лазерных МФУ с цветной печатью, ни один из которых не отвечал последним двум требованиям. Спустя два месяца аccортимент ничем не пополнился, а наоборот, сократился до двух позиций на всю Москву, и я решил взять то, что было в наличии и не на витрине.

Счастливчиком оказался HP Laserjet Pro 100 Color MFP M175a, без автоповорота страниц и с подключением только по USB. Кстати, он оказался не таким большим, как я ожидал, и не таким шумным, как пишут в отзывах.

Задача

Если автоматическую двустороннюю печать добавить к принтеру почти невозможно, то отвязать его от компьютера вполне реально.

Аннотация

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

Эта статья не для специалистов по серверному хранению данных, геймеров и прочих оверклокеров. На вас, коллеги, и так вся индустрия работает. Она для начинающих сисадминов, любителей UNIX-систем и энтузиастов свободного программного обеспечения. У всех накопилось старое железо. Всем нужно хранить большие объемы дома или в офисе. Но далеко не у всех есть простой доступ к серверным технологиям.

Я очень надеюсь, что вы найдете для себя несколько полезных идей и все-таки научитесь на чужих ошибках. Помните: система стоит не столько, сколько вы заплатили за железо, а сколько вы вложите потом времени и сил в тестирование и эксплуатацию.
Если не хотите читать — посмотрите ссылки и выводы в конце; может, и передумаете.

DISCLAIMER

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

Благодарности

Респект Андрею Александровичу Бахметьеву, инженеру и изобретателю. Я горд, что Андрей Александрович преподавал для меня в институте! Желаю ему всяческих успехов в его проектах!

Задача

Итак, есть малый бизнес-стартап, генерирующий порядка 50Гб файлов в неделю, с необходимостью их архивного хранения в течение нескольких лет. Файлы крупные (порядка 10-20 Мб каждый), обычными алгоритмами не сжимаемые. Начальный объем данных порядка 2Тб. Совсем старые данные можно хранить в оффлайне, подключая по требованию.
Нужно уложиться в весьма скромный начальный бюджет решения 500 евро (в ценах лета 2013) и двухнедельный срок на сборку и тестирование.

За эти деньги нужно построить систему, которая позволит работать с файлами небольшой группе в одной локальной сети с разных платформ (Windows, Mac OS). Требуется длительная работа без сисадмина на площадке, защита от отказов и базовые функции управления правами доступа.

Традиционные пути

Безусловно, можно купить сетевое хранилище: их делают NetApp, QNAP, Synology и другие игроки, и притом делают неплохо даже для малого бизнеса. Но наши 500 евро – это только начало разговора для пустой коробки, без самих дисков. Если у вас есть 1000-2000 евро, лучше купите готовое изделие, а мы попробуем максимально заплатить знаниями и минимально — временем и деньгами.

UPD (спойлер ред. 2 от 2014-03-08):


А как же облачное хранение, спросите вы? На момент написания этой статьи популярные облачные хранилища для наших объемов выглядят дороже, чем хотелось бы. Например, стоимость хранения неограниченного объема данных 36 месяцев на известном сервисе Брось Бокс обойдется в пару тысяч долларов с лишним, хотя и выплачивать их можно постепенно. Конечно, есть сервисы вроде Amazon Glacier (благодарю А.М. за подсказку) или Ажурных Окон, но, во-первых, они тарифицируют не только хранение, но и обращение (как его априорно подсчитать?), а во-вторых не будем забывать, что бизнес сидит на Интернет-аплинке 10Мбит, и маневры терабайтами потребуют не только определенных усилий по управлению процессами, но и будут весьма утомительными для пользователей.

Обычно в таких случаях берут старый компьютер, докупают большие диски, ставят Linux (не обязательно, кто-то ухитряется и Windows 7), делают массив RAID5. Отлично. Всё работает хорошо примерно полгода-год, но одним солнечным утром сервер вдруг пропадает из сети без всякого предупреждения. Конечно, сисадмин уже давно работает в другой фирме (текучка кадров), резервной копии нет (объемы слишком велики), а новый сисадмин починить систему не может (при этом на чем свет стоит ругает старого сисадмина и диалект Linux YYY, ведь надо было использовать Linux ZZZ, тогда проблем бы точно не было). Все эти истории повторяются давно и одинаково, меняются только версии ОС и растут объемы данных.

Отраслевые мифы

Миф о RAID5

Самый распространенный миф, в который я и сам верил до недавнего времени – это то, что второго подряд отказа в массиве на практике не может быть по теории вероятности. А вот и может, да еще как! Смоделируем реальную ситуацию: сервер проработал пару лет, после чего в массиве отказывает диск. Пока ничего страшного, ставим новый диск, и что происходит? Ага, реконструкция массива, т.е. длительная максимальная нагрузка на уже порядком изношенные диски. В такой ситуации отказы очень даже возможны и происходят.
Но это не все. Есть еще заложенная производителем методическая вероятность ошибки чтения, которая при определенных обстоятельствах сейчас уже практически гарантирует, что RAID5 после отказа диска обратно не соберется.

Сбалансированное дерево поиска является фундаментом для многих современных алгоритмов. На страницах книг по Computer Science вы найдете описания красно-черных, AVL-, B- и многих других сбалансированных деревьев. Но является ли перманентная сбалансированность тем Святым Граалем, за которым следует гоняться?

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

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

Как все начиналось

Порядка 5 лет назад, я начал свое шествие по миру ламповой техники. За это время было собраны десятки разных схем и прослушано порядка пяти десятков «оригинальных» ламповых усилителей. В результате, сформировалось четкое понимание «как должно звучать» и какой «гибкостью» должен обладать аппарат.
В процессе знакомства с разными гитарными усилителями, долгое время, меня не оставлял в покое звук «головы» от фирмы Krank. Но в тот момент, к сожалению, оценить его и попробовать — было невозможно. Продажи начались только-только в Штатах, а живых экземпляров в Санкт-Петербурге не было. Было принято решение во что бы то ни было, достать столь «лакомый кусочек». К счастью нашлись подходящие люди которые смогли купить и привезти его в Питер. Долгие 14 дней ожидания и моя прелесть стояла на пороге квартиры. Счастью не было предела. Чем больше я на нем играл, тем больше мною овладевала мысль: «Как же устроена эта штука».
В один прекрасный момент, собравшись с духом, я твердо решил: “Я должен узнать «тайну » этого чуда”.

Шли дни, летели недели. Кусочек за кусочком вырисовывалась схема.

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

Как показывает практика, большинство людей (увы!) бросают свои диссертации, не дойдя до защиты. Почему так происходит?

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

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

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



Я уже не помню как и когда в моей голове поселилась эта странная идея — собрать ламповый усилитель. Зачем тоже не совсем понятно — меломаном я не являюсь, домашними кинотеатрами давно и быстро переболел, на память об этом времени остались напольные колонки Wharfedale Diamond 8.4, последние годы использовавшиеся исключительно как декоративная подставка для цветов. Как бы то ни было, мысль настолько глубоко поселилась в моей голове, что началось неспешное изучение профильных ресурсов, чтение форумов, поиск схем ламповых усилителей «для чайников» и т.д. и т.п. Отсутствие какого-либо опыта общения с ламповой техникой (самый современный гаджет, который я помню — это ч/б телевизор в студенческой общаге в начале 90-х годов прошлого века) отпугивало и привлекало одновременно.

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

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

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