Arch Linux и Fedora Linux: баги, несовместимости и системные различия (2024–2025)

Проблемы с Waydroid на Arch vs Fedora

Arch Linux: Установка и работа Waydroid (аналог Anbox для запуска Android) на Arch часто сопряжена с дополнительными шагами и неполадками. Исторически, основной проблемой было отсутствие необходимых модулей ядра (binder) в стандартном ядре Arch. Пользователям приходилось либо переходить на ядро linux-zen, либо устанавливать пакет-драйвер из AUR (например, anbox-modules-dkms). Это усложняло настройку, тем более что DKMS-модули могли перестать компилироваться после обновления ядра Arch. Даже после включения binder-модулей в штатные ядра Arch, возникали баги интеграции. 

Один из свежих примеров (январь 2025) – Waydroid ожидает устройство /dev/binder, тогда как служба waydroid-container на Arch создает binder-устройства с префиксом /dev/anbox-*, из-за чего Waydroid “не видит” binder и не запускается. Также на Arch нужно осторожно подходить к образам Android: сообщество отмечает, что установка Waydroid-образов через AUR может приводить к сбоям, поэтому в Arch Wiki прямо не рекомендуется использовать сторонние пакеты-образы из AUR (лучше позволить waydroid init самостоятельно скачать образ). Все это означает, что на Arch запуск Waydroid требует большего вмешательства пользователя и подвержен поломкам при обновлениях.

В Fedora Waydroid, как правило, работает из коробки при соблюдении официальной инструкции. Начиная с версии 35, разработчики включили необходимые возможности в штатное ядро (все нужные binder-драйверы были активированы в ядре 5.15 и новее). Благодаря этому не требуется установка кастомных ядер или DKMS-модулей — достаточно скачать Waydroid и установить пакет. Пользователи отмечают, что Waydroid в Fedora запускается проще и "просто работает", поскольку ядро дистрибутива изначально готово для запуска Android-контейнера. 

Таким образом, многие проблемы Arch (ручная установка binder-модулей, конфликты имён устройств и т.д.) в Fedora отсутствуют. SELinux может потребовать дополнительной настройки, но в официальной документации COPR уже учтены необходимые политики. В целом, Fedora предлагает более стабильный и готовый к работе опыт с Waydroid — с минимумом ручных правок и сбоев, которые часто беспокоят пользователей Arch.

Поддержка файловых систем: NTFS3 (Arch) vs NTFS-3G (Fedora)

Различие в драйверах: Arch Linux с конца 2021 года перешёл на новый встроенный драйвер NTFS3 (от Paragon) из ядра 5.15+, позволяющий читать/писать NTFS-разделы напрямую через ядро. В Fedora же по умолчанию до сих пор используется проверенный временем FUSE-драйвер ntfs-3g, работающий в пространстве пользователя. Arch рассматривает ntfs-3g как устаревший вариант (пакет есть в репозитории, но не устанавливается базово) – если ntfs-3g не установлен, утилиты монтирования на Arch автоматически используют модуль ntfs3 ядра. Fedora 38/39/40, напротив, продолжала монтировать NTFS через ntfs-3g, считая его более безопасным по умолчанию. В сообществе отмечают, что ntfs-3g остаётся «надёжным вариантом», тогда как новый ntfs3 хоть и быстрее, но ещё не безупречен. Например, udisks в Linux предпочитает ntfs-3g, если он присутствует, поскольку FUSE-драйвер лучше отлажен и менее рискован.

Влияние на внешние диски: Разница драйверов особенно заметна при работе с внешними NTFS-носителями. Kernel-драйвер ntfs3 в Arch строже относится к состоянию тома: он откажется монтировать NTFS-раздел, если тот помечен как “dirty” (т.е. Windows не был корректно завершён или есть ошибки файловой системы). В таких случаях при попытке монтирования в Arch вы получите ошибку “wrong fs type, bad superblock… or other error”. Пользователю приходится вручную исправлять том: либо запустить Windows и сделать chkdsk, либо на свой страх и риск очистить флаг грязного тома утилитой ntfsfix -d. Только после этого ntfs3 смонтирует раздел. В Fedora же, использующей ntfs-3g, поведение несколько иное. Ntfs-3g тоже не монтирует грязный NTFS на запись, но может смонтировать его в режиме чтения либо сообщить об ошибке с советом запустить ntfsfix. Кроме того, Fedora изначально устанавливает ntfs-3g, поэтому у пользователя меньше сюрпризов – том просто смонтируется (или выдаст запрос на проверку) через знакомый fuse-драйвер.

Надёжность и производительность: Преимущество ntfs3 – более высокая скорость работы с диском (благодаря работе в ядре и поддержке кеширования). Однако в 2024 году многие дистрибутивы (Debian, RHEL и др.) всё ещё осторожничают с включением ntfs3 по умолчанию, указывая на возможные баги. На форумах Arch обсуждались случаи, когда при заполнении NTFS-раздела >70% возникали ошибки ввода-вывода и даже порча каталогов – некоторые пользователи винят в этом драйвер ntfs3. Также сообщается о несовместимости реализаций символических ссылок в ntfs3 и ntfs-3g: ссылки, созданные одним драйвером, могут не распознаваться другим. 

