Недавно, перебирая хлам скопившийся на пыльных антресолях, я обнаружил старенький 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 — с жёсткими правилами валидации, ограниченной моделью исполнения и целым набором архитектурных компромиссов, о которых обычно не принято говорить в маркетинговых описаниях.

Что такое BootMii
На просторах Сети можно найти много разных образов Linux под этот аппарат. Все они в большинстве своем базируются на старых ядрах, что обусловлено весьма скромными техническими характеристиками Wii. Их объединяет способ запуска — они завязаны на такую штуку, как BootMii. Это небольшой кусок кода, который изначально был разработан вовсе не для запуска сторонних ОС, а чтобы в случае чего дать возможность выполнить аварийное восстановление консоли.

Важно понимать: Wii чем-то похожа на обычный компьютер, но в реальности тут нет ни BIOS, ни UEFI. Если вдруг в процессе исследования что-то пойдет не так, то система просто превратится в бесполезный кирпич без адекватных возможностей восстановления. BootMii был создан как раз на этот случай — он работает максимально близко к «нулевому уровню» загрузки и может легко снять точный побитовый слепок текущего состояния NAND-флешки.

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

Защитить систему от особенно прожорливого процесса

Обеспечить справедливое распределение ресурсов между несколькими приложениями

Проверять производительность приложения при ограниченных ресурсах

Гарантировать доступность ресурсов в мультиарендных средах

Мы начнём с создания, настройки и добавления процесса в cgroup самым базовым (и трудоёмким) способом, напрямую работая с виртуальной файловой системой cgroupfs. Затем посмотрим, как сделать ровно то же самое с помощью более высокоуровневых инструментов вроде cgcreate и cgexec из libcgroup или systemd-run и slice-юнитов в systemd.

Начало 2026 года для сообщества ядра Linux получилось насыщенным. В конце января в документацию добавили раздел Linux kernel project continuity. В нем описывается, что произойдет, если ключевые участники проекта внезапно не смогут выполнять свою работу. Обсуждения шли еще на Maintainers Summit в декабре 2025-го, и теперь этот вопрос зафиксирован в документации в явном виде.

Все вполне логично. Ядро Linux давно превратилось в часть огромной мировой инфраструктуры — с десятками миллионов строк кода, тысячами разработчиков из компаний по всему миру и постоянным давлением со стороны требований к производительности, безопасности и энергоэффективности. Поэтому сообщество вынуждено не только поддерживать текущий уровень стабильности, но и экспериментировать, стараться сделать систему гибче и надежнее. В 2026 году проявились несколько направлений такой работы — от Rust и планировщиков до поддержки новых архитектур.

Часто в учебной литературе по Linux приведены скучные и неинтересные примеры написания модулей ядра. Я решил исправить этот пробел и показать, что разработка небольшого модуля — это задача под силу многим, если понимаешь принципы разработки программ.

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