Linux *

Когда собираешь и тестируешь свой Linux для одноплатника достаточно долго, начинаешь замечать, что деплой Linux на SD-карту — монотонная повторяющаяся последовательность действий, занимающая ценное время, в которой легко совершить ошибку. К тому же больно видеть, как исчерпывает свой ресурс SD-карта и слот для неё.

Часто при embedded-разработке эти проблемы решают при помощи сетевой загрузки Linux.

В этой статье я расскажу, как организовать сетевую загрузку для Raspberry Pi и собрать минимальное ядро Linux, поддерживающее сетевую загрузку.

Сетевая загрузка рассматривается для Raspberry Pi 3 Model В и Raspberry Pi 4 Model B, которые я далее называю общим термином Raspberry Pi или более ласково — малинка.

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

Тема сетевой загрузки довольно многогранна и затрагивает несколько уровней стека — от протоколов локальной сети до особенностей загрузчика Raspberry Pi. Я старался изложить материал максимально просто и последовательно, но если у вас нет базовых знаний о работе локальных сетей (DHCP, TFTP), протоколах TCP/IP или процессе загрузки Linux, некоторые моменты могут показаться сложными.

Статья является продолжением моей предыдущей статьи, где я рассказывал, как создать минимальный Linux для Raspberry Pi, который грузится с SD-карты.

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

Надеюсь, что статья сэкономит вам время, которое вы сможете потратить на свой увлекательный проект.

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

На прошлой неделе моё внимание привлёк этот коммит:

858d2e434dd 8372584: [Linux]: Замена чтения proc для получения CPUtime потока на clock_gettime

diffstat выглядел интересно: +96 вставок, -54 удалений. В changeset был добавлен бенчмарк JMH из 55 строк, что означало реальное уменьшение кода продакшена.

Данная статья была впервые опубликована в июле 2024 года. В ней разбирается, пожалуй, самый популярный миф о свободном программном обеспечении. Будто критерии свободы, обозначенные проектом GNU лишь снижают свободу пользователей. Поскольку этот миф столь же живуч, что и иные мифы о свободном ПО, разобранные в статье о соотношении свободы и приватности с безопасностью, — данная работа также не потеряла актуальности. Ее текст остался без изменений, однако, как и в случае с упомянутой статьей, некоторые ссылки на источники были заменены на более удобные.

Мониторинг целостности файлов выглядит простым ровно до тех пор, пока не пытаешься сделать его полезным для расследований и одновременно не убить прод. Сканы пропускают «изменил и откатил», inotify не даёт нужного контекста, auditd начинает стоить слишком дорого. В Datadog пошли через eBPF и получили то, чего не хватало: реальные события с привязкой к процессам и контейнерам — а вместе с ними и новую проблему масштаба, когда счёт идёт на миллиарды событий в минуту. В статье разберем, как они перенесли часть логики фильтрации в ядро, научились отсеивать шум ещё до user space и превратили поток телеметрии в сигнал, который можно выдержать.

Прямо сейчас в вашем ядре есть баги, которые не найдут ещё многие годы. Я знаю это, потому что проанализировал 125183 бага с отслеживаемой меткой Fixes: за 20-летнюю историю Git ядра Linux.

Прежде чем баг обнаружат, он в среднем живёт в ядре 2,1 года. Но в некоторых подсистемах ситуация гораздо хуже: для драйверов шины CAN этот срок в среднем составляет 4,2 года, для сетевого протокола SCTP — 4,0 года. Самый долгоживущий баг в моём датасете (переполнение буфера в ethtool) прятался в ядре 20,7 года. Баг, который я проанализирую в статье подробно (утечка refcount в netfilter), прожил 19 лет.

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

Привет всем!

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

Я решил сам разобраться и доказать: ядро Linux — это просто исполняемый файл. Никакой магии. Его можно взять, скомпилировать (или просто скопировать) и запустить, как любой другой бинарник.

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

Но сперва — а что это вообще за ядро?

В прошлой статье я закончил обзор open source решения для аналитики и, что важно для нас, решения для менеджера тегов - Matomo Tag Manager. В этой статье приступаем к разбору по косточкам самого решения. И начинаем с установки его на сервер. А я продолжаю выступать своего рода евангелистом Matomo Tag Manager в рунете, где он незаслуженно, по моему мнению, обойден стороной.

В этой статье мы разберём Dokploy — open-source платформу для деплоя приложений. Узнаем, какие задачи она решает, какие функции предлагает и чем отличается от популярного конкурента Coolify. В конце вы поймёте, подходит ли Dokploy для ваших проектов.

Помните мою статью про историю моддинга и аппаратную платформу Motorola E398? Если ещё не читали, то рекомендую ознакомиться. А тем временем у @EXL нашёлся редчайший прототип E398, который разработали в России и он работал на Linux! Если интересно почитать его историю и что у него внутри - жду вас под катом.

