☕️ Полезная статья недавно вышла на Хабре: Как я написал свой клиент Miracast для шаринга экрана под Linux в 2026 году и погряз в войне за проприетарные байты!

В этой статье:
• Разбирается, как автор на Python собрал собственную Linux-утилиту FluxCast для трансляции экрана на Smart TV без HDMI-кабеля;
• Показываются реальные проблемы Miracast, DLNA, RTSP/RTP, GStreamer, Wayland, Wi-Fi Direct и совместимости с разными телевизорами;
• Рассказывается, как open-source проект вырос из CLI-скрипта в AppImage, AUR-пакет и утилиту, попавшую в ArchWiki.

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

📂 Напоминалка по типам файлов в Linux!

Например, символические ссылки (symlink) позволяют обращаться к файлам без их дублирования, а FIFO и сокеты используются для обмена данными между процессами.

На картинке — основные типы: обычные файлы, каталоги, символьные и блочные устройства, символические ссылки, FIFO, сокеты и специальные файловые системы.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Проверяем задержки сети в Linux через mtr!

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

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

Для таких случаев удобно использовать mtr — инструмент, который объединяет возможности ping и traceroute и позволяет увидеть, где именно начинается деградация. Запуск:

mtr api.example.com

MTR показывает маршрут до узла и статистику по каждому промежуточному хопу: задержку, количество отправленных пакетов и возможные потери ответов.

Для длительного тестирования удобно использовать:

mtr -rwbc 100 api.example.com

Параметры:
-r — вывести итоговый отчёт и завершить выполнение; -w — расширенный формат вывода; -b — показывать IP-адреса вместе с именами узлов; -c 100 — отправить 100 пакетов.

Для больших маршрутов иногда удобнее отключить DNS-резолвинг:

mtr -n api.example.com

Сохранить результат для дальнейшего анализа:

mtr -rwbc 100 api.example.com > mtr-report.txt

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

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

Для проверки конкретного TCP-сервиса можно использовать:

mtr -T -P 443 api.example.com

В этом режиме MTR использует TCP SYN probes вместо ICMP, что ближе к проверке реального пути для сервисов вроде HTTPS, SSH или API. Примеры:

# HTTPS
mtr -T -P 443 api.example.com

# SSH
mtr -T -P 22 server.example.com

Но важно понимать: TCP MTR проверяет сетевую доступность и транспортный уровень. Он не покажет проблемы внутри TLS, HTTP или самого приложения. Полезно сравнивать разные направления:

mtr -T -P 443 server-a.example.com
mtr -T -P 443 server-b.example.com

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

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

🚪 Linux Ready | #практика

📂 Напоминалка по типам IPv6-адресов!

Например, Global Unicast используется для глобальной маршрутизации, Link-Local — для связи внутри локального сегмента, а Multicast заменяет broadcast и позволяет отправлять данные группе устройств.

На картинке — основные типы IPv6-адресов, их префиксы, назначение и примеры использования.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Управляем ресурсами процессов через cgroups v2!

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

Для управления ресурсами в Linux используется механизм control groups (cgroups). Он позволяет ядру учитывать и ограничивать потребление CPU, памяти, дискового ввода-вывода и количество задач, включая процессы и потоки.

В большинстве современных дистрибутивов по умолчанию используется cgroups v2. Проверить это можно командой:

findmnt -t cgroup2

или:

stat -fc %T /sys/fs/cgroup

Если используется cgroups v2, в последнем случае будет получен вывод:

cgroup2fs

В системах с systemd процессы сервисов автоматически размещаются в отдельных cgroups, поэтому ограничения ресурсов обычно задаются средствами systemd.

Например, ограничить объём памяти для сервиса можно следующим образом:

systemctl set-property nginx.service MemoryMax=1G

После применения параметра systemd устанавливает соответствующее ограничение для cgroup сервиса. При достижении лимита ядро сначала пытается освободить память, а если это невозможно, OOM-механизм memory cgroup может завершить один или несколько процессов.

Следует учитывать, что MemoryMax ограничивает не только анонимную память приложения, но и учитываемый page cache. Проверить текущие значения можно командой:

systemctl show nginx.service -p MemoryCurrent -p MemoryMax

