Давайте поговорим о покупке электронных компонентов в интернете. Я собрал список интересных отечественных и зарубежных магазинов:

а) которые заточены под любителей DIY и делают свои собственные крутые продукты: конструкторы, модули, обучающие курсы и т.д.;

б) для профи, с широкой номенклатурой электронных компонентов.

Продолжение: Часть II: зарубежные магазины

^{Aqua Mine}
Ревизор — программно±аппаратный комплекс для мониторинга доступа к сайтам из реестра со стороны провайдеров — берет свое начало в октябре 2015 года, когда компания «МФИ Софт», та же компания, что сделала СОРМы, выиграла тендер на разработку ПО за 84 миллиона рублей. Согласно условиям тендера, разработчик должен был предоставить работоспособное ПО под Windows и Linux и 700 аппаратных «Агентов» в срок до 14.12.2015, всего через 2.5 месяца, и, похоже, все было готово даже на пару недель раньше дедлайна. Провайдерам в добровольно-принудительном порядке уже в начале декабря предлагалось установить один из трех вариантов Ревизора: в виде образа виртуальной машины VMWare, основанной на OpenWRT 14.07, в виде программы-сервиса под Windows, либо же в виде железного «Агента», который представлял из себя маршрутизатор TP-Link MR3020 с установленным на него OpenWRT и необходимым ПО. Многие провайдеры отказывались от установки комплекса из-за того, что он не сертифицирован, а использоваться будет только им во вред, а другим устройств просто не досталось, и им пришлось установить софтовую версию.

Итак, у меня в руках последняя версия VMWare-образа и exe-файла Ревизора. Давайте же посмотрим, что внутри!

Написано на реальных событиях.

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

Итак, приступим. Вводные данные:

• 7 дисков, 2 primary-раздела на каждом;
• 1й раздел 7и кратное зеркалирование (RAID1);
• 2й раздел RAID5, под которым крутится LVM.

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

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

Всем доброго дня!

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

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

Почитав в свое время «Cloudmouse удалил все виртуальные сервера» и некоторые комментарии в стиле «сам виноват, надо было доверять проверенным облакам», решил поведать свою историю ужаса с весьма уважаемым облаком от Амазона (AWS). В подкасте радио-т я вкратце об этом рассказывал, но тут, как мне кажется, важны детали и впечатления от всего произошедшего кошмара.

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

В апреле 2001 Пол Грэм написал статью «Превосходя посредственность» («Beating the averages» — ориг).

Этот пост о том, почему Go, следуя статье, и есть то самое секретное оружие, которое должно быть у каждого стартапа.

Секретное оружие

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

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

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

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

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

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

1 Преждевременная оптимизация

В 97% случаев надо забыть об эффективности малых частей программы: преждевременная оптимизация – корень всех зол. Но в 3% случаев об оптимизации забывать не нужно.
Дональд Кнут

Хотя никогда зачастую лучше, чем прямо сейчас
Тим Питерс, Зен языка Python

Что это

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

Почему плохо

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

Как избежать

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

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

Инфографика Inside NGINX сверху вниз проведет вас по азам устройства процессов к иллюстрации того, как NGINX обрабатывает множество соединений в одном процессе. Данная статья рассмотрит всё это чуть более детально.

Привет, хабраюзер!

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

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

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

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

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

Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

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

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



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

Вредоносное ПО Linux/Moose используется злоумышленниками для компрометации различных устройств под управлением Linux, включая, сетевые роутеры. На скомпрометированном роутере или другом устройстве Linux/Moose будет перехватывать сетевой трафик и обеспечивать ее операторов прокси-сервисом. Как правило, злоумышленников интересуют служебные файлы сессий HTTP (cookie) от популярных сетевых сервисов. Они будут использоваться злоумышленниками для выполнения в них различных нелегитимных действий через прокси.



Вредоносная программа представлена обычными исполняемыми ELF-файлами, из которых удалена вся отладочная информация. Linux/Moose использует в своей работе многопоточность, для выполнения различных задач он создает более 30 потоков. Многие из них используются для автоматического поиска и заражения других устройств.

В прошлых частях [1], [2] анализа вредоносной программы Linux/Moose мы рассмотрели почте все ее механизмы работы. В этой части мы рассмотрим возможности удаления из системы других вредоносных программ, а также протокол работы бота с конфигурационным C&C-сервером.



Мы уже упоминали, что бот имеет в своем составе возможности по удалению из системы других вредоносных программ. Конфигурационный C&C-сервер передает ему список имен исполняемых файлов процессов. Каждый час бот проходит по списку процессов /proc/pid/ и просматривает командную строку, с которой был запущен процесс. В командной строке указано название процесса, а также переданные ему во время запуска аргументы. Проходя по этому списку процессов, Moose будет посылать сигнал kill каждому процессу из вышеупомянутого «черного списка». Этот список жестко зашит в тело вредоносной программы.

Представляю вашему вниманию обзор и мои субъективные оценки некоторых специализированных способов обхода блокировок со стороны провайдеров или сетевых администраторов.

1. Аддоны для браузеров

ZenMate (Chromium-based, Firefox, Android, iOS)

• Удобство использования: 5/5
• Скорость: 5/5
• Шифрование трафика: Да (TLS)
• Анонимность: Да
• Проксирование всего трафика: Да
• Выборочное проксирование: Да

    Описание:
        Хороший, быстрый аддон.
        На момент тестирования было доступно 5 прокси в разных странах.

    Плюсы:
        Высокая скорость работы аддона
        Быстрые прокси

    Минусы:
        Требуется регистрация в сервисе

Системное администрирование сейчас в печальном состоянии. Оно в хаосе.

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

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

Давайте взглянем на Hadoop. Судя по всему, никто не знает как собирать Hadoop с нуля; это просто огромная куча из зависимостей, необходимых версий и утилит сборки.

Ни одна из «замечательных» утилит не собирается традиционной командой make. Каждая утилита поставляется со своим собственным не переносимым и не совместимым c чем-либо «методом дня» для сборки.

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