Как собрать первый модуль ядра Linux и понять ошибки сборки

Минимальный модуль занимает 22 строки, но на машине автора сборка создала файл размером около 106 000 байт. После удаления отладочных данных осталось 4 864 байта. Точный размер зависит от компилятора, конфигурации ядра и даже пути к каталогу сборки.

Для эксперимента нужны компилятор и заголовки именно запущенного ядра. Makefile передаёт исходник в kbuild, систему сборки ядра. Она компилирует код, проверяет обращения к экспортированным символам и собирает модуль в файл .ko.

Если сборка не начинается, проверьте ссылку /lib/modules/$(uname -r)/build. Перед загрузкой также стоит проверить Secure Boot и режим блокировки ядра: они могут отклонить уже собранный модуль. Полный путь от hello.c до диагностики ошибок включает Makefile, устройство файла .ko, параметры модуля и причины несовместимости старых руководств.

Как правило против ложных срабатываний ослепило линтер

Автор линтера не проверял поле tools: список допустимых инструментов меняется, и сохранённая копия быстро устаревает. Защита от лишних предупреждений скрыла ошибки синтаксиса, для которых список вообще не нужен.

В четырёх конфигурациях стояло tools: *. Документация не считает одиночную звёздочку допустимым шаблоном, а для доступа ко всем инструментам советует убрать поле. Четыре зелёных прогона ошибку не заметили, ручное чтение заметило.

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

Как ускорить Quicksort на C, сократив ветвления

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

На Apple M1 сортировка 50 млн чисел заняла 1,70 секунды вместо 3,70. После дополнительных оптимизаций вариант показал 0,86 секунды против 1,19 у std::sort. На Intel Xeon соотношение другое, поэтому результат нужно проверять на своём процессоре.

В разборе с кодом на C показаны буфер, защита от неудачного разбиения и обработка малых участков.

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

ИИ может перенести старый код на новый стек вместе с неясными правилами и проблемами развёртывания. Получится та же система, только переписанная быстрее.

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

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

Полный процесс миграции разобран на TypeScript и Vitest.

Как сделать системную утилиту понятнее и приятнее

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

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

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

Почему Big O недостаточно для выбора структуры данных в C++

Автор создал hashbrowns, набор тестов для массивов, связных списков и хеш-таблиц. В замерах линейный поиск по массиву обгонял хеш-таблицу до примерно 150 элементов: вычисление хеша съедало выигрыш от быстрого доступа.

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

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

Как спроектировать память ИИ-агента, а не склад контекста

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

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

Схема архитектуры памяти агента показывает, как проверять эпизоды перед превращением в знания и удалять устаревшие данные.

Как защитить API от повторного выполнения операций

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

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

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