Альянс цифровых общественных благ (Digital Public Goods Alliance, DPGA) при ЮНИСЕФ (Детский фонд ООН) признал Fedora Linux «цифровым общественным благом». Альянс занимается продвижением идей устойчивого развития, в том числе посредством решений с открытым исходным кодом, которые способствуют созданию справедливого мира.

В списке причин присвоения такого статуса Fedora есть следующие пункты:

• Дистрибутив продвигает лучшие решения и придерживается стандартов.
• Дистрибутив создаёт инновационную платформу для оборудования, облаков и контейнеров, которая позволяет разработчикам ПО и членам сообщества создавать индивидуальные решения для своих пользователей.
• Дистрибутив является бесплатным и предоставляет права на использование, копирование, изменение, объединение, публикацию, распространение, сублицензирование и/или продажу копий ПО без ограничений. При этом конечные пользователи получают те же права.
• Fedora Linux соблюдает международные и локальные законы.
• Способы сбора и обработки персональной информации ограничены и явно прописаны.
• Дистрибутив не приносит вреда.
• Проект соблюдает политику конфиденциальности и делает её доступной для партнёров.

Также, по данным DPGA, Fedora активно используется в 183 странах. Отметим, что с точки зрения DPGA «общественным благом» могут признать не только программные наработки, но и другие решения и проекты в сфере здравоохранения, науки, технологий и т. д.

Компания Red Hat сообщила о формировании команды, которая займётся вопросами поддержки и сопровождения репозитория EPEL (Extra Packages for Enterprise Linux). При этом команда дополнит усилия сообщества и будет занята подготовкой репозитория к грядущим выпускам Red Hat Enterprise Linux (RHEL). Тем не менее, в свете событий с CentOS, интересно, как на это отреагирует сообщество.

EPEL крайне популярен среди пользователей RHEL, CentOS и других родственных или совместимых дистрибутивов. В EPEL доступны пакеты из Fedora Linux, которые собираются для всех базовых архитектур, поддерживаемых Red Hat. Потому команда и будет заниматься вопросами взаимодействия между разработчиками и сообществом. Она будет сформирована как часть группы CPE (Community Platform Engineering). Начало работы запланировано на октябрь текущего года, хотя точной даты пока нет.

Релиз Fedora 34 должен выйти на этой неделе, но разработчики уже активно работают над Fedora 35, внося новые предложения. Так, например, сейчас в Fedora основным системным компилятором выступает GCC. Исключением может быть лишь тот случай, когда исходный проект поддерживает только LLVM/Clang. Однако в будущем возможен переход на LLVM там, где это целесообразно, в рамках всего дистрибутива.

В Red Hat предложили пересмотреть политику использования компиляторов для Fedora 35 — при создании пакета у сопровождающего его разработчика будет выбор между GCC и LLVM. При этом GCC останется в качестве системного компилятора по умолчанию, и большинство пакетов, вероятно, продолжат использовать именно его. Однако будет возможность собирать проекты и с помощью LLVM, причём даже те, которые официально поддерживают только GCC.

Среди пакетов, которые могут затронуть эти изменения, есть Firefox и некоторые другие. При этом пока что комитет по разработке и управлению Fedora ещё не оценил это изменение, потому решение пока что находится в «подвешенном» состоянии. Похожий подход используется в Intel Clear Linux, где для каждого конкретного пакета выбирается тот компилятор, который позволит получить лучшую производительность.

В будущем дистрибутиве Fedora 34 ожидается появление новинки, которой пока нет ни у кого. В нём будет доступна sevctl — утилита с открытым исходным кодом для управления системой шифрованияя Secure Encrypted Virtualization (SEV) в процессорах AMD EPYC. Эта утилита отображает различные детали SEV, позволяет управлять сертификатами, состоянием платформы и так далее.

Она реализует все основные возможности, доступные через API для SEV. Технология SEV, напомним, позволяет изолировать виртуальные машины, шифруя их память по алгоритму AES (128 бит) с помощью уникальных ключей, управляемых отдельной SoC AMD Secure Processor, находящейся непосредствено внутри чипов EPYC.

Технология AMD появилась ещё в первом поколении процессоров EPYC 7001 (Naples). AMD внедрила поддержку SEV в ядро Linux и соответствующие части стека виртуализации с открытым исходным кодом. В EPYC 7002 (Rome) компания увеличила число доступных ключей шифрования памяти с 15 до 509, а в EPYC 7003 (Milan) появилось расширение SEV-SNP (Secure Nested Paging), которое защищает гостевые системы от попыток вмешательства в их память со стороны гипервизора.