Fedora, оставаясь на ntfs-3g, избегает этих потенциальных проблем ценой более низкой скорости и повышенного потребления CPU в операциях записи. В случае возникновения ошибок на NTFS, Fedora (с ntfs-3g) позволяет воспользоваться утилитой ntfsfix напрямую. Arch при использовании ntfs3 фактически полностью полагается на Windows для исправления сложных ошибок на разделе – kernel-драйвер не умеет выполнять полноценное восстановление, и при сбоях или повреждениях пользователю придётся подключать диск к системе Windows для запуска chkdk. Многие пользователи Arch в итоге устанавливают пакет ntfs-3g и монтируют проблемные диски через него, особенно если диск регулярно используется в dual-boot с Windows.

Вывод: Arch Linux предлагает более новый и быстрый NTFS-драйвер (ntfs3), но он требовательнее к корректности тома и имел ряд сырых углов в первые годы выпуска (есть риск столкнуться с редкими багами). Fedora выбирает более консервативный подход: старый ntfs-3g, обеспечивающий максимальную совместимость и предсказуемость работы (а пользователь, при желании, может вручную подключить использование ntfs3 через опции монтирования). Для внешних дисков, регулярно перетаскиваемых между Windows и Linux, Fedora из коробки доставляет меньше хлопот – меньше вероятности столкнуться с тем, что диск не примонтировался из-за “fast startup” Windows или флага dirty. В Arch при таких сценариях, администратору нужно быть готовым оперативно устранять проблемы и следить за состоянием разделов.

Графический стек: Wayland и X11, драйверы NVIDIA/AMD

Wayland по умолчанию: Fedora была новатором в переходе на Wayland. Fedora Workstation с GNOME включает Wayland-сессию по умолчанию с 2016 года, и к 2024 году этот выбор уже зрелый и отлаженный. Arch Linux не навязывает дисплейный сервер – выбор зависит от окружения рабочего стола и пользователя. Если установить GNOME на Arch, он тоже запустится под Wayland, однако в Arch всегда легко переключиться на X11 при необходимости (через настройки GDM или переменную окружения). Для KDE Plasma ситуация разнится: Fedora 34+ предлагала опциональный Wayland для Plasma, а начиная с Fedora 40/41 KDE Spin включил Wayland по умолчанию, фактически убрав видимый выбор (сессия X11 остается как резерв, но акцент на Wayland).

 Arch же (и основанные на нём дистрибутивы вроде Manjaro) не спешат делать Plasma только Wayland – классический X11-сервер продолжает устанавливаться и поддерживаться из коробки. Разработчики Manjaro прямо указали, что они следуют подходу Arch и не будут повторять шаг Fedora по полному переключению KDE на Wayland только ради тренда. В Arch Plasma и другие DE предлагают обе сессии (“Plasma (Wayland)” и “Plasma (X11)”), давая пользователю выбор. Таким образом, Fedora более агрессивно продвигает Wayland, тогда как Arch сохраняет гибкость и обратную совместимость с X11.

NVIDIA и Wayland: Ключевая больная точка – поддержка проприетарных драйверов NVIDIA под Wayland. Исторически, драйверы NVIDIA долго не поддерживали нужные протоколы (GBM, DRM leasing и пр.), поэтому на Fedora вплоть до серии драйверов 470/495 при наличии NVIDIA GPU система автоматически переключалась на Xorg-сессию (чтобы избежать проблем). В последние годы (драйверы 5xx/6xx) NVIDIA реализовала совместимость с Wayland, и Fedora 37+ уже позволяла GNOME+NVIDIA на Wayland. Тем не менее, стабильность и качество работы NVIDIA с Wayland остаются переменными. Пользователи отмечают, что “Wayland с NVIDIA – вещь непредсказуемая: кому-то везёт, а у других всё лагает, несмотря на последние драйверы”. В реальных кейсах нередко советуют остаться на X11, если у вас NVIDIA, для лучшей стабильности – в X-сессии в Arch или Fedora игры и приложения с NVIDIA обычно работают без нареканий. 

Особая проблема – владельцы старых видеокарт NVIDIA. GPU поколения Kepler, Maxwell, Pascal, которым требуются Legacy-драйверы (390.xx или 470.xx), практически не работоспособны под Wayland. Эти устаревшие драйверы не получают обновления с поддержкой Wayland, так что пользователи таких карт вынуждены использовать X11. Fedora 41, сделавшая Wayland стандартом в KDE, столкнулась с этой ситуацией: для старых NVIDIA она всё равно устанавливает X-сессию, иначе у людей попросту не будет рабочего стола. Arch Linux, как отмечено, предоставляет X11 без ограничений, так что для пользователей legacy-NVIDIA там нет препятствий – они могут продолжать с X.org столько, сколько нужно. В целом, разница в философии: Fedora старается идти вперёд с Wayland даже ценой отключения поддержки устаревших случаев, Arch более нейтрален и поддерживает параллельно оба стека.

Установка и обновление драйверов NVIDIA: Fedora и Arch по-разному распространяют проприетарный драйвер NVIDIA. Fedora по умолчанию включает только открытый драйвер Nouveau (который для современных карт NVIDIA зачастую недостаточен), а официальный проприетарный пакет доступен через внешнее репозитории RPM Fusion. Arch Linux, хотя и придерживается принципов open source, распространяет драйвер NVIDIA в собственном репозитории (Extra): установка производится командой pacman -S nvidia (для текущего ядра) или nvidia-lts (для LTS-ядра). Это удобнее, однако требует внимательного отношения при обновлениях: ядро Arch обновляется очень часто, и важно, чтобы пакет nvidia обновлялся синхронно. Обычно Arch-разработчики координируют выпуск новой версии драйвера сразу под новое ядро, но если пользователь задержал обновление или использует нестандартное ядро, может возникнуть ситуация несовместимости (X сервер не стартует из-за несовпадения версии модуля). 