Для анализа текущего потребления ресурсов удобно использовать:

systemd-cgtop

Утилита отображает активные cgroups, текущее использование CPU и памяти, объём ввода-вывода и количество задач, что позволяет быстро определить сервис, создающий основную нагрузку.

Ограничение использования процессора задаётся аналогичным образом:

systemctl set-property worker.service CPUQuota=50%

Значение CPUQuota=50% соответствует половине времени одного логического процессора, а CPUQuota=200% позволяет использовать до двух логических процессоров. Ограничение распространяется на суммарное использование CPU всеми процессами, входящими в cgroup сервиса.

Количество процессов и потоков можно ограничить следующим параметром:

systemctl set-property worker.service TasksMax=200

Это предотвращает неконтролируемое создание задач и снижает риск исчерпания системных ресурсов.

Постоянные ограничения удобно задавать через override-конфигурацию:

systemctl edit worker.service

Например:

[Service]
MemoryMax=2G
CPUQuota=200%
TasksMax=500

После изменения конфигурации сервис необходимо перезапустить:

systemctl restart worker.service

🔥 Механизм cgroups работает на уровне ядра и применяет ограничения к группе процессов независимо от языка программирования или способа запуска приложения. На основе cgroups v2 реализованы механизмы управления ресурсами в systemd и большинстве современных контейнерных платформ.

🚪 Linux Ready | #практика

✍️ Крайне информативная статья вышла на Хабре: «Ваш docker-compose.yml сломается: 5 настроек, которые все забывают»!

В этой статье:
• Разбираются пять важных настроек Docker Compose, которые стоит использовать в продакшене;
• Показывается, как правильно настроить лимиты ресурсов, restart policy, ротацию логов и healthcheck;
• Объясняется, почему резервное копирование volumes помогает избежать потери данных при сбоях и ошибках.

🔊 Продолжайте читать на Habr!

🚪 Linux Ready | #статья

В Linux можно запустить программу в изолированной среде без Docker и виртуальной машины!

Для тестирования скриптов, сборки проектов или проверки поведения программ часто создают контейнеры. Но иногда полноценный контейнерный стек просто не нужен.

Bubblewrap (bwrap) использует Linux namespaces и позволяет создавать минимальное sandbox-окружение одной командой. Во многих системах это работает без root (если разрешены user namespaces):

$ bwrap \
  --ro-bind /usr /usr \
  --ro-bind /bin /bin \
  --dev /dev \
  --proc /proc \
  --tmpfs /tmp \
  bash

Внутри этой оболочки процесс видит только те файлы и ресурсы, которые вы явно ему предоставили.

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

$ bwrap \
  --bind ./project /app \
  --chdir /app \
  bash

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

Можно запускать тестовые скрипты или проверять сборку без изменения основной системы:

$ bwrap \
  --ro-bind /usr /usr \
  --bind ./test-env /tmp \
  ./test.sh

Например, Flatpak использует Bubblewrap для изоляции приложений.

🔥 bwrap — это минимальный контейнерный инструмент без Docker: быстрый способ проверить программу в отдельном окружении и не засорять основную систему.

🚪 Linux Ready | #совет

📂 Напоминалка по Git для разработчиков!

Например, git add подготавливает изменения к коммиту, git commit фиксирует состояние проекта в истории, а git branch и git merge позволяют управлять ветками разработки.

На картинке — базовый набор Git-команд, необходимых для ежедневной работы в команде.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Анализ времени загрузки через systemd-analyze!

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

Первый этап анализа — общее время загрузки:

systemd-analyze

Пример вывода:

Startup finished in 4.2s (kernel) + 35.8s (userspace) = 40.0s

kernel показывает время загрузки ядра, а userspace — время запуска systemd, сервисов и пользовательского пространства. На некоторых системах дополнительно отображаются этапы firmware, loader и initrd.

Если основная задержка находится в userspace, дальнейший анализ выполняется через systemd юниты и их зависимости. Для поиска юнитов с длительной активацией используется:

systemd-analyze blame

Пример:

45.231s docker.service
32.814s NetworkManager-wait-online.service
18.502s nginx.service

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

