Обеспечение работы прикладного ПО
В этом тексте я написал как реализовать CLI на CAN шине.
В разработке электроники часто делают электронные плату без UART, но с CAN .
Как же отлаживать софт и железо в таких случаях?
Кейс полностью автономного траблшутинга нетривиальной системной проблемы с неработоспособностью NVENC в Docker-контейнере на Jetson Orin NX с помощью Claude Opus 4.6, как пример выхода больших языковых моделей за пределы квалификации middle-grade инженера. Около 40 минут заняло расследование проблемы, по мотивам которого, я попросил сеть написать статью, которую и предлагаю вашему вниманию как пример того, на что я мог потратить целый день, а большинство middle-grade инженеров бы не справилось вообще. Весь траблшутинг и статья сделаны в полностью автоматическом режиме без участия человека.
Иногда возникает странное ощущение: железо стало безумно быстрым, процессоры научились выполнять миллиарды операций в секунду, памяти стало больше, чем раньше было дискового пространства. Но почему-то программы всё равно тормозят. Открываешь простой веб-интерфейс — и ноутбук начинает шуметь вентиляторами. Запускаешь приложение для заметок — и оно ест полгигабайта RAM. Я долго думал, откуда это ощущение. Потом начал копаться: читать дизассемблер, смотреть профилировщики, запускать микробенчмарки. И постепенно стало понятно, что дело не в железе. Дело в том, как мы пишем код.
Предлагаю поговорить о кэше процессора, о том, сколько стоит случайный доступ к памяти, о том, как CPU исполняет ваш цикл.
Логирование есть практически в каждом C++ проекте. Почти любой сервис, демон или библиотека рано или поздно обрастает строками вроде LOG_INFO(...) или logger.debug(...).
Чаще всего библиотека выбирается по привычке или популярности — spdlog, quill, easylogging++ и т.п. При этом редко кто проверяет, какую цену приложение платит за логирование.
В высоконагруженных системах логирование может выполняться:
А вы знаете что в СССР у нас были свои языки программирования? Что ж, почему бы нам не посмотреть что мы можем возродить?
Иногда старые проекты дают о себе знать в самый неожиданный момент — так случилось и с моим Linux GPIO Daemon. Коллеги из департамента методик и автоматизации тестирования в YADRO заинтересовались разработкой, и я наконец решил довести его до ума. Расскажу о демоне, который реагирует на события линий: текстовым сообщением об изменении состояния в сокет либо запуском скрипта. Это аналог incron-ng, только мониторит он не файлы, а линии GPIO. А в конце обсудим, как найти и затем не терять нужный нам gpiochip.
Эта статья скорее всего будет полезна тем, кто продолжает разбираться или работать на платформах .NET . Предупреждаю! Здесь будет далекое плавание в разные места, и с точки ОС будет упомянуто достаточно много!
На просторах Хабра есть несколько хороших статей про устройство и поведение .NET. Мне хотелось бы стать "чем-то по связующим" между ними.
В данной статье мы подробно поговорим об устройстве RPC. Также для лучшего понимания применим знания на практике и напишем свое RPC-приложение под Windows.
Привет, Хабр! Меня зовут Владлен, я ― инженер-программист отдела разработки РЕД ОС. Ко мне пришли с предложением рассказать об утилите, которую мы создали для быстрого ввода устройств на базе РЕД ОС в домен. Тема интересная, ведь join-to-domain умеет в несколько механизмов подключения, пережил перенос на другой язык программирования и дружит с РЕД АДМ. Итак, сегодня я расскажу подробнее о том, как мы создали join-to-domain и как использовать его на благо вашей ИТ-инфраструктуры.
Древний дисковод ожил и издавая чудовищный скрежет стал медленно загружать мое послание. Через какое-то время на экране появились строки:
NE PUERO GLADIUM, DR. KRIGER. 04.03.2026
Три пары глаз повернулись ко мне в немом изумлении.
— Это длинная история, нам лучше присесть.
CP/M — это известная операционная система для 8 битных процессоров Intel 8080. Если вам интересно узнать, как она была устроена на самом деле (не по пересказам, а по оригинальному исходному коду) — добро пожаловать под кат.
Переезд с macOS на Windows для разработчика часто сопровождается болью от потери привычного инструментария. В моем случае решающим стимулом свитчнуться на ПК стала мощная видеокарта. Сейчас мой верный MacBook всё так же лежит на столе и даже подключен к мониторам, но по факту именно Windows (как бы сильно она мне ни не нравилась) стала основной рабочей системой.
И главной болью при этом переходе стал менеджер буфера обмена. На маке я привык к тому, что могу найти скопированный лог недельной давности за секунду, вставить текст без форматирования одним шорткатом и вообще не думать о том, что история куда-то исчезнет.
Штатный инструмент Windows (Win+V) разочаровал моментально: лимит в 25 элементов, отсутствие поиска и полное обнуление после перезагрузки ОС. Поиск альтернатив тоже не увенчался успехом: Ditto надежен, но выглядит как гость из 2005 года, а мощный CopyQ имеет перегруженный интерфейс суровой системной утилиты. Ни в одном из них не было современных функций вроде OCR «из коробки» или базовой интеграции с LLM для обработки текста на лету.
Решение напрашивалось само собой — написать свой велосипед. Но сделать его легким, быстрым и без Electron. В этой статье расскажу о том, как устроен Beetroot — менеджер буфера обмена с бесконечной историей, нативным OCR и AI-трансформациями.
После первой статьи в комментариях несколько раз прозвучало примерно одно и то же:
"Всё правильно, но это же про любую зрелую СУБД — что с этим делать?"
Я думал над этим вопросом несколько недель. И в итоге решил не искать ответ в виде
"возьмите правильный инструмент X" — а попробовать честно сформулировать:
какими свойствами OLTP-БД должна обладать сама по себе, независимо от того,
насколько хорош ваш оператор, консультант или runbook.
Что такое "контракт" — и почему это не маркетинг
Попробую объяснить не через определение, а через ощущение.
Когда вы покупаете автомобиль, вы не читаете инструкцию к тормозам каждое утро.
Вы просто знаете: нажал педаль — машина тормозит. Это контракт. Он не зависит от того,
правильно ли вы настроили тормозную жидкость этим утром или не забыли включить
"режим торможения" в меню.
Это продолжение серии. Если вы не читали первую часть, рекомендую начать с неё: https://habr.com/ru/articles/1000766/
Добрый день, в контексте моего хобби по схемотехнике и программированию микроконтроллеров появилась идея реализовать устройство для дистанционного запуска предпускового котла Webasto, в моем случае это "Webasto Thermo Top Evo 5". Вероятно предложенный материал подойдет и для реализации устройств управления для схожих отопителей данной марки работающих по протоколу W-bus.
Как только я узнал, что книга Making Embedded Systems 2nd Edition (русская версия: «Создание встраиваемых систем. Паттерны проектирования отличных программ. 2-е издание») доступна для предзаказа, я не раздумывая отправился на Amazon и раскошелился за неё.
Некоторое время я занимался самообучением в различных областях, связанных с электроникой и разработкой встраиваемых систем, но в совершенно произвольном и никак не организованном ритме.
Рассчитывал, что эта книга даст мне хороший каркас, на базе которого можно будет формализовать мой рост и обучение.
Я сразу примерно представлял, о чём будет книга, и полагал, что сначала научусь с её помощью настраивать среду разработки для различных микроконтроллеров класса STM32, а потом, отталкиваясь от материала книги, смогу перейти в любую область разработки, которая к тому времени будет меня больше всего интересовать.
Просмотрев на сайте O'Reilly предметный указатель и выложенные для просмотра главы, я обнаружил, что такой «конфигурационной» главы в книге нет. Также в предисловии прямо рекомендовалось не прыгать по книге от главы к главе, а проработать её всю по порядку.
Нередко при оптимизации приложений, написанных на языках со статической компиляцией (C, C++, Rust), наступает момент, когда стандартные методы оптимизации, такие как улучшение алгоритмов, подбор структур данных, флаги компиляции вроде -O3, перестают давать дополнительный прирост производительности. В этот момент многие вспоминают про фундаментальное ограничение статических компиляторов. В отличие от JIT, они не знают, какой код будет горячим, а какой холодным. JIT-компиляторы (JVM, V8, .NET) получают эту информацию в runtime и адаптируют оптимизации под реальную нагрузку. Статические компиляторы генерируют машинный код заранее и лишены информации о поведении программы в runtime. Для решения этой проблемы используется подход Profile Guided Optimization (PGO). Он позволяет собрать данные о выполнении программы и передать их компилятору для принятия более оптимальных решений при генерации кода. По сути, PGO - это способ дать статическому компилятору некоторые преимущества JIT, сохраняя при этом все преимущества ahead-of-time компиляции: отсутствие пауз на перекомпиляцию и полный контроль над билдом.
По данным отраслевых опросов, в 2025 году 84% разработчиков использовали ИИ-инструменты для написания, отладки и автоматизации кода. А в 2026 году ожидается, что более 80% компаний будут применять генеративный ИИ в разработке своих продуктов. Но у LLM есть ограничения, которые не позволяют им быть одинаково эффективными для всех языков программирования — например, для С++.
Тему ограничений AI в пайплайне «плюсовой» разработки обсудили Андрей Золотых и Илья Казаков из YADRO, Константин Владимиров из Синтакор, Илья Шишков из Сбертех и Денис Фокин из LRI. К каким выводам пришли эксперты, читайте под катом.
Кен Томпсон с Деннисом Ритчи являются соавторами Unix — операционной системы, которая лежит в фундаменте современной ИТ-индустрии. Важно заметить, что он начал работать над Unix раньше Ритчи. По словам Томпсона, он в одиночку написал первые версии Unix и делал в Bell Labs предшественников Unix и С — ОС Multics, языки Bon и B — ещё до того, как туда пришёл юный аспирант Деннис, помог всё улучшить и разработал язык С. Но вообще их карьера очень похожа: обоих после вуза направили в Bell Labs, где они трудились почти всю жизнь.
Томпсон неоднократно входил в топ-10 программистов всех времён и тому подобные рейтинги. Кроме Unix, в его послужном списке операционная система Plan 9, язык программирования Go и несколько выдающихся программ.
Это история о том, как мы несколько недель искали странные скачки latency в продакшене и в итоге уткнулись в поведение кэша процессора. Не в аллокатор, не в GC, не в сеть. В кэш. В статье — реальные эксперименты, код, метрики, гипотезы, которые не подтвердились, и довольно неприятные выводы о том, насколько процессор может быть непредсказуемым, когда система нагружена по-взрослому.