В Fedora обновления ядра и драйвера NVIDIA (из RPM Fusion) тоже выходят регулярно, но используются механизмы акмодов: если установлен akmod-nvidia, при обновлении ядра система автоматически перекомпилирует модуль под новое ядро. Это снижает вероятность ситуации, когда пользователь перезагрузился после апдейта и получил черный экран – Fedora постарается собрать модуль во время загрузки. На Arch для похожей надёжности некоторые используют пакет nvidia-dkms из AUR, чтобы модуль собирался под любое установленное ядро, но это требует времени и может быть сложнее. Таким образом, Fedora чуть более “дуракоустойчива” при обновлении NVIDIA-драйверов, а Arch предоставляет свежайшие версии драйвера быстрее, но требует от пользователя следить за совместимостью.

Драйверы AMD/Intel: С графикой от AMD и Intel ситуация проще – оба дистрибутива используют открытый драйвер AMDGPU (или i915/Xe для Intel) встроенный в ядро и стек Mesa. Arch, следуя rolling-release, часто первым приносит обновления Mesa и ядра, что может быть критично для поддержки новейших GPU. Например, как только выходит новая архитектура Radeon (RDNA3 в конце 2022, RDNA4 в 2024), в Arch соответствующие патчи ядра и Mesa появляются почти сразу. Fedora включает новые версии Mesa и ядра в очередной релиз или значимые обновления, возможно с небольшой задержкой. 

Но в целом разница невелика: Fedora известна тем, что тоже предоставляет довольно свежие версии драйверов (например, Mesa, библиотек Vulkan) в рамках текущего выпуска, особенно если это нужно для поддержки оборудования. Поэтому совместимость с видео у Fedora и Arch сопоставима; заметных “лагов” поддержки AMD/Intel нет ни там, ни там. Единственное – Arch может получить баги новейших версий драйверов чуть раньше: например, если свежая версия Mesa вызывает артефакты на определённых картах, Arch-пользователи могут первыми на них натолкнуться, тогда как Fedora могла удержать предыдущую версию до выхода патча. В то же время, Arch-пользователи первыми получают и исправления.

Итог: Оба дистрибутива сегодня хорошо поддерживают современный графический стек Wayland + DRM (в Fedora он более интегрирован по умолчанию). Fedora позиционируется как “Wayland-first”, активно включая новшества (даже в KDE, даже ценой отключения X11 по умолчанию), Arch же сохраняет полную поддержку X11 для тех случаев, где Wayland ещё неприменим (устаревшие драйверы, специфичные приложения). Для пользователей NVIDIA Fedora не даёт каких-то магических улучшений – проблемы проприетарного драйвера проявляются на всех дистрибутивах примерно одинаково. Однако Fedora может быть чуть более дружелюбна при установке и обновлении драйверов (через akmod и GUI-интеграцию в Gnome Software для RPM Fusion), тогда как Arch требует от пользователя руками поставить пакет и понимать, как он привязан к ядру. С другой стороны, Arch раньше доставляет новые версии драйвера (полезно для геймеров, ждущих оптимизаций). Пользователи AMD/Intel разницы почти не почувствуют: и Fedora, и Arch для них – свежие и отлично поддерживаемые платформы.

Совместимость с аппаратным обеспечением

Поддержка нового железа: Благодаря своей модели релиза, Arch Linux зачастую быстрее начинает поддерживать новое оборудование. Новые версии ядра Linux, драйверов и прошивок появляются в Arch вскоре после релиза upstream. Fedora же обновляет ядро регулярно, но в рамках выпуска может держаться чуть более старой версии (с бэкпортом критических патчей). Например, когда выходит новое поколение процессоров или GPU, Arch-пользователи обычно получают поддержку “из коробки” раньше, чем пользователи стабильного выпуска Fedora – последние могут дождаться либо очередного ядра через dnf update, либо даже следующей версии Fedora. 

Однако разница измеряется чаще всего неделями. Fedora достаточно современна, чтобы поддерживать большинство железа к моменту релиза. С другой стороны, Fedora (как потомок RHEL) иногда включает дополнительные патчи для enterprise-оборудования и имеет более широкую базу проверок на совместимость. В общем случае, обе системы хорошо работают с современным железом, но Arch – выбор энтузиастов, кто хочет мгновенно использовать новинки, а Fedora – более консервативна, предпочитая убедиться в стабильности поддержки. Пользователи отмечают, что “если нужна самая новая поддержка оборудования – Arch подходит лучше; если важнее стабильность – Fedora предпочтительнее”.

