Serge Bobrovsky 

От драйвера до пикселей на экране.

Kernel layer: от DRM (Direct Rendering Manager) к KMS (Kernel Mode Setting)

DDX layer: xf86-video-* для X11 или mesa + libgl для прямого рендеринга

Display server/protocol layer: X11 (Xorg с DDX-драйверами) vs Wayland (композитор сам себе сервер)

Compositing layer: Picom (X11) или встроенный композитор (Wayland)

Session layer: Display Manager (GDM/SDDM) - WM/DE - приложения

В Ubuntu это всё «настройки дисплея».

В Arch вы выбираете например X11 с i3-gaps + picom или Wayland с sway/Hyprland, причём второй не работает с проприетарными драйверами NVIDIA без танцев с nvidia_drm.modeset=1 ...

Это классический клиент-серверный протокол.

X Server -- это программа, которая имеет монопольный доступ к видеокарте. Приложения говорят ей: "Нарисуй мне окно 500x500", сервер рисует и отправляет события обратно.

Минусы:

Любое приложение может прочитать ввод с клавиатуры любого другого окна.

При падении X Server падают все графические приложения.

Мониторы с разной частотой обновления (60 Гц + 144 Гц) работают плохо (тряска).

HDR и HiDPI -- костыли, работают через раз.

Каждое действие проходит длинный путь (App - X Server - GPU).

Это протокол, а не программа. "Композитор" (например, KWin, Mutter, Sway, Hyprland) сам является сервером. Приложение говорит композитору напрямую: «Дай мне участок памяти (buffer), я сам туда нарисую», композитор просто собирает эти буферы и отправляет на экран.

Почему круто:

Приложение не видит ввод других окон.

Путь короткий (App - Compositor - GPU).

Каждое окно рендерится с собственной частотой.

Нет разрывов по определению (если приложение не просит explicit sync).

Почему это уровень стека, а не просто галочка? В большинстве ОС (Windows, macOS, Ubuntu) выбор протокола скрыт от пользователя. А в Arch вы выбираете это сознательно! :)

Вы не ставите «видеодрайвер» и радуетесь, вы выбираете стек:

sudo pacman -S sway wayland libinput mesa

Firmware layer: UEFI (vs legacy BIOS), поиск bootx64.efi

Bootloader layer: systemd-boot/GRUB/EFISTUB - загрузка vmlinuz-linux и initramfs-linux.img

Initramfs layer: ранний userspace с хуками (udev, keyboard, encrypt) - монтирование настоящего root

Init layer: переход к systemd (PID 1) и default.target

В обычных линуксах вы просто смотрите на логотип. В Arch вы правите mkinitcpio.conf, пересобираете initramfs и настраиваете systemd-boot entry вручную :)
p.s. ну или так )
grub-install --target=x86_64-efi --efi-directory=/boot

Сериал "Дзен и искусство ухода за Arch Linux".

Я немного расскажу о моём любимом дистрибутиве линукса, но без тесной привязки к нему; всё это конечно во многом относится к любому другому Линуксу в целом.

Arch Linux просто особенно хорош в том, что вам приходится разбираться вручную во многих низкоуровневых вещах, и это наверное самый лучший способ изучения данной ОС. Интерес к тому, как всё устроено "внутри" -- двигатель успешной инженерной карьеры!

Вы не просто нажимаете Install, вы разбиваете диски на разделы, управляете ядром и настраиваете display protocols. За одну неделю работы с Arch вы узнаете о том, как на самом деле работает компьютер и Linux, больше, чем за три года использования macOS.

1. Устанавливая Arch, вы реально начинаете разбираться в stack layers.

physical layer / partition layer / volume management / filesystem layer / mount layer.

в Arch вы ручками создаёте каждый слой:)

gdisk - cryptsetup - lvm - mkfs.ext4 - mount

Если вы плотно поработаете с Линуксом в течение месяца, я гарантирую, что вы никогда не вернётесь к другой ОС.

Если же вы захотите вернуться через месяц к другой ОС, то это только потому, что вы

a) недостаточно разбираетесь в компьютерах,

b) не потратили достаточно времени на то, чтобы ваша машина работала идеально для вас.

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

Моя любимая часть взаимодействия с (Arch) Линуксом, помимо регулярной многочасовой настройки, заключается в том, что я вообще не забочусь о своей машине: она потеряна? сломалась? украдена? Я получаю новую машину, запускаю 1 команду, и всё возвращается в точно такую же ситуацию, как я её оставил!!1

Прекрасное:
Rust на bare-metal

- Writing firmware for microcontrollers
- Writing bootloader / kernel code for application processors

и т.д.

+ сам курс Rust классный от команды Google Android

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

Единственный стабильный ABI на Linux -- это Windows Wine, и в 2026-м ситуация превратилесь в практическую инженерную стратегию.

Смешное: Win32 (через Wine) -- это единственный стабильный ABI на Linux, автор написал в 2022-м. Потому что бинарная совместимость Windows сохраняется десятилетиями, в то время как экосистема Linux (даже в одной библиотеке) может произвольно измениться.

В Glibc 2.36 тогда удалили старый стандарт хеширования символов DT_HASH ("костыль" 16-летней давности, но документированный!), оставив только новый GNU_HASH, что сломало кучу программ и игр (особенно использующих Easy Anti-Cheat), которые были жестко завязаны на старый стандарт.

Со временем  некоторые дистрибутивы для некоторых библиотек вернули DT_HASH, а разработчики игр обновили античиты, но выпуск native-версии под Linux остается рискованным, так как системные библиотеки могут обновляться непредсказуемо.

Сгодня идея автора стала реальностью! В январе 2026-го вышел революционный Wine 11:

1. Больше не нужны 32-битные библиотеки. Новая архитектура WoW64 позволяет запускать старые 32-битные игры на чистых 64-битных системах без установки кучи 32-битных драйверов и библиотек

2. Добавлена NTSYNC -- поддержка нативной синхронизации с ядром
Linux, что в некоторых играх дает прирост производительности до 50% по сравнению с запуском в нативной Винде!

Резюме: установка родной Windows-версии игры через Proton, встроенный в Steam, часто работает "из коробки" лучше, чем нативная Linux-версия, выпущенная 5 лет назад и теперь не запускающаяся из-за устаревших зависимостей.

Ну и Steam Deck (который на базе Linux) как бы намекает :)

 
Вдобавок в конце 2025-го вышел

Полностью завершена техническая работа над стандартом C++26.

"Большая четвёрка" ключевых нововведений C++26:

Reflection -- крупнейшее улучшение со времен появления темплейтов!  Позволяет коду "видеть" и генерировать себя на этапе компиляции.

Memory Safety -- существенное повышение безопасности при перекомпиляции кода в C++26.
Чтение неинициализированных локальных переменных больше не вызывает UB. Стандартная библиотека получила hardened версию с проверками границ (уже
протестирована Google и Apple на сотнях миллионов строк кода, оверхед ~0.3%).

Contracts -- языковая поддержка предусловий, постусловий и contract_assert для функциональной безопасности (принята, несмотря на технические разногласия).

td::execution (Sender/Receiver) -- унифицированная асинхронная модель
для управления конкурентностью и параллелизмом.

Говорят, что GCC и Clang уже реализовали 2/3 возможностей,
включая рефлексию и контракты.

График трехлетнего цикла разработки C++29 утверждён, основной фокус -- дальнейшее повышение безопасности памяти и работа над profiles для контроля безопасности кода (в стиле WebKit).