Для анализа реальной цепочки зависимостей используется:

systemd-analyze critical-chain

Пример:

multi-user.target @40.012s
└─docker.service @35.421s +4.580s
  └─network-online.target @35.400s
    └─NetworkManager-wait-online.service @2.561s +32.814s

Символ @ показывает момент активации юнита, а + — продолжительность его запуска. Такой вывод позволяет определить, какой компонент находится в критической цепочке и задерживает достижение target.

Один из частых случаев — NetworkManager-wait-online.service, который ожидает готовности сети перед продолжением загрузки. На серверах без необходимости ждать полного поднятия сети он может увеличивать время старта, однако отключение этого сервиса требует проверки зависимостей от network-online.target.

Для визуального анализа процесса загрузки:

systemd-analyze plot > boot.svg

Файл boot.svg содержит временную диаграмму запуска юнитов и позволяет увидеть параллельные процессы, последовательные зависимости и точки задержек.

Для проверки конкретного сервиса:

systemctl status docker.service

Время запуска основного процесса можно получить командой:

systemctl show docker.service -p ExecMainStartTimestamp

А причины ошибок и тайм-аутов анализируются через журнал systemd:

journalctl -b -u docker.service

Для предыдущей загрузки:

journalctl -b -1 -u docker.service

Отключать сервисы только на основании systemd-analyze blame некорректно. Перед изменением конфигурации необходимо проверить назначение юнита, наличие зависимостей и сообщения в журнале.

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

🚪 Linux Ready | #практика

📂 Шпаргалка по команде less!

Например, less /var/log/syslog используется для постраничного просмотра больших файлов и системных журналов без загрузки всего содержимого в оперативную память.

На картинке основные возможности less: навигация (Space, b, g, G), поиск вперёд и назад (/, ?, n, N), просмотр обновляемых логов (F), переходы между файлами, отображение номеров строк и дополнительные параметры запуска.

Сохрани, чтобы использовать в работе!

🚪 Linux Ready | #ресурс

Диагностика производительности дисковой подсистемы с помощью iostat!

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

Например, сервис начинает отвечать значительно медленнее:

curl http://localhost:8080/api

При этом загрузка процессора остаётся на уровне 20–30%, память не испытывает дефицита, а процессы работают без ошибок. В такой ситуации стоит проверить состояние устройств хранения.

Для этого используется iostat из пакета sysstat. Утилита отображает статистику работы блочных устройств и помогает определить, связаны ли задержки с вводом-выводом. Запуск:

iostat -yxz 1

Ключ -y пропускает первый отчёт, содержащий статистику с момента загрузки системы, -x включает расширенную статистику, -z скрывает устройства без активности, а 1 задаёт интервал обновления в одну секунду. Пример:

Device      r/s    w/s   await   %util
sda         120     80    45.2     98.7

Наиболее полезные показатели: r/s и w/s — количество завершённых запросов чтения и записи в секунду, await — среднее время выполнения операций ввода-вывода, включая ожидание в очереди, %util — доля времени, в течение которого устройство было занято обработкой запросов.

Высокий await указывает на рост задержек ввода-вывода. Значение %util, близкое к 100%, говорит о высокой загрузке устройства, однако для современных SSD и NVMe эту метрику следует оценивать вместе с await, поскольку сама по себе она не всегда означает насыщение устройства.

Если наблюдается высокая нагрузка, следующий шаг — определить процесс, создающий её:

iotop

Для общей оценки состояния системы полезно также выполнить:

vmstat 1

Если одновременно растут значения await в iostat и wa в vmstat, это является сильным признаком того, что снижение производительности связано с ожиданием операций ввода-вывода. Однако для окончательных выводов результаты следует анализировать в контексте всей системы. Для анализа конкретного устройства:

iostat -yxz nvme0n1 1

Важно учитывать, что iostat показывает состояние устройств, но не источник нагрузки. На практике его обычно используют вместе с iotop, pidstat -d и vmstat.

🔥 iostat позволяет понять, имеются ли признаки проблем на уровне дисковой подсистемы и выбрать дальнейшее направление диагностики.

🚪 Linux Ready | #практика

📂 MySQL JOIN: шпаргалка по объединению таблиц!

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

