Компания Red Hat, принадлежащая IBM, в настоящее время проводит сокращение штата, о котором было объявлено в апреле этого года. Одной из жертв этого раунда увольнений стал программный менеджер проекта Fedora, в рамках которой производится разработка одноимённого дистрибутива Linux. Минувшая пятница стала последним днём работы Бена Коттона (Ben Cotton), занимавшего эту должность последние пять лет.

В обязанности Коттона входила координация действий участников сообщества Fedora и заинтересованных сторон, включая Red Hat и поставщиков оборудования, управление выборами в сообществе Fedora и т.д. Коттон был в числе тех, кто реализовал программу CentOS Stream. «Хотя я больше не буду вносить свой вклад в качестве программного менеджера Fedora, я был участником Fedora задолго до того, как присоединился к Red Hat, и я не позволю им отнять это у меня. Я по-прежнему буду находиться рядом с Fedora »,— пообещал Коттон в своём блоге.

Изображение: Fedora

Он отметил, что добился определённых успехов в работе над проектом, добавив, что это было бы невозможно без работы, проделанной предшественниками. Red Hat через два года после поглощения со стороны IBM сначала лишилась своего главы Джеймса Уайтхерста, а затем и главы управляющего совета CentOS Каранбира Сингха — оба посвятили своей работе более десяти лет. В это году IBM объявила, что полностью окупила приобретение Red Hat за $34 млрд.

Программная платформа AMD ROCm существует уже несколько лет, но официально поддерживается компанией только для дистрибутивов SLES, RHEL/CentOS и LTS-выпусков Ubuntu. При этом самостоятельная сборка всего программного стека ROCm является нетривиальной задачей. Однако теперь, похоже, в списке поддерживаемых платформ появится ещё как минимум Debian и его ответвления.

Как сообщает Phoronix, сопровождающие Debian при поддержке разработчиков из AMD при добились прогресса в портировании ROCm в пакетную базу этого дистрибутива. Если всё пойдёт по плану, то поддержку ROCm получат и наследники Debian, включая Ubuntu (обычные выпуски), Linux Mint, Pop!_OS и т.д. Также ранее говорилось о подготовке пакетов с ROCm для Fedora, но инициатива, не найдя должной поддержки, фактически заглохла. Однако по счастливому стечению обстоятельств интерес к ней снова появился со стороны одного из сотрудников AMD, который интересуется, актуальна ли она.

Сам проект ROCm подразумевает создание и развитие открытой и универсальной программной платформы для CPU, GPU и FPGA, которая сможет упростить создание, перенос и адаптацию ПО. Фактически это стек для высокопроизводительных вычислений (HPC) и ИИ-решений, который позволяет задействовать сильные стороны чипов разных архитектур.

Альянс цифровых общественных благ (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, если не будет придуман более щадящий механизм для обработки нехватки памяти.

* Внесена в перечень общественных объединений и религиозных организаций, в отношении которых судом принято вступившее в законную силу решение о ликвидации или запрете деятельности по основаниям, предусмотренным Федеральным законом от 25.07.2002 № 114-ФЗ «О противодействии экстремистской деятельности».

Для 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 года.