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

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

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

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

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

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

В мире текстовых терминалов для этих задач часто выбирают Htop. Он предельно прост, работает в режиме Text-based User Interface (TUI) и есть в репозиториях всех популярных ОС из семейства Unix-like.

Htop позволяет наблюдать только за CPU, памятью, процессами и операциями ввода-вывода. И это его минус — больше ничего просто нет…

Более широким профилем обладает Btop. Он имеет всё тот же форм-фактор интерактивного TUI и уже есть в большом количестве стандартных репозиториев.

Btop позволяет, окромя возможностей Htop, следить за температурой CPU, получать детализированную информацию с графиками по процессу, точкам монтирования и сетевым интерфейсам. Кроме этого, он поддерживает темы и настройку расположения панелей по вкусу прямо на лету.

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

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

Недавно, перебирая хлам скопившийся на пыльных антресолях, я обнаружил старенький MacBook 2,1 (A1181) образца 2008 года выпуска. Этот MacBook мне на день рождения, который состоялся более 15-ти лет назад, подарила супруга. Большим ценителем яблочной продукции я так и не стал, но некоторое время использовал эту машинку в качестве второй — для чтения почты или просмотра ютуба, брал с собой в туристические поездки. Мне нравился дизайн корпуса и клавиатуры этой машинки, местами даже где-то меня привлекала операционная система MacOS X являющаяся родственником FreeBSD. Но сейчас не об этом. В те времена вычислительная техника персонального применения стремительно устаревала — появлялись процессоры с всё большим числом ядер и большей тактовой частотой, состоялся полный переход от 32-битных архитектур к 64-х битным и т. д. Всё это сильно расслабило разработчиков и, как следствие, требования софта к железу выросли просто непомерно. Таким образом, данная машинка очень быстро «морально устарела». Я пару раз проводил апгрейд — сначала добавил немного SDRAM, потом заменил HDD на SSD, несколько раз апгрейдил MacOS X. Но к 2012 году машинка всё равно стала мало пригодной для работы и отправилась на антресоли.

Недавно я установил Linux на свой основной десктопный компьютер и рабочий ноутбук, полностью перезаписав раздел Windows. По сути, я удалил главную операционную систему с двух компьютеров, которыми пользуюсь чаще всего, доверив все свои личные и рабочие потребности сообществу опенсорса. Эта тенденция набирает популярность, и я присоединился к общему ажиотажу, но по веским причинам. Некоторые из этих причин могут отозваться в вас и убедить наконец-то тоже совершить этот переход.

Однажды администратор одного из внутренних сайтов предприятия попросил прописать TXT запись для получения Let's Encrypt сертификата, поскольку сайт не доступен снаружи и, нет возможности настроить проверку HTTP-01. Через три месяца попросил прописать еще раз, для продления, потом появился второй такой сайт, и, стало очевидно, что процесс пора автоматизировать.

Linux Mint — один из тех проектов, которые пережили практически всё, что только можно было в мире Linux-дистрибутивов. Он видел взлет и падение KDE 4 с его радикальными изменениями, приход GNOME 3, который перевернул привычный рабочий стол с ног на голову, бесконечные споры вокруг Unity, первые шаги Wayland и даже нынешнюю моду на immutable-системы с их атомарными обновлениями. А сам Mint все это время оставался верен своей идее: дать пользователям предсказуемый, удобный интерфейс, который не нужно переучивать каждые полгода и он просто работает.

В середине января 2026-го вышел Mint 22.3 — очередной релиз в LTS-ветке на базе Ubuntu 24.04. Поддержка обещана до 2029 года, ядро по-прежнему Linux 6.14, а окружения рабочего стола — те же проверенные Cinnamon, MATE и Xfce. Никаких революций и обязательных переходов на новые протоколы дисплея. Зато множество мелких, но осмысленных улучшений, которые делают повседневную работу чуть комфортнее. И именно в этом подходе вся суть проекта. Давайте оценим новинку.

Для пользователя может показаться, что переход с HTTP/2 на HTTP/3 — это просто замена TCP на UDP в конфиге. Но для серверного ПО с многопроцессной архитектурой этот шаг превращается в настоящую «головную боль». Классическая схема с accept(), на которой годами строилась работа с TCP‑соединениями, в мире QUIC попросту не существует. Пакеты летят в UDP‑порт, и ядро ОС больше не знает, какому именно рабочему процессу их отдать.

В оригинальном nginx это привело к тому, что поддержка HTTP/3 уже долгое время остается «экспериментальной» и ограниченной: она страдает от проблем с обрывами сессий и деградации сервиса при обновлении конфигурации. Для многих это стало стоп‑фактором для внедрения протокола в реальный продакшен.

eBPF давно перестал быть узкоспециализированной игрушкой для kernel-энтузиастов и исследователей внутренностей Linux. Сегодня с ним, так или иначе, сталкиваются не только SRE, но вообще все, кто разрабатывает системы, близкие к сети, производительности или безопасности: от авторов сетевых плагинов (CNI) и прокси, до разработчиков кастомных агентских решений, observability-инструментов и low-level инфраструктурных компонентов. Даже если вы никогда не писали eBPF-код руками, есть хороший шанс, что он уже работает в вашей системе — тихо, незаметно и с довольно широкими полномочиями.

Чаще всего eBPF проявляется через удобные CLI, библиотеки и дашборды: установили агент, включили, и внезапно система знает о происходящем больше, чем strace, tcpdump и половина метрик вместе взятых. Но за этим комфортом скрывается нетривиальный механизм исполнения пользовательского кода прямо внутри ядра Linux — с жёсткими правилами валидации, ограниченной моделью исполнения и целым набором архитектурных компромиссов, о которых обычно не принято говорить в маркетинговых описаниях.