На днях стартовал тестовый процесс для бета-версии Fedora Linux 40, релиз которого запланирован на 23 апреля. Стоит отметить, что этот выпуск касается Fedora Workstation, Fedora Server, Fedora Silverblue, Fedora IoT, Fedora CoreOS, Fedora Cloud Base, Fedora Onyx и Live-сборки. Уже сформированы сборки для разных архитектур, включая x86_64, Power64 и ARM64 (AArch64).

Изменений и нововведений немало, среди наиболее важных для пользователей, как обычных, так и корпоративных, стоит выделить следующие:

  • Обновился рабочий стол GNOME в Fedora Workstation — теперь до версии 46.

  • Кроме того, обновилась и редакция с рабочим столом KDE, что логично. При этом поддержка сеанса на базе протокола X11 прекращена. Для того чтобы запускать X11-приложения, применяется DDX-сервер XWayland. Конечно, озвучена причина прекращения поддержки сеанса с X11 — это перевод X.Org-сервера в RHEL 9 в категорию устаревших и решение полностью удалить его в будущем значительном выпуске RHEL 10. Ещё одна причина — замена драйверов fbdev на драйвер simpledrm, корректно работающий с Wayland, ну и конечно, появление поддержки Wayland в драйверах Nvidia.

  • Пользовательские дистрибутивы, которые ранее развивались по отдельности в рамках всего проекта, объединили под брендом Atomic Desktops. Соответственно, Fedora Sericea и Fedora Onyx теперь распространяются под именами Fedora Sway Atomic и Fedora Budgie Atomic.

  • Ещё одно значительное обновление касается версий пакетов, среди которых LLVM 18, GCC 14, binutils 2.41, glibc 2.39, gdb 14.1, PHP 8.3, Ruby 3.3, Go 1.22, Java 21, AMD ROCm 6, Boost 1.83, 389 Directory Server 3.0.0, Podman 5, PostgreSQL 16, TBB (Thread Building Blocks) 2021.8, SQLAlchemy 2, Kubernetes 1.29.

  • Убран пакет с библиотекой OpenSSL 1.1 — просто потому, что прекращена поддержка самой ветки. Ну а привязанные к библиотеке зависимости переключили на OpenSSL 3.0.

  • Не обошли вниманием и конфигуратор NetworkManager, в котором теперь по дефолту включён механизм определения конфликта IPv4-адресов в локальной сети (RFC 5227). Основное его предназначение — отправка проверочного ARP-пакета перед прикреплением адреса к сетевому интерфейсу (если получен ответ, значит адрес занят и не будет назначен).

  • В таком менеджере, как DNF, отключили загрузку метаданных со всеми списками файлов, которые входят в пакеты. Они достаточно редко требуются, но у них большой размер, что приводит к замедлению работы.

  • Библиотеку Zlib заменили на форк Zlib-ng, который совместим со Zlib на уровне API. Он также предоставляет дополнительные оптимизации для повышения производительности.

  • Важный момент: теперь завершена вторая стадия перехода на обновлённый и оптимизированный процесс загрузки, который предложен Леннартом Поттерингом. В чём его отличие от обычной загрузки? Дело в том, что вместо образа initrd, формируемого на локальной системе при установке пакета с ядром, используется унифицированный образ ядра UKI (Unified Kernel Image). Он генерируется в инфраструктуре дистрибутива и заверяется его цифровой подписью. Стоит отметить, что образ UKI объединяет в одном файле обработчик для загрузки ядра из UEFI (UEFI boot stub), образ ядра Linux и загружаемое в память системное окружение initrd. Если образ UKI вызывается из UEFI, то обеспечивается проверка целостности и достоверности по цифровой подписи не только ядра, но и содержимого initrd, проверка достоверности которого важна, так как в данном окружении осуществляется извлечение ключей для расшифровки корневой ФС. Кроме того, появилась возможность прямой загрузки UKI из UEFI-модуля shim.efi без привлечения отдельного загрузчика (grub, sd-boot), реализована поддержка использования UKI на системах с архитектурой Aarch64 и подготовлен вариант UKI-образа для облачных окружений и защищённых виртуальных машин. В Fedora 38, дистрибутиве, о котором мы писали, была добавлена поддержка UKI в загрузчик, реализован инструментарий для установки и обновления UKI, а также сформирован экспериментальный образ UKI для загрузки виртуальных машин с ограниченным набором компонентов и драйверов.

  • В репозитории теперь есть пакет с фреймворком машинного обучения PyTorch, доступный для установки командой dnf install pytorch. В него добавлены компоненты для вычислений при помощи процессора. Ну а в будущем будет добавлено и привлечение GPU с NPU-ускорителями.

  • Для сборки минимальных образов для архитектуры ARM задействован инструментарий osbuild.

  • Модуль pam_userdb переведён с использования BerkeleyDB на GDBM из-за прекращения сопровождения ветки BerkeleyDB 5.x и перевода ветки BerkeleyDB 6.x на неприемлемую лицензию. Bogofilter переведён на использование SQLite вместо BerkeleyDB (libdb).

  • Fedora IoT, редакция для устройств интернета вещей, переведена на использование загрузочных контейнеров, сформированных при помощи инструментария OSTree и технологии bootc.

  • Прекращено формирование delta-обновлений RPM-пакетов, позволяющих загружать при обновлении только изменившиеся данные относительно уже установленной версии пакета. Отключена поддержка deltarpm в DNF и DNF5.