Сама утилита sevctl выпущена под лицензией Apache 2.0 в рамках проекта Enarx для работы со средами доверенного исполнения различных поставщиков. Исходники её размещены на GitHub. Также она доступна в репозитории. А сам релиз Fedora 34 намечен на конец апреля этого года.

Комитете по проектированию и управлению дистрибутива Fedora единогласно одобрил несколько важных функций для грядущей сборки Fedora 34, которая должна выйти в конце апреля. Обещана чистка от старых пакетов, а также новые функции. В частности, мы уже рассказывали про улучшение работы с малым объёмом ОЗУ.

После внедрения Btrfs по умолчанию в Fedora 33 вместо ext4, на что, к слову, ушло немало лет, в новых релизах дистрибутива предполагается более полное использование возможностей этой файловой системы. Так, в Fedora 34 планируется включить прозрачное сжатие Zstd для большей экономии места. Характерными чертами Zstd (алгоритм Zstandard) являются высокий уровень сжатия в сочетании с очень быстрой распаковкой.

wikipedia.org

Ещё одной функцией для Fedora 34, использующей возможности Btrfs, станет поддержка механизма Copy-on-write для DNF/RPM. Это должно обеспечить более быструю установку и обновление ПО. Правда, это довольно серьёзное изменение самого формата пакетов и работы с ними, так как используется декомпрессия во время загрузки и локальное формирование оптимизированных под конкретную систему пакетов.

В конце осени появилась версия systemd 247 с новым демоном Out-of-Memory Daemon (Systemd-OOMD). Он призвал улучшить работу на системах, где мало оперативной памяти. И вот теперь разработчики Fedora сообщили, что в версии под номером 34 эта возможность может быть включена по умолчанию.

Технически идея состоит в том, чтобы принудительно завершать процессы отправкой SIGKILL в выбранной cgroup, когда рост нагрузки на память (memory pressure) для всех её процессов превышает 4% в течение 10 секунд. Также будет отслеживаться использование раздела подкачки (swap). При превышении заданного лимита заполнения swap процессы тех cgroup, которые занимают больше всего места в нём, также будут принудительно останавливаться.

Изначально Systemd-OOMD предназначался для Linux-серверов Facebook. Демон позволяет отслеживать объём занятой памяти и выгружать те процессы, которые превышают заданный объём. Пока что эта функция считается экспериментальной, но, учитывая, что Fedora 34 выйдет не раньше весны, разработчики уверены, что она будет готова к использованию со временем. В дальнейшем, надо полагать, эта функция попадёт и в RHEL, если не будет придуман более щадящий механизм для обработки нехватки памяти.

Для Linux пришло время больших перемен — в прошлом году начался «крестовый поход» против поддержки 32-бит систем, а уже в этом наметился курс на отказ от старых CPU без AVX2 и ряда других инструкций в рамках Fedora Enterprise Linux Next. Теперь разработчики обсуждают следующий логичный шаг — отказ от поддержки BIOS и работу только с UEFI.

GitHub: hakluke / how-to-exit-vim

Компания Intel, ключевой игрок серверного рынка, ещё три года назад пообещала избавиться от поддержки BIOS и OpROM-модулей к концу 2020 года — в современных платформах для их работы требуется принудительно включить режим совместимости CSM (Compatibility Support Module). ARM в рамках программы ServerReady склоняет производителей к унификации, и здесь наличие классического BIOS тоже не подразумевается.

Разработчики дистрибутива Fedora, который многие называют тестовым полигоном для нововведений, попадающих в итоге в Red Hat Enterprise Linux и его «потомков», обсуждают возможность отказа от поддержки BIOS и работу только с UEFI. Отмечается, что современное «железо» всё равно не будет адекватно работать с 32-бит ОС и ПО и не будет совместимо с действительно старым оборудованием.

Если решение об отказе будет принято, а произойдёт это всё равно не раньше следующего года, то обладатели старых, но всё ещё рабочих, то есть чаще всего серверных, систем вряд ли этому обрадуются. Кроме того, могут возникнуть и проблемы с системами виртуализации — почти все из них по умолчанию предлагают загрузку виртуальных машин именно с эмуляцией BIOS, а не UEFI.

Второе важное изменение, обсуждаемое в сообществе Fedora, носит не технический, а скорее исторический характер. В качестве текстового редактора предлагается всегда использовать по умолчанию nano вместо vi (или Vim). Оба из них достаточно легковесны для любых современных систем (со встраиваемыми решениями это не всегда так, но Fedora к таковым трудно отнести). Однако nano гораздо проще в использовании для неподготовленного пользователя, он хотя бы отображает подсказки для клавиатурных сочетаний прямо на экране.

