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

В данной заметке я постараюсь сравнить два разных подхода к задаче запутывания машинного кода – это протектор и обфускатор, построенный на базе LLVM-фреймворка. Нам пришлось с этим столкнуться, когда возникла задача защиты библиотек Guardant под разные операционные системы и разные ARM-архитектуры. Для x86/x64 мы используем протектор Guardant Armor, который является полностью нашей разработкой. В случае ARM-архитектуры было принято решение параллельно посмотреть в сторону открытых обфускаторов на базе LLVM с целью их модификации и использования для защиты своих продуктов.

Недавно компания OrangePi обновила линейку одноплатных компьютеров Orange Pi 5/5B/5+, распаяв на платах 32GB LDDR4 RAM. Однако данные платы вполне прилично работают и с меньшим объемом памяти на борту, а наличие SPI Nor Flash и возможность подключения NVMe диска делают эти платы достойными конкурентами среди одноплатных устройств для разаработки.

Нас заинтересовал первый образец серии 5/5B/5+, а именно Orange Pi 5, на предмет того, как на данном устройстве поведет себя EDK II и можно ли его использовать так, как мы привыкли работать с обычными ПК.

Параллелизм – это возможность выполнения запросов сервером СУБД в нескольких потоков. По умолчанию в настройках SQL Server параллелизм не ограничен и потенциально для выполнения запроса могут использоваться все ядра всех процессоров (max degree of parallelism= 0). В то же время, в системах 1С вендор настоятельно рекомендует установить max degree of parallelism = 1, и, соответственно, один запрос будет использовать только одно ядро.

Почему так и что же с этим всем делать? Давайте разбираться.

Это первый материал по «ИТ‑Пикнику», проходившему 2 сентября 2023 года. Будет отдельный обзорный материал мероприятия, а пока хочу представить интервью с руководителем направления исследований безопасности аппаратных решений компании Positive Technologies (РТ) Алексеем Усановым.

Осматриваясь на «ИТ‑Пикнике», я заглянул на стенд Positive Technologies. Там проходила лекция, я заинтересовался темой и решил послушать. Лекция была посвящена реверс‑инжинирингу в информационной безопасности. Я раньше с темой сталкивался только в контексте создания игр. Когда энтузиасты делают клон игры, но у них нет исходников и советов от разработчиков, только внешний вид игры и примерные представления, на каком движке она была создана. Оказывается, в ИБ это довольно знаковая область. Немного подумав после лекции, я поймал Алексея Усанова и поговорил с ним на тему реверс‑инжиниринга в ИБ, кстати, оказалось, что он написал целую книгу об этом.

Давайте рассмотрим распространенную проблему с пропущенными данными и способы ее решения.

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

Кстати, подписывайтесь на наши социальные сети, мы туда еженедельно публикуем топовый контент! Вот наш канал в телеграм и группа ВК.

Таблица 1: Пример набора данных о машинах

| Марка   | Модель  | Год выпуска | Цена | Нормализованные потери | Тип топлива |

|---------|---------|-------------|------|------------------------|-------------|

| Toyota  | Corolla | 2019        | 15000| 134                    | Бензин      |

| Honda   | Civic   | 2020        | 17000| NaN                    | Дизель      |

| Ford    | Mustang | 2018        | 25000| 235                    | NaN         |

| Subaru  | Outback | 2017        | NaN  | 178                    | Бензин      |

| Hyundai | Elantra | 2021        | 18000| 156                    | Гибрид      |

| Nissan  | Sentra  | 2019        | 15500| 170                    | Бензин      |

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

Двухтрубные системы отопления тупикового и попутного типа. В чём разница и что об этом говорят современные строительные нормы.

Ранее в одной из статей я уже рассказывал об однотрубных системах отопления.

Теперь настала очередь рассмотреть особенности проектирования и эксплуатации двухтрубных систем, которые крайне популярны у частных домовладельцев в ИЖС.

Так же двухтрубные вертикально-стояковые системы отопления пытаются применять и в многоквартирных домах.

Далее мы рассмотрим гидравлический расчёт систем для одного этажа частного дома с периметром в те же 50м для дом 10х15м по внутренним стенам (150м.кв на этаж).

А позже попытаемся применить те же подходы для максимальной высоты 50м в стояковой системе высотного дома.

Тупиковая система

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

На Хабре уже была новость об этом знаменательном событии. Правда, она похожа на пересказ официального пресс-релиза Microsoft, но такой и должна быть "новость".

Привет, уважаемые читатели!

GIL, или Global Interpreter Lock десятилетиями оставался темой обсуждения и дебатов среди питонистов.

