FOSDEM 2014 - Свободное ПО в Европе
За два дня FOSDEM посетило несколько тысяч человек — организаторы дают расплывчатую оценку «5000+», но поскольку вход абсолютно бесплатный, свободный и не требует никакой регистрации, то точное число узнать вряд ли получится. Посчитать посетителей можно только косвенно — например, по количеству подключений к dhcp-серверам wifi-сети. К слову, wifi работал без нареканий, но организаторы решили провести эксперимент и основную сеть сделали IPv6-only. Судя по достаточно большому количеству вопросов от людей, которые вроде бы подключались к wifi, но до интернета достучаться не могли, далеко не все настольные системы на данный момент готовы переехать на IPv6 прозрачно для пользователей. Впрочем, организаторы сжалились, параллельно развернули сеть с IPv4.
Возвращаясь к количеству посетителей, цифра 5000 на самом деле может оказаться и заниженной. Ведь всего на конференции было около полутысячи докладов, презентаций и круглых столов (и значит, почти столько же докладчиков). Доклады шли параллельно в 23 аудиториях, каждая из которых вмещала минимум несколько десятков человек, а многие — и несколько сотен. Конечно, на некоторых докладах залы были заполнены процентов на десять, но на некоторых из тех, что я посетил, было более двухсот слушателей.
К тому же помимо докладов, народ активно изучал стенды представленных на конференции проектов и общался с разработчиками. Стендов было 45 штук, и пообщаться было с кем. Из дистрибутивов помимо OpenMandriva были представлены Fedora, OpenSUSE, Debian, Mageia, а также дистрибутив для детей — DoudouLinux. Представлявший его товарищ сам похож на большого ребенка, так что есть основания полагать, что он знает, что делает:) Интересно полное отсутствие Ubuntu, хотя на машинах для общего пользования, стоявших в коридорах, была установлена именно эта ОС. Коммерческий Red Hat как дистрибутив тоже представлен не был, однако сама компания являлась основным спонсором конференции и ее сотрудники представили достаточно много докладов про открытые технологии, продукты и процессы, развиваемые и используемые в крупнейшем коммерческом Linux-вендоре.
В частности, были несколько докладов от разработчиков Foreman — нового инструментария для управления пулом серверов (как реальных так и виртуальных и витающих в облаках). Foreman предоставляет средства развертывания ОС на множество серверов и интегрируется с системами управления конфигурацией — на конференции рассказывалось о Puppet и Chef. Авторы также обещают интеграцию с Katello — в совокупности с системой управления репозиториями Pulp эти продукты должны прийти на смену Spacewalk/Satellite в будущих поколениях RedHat Networks. Правда, пока что интеграция Foreman с Katello сводится к наличию ссылок на интерфесый друг друга. Pulp на данный момент умеет работать только с репозиториями, созданными с помощью createrepo, но разработчики высказали заинтересованность в поддержке других платформ. Внутри РОСЫ мы уже сделали вполне работоспособную поддержку urpmi-репозиториев в Pulp — теперь на очереди общение на эту тему с апстримом. Может, подскажут — как сделать еще лучше:)
Помимо рассказов о продуктах и технологиях (большинство из которых так или иначе были связаны с облачными технологиями и обслуживанием большого количества машин), представители RedHat делились некоторыми подробностями внутренней кухни компании и процессов разработки. Можно было узнать, что инженеры RedHat активно используют Gerrit для инспекции исходного кода, Nitrate для управления тестами, Dogtail для автоматизации тестирования приложений с графическим интерфейсом. Автоматизации тестирования вообще уделялось достаточно много внимания, ведь компаниям, предоставляющим коммерческие услуги, необходимо заботиться о качестве своих продуктов. А как показывает практика, полагаться в сфере тестирования исключительно на сообщество — не самый хороший вариант. Поэтому над тестами в RedHat работают активно, и по возможности стараются все автоматизировать.
Прогресс в этой области, безусловно, есть, и автоматические тесты активно используются для регрессионного тестирования различных приложений — как консольных, так и графических. Например, был неплохой доклад про cwrap — обертку для libc, позволяющая тестировать клиент-серверные приложения без развертывания реальной сети и виртуальных машин. Для тестирования GUI разработчики используют AT-SPI, что позволяет не привязываться к внешнему виду приложений, темам DE и прочим элементам оформления, не имеющим отношения к функциоанлу программы. Теоретически, это делает возможным использование одних и тех же тестов для разных версий одного и того же приложения в разных версиях ОС, но и здесь есть нюансы — например, при изменении структуры меню все равно придется модифицировать тесты, имитирующие клик на тот или иной пункт. В общем, забот по поддержке автотестов у RedHat хватает, но компания считает эти затраты обоснованными и смотри в будущее с оптимизмом. А заодно планирует в будущем «привить» культуру разработки с автоматическим тестированиям в Fedora.
Представители других дистрибутивов докладов особо не делали, хотя, я думаю, товарищи из SUSE тоже могли бы рассказать много интересного. Зато был показательный доклад от Debian, вполне дающий представление о процессе разработки этого дистрибутива — доклад назывался Reproducible Builds for Debian и, как нетрудно догадаться, был посвящен проблеме невоспроизводимости сборок многих пакетов в этой системе. То есть на основе одного и того же исходного кода и при использовании штатных инструментов Debian у разных разработчиков могут получиться несколько различные приложения, а какой из них попадет в репозитории — загадка. Так что исправив небольшую ошибку и пересобрав пакет, мэйнтейнер может случайно внести в него и еще ряд изменений по сравнению с предыдущей версией, обусловленные изменением сборочного окружения. Наличие проблемы создатели Debian признают, но вместо создания единой среды сборки типа ABF, OBS или Koji, которая была бы единственным источником пакетов в репозиториях, они предпочитают работать над «допилкой» инструментов сборки. Согласно тезисам доклада, после некоторой доработки инструментария в ходе массового эксперимента в сентябре идентичность сборок была достигнута для 1200 из 5000 пакетов. Авторы считают это неплохим достижением и потихоньку двигаются вперед.
Немало было обсуждений еще одной вечной темы — нивелирования различий между дистрибутивами для разработчиков приложений и вендоров. Ведь далеко не все разработчики горят желанием тестировать свои творения во всех существующих системах, но при этом нередко с подозрением относятся к мэйнтейнерам, видоизменяющим их продукты. Как сказал в кулуарах один из апстрим-разработчиков: «We need a way to protect us from maintainers». Впрочем, каких-то серьезных подвижек в этой сфере пока не предвидится. Как не предвидится их и в смежной проблеме распространения приложений — ведь собирать пакеты под каждый дистрибутив достаточно накладно, даже если использовать среды наподобие ABF или OBS, а сделать что-то универсальное, способное корректно устанавливаться в любой ОС — совсем непросто. На FOSDEM в очередной раз «всплыл» проект Listaller, три года назад слившийся с Autopackage, а сейчас активно поглядывающий на AppStream.
Для достижения кросс-дистрибутивности Listaller использует в качестве бэкенда хорошо известные PackageKit. Для решения проблемы зависимостей автор Listaller, не мудрствуя лукаво, предложил статически линковать приложение со всем, чем нужно. Вопрос отслеживания ошибок/уязвимостей в библиотеках, которые оказались встроены в приложение? Ну да, хороший вопрос, ну так что поделать — такова цена универсальности, придется в случае багов в библиотеке пересобирать и обновлять приложение. Заодно автор объяснил ненужность всяких post-скриптов в пакетах, пообещав, что Listaller выполнит все, что надо, автоматом — запустит ldconfig в случае установки библиотеки, перезапустит http-сервер при установке веб-приложения и так далее. В общем, Listaller умеет делать примерно то же самое, что файловые триггеры в нашем rpm5. А опыт использования файловых триггеров показывает, что несмотря на все свое удобство, предусмотреть все возможные ситуации и совсем избавиться от post-скриптов они не позволяют даже в рамках одного дистрибутива. Да и кросс-дистрибутивность многих файловых триггеров тоже вызывает сомнения.
В общем, подход Listaller на деле оказывается даже более ограниченным, чем способ, рекомендованный стандартом Linux Standard Base (LSB) еще десять лет назад. LSB рекомендует создавать пакеты формата RPM (и устанавливать их в debian-based системах с помощью alien), не делать никаких внешних зависимостей, кроме «lsb» (а любой дистрибутив, совместимый со стандартом, эту зависимость предоставляет), но при этому советует статически линковать только те библиотеки, которые не входят в LSB. Так что по крайней мере можно не линковать статически Qt, Gtk, ALSA и другие распространенные библиотеки.
Как итог — несмотря на долгую историю развития, ни Listaller, ни Autopackage, ни AppStream пока не снискали большой популярности у вендоров приложений. Однако актуальность проблемы никуда не делась, и искать какие-то пути ее решения надо.
Наконец, отмечу, что все больше разработчиков приходит к мысли, что большинству пользователей вообще-то без разницы, как устроены пакеты в репозитории — они всего лишь хотят устанавливать себе готовые приложения, а что такое «пакет» им и знать не обязательно. И постепенно начинают обдумывать, как бы пользователям предоставить что-то проще пакетного менеджера — например, Центр Приложений, как у Ubuntu. Так что и наш разрабатываемый Software Center вполне в общем тренде, только гораздо ближе к завершению, чем задумки большинства зарубежных коллег.
Немало интересного можно было узнать и на стендах. Разработчики KDE показывали будущий KDE5 — правда предупреждали, что на экране работают только часы и кнопка «Пуск» . На вопрос о Kiosk, который многие находили полезным для enterprise-использования, но который не был перенесен в KDE4, разработчики ответили просто — никто из активных участников проекта KDE не заинтересован в Kiosk, и даже не совсем не в курсе, что точно от него требуется. Так что если вы хотите допиливать Kiosk — you are welcome. А то, мол, все только жалуются на его отсутствие, а помочь сделать не хотят. Да и вообще — Kiosk на самом деле можно использовать в KDE4, правда GUI у него работать не будет:)
Разработчики Gnome высказывали схожий подход к просьбам пользователей — ведь в Gnome тоже неплохо знают, что этим пользователям нужно, а если чего-то не хватает — patches are welcome.
На стенде MySQL и Percona можно было обсудить состояние MySQL, его перспективы и взаимосвязь с MariaDB. Представители Percona со скепсисом отнеслись к слухам о возможном свертывании активности самого MySQL и сказали, что не очень понимают тенденцию дистрибутивов переезжать на MariaDB (конечно, если не считать того аспекта, что MySQL — продукт классового проприетарного врага, а MariaDB вроде как поближе к сообществу). Сама Percona стабильно базируетсяна кодовой базе MySQL, никаких проблем с исправлением ошибок и уязвимостей не наблюдает и переходить на MariaDB не собирается. Может, немного лукавят, но возможно они и правы. В конце концов, я бы не сказал, что во время пребывания MySQL под крылом Sun жизнь в нем кипела, а потом прекратилась. В проекте по развитию инфраструктуры LSB мы использовали MySQL очень активно, и временами натыкались на ошибки, которые висели в баг-трекере MySQL годами, сталкивались с регрессиями и вообще старались очень аккуратно подходить к обновлениям MySQL. С переходом MySQL под крыло Oracle не заметили каких-то ухудшений в этой ситуации; впрочем, насчет улучшений утверждать тоже не берусь, но и насколько лучше в этом плане MariaDB — тоже вопрос открытый.
Интересной оказалась секция, посвященная свободным текстовым процессорам, где рассказывали далеко не только про Libre- и OpenOffice. Скорее можно было узнать, что для многих других проектов эти монструозные офисные пакеты выступают хорошей площадкой для экспериментов. Например, разработчик GDB рассказывал, какие улучшения происходят в последних версиях отладчика по просьбам разработчиков LibreOffice. А эти самые разработчики в ответ жаловались, что GDB при отладке их продукта все еще временами подвисает и подтормаживает:) Схожее взаимодействие наблюдается между Eclipse и OpenOffice — во всяком случае, разработчики CDT сделали немало улучшений именно по запросам разработчиком открытого офиса. Что касательно непосредственно офисных пакетов, то мне понравилась презентация использования GPU при работе LibreOffice Calc, а также рассказ про использование групповых политик (GPO) для управления конфигурациями LibreOffice на клиентских машинах. В этом же докладе авторы нахваливали RemoteRoot — новый инструмент для удаленного обслуживания большого парка машин, не требующий (в отличии от того же Katello) наличия специальных агентов на клиентских машинах. Правда, разделы Documentations и Downloads нового инструмента сейчас гордо заявляют «Very soon, please be patient!», так что попробовать это новшество в деле пока не получится.
Техническими докладами конференция не ограничивалась. Много слушателей привлекли доклады на юридические темы, рассказы про формирование сообщества и работу с ним и прочие аспекты, немаловажные при создании любого продукта. Было много докладов с научным уклоном — например, про эвристические алгоритмы для решения NP-сложных задач. Целая секция была посвящена инструментам работы с графами — но до туда никто из нас не добрался, так что можем только отослать на сайт FOSDEM за тезисами, видео и презентациями.
В завершение конференции мы побеседовали с представителями Google Summer of Code, в рамках которого сотрудники РОСЫ не раз выступали в роли менторов от Linux Foundation. Обсудили возможность участия в этом году OpenMandriva как менторской организации — представителям OMV тоже такая идея понравилась, так что они попробуют побороться за право участия, и сейчас идет сбор идей для студентов. В конце концов, старая Mandriva участвовала в GSoC, почему бы не попробовать и ее правопреемнице? Конечно, было бы неплохо там поучаствовать и РОСЕ. Но пока объективная реальность такова, что у европейской OpenMandriva шансов существенно больше, чем у российской компании, пусть даже и с международным сообществом. Однако представители РОСЫ вполне могут предложить свои идеи OpenMandriva — ведь у нас много общего в плане кодовой базы, OpenMandriva использует огромное количесвто наработок РОСЫ, так почему бы не поработать совместно над студенческими проектами? На представление идей и подачу заявки от организации есть еще чуть больше недели.
Заодно представителям GSoC был задан вопрос, волнующий студентов из России и ряда близлежащих стран — почему Google в прошлом году перестал присылать в эти страны футболки, ручки и прочие наклейки, ограничившись выплатой стипендий и рассылкой сертификатов. Ведь многие студенты радуются футболкам ничуть не меньше, чем стипендии:) Ответ был таким, что решение было принято на высшем уровне, и точные его причины неизвестны — может, с таможней что-то не так, а может решили упростить логистику. И в этом году улучшений не планируется.
Вот такая вот европейская конференция по свободному ПО. По масштабам российским конференциям до FOSDEM еще расти и расти. Но зато мы гораздо лучше организуем запись докладов:)
Сорри за много букв, но конференция действительно нереально большая, и выше изложено только то, что вспомнилось навскидку, и что я видел своими глазами:)
Перечень всех докладов можно посмотреть здесь, для некоторых докладов можно скачать презентации. Также организаторы обещают в скором будущем подготовить видео большинства выступлений.
|
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.