Как вы могли заметить, в RHEL 7 забросили поддержку 32-битных микропроцессоров, в т.ч. x86. К сожалению, это означает, что для 32-битных ARM RHEL 7 не будет. Конечно, неофициальные пересборки будут существовать, но официально Red Hat будет заниматься только 64-битным ARM, вся архитектура которых спроектирована с участием нашего коллеги, инженера Red Hat, участника Fedora ARM SIG Jon Masters.

Коммьюнити тяжело принимало рекомендации Red Hat - ACPI, UEFI, как обязательные стандарты для ARM. Очевидные недостатки ARM-систем (не микропроцессоров, а систем, построенных на базе лицензируемых у ARM Holdings технологий) некоторыми виделись, не как недостатки, а как преимущества - свобода выбора и свобода реализации. В принципе так оно и есть, потому что любое следование стандартам и правилам, это отказ от некоторых свобод. Но понятно, что это не то, что нам, как разработчикам дистрибутива, и нашим коллегам, разработчикам и архитекторам серверных платформ, хочется. Заметьте, очень характерно то, что не существует ARM-дистрибутива - есть ARM-сборки для той машинки, для другой, для третьей, и т.п., с зачастую общим userland, но различными ядрами, и методами установки и последующей загрузки. Как курьез можно привести архитектурное решение, использованное в Raspberry Pi - в процессе загрузки используется видеопроцессор. Стандартизация ARM-систем, начавшаяся с Device Tree и unified kernel и продолжившая с UEFI, ACPI была принята разработчиками дистрибутивов как манна небесная, хотя разработчики ядра и были недовольны свалившейся на них работой и новыми проблемами.

Так или иначе, вроде коммьюнити в целом успокоилось по поводу перехода на новые стандарты, как вдруг все началось снова. Мы уже говорили, что инженер Google, Olof Johansson, был недоволен ACPI-кодом, но свое недовольство он выражал в ленте Google+. Внезапно он написал в мэйллист пост, в котором предложил вообще отказаться от ACPI в ARM. Вместо него он предложил разработать тонкую прослойку перед ядром, которая бы читала ACPI-таблицы, и формировала бы на ее основе DeviceTree. Чуть позже, он предложил кое-что еще более удивительное - подождать, пока Microsoft отладит и допишет стандарт на ACPI для ARM. У многих в этот момент, при словах "Майкрософт разработает стандарт", проснулись болезненные воспоминания - Russell King и Mark Rutland почти одновременно высказались о том, что было б очень наивно ожидать, что Microsoft разработает хороший открытый стандарт, который потом можно будет беспроблемно реализовать в открытом ПО. Russel высказался еще об одном моменте - сейчас Linux доминирует в ARM-мире, и отдавать это преимущество просто потому что кто-то из разработчиков Google не хочет следовать стандарту, стратегически неверно. К диалогу присоединился Jon Masters и мастерски завоевал всеобщую любовь, сказав, что решать уже нечего, т.к. серверные производители у себя, за речкой, все давно решили в пользу ACPI, потому что ваш DT - глючный отстой, и сами вы все дураки. Чуть позже он закрепил успех сказав, что Red Hat тоже хочет ACPI на ARM, хотя не планирует выпускать коммерческий продукт в ближайшее время, так что разработчикам ARM надо все переписывать с DT на ACPI прямо сейчас. Проблема усугубилась тем, что оказалось, что Jon подписал какое-то адское NDA, запрещающее ему рассказывать публично, что же такого хорошего в ACPI по сравнению с DT?

С таким вот настроением разработчики приступили к обсуждению того, все таки, как работать ядру с ACPI на ARM? Основные проблемы в том, что ACPI - это немаленькая (особенно по меркам разработчиков ARM) виртуальная машина в ядре, и в том, что реализация еще очень далека от стабилизации. Идея Olof о трансляции ACPI в DT, хотя и будет работать в каких-то случаях, не будет работать, когда в ACPI будут использоваться скрипты на ACPI Machine Language (AML), порой используемые для инициализации сложного оборудования. Увы, но аналогов в DT просто нет. Так или иначе придется реализовывать ACPI для ARM, и теперь уже понятно, что этот скандал был не последним в LKML - впереди еще UEFI.

