Linux *

TL;DR: Расскажу про свой опыт перепрошивки телефона и превращения его в маленький домашний сервер. Спойлер: оказалось гораздо проще, чем я сам ожидал.

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

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

Можно было для этой цели взять какой-нибудь из старых ноутбуков, что пылятся у меня за спиной, или купить Raspberry Pi, но я решил, что это будет слишком скучно, потому что, честно говоря, затеял всё это для развлечения, а не для гонки за реальным результатом, этого мне и на работе хватает. Я было полез на всем известный сайт в поисках б/у дешёвого Mac на M1 или чём повкуснее. Искал как сами miniPC, так и ноутбуки со сломанными дисплеями. Но, покопавшись в объявлениях с полчаса, понял, что это не такое дешёвое удовольствие, как хотелось бы. Да и что там будет веселее, кроме повышенной мощности?

И вот в этот момент я подумал: ну я же вырос из мобильной разработки, а M1 – это сильно ушедший вперёд мобильный процессор (не бейте ногами, я сильно упрощаю, да).

Почему бы не поискать возможность накатить сервак на телефон?

Если у вас есть конфигурационный файл docker‑compose.yml, то в большинстве случаев его можно запустить через Podman без переписывания. Так вы, с одной стороны, сохраните привычный воркфлоу, а с другой — получите преимущества rootless‑контейнеров. В Docker же для запуска compose-файлов раньше использовалась внешняя утилита Docker Compose, но спустя время Docker внедрил возможность запускать такие файлы нативно через Docker Compose plugin.

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

В Podman аналогично есть Podman Compose — подкоманда, которая запускает внешний провайдер. В качестве такого провайдера может выступать Docker Compose / docker‑compose. Вот во всем этом сегодня и разберемся.

Что делать, если после очередного обновления Linux на старом ноутбуке намертво отвалился звук, а в логах висит зловещее CORB reset timeout и 0xFFFF? Переустановка аудио-серверов не поможет, параметры загрузчика GRUB система упорно игнорирует, а LTS-ядро больше не гарантирует стабильности. В этой статье разбираем, как спуститься в логи dmesg, понять, почему устройство «задыхается» на шине PCI, и заставить ядро заново проинициализировать аудиокарту «на горячую» с помощью sysfs и systemd.

Многие наверняка сталкивались с проблемой: смотришь по ТВ спокойный фильм, который прерывается резкой и громкой рекламой; или, например, при общении по ВКС всех собеседников слышно нормально, но у кого-нибудь одного микрофон будет шуметь так, будто он в данный момент находится рядом с двигателем самолета, готовящегося взлетать. Конечно, всегда можно подрегулировать громкость динамиков, но всегда ли это удобно и возможно?

AI-агент для управления VPS через Telegram

В прошлой статье я показал идею: AI-агент на VPS, который позволяет управлять сервером через Telegram и практически забыть про SSH.

Главный вопрос в комментариях был один: «Как это повторить у себя?»

В этой статье — полный разбор и готовый open-source комплект, который можно развернуть за ~10 минут:

docker-compose конфигурация

набор bash-скриптов для управления сервером

конфиги агента

deploy-скрипт

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

Технология eBPF — интересная штука. С её помощью можно без труда внедрять в ядро Linux фрагменты кода, которые затем компилируются в коды операций (опкоды), которые гарантированно не обрушат работу ядра. Набор допустимых инструкций ограничен, переходы назад не допускаются (поэтому не будет никаких неопределённых циклов). При этом вы не можете разыменовывать указатели, но вместо этого можете выполнять проверяемые операции считывания через указатели, которые потенциально могут оказаться неудачными, но при этом не спровоцируют паник на всю систему. eBPF в ядре Linux можно закреплять в тысячах хуков (точек перехвата), в качестве которых могут выступать u-пробы, k-пробы, точки трассировки и даже такие штуки как отказы страниц. У eBPF есть целый спектр захватывающих возможностей, которые при этом очень активно разрабатываются. Фичи, поддерживаемые в каждой конкретной версии ядра, перечислены в виде списка по этому адресу.

Недавно Apple подтвердила стратегическое партнерство с Google для интеграции ИИ Gemini в свои устройства.  Сегодня мы их опередим и поднимем свою LLM в Android-смартфоне. С блэкджеком и WebUI.

eBPF давно стал стандартным инструментом для работы с ядром, но на практике быстро выясняется: одна и та же программа может вести себя по-разному на соседних версиях Linux. Причина — в деталях, которые обычно остаются «под капотом»: структурах ядра, их смещениях и способе доступа к данным. В статье разбираемся, откуда берётся эта нестабильность, как работают механизмы вроде CO-RE и BTF и что на самом деле нужно учитывать, чтобы eBPF-код был переносимым и предсказуемым в разных окружениях.

Я посадил AI-агента на свой VPS и перестал открывать SSH. На сервере крутится дюжина Docker-контейнеров — клиентские проекты, SaaS, мониторинг, базы. Раньше любая мелочь требовала SSH: глянуть логи, рестартнуть контейнер, проверить место на диске.

Теперь я пишу в Telegram «память за 90%, разберись» — и через минуту получаю ответ: что случилось, что починил, сколько памяти сейчас.

В статье — реальные сценарии: SQL-запросы к PostgreSQL из Telegram, автодиагностика упавших сайтов, правка конфигов, мониторинг с авторестартом и управление задачами в YouTrack. Всё через кастомные shell-скрипты и AI-агент OpenClaw.

Привет, Хабр! Расскажу, как мы спасли крупный новостной сайт ugra-news.ru от постоянных падений — без покупки нового железа и переписывания с нуля. Только точечные оптимизации, знание архитектуры Битрикс и немного детективной работы. Приступим.

