Зачем вообще этим заморачиваться?

Некоторые образцы malware выполняют различные проверки, чтобы определить, запущены ли они в виртуальной машине. Один из самых частых способов — проверка наличия определённых аппаратных компонентов, обычно не эмулируемых в виртуальных средах. Один из таких компонентов — кулер процессора. Например, malware может проверять наличие кулера процессора, поискав в WMI класс Win32_Fan:

wmic path Win32_Fan get *

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

Зловредное ПО может определять, запущено ли оно в виртуальной машине, множеством разных способов. Есть различные классы WMI, позволяющие обнаружит присутствие виртуальной машины, например, Win32_CacheMemory, Win32_VoltageProbe и множество других.

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

Категорически приветствую, дорогой Хабр! Меня зовут Сергей и я психолог. Но не нужно хлопать и говорить «я тебя так понимаю» или «сочувствую». Я искренне люблю свою профессию. Одна из главных причин этой любви – возможность прикоснуться ко множеству жизней и понять размышления человека, его майндсет, если позволите. А также, увидеть, к чему этот майндсет привел – к каким достижениям и, разумеется, трудностям.

И по моим подсчетам, за последние три года я пообщался (как бы сказали любимые здесь всеми HR-ы: «провел глубинное интервью») примерно с сотней айтишников всех мастей. И вот замеченные закономерности и выводы мне хочется обобщить в этой статье. Фактически, это будет набор жизненных историй, переживаний и размышлений, которые достаточно трудно узнать в таком количестве и на таком уровне откровенности, не находясь в роли психолога. Впереди вас ждет квинтэссенция самых сокровенных мыслей, желаний и неудач ваших коллег по цеху, которые вам никогда об этом не расскажут. Поехали!

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

В последние месяцы всё чаще слышим про «reasoning-модели», способные не просто продолжать текст, а действительно шаг за шагом решать сложнейшие задачи цепочкой рассуждений (chain-of-thought). Впервые такой подход эффектно показали в OpenAI o1, но, к сожалению, подробности там остаются секретными. Недавно же команда DeepSeek наделала шуму с открытыми вариантами R1 и R1-Zero, созданными поверх их собственной большой MoE-модели DeepSeek-V3. В этом посте я не стану углубляться в вопрос «чья модель лучше — o1 или R1». Зато разберу, какие главные технические детали стоят за R1, почему Zero-версия выглядит особо захватывающе, и как именно авторам удалось обучить модель мыслить.

Вашему вниманию предлагается полный список разделов электронной книги (12 из 11 :)), посвящённой неопределённому поведению. Книга не является учебным пособием и рассчитана на тех, кто уже хорошо знаком с программированием на C++. Это своего рода путеводитель C++ программиста по неопределённому поведению, причём по самым его тайным и экзотическим местам. Автор книги — Дмитрий Свиридкин, редактор — Андрей Карпов.

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

Недавно нам пришлось организовать пайплайн с использованием интересных С++-трюков. О них я и расскажу в статье. 

— Как хранить в одном контейнере разные типы и использовать тип в качестве ключа контейнера 

— Как средствами метапрограммирования удобно сериализовать и десериализовать разнотипные объекты 

— Как сделать универсальный запускатель функций, который будет запускать любую функцию и сам искать, откуда «добыть» эти аргументы 

— И главное, как сделать интерфейс для написания пайплайна обработки события — удобный и полностью изолированный от инфраструктуры

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

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

Шутка, написанная гарнитурой Times, на 10 % смешнее той, что написана гарнитурой Arial. Почему? Чёрт знает. Лучшее объяснение, которое я видел: юмор ассоциируется с агрессией, с остротой, с остроумием — а Times выглядит более острым, чем Arial.

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

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

(КДПВ – см. аннотацию к диаграмме в конце)

Должен признать, что в некоторые из предыдущих лет C++ мог ощущаться немного «скучным» и «стабильным». Новые фичи, новый стандарт каждые три года, встречи, конференции... обычная жизнь (не считая некоторых дополнительных событий с в мире, экономике и эпидемиологической ситуации). Прошедший год отличается, потому что выглядит как «переломный» в истории C++... и кто знает, куда это заведёт нас.

Давайте вспомним некоторые вещи, случившиеся в прошедшем году.

Насколько популярна сегодня тема атомарных данных, настолько же она обширна для одной статьи. Можно подробно останавливаться на разных аспектах атомарности: например, анализировать memory ordering, рассуждать о lock-free алгоритмах с использованием атомиков или исследовать производительность атомиков на разных платформах.

Под катом мы рассмотрим некоторые базовые принципы работы с атомарными типами данных в языке C++. А именно: осветим работу с атомарными данными, основные операции с ними в стандартной библиотеке C++, а также некоторые аспекты использования атомиков с пользовательскими типами данных.

Пишем синхронный сервер

void naive_accept() {
  for (;;) {
    auto new_socket = accept(listener);

    std::thread thrd([socket = std::move(new_socket)] {
      auto data = socket.receive();
      process(data);
      socket.send(data);
    });

    thrd.detach();
  }
}

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

Search4Faces

Это обновленный до версии 2020-21 мой список 2003, 2005, 2006, 2007, 2009, 2011 и 2014 годов, который в настоящее время включает все остальные мои списки. Я занимаюсь этим более 17 лет. Вау. Думаю, стоит тратить на это больше времени.

Это расшифровка-перевод доклада Саши Гольдштейна, признанного лучшим на конференции DotNext 2016 Piter. С годами этот доклад стал лишь актуальнее прежнего: появление Mac на ARM-процессорах — еще один пример, почему разработчикам сегодня нужно думать не только о x86-архитектуре.

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

То, что подходит процессорам Intel на архитектурах x86 и x86-64, может не подойти другой архитектуре. Как только вы перенесете свой код на другой процессор, например, на ARM для iPhone и Android, есть вероятность, что он перестанет работать как надо. Проблемы могут быть как очевидными (воспроизводиться с первого-второго раза), так и не очень (возникать только раз в миллион итераций). Вполне вероятно, что такие баги могут добраться до продакшна. Сегодня .NET и, конечно, C++ можно использовать не только на Windows и Intel, но и на других платформах, так что доклад будет полезен многим разработчикам.

Дисклеймер: статья предназначена для продвинутых читателей. Смотрите на свой страх и риск. За частое упоминание барьеров памяти и изменения порядка исполнения инструкций она получила возрастное ограничение 18+.

Все говорили – переходи на rust! Начинай пользоваться самым-самым языком, который самый любимый язык на stackoverflow и всё такое.

Я тяжело вздохнул и огляделся. Ну опять двадцать-пять. Ладно, давайте разбираться, как правильно покрывать всё ржавчиной.

Профессионально я программирую уже 17 лет. В далёкие-предалёкие времена я начал изучать программирование с x86 Assembly. Такой жестокий подход к изучению компьютера дал мне глубокое понимание того как работает процессор и что делают другие языки программирования. Учить новые языки для меня никогда не было проблемой. Я их просто учил. C, C++, шарпы, ГО, тысячи разных скриптов и фреймворков. Чего уж там, ещё один язык, можно и выучить.

Ага.

Только вот не с этой ржавой развалюхой. Я просидел две недели над официальным руководством, пялился в VSCode и не мог выдавить из себя больше чем fn main() {}. Ну какого же чёрта? Я просто закрыл глаза, открыл руководство на рандомной странице и начал его читать. И прикол в том, что я понял о чём там говориться. И тут до меня дошло… Руководство написано наизнанку. Начало и конец ничуть не лучше чем в Мементо Кристофера Нолана. Они как-то умудрились запутать в общем-то нормальное руководство. После этого всё пошло получше.

Ржавые шестерёнки заскрипели и начали крутиться. Программа пошла-поехала. Если хотите знать как я внедрил rust в продакшин, как я ему научился и что из этого вышло – добро пожаловать под кат. Реальные люди, коммиты, примеры и никаких todo-list и хеллоу-ворлдов.