Vi и его наследники по историческим причинам используют отдельные режимы для набора текста и манипуляций над ним, в которых назначение клавиш отличается и никаких подсказок по умолчанию не выводится. Никакой сложности в этом на самом деле нет, но вопрос «Как выйти из vi(m)» регулярно задаётся на протяжении 40 с лишним лет, что стало поводом для, пожалуй, изрядно затянувшихся шуток. Есть даже специальные подборки весьма изощрённых способов покинуть редактор.

Fedora 33 уже в этом году выйдет в новом варианте Enterprise Linux Next (ELN) и предоставит возможности для тестирования изменений, потенциально предназначенных для следующего выпуска Red Hat Enterprise Linux (RHEL). Наиболее важным из нововведений ELN считается повышение минимальных требований к процессорам x86-64.

Вчера окончательное решение в пользу реализации ELN было принято: запрос на создание buildroot-окружения и настройки компоновки для ELN был одобрен 13 апреля 2020 г. 

Как сообщалось в прошлом месяце, Enterprise Linux Next станет своего рода испытательным полигоном для возможных изменений в грядущих релизах RHEL и для сборки пакетов присущим RHEL способом. ELN предоставит разработчикам и другим заинтересованным сторонам возможность обратной связи, что напоминает собой процесс разработки CentOS / RHEL.

Краткое изложение планов можно найти на вики-странице проекта: «ELN – это новая система сборки "buildroot" и компоновщика для Fedora, который берёт исходники Fedora Rawhide и эмулирует компоновщик Red Hat Enterprise Linux. Обратная связь от работы компоновщика и интеграционного тестирования будет предоставлена разработчикам Fedora, чтобы они могли увидеть потенциальное влияние своих изменений на разработку RHEL. ELN позволит исследовать новые возможности, такие как более высокий базовый уровень для используемой архитектуры процессоров, не затрагивая остальную часть Fedora».

Ранее сообщалось, что разработчики Red Hat Enterprise Linux 9 могут отказаться от поддержки старых процессоров x86-64 в пользу более современных. Очевидно, что этот процесс начнется с дистрибутива Fedora 33. Бета-версия Red Hat Enterprise Linux 8.2 была представлена в январе 2020 года.

Разработчики Red Hat Enterprise Linux 9 могут отказаться от поддержки старых процессоров x86-64 в пользу более современных. При этом пока что окончательное решение об отказе не принято. 

На текущий момент команда создателей Fedora трудится над инициативой Enterprise Linux Next, в рамках которой планируется не только проверить создание таких сборок, но и обеспечить обратную связь с пользователями, чтобы минимизировать проблемы при переходе на более новые процессоры.

wikimedia.org

Ещё летом прошлого года было внесено предложение повысить минимальные требования для Fedora 32, что вызвало негативный отклик. Тогда предполагалось, что для работы потребуются CPU с поддержкой AVX2 и ряда других инструкций вроде CMPXCHG16B, FMA и SSE 4.2

В феврале разработчики уже запустили дополнительное тестирование обновлений микроархитектуры x86-64 на Fedora. На текущий момент релизы Fedora и RHEL поддерживают процессоры этой архитектуры, включая старые модели AMD K8. Однако с выходом «девятки», скорее всего, будет достигнута некоторая промежуточная точка, направленная на поддержку только более поздних семейств CPU.

Отказ от старых процессоров позволит задействовать более современные процессорные инструкции по умолчанию, что упростит процесс разработки и уменьшит «зоопарк» аппаратных решений. Также это стимулирует клиентов обновить свои системы.

Напомним, что бета-версию Red Hat Enterprise Linux 8.2 представили в начале этого года. Так что до старта развёртывания девятой сборки ещё есть время. Скорее всего, она выйдет не раньше 2023 года.

Дистрибутив Linux Fedora CoreOS, как сообщают разработчики, стабилизирован и готов для массового использования. Отныне он является полноценной заменой Fedora Atomic Host и CoreOS Container Linux, поддержка которых прекратится в середине и конце текущего года. 

Сама сборка является максимально автоматизированной системой с атомарным обновлением, рассчитанной на унифицированное развёртывание контейнерных систем.

fedoramagazine.org

В поставке есть только базовый набор: ядро Linux, системный менеджер systemd, а также набор утилит для SSH, управления конфигурацией и установки обновлений.

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

Fedora CoreOS основана на ядре Linux 5.4, systemd 243 и может функционировать в live-режиме. Кроме запуска с носителя, есть возможность загрузки по сети через PXE. Сам образ скачать можно здесь.