Однажды вечером, листая объявления на самом известном сайте, я наткнулся на курс по DevOps за слишком скромную стоимость. Я подумал, что, наверное, это будет сборник ссылок на YouTube и мотивирующих цитат. Но нет. По описанию оказалось, что автор предлагает своего рода методичку — как с нуля вкатиться.

Отзывов на профиле нифига, решил от скуки написать автору. На первый взгляд всё оказалось прозрачно. Он расписал пример того, как устроен один из блоков. Подумал немного и получил заветный PDF-файлик.

Представьте себе классический кошмар системного администратора или SRE: три часа ночи, в управлении огромный кластер Greenplum на сотню сегмент-хостов, и вам нужно запустить тяжелый ETL-процесс или проверить доступность gpfdist строго одновременно на всех узлах.

Вы начинаете перебирать инструменты. Стандартный Cron? Он локальный, замучаешься синхронизировать конфиги. Ansible или SaltStack? Хороши, но требуют центрального «мастера» и стабильного SSH-соединения в момент старта. А если в дата-центре «моргнула» сеть и часть сегментов оказалась изолирована? Команда просто не дойдет.

Я решил, что миру нужен инструмент, который ведет себя как «умный почтовый ящик»: вы закидываете в него зашифрованную команду, а она сама расползается по всей сети и ждет своего часа, чтобы «выстрелить» точно в срок. Так появилась Gorgona.

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

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

Когда ваше приложение состоит из нескольких сервисов, например бэкенда, БД и кэша, невольно возникает вопрос — а как гарантировать, что они запустятся в правильно порядке и вообще увидят друг друга? В Docker это решается с помощью depends_on, тут ничего нового. А вот в Podman подход немного другой. Ну кто бы сомневался!

Привет! Меня зовут Данил, я разрабатываю прикладное ПО для радиочастотных систем YADRO. В этой статье я расскажу об одном из вариантов сбора данных AXI-Stream для обработки на CPU, рассмотрю в этом контексте возможности и требования блока AXI DMA, а напоследок порассуждаю о когерентности кешей и о том, что на самом деле здесь требуется от драйвера ядра.

В последнее время мне захотелось вернуться к проекту игровой консоли. Правда, он забуксовал, но ничего страшного: это долгоиграющий проект, и буду его разбирать по чуть-чуть. А вернулся к нему всё потому, что захотелось программировать. Потом я стал размышлять, что необязательно делать свою консоль — можно достать готовую. И везде я слышал упоминания про ретро-консоли, а у меня такой не было! Выбрал для себя Anbernic RG35XX Pro и заказал.

В этой статье будет небольшой обзор и впечатления от этой приставки. Но больше всего меня интересовал вопрос: допустим, я разрабатываю игры — могу ли я использовать ретро-консоль для моих нужд? Как легко запустить мою игру на ней? Может быть, игровые движки поддерживают опцию экспорта для таких консолей? И похожие вопросы — в основном из-за непонимания того, как это происходит.

Всё будет рассмотрено на примере PortMaster и написания Hello World на C/C++ (SDL2, SDL3, raylib), но также поговорим про Unity, Godot и HTML5 (Phaser).

«Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?» — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы. 

Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл. 

Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование. 

Если к этому добавить разнородный парк, где рядом с Ubuntu живут динозавры на AIX и Solaris, путаница приобретает глобальный характер. 

Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку. 

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

В инфраструктурных проектах цена ошибки может измеряться миллионами и репутацией компании. Но практика показывает: поиск виноватых редко помогает избежать повторения проблем, гораздо эффективнее работает культура постмортем-разборов — честный анализ инцидентов без наказаний, который превращает ошибки в системные улучшения.

В инфраструктурных проектах цена ошибки редко бывает символической. Это может быть простой систем, финансовые потери, штрафы, иногда репутационные риски для клиента и подрядчика. В такой среде логично ожидать жесткой культуры поиска виноватых. Но практика показывает обратное: чем сложнее технологическая среда, тем бесполезнее модель «найти виновного и наказать». Она не снижает количество ошибок. Иногда она даже увеличивает их. За годы работы в инфраструктурных проектах я убедился, что единственный способ реально повышать качество, это культура разбора ошибок без наказаний. В инженерной среде это часто называют постмортем.

Почему поиск виноватых не работает

В ИТ есть старая поговорка: «Быстро поднятое не считается упавшим». Почти каждый инженер слышал её ещё в начале карьеры. В этой фразе есть важный инженерный принцип: в момент инцидента главная задача — не выяснять, кто виноват, а максимально быстро восстановить систему.

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

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

Набрав в поиске "VDS в Германии аренда" я с удивлением обнаружил, что арендовать такой сервер можно с российской карты и за вполне вменяемые деньги. Арендовав сервер на неделю, я принялся поднимать собственный MTProto для телеги. Использовал я образ https://github.com/telemt/telemt

Я поднял свой контейнер с прокси, проверил, что все работает и обрадовался. Но сразу же встал следующий вопрос - CLI это хорошо, но хотелось бы какой-то GUI для управления прокси. Я перепробовал несколько панелей и остановился на https://github.com/MaksimTMB/mtg-adminpanel. её суть в том, что панель можно установить на любой сервер или вообще локально, а на сервер, где будет развернут прокси ставится агент, который будет выполнять команды панели. Такое решение мне понравилось, так как в будущем можно будет расширить сеть до нескольких узлов, во избежание тотальной блокировки.

Использовали Cloud DNS, всё работало штатно.

В марте 2026 года мы столкнулись с неприятной ситуацией: в облачном DNS, который использовался для одной из наших публичных зон, начался резкий всплеск публичных авторитетных DNS‑запросов, причём основную массу составляли ответы NXDOMAIN.

На практике это привело сразу к двум проблемам: