Перевод статьи подготовлен специально для студентов курса «Разработчик С++».

---

Что такое детерминированная сборка?

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

И ещё о сортировках

Рискну опять поднять эту тему. Начну со ссылки на статью Михаила Опанасенко (oms7), очень впечатляющую по объёмам проделанной работы, а также по количеству приведёных ссылок. Свой материал начал готовить, не зная об этой публикации, что впоследствии, после ознакомления привело к необходимости его существенной переработки. Для тех, кто уже прочитал эту статью, сообщаю, что в моём материале, исследуются более разнообразные по типам данные, в частности, строки и вещественные числа, используются библиотеки boost и bsd, а также затрагиваются некоторые другие отсутствующие в названной статье темы.

Около 3 лет назад я перешел с C# разработки на Python. Два с половиной года я пытался найти инструмент, который был бы похож на NCrunch по удобству в ежедневной работе.

В какой-то момент я забил на unit-тестирование, и писал код, прогоняя тесты на CI.

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

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

«А зачем мне это нужно?»:

1. Автоматический запуск только тех тестов, которые затронуты изменениями кода. (Запуск происходит в фоновом режиме, и не отвлекает от написания кода)

2. Понимание, какие конкретно тесты, затрагивают определенную строчку кода (Удобно, например, отслеживать путь выполнения программы и понимать какие ветви кода еще не покрыты тестами):

Как устроено контрактное производство электроники в США?
Можно ли заработать на краудфандинге?
Софт, который убивает железо. Миф или реальность?
Есть ли жизнь у open-source проектов?

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

Всем привет!

После вчерашнего поста о замене штатного ls другими штатными (или не очень) утилитами, я просто не мог пройти мимо комментов, особенно учитывая то что пост взлетел на вершины хит-парадов и за сутки его прочитало 18k, с хвостиком человек. Хабровчане подарили миру много новых способов избавиться от ls. Я их все (но это не точно) проверил, некоторые «причесал», что бы они соответствовали условиям задачи, и хочу поделиться с вами. Наслаждайтесь!

Однажды в телеграм чат питерского сообщества линуксоидов SPbLUG я кинул забавную задачку:

Выведите список файлов в домашней директории максимально возможным количеством способов, без использования ls или его алиасов(1 способ — 1 балл)

Такое же задание чуть позже прилетело в ещё один чат, и вот что из этого получилось:

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

До последнего времени, несмотря на очевидность уязвимости DNS трафика, который, до сих пор, по большей части, передаётся в открытом виде, для злонамеренных действий со стороны провайдеров, стремящихся повысить своих доходы за счёт встраивания рекламы в контент, государственных силовых органов и цензуры, а также просто преступников, процесс усиления его защиты, несмотря на наличие различных технологий, таких как DNSSEC/DANE, DNScrypt, DNS-over-TLS и DNS-over-HTTPS, буксовал. И если серверные решения, а некоторые из них существуют уже довольно долгое время, широко известны и доступны, то поддержка их со стороны клиентского программного обеспечения оставляет желать много лучшего.

Добрый день, Хабровчане!

1. Вместо вступления

Недавно опубликованный перевод Ментальные модели ИБ заинтересовал меня не только общим посылом (в частности, применение моделей в обучении – острый для меня вопрос, ведь учёба – процесс непрерывный), но и списком ссылок на модели. Почему он так важен? Разберёмся по ходу статьи.

С некоторыми из перечисленных в тексте моделей приходится сталкиваться в рамках рабочего процесса (мониторинг и реагирование модно связывать с MITRE ATT&CK и Kill Chain). О других у меня было общее представление, но как их применять, или какие ключевые особенности позволяют повысить эффективность сего процесса, оставалось за кадром. Названия каких-то моделей, признаться честно, я слышал впервые.

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

Источник: xkcd

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

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

Всем привет!

Начал перевод небольшой книги:
"Understanding Message Brokers",
автор: Jakub Korab, издательство: O'Reilly Media, Inc., дата издания: June 2017, ISBN: 9781492049296.

Из введения к книге:
"… Эта книга научит вас рассуждать о системах обмена сообщениями на брокерах, сравнивая и противопоставляя две популярные технологии брокеров: Apache ActiveMQ и Apache Kafka. Здесь будут изложены примеры использования и стимулы разработки, которые привели к тому, что их разработчики использовали совершенно разные подходы к одной и той же области — обмену сообщениями между системами с промежуточным брокером. Мы рассмотрим эти технологии с нуля и выделим влияние различных вариантов дизайна на этом пути. Вы получите глубокое понимание обоих продуктов, понимание того, как их следует и не следует использовать, и понимание того, на что следует обращать внимание при рассмотрении других технологий обмена сообщениями в будущем ..."

Переведенные к настоящему моменту части:
Глава 1. Введение
Глава 2. ActiveMQ
Глава 3. Kafka

Перевод выполнен: t.me/middle_java