Secure Boot и проверенная загрузка: Ключевое отличие – Fedora изначально ориентирована на работу с UEFI Secure Boot. Ядра Fedora и важные модули подписаны, дистрибутив имеет доверенную цифровую подпись Microsoft, поэтому его можно установить и запускать с включённым Secure Boot на большинстве ПК. Arch Linux, напротив, не поддерживает Secure Boot “из коробки” – установка Arch или запуск live-носителя потребует либо отключить Secure Boot в BIOS, либо вручную заняться подписью загрузчика и ядра. На практике это означает, что на современных ноутбуках с включённым Secure Boot Arch просто не будет загружаться (BIOS сообщит о неудачной проверке). Например, владельцы Framework Laptop отмечали, что “загрузиться удалось только на проверенных дистрибутивах Fedora и Ubuntu, тогда как Arch и Manjaro не стартуют вовсе, пока Secure Boot включён”. Решение – выключить Secure Boot: после этого Arch сразу запускается. Fedora таких манипуляций не требует – её загрузчик “проверен”. Разница влияет и на драйверы: например, проприетарный драйвер NVIDIA на Fedora поставляется с подписью (через ключи MOK), поэтому тоже работает при Secure Boot, а на Arch при SB придётся либо отключить его, либо подписывать вручную пользовательскими ключами каждое обновление драйвера. Для корпоративных сред или просто пользователей, ценящих Secure Boot, Fedora явно выигрывает – Arch требует дополнительных телодвижений для достижения аналогичного уровня проверки загрузки.

Устройство и прошивки: Fedora по умолчанию включает ряд сервисов и утилит для удобства работы с оборудованием. Например, в Fedora предустановлен fwupd – демон для обновления прошивок UEFI, контроллеров, док-станций и т.п. из Linux. Многие производители (Lenovo, Dell, Framework и др.) распространяют обновления BIOS через сервис LVFS, и Fedora автоматически предложит их установить (через GNOME Software), обеспечивая актуальность прошивок. Arch Linux не устанавливает fwupd автоматически (только если пользователь сам решит), то есть обновление BIOS/EC обычно выполняется вручную или вовсе из Windows/BIOS утилитами. 

Похожая ситуация с профильными вещами: Fedora включает пакет bluez и сразу активирует Bluetooth-службу, Arch – даёт возможность, но пользователь должен сам поставить bluez и включить bluetooth.service. Fedora также по умолчанию активирует FirewallD (брендмауэр) с базовым набором правил, тогда как Arch никакой фаервол при установке не настраивает – безопасность сети предоставлена на усмотрение пользователя. Fedora из коробки защищает порты: используется firewalld (с frontend firewall-cmd), тогда как на Arch при стандартной установке все порты открыты, пока администратор сам не включит UFW, nftables или другую систему брандмауэра. В результате Fedora в типовой графической инсталляции более безопасна для новичка (нет доступа к нежданным сервисам извне), Arch же требует осознано позаботиться об этом.

Специальные проприетарные устройства: И Fedora, и Arch включают пакет linux-firmware, содержащий тысячи бинарных прошивок для Wi-Fi/Bluetooth-чипов, GPU и прочего. Поэтому поддержка, например, Wi-Fi 6E или Bluetooth 5 на обеих платформах сходная – если прошивка есть, устройство заработает. Разница иногда проявляется в том, как легко установить закрытые драйверы, если они нужны. Fedora не включает их в основные репозитории по идеологическим причинам. 

Например, драйвер для некоторых Broadcom-чипов (bcmwl-kmod) или проприетарный модуль для ноутбучных графических переключателей нужно ставить из RPM Fusion. Arch, напротив, содержит в репозитории Community проприетарный пакет broadcom-wl и прочие (в AUR есть даже пакеты для устройств вроде 3rd-party принтеров/сканеров). Впрочем, и там, и там установка несложна, разница минимальна. Fedora, кстати, начиная с Fedora 38 облегчила жизнь – при первом запуске она предлагает включить Third-party repositories, после чего RPM Fusion доступен прямо через графический магазин.

Совместимость старого оборудования: Fedora известна фокусом на новом, но при этом довольно долго тянет поддержку старых технологий ради совместимости. Например, Fedora 37 всё ещё включала модуль для ISA-шины (хотя мало кому нужен), а Fedora 39 имела опцию запуска в режиме BIOS/CSM (на совсем старых ПК). Arch Linux, в силу своей философии “modern by default”, может отсекать устаревшее: например, Arch дропнул поддержку 32-битных систем много лет назад (Fedora тоже, хотя сообщество Spin существует). Некоторые пользователи старых ноутбуков (Pentium M, драйверы ndiswrapper и т.п.) отмечают, что на Fedora им чуть проще – Fedora может иметь модуль или пакет в архиве, тогда как на Arch подобное давно удалено из репозиториев. Однако это экзотика.

Вывод: В плане работы с железом Fedora предлагает больше удобств по умолчанию – поддержка Secure Boot, авто-обновление прошивок, активированный фаервол, Bluetooth, продуманные профили питания (TLP включён), SELinux (см. следующий раздел) и т.д. Arch же даёт максимальную гибкость ценой ручной настройки: опытный пользователь может настроить всё те же функции, но ничего не делается без его указания. 

С точки зрения драйверов и совместимости конкретных устройств, нельзя сказать, что Arch существенно уступает – оба дистрибутива используют современное ядро Linux и обширный набор firmware. Тем не менее, Fedora может оказаться менее болезненной, если вы просто хотите установить систему и сразу иметь рабочее окружение на ноутбуке со всеми функциями. Arch же придётся “допиливать”, особенно в аспектах безопасности и редких проприетарных компонентов.

Системные службы и компоненты (сеть, звук, безопасность)

Сетевое управление: Fedora по умолчанию использует NetworkManager для конфигурации сети (это касается и редакции Server, и даже минимальной установки – NetworkManager включён всегда). Это обеспечивает единый подход к управлению Wi-Fi, Ethernet, VPN через GUI (в GNOME Settings) или nmcli. Arch Linux ничего не навязывает – после базовой инсталляции сеть может быть настроена разными способами. Пользователь Arch часто сам устанавливает NetworkManager (пакет networkmanager) и включает его сервис, чтобы получить функциональность, аналогичную Fedora. Однако можно использовать и systemd-networkd или старые скрипты netctl – в Arch эти инструменты равноправны.

 Различие проявляется в “из коробки” опыте: на Fedora сеть будет работать сразу (например, ethernet-интерфейс активен, а Wi-Fi можно подключить через апплет), а на Arch без ручной настройки интернет-соединения может не быть вовсе. Впрочем, большинство графических сред на Arch (GNOME, KDE) по зависимостям устанавливают NetworkManager. Иными словами, Fedora здесь чуть более монолитна – NetworkManager является стандартом де-факто, Arch более модульный, позволяя заменить NM на альтернативы без конфликта. Но проблем совместимости это обычно не рождает – скорее, вопрос удобства.

Аудио: PipeWire vs PulseAudio: Fedora была одним из первых дистрибутивов, кто переключился на PipeWire для аудио (и видео) вместо PulseAudio. Начиная с Fedora 34 (2021 год) PulseAudio в Fedora полностью заменён на PipeWire/PipeWire-Pulse. Arch Linux перешёл на PipeWire не мгновенно: в 2021–2022 PA ещё оставался стандартным звуковым сервером у многих пользователей Arch. Однако по мере взросления PipeWire Arch также внедрил его – новые установки с GNOME, KDE, XFCE сейчас, как правило, получают PipeWire по зависимостям. Тем не менее, замена PulseAudio в Arch – немного более ручной процесс. Arch Wiki предлагала пользователям самостоятельно установить пакет pipewire-pulse, который замещает pulseaudio, и перезапустить сеанс. На Fedora же это произошло автоматически через обновление. 

К 2024 году можно считать, что и на Arch, и на Fedora PipeWire стал основным звуковым сервером (на Arch пакет PulseAudio присутствует, но уже мало используется, разве что в каких-то редких сценариях). Fedora опередила многих (включая Ubuntu) в признании PipeWire достаточно стабильным ещё в 2021, Arch традиционно предоставил выбор и дал сообществу убедиться, после чего последовал. Оба дистрибутива сейчас используют связку PipeWire + WirePlumber для аудио и экранного захвата. Особых проблем совместимости здесь не наблюдается: и Fedora, и Arch решают аналогичные задачи (Bluetooth-аудио через PipeWire, низкие задержки для Steam Proton и OBS, etc.). Единственное – миграция с PulseAudio могла вызвать у Arch-пользователей временные сложности (например, нужно было вручную отключить демоны PulseAudio и убедиться, что PipeWire запущен). Fedora избавила своих пользователей от этой рутины.

Службы и модули systemd: Fedora любит включать новые возможности systemd сразу, тогда как Arch опять же предоставляет их, но не всегда активирует по умолчанию. Пример – systemd-oomd, демон пользовательского пространства для убийства процессов при нехватке памяти. Fedora включила его по умолчанию (в таргет Default) начиная с Fedora 34. Это вызвало некоторые нарекания: были случаи, когда systemd-oomd агрессивно убивал приложения (например, мог неожиданно закрыть GNOME Shell или браузер при заполнении RAM + swap). В Arch Linux systemd-oomd присутствует (идёт в составе systemd), но не активирован по умолчанию. Пользователь Arch должен сам решить и настроить его, следуя документации (не самой простой – на форуме Arch новички часто спрашивали, как корректно запустить oomd). 

По умолчанию Arch полагается на классический механизм ядра (OOM-killer через kernel), без дополнительных демонов. В результате Fedora из коробки лучше справляется с очисткой памяти на десктопе, но может совершать “лишние” убийства процессов, тогда как Arch менее вмешивается (с риском, что при нехватке памяти система начнет подвисать, вместо того чтобы закрыть программы). Схожая ситуация с модулем systemd-homed (управление домашними каталогами как контейнерами) – Fedora экспериментировала с ним, Arch не включает по умолчанию.

Мандатный контроль доступа (SELinux/AppArmor): Fedora – один из немногих дистрибутивов, где SELinux включён по умолчанию (в режиме Enforcing). Это значительно повышает безопасность: даже получив root-доступ, злоумышленник ограничен политиками SELinux. Arch Linux же не включает ни SELinux, ни AppArmor из коробки. Теоретически SELinux можно настроить в Arch (есть пакеты в AUR и wiki-гайд), но это довольно трудоёмко и не принято большинством сообщества. Поэтому типичная Arch-система полагается только на Unix DAC (классические разрешения и sudo), тогда как Fedora имеет слой MAC. 

Эксперты отмечают: “с точки зрения безопасности лучше выбрать Fedora – SELinux там настроен и снабжён профилями, тогда как в Arch если и нужно усилить защиту, то придётся вручную включать AppArmor или Firejail”. Наличие SELinux может вызывать отличия в поведении: например, серверные службы в Fedora изолированы (HTTP-сервер не получит доступ к чужим файлам даже под root), а в Arch – нет (если только админ сам не настроил аналог). С другой стороны, SELinux добавляет сложности в отладке – Fedora-программисту иногда приходится разбираться, не блокирует ли SELinux его приложение. 

В Arch таких загадок нет. На десктопе среднестатистический пользователь может не заметить работу SELinux, но при нестандартных настройках (например, запуск стороннего сервиса, работа Waydroid с Binder) SELinux может внезапно мешать, требуя создания кастомных правил. В Fedora большинство типовых случаев уже покрыто готовыми профилями SELinux (для веб-сервера, Docker, VMs и т.д.), поэтому проблем возникает немного. Резюмируя: Fedora обеспечивает более высокий уровень безопасности по умолчанию, Arch предлагает чистый лист – хотите SELinux или AppArmor, настраивайте сами, но по умолчанию их нет.

Другие системные службы: Fedora включает ряд фоновых сервисов “для пользователя”: геолокация (источник времени через GPS у ноутбуков), Power-Profiles-Daemon (управление профилями энергопотребления), ABRT (автоматический сбор отчётов об ошибках) и пр. Arch Linux минималистичен – ничего лишнего не запущено, только то, что поставил пользователь. В контексте вопроса это означает отсутствие каких-либо лишних багов на Arch, связанных с этими сервисами, потому что их там попросту нет. Например, Fedora в прошлом имела баги с ABRT, когда тот мог случайно занять 100% CPU, или с geoclue, неверно определявшим местоположение – на Arch таких демонов обычно нет изначально, значит, и багов нет. Но эти службы Fedora не критичны и при желании могут быть отключены.

Обновления и стабильность системы

Rolling-release vs Fixed-release: Arch Linux является rolling-release дистрибутивом – обновления пакетов выходят постоянно и сразу доставляются пользователю. Fedora же следует циклу стабильных релизов ~каждые 6–8 месяцев; внутри релиза обновления есть, но более минорные. Это ключевое различие, влияющее на стабильность. В Arch пользователь получает самые новые версии ядра, драйверов, библиотек и приложений немедленно, без длительных тестовых циклов. С одной стороны, это плюс – всё самое свежее под рукой. С другой – выше риск наткнуться на сырое обновление. Несмотря на то, что Arch-пакеты тоже проходят базовое тестирование, иногда в репозиторий проскакивают проблемные апдейты. 

В Fedora же обновления проходят строже: потенциально нестабильные изменения приберегаются до следующего номерного выпуска ОС. В результате Fedora славится тем, что “обновления там скучные, но надёжные” – критичные баги очень редко доезжают до пользователя. Arch же известен: “если обновление ломает систему, оно сломает её быстро – и только если вы сами запустили обновление” (то есть всё под контролем пользователя). Сторонние наблюдатели отмечают: Fedora делает ставку на стабильность, тогда как у Arch обновления хоть и проверяются, но проблемы время от времени проскальзывают.

Риск сбоев и прецеденты: Пользователи Arch, как правило, часто обновляют систему (раз в несколько дней или каждую неделю). Это рекомендуется, чтобы изменений за раз было не слишком много. Если же отложить обновления на месяцы, есть риск так называемого “upgrade hell” – когда одно крупное обновление тянет сотни пакетов и больше шансов конфликтов. При грамотном подходе Arch может работать долго без переустановки. 

Однако определённые инциденты всё же происходят. Например, известен случай, когда обновление библиотеки OpenSSL в Arch привело к тому, что перестали запускаться несколько проприетарных игр (DiRT Rally, XCOM2, Civilization VI и др.). Это произошло потому, что новые версии OpenSSL больше не содержали старых символов OPENSSL_1.0.0, которые эти игры ожидали – в Arch старую версию библиотеки сразу убрали, не сохранив обратной совместимости, и игры сломались. Решение нашлось (установка совместимого пакета с OpenSSL 1.0 из AUR и установка переменной окружения для игры), но сам факт: обновление Arch “на лету” может вот так что-то сломать. Fedora же обычно избегает подобных ситуаций. В похожем примере с OpenSSL, Fedora и RHEL долго держали пакет compat-openssl10 параллельно с новой версией, чтобы закрытые приложения продолжили работать. В Arch политика другая: "если ПО не совместимо с новым API – оно не будет работать, пока не будет исправлено". Это относится прежде всего к закрытому ПО и AUR-пакетам. 

Репозитории Arch официально стараются координировать обновления связанных компонентов вместе. Например, если выходит новая версия ICU или Boost, требующая пересборки множества программ, мейнтейнеры Arch обычно заносят все пакеты в staging и обновляют одновременно, не раздробленно. Но иногда что-то могут пропустить или задержать на несколько часов – тогда возможны временные несовместимости (решаются повторным pacman -Syu через день-два). В Fedora же подобные переходы отыгрываются в сырых ветках, и в стабильный выпуск попадают только целиком, либо откладываются. Поэтому в плане системных библиотек Fedora предоставляет более монолитную стабильность, Arch – гибкость ценой того, что пользователю приходится самостоятельно разбираться с последствиями крупных обновлений.

Частота и объем обновлений: В Arch обновления выходят ежедневно. Новые версии браузеров, графических сред, утилит – всё приходит очень быстро. Fedora тоже получает обновления приложений (особенно в Flatpak/Snap виде, хотя традиционные RPM тоже обновляются), но в среднем реже. Кто-то предпочитает постоянный поток небольших патчей (Arch), кому-то удобнее батched-обновление раз в неделю/месяц (Fedora). Fedora выпускает новую версию ОС каждые ~6 месяцев, требуя от пользователя выполнить dnf system-upgrade (или автоматический офлайн-апгрейд через GNOME Software). Этот процесс достаточно прост, но всё же крупный – по сути, переустановка пакетов системы. 