Корни сложившейся ситуации в том, что в организациях, ответственных за стандарты ARM, из авторитетных Linux-компаний есть лишь Red Hat и коллектив участников Linaro. Пока коммьюнити радовалось свободе выбора и сотням форков Linux - по одному на каждое ARM-устройство, индустрия требовала стандартов, и недождавшись конструктивного диалога с любителями "поковыряться с девайсом", решила двигаться сама. Хорошо хоть вес Red Hat в Linaro Enterprise Group сделал свое дело, и коммьюнити постепенно начало переходить к стандартизированным технологиям.

Вдоволь наругавшись, начали писать код. Недавно инженерами Linaro была добавлена возможность загрузки ядра с UEFI, реализованы сервисы UEFI, и включен базовый функционал ACPI для ARM64. Этак дело пойдет, и не придется пересобирать ядро 2.6.17.4 и старые версии U-Boot с out-of-tree патчами!

Многие коллеги-аналитики выразили свои сомнения в целесообразности перехода на XFS по умолчанию в RHEL 7. Возражения разделились на две части - медленная работа с множеством маленьких файлов и потери данных при авариях. С первым пунктом разобрались еще в прошлом году, а вот по авариям - мы уверены, что пользователям надо бы следить за физическим состоянием жесткого диска, и не повторять легенды времени включения XFS в Linux.

Кстати, развитие XFS почти полностью ведется инженерами Red Hat (как и всегда, они развивают ключевые Open Source продукты, используемые в их продуктах), и если кто пропустил, в ноябре была интересная история. Несмотря на почти половину всей работы над файловой системой, инженер Red Hat, Dave Chinner не был ее мэйнтейнером. Система формально была под контролем компании SGI - мэйнтером числился инженер SGI Alex Elder, и, вероятно, была еще скрытая от нас иерархия принятия решений в самой компании SGI.

Неожиданно, еще один инженер SGI, Ben Myers, выступил с инициативой - сменить мэйнтейнера с ушедшего от них разработчика на другого работника компании. Шаг вполне понятный - компания хочет сохранить управление над проектом. Но не тут то было! Разработчик Red Hat, Ric Wheeler обратил внимание коммьюнити, что это не очень демократично, и что у продвигаемого будущего мэйнтейнера всего два десятка патчей, относящихся к файловой системе. В принципе и у старого мэйнтейнера тоже было с три дюжины патчей, но это всех устраивало.

Фишка в том, что все управленческие изменения в OSS-коммьюнити происходят согласно правилу меритократии. Т.е. тот, кто пишет код, тот и решает - именно поэтому Red Hat скупает разработчиков, и именно поэтому участники Fedora Community решают, в состав чего войдет udev. Несогласные, конечно, могут форкать, но дело в том, что их не слушают именно потому, что они пишут мало кода, и практика показывает, что после враждебного форка, кода от них будет также ничтожное количество. В общем понятно, что так, как хотелось бы в невидимой нам управленческой иерархии SGI, приказом по отделу, у нас дела не делаются.

Возвращаясь к XFS - после изучения git log, выяснилось, что есть два лидера. Это разработчик Red Hat, Dave Chinner, и Christoph Hellwig, бывший сотрудник SGI, продолжающий работу над файловой системой. Среди них и предстояло бы выбирать, но Christoph взял самоотвод в пользу Dave, и инженер Red Hat, наконец-то получил контроль над развитием XFS. Как раз перед релизом RHEL 7!

Интересно, что коллеги-аналитики с иностранных сайтов заподозрили тут заговор известно кого, с понятно какой целью, хотя тут все просто - если хочешь контролировать разработку, то напиши с четверть или больше патчей.

Выход RHEL 7 Beta c systemd не стал для нас новостью, но за этот месяц были и другие примечательные systemd-события.

Наконец-то вышел первый полноценный мобильный телефон на базе systemd от компании Jolla. Ну, если по-честному, то 450 экземпляров первой партии выглядит не очень внушительно, но это уже значит, что Jolla продвинулась в бесконечное количество раз дальше, чем другая компания, показывающая рендер мифического смартфона, щедро приправленный подмигиваниями о ведущихся переговорах с неназываемыми производителями. Если говорить о конкурентах Sailfish, то к сожалению, systemd пока не используется в Anroid - у Google пока нет заинтересованных в этом инженеров, зато он уже используется в Tizen.

Сетевые возможности systemd были расширены. Теперь systemd умеет создавать bridge, спасибо разработчику Arch Linux, Tom Gundersen. Кстати, в NetworkManager эта фича ожидается лишь в Fedora 20, т.е. в других дистрибутивах можно ожидать лишь к лету-осени 2014 года.

