Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Будущее Btrfs

В RHEL 7.4, вышедшем совсем недавно, файловая система Btrfs объявлена deprecated. Не сложилось.

По опыту нашего коммьюнити, каждый раз, когда очередной смельчак пробует использовать Btrfs, это обязательно заканчивается неисправимой ошибкой файловой системы. Поэтому мы рекомендуем не использовать ее для раздела ~/. Но как же ее используют в Facebook? Ну во-первых сравните сценарии - накроется в FB файловая система, так целый комп переустановят с нуля, засинхронизируют данные, и готово! А вы что делать будете? Ну и во-вторых, если упадет что-то чужое навсегда, то вы сильно станете жалеть? Вот то-то же. А свое жалко.

Ситуацию с нестабильностью Btrfs усугубляло то, что каждый раз разработчики обещали, что оно вот-вот будет готово. Не готово до сих пор, и бэкпортировать быстро движущуюся цель на стабильные ядра тоже удовольствия мало. Самое интересно, это то, зачем возиться с Btrfs, когда все ее фичи (подчеркнем, вообще все) доступны в других утилитах или компонентах ядра. Уже есть управление томами и разделами, есть надежная журналируемая файловая система (XFS), есть дедупликация, thin provisioning, шифрование, создание снапшотов - нужно только правильно, по-юниксвэйному все организовать.

Создав список необходимого функционала, наши коллеги предложили Stratis, написанный на Rust и Python фреймворк, использующий device-mapper и XFS. Если все пойдет хорошо, то первая версия будет доступна уже в Fedora 28. Если же все пойдет совсем хорошо, то к версии 3 планируется полностью реализовать функционал ZFS.

Ответим на напрашивающийся вопрос - что насчет ZFS? К сожалению, нет. Эта FS, по-видимому, никогда не будет предложена для включения в Linux.

Еще один вопрос - что будет с Btrfs в Fedora? Она там будет доступна. Бэкпортировать в Fedora ничего не нужно, и поэтому там ситуация гораздо проще. Пользуйтесь на здоровье, но не забывайте бэкапиться, т.к. она наверняка рухнет.

Вообще, напомню, файловые системы вскоре сильно изменятся, т.к. меняется сам носитель, на который записываются данные. И такие ФС начинают появляться! Например, недавно была анонсирована такая ФС - NOVA (новость уже обсуждают на OpenNET.ru).

Red Hat в космосе!

Состоялся запуск очередной системы с RHEL!

На этот раз, это в буквальном смысле запуск - разработанная компанией Илона Маска ракета Falcon 9 с кораблем Dragon полетела к МКС. На борту, среди прочего груза, будет высокопроизводительный компьютер Apollo 40, разработанный Hewlett Packard и работающий под управлением немодифицированной версии RHEL.

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

Почему нельзя использовать традиционные дорогостоящие комплектующие, сделанные по стандартам 1991 года, а вычислительные задачи передавать на обсчет на Землю? Да потому, что эта схема не заработает, если надо будет лететь на Марс. Там даже интернет другой, без социальных сетей. Так что придется все обсчитывать на месте.

Evince получает поддержку новых форматов

Многие уже давно пользуются Evince для просмотра PDF вместо проприетарных аналогов. Ну и наверное многие знают, что Evince может открывать не только PDF-файлы.

Bastien Nocera в своем блоге объявил о нововведенияx в Evince, очередная версия которого будет доступна в составе GNOME 3.26:

  • Переход на libarchive для открытия форматов CBT, CBZ, CB7.
  • Использование библиотеки libarr для открытия файлов CBR (будет доступно и в Fedora 26)
  • Файлы Adobe Illustrator (расширение ai)

Wayland и NVIDIA

Наш коллега, Christian Schaller, сообщает хорошие новости! Оказывается, NVIDIA не только работает над поддержкой Wayland в своих драйверах, но уже и может кое что показать.

К сожалению, чтобы запустить на проприетарных драйверах NVIDIA Wayland-композиторы требуется патчить, что довольно трудоемко. Понятно, что какой-нибудь Weston поправить относительно легко, но скажем сразу - кто им всерьез пользуется? А вот дорабатывать Kwin и Mutter, это совсем другая история.

Понимая все это, инженер NVIDIA, Miguel A. Vico, создал copr-репозиторий для пользователей Fedora с проприетарными драйверами NVIDIA. В этом репозитории он выложил Mutter, собранный c EGLStream. Теперь пользователи GNOME могут попробовать Wayland в такой причудливой конфигурации.

Пробуйте!

grep 3.1

Уже почти месяц прошел с выхода grep версии 3.1, а традиционных критических багов так и не нашли! Отличный результат.

В этот раз разогнали в 7 раз маски вида [0-9] в многобайтовых локалях, т.е. практически везде, кроме какой-нибудь из несовместимых друг с другом вариантов BSD, где по слухам используется KOI-8 и ISA-видеоускорители.

Продолжение истории про RPM и новый бэкенд хранения данных

Продолжается история с новым бэкендом к RPM. Обновление RPM до версии 4.14 утвердили фичей Fedora 27. Rich W.M. Jones потребовал, чтобы бэкенд NDB включен не был.

На это поступили разъяснения. Этот бэкенд по умолчанию использоваться не будет, но пользователь может его попробовать, если установит переменную _db_backend в значение ndb и запустить rpmbuild --rebuild.

RPM выбирает бэкенд для хранения данных

Долгое время для хранения служебных данных в RPM использовалась BerkleyDB. Это довольно старое ПО, да еще и с неудобной лицензией (AGPL, начиная с версии 6.x). Заменить BDB планировали давно, и даже написали NDB, экспериментальный бэкенд, который и включили в RPM версии 4.13.

Начиная с RPM 4.14, который будет фичей Fedora 27, разработчики планируют переключиться на новый бэкенд. Как всегда бывает, мало кто увидел, что изменение внесено уже пару лет назад, и реальное обсуждение началось лишь сейчас.

Довольно очевидны проблемы - апгрейд будет требовать изменения самой базы данных, вероятно "сломается" некоторое стороннее ПО. Но главное - на GitHub лежит туча встраиваемых KV-хранилищ, транзакционных баз данных, реляционных баз данных, и простых data store. Зачем при таком богатстве выбора создавать что-то новое?

Сразу поступили предложения пересмотреть решение и использовать SQLite или LMDB - самые напрашивающиеся варианты. Это, конечно, далеко не полный список.

По поводу библиотеки SQLite - интересно то, что такой бэкенд в RPM был, но его удалили, мол, был медленный. Скорее всего, дело было в низком качестве самого бэкенда, и в том, что вряд ли кто-то использовал SQL-функциональность библиотеки.

По поводу же LMDB - был только RFE, а не PR. Реального кода никто еще не предложил, хоть заявленные характеристики библиотеки и превосходят ожидания. Однако, мы знаем, что разработчики LMDB (они же разработчики OpenLDAP) - люди уникальные. Наш товарищ, Леонид Юрьев, по неизвестной причине уже который год с коллегами убирается в этих Агиевых конюшнях, для чего, помимо всего, пришлось форкнуть LMDB. Мы желаем им удачи, разумеется, но также нужно признать, что когда он начинает перечислять проблемы в стоковой LMDB, становится понятно, что просто так в RPM это брать нельзя.

Обсуждение только началось, и посмотрим, чем все закончится.