/usr/bin

Для меня файловый менеджер FAR — это настоящий центр компьютерной вселенной. Это та самая программа, которую я запускаю сразу после загрузки операционной системы. Это то самое приложение, которое у меня всегда открыто, что бы я ни делал, какие бы задачи ни решал. За много лет мой FAR превратился в привычный инструмент, который так удобно ложится в руку, что тут же становится её естественным продолжением.

FAR — это тихая надёжная гавань, в которой я могу отдохнуть от пёстрых окон, разноцветных иконок и безумных графических интерфейсов. Это то место, откуда начинаются все мои цифровые экспедиции, где хранятся все мои привычные инструменты и находятся дверцы во все мои заветные сокровищницы знаний.

В статье я рассказываю, как из набора команд (free, df, ip, ps, uptime) собрать CLI‑утилиту на Bash, добавить аргументы, цветовую индикацию и упаковать всё в AUR как пакет system-monitor

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

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

/dev/random предоставляет случайный поток байт, генерируемый ядром при помощи энтропии созданной пользователем, при вводе с клавиатуры и использования мыши. Это конечный источник энтропии, то есть данные в потоке могу закончиться, если он закончился, нужно просто начать вводить с клавиатуры данные и двигать мышью.
В свою очередь /dev/urandom - бесконечный источник псевдослучайных байт, так как использует CSPRNG на базе /dev/random.

Теперь Postgresus — это Databasus. И поддерживает другие базы: MySQL, MariaDB и MongoDB (при этом оставляя основной фокус на PostgreSQL).

С официальным прекращением поддержки Ingress NGINX, запланированным на март 2026 года, пользователи Kubernetes сталкиваются с серьёзным архитектурным изменением. Это прекращение поддержки знаменует собой прекращение выпуска обновлений безопасности и исправлений ошибок, поэтому командам разработчиков крайне важно оценить планы миграции уже сейчас.

Один из самых простых и удобных в обслуживании путей — переход от традиционных ресурсов Ingress к Gateway API, современному стандарту сетевого взаимодействия в Kubernetes. Для упрощения этого процесса сообщество Kubernetes SIG Network предоставляет инструмент ingress2gateway с открытым исходным кодом, который автоматически преобразует объекты Ingress в ресурсы Gateway API.

Наш API был медленным. Не сломанным — просто медленным.

Таким медленным, из-за которого пользователи обновляют страницу. Таким, из-за которого телефон кажется старым. У нас была задержка 200 мс на эндпоинтах, которые должны были отвечать за 40 мс. Каждая оптимизация, которую мы пробовали, делала всё только хуже. Затем я удалил большую часть нашей конфигурации Kubernetes. Задержка снизилась до 35 мс.

Иногда самые опасные угрозы — это не атаки методом перебора или уязвимости нулевого дня. Это тихие, настойчивые точки закрепления, скрывающиеся из виду. Однажды я обнаружил reverse shell, незаметно работавший под пользователем www-data на моем веб-сервере Ubuntu. Вот как я ее обнаружил — и какие именно шаги предпринял для ее удаления.

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

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

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

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

В прошлом году текст «Два года Angie», кажется, вам понравился. В нем мы более-менее подробно писали о том, как именно создавалась компания Angie Software, почему вообще мы стартовали с опенсорса, какую роль в появлении Angie сыграли китайские товарищи, и как мы, сообразив, что заработать на опенсорс проекте мы не можем, стремительно переобулись в сторону производства целой линейки продуктов. Ну и еще немного плевались в сторону F5, которая вымарала наших коллег из истории Nginx. Кому интересно, как все начиналось, почитайте.

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

При анализе артефактов с Linux систем journal являются источником огромного количества полезной информации. Из журналов можно достать:

🚀 название машины;

🚀 идентификатор события;

🚀 тип события;

🚀 критичность события;

🚀 сообщение;

🚀 объект породивший событие;

🚀 и многое другое.

Существует множество утилит которые позволяют парсить журналы:

🚀 встроенный во многие дистрибутивы linux journalctl;

🚀 кроссплатформенный go-journalctl от Velocidex;

🚀 библиотека go-systemd;

🚀 и т.д.

Однако, у всех этих утилит есть свои минусы. Так go-systemd и journalctl не имеют встроенной кроссплатформенности, а go-journalctl не может парсить все файлы находящиеся в директории рекурсивно.