Буду выкладывать законченные главы по мере перевода.

Встреча в Кёльне прошла, стандарт C++20 приведён к более или менее законченному виду (по крайней мере до появления особых примечаний), и я хотел бы рассказать об одном из грядущих нововведений. Речь пойдёт о механизме, который обычно называют operator<=> (стандарт определяет его как «оператор трёхстороннего сравнения», но у него есть неформальное прозвище «космический корабль»), однако я считаю, что область его применения гораздо шире.

У нас не просто будет новый оператор — семантика сравнений претерпит существенные изменения на уровне самого языка.

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

Важно:
1. Эта серия уроков для новичков. Цель — сформировать целостную картину мира. Очень долго у меня в голове была теория Таненбаума и я не мог ее связать с практикой. Тем у кого то же самое — посвящаю эту статью.
2. Код самый простой и тупой, но максимально понятный. Моя цель дать вам понимание чтобы вы смогли написать свое ядро, гораздо более крутое чем это.
3. Репо опубликую как только посчитаю его готовым для широкого круга. Я пишу небольшую часть, отлаживаю, и снимаю видеоурок. У меня нет готового продукта.

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

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

Я должен был разобраться как получить состояние функционирования фискального принтера и его внутренние параметры настройки. Задача давно выполнена, а фискальный принтер был надолго заброшен в дальний угол… Пока в мою голову не пришла идея немного покреативить :D

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

На выходе получился вот такой ролик:


Подробные действия для печати гобелена на языке python под катом ниже.

Вышел React 16! Рассказывая об этом событии, можно упомянуть множество замечательных новостей (вроде архитектуры ядра Fibers), но лично меня больше всего восхищают улучшения серверного рендеринга. Предлагаю подробно всё это разобрать и сравнить с тем, что было раньше. Надеюсь, серверный рендеринг в React 16 понравится вам так же, как он понравился мне.

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

Статья будет состоять из нескольких разделов ниже:

• Функции
• Данные
• Результаты
• Выводы

В последние годы C++ шагает вперед семимильными шагами, и угнаться за всеми тонкостями и хитросплетениями языка бывает весьма и весьма непросто. Уже не за горами новый стандарт, однако внедрение свежих веяний — процесс не самый быстрый и простой, поэтому, пока есть немного времени перед C++20, предлагаю освежить в памяти или открыть для себя некоторые особо «скользкие» места актуального на данный момент стандарта языка. 

Сегодня я расскажу: почему if constexpr не является заменой макросов, каковы «внутренности» работы структурного связывания (structured binding) и его «подводные» камни и правда ли, что теперь всегда работает copy elision и можно не задумываясь писать любой return. 

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

Предположим, ваша Python-программа оказалась медленной, и вы выяснили, что это лишь отчасти обусловлено нехваткой процессорных ресурсов. Как выяснить то, какие части кода вынуждены ожидать чего-то такого, что не относится к CPU?



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

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

Часто бывает так, что приходишь на машину и обнаруживаешь какой-то скрипт, запущенный под системным пользователем неделю назад. Кто его запустил? Где искать этот run.php? Или добавляешь запись в /etc/crontab, а скрипт там падает с ошибкой «command not found». Почему? И что делать? 

У меня есть ответы на эти вопросы.

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

Как мы узнали из предыдущего урока, IPv4 использует автоматическую конфигурацию внутренних, или приватных IP-адресов (APIPA).



Этот механизм включается, когда сетевой клиент пытается связаться с DHCP-сервером, чтобы получить IP-адрес, но по каким-то причинам не может этого сделать. В этом случае устройство, работающее по протоколу IPv4, само присваивает себе случайный IP-адрес вида 169.254.Х.Х. После этого оно сообщает свой APIPA адрес с помощью широковещательной трансляции, и если больше ни одно устройство в сети не имеет такого IP-адреса, оставляет его себе. В противном случае клиент генерирует новый адрес, случайным образом выбирая содержимое третьего и четвертого октета, и снова использует broadcast – передачу.

Эта тривиальная задача возникла в один из пятничных дней и должна была занять 2-3 минуты времени. В общем, как всегда.

Коллега попросил поправить скрипт у него на сервере. Сделал, сдал ему и обронил ненароком: «Время спешит на 5 минут». Сервер его, пусть сам и разбирается с синхронизацией. Полчаса, час прошел, а он всё пыхтит и тихо матерится.

«Бестолочь! — подумал я, переключаясь в консоль сервера — ну ладно оторвусь ещё на пару минут.»

Смотрим, ntp, rdate, sdwdate не установлены, timesyncd отключен и не запущен.

# timedatectl
      Local time: Sun 2019-08-25 20:44:39 +03
  Universal time: Sun 2019-08-25 17:44:39 UTC
        RTC time: Sun 2019-08-25 17:39:52
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

Здесь сразу отмечу, что аппаратное время верное: по нему будет легче ориентироваться дальше.

Отсюда и началась череда ошибок.