Разработчики проекта CoreOS продолжают расширять функциональность systemd. До сих пор его возможности для интеграции в кластерную систему были незначительны - так, встроенный HTTP-сервер, чтоб получить логи, запуск виртуальных машин и контейнеров с помощью socket activation. Вот и все, что вспоминается навскидку. Это, конечно, не удовлетворяет запросам инженеров сложных систем, состоящих из десятков и сотен тысяч контейнеров, на которых и ориентируется проект CoreOS. Именно поэтому в рамках проекта был написан на golang еще один компонент - coreinit. Это надстройка над etcd и systemd для управления процессами в виртуальных машинах и контейнерах. Если вам раньше требовался SSH-доступ (или иной shell-access) на виртуальную машину, то теперь это не нужно. Вряд ли приложение будет включено в состав systemd, но в перспективе его функциональность может быть частично перенесена.

Kay Sievers в своей ленте G+ объявил, что kdbus уже можно пробовать, и выложил инструкцию (с логом) запуска тестового контейнера с systemd и kdbus. Lennart Poettering чуть более подробно рассказал о текущей ситуации. Почти все работает, кроме одного важного момента - нет разграничения по пользователям. Прямо сейчас в kdbus регистрировать имена может лишь суперпользователь, а простые юзеры могут посылать кому угодно какие угодно сообщения. Это, разумеется, проблема. Еще он переводит kdbus на использование GVariant в качестве внутреннего формата, и в этом ему помогает один из немногих разработчиков Canonical - Ryan Lortie. Интересно, что критика подходов, применяемых в systemd, со стороны Canonical как-то подутихла - вероятно из-за того, что они наконец-то разобрались в техническом превосходстве systemd и теперь заняты бэкпортированием фич из systemd в Upstart, ну и потихоньку втягиваются. Это здорово.

В то время, как инженеры Canonical втихомолку от своего главаря сотрудничают с нашими коллегами, Debian продолжает биться в корчах. Как вы знаете, Debian теряет свои позиции в пользу более динамичных RHEL/Fedora или даже Ubuntu. Все понимают это, и нынешний лидер проекта Debian, Lucas Nussbaum, разумеется, тоже в курсе. Debian, это стабильность в смысле "окаменелость", и никто уже давно не ожидает увидеть там новые технологии. Переделать это крайне сложно, т.к. шумные любители юниксвэя парализуют спамом и персональными атаками любое взвешенное обсуждение на тему, а т.к. разработчики OSS люди ранимые и пугливые, то нужные шаги просто не совершаются. А делать что-то надо. Последнее обсуждение того, на какую систему инициализации переходить, systemd или Upstart, (разумеется, отказавшись навсегда от бессмысленных поигрушек с просто неработающими или отстающими на декаду ядрами, типа Hurd или FreeBSD), превратилось в фарс, наподобие российских выборов - участники Debian, перепуганные грузом ответственности, брать которую просто разучились, самоустранились, передав право решать техническому комитету, почти наполовину состоящему из людей, имеющих коммерческий интерес в одном из двух вариантов. Нам очень тяжело смотреть на все это, как дети и внуки смотрели бы на погружающихся в болото старческой деменции родителей. Lucas, осознавая свое бессилие переломить ситуацию по превращению когда-то самостоятельного и авторитетного проекта в тестовый полигон коммерческой компании, сделал последнее, что мог - ввел в состав технического комитета известного разработчика XFree86/X.org, архитектора графических пoдсистем Unix, начиная от X11 и заканчивая Wayland, Keith Packard. Мы уже говорили, что Keith технически грамотно смотрит на архитектуру Unix, поэтому можно ожидать от него незаполитизированного мнения, которое может переломить тенденцию сползания проекта на третьи роли. Ну что, посмотрим.

Red Hat выпустила RHEL 7 Beta. На Linux.org.ru сообщают коллеги-аналитики, что релиз основан на Fedora 19, а среди основных изменений:

  • Ядро 3.10
  • Дефолтная файловая система - XFS
  • Поддержка Ethernet 40G
  • Поддержка работы openLMI, интеграция с AD при помощи samba 4.1
  • systemd вместо upstart
  • дефолтный десктоп - gnome classic 3.8.5
  • обеспечена бесшовная миграция виртуальных машин c хостов на rhel6


С удовольствием обновляемся!

