Домашний облачный рабочий стол и гейминг в контейнере, с общим GPU. Готового решения не было — пришлось пройти четыре тупика и написать свой Wayland-композитор.
Я считаю, что попытки сделать линукс системой для любого - не лучшая идея. Она может погубить много проектов, и вот почему.
Что делать ученому с Эльбрусом? Краткий обзор ПО, которое мне удалось собрать и протестировать на Эльбрусе - средства для симуляции в ядерной физике, обработки и визуализации данных, верстки научных статей.
В предыдущей статье я рассказал, как писал скрипт мониторинга системы с нуля от идеи до рабочего инструмента с меню, цветным выводом и уведомлениями в Telegram. Там же выяснилось, что большинство проблем при написании bash-скриптов возникает не из-за сложной логики, а из-за незаметных ошибок: забытых токенов-заглушек, тихих падений через pipe, команд которые молча возвращают не то. Именно тогда я понял, что echo для отладкиэто каменный век.
Скрипт мониторинга написан и работает. Теперь поговорим о том, что делать, когда он перестаёт работать или ведёт себя странно. Я собрал инструменты и приёмы, которые реально меняют то, как работать с bash. Не абстрактный список из документации, а вещи которые я использую сам и которые несколько раз спасали в ситуации «скрипт упал на проде, надо найти за пять минут».
Для тех, кто спешит: быстрая шпаргалка
Все мы любим терминал. Но мало кто помнит наизусть все флаги команды find или как правильно распаковать хитрый архив без гугла. Данный инструмент может помочь избежать данной рутины.
Если ваш проект перерос стадию “просто собрать” и теперь требует бесперебойной работы в проде, простого пайплайна больше недостаточно. Главная боль — как исключить downtime и иметь возможность мгновенного отката? В третьей части цикла разбираемся с GitLab Container Registry.
Мы настроим хранение версий Docker-образов, разберем подводные камни Docker in Docker (dind) и SELinux, а также автоматизируем тестирование перед выкатом. Наконец простейший скрипт для запуска контейнера на production-сервере из вашего приватного Gitlab Registry.
Как же я люблю метонимичный технологический термин «задача cron». Несмотря на то, что реальным демоном, выполняющим задачи по расписанию, может являться совсем не cron, мы называем этим именем всё, что «ходит» как cron и «крякает» как cron. Как говорит Патрик Маккензи, задачи cron — это одни из самых полезных вычислительных примитивов. Их ценность легко демонстрируется множеством контекстов применения, с которыми сталкиваются почти все, кому требуется регулярно выполнять задачи, например, на ежедневной или ежемесячной основе.
И всё же использовать для планировки задач реальный cron вам, пожалуй, не следует. В 2026 году уже есть более продуманные варианты, и моим любимчиком является скромный таймер systemd. Я люблю таймеры systemd. И если вы о себе пока так сказать не можете, то я приведу аргументы, которые заставят вас пересмотреть свой взгляд.
Разработчики и системные администраторы, которые имеют дело и с Windows, и с Linux, давно привыкли к одной проблеме: скрипты и команды нормально функционируют на сервере, но не пойдут без адаптации на локальном компьютере. Для запуска привычных утилит вроде ls, cp, grep или find обычно приходилось использовать WSL, Git Bash или другие слои совместимости.
Microsoft решила упростить этот сценарий и выпустила пакет Coreutils для Windows, добавляющий популярные Unix-команды прямо в их систему. Решение ориентировано прежде всего на разработчиков, DevOps-инженеров и администраторов, которым приходится регулярно переключаться между разными платформами. Давайте разберемся, что это за пакет и как он устроен.
Демон «ничего не делал» — а одно ядро было загружено на 100%. История про виртуальный COM-порт для Linux/WSL2: PTY, epoll и эмуляция RS485, с кодом и граблями.
Рассказываю, как сделал vseriald — демон, который создаёт виртуальный последовательный порт /dev/ttyV0 в Linux и WSL2 и выводит его в сеть, FIFO или очередь сообщений. Разбираю три неочевидных места: псевдотерминал, после закрытия которого одно ядро уходит в 100%; притормаживание источника в однопоточном epoll-цикле без блокировок; эмуляцию полудуплексного RS485 как конечного автомата с таймингами и коллизиями. Плюс честный ответ на вопрос «зачем это, если есть socat и /dev/pts» — и код из реального проекта.
Я мобильный разработчик. Иногда при работе со структурами данных я имею дело с endpoint-ами, иду в вики, нахожу страницу с описанием — и не верю ей. Потому что по опыту знаю: страница описывает API таким, каким он был задуман полгода назад, а не таким, какой он сейчас. Дальше начинается знакомый ритуал: пишу в чат бэкендеру, он отвечает «глянь в сваггере», сваггер сгенерирован из аннотаций и показывает приблизительную картину, реальный ответ с сервера от неё отличается, потому что правило сериализации живёт в одном месте, а правило генерации описания — в другом. В итоге я делаю то, что делает большинство клиентских разработчиков: дёргаю endpoint «вживую», смотрю реальный JSON и верю только ему. То же самое бывает и при работе с внешними API (в том числе и солидных компаний).
Это и есть проблема источника правды. У нас не один источник, а несколько, и они конкурируют. Вики — это намерение. Код бэкенда — это реализация. Реальный трафик — это факт. И когда между ними возникает расхождение (а оно возникает всегда), цена ошибки ложится в первую очередь на потребителя API: на фронтенд, на iOS, на Android, на десктоп, на внешних интеграторов.
Эту боль на Habr описывали многие. Алексей, Java-разработчик ЮMoney, в статье «Как улучшить межсерверное взаимодействие и сэкономить время разработчика» формулирует её предельно прямо: «Swagger UI, который генерируется автоматом по метаданным классов, показывает очень примерное описание того, что у нас реально отдаётся из API. Поэтому фронты и мобильные разработчики не могут начать разработку, не вызвав endpoint на живую». Это не чья-то личная неаккуратность — это структурный изъян процесса, в котором правда не централизована.
Я использую Linux 15 лет. Ну, то есть как использую: первые года три я его настраивал, а не использовал. Это разные вещи, и мне понадобилось позорно много времени чтобы это понять.
Сейчас у меня Fedora. Из коробки. С GNOME. Почти без кастомизации. Я набираю в ней код, сижу в браузере, иногда монтирую видео для внутренних демок. Всё работает.
Пятнадцать лет назад я бы от такого описания плевался. Как это «из коробки»? А где i3? Где polybar? Где 400 строк .vimrc? Где кастомный скрипт на баше который при подключении второго монитора переключает раскладку DPI и температуру цвета?
Ну вот, нету. И ничего не сломалось.
Пришла в голову задача, которая на словах звучит просто. «Сделай скрипт, который смотрит логи и шлёт в Telegram» ну что тут сложного? Bash, curl, пара if-ов. Час работы, не больше.
Изначально хотелось простого, чтобы скрипт анализирует системные логи и отправляет отчёт. Потом захотелось чуточку усложнить и добавить:
1. Проверка ошибок в системных логах
2. Контроль свободного места на диске
3. Мониторинг состояния сервисов
4. Анализ использования памяти
5. Контроль попыток несанкционированного доступа
Пять пунктов. Каждый кажется несложным. Вместе они означали, что это уже не «скриптик на вечер», а полноценный инструмент. Что ж, поехали.
Для начала решил написать тестовую версию с минимальными фукциями:
Привет, Хабр! На связи Даниэль из InfoWatch, разработчик решений класса информационной безопасности. В предыдущей статье мы рассматривали задачу контроля целостности в среде Linux с помощью системного интерфейса inotify. Поговорили о ключевых недостатках, с которыми приходится сталкиваться в ходе работы с самим инструментом напрямую.
Наверное, многие из вас знают, что существует другой более совершенный и более функциональный системный интерфейс — fanotify. В рамках данной статьи мы продолжим рассматривать задачу мониторинга объектов файловой системы, но уже через призму fanotify. Попробуем ответить на вопросы, решает ли данный инструмент описанные ранее проблемы.
Введение
Начнём с краткой сводки по fanotify. fanotify представляет собой kernel-интерфейс, позволяющий мониторить события файловой системы в режиме реального времени. Определение такое же, как и для inotify. Почти. Существенная разница в том, что список обрабатываемых событий у fanotify гораздо шире, а также есть возможность принимать решение kernel-характера в user space. Простыми словами: вы можете разрешать/запрещать запуск программ без написания драйверов (модулей ядра), так как fanotify позволяет разрешить/запретить создание процесса в пользовательском пространстве.
Практический опыт ограничения приложений на Android
В статье рассматривается практический опыт настройки Android‑смартфона с root‑доступом для ограничения сетевого взаимодействия приложений и управления их разрешениями. Анализ трафика, whitelist/blacklist доменов, Magisk, iptables и создание контролируемой среды на устройстве.
На кону финансовые данные клиентов, а странный и неуловимый баг в Cilium не даёт как следует настроить сетевую безопасность.
Статья о том, почему любая «нерешаемая» проблема — это «пока недостаточно изученная» проблема. От случайных догадок — к системному исследованию и пул-реквесту с фиксом прямо в Linux.
Попытался структурировать всю эту прекрасную линуксовую фрагментацию и собрал «айсберг» дистрибутивов
Не так давно у меня на руках появилась плата RK-ZYNQ7020-F REV 1.1.
В данной статье я хочу поделиться своим опытом, связанным с подготовкой buildroot для данной платы. Здесь мы разберем этапы от формирования xsa файла до запуска платы и первых логов, с объяснением что происходит в железе на каждом этапе.
Также в рамках этой статьи я не буду использовать FSBL, мы попробуем обойтись U-Boot SPL.
Итак, приступим к рассмотрению!
Описание отладочной платы
Базовый набор периферии на данной плате, заявленный в документации:
Всем привет! Это моя первая статья на Хабре. Я постарался максимально понятно изложить проблематику получения HDR изображений на современных мониторах и операционных системах.
Давайте сразу проясним, что подразумевается под HDR фото, а что нет. В начале двухтысячных было модное занятие сначала фоткать высококонтрастный объект с разными экспозициями, проводить так называемый брекетинг экспозиции, а затем с помощью софта склеивать все в одно изображение. Изначальный огромный перепад яркостей сужался до обычного JPG и демонстрировался как достижение. Да, достижение было в виде сохранённых деталей в светах и тенях, но минимальный и, что самое важное, максимальный уровень яркости был далек от натуры. К тому же неизбежным следствием являлось падение общего контраста. Так вот, это не HDR. Это, назовем его, прокрустово ложе, куда надо впихнуть невпихуемое, и на выходе получить псевдо-HDR. Данная статья просвещена получению настоящего HDR, где узость диапазона уже не мешает делать высококонтрастные снимки. И не только делать, но и увидеть.
Представьте, что завтра из нашего мира исчезнут все проекты Линуса Торвальдса. Ваш смартфон на Android моментально превратится в кирпич, интернет ляжет, а вся командная разработка ПО намертво встанет без Git. Удивительно, но вся современная цифровая инфраструктура держится на решениях, которые были придуманы одним человеком не ради миллиардов или славы, а просто из любопытства. В этой статье вспоминаем путь главного интроверта IT: от попыток починить старый Commodore до создания ядра Linux, победы над Microsoft и революции в Open Source.
В статье описано восстановление смартфона Alcatel POP3 4035D после отказа большей части встроенной памяти.