На картинке — основные типы JOIN в MySQL с примерами SQL-запросов и визуальным объяснением.

Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс

Знали, что lsof уже не единственный и далеко не самый удобный способ искать открытые файловые дескрипторы?

В util-linux 2.40+ утилита lsfd поддерживает встроенный механизм фильтрации, поэтому не нужно строить длинные цепочки из grep и awk.

Например, найти процессы, которые всё ещё держат удалённые файлы:

lsfd -Q 'DELETED'

Или посмотреть только UNIX-сокеты:

lsfd -Q '(TYPE == "UNIX" || TYPE == "UNIX-STREAM")'

А если интересует конкретный процесс:

lsfd --pid 12345

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

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

🚪 Linux Ready | #совет

📂 Напоминалка по регулярным выражениям (Regex)!

Например, \d позволяет найти любые цифры, ^ и $ — проверить начало и конец строки, а (?=...) и (?<=...) помогают искать совпадения с учетом контекста без включения его в результат.

На картинке — основные возможности регулярных выражений: классы символов, квантификаторы, группы, диапазоны, якоря, экранирование спецсимволов, флаги, Unicode-свойства и lookaround-утверждения.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

😎 Awesome tmux — большая подборка ресурсов по tmux!

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

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Что происходит при вызове sync и зачем используются drop_caches?

Во время диагностики производительности или тестирования файловой системы нередко встречаются рекомендации выполнить:

sync
echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null

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

Когда приложение записывает данные в файл, они обычно не сразу попадают на устройство хранения. Ядро сначала размещает их в page cache, помечая соответствующие страницы как dirty. Это позволяет объединять множество небольших операций записи в более крупные и снижать количество обращений к диску.

Проверить объём таких страниц можно командой:

grep -E "Dirty|Writeback" /proc/meminfo

Пример:

Dirty:             18432 kB
Writeback:             0 kB

Значение Dirty показывает объём данных, ожидающих записи, а Writeback — объём страниц, которые в данный момент уже записываются фоновыми потоками ядра.

Команда:

sync

не очищает page cache и не освобождает память. Она инициирует запись всех изменённых страниц и метаданных файловой системы в нижележащее хранилище и завершается после окончания этих операций. Итоговые гарантии сохранности данных зависят от файловой системы, устройства хранения и его политики кэширования.

Если в системе в этот момент нет новых операций записи, после выполнения sync значение Dirty обычно становится близким к нулю.

Команда:

echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null

работает иначе. Она освобождает объекты, которые ядро может безопасно восстановить при необходимости. Значение 1 очищает page cache, 2 — кэш dentry и inode, а 3 очищает оба типа кэша одновременно.

Поэтому на практике сначала выполняют:

sync

а затем:

echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null

Без предварительного sync часть страниц может оставаться изменённой (dirty), и ядро не сможет освободить их до завершения записи.

Проверить эффект можно с помощью:

grep -E "Cached|Buffers|SReclaimable|MemAvailable" /proc/meminfo

или:

free -h

При этом важно понимать, что уменьшение значения Cached не означает сопоставимого увеличения MemAvailable. Page cache и без принудительной очистки автоматически освобождается ядром при возникновении нехватки памяти и является частью нормальной работы Linux.

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

🔥 sync обеспечивает синхронизацию накопленных изменений с устройством хранения, а drop_caches освобождает восстанавливаемые структуры памяти. Эти механизмы предназначены для диагностики и тестирования, а не для регулярной оптимизации работы системы.

🚪 Linux Ready | #практика

🐱 Вышла интересная статья на Хабре: «Что такое LiteLLM и для чего его едят»!

В этой статье:
• Разбирается, как с помощью LiteLLM объединить работу со 100+ LLM-провайдерами через единый OpenAI-совместимый API;
• Показывается настройка LiteLLM в Docker, подключение разных моделей, fallback-механизмы, кэширование запросов и встроенный веб-интерфейс;
• Объясняется, как упростить интеграцию ИИ в проекты, избежать привязки к одному провайдеру и снизить расходы на использование моделей.

🔊 Продолжайте читать на Habr!

🚪 Linux Ready | #статья