У нашего сообщества завтра пятилетний юбилей, и мы отметим это в субботу, 23 ноября, в 14:00, в Пилзнере на Маяковской.

В качестве дополнительного стимула - к нам доехали из Брно несколько кружек и бейсболок с лого Fedora.

20 ноября в Яндексе пройдёт очередная встреча московского Go-сообщества. Специалисты по Go, начинающие Go-разработчики и все, кто интересуется этим языком, услышат доклады о его использовании в разных проектах, смогут пообщаться и обменяться опытом.

Программа:

  • Golang и Fedora - Петр Леменков, Fedora Project
  • Организация совместной работы Go и Python-based сервисов в Ostrovok.ru - Илья Биин, Островок
  • Go runtime и сборщик мусора - Дмитрий Вьюков, Google
  • Go и Cocaine - Антон Тюрин, Яндекс


Участие бесплатное, но зарегистрироваться необходимо.

20 ноября, в среду, с 18:30 ждем участников по адресу: Москва, ул. Льва Толстого 16, офис Яндекса, зал Экстрополис.

Количество мест ограничено. Если вы зарегистрировались, но не сможете прийти, – пожалуйста, сообщите нам об этом заранее.

Сегодня в один день мы выпускаем два дистрибутива. Бета-версию RFRemix 20 и обновление 19-й версии RFRemix 19.1. Оба дистрибутива основаны на официальных репозиториях Fedora, RPM Fusion и Russian Fedora. Как обычно из коробки доступны мультимедиа кодеки, Adobe Flash и некоторые дополнительные пакеты. В RFRemix 20-Beta браузер Chromium убран с диска для экономии места.

Изменения RFRemix 20-Beta:

  1. Возвращена возможность использования VPN в инсталляторе. В 19-й версии это было не возможно;
  2. Поддержка репозиториев RPM Fusion и Russian Fedora в установщике;
  3. Исправлена установка минимальных режимов для GNOME и KDE;
  4. FreeType собран с поддержкой subpixel rendering и subpixel hinting;
  5. Fontconfig использует патчи из Ubuntu для лучшего отображения на LCD мониторах;
  6. Taglib 1.9 пропатчен исправленным патчем от rusxmms (патч отправлен автору, спасибо Taurus), что позволяет некоторым плеерам (vlc, qmmp) корректно отображать mp3 файлы с тегами в CP1251. На Gstreamer это сейчас не распространяется;
  7. Unzip правильно обрабатывает кириллицу.

Для загрузки доступны DVD образы, образы сетевой установки, а также Live-образы с GNOME, KDE, XFCE, LXDE и MATE. Загрузка образов возможна через torrent.

  • Установочные диски [ i686 ] [ x86_64 ]
  • Образы Live [ i686 ] [ x86_64 ]
  • Торренты [ i386 ] [ x86_64 ]

Изменения RFRemix 19.1:

  1. Актуальные обновления на 9 ноября 2013;
  2. Исправлена установка минимальных режимов для GNOME и KDE;
  3. Пропатченный taglib доступен в репозитории;
  4. Исправлена установка Eclipse с диска;
  5. На диск с KDE minimal добавлен конфигуратор тачпанели;
  6. И как всегда пересобранные Freetype, Fontconfig и unzip с поддержкой кириллицы.

Для загрузки доступны DVD образы, образы сетевой установки, образы delta, а также Live-образы с GNOME, KDE, XFCE, LXDE, MATE и KDE-minimal. Загрузка образов возможна через torrent.

  • Установочные диски [ i686 ] [ x86_64 ]
  • Образы Live [ i686 ] [ x86_64 ]
  • Торренты [ i386 ] [ x86_64 ]

Все найденные ошибки просьба отправлять в наш redmine.russianfedora.pro. Срочную поддержку можно получить в конференции fedora@conference.jabber.ru.

Выпуск финальной версии RFRemix 20 ожидается одновременно с выпуском Fedora 20 в декабре.

Как и преполагалось, нас, разумеется, тоже затронула ситуация c очередной OpenSource-реализацией кодека h.264 от Cisco. Firefox будет поддерживать использование этого кодека (и блоб, скачиваемый с сайта Cisco), тем самым h.264 становится победителем в этом раунде битвы за интернет. В Fedora придется что-то делать, чтоб обеспечить возможность просмотра котиков без флэша на Ютубе. И пока есть два теоретических варианта - gstreamer, или каким-то образом скачивать блоб с сайта Cisco.