Arch избавляет от таких “скачков” – здесь единый поток изменений, система постепенно эволюционирует без переустановок и понятия “дистро апгрейд”. Некоторые ценят это, так как не нужно мигрировать конфиги или переживать смену выпуска. С другой стороны, Arch не имеет точек стабилизации – если произошёл неудачный апдейт, откатиться трудно (нужно использовать архив пакетов). Fedora же поддерживает каждый выпуск ~13 месяцев; если вам не понравился свежий Fedora 39, вы можете остаться на Fedora 38 ещё полгода (получая только исправления безопасности). Arch так не позволяет – вы либо обновляетесь постоянно, либо система со временем может попасть в состояние, когда обновиться без ошибок уже сложно (слишком большой разрыв). 

Поэтому для тех, кто хочет минимум неожиданностей, Fedora выглядит предпочтительно. Arch больше рассчитан на энтузиастов, готовых выделять время под свойственно rolling-release уход: читать новости Arch (где предупреждают о действительно критических вмешательствах), делать резервные копии, решать конфликты при обновлении и пр. Например, в Arch нередки объявления вида: “в следующем обновлении требуется вручную вмешаться – переместить файл, поменять опцию в конфиге” и т.п. Fedora такие изменения делает внутри релизов крайне редко – их переносят на новый релиз и документируют в примечаниях.

Обратная совместимость: Стабильность Fedora проявляется и в том, что она лучше сохраняет обратную совместимость API/ABI в пределах одного выпуска. Arch же не делает различий между major/minor версией – если вышел, к примеру, GNOME 45 с изменёнными расширениями, он немедленно придёт в Arch и может сломать совместимость с вашими расширениями GNOME Shell до их обновления. Fedora бы, вероятно, не стала обновлять GNOME 44 -> 45 внутри выпуска (это произойдёт при переходе Fedora 38 ->39, например), давая экосистеме время подтянуться. В Arch были случаи, когда обновление ядра сломало модуль VirtualBox (не успели обновить DKMS-пакет вовремя) или обновление pacman потребовало от пользователей вручную переинициализировать ключи подписи – все эти новости публиковались на сайте Arch, но если пользователь пропустил – его могла ждать проблема при следующем -Syu. Fedora подобные изменения обычно автоматизирует или информирует через более контролируемый процесс обновления релиза.

Нельзя сказать, что Arch – нестабильный. Многие успешно используют его на продакшн-станциях, ежедневно обновляя, и сталкиваются с проблемами очень редко. Но консенсус сообщества такой: Fedora более стабильна для конечного пользователя (за счёт более медленного и управляемого цикла), а Arch более чувствителен к качеству обновлений, которые сам же быстро поставляет. В обмен Arch даёт самое новое ПО и возможности. Как сказал один из участников сообщества: “Fedora практически не уступает Arch по свежести софта, но если вам нужна самая новьё – Arch лучше; если же нужна предсказуемость – Fedora надёжнее”. В контексте рисков сбоев это и означает: на Arch вы первым получите и баг, и его фикс; на Fedora велика вероятность, что этот баг даже не появится у вас, потому что его отловят и исправят до выпуска обновления. Пользователю остаётся решить, что важнее для его задачи.

Обратная совместимость и проблемы после обновлений (Arch)

(Эта тема тесно связана с предыдущей, но сконцентрируемся на специфических для Arch моментах после крупных обновлений.)

Arch Linux известен тем, что не гарантирует совместимость старых версий библиотек или ядер после обновления. Это означает: если пакет удалён или обновлён с разрывом совместимости, старой версии в системе больше не останется (если только пользователь сам не удержит её). В Fedora и других стабильных дистрибутивах нередко практикуется параллельная установка библиотек, чтобы не сломать софт. Пример с OpenSSL 1.1 vs 3.0: Fedora 36 включала обе версии, Arch же при переходе на OpenSSL 3.0 удалил 1.1, вынуждая все приложения перейти сразу. Большинство открытых программ в репозиториях Arch сразу пересобрали под новый OpenSSL, и они работали. Но если у пользователя был, скажем, закрытый VPN-клиент, который ещё не поддерживал OpenSSL 3 – он просто перестанет запускаться до выхода обновления от производителя. 

Та же ситуация случилась с играми – Feral Interactive не обновляли старые порты игр под новые библиотеки, и Arch-обновление открыло эту “ракушку”: игры перестали работать, пока сообщество не предоставило элегантный выход (совместимый пакет в AUR). На Fedora подобные игры работали дольше, пока в следующем релизе Fedora не убрали старые либы – т.е. пользователи выиграли время или вовсе дождались патчей от разработчиков.

Ядро и модули: После обновлений ядра Arch пользователи иногда сталкиваются с тем, что дополнительные модули (из AUR или проприетарные) надо пересобирать. Например, модуль файловой системы ZFS, сторонние out-of-tree драйверы, VirtualBox-модули – всё это требует DKMS. Если пользователь обновил ядро, но не обновил/не пересобрал модуль, функциональность может пропасть (VirtualBox не запустится, пока модуль не собран под новое ядро и не перезагружен). В Fedora ситуация аналогичная, но пакеты DKMS в RPM Fusion обычно делают это автоматически при обновлении. Тем не менее, Fedora тоже может временно отставать – например, выпуск нового ядра может опередить готовность модуля NVIDIA или ZFS, и тогда владельцу Fedora придётся либо отложить обновление ядра, либо временно потерять модуль. Но Fedora обычно старается скоординироваться, а Arch просто выкладывает новое ядро сразу. В итоге в Arch чуть чаще можно увидеть сообщения на форуме “после обновления ядра не работает Wi-Fi через внешний модуль – надо пересобрать/подождать обновления AUR-пакета”.

Конфигурационные изменения: Arch не имеет собственного патчинга программ, поэтому когда upstream меняет поведение или форматы конфигов, это сразу прилетает пользователю Arch. Классический пример – переход с iptables на nftables: Fedora готовила миграцию заранее, в нужный релиз включила автоматическую конверсию правил и т.д. Arch же просто начал поставлять iptables как прокси на nftables и объявил в новостях, что пользователям надо вручную переписать скрипты, т.к. старый движок больше не поддерживается.

Таких случаев было много: переход на PipeWire, слияние каталогов /usr (Fedora сделала это ещё годы назад, Arch – в 2022, потребовав ручной проверки от пользователя), замена netctl на современные средства и т.п. Это типичные проблемы после обновлений в Arch – они требуют от пользователя участия. В Fedora подобные большие изменения происходят реже и сопровождаются более прозрачным процессом (вплоть до автоматических миграций при апгрейде системы).

В целом, Arch предоставляет новейшие технологии ценой сокращённой поддержки старых. Fedora стремится дать пользователю немного “буфера” совместимости. Поэтому на Arch нужно быть готовым применять решения сообщества для устранения проблем после обновлений. Сообщество Arch весьма активно: почти на каждый казус в течение суток появляется либо инструкция (например, “удалите такой-то файл и повторите обновление”), либо обновлённый пакет.

Но сами Arch-разработчики ожидают от пользователей дисциплины: регулярно читать новости Arch перед обновлением и выполнять указанные там действия. Например, когда Arch обновил pacman и сменил формат ключей PGP, новость предупреждала: “необходимо до обновления вручную обновить пакет archlinux-keyring”. Те, кто пропустили это, столкнулись с недоступностью pacman до ручного вмешательства. Fedora подобные “manual intervention” практически исключает – там постараются заложить скрипт, который обновит ключи автоматически при апгрейде.

Таким образом, если суммировать: обратная совместимость на Arch ломается чаще, особенно для стороннего ПО (игры, проприетарные клиенты, эмуляторы и т.д.), – обновления могут временно вывести их из строя до появления фикса или совместимого пакета. На Fedora те же программы, как правило, работают стабильнее в рамках жизненного цикла релиза, потому что базовые библиотеки сохраняют прежние ABI (либо Fedora включает пакеты совместимости).

После обновлений ядра и системных компонентов Arch требует больше внимания: проверять работа ли видео-драйвер, обновились ли все AUR-пакеты под новую библиотеку, не нужно ли открыть .pacnew и перенести настройки. Fedora после обновлений обычно “просто работает” без подобных задач. Зато Arch всегда предлагает самые последние версии всего, и если обновление прошло успешно – вы сразу пользуетесь новыми фичами. Fedora же, как говорят, “стабильна в ущерб новизне”.

Например, Fedora 38 может использовать GNOME 44 весь цикл, пока Arch обновится до GNOME 45 в день релиза, но вместе с тем Arch-пользователь рискует первым обнаружить баг GNOME 45, о котором разработчики ещё не знают. В Fedora этот баг, возможно, будет исправлен к моменту выхода Fedora 39. Каждый выбирает по потребностям: Arch – для тех, кто готов мириться с периодическими шероховатостями и участвовать в их разрешении, Fedora – для тех, кто ценит предсказуемость и сниженные риски в работе системы.

TL;DR: Fedora уделяет приоритетное внимание стабильности и обратной совместимости, в то время как Arch делает ставку на скорость обновлений и чистоту системы, допуская, что “что-то иногда может пойти не так”. Пользователь Arch должен быть чуть более технически подкован и внимательно относиться к обновлениям, тогда как пользователь Fedora может больше доверять тому, что обновление не нарушит его рабочий процесс. Когда же речь идёт о критичных багаха Arch vs Fedora, то зачастую то, что ломается в Arch, уже исправлено или не появляется в Fedora – будь то Waydroid, NTFS-драйвер или библиотечная совместимость, как было подробно описано выше.

Источники: Arch Wiki, Fedora Docs, баг-трекеры и форумы. Каждый пункт подкреплён свежими данными 2024–2025 гг, отражающими актуальное состояние дел на обеих платформах. Например, проблемы Waydroid приведены по баг-репортам начала 2025 года, различия в NTFS-драйверах — по обсуждениям 2023–2024 гг на форумах Arch и Fedora, вопросы графики — по кейсам конца 2024 года (переход Fedora KDE на Wayland) и т.д.

Многие из этих ситуаций я видел и встречал лично — будь то проблемы с запуском Waydroid на Arch, несовместимость с новыми ядрами, или наоборот, беспроблемная работа на Fedora "из коробки". Эти примеры демонстрируют, как архитектурные решения дистрибутивов влияют на опыт пользователей и какие типичные проблемы могут возникать в одном и при этом быть отсутствующими или уже решёнными в другом дистрибутиве.