На Хабре про OSTree обычно вспоминают не как про самостоятельную технологию, а как про "то, на чём держатся" Fedora CoreOS / Silverblue / Kinoite и вообще вся тема immutable / atomic desktop / container-optimized OS. Это видно по типовым материалам: обзор CoreOS с объяснением rpm-ostree и layering, обзор Silverblue, новости/разборы релизов Fedora, где rpm-ostree фигурирует как механизм поставки базовой системы. 

При этом намного хуже покрыта практическая сторона "как сделать свой цикл поставки": поднять свой OSTree-репозиторий, выпускать свои refs и раскатывать их на узлы так, чтобы можно было обновиться и откатиться, а не как герои трагикомедии "обновили пакеты — и внезапно утро не наступило". На фоне обилия статей "как устроен Silverblue/CoreOS" такой сценарий встречается реже. 

Мы раскроем полный цикл от публикации сервера до создания клиентских образов в этой статье.

Создатель Linux официально присоединился к лагерю тех, кто не стесняется генерить код через AI. Подрыв устоев!

Если вы работаете с роботом под Linux, то знаете эту боль: сегодня лидар — /dev/ttyUSB0, завтра — /dev/ttyUSB1, а камеры внезапно меняются местами.

В статье разобран надёжный способ привязать USB-устройства к физическим портам через by-path, создать стабильные имена в /dev и перестать править конфиги после каждой перезагрузки.

Подходит для роботов (да и не только), Linux (проверено на Ubuntu Server) и ROS2.

Если что, это не кликбейт. История довольно проста: в один из рабочих дней (работаю экспертом по компьютерной экспертизе) мне "на стол" попал сервер на ALT. Всё стандартно:

1) делаю чек железа, дабы исключить модули аппаратного шифрования / аппаратные токены и т.д.

2) делаю диагностику всей системы на момент первого запуска, для внесения в отчёт. Данная диагностика должна включать в себя первичную информацию о: диске; памяти; сети; базовых службах (ssh, cron и тд.) и о системе в целом.

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

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

Существует ли хотя бы теоретическая возможность защититься от ошибок переполнения стека и сделать из нее обычную ошибку (исключение), которую можно поймать (обработать) в самом приложении, чтобы была возможность продолжить выполнение программы без боязни последующей ошибки сегментации (segmentation fault) или повреждения стека (stack smashing)?

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

В руках у меня оказалась невзрачная черная коробочка — KM8p, сердцем которой бился восьми ядерный кристалл s912, с двумя гигабайтами оперативной памяти и восемью гигабайтами встроенного хранилища. Задача — вдохнуть в нее жизнь, установив легковесную графическую среду xfce, единственную, что под силу этой скромной оперативе.

Мой путь лежал через дистрибутив armbian, версию 26.02.0-trunk. Но это был не простой установочный образ, а целый лабиринт, полный не очевидных ловушек и правил, будто составленных загадочным архитектором.

Вот и настало время финальной части повествования, в которой я расскажу о практическом результате той эпопеи что растянулась на несколько лет.

Ситуация: рабочая машина под управлением Windows находится в корпоративной сети за NAT. Извне хода в сеть нет. К рабочему компьютеру необходим удалённый доступ с домашнего компьютера на Linux. Работа AnyDesk оставляет желать лучшего.

Всем доброго времени суток, не так давно появилась необходимость вывести звук на несколько наушников подключенных по bluetooth к ноутбуку, система Ubuntu 22.04, ядро 6.8.0. Пересмотрел много информации, но почти все не то, куча ошибок, зависаний и тд. Решил обобщить все что было прочитано и попробовано и что в итоге вышло.

Начнем с того, что нужно посмотреть какие модули установлены в системе для PulseAudio:

Как заставить китайскую механическую клавиатуру (Zifriend, SAMA, Gamestop, Cyberlinx) работать в Linux, хотя производитель этого не обещал.

История о том, как я «подружил» свою Cyberlinx ZA63 с Linux Ubuntu, когда официально поддержки нет. Для всех, кто думал, что клавиатуры «просто работают» везде или столкнулся с такой же проблемой.

Начал я проходить курсы системных администраторов Linux. Ну и одним из заданий стала установка Netbox с «нуля». Первым делом — как всегда — открыл официальную документацию Netbox‑а. Тут есть подробнейшая инструкция (кстати, довольно информативная), как его установить, смотри.

Но на определённых этапах установки стали появляться совершенно непредвиденные проблемы. То, что в главном конфиге пароль нужно указывать дважды и то, как его вообще устанавливать — это уже мои недосмотры, а вот то, что для первой установки после создания базы /venv/bin нужно инициализировать статический контент — это я нашёл где‑то совершенно случайно, и понял что оно работает, что называется, методом «волшебного тыка».

Саму установку делал под «чистым» debian. Такие условия у курсов... Но — на мой скромный взгляд — установка под «Убунтой» полностью идентична, а в Npm и Dnf based системах всё должно работать так же. Никаких специфичных пакетов тут нет.