Что такое GIL? GIL, сокращение от Global Interpreter Lock, представляет собой важную концепцию в Python. Он представляет собой мьютекс, который блокирует доступ к объекту Python interpreter в многопоточных средах, разрешая выполнять лишь одну инструкцию за раз. Этот механизм, хоть и заботится о безопасности и целостности данных, одновременно становится камнем преткновения для тех, кто стремится максимально задействовать многозадачность и использовать полностью потенциал многоядерных процессоров.

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

В начальных версиях Python, GIL не существовал. Однако, когда Python начал использоваться для многопоточных приложений, стало очевидным, что возникают проблемы с одновременным доступом к общим ресурсам. Поэтому Гвидо ван Россум и команда разработчиков внедрили GIL, чтобы обеспечить безопасность работы с памятью и объектами Python.

Когда Большой адронный коллайдер запущен — как например, во время своего второго цикла, с начала 2015 года по 2018 год, — он обрабатывает события на частоте 40 МГц. Другими словами, он учитывает 40 миллионов событий в секунду. Это необходимо, чтобы отслеживать столкновения между частицами, длящиеся менее 25 наносекунд.

Каждое событие содержит в себе примерно 1 мегабайт данных. Это значит, что в систему во время работы коллайдера входит примерно 40 терабайт данных. В секунду! Абсолютно фантастический объем информации, ведь петабайт набирается примерно за полминуты. Около 72 000 средних жестких дисков заполнялись бы каждый час.

Обрабатывать всё это на такой же скорости не представляется возможным; для анализа подобных объемов данных после окончания работы установки требуются годы. Значительная часть отфильтровывается еще на этапе сбора, на что тоже уходят огромные вычислительные ресурсы. Но всё‑таки остальную часть информации нужно где‑то хранить. Для этого европейская организация по ядерным исследованиям (ЦЕРН) содержит самый большой ЦОД в мире.

Технологическая платформа 1С:Предприятие – это большой программный продукт (только на С++ - более 10 миллионов строк кода, а есть ещё Java и JavaScript). Подробнее про устройство платформы можно прочитать тут.

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

О том, какие инструменты мы пробовали использовать, почему они нам не подошли и как мы в итоге решили задачу анализа использования памяти – под катом.

В программировании программы часто строятся иерархично. Один программный компонент вызывает функции из другого программного компонента. Как бы представить эту взаимосвязь в законченной программе?

Эту задачу можно решить прибегнув к языку Graphviz и утилитам cpp, dot, make, chrome.

Сегодня концепция витрин данных является стандартом и используется повсеместно. Поэтому даже небольшим компаниям важно определиться с помощью каких инструментов они будут решать проблему оркестрации процессов построения витрин. Какой инструмент в условиях относительно небольшого бюджета позволит достигать поставленных целей? Этот вопрос мы и постараемся раскрыть в статье. Для этого рассмотрим два известных инструмента: Airflow и NiFi, а также постараемся выявить их сильные и слабые стороны.

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

Copilot – система автодополнения кода от GitHub на основе модели Codex.
В статье даю советы по эффективному использованию Copilot на основе 6 месяцев личного опыта. Также добавил инструкцию по установке из России.

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

Откройте для себя один из первых языков программирования, который, по мнению Майка Бедфорда, не мог быть более непохожим на своих ранних собратьев.

В предыдущей части нашей серии, посвященной классическим языкам программирования, мы рассмотрели ALGOL, а в этом месяце мы углубились в изучение другого архаичного языка - LISP. Однако то, что оба они появились в 1950-х годах, - это практически единственное, что их объединяет; в большинстве других аспектов они не могут быть более разными. Скорее всего, практически все языки, которыми вы когда-либо пользовались, относятся к типу императивных. LISP же является декларативным языком. Проще говоря, программирование на императивном языке предполагает определение набора операций, которые при последовательном выполнении обеспечивают требуемую функциональность. требуемую функциональность. Тот факт, что существует альтернатива, может вызвать удивление, но в декларативном языке конечный результат определен, а система сама решает, как достичь поставленной цели.

Эти два подхода можно сравнить с инструкциями, прилагаемыми к мебели для самостоятельной сборки. При императивном подходе инструкция представляет собой подробный перечень указаний, а при декларативном методе вам просто показывают картинку собранной мебели. На самом деле, это не первое знакомство с декларативным программированием за последние месяцы. Чуть ранее мы познакомились с языком Prolog, который практически канул в Лету в 1980-х годах, а затем вновь стал популярным благодаря Al-революции.