Ситуация с использованием gstreamer очень похожа на политизированную - несмотря на то, что этот кодек доступен в gstreamer 0.10, в Fedora поддержку не включили, т.к. почему-то ждут перехода на gstreamer1. Надо напомнить, что Mozilla Foundation требует согласовывать с ними все изменения в своих продуктах, поставляемых в Fedora, и похоже, что тут есть какие-то скрытые договоренности.

Ситуация с блобом немного хуже - мало того, что его как-то надо скачивать и устанавливать, реанимируя похороненную идею о т.н. CodecBuddy, но это еще и работать будет лишь на x86_64 и возможно на ряде ARM-систем. Участник коммьюнити Fedora и Xiph Foundation, разработчик Bitcoin, Gregory Maxwell, попросил в списке рассылки IETF сделать заявление от лица проекта о том, какие сложности для нас будут при стандартизации h.264, как видеокодека по умолчанию для передачи видео в интернет. И такое заявление сделал от лица нашего проекта Toshio Kuratomi. К сожалению, складывается впечатление, что участники голосования IETF уже приняли решение, и заявление вызвало лишь предсказуемую попытку распространить FUD по поводу патентов в VP8, высказанную представителями Skype и Nokia. Одно хорошо, как подметили комментаторы нашего заявления по кодекам, сложившаяся ситуация сильно уменьшает вероятность коммерческой успешности лицензирования H.265.

Инженер Red Hat, Ben Skeggs, добавил поддержку регуляторов частоты и напряжения в драйвер nouveau. Новость уже обсуждается на OpenNET.ru и Linux.org.ru. Коллеги-аналитики недоумевают, как же так - что ни хорошая новость про Linux и Open Source, то обязательно про Red Hat. Ну, на самом деле не все хорошее в мире открытого ПО делается в Red Hat - например, еще в Apple, Google, Facebook, Intel, Parallels, и многих других больших и маленьких компаниях. Возвращаясь к nouveau, David Airlie недавно выпустил версию 1.0.10.

ARM переходит на ACPI, ну вы про это уже знаете. Инженер Google, Olof Johansson, обращает наше внимание, что в процессе перехода исходники ядра начали наполняться простым и понятным кодом для работы с ACPI.

Участник проектов Fedora и LibreOffice, инженер Red Hat, Caolán McNamara, объявил о полном переходе с устаревшего класса строк в LibreOffice на новый. В OpenOffice было аж два класса для строк, "старый" (совсем старый) и "новый" (которому более 13 лет). Из интересных ограничений, накладываемых использованием этим "новым" классом было ограничение в 64 килобайта на максимальный размер параграфа в документах, испортированных из MS Office. В общем, теперь LibreOffice полностью перешел на третий, современный класс.

David Herrmann начал работу над реализацией Wifi-Display / Miracast.

Инженер Red Hat и мэйнтейнер libssh, Andreas Schneider, обращает наше внимание, что в библиотеке libssh сменился метод обмена ключами (kex) с предложенного NSA на разработанный в коммьюнити.

Все фичи безопасности RHEL / Fedora теперь оформлены в виде таблицы. Теперь видно, какие фичи когда и куда были добавлены.

Вышел SystemTap 2.4. Из новостей - теперь с помощью libvirt им можно анализировать виртуальные машины.

Начали анонсироваться и обсуждаться фичи будущей Fedora 21. Уже анонсировали поддержку OpenCL в Fedora, и обновление Python3 до версии 3.4.

Продолжаются дебаты вокруг архитектуры Phonon. Недавно вышедший Phonon 4.7.0 теперь использует VLC по умолчанию, если в системе есть несколько бэкендов, и пользователь не указал явно, какой из них использовать.

Alexander Larrson рассказал об изменениях в способе отрисовки в GTK 3.10.

Наши друзья из Kolab Systems объявили о выходе Kolab 3.1. Новость уже обсуждается на Linux.org.ru

Бдительные участники коммьюнити Fedora заметили, что разработчики GNOME втихую сделали все обновления, устанавливаемые с помощью графической утилиты, требующими перезагрузки. Раньше все вроде-бы договорились, что перезагрузка потребуется лишь в случае т.н. "системных" обновлений, затрагивающих компоненты Base OS, а они сделали так, что любое обновление уведет машину в reboot. За разработчиками GNOME нужен глаз да глаз! Мы будем следить за развитием событий.

Страницы