Предрелизы различных редакций можно загрузить по ссылкам:

Что же, ждём релиз финальной версии дистрибутива. Если вы опробовали бета-версию, расскажите, как она вам, нет ли каких-то критических проблем?

Комментарии (7)


  1. aniserg
    30.03.2024 10:49
    +1

    А чем deltarpm плох оказался? Я помню centos или oracle выводил предупреждение в yum, мол не установлено deltarpm, так что буду кушать много трафика.. Так и не попробовал ни разу..


    1. TIEugene
      30.03.2024 10:49
      +1

      Нигде не указано, что он плох.
      Просто нет смысла.
      Например на моих машинах оно экономит от 0 до 1.5% трафика. А возни с этим в инфраструктуре RH - немеряно.


    1. d0td0t
      30.03.2024 10:49

      Его сложно поддерживать и на уровне репки и на уровне установленной системы.

      Допустим, у нас есть пакет libfoo, за время жизни дистрибутива версия на релизе была версия 1.0.0, в процессе выпускались последовательно обновления до 1.0.4, в таком случае для того, чтобы пользователь в любой момент времени мог обновиться на последнюю версию с любого состояния дистрибутива, нужно либо применять (и хранить на стороне сервера репки) последовательно изменения 1.0.0-> 1.0.1 ... 1.0.4, либо иметь набор патчей 1.0.0->1.0.4, 1.0.1->1.0.4, 1.0.2 ->1.0.4 и т.д. Если мы начнём закладывать ещё и ситуацию "обновление с предыдущей федоры", то тут количество дельт возрастает кратно, а если добавить rawhide, то всё вообще превращается в адЪ. Кроме того, нет гарантии, что пользователь не вносил изменений в файлы пакета.


  1. Wakeonlan
    30.03.2024 10:49

    Новый китайский бэкдор там появится?))


  1. Ulrih
    30.03.2024 10:49

    Вчера уже обновился, но не обратил внимание может это бета была?


    1. Nnnnoooo
      30.03.2024 10:49

      Я обновился давно, даже до беты 40 была в разы стабильнее чем 38 и 39 версии, которые были самые нестабильные за последние несколько лет


  1. med2wed
    30.03.2024 10:49

    Хороший дистр, использую давно, радуюсь, так тут ещё и большое обновление прикатил. Классно, одним словом