Russian Fedora

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

Coreutils 8.28

Наш коллега, мэйнтейнер coreutils, инженер Red Hat и участник Fedora Pádraig Brady объявил о выходе coreutils версии 8.28. В основном багфиксы, но есть и интересное нововведение. В команде ls теперь вожможно выводить результат в виде гиперссылок вида file://, которые распознаются современными терминалами.

Фотоэкскурсия по новому офису Red Hat в Brno

На VC.ru появилась фотоэкскурсия по новому офису Red Hat в Brno.

Штаб-квартира: Чешский офис компании-разработчика Red Hat

С ярким дневным освещением за счёт высоких окон, установленных по всему периметру здания.

В 2017 году мировой разработчик программного обеспечения Red Hat открыл новый офис в чешском городе Брно. Здание выполнено в форме крыльев бабочки и занимает площадь около 4 тысяч м², которая рассчитана на 350 сотрудников.

Дизайн разработали архитекторы из Великобритании в сотрудничестве с командой Red Hat. Помимо рабочих комнат и конференц-залов, пространство включает в себя тренажерный зал, оздоровительный центр, библиотеку, зоны для игр и отдыха. При помощи современного и высокотехнологичного подхода к оформлению офиса руководство компании пытается привлечь и сохранить лучших специалистов, которые выпускаются из местных технических университетов.

https://png.cmtt.space/paper-media/fb/ee/de/5ce552da8af205.jpg https://png.cmtt.space/paper-media/46/b3/0d/b8dd5de46035ee.jpg https://png.cmtt.space/paper-media/99/73/94/4b11996f13422b.jpg https://png.cmtt.space/paper-media/00/59/72/14b96d1801b8a5.jpg https://png.cmtt.space/paper-media/c7/e7/39/4f2e2d20c03695.jpg https://png.cmtt.space/paper-media/2d/83/94/8f995c95be125a.jpg https://png.cmtt.space/paper-media/9a/89/64/2a2a7805446a47.jpg https://png.cmtt.space/paper-media/6e/3c/c0/1854c8131f6813.jpg https://png.cmtt.space/paper-media/9d/23/3f/15af3ed7343879.jpg https://png.cmtt.space/paper-media/20/6e/3b/51047bb6d3cb07.jpg https://png.cmtt.space/paper-media/2a/36/b3/1d7d75d36351d7.jpg https://png.cmtt.space/paper-media/e4/84/b4/1b80cdec2ba88a.jpg https://png.cmtt.space/paper-media/35/95/f8/55838ce8a47a78.jpg https://png.cmtt.space/paper-media/3d/93/07/a6fe45927d6bff.jpg

Вроде неплохо получилось.

All Systems Go! 2017

Сформирована программа конференции All Systems Go! 2017, которая пройдет в Берлине, с 21 по 22 октября 2017 года. Пока список докладов не сообщается, но уже известен список выступающих:

  • Alban Crequy (Kinvolk)
  • Brian "Redbeard" Harrington (CoreOS)
  • Gianluca Borello (Sysdig)
  • Jon Boulle (NStack/CoreOS)
  • Lennart Poettering (Red Hat)
  • Martin Pitt (Debian)
  • Matthew Garrett (Google)
  • Thomas Graf (covalent.io/Cilium)
  • Vincent Batts (Red Hat/OCI)

Будете в Берлине осенью, заходите!

Новый демон D-Bus

Продолжается история замены штатного и порядком устаревшего сервиса D-Bus. После того, как не взлетел проект kdbus, а перспективы bus1 по включению в ядро и не просматриваются, было принято решение переписать имеющийся демон.

David Herrmann на днях предложил первый вариант новой реализации - dbus-broker.

Почему понадобилось переписывать начисто, вместо патчей к старой версии, которой, кстати, больше 15 лет, и как то ведь оно работает. Потому что, при всем уважении к разработчикам первой реализации, она была спроектирована не очень хорошо. Этому есть объяснение - было сложно увидеть общую схему взаимодействия приложений в то время. Поэтому архитектура получилась гродомздкой, реализация вышла неторопливой, а неизбежная сложность привела к увеличивающейся горе ошибок, некоторым из которых уже по 7 лет. Багрепорты варьируются, как указывает David, от ошибок обращения к памяти, до молчаливой потери сообщений и вызванных недостатками архитектуры дедлоков. Решить некоторые из этих проблем можно, но результат не будет соответствовать техническому заданию.

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

  • Вместо концепции общей шины данных, была реализована концепция отдельных узлов, которые независимо друг от друга общаются.
  • Демон не использует сеть или другие IPC. Раньше это вызывало дедлоки, например, когда пользователи заведены в LDAP или NIS.
  • Все ресурсы учитываются не по отдельным узлам, а по пользователям, инициировавшим соединения.
  • О каждой ошибке теперь будет сообщаться. Если уведомить пользователя невозможно, то демон будет завершать работу аварийно.

В результате получился довольно простой локальный брокер сообщений (не работает по сети, другой шине, или через libastral), который использует только самые последний Linux-технологии, работает полностью в пространстве пользователя, и который довольно хорошо совместим с предыдущей референсной реализацией. Коллеги-аналитики уже анонимно обсуждают увиденное на Linux.org.ru и OpenNET.ru.

Пока непонятно, каково будущее у bus1, если реализация шины в userspace будет успешно работать.

Статистика разработки ядра Linux 4.13

На LWN опубликовали статистику разработчиков ядра версии 4.13. И вновь в лидерах все те же компании, но есть и приятный сюрприз. Давно не видели Canonical в списке топовых корпоративных разработчиков ядра, и вот, наконец-то они появились.

/images/contribution-linux-413.png

Будущее 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 года, а вычислительные задачи передавать на обсчет на Землю? Да потому, что эта схема не заработает, если надо будет лететь на Марс. Там даже интернет другой, без социальных сетей. Так что придется все обсчитывать на месте.