Викилоги

Опубликована trial-версия курсов Сертифицированного администратора ОС РОСА «КОБАЛЬТ»

На сайте популярного журнала PC Magazine/RE опубликованы несколько ознакомительных уроков и базовый тест, помогающий получить представление о платном курсе «Сертифицированный администратор ОС РОСА «КОБАЛЬТ».

Сдав контрольный тест курса, вы можете принять участие в розыгрыше USB-флэш, 32 Гбайт, USB 3.0 (2 шт. в течение каждого месяца). Успешная сдача подтверждается также сертификатом (в электронном виде, PDF).

Содержание курса:

• Настройка DNS в режиме кэширования
• Разрешение использования подключаемых накопителей для обычных пользователей
• Включение аудита для отслеживания использования приложений

… Подробнее, см на странице курса.

Надеюсь, эта новость вас…

В РОСЕ, как и во многих других дистрибутивах, много внимания уделяется автоматизации различных задач и снижению «входного порога» для потенциальных мэйнтейнеров. Одним из первых вопросов, который встает перед человеком, желающим собрать некоторое приложение в репозитории РОСЫ — это как подготовить spec-файл для сборки RPM-пакета. Во многих случаях это можно сделать автоматически (по крайней мере, в первом приближении) — например, автоматические генераторы spec-файлов доступны для модулей Python, Perl, Ruby и так далее.

Однако модули — модулями, а многие приложения в Linux по-прежнему разрабатываются на компилируемых языках типа C/C++ и собираются с помощью GNU Autotools, CMake и аналогичных инструментов. До сих пор для таких приложений мы ограничивались шаблонами spec-файлов и политиками сборки. Для опытного мэйнтейнера этого достаточно, но у новичков нередко возникают трудности именно с первым шагом, так что мы решили еще больше упростить процесс и подготовили утилиту spec-gen, генерирующую заготовку spec-файла на основе анализа архива с исходным кодом.

Использовать утилиту очень просто — достаточно установить в РОСЕ пакет spec-gen и запустить команду spec-gen.py, передав ей в качестве аргумента имя архива с исходным кодом:

$ spec-gen.py my_tarball-1.0.tar.gz

С помощью опций -g, -s, -l и -u вы можете указать группу, короткое описание, лицензию и URL создаваемого пакета. Можно эти опции и не задавать, а заполнить соответсвующие поля в сгенерированном spec-файле. Имя и версию пакета утилита пытается угадать по имени архива, исходя из предположения, что большинство архивов называются «<имя_программы>-<версия>». Утилита подерживает все распространенные форматы архивов; впрочем, если вам попался неподдерживаемый архив — напишите нам, мы добавим код для его обработки.

В процессе работы утилита первым делом просмотрит содержимое архива на предмет наличия там файлов configure.in, configure.ac, CMakeLists.txt, *.cmake и setup.py. Если обнаружится последний, то spec-gen, не мудрствуя лукаво, запустит python setup.py bdist_rpm5 и выдаст вам spec-файл, сгенерированный этой командой. В случае же наличия файлов CMake или GNU Autotools, spec-gen произведет их анализ и попробует определить, какие пакеты необходимо установить для сборки приложения — иными словами, попробует сформировать перечень сборочных хависимостей (BuildRequires) для нового пакета.

Запускать spec-gen.py рекомендуется в той системе, под которую вы хотите создать пакет, поскольку информацию о доступных пакетах, предоставляющих ту или иную зависимость, утилита берет из репозиториев системы с помощью urpmq.

На выходе получится заготовка spec-файла с заполненным заголовком, перечнем BuildRequires, секциями %prep, %build и %install. Перечень файлов в секции %files необходимо будет доработать самостоятельно, равно как и произвести разбиение на подпакеты при необходимости. Безусловно, стопроцентной точности сгенерированного списка BuildRequires гарантировать нельзя — могут проявиться и неявные зависимости, не указанные в скриптах сборки, либо spec-gen может сделать неправильный выбор среди имеющихся альтернатив. Тем не менее, в большинстве случаев утилита отрабатывает корректно и создает spec-файл, с помощью которого уже можно начинать собирать пакет, и с немалой вероятностью вам останется только посмотреть на список файлов, созданных в ходе сборки пакета, и подправить секцию %files.

Возможно, в будущем мы продвинемся еще дальше, и сразу будем запускать сборку пакета с помощью полученного spec-файла, автоматически определять перечень файлов пакета и так далее. Простора для творчества здесь хватает. А пока что — устанавливайте, пробуйте и вносите свои идеи, предложения, а главное — патчи. Исходный код утилиты доступен здесь — https://abf.io/soft/spec-gen-dev.

В заключение отметим, что основа для утилиты spec-gen была разработана студентом НИУ ВШЭ Андреем Соловьевым в рамках производственной практики в РОСЕ.

Надеюсь, эта новость вас…

25-27 июля 2014 года ИТ-специалисты страны соберутся на самом масштабном профессиональном мероприятии лета для полного погружения в информационные технологии и отдыха в кругу единомышленников

В мероприятии нового формата — IT CAMPUS — примут участие ИТ-профессионалы различной специализации: разработчики ПО, специалисты в сфере веб- и мобильных технологий, ИТ-инженеры, системные администраторы, руководители ИТ-подразделений, сотрудники технической поддержки и другие специалисты ИТ-отрасли.

На мероприятии с докладом выступит президент и генеральный конструктор компании "РОСА" Владимир Рубанов. Тема выступления — "От "дикого" СПО - до сертифицированных систем промышленного качества". "Феномен свободного программного обеспечения (СПО) известен давно. Начинался он как инициатива энтузиастов, однако за последнее десятилетие произошел кардинальный скачок в использовании СПО-решений в реальном бизнесе. Большая часть Интернет, включая такие известные сервисы как Google, Facebook и Twitter, работают на СПО; дошло и до того, что крупнейшие фондовые биржи и банки доверяют огромные деньги Linux-серверам. Однако многие по-прежнему считают, что СПО — это продукт творчества "свободных художников", на который нельзя полагаться. Истина же где-то рядом, и одно СПО другому СПО, действительно, рознь. В докладе обсудим, как можно совмещать свободное творчество и бизнес, открытость и надежность, а также — как во всем этом процессе правильно поучаствовать", — рассказывает Владимир Рубанов.

IT CAMPUS проводится на природе (центр отдыха и туризма «Высокие берега», Калужская область) и включает как насыщенный конференционный блок, который пройдет в три параллельных потока, так и тематическую развлекательную программу. Цель конференции — избегая рекламы, дать исключительно полезную практическую информацию о новейших тенденциях в сфере информационных технологий. Конференционная часть состоит из докладов, дискуссий и мастер-классов. Спикеры — представители крупных ИТ-компаний — затронут темы управления проектами, разработки ПО, веб- и мобильных приложений; обсудят тенденции в сфере облачных технологий и виртуализации; коснутся вопросов управления ИТ-ресурсами и бизнес-процессами предприятий; уделят внимание информационной безопасности.

Параллельно с конференционной частью, участников мероприятия будут ждать соревнования по информационной безопасности – Capture the flag, турнир по легендарной игре Quake, ярмарка вакансий от ведущих IT-компаний и еще много всего интересного. Организатором IT CAMPUS является ГК Softline, партнерами стали Microsoft, «Лаборатория Касперского», VMWare, HP, EMC, Veeam, Netwrix, Академия Информационных Систем.

IT CAMPUS заявляет: ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ ДОЛЖНЫ БЫТЬ ДОСТУПНЫ ВСЕМ!

Стоимость участия в этом грандиозном мероприятии составит всего 200 рублей.

С подробной программой мероприятия и условиями участия можно ознакомиться на сайте www.itcampus.ru.

Устанавливать РОСУ можно множеством различных способов — в частности, c ISO-образа, расположенного на вашем жестком диске. Однако описанный в нашей вики способ подразумевает также наличие на вашей машине полноценно работающей ОС, в которой надо произвести некоторые подготовительные действия перед установкой. Однако может случиться, что такой системы на машине нет, равно как нет возможности загрузиться с внешнего устройства. Именно в такой ситуации оказался недавно наш коллега Сергей Соколов, и ниже мы приводим его рассказ о том, как он из этой ситуации выпутался.

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

Так и эдак потыкался, никак система не поднимается. В общем, нужно переустанавливать. Флешки нет, CD/DVD привода нет, в офисе тоже никого нет, чтобы записать установочную флешку. Ну или представьте ситуацию, что система умерла где-нибудь в отпуске, а ноут вот прямо сейчас очень нужен.

Решил я малость поэкспериментировать с загрузкой с ISO-образа, расположенного на моем SSD/HDD носителе, да еще и на том самом, на который будет устанавливаться система.

# fdisk -l /dev/sda

Disk /dev/sda: 480.1 GB, 480103981056 bytes, 937703088 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sda1            2048    33556479    16777216   82  Linux своп / Solaris
/dev/sda2        33556480    96471039    31457280   83  Linux
/dev/sda3        96471040   937703087   420616024    5  Расширенный
/dev/sda5        96473088   937703087   420615000   83  Linux

В общем-то, тут

• /dev/sda1 — своп раздел который у меня когда-то был, но сейчас просто отключен,
• /dev/sda2 — мой рут,
• /dev/sda5 — /home

От системы у меня в наличии только initrd и вываливается dracut

Вот его-то оказалось вполне достаточно:

mkdir /mnt
mount /dev/sda2 /mnt
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /mnt/dev/pts
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount /dev/sda5 /mnt/home
chroot /mnt
dd if=/home/path/to/ROSA.FRESH.KDE.R3.x86_64.iso of=/dev/sda1 bs=8M
touch /boot/resque.iso
vi /boot/grub2/grub.cfg

В конфигурационном файле grub находим строку содержащую rescue.iso и приводим эту часть файла к следующему виду:

### BEGIN /etc/grub.d/43_resque ###
if [ -f  /boot/resque.iso -o -f /boot/sgb.iso ]; then
submenu 'Repair tools' {
if [ -f  /boot/resque.iso ]; then
menuentry "Boot rescue CD" {
linux (hd0,1)/isolinux/vmlinuz0 boot=live iso_filename=/dev/sda1 root=live:/dev/sda1 rootfstype=auto ro rd.live.image rhgb splash=silent logo.nologo rd.luks=0 rd.md=0 rd.dm=0
initrd (hd0,1)/isolinux/initrd0.img
}
fi

Синкаем файловую систему командой sync и перезагружаемся. Теперь у нас есть recovery раздел, с которого без проблем устанавливается система. Главное здесь — не запускать форматирование раздела sda1 при установке системы.

Кстати, мы внутри неоднократно обсуждали, нужен ли при загрузке опциональный режим «восстановления через переинсталляцию», а именно:

• В инсталляторе предложить пользователю сохранить на /boot (если он создан) или /root- разделе собственно сам ISOшник, в виде файла installer.iso, с которого проходит инсталляция.
  • Да, в /boot его положить лучше, ибо тогда можно будет переинсталлировать и полностью убитые /root-разделы, но это отдельный UX-вопрос, как предложить это проще, не перегружая и так непростой инсталлятор. Пока можно просто предложить такую опцию, интерфейсно аналогично как в конце инсталляции предлагается выбрать swap-файл, если swap-раздела не найдено — т.е. еще один вопрос в конце инсталляции.
• В GRUB-меню, в раздел Troubleshooting добавить и пункт «Переинсталляция», которный собственно и даст возможность переинсталлировать базовую систему (для начала без специальных типа сохранения /etc/passwd, и прочего) — т.е. опция скорее для не очень простых пользователей, хотя, если это ноутбук, который использует один человек, то, т.к. переформатирования /home не будет, то средней вменяемости пользователь уже сможет себе восстановить систему практически без приседаний.

Вопрос, интересно ли это нашим пользователям, иметь возможность держать полтора гига на винте, под возможность быстрой базовой переинсталляции?

Идея «Troubleshooting-восстановление через переинсталляцию»:

Продолжим тему развлечений на «ROSA». О видео мы уже поговорили, обсудим ситуацию с играми.

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

Т.е. игры под Linux конечно были. Но, в основном, это open-source проекты энтузиастов, и среди тысяч пакетов с играми преобладали игры с несложной графикой: «казуальные» игрушки-головоломки, разные шахматы и карты, простые «аркадные» стрелялки-бродилки — и некоторым достаточно и этого, я повидал многих, кому на компьютере достаточно пасьянса и Lines.

Впрочем, теперь новый уровень «казуальщины» — это броузерные игры на Flash и HTML5 — и теперь можно растить веселую ферму и рубиться в сетевые стратегии с друзьями, вовсе не задумываясь, какая система установлена, и что вообще нужно что-то инсталлировать. И с этим все ОК, ибо слава Мозилле и работающему Flashу, тут все одинаково^[1].

Но все это, увы, было недостаточно для подлинных игроков.

• «Казуальщина» не дотягивает по уровню (графика, геймплей) до самых известных и популярных игр, скажем так, игр класса AAA, блокбастеров и бестселлеров, игр требующих 146% возможностей процессора и видеокарты.
  • Нет, конечно под Linux есть нестыдные open-source игры, вполне почти «профессионального» уровня, например, 0 A.D., Battle For Wesnoth, Xonotic, AstroMenace, Speed Dreams, но их не так много, покрыты не все жанры, плюс соображения следующего пункта…
• И, наверное, самое важное — тут срабатывает импринтинг, ко многим популярным играм настолько привыкаешь, что расставание, или замена на аналоги, увы, не катит.
  • Не говоря о играх, в которых с друзьями рубишься по сети, или просто обсуждаешь прохождение — и тут аргументы «да XXX нет, но есть похожий YYY» — не катит. Так FreeCIV не заменит пятую цивилизацию, а любая трехмерная стрелялка не заменит CS.

Поэтому игроману приходилось для таких игр

• либо держать отдельный раздел с DOS/Windows — это более-менее ОК для игр-«стрелялок» требующих 100% CPU и твоего внимания, это вполне разумно («делу время, потехе час»), то в разные пошаговые стратегии можно играть параллельно с офисной работой, и тут нужна нативность для мгновенного переключениям между приложениями.
• либо использовать разнообразные эмуляторы, типа PlayOnLinux или даже DOSBox, для совсем древних игр. В большинстве случаев, это, кстати, работает, например, у меня, к моему удивлению, работала даже пятая цивилизация, с настройками графики чуть хуже, чем под DirectX. Но все-таки это как-то не комильфо — и не так эффективно, и возможны странные баги.

Прогресс тут резко пошел за последнюю пару лет, и связан он со Steam — теперь наверно, самой известной инфраструктурой игровой дистрибьюции от компании Valve. Эта компания известна

• и в мире разработчиков, удивительным внутренним процессом, напоминающим то ли раздолбайство, то ли советское НИИ^[2].
• и в мире игроманов, за кучу эпичных бестселлеров, из которых серии Half-Life и Counter Strike знакомы всем, даже далеким от игр.

Но самое известное и важное направление — это построение Steam, собственной игровой инфраструктуры с нуля, от непосредственно железа и приставок SteamBox со Linux-based SteamOS, чтобы не зависить ни от каких вендоров (операционных систем или консолей). И именно эта движуха и заинтересовала Linux-ом игроделов. Да, это не первая система цифровой дистрибьюции с Linux-играми, есть ведь и Desura, но первая, набравшая критическую массу и захватывающая всю вертикаль, от железа до пользователя.

Сложно конечно однозначно сказать, что именно повлияло на игровых производителей:

• Есть факты, что Linux-пользователи Steam оказались даже платежеспособней, чем Windows-стимеры (покупают больше игр, больше платят при распродажах «заплати сколько хочешь»), т.е. потенциально это выгодная аудитория, а не сборище халявщиков. Кстати, интересно посмотреть Steam-статистику → [1], [2].
• Есть мнение, что для игроделов всегда выгоднее разработка под консоли, игровые приставки с фиксированными характеристиками — меньше проблем с зоопарком железа, больше профита, ибо консоли — для истинных геймеров, там больше играют, и тратят деньги на закупку игр или транжирят внутри игры. И чтобы попасть на эту новую консоль, уже сейчас надо разворачиваться и учиться делать Linux-совместимые игры.

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

Смотрите сами, в TOP10 уже 8 Linux-совместимых (да и если смотреть топ игр дальше — чуть похуже, но все равно, Linux-совместимости все больше и больше).

Лично для меня «переломным моментом» стало портирование в мае «Civilization V» (кстати, тут можно публично пообщаться на эту тему с ее разработчиками). А исторические стратегии от Paradox уже давно Linux-совместимы — Crusader King II портировали еще год назад, а Europe Universalis IV уже вышла Linux-рожденной.

Лично я как-то больше любитель неспешных стратегий, вот например, «мой стим»:

Да, проблемы с портированием еще есть — некоторые компании стремятся выпустить линукс-версию «как-нибудь побыстрее, хоть тушкой, хоть чучелом» — и некоторые Linux-порты теряют в качестве: либо это перенос путем встраивания Wine-эмулятора, либо разработку линукс-версии аутсорсят, либо почему-то нет локализации…

Все это огорчает, но тренд очевиден — нет уже никакой эмиграции, и «игровая граница» между Linux и Windows почти стерта — самое важное уже работает под Linux, остальные Steam Windows-игры можно запустить из под PlayOnLinux, и кстати, Steam предлагает еще один вариант Linux-Windows гетерогенности — «стриминг».

Можно продолжать держать Windows-десктоп для игр, а играть в них лежа на диване даже с слабеньким Linux-ноутбуком, при этом десктоп пыхтит и рендерит игровые картинки, а Linux-ноутбук удаленно управляет этой игрой, не напрягаясь и не перегреваясь. Это конечно, не очень подходит к стрелялкам, но ко всему остальному — совершенно замечательно.

У нас Steam беспроблемно устанавливается и работает, в этом уже нет нашей заслуги — если раньше, еще год назад (скажем, для тех, кто в теме, во времена «steamhack-а»), нам приходилось делать какие-то хаки и патчи — подкладывать отстутствующие файлы шрифтов и делать симлинки на библиотеки и т.п. (ведь бета Steam-клиент был «захардкожен» под Ubuntu), то сейчас — это такой же steam, как и у всех.

Кстати, мы думаем, а не стоит ли Steam включить в образ? С одной стороны, вроде идея хорошая, с другой:

• все равно потребуется интернет для инсталляции игр, а тогда можно поставить Steam из репозиториев.
• надо будет договариваться с Valve, обсуждать юридические тонкости — а это непросто. Ибо известно, что почти нереально дождаться от Valve ответов на свои запросы.
• кому-то может не понравится наличие «проприетарщины»…

Но спросим:

Идея включить Steam-клиент в инсталляционный образ дистрибутив ROSA Fresh…

А работоспособность же игр, определяется именно здоровьем графической системы в дистрибутиве. Чтобы все было гладко с X-ами, MESA-библиотеками, и драйверами видеокарточек, чтобы были наложены все важные патчи в непротиворечивой комбинации, и все это было проверено.

Так вот, даже в головном офисе, мы постоянно тестируем нашу графическую подсистему на куче ноутбуков и на тестовом стенде для проверки графических карт, где мы прогоняем нашу коллекцию — видеокарт, от слабенького старья, до современных профессиональных. И это не говоря уже о куче оборудования нашей распределенной по миру QATeam.

При тестировании мы используем и широко известные Phoronix-тесты, так и ручное «проигрывание» Steam-коллекций сотрудников^[3].

Про процесс тестирования, впрочем, надо писать отдельную статью, а пока лишь отметим, что в целом, если технические требования игры удовлетворены, то скорее всего, все будет хорошо, и главная нетривиальность — не забыть поставить правильный видеодрайвер. Скорее всего, наиболее эффективным будет проприетарный драйвер видеокарточки, и для его инсталляции достаточно лишь запустить нашу утилиту XFdrake, которая сама все скачает и настроит^[4].

Мы кстати, размышляем, надо ли как-то напоминать или предлагать запускать XFdrake при первом подключении к сети? Именно в этот момент можно проверить, есть ли проприетарные драйвера AMD/Nvidia для видеокарты, и предложить их использовать.

Идея запускать XFdrake после инсталляции/при первом подключении к сети, если есть проприетарные драйвера для найденной видеокарты…

Так что еще раз отметим

• все что может играть под Linux — популярные open-source игры, все Linux-игры из Steam,

эмуляторы DOSBox и PlayOnLinux — все работает,

• графическую подсистему тестируем, нужные патчи проносим,
• есть XFdrake — утилита, которая автоматически поставит проприетарные драйвера для видеокарт.

И теперь, искренне, а не на правах рекламы, мы можем направить вас в Steam за Linux-играми, в котором до 30 июня идет традиционная летняя распродажа! А многие теперь получают удовольствие именно от покупки («раньше мы играли в игры, за которые не платили, теперь платим за игры, в которые не играем»), делая запас на будущее, для игр с детьми и т.п.

Ну и в конце, для дочитавших — бонус. Краткий обзор Unity of Command — не очень популярной, но увлекательной пошаговой стратегии основных сражений Великой Отечественной Войны.

Игра подробно описана в Википедии, но если кратко — это совершенно нетребовательные к ресурсам «историческо-военные шахматы» на реальных картах ВОВ. Игра сейчас ужасно кажется актуальной — и из-за недавней даты 22-июня, и из-за часто мелькающих сейчас в новостях топонимов «Славянск», «Изюм», «Донбасс» вместе с словосочетаниями «танковая атака», «окружение» и т.п.

Я играл вместе с сыном-младшешкольником^[5], совершенно наглядным образом объясняя-показывая

• и важность снабжения (без него любое сопротивление стихает максимум через неделю), на которую не общают внимания во многих стратегиях.
• тактические приемы танковых прорывов, окружений, блицкригов.
• почему кавалерия вполне рулила в ВОВ, несмотря на танки.
• важность мостов, перекрестков и железных дорог,
• стойкость солдат разных армий («почему под Сталинградом надо прорываться через румынские дивизии»)
• необходимость жертвовать войсками, чтобы выиграть позицию или время…
• географию СССР.

Как это выглядит — проще всего увидеть на короткой записи моей версии прохождения операции «Уран» с сталинградским контрнаступлением и окружением армии Паулюса:

Если не боитесь спойлеров, или вы начали играть, что-то не получается и хотелось бы подсказки, вот «блестящие победы»^[6] в моем исполнении, записанные штатными средствами ROSA Fresh GNOME, см.

• «Crossing the Dnieper» — бои за Днепропетровск
• «Dneper-Donbass» — бои за Донбасс
• «Gallop Star» — Славянск, Изюм, Полтава, Запорожье

А также «Don Offensives», «Race for Rostov», «Orel-Bryansk», «Little Saturn».

Сейчас распродажа, и все это удовольствие со всеми дополнениями можно за 150р.

И наконец, перепись тех, кто дочитал до конца…

Надеюсь, эта статья вас…

1. ↑ За очень-очень-очень редкими исключениями
2. ↑ См. например, [3]; впрочем, лично я ориентируюсь на рассказы моего товарища, поработавшего с ними
3. ↑ Так что если вдруг кто-то увидит у нас играющих в рабочее время — вы все неправильно поняли, мы тестируем.
4. ↑ По юридическим соображениям, мы не можем включать проприетарные видеодрайвера в дистрибутив, поэтому наш мастер настройки XFdrake, выкачивает их с сайтов после установки системы. Ну и отдельный вопрос — это хитрости запуска видеокарт серии Optimus, про которых нужно тоже писать отдельную статью
5. ↑ Дети — отличное оправдание играм во взрослом возрасте, их нужно завести хотя бы для этого.
6. ↑ Все цели взяты вовремя.

С момента выпуска последней русскоязычной заметки про новости ABF в «Точке РОСЫ» прошло уже три месяца. Эти три месяца разработка ABF шла полным ходом (а заодно мы показали ABF на LinuxTag), и пришла пора подитожить достижения за квартал.

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

Непосредственно перед реализацией перезапуска тестов, мы поработали над улучшением этих самых тестов. Теперь помимо проверки возможности установки собранных пакетов в целевую систему, ABF проверяет — нет ли в репозиториях системы пакетов с таким же именем, версией и релизом. Такая проверка позволяет отловить ситуации, когда вы пересобрали пакет, но забыли поднять релиз. Иногда такие проверки неактуальны — что ж, вы всегда можете их отключить, сняв галочку «Использовать дополнительные тесты» при создании сборки.

Помимо тестов, мы поработали и над упрощением процесса сборки, реализовав давно обсуждавшиеся кэшированные chroot-окружения. Теперь при создании сборки вы можете выбрать — создавать ли chroot с нуля или использовать кэш. Кэш немного быстрее, однако есть шанс, что он уже разошелся с базовым репозиторием, и ваша сборка будет невоспроизводимой. Хотя кэш и обновляется ежедневно, такие ситуации все-таки возможно, и мы настоятельно рекомендуем не использовать кэш при сборке пакета, который будет опубликован в официальные репозитории. Более актуальное применение кэшированного chroot-окружения — это ситуация, когда необходимо обновить ключевые пакеты системы (которые, собственно, и входят в кэшированный chroot), сломав при этом на время их зависимости. С помощью кэшированного chroot и контейнеров эта задача решается достаточно легко и быстро, как показало недавнее обновление Perl и всех зависящих от него компонентов (включая urpmi и perl-URPM) в разрабатываемой ветке РОСЫ.

Наконец, мы позаботились об администраторах платформ, которые отвечают за наполнение и целостность дистрибутивов. Маленькое улучшение для них — теперь есть возможность фильтровать пакеты по группе при их добавлении в репозиторий, так что можно не путаться среди кучи проектов с одинаковым названием. Улучшение посерьезнее — возможность ограничить публикацию в репозиторий пакетов и разрешить публиковать только те пакеты, которые собраны из определенных веток Git-репозитория. Например, пакеты для ROSA Desktop Fresh у нас традиционно собирались из ветки rosa2012.1 (а для новой версии Desktop Fresh — из rosa2014.1). Теперь эта традиция зафиксирована на уровне ABF, и собрав пакет из другой ветки, вы обнаружите, что опубликовать его не можете. Такое вот небольшое ужесточение дисциплины, которое на самом деле очень сильно облегчает поддержку дистрибутива.

Прошла зима, настало лето, спасибо па, пришло время для очередного дайджеста «Точки РОСЫ», ведь с момента предыдущего прошло уже больше полгода.

Возможно надо чаще выпускать дайджест, но с другой стороны, те, кто активно интересуется нашей работой могут подписаться на непрерывный поток новостей по RSS/Atom, или в социальных сетях VK и FB, ну а остальным…, мы бы не хотели излишне надоедать.

Впрочем, не упустим случая спросить:

С какой частотой выпускать «Точку РОСЫ»?

Как обычно, это будет и вебжурнал в формате «подборка статей с обложкой», так и так и в олдскульном PDF-файле c сотней страниц. В любом случае — «многобукф», их будет почти двести тысяч, плюс почти сотня иллюстраций.

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

Итак, в девятом выпуске «Точки РОСЫ»:

Фичи и багфиксы

наши наработки и доработки, все для юзабилити и надежности.

Эффективная работа с клавиатурой:

• Типографская раскладка Бирмана
• Кнопка WIN ваш лучший друг! Учим горячие клавиши в GNOME

мышами и тачпадами…

• Раскол Магического Коврика — гладить его двуперстно или по краю? Еще одна гномопроблема решена
• Теперь можно не боятся бесхвостой мыши в GNOME

Нестыдно поставить РОСу, девушкам, детям и прочим родственникам. Все сделано понятней и привычней, и удобно для «домашнего использования»,

• Развиваем и KDE! Нескучные обои — сразу из браузера
• Мы вернули ярлыки на рабочий стол в GNOME
• «Приложение по-умолчанию» в GNOME теперь можно запомнить в момент выбора
• Из всех искусств для нас важнейшим является кино…
• «Не заставляйте меня помнить!» — Свобода пользовательским паролям
• OpenVPN в линуксах — не rocket science, это должен уметь каждый
• Поумневший инсталлятор и больше удобства в консоли

Advanced users, которым нужны все возможности быстрого и надежного Desktop Environment, надеемся, оценят наши доработки рабочих столов:

• Укрепляем GNOME — дело о пропавшей памяти и неучтенных картинках
• Скриншотинг и скринкастинг — что нам пришлось доработать в GNOME Shell
• Допиливаем Gnome Control Center — теперь контроль при любом разрешении
• Тук-тук, откройся, или решена проблема входа в GNOME после засыпания

… и надежное ядро и систему обновлений:

• Ядро nrjQL - "сердце" РОСЫ
• Urpmi.recover - машина времени для пакетной базы
• Графический интерфейс для urpmi.recover
• Мультизагрузочная флешка с несколькими версиями РОСЫ

Ну, а части новых фич не досталось отдельных статей, так, пара слов в описании релиза * ROSA Desktop Fresh R3 «KDE».

Для мейнтейнеров

— новые возможности ABF и полезные утилиты:

• В помощь мэйнтейнеру - spec-cleaner и rediff patch
• Новости ABF - новые возможности консольного клиента, поиск по Advisory и другие радости
• Mib-report - еще одна утилита в помощь мэйнтейнерам
• Визуализация результатов деятельности Updates Builder
• Применение наших инструментов разработчика в апстриме

Конференции

Ну и для всех более-менее связанных с IT, будут интересны наши обзоры и видеозаписи IT-конференций:

• Видеозаписи AgileDays-2014 — я хочу сыграть с тобой в игру…
• ProfsoUX — юзабилити-конференция в SPB. Обзор ProfsoUX-2013, приглашение на ProfsoUX-2014
• Russian Open Source Summit
• FOSDEM 2014 - Свободное ПО в Европе
• OpenMandriva Association - встреча в Праге
• ROSS-2014 — видео докладов опубликовано

Кстати, в нашей медиатеке уже шесть сотен докладов. Заходите, смотрите, комментируйте.

И еще раз напоминаем, что есть и любовно сколоченный PDF со всеми этими статьями.

Ну, а теперь, в послесловии, как раз хотелось бы поговорить насчет того, нужен ли этот PDF, а если нужен, то какой? Год назад, в Blog:Точка Росы/Точка_Росы_№7 мы уже поднимали этот вопрос, и тогда большинство высказалось за полезность PDF. Но сейчас, попробуем поставить этот вопрос еще раз. Если бы наш контент был простой, чисто текстовый — не было бы никаких проблем засунуть его во все возможные форматы, даже в fb2 и epub, но мы включаем и видеоматериалы (и хотели бы делать это больше, включая обучающе-иллюстрирующие ролики), и интерактивные голосования, на результаты которых мы внимательно смотрим, комментарии, и прочий фидбек…, не говоря уже о куче ссылок, которые полезно просматривать при чтении материала, но невозможно, если PDF распечатан на бумаге, или читается в ситуации отсутствия доступа в интернет.

Т.е. теряется многое, а изготовить его, чтобы он был добротный — с нормальной версткой, работающими внешними и внутренними ссылками — это муторный труд по верстке («эй, ты, ободранный — ты идешь с ристалища? Да, верстальщик я… ©»), стоивший немало нервов и времени на, скажем так, тестирование LibreOffice. И непонятно, оно того стоит?

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

PDF-версия для «Точки РОСЫ» — вы будете читать?

Если вы читаете PDF «Точки РОСЫ», как и зачем вы это делаете?

Удобный формат верстки/ориентация страниц «Точки РОСы»?

Шрифт для основного текста — с засечками (serif) или без (sans-serif)?

Если не рассматривать вариант распечатки на бумаги или листающих ебуков, то можно рассмотреть модель публикации в MHTML — тот же HTML со всеми стилями и картинками единым файлом, без необходимости верстать с разбиением на страницы. Смотреть можно во всех браузерах (иногда доставив какое-нибудь расширение).

MHTML-публикация «Точки РОСы» заменила бы вам PDF-версию?

Ну, пока хватит опросов, а если вы дочитали до сюда (wow!), то возможно вам будет интересно читать наши заметки самыми свежими, до дайджеста — тогда, еще раз напомним, как можно на наши новости подписаться:

• RSS/Atom,
• или в социальных сетях
  • VK,
  • FB.

9 мая 2014 года мне довелось встретить не совсем обычно, но символично — почти в центре Берлина, в получасе ходьбы от Рейхстага. А если точнее — в здании Station Berlin, где с 8 по 10 мая проходила очередная конференция/выставка LinuxTag.

LinuxTag — where .com meets .org

Как и на FOSDEM, здесь мы с коллегами из OpenMandriva демонстрировали их дистрибутив и рассказывали, как для его сборки используется наша ABF. В частности, Саша Хрюкин делал доклад про сборку ARM-версии Openmandriva на ABF.

LinuxTag позиционируется организаторами как одно из крупнейших мероприятий в Европе и мире, посвященных свободному ПО. Впрочем, LinuxTag существенно отличается от FOSDEM — если последний является полностью бесплатным для посетителей, то билет на LinuxTag обойдется в немалую сумму — от 50 до 150 евро. Правда, можно бесплатно посещать доклады после 18:00 — но многие интересные доклады проходят раньше, да и большинство стендов после 18:00 уже не работают. Главное же различие заключается в позиционировании мероприятий и целевых аудиториях. Если на FOSDEM одни разработчики рассказывают другим о своих достижениях и наработках, то слоган LinuxTag — «Where .com meets .org» — однозначно говорит, что цель конференции — свести вместе представителей бизнеса и сообщества.

Набор спонсоров у LinuxTag солидный, что не мешает брать от 50 до 150 евро за билет

В общем, Linuxtag скорее похож на наш ROSS. Правда, по масштабам и насыщенности LinuxTag от ROSS отличается примерно так же, как FOSDEM от Конференции разработчиков свободных программ — то есть на пару порядков. При этом несмотря на статус международной конференции, LinuxTag все еще остается во многом ориентирован на немецкую аудиторию — около половины докладов в этом году были на немецком языке, а многие стенды были посвящены внедрению открытых решений в немецких компаниях и учреждениях. Так что разница в масштабах ROSS и LinuxTag вполне отражает различия в использовании СПО в двух странах.

Нацеленности LinuxTag на бизнес нашла отражение и в темах докладов — технических презентаций было гораздо меньше, чем на FOSDEM, зато было больше рассказов о решениях и проектах по развертыванию всевозможных инфраструктур на предприятиях и о внедрении тех или иных технологий в реальные бизнесс-процессы. Например, как перейти на LibreOffice или как мониторить состояние машин с помощью Icinga — форка Nagios, чья история наглядно демонстрирует специфику разработки открытых проектов (несколько длинное и туманное, но интересное изложение истории можно найти здесь).

В первый день шарики были только у OpenMandriva, а на второй день идею подхватили многие стенды и даже сами организаторы

Из технических тем, как ни странно, наиболее активно затрагивались низкоуровневые вещи — ядро, драйвера и прочие основополагающие системные компоненты. Чего-то принципиально нового услышать не удалось, но немало людей пришли посмотреть на ведущих разработчиков Linux — в частности, на Грега Кроа-Хартмана (Greg Kroah-Hartman), рассказывавшего о разработке непосредственно ядра, или Ленарта Поттеринга (Lennart Poettering) и Кея Сиверса (Kay Sievers), подготовивших презентацию про kdbus — реализацию механизмов D-Bus на уровне ядра. Интересен был и доклад про Coreboot — свободную реализацию стандарта UEFI, используемую в Chromebook, наглядно демонстрирующую, что реализация UEFI совсем не подразумевает привязку к конкретному вендору.

Естественно, не остались без внимания модные нынче облачные технологии (в частности, целая секция была посвящена OpenStack) и вообще Web-разработка. Из последней области интересным был рассказ про WebODF — Javascript-библиотеку для работы с документами ODF, — а также доклад про WebRTC. Точнее, в последнем докладе рассказывалось в основном про JitsiMeet — открытое решение для проведения видеоконференций. Тема видеоконференций в Linux (а точнее, свободных инструментов для их организации) очень актуальна, и сообщество постепенно развивает свои аналоги сервисам Google или Skype. Кстати, непосредственно Jitsi есть в репозиториях РОСЫ, так что можете его попробовать. Программа написана на Java и интерфейс красотой не блещет, но с функциональной точки зрения приложение вполне рабочее.

В этом году LinuxTag был совмещен с конференцией Android-разработчиков Droidcon, поэтому часть докладов была посвящена разработке мобильных приложений, а в холлах конференции можно было ознакомиться с новейшими предложениями в этой сфере от BlackBerry, Sony и Intel.

Возможно, было еще что-то очень интересное, что я пропустил — поскольку многие презентации были на немецком, в котором я не силен. Желающие могут изучить подробную программу выступлений; там же можно найти аудио- и видеозаписи выступлений.

LXQT в OpenMandriva уже работает и использует тему РОСЫ

Интересно, что несмотря на нацеленность на бизнес, на LinuxTag не было представлено вендоров коммерческих дистрибутивов (прежде всего, Red Hat и Novell). Вместо этого, были стенды их коммьюнити-версий — Fedora и OpenSUSE, которые соседствовали со стендами Debian, ReactOS, и OpenMandriva. Было несколько докладов от представителей RedHat, но их охват был существенно уже, чем на FOSDEM. В частности, ничего не говорилось про Katello или Foreman, хотя, казалось бы, эти темы вполне подходят для LinuxTag. Впрочем, был доклад от Inovex про развертывание OpenNebula с помощью Foreman, демонстрирующий готовность Foreman для использования в реальных проектах.

К тому же были представлены другие интересные проекты схожей направленности — например, Univention, предлагающий собственный аналог Active Directory. По словам представителей компании, их решение полноценно интегрируется с AD и поддерживает не просто аутентификацию пользователей, но и групповые политики и прочие вкусности. Представители проекта Fully Automatic Installation (FAI) рассказывали об инструментарии для автоматической установки Linux на множество машин, а разработчики YADT («an Augmented Deployment Tool»; впрочем, явно напрашивается расшифровка «Yet Another Deployment Tool») демонстрировали, как управлять этим множеством машин (с упором на то, как корректно перезапускать множество зависимых сервисов при обновлении). Эти проекты, возможно, не так раскручены, как творения RedHat, но определенно заслуживают внимания.

Опять же в противовес FOSDEM, посетителей на стендах было не очень много. Приятно, что сайт OpenMandriva явно не уступал по популярности остальным — впрочем, не только из-за технических характеристик дистрибутива, но и из-за шариков, приводивших посетителей к нашим столикам. Однако и некоторые технические моменты вызывали живой интерес пользователей — так, NicCo демонстрировал свои навыки настройки VMware в РОСЕ и OpenMandriva, запуская одновременно разные вариации Mac OS X, Windows и Linux, да еще так, что в каждой из гостевых ОС можно было вполне спокойно смотреть видео с YouTube (естественно, со звуком). Если кому-то захочется это повторить, то процесс настройки описан в нашем форуме.

К началу LinuxTag был приурочен выпуск OpenMandriva Lx 2014.0, незадолго до которой вышел ROSA Desktop Fresh R3, так что посетители могли взять образы со свежими версиями наших дистрибутивов. Одной из основных нашей целей было привлечение не просто пользователей, но разработчиков. Насколько это удалось — время покажет, но интерес со стороны сообщества определенно есть.

Наконец, было бы странно оказаться в Берлине на 9 мая и не посетить ряд примечательных мест — в первую очередь, мемориал советским воинам рядом с Рейхстагом. И еще раз убедиться, что состязаться в качестве ПО, а тем более — разрабатывать это ПО в составе большой международной команды, все-таки гораздо приятнее и безопаснее, чем в совершенствовании средств собственного уничтожения.

Мемориал советским воинам в Берлине

Не секрет, что многие разработчики РОСЫ стараются сделать что-то полезное для дистрибутива каждый раз, когда у них появляется свободная минутка. Впрочем, даже если у вас не минутка, а целых полчаса, но при этом нет под рукой установленной РОСЫ, то существенную часть свободного времени придется потратить на скачивание iso-образа и установку системы хотя бы в виртуальную машину. Конечно, не все активности требуют установленной системы — можно поотвечать на вопросы в форуме или пособирать пакеты на ABF, но именно разработку все-таки гораздо проще вести внутри реальной ОС.

Хорошая новость — теперь у нас есть инструмент, который позволит быстро развернуть chroot-окружение с РОСОЙ внутри любой системы, где можно делать этот самый chroot. Для работы инструментария достаточно иметь Shell и Python (даже наличие rpm не является обязательным!). Инструмент называется Rosabootstrap и заполучить его можно на ABF — https://abf.rosalinux.ru/soft/rosabootstrap.

Если у вас установлен git, вы можете склонировать проект:

$ git clone https://abf.io/soft/rosabootstrap.git
$ cd rosabootstrap

а если не хочется клонировать, можно просто скачать и распаковать архив с актуальными скриптами:

$ wget https://abf.io/soft/rosabootstrap/archive/rosabootstrap-master.tar.gz
$ tar xzvf rosabootstrap-master.tar.gz
$ cd rosabootstrap-master

И запустить скрипт rosabootstrap с необходимыми параметрами (полный список которых вы можете узнать, запустив этот скрипт с опцией «-h»):

$ sudo ./rosabootstrap -d -a x86_64 -v 2012.1 -c 2012.1 -m http://mirror.yandex.ru/rosa/rosa2012.1/repository/x86_64/main/release

Вот и все — после завершения работы скрипта с приведенными выше параметрами, у вас должна появиться директория 2012.1, в которую и необходимо сделать chroot::

$ sudo chroot 2012.1

Пару недель назад прошла конференция ROSS-2014, или более звучно → Russian Open Source Summit-2014. Собственно мы недавно зазывали на нее, и публиковали обзор наших видеозаписей прошлогодней ROSS-2013, ну и сразу после этого занялись сьемкой-монтажом-публикацией докладов этого года («еслинемытокот?»).

По прошедшей конференции уже можно почитать вал отзывов, как от обычных блоггеров, так и от настоящих IT-журналистов → [1],[2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12] и посмотреть фотки — [13], [14].

Не в силах пока конкурировать этими профессиональными обзорами, заметим пару кратких наблюдений:

• Это не веселая конференция разработчиков-тестировщиков-дизайнеров, с котегами на слайдах и играми на Xbox в кулуарах — тут собрались серьезные, возможно немного скучные дядьки — топменеджеры, чиновники, юристы, эксперты-архитекторы крупных вендоров.
• Но, в отличие от прошлого года, не было совсем уж «свадебных генералов», которых лучше не пускать ни на свадьбу, ни близко к ITшным темам.
• Участники — тоже серьезная публика «в пиджаках», молодежных гиков, в отличие от прошлого года, было совсем мало.
• Темы «Open-Source и бизнес», «Open-Source и государство» — хайп вокруг них был несколько лет назад, в прошлом году, наверно был закономерный минимум, ну а сейчас, в связи с кучей громких политических и ITшных событий, наконец-то пришло осознание глобальных рисков, «черных лебедей», от которых раньше привычно отмахивались. И что надежность софта требует, как необходимого условия открытость кода и стандартов, но что этого совсем недостаточно^[1] — нужен национальный бизнес вокруг этого.
• Эти темы плотно обсуждали на специально организованных пяти дискуссиях — да, понятное дело, наверно любой из читающих эти строки, уже имеет свое мнение по теме (от «все плохо» до «мы еще покажем»), но гораздо интересней послушать, что думают инсайдеры процесса, лица принимащие решения на корпоративном или государственном уровне.
• И, хотя многие доклады можно расценить, как «маркетинговые» (что обычно, на IT-конференциях не любят), здесь тема «Что вы сделали на базе open-source, и как вы это продаете» — она наоборот, приветствовалась.
• Да, некоторых конечно очень бы хотелось прокачать в искусстве публичных выступлений и оформлении слайдов, но мы не в программном комитете, а большинство выступающих, скажем так, уже выбрали свой стиль.

Впрочем, мне тут говорили, что 99% всех пользователей социальных сетей не могут осилить видео дольше трех минут… ну вот, вся конференция за две минуты — может это видео^[2] передаст стиль и ощущения?

Мы же, своими ограниченными ресурсами, постарались донести все это, так, чтобы было удобно смотреть — для всех этих пяти секций мы записывали и экран, и несколько планов (крупный-общий-зал), и несколько источников звука… и сколотили из этого качественный информационный консерв, дающий эффект присутствия.

Итак, встречайте → ROSS-2014

Как обычно, мы даже несколько взбодрили доклады ускорением темпа (может быть недостаточно?), к каждому докладу подшиты слайды, развернутые в инфографику картинок, т.к. не было изначально аннотаций — к большинству докладов подшиты отзывы-обзоры от профессиональных журналистов, и самое главное — вычислены все докладчики, и за пару кликов их можно найти их профили в социальных сетях, профессиональных или не очень (ну или, на худой конец — email).

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

• В одном из залов кто-то закрыл нашу программу-скринкастер — пришлось все слайды за день «прибивать руками», и до сих пор, пока не доделан один доклад, где кроме слайдов была еще сложная анимация (ужас-ужас...).
• Мы старались записать максимально качественный звук, и в крупных залах, где обычно лютует эхо, записывали с микрофонного канала на диктофоны — увы, местами там наблюдались адские помехи, возможно надо переключать на звук с камер.
• А в один из небольших залов, где звук записывали «с воздуха», оказалось, что он напрямую прилегает к кухне, и грохот тарелок сопровождал несколько докладов… — это тоже наверно можно починить, можно снять более примитивный звук с фотоаппарата, который был в глубине зала…
• На паре докладов отключилась HD-камера крупных планов (это точно не наша диверсия, ибо случилось именно на наших докладах :()

Да, пока мы выложили, бета-версии видео — они вполне смотримы, хотя в них возможны проблемы — рассинхрон, неидеальный звук, или докладчик что-то сверхважное показывает указкой на экране, а он закрыт скринкастом, ну или что-то еще — все не предусмотреть.

Тут мы хотим использовать принципы Open-Source тестирования свежих версий на опытных пользователях, и как в случае с AgileDays, призываем всех смотреть, комментировать, писать о проблемах в видео и свои замечания по теме — как обычно, можно писать в своих блогах, а сбрасывать только ссылку. Большую часть проблем решить пока возможно — взять звук с другого, менее крутого источника (но, видимо стоит, если с основными источниками проблема), сменить план, подкрутить синхронизацию. Ну, а если видео НИКТО не смотрит, то тут будет опять классический дзен-вопрос «о багах в программе, которой никто не пользуется» — их и не надо фиксить.

Активных комментаторов ждет награда — гаджеты, сувениры, признание. Буду даже конкретней — первому тому, кто за бета-период отсмотрит и откомментирует 80% докладов — лично подарю ноутбук с РОСой в подарок. Ну да, а чтобы не случилось классического «Пастернака не читал, но осуждаю» — паттерн большинства комментаторов околоопенсорсных ресурсов, я настоятельно рекомендую при просмотре собирать голубенькие коды, которые будут случайно появлятся на пару десятков секунд по центру видео (и это будут слова, связанные с опенсорсом), и указывать их в комментариях — это будет некоторым доказательством, что вы просмотрели таки видео.

Удачного просмотра, ждем комментариев!

Надеюсь, эта новость вас…

1. ↑ История с Heartbleed это вполне показало. Кстати, «наши сердца не кровоточат» — эта уязвимость коснулась только ROSA Fresh, где была исправлена за считанные часы, наш ROSA «Marathon» LTS этот баг не затронул, ну а в сертифицированных версиях, подобный баг вообще невозможен — там и сертифицированная криптография, и жесткие права на межпроцессное взаимодейстсвие, и очистка памяти — вытащить секретные ключи из памяти совершенно невозможно.
2. ↑ Музыка там тоже «open-source»

В процессе разработки операционных систем наши разработчики и мэйнтейнеры используют огромное количество разнообразных вспомогательных инструментов (для сборки пакетов, анализа качества кода, анализа изменений и т. д.). Большинство из них — это свободные давно зарекомендовавшие себя инструменты, доступные почти в любом репозитории, такие как, например, rpmbuild, gcc, rpmlint, check, valgrind, diff и др. Но иногда встречаются задачи, для решения которых инструментов еще не было создано. В таких случаях мы создаем свои собственные решения для наших разработчиков. В случае, если эти инструменты могут быть полезны не только для нас, но и для сообщества, мы публикуем их исходные коды.

Примером одной из нестандартных задач был анализ обратной совместимости API/ABI системных библиотек в нашей операционной системе РОСА. Поскольку количество библиотек в системе достигало нескольких тысяч, то отслеживать вручную изменения во всех было слишком неподъемной задачей. Поэтому мы разработали инструмент ABICC, который может производить анализ совместимости изменений в автоматическом режиме. Исходные коды этого инструмента были открыты и постепенно все больше и больше разработчиков библиотек в апстриме пользуются этим инструментом для контроля совместимости API/ABI интерфейсов. В результате этого, нашим мэйнтейнерам библиотек легче обновлять их в системе.

Примерами библиотек, успешно использующих наши инструменты, являются: Pacemaker, MySQL++, Wireshark, Glibc, Enlightenment, libDAP++, libapt, Barry, PySide, PLplot и др. Также довольно большое число разработчиков библиотек предпочитают пользоваться нашим специальным сервисом Upstream Tracker, где они могут бесплатно добавить любую библиотеку и следить за изменениями в ее API/ABI интерфейсе. Примерами таких библиотек являются ImageMagick, V8 и др.

С нашими наиболее популярными open-source инструментами для разработчиков можно ознакомиться здесь. Среди них представлены следующие инструменты:

ABICC

инструмент для анализа совместимости API/ABI системных библиотек.

PkgDiff

инструмент для классификации файлов в пакете и визуализации изменений.

Java ACC

аналог ABICC для Java библиотек.

API Sanity Checker

автоматический генератор автоматических модульных тестов для Си/C++ библиотек.

ABI Dumper

извлечение ABI-интерфейса из debug-информации библиотеки.

Vtable Dumper

извлечение структур виртуальных таблиц из бинарных файлов библиотек.

Мы призываем использовать наши инструменты в апстриме. Это позволяет улучшить качество и стабильность API/ABI интерфейсов. А нам это облегчает и без того сложную работу наших мэйнтейнеров при последующем обновлении библиотек.

В конце марта в Москве прошла конференция AgileDays-2014, посвященная методам продвинутой разработки, объединенных ценностями Agile Manifesto. Можно пафосно распинаться про ее глобальность, межгалактичность международность, но вот простые факты — почти тысяча человек, два дня, семь десятков докладов в пяти треках… это действительно было круто.

Темы — как всевозможные вопросы продвинутого менеджмента проектов («Мотивация», «Управление продуктами», «Планирование и оценки», «Организация») — в общем, как делать что нужно, эффективно, без насилия и с песней, даже, если для этого вообще нужно отказаться от всего перечисленного — оценок, мотивации, и менеджмента как класса.

Плюс — всевозможные инженерные практики эффективной разработки — тут и Test-Driven Development и Domain Driven Design, и Pair Programming и CQRS-архитектура приложений, Continuous Integration & Deployment и прочий DevOps во всех видах…

В целом, тут собрались самый разные участники — от корпоративщиков, сытых, но скучающих, до вечноголодных упоротых стартаперов — Agile-подходы рулят везде, даже в таких консервативных областях, как 1C-development (да, был доклад и про это).

И если еще недавно, многие, надув щеки, презрительно цедили «Agile? У вас секта… У вас нет по настоящему больших проектов… Это для мелких лохов, а у нас Enterprise… Это для скучного Enterprise, а у нас Продукт… Это для софта, а у нас ВеликийСистемноинженерныйПроектВека… Это для анархистов, не осиливших мудрости PMBOK, SWEBOK, BABOK, и кому не дадут бабок… », то сейчас видно — новые подходы к разработке просто ВЕЗДЕ, и даже нет смысла спорить и переубеждать консерваторов, ведь, как известно «выживание не обязательно». Просто самые продвинутые разработчики и менеджеры не пойдут в компанию, где «угорают по хардкору … и царит дух старой школы»™, а неповоротливость на все более динамичных рынках может убить даже старожилов — в IT не очень работают традиции стабильности «занимаемся программированиемѣ с 1913 года».

Доклады были реально круты — программный комитет^[1], отобрал лучших из лучших, самых опытных специалистов и крутых спикеров — прошло время скучных конференций советского стиля, тут же отзывы в целом таковы:

Очень крутые блиц-доклады на #agiledays, как будто на TEDe сижу. ©

Можно почитать более подробные отчеты: [1], [2], [3], [4], [5], [6], посмотреть фотографии [7] или двухминутное видео [8], но, весь этот жанр, «Wish you were here/Ах, как там было хорошо, жаль, что вас не было», несколько обидный для тех, кто там не был. И даже для тех, кто был, но не смог посетить все интересующие доклады — тут было пять треков, и хотя программа была тематически выровнена, не было конкурирующих докладов на схожую тему в одно и то же время, куча народу жаловались на невозможность разорваться.

Good news, everyone!™

Мы организовали и видеосьемку! Снято все, за исключением нескольких игровых мастер-классов — по нашему опыту, в таких интересно участвовать, но смотрят их мало :(.

Как обычно, самые лучшие стандарты информационного видео — монтаж с точной записью экрана, плюс чередование крупных и дальних планов, видна реакция зала^[2], по возможности звук с микрофона докладчика, ускорение скучных докладов до бодрого тема лучших спикеров TED, в общем, все как мы любим.

Да, были и проблемы^[3] — в паре залов было темно на сцене при ярком экране… — плохо видно докладчика… иногда не очень хорошо получился звук^[4]. Но в любом случае, все вполне смотримо. Более того, в рамках первоапрельской шутки, доклады были выложены в специально изуродованном низком качестве, но к моему ужасу, народ не понял шутки, и начал смотреть, благодарить и распространять…

На самом деле, тут я подумал, что просто опубликовать, было бы скучно, и решил сделать это в Agile/Lean-стиле. А именно — итеративно, со сбором пользовательского фидбека, и геймификацией.

Первый первоапрельский драфт был для совсем нетерпеливых, теперь все^[5] доклады опубликованы в бета-версии.

Еще раз — это тут Видео AgileDays-2014.

Оно все вполне смотримо, но там встроена отладочная информация («маркеры времени»), и возможно их еще можно будет отредактировать, вырезав секретное или неудачное, поправить планы и т.п.

А спустя месяц наверно (ну, как пойдет), будет выложена уже окончательная версия.

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

Нет, это не страшная игра на выживание, это Win-Win игра, и я сразу объясню, кому и что тут интересно.

Да, мы хотим, что бы эта конференция стала не только местом тусовки единомышленников, а стала «Конференцией 2.0», распределенной в пространстве и времени, собравшей в интернете на порядок больше зрителей, и с сontinuous обратной связью. И нам всем, очень важен feedback:

• Докладчикам, чтобы увидеть ошибки и получить новые идеи по теме — ведь многие из них будут рассказывать эти доклады и на других конференциях.
• Программному Комитету — мы уже собирались на ретроспективу, и будем делать это еще — чтобы понять, где мы ошиблись — в выборе докладчика или темы, где мы не доработали, рецензируя слайды или аудируя (или недоаудируя) докладчика.
  • У нас есть первоначальный простой фидбек в виде олдскульного голосования разноцветными стикерами, по нему мы уже видим неожиданные результаты (потенциально сильный доклад собирает много красных стикеров), но понять — почему, этот инструмент не дает.
  • Еще будут обработаны электронные анкеты участников… но в любом случае, это фидбек сильно ограничен и аудиторией, и нашей планировкой докладов по трекам — возможно интересный доклад попал в малый зал (из-за различных ограничений, включая расписание докладчика), и не собрал ожидаемую аудиторию… в общем, тут же будет равноценных доступ к любому из докладов, и нам интересны и ваши оценки, и желательно именно отзывы. Да, многие писали более-менее полноценные обзоры, но, увы, таких людей мало, а некоторые из них уже стали «профессиональными зрителями конференций», посещающими по десятку конференций в год, несколько пресыщенными («на мой взгляд, ничего нового-с…»), и оторванными от практики,… А хотелось бы именно Труѣ-фидбека, особенно от тех, кто нечасто бывает на конференциях по разработке.
• А еще лично мне, чтобы узнать, есть ли какие косяки в видеомонтаже — рассинхрон потоков, или выбранный план скрывает что-то важное («докладчик явно что-то важное показывает на экране указкой/рукой, а экран/рука закрыт скринкастом»), или тема и мысли ОК, но, скажем темп изложения усыпляющий — можно ускорить. Или наоборот, слишком шустро, не поспеваю — можно замедлить.

Или случайно спалили что-то секретное на слайдах (на прошлом AgileDays было, и на этом уже). Или про что-то проговорились («А я не знал, что записывают…»). Все это пока можно починить.

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

Так какие же правила игры?

• Там, на каждой странице доклада из категории прикручена самая популярная система комментирования DISQUS — в нее можно логиниться любыми соцсетями и т.п., если их нет, полезно в ней завестись, все равно она прикручена к 80% всех комментируемых сайтов в инете.
• Просмотрев доклад — напишите хотя бы одноабзацный отзыв. На самом деле никаких ограничений нет, можно писать и кратко, можно и романы, но текущий ужасный тренд в том, что многие разучаются выражать свои мысли, заменяя это простым лайканьем, ознакомившись с заголовком, и хотелось бы этот тренд переломить. Т.е. да, можно писать и короче, можно и длиннее, можно написать отзыв в своем блоге, а сбросить только ссылку — как вам удобно. Заодно можно указать и на вышеперечисленные проблемы, если было что-то не ОК, причем указать точно — ведь во всех видео сейчас вшиты временные маркеры, однозначно определяющие момент (Не «Вырежи, где я где-то во второй половине доклада проговорился о наших заказчиках», а «плиз, вырежите 7:34:56-7:35:10»). И т.п.
• Особо я хочу выделить тех, кто действительно просмотрел весь доклад, ведь очень многие готовы написать отзыв вообще по заголовку и аннотации («Пастернака не читал, но осуждаю…»). Тут есть хитрость — во все видео вшиты в случайных местах слова, связанные с Agile-тематикой. Эти слова появляются на пару десятков секунд фиолетовым цветом по центру видео. Если вы просмотрели видео и увидели это слово — запишите его, и укажите его в комментарии — такие комментарии я выделю особо.

Ну и геймификация такова — я отберу топ тех, кто просмотрит больше всего видео, откомментировав его («собирая слова»), и обязательно придумаю, как нестыдно, материально или нематериально наградить. Среди идей — и «доски почета/hall of fames», и может удастся выбить скидки на следующее посещение AgileDays, а может целое приглашения, или приглашение на другие конференции пораньше, ну и я разыграю какой-нибудь набор полезных в образовании гаджетов — диктофоны например…, что-нибудь USB-полезное, +рюкзаки/сумки с символикой AgileDays… единственное с предметами может быть геморрой с пересылкой в другой город, очень хотелось бы обойтись самовывозом.

Собственно, в такие игры я играю впервые, не знаю — сработает ли, мне бы очень хотелось бы, чтобы да. Игра будет наверно в ближайшие пару недель, или целый месяц, это особенно ценное время, чтобы Программный Комитет и авторы могли осмыслить по свежим следам результаты, косяки видеозаписи, по крайней мере, в интересных докладах^[6] были найдены. Потом я залью уже окончательные, возможно исправленные версии без временных маркеров.

Может действительно окажется, что комментировать непросто… ну в любом случае можно также и шарить-лайкать кнопками, это все тоже наверно хорошо и полезно, но как-то геймифицировать лайки мне кажется неэтичным — поэтому лайкате и шарьте только, если вам действительно понравился доклад.

Такие дела, если есть предложения по правилам — тоже welcomed, но мне кажется, идея неплохая, явно типа Win-Win.

Удачного просмотра!

Надеюсь, эта новость вас…

1. ↑ Где тоже были наши
2. ↑ Особо рекомендуем докладчикам, чтобы работать над ошибками
3. ↑ А еще я куда-то потерял две камеры и фотоаппарат…
4. ↑ Очень хотели везде записать звук с микрофона, но тут нам выкатили оху нечеловеческий ценник — 800руб/час/трек за запись звука, и записать идеальных звук удалось только в одном зале, несанкционированно подключившись к системе
5. ↑ Есть еще парочка, которых нужно доделать, это вопрос пары дней
6. ↑ Если будут косяки в докладах, которых никто не захотел смотреть… ну значит так звучит ломающееся дерево в лесу, в котором никого нет

В пятницу, 11 апреля, будет проходить наверно крупнейшая российская конференция по свободному софту — Russian Open Source Summit.

Крупнейшая — по количеству участников, ибо посещение бесплатное, сняты огромные залы в крутом отеле в центре Москвы, там полдесятка треков, и бесплатный обед и плюшки.

Что же там будет классного (кроме плюшек и обеда) — сложно сказать уверенно, но зато, мы можем рассказать и показать, что там было в прошлом году.

Ведь за всю историю конференции, там не велась съемка, кроме как прошлом году, когда нас внезапно (вечер до) позвали снимать, и мы попробовали запечатлеть доклады.

Несмотря на кучу накладок^[1] все доклады записаны, и вполне смотримы^[2].

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

И так как боюсь, все равно получится «многобукф» — скажу главное — не важно, какие будут доклады, приходите все равно. Будет и тусовка, там будем мы со своим стендом, и парой докладов, можно будет пообщаться-пожаловаться, увидеть, что «слухи о моей смерти несколько преувеличены», предложить интересные идеи , узнать, почему это не работает…

Ждем вас! Только не забудьте зарегистрироваться — Russian Open Source Summit.

А теперь поехали, обзор прошлогодних докладов.

→ продолжить чтение…

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

Все это поддержалось тотальной WiFi-зацией пространства, и в целом, все привыкли, что Интернет — это некое единое магическое пространство, платоновский мир идей, к любому объекту которого которому можно всегда подключиться, если на ноутбуке-планшете-смартфоне горит значок сети или иконка веселой антенны.

Однако мир меняется, разные границы появляются и в интернете, и все чаще, можно получить удивительные ошибки «Ресурс заблокирован», «Это видео недоступно для вашей страны» и т.п. Кто только этим не занимается — Netflix и Hulu не хотят, даже за деньги^[1] делиться контентом с Восточной Европой и Азией, ну, а про а про наши интернет-блокировки решениями районных судов тоже наслышаны все.

Впрочем, иногда ограничение доступа вполне оправдано, когда речь идет о доступе к корпоративному интранету — только доверенные сотрудники должны иметь к нему доступ. Но ведь этим сотрудникам хочется удобства и постоянного доступа, и не с привинченного к полу громоздкого десктопа в унылом офис-центре, а с своего любимого лептопа, в любой момент, из дома, вайфайзированного кафе или парка, и прочего цивилизованного пространства («дом, это то место, где WiFI подключается автоматически»). В общем, BYOD-тренд заруливает.

Все эти задачи — как протуннелировать в другую сеть, и стать для интернета «голландцем» или «американцем», или наоборот, попасть в свою внутреннюю сверхзащищенную сеть, или даже просто — вырваться из недоверенной сети, где твои пароли могут прослушать — решают VPN-технологии, и здесь мы не будем говорить прописных истин о том, как это работает, почему это надежно, о тонкостях алгоритмов шифрования, сертификатах, heartbleed, капусте, Королях и т.п., а расскажем о том, как это для выглядит для пользователя в наших дистрибутивах.

Да, подавляющее большинство VPN-сетей кстати тоже сделаны на базе open-source технологий OpenVPN^[2], и там очень много гитик, как все это настраивать — сертификаты, ключи, конфиги, под винду надо ставить специальный софт, с глючными драйверами, в общем, сам в свое время писал регламенты подключения удаленным сотрудникам, ставил все это, офигевая от сложностей объяснения, ну а большинство пользователей запомнили, что «випиэн» — это какой-то рокетсайнс, и надо звать бородатых чуваков в растянутых свитерах^[3], ибо само не заработает.

В GNOME же все это работает из коробки! И не нужно знать практически ничего.

Допустим, вы решили вырваться в Атлантический Интернет — арендуете за $1/месяц какой-нибудь ProstoVPN^[4], вам присылают набор каких-то файлов (файл-конфигурации и всякие ключи — не глядя положите-распакуйте их куда-нибудь, где вы их не сотрете, и запустите «Настроить сеть» → «+» → «VPN» → «Импортировать из файла»

Тут уже выберите файл с расширением «*.ovpn» или «.config», это зависит от фантазии сисадминов или провайдера, и если есть выбор между «что-то TCP» и «что-то UDP», то, в любой такой непонятной ситуации выбирайте «что-то TCP».

Все, ничего не трогая руками, можете смело жать кнопку «Добавить».

Ура! У вас в выпадающем списке сетей появился еще один слайдер-переключатель для защищенной сети, и достаточно переключить его, как иконка сети превратится в замочек, а вы, согласно сервисам, типа http://internet.yandex.ru, смените место жительства.

Итак, все замечательно, работает из коробки, зачем же я начал писать статью… А, конечно нет. Не все. Без напильника и наших доработок конечно не обошлось.

Да, обычный VPN, когда весь трафик мы выбрасываем через выбранную точку, работает ОК, но при доступе к корпоративным частным сетям нужно несколько другое — чтобы только в корпоративную сеть шли только обращения за внутренними сайтами, всякими там *.office.supercompany.ru, а гугл-яндекс-вконтактик по-прежнему работали с вами напрямую.

Технически, это означает, что маршрут по умолчанию не должен меняться (см. первую строчку таблицы)

[stas@stas-HP2740p-grey test-openvpn]$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.168.0.1      0.0.0.0         UG        0 0          0 wlan0
10.9.0.0        10.9.0.5        255.255.255.0   UG        0 0          0 tun0
10.9.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0

А практически, для этого в GNOME Network Manager нужно было поставить одну галочку:

Но это не работало! Галочку «использовать это подключение только для ресурсов локальной сети» ставили, но она не запоминалась, и соответственно, все работало по прежнему, через… туннель.

Пришлось разбираться и фиксить — оказалось да, глупая UI-ошибка, когда изменение этого чекбоксика формой не отслеживалось, это изменение не запоминалось, ну и так далее.

Good news, everyone!

UX Team пофиксил и это, и у нас OpenVPN в GNOME работает из коробки и как должно — просто, легко, и надежно.

А, что касается KDE — там тоже все ОК, допиливать не пришлось, и примерно также.

Тоже не надо забывать установить правильную галочку про частные сети, и про использование TCP-соединения:

Здесь могла бы быть реклама вашего VPN-сервиса

Надеюсь, эта новость вас…

1. ↑ Когда я тестировал работоспособность платных DRM-каналов, см. Blog:Точка Росы/Из всех искусств для нас важнейшим является кино…, я оплачивал доступ к этим ресурсам… и так получилось, что как-то забыл отписаться от Hulu — и оно несколько месяцев доило мой карточный счет, а чтобы отписаться, пришлось пройти нетривиальный квест… :(
2. ↑ И кровавыми слезами плачут пользователи разных малораспространенных вендорских решений
3. ↑ Ну или тыжпрограммиста
4. ↑ Это бесплатная реклама

Обои для рабочего стола. Казалось бы, элементарная вещь, но сколько шума и проблем связано с ними у линукс-дистрибутивов.

С одной стороны, Труѣ-линуксоиды считают недостойным само размышление на эту тему, что лучше всего отражено в следующем коане:

Как-то Сисадмин спросил:

— Учитель, не желаете ли красивую картинку для вашего десктопа? У меня есть коллекция «обоев для рабочего стола» со звёздным небом и моральным законом.

— Почему ты думаешь, что мой нынешний «wallpaper» хуже? — спросил в ответ Инь Фу Во.

— Я не знаю, какая у вас картинка сейчас. Я никогда не видел вашего десктопа. У вас всегда открыто множество окон.

— Я тоже его никогда не видел, — сказал почтенный Инь. — Я работаю.

©

С другой — почему-то выбор обоев для дистрибутива считается чуть ли не системообразующим фактором, порождающим кучу самоделок с «нескучными обоями», ну и часто, при поверхностных^[1] обзорах дистрибутивов, основное все впечатление по дизайну обосновывается скриншотами прибитых по умолчанию обоев, что на самом деле, также осмысленно, как оценивать покупаемую квартиру по обоям.

С третьей — невыразимый ѣ-стыд охватывает, когда ставишь KDEшный Linux девушке/жене и видишь, что самое первое, что делает типичный «female user» — это пытается придать уют, пытаясь сменить обои рабочего стола, неважно, были ли они специально страшные, или специально разрабатывались целым отделом дизайна. И не может. Ведь те, кто меняет обои в KDE, знают, что это совершенно неочевидный процесс, который нельзя понять, можно только запомнить, и состоит из странных действий, связанных с файловой возней («файловой» — значит уже неочевидной «нормальному пользователю») или какими-то странными KDEшными каналами их получения.

При том, что даже ребенку, выпущенному в интернет, понятно, что именно там находится тот самый неисчерпаемый источник красивых обоев (Яндекс, Google), где можно их выбрать и по ключевым словам, темам, популярности и адаптированным под нужное разрешение. Впрочем, в интернете уже все хранят даже семейные фотоальбомы, если кто захочет радовать себя фотками родных на рабочем столе — он тоже будет ставить их из браузера.

И не нужно ни странных методов настройки, закопанных в глубины центров управления, ни странных «wallpaper stor-ов», нужно лишь одно, чтобы работала стандартная функция браузера, контекстое меню на картинке → «Сделать обоями рабочего стола».

Такая штука уже работала в GNOME (хотя не совсем ОК, об этом дальше), но ее не было в KDE, а соответствующие баги мирно тухли уже лет пять.

Good news, everyone!

Наш KDE-эксперт, Андрей «Pulfer» Бондров, наконец-то закрыл страницу этого позора, запатчив KDE, KMozillaHelper и Firefox.

Теперь и KDEшный ROSA Fresh можно без стыда поставить девушке и ребенку. И умильно наблюдать, как ваша жена, перебирает для обоев ваши фотографии… чтобы потом выкинуть их и поставить что-нибудь по-настоящему красивое^[2].

И кстати, по нашим прошлым постам в «Точке РОСы» могло сложиться впечатление, что работа идет только по GNOME-версии, а KDEшная версия заброшена — уверяем вас, это не так.

И сделанные патчи по обоям уже отправлены в апстрим, и можно надеятся, с учетом предыдущего опыта небыстрой KDE-адаптации, что через пару лет эти фичи будут во всех KDE-дистрибутивах.

Кроме доработок апстримого KDE много исправлений делалось и в наших KDE-продуктах — ROMP, SimpleWelcome… описывать исправленные ошибки как-то наверно скучно, хотя там были исправлены и очень неприятные проблемы, например, когда пользователь проигрывал видео с подключенных сетевых хранилищ (FTP и т.п., как описано в Blog:Точка Росы/Из всех искусств для нас важнейшим является кино…), система, ради красивого тамбнейла вытаскивала целиком видеофайлы в /tmp, забивала его полностью и происходило много-много неприятностей. В общем, и с этим «чудовищем, которое преследовало ваш род» было покончено.

Впрочем, насчет обоев, мы еще не закончили. Ведь пришлось делать доработки и в GNOME, где, казалось бы, все должно было работать из коробки. Так казалось мне, и наверное всем гномо-пользователям. Мужского пола. Ведь мужской выбор (если все-таки лень вообще что-то менять удалось победить) — это неторопливый выбор подходящей картинки в браузере, установка ее, и все. Забываем на годы.

Как выяснилось, наблюдая за женским выбором — он не таков. Картинка выбирается, на нее смотрят, ставят на рабочий стол… живут с ней несколько минут… после чего «нет, что-то не очень» и идем переклеивать обои заново. Хорошо, что не в квартире, но каково же было мое удивление, когда мне сообщили «WTF? Обои меняются только четыре раза, а потом все, надо перезагружаться». Такие странные физические ограничения для электронных артефактов обычно вводят в удивляющий ступор, заставляя вспомнить разные истории, про «email, который идет не дальше 500 миль» и т.п.

Оказалось да, там была вполне реальная проблема, связанная с именованием выбранной из браузера картинки, кешированием, и отслеживанием изменений… — и UX Team успешно зафиксил и ее.

Так что теперь, и ROSA GNOME Fresh и ROSA KDE Fresh можно смело ставить девушкам, женам и детям…

Остается только ROSA LXDE Edition, где и браузерно-обойная проблема еще не решена, и выбор обоев по умолчанию, у многих пользователей вызывает … некоторое удивление^[3]… но будем пока считать это не багом, а фичей, и лично я, ROSA LXDE поставил на лептопы тестю и теще^[4].

Надеюсь, эта новость вас…

1. ↑ А таковых — большинство
2. ↑ My true sad story :(
3. ↑ Даже политкорректные англоязычные пользователи признаются «Now to be honest, the default wallpaper doesn't do much for me. Actually it probably almost fried my eyes and shot me back to the 90's at the same time…»[1]
4. ↑ Разумеется, я не зверь, и обои по умолчанию сменил на нестыдные, а тяги к перемене обоев в их возрасте уже нет

На прошлой неделе мы отправили в репозитории urpmi.recover, способный откатывать состояние пакетной базы в прошлое. Новая утилита уже нашла своих пользователей, которые, в свою очередь, нашли в ней некоторые шероховатости:) Впрочем, систему urpmi.recover никому не убил, данные не потер, а найденные недочеты мы оперативно исправляем. Но хотим напомнить, что текущий urpmi.recover пока надо рассматривать как бета-версию, недостаточно оттестированную и не готовую к повсеместному промышленному использованию.

Неожиданные результаты работы urpmi.recover иногда происходят из-за того, что в командной строке не очень-то удобно определять, на какую дату следует откатиться или сколько транзакций надо отменить для возврата системы в рабочее состояние. Для решения этой проблемы, мы на скорую руку соорудили для urpmi.recover простенький графический интерфейс — а точнее, добавили его поддержку в утилиту qt4urpm.

Qt4urpm — это небольшая программа, написанная несколько лет назад участниками сообщества MandrivaUser.de для двух операций с репозиториями urpmi — поиском в них файлов и определения и удаления осиротевших пакетов (то есть пакетов, которые были когда-то установлены в систему для удовлетворения зависимостей других пакетов, но необходимость в которых с тех пор отпала — например, потому что зависящие от них пакеты были удалены). Конечно, схожую функциональность предоставляет и графический Rpmdrake, однако qt4urpm — гораздо более легковесная программа (написанная на Qt) с очень простым интерфейсом, но в то же время нередко более удобная в плане стоящих перед ней задач — например, здесь можно удалять только определенные пакеты-сироты, а не все сразу, как в Rpmdrake, при этом выполнение типичных действий требует максимум трех кликов мышкой.

В общем, мы решили, что простой и прямолинейный интерфейс для urpmi.recover хорошо впишется в qt4urpm и оперативно это дело реализовали. Устанавливайте свежую версию (2.0) пакета qt4urpm, запускайте программу и переходите на вкладку urpmi.recover. Здесь будут перечислены транзакции, отсортированные по дате, и для каждой транзакции указывается перечень установленных во время ее выполнения пакетов:

Выбирайте интересующую вас дату/транзакцию и жмите Rollback — и urpmi.recover откатит все транзакции, начиная с выделенной.

В будущем, возможно, наши специалисты по приложениям с графическим интерфейсом создадут что-нибудь более красивое и эстетичное, но в плане функциональности qt4urpm предоставляет все необходимое. Надеемся, он позволит вам избежать путаницы в транзакциях rpm и более удачно рассчитывать эффекты от отката пакетной базы.

Надеюсь, эта новость вас…

Работа мэйнтейнера включает в себя много рутинных операций — адаптацию spec-файлов под изменяющиеся политики и инструменты сборки, переделку патчей под новые версии пакетов, обновление списка файлов приложения в пакете и так далее. Много рутины берет на себя инструментарий сборки — сам rpmbuild и вспомогательные скрипты из пакета spec-helper. Однако эти скрипты по определению не могут выполнить ряд задач — например те, которые требуют внесения изменений в spec-файлы.

Чтобы несколько облегчить жизнь мэйнтейнеров, мы включили в пакет spec-helper два новых скрипта, которые не применяются автоматически при сборке, а предназначены для ручного запуска человеком. Полагаю, названия скриптов говорят сами за себя — spec-cleaner и rediff_patch. Обновите в своей системе spec-helper, и эти скрипты появятся у вас в /usr/bin.

Spec-cleaner выполняет следующие действия:

• удаляет устаревшие и ненужные декларации — например, определение BuildRoot и Packager, зависимость от install-info, очистку buildroot и так далее;
• изменяет оформление использования макросов и переменных — переменные печатаются в фигурных скобках — %{const}, а макросы — без них — %{macro}. Такие изменения производятся только для макросов и переменных, определенных в самом rpm (а точнее, перечисленных непосредственно в скрипте spec-cleaner). Если вы сами определяете какие-то сущности, то их оформление скрипт изменять не будет;
• изменяет форматирование Summary — делает первую букву заглавной, удаляет точку в конце;
• удаляет явные определения переменных %{name}, %{version} и %{release};
• заменяет устаревшие макросы на современные аналоги;
• … и много других мелочей.

Пользоваться spec-cleaner — проще простого:

spec-cleaner my.spec

Если вы не хотите, чтобы изменения делались непосредственно в spec-файле, то можно указать второй параметр — имя нового spec-файла:

spec-cleaner old.spec new.spec

При разработке spec-cleaner мы старались прежде всего избежать ситуаций, когда новый spec-файл окажется некорректным — поэтому некоторые недочеты spec-файлов, исправление которых кажутся тривиальными, пока не реализованы.

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

1. запускать rediff_patch необходимо в директории склонированного проекта — там, где лежит spec-файл и патчи. Spec-файл используется для того, чтобы определить — как именно применяется патч;
2. в эту же директорию необходимо поместить новый тарболл с исходным кодом, для которого надо переделать патч;
3. непосредственно запуск скрипта выглядит так:

 rediff_patch <patch_ro_rediff> <tarball>

Если у вас в директории только один тарболл, то второй параметр можно опустить — rediff_patch возьмет единственный тарболл самостоятельно.

В ходе работы rediff_patch создаст директорию rediff_patch, распакует в нее новый тарболл и попытается применить к нему патч с параметрами, взятыми из spec-файла, добавив к ним опцию «--force» и используя значение fuzz по умолчанию (при сборке в rpmbuild используется «--fuzz=0»). Сейчас скрипт рассчитан на работу с тарболлами, при распаковке которых получается одна директория — обрабатывать tar-бомбы он откажется. В случае, если все сложится успешно, рядом с вашим патчем вы обнаружите новый патч с суффиксом «.new», а остальные следы деятельности скрипта (директория rediff_patch со всем содержимым) будут уничтожены. Если же что-то не заладится (например, патч применился не целиком), то вам останется директория rediff_patch с двумя поддиректориями — исходной и новой, к которой пробовали применить патч. Так что вы сможете вручную завершить работу, которую не получилось сделать автоматически, и уже самостоятельно сформировать новый патч с помощью стандартного diff -Naur.

Практика показывает, что большинство патчей все-таки требуют доработки, переделать их автоматически с использованием --force и более мягкого значения fuzz получается не очень часто. Однако даже если rediff_patch справился со всем самостоятельно, обязательно проверьте результирующий патч — ведь '--force' иногда может привести к нежелательному результату. А если rediff_patch не справился — что ж, по крайней мере, мы немного сэкономим на распаковке архива и первой попытке применить патч.

Оба скрипта довольно просты и прямолинейны. Как всегда, приветствуются отзывы, предложения, а главное — патчи:)

Многие разработчики и любопытные пользователи нередко сталкиваются с необходимостью откатить недавно установленные пакеты, которые привнесли в их систему не совсем ожидаемые обновления. Это обычно случается при установке пакетов из неофициальных источников, из testing-репозиториев или просто из частных репозиториев разработчиков и контейнеров, содержащих пакеты исключительно для тестирования. Последнее особенно актуально для нашей команды QA — откатывать установленные для тестирования пакеты им приходится очень часто.

Откатывать пакеты вручную не очень удобно, особенно если их много и вы не вполне уверены, что именно надо откатить для возврата системы в нормальное состояние. На помощь может прийти urpm-reposync, но этот инструмент может оказаться слишком мощным — он осуществит полную синхронизацию вашей системы с подключенными репозиториями, и откатить только часть пакетов с его помощью затруднительно.

Хорошая новость — теперь ниша между ручным откатом пакетов и использованием reposync заполнена утилитой urpmi.recover, способной откатывать установленные вами пакеты. Urpmi.recover может вернуть пакетную базу в состояние на определенную дату в прошлом, либо откатить заданное количество транзакций по установке пакетов.

Urpmi.recover является частью пакета urpmi и автоматически попадет в вашу систему с обновлениями.

Для осуществления такого отката пакетов, urpmi.recover сохраняет старые версии обновляемых пакетов в директории /var/spool/repackage. И для того, чтобы начать пользоваться утилитой, необходимо сначала инициализировать сохранение старых версий пакетов, выполнив команду

# urpmi.recover --checkpoint

Этой командой вы как-бы говорите: «Сейчас у меня система в стабильном состоянии, но я собираюсь установить потенциально опасные пакеты. Пожалуйста, начиная с этого момента, отслеживай все устанавливаемые пакеты и сохраняй их старые версии в случае обновления».

Вы можете выполнять эту команду и в будущем для переопределения стабильного состояния системы. При этом при каждом вызове urpmi.recover --checkpoint директория /var/spool/repackage будет очищаться, так что откатиться на более раннюю дату вы уже не сможете.

Пока отслеживание установки и обновления пакетов включено, старые версии пакетов сохраняются в поддиректориях /var/spool/repackage, соответствующих дате обновления, так что вы всегда можете изучить эти пакеты самостоятельно.

Если в некоторый момент времени вы решаете, что настало время откатить систему в прошлое, то просто выполните команду

# urpmi.recover --rollback <timestamp>

Время отката можно указать как число секунд с начала Эпохи, но для людей предусмотрены и более удобные варианты, например:

# urpmi.recover --rollback "2014-03-07 13:20:47"

или даже так:

# urpmi.recover --rollback "1 hour ago"

Можно откатить и заданное количество транзакций, указав опцию --transactions и передав количество транзакций для отката опции --rollback:

# urpmi.recover --transactions --rollback <число_транзакций>

В частности, если вы только что установили пакет (который притянул кучу зависимостей), то вы можете просто откатить это обновление, выполнив

# urpmi.recover --transactions --rollback 1

Наконец, отключить отслеживание установки пакетов вы можете командой

# urpmi.recover --disable

Эта команда также очистит /var/spool/repackage.

Вот так с помощью urpmi.recover можно откатывать состояние пакетной базы. Утилита находится в экспериментальном состоянии и отсутствие ошибок не гарантируется, тестируйте на свой страх и риск:). Впрочем, перед осуществлением отката urpmi.recover сообщит вам, что именно он собирается сделать (какие пакеты удалить, какие откатить), и у вас будет возможность отказаться, если вам что-то не понравится. Наконец, в случае чего, urpm-reposync готов прийти на помощь.

Также стоит помнить, что мэйнтейнеры не всегда заботятся об обеспечении корректного отката пакетов на предыдущие версии — так что если новая версия пакета вам что-то сломала в системе, то откат на старую может и не помочь.

ABF — один из ключевых компонентов разработки всех дистрибутивов РОСЫ (и не только), а вот новости про него в «Точке РОСЫ» проскакивают редко. Англоязычные пользователи могут читать новости в блоге ABF, а вот для русскоязычной аудитории мы постараемся восполнить недостаток известий в нашем блоге.

Итак, вкратце основные улучшения ABF за последний месяц.

Во-первых, мы улучшили поиск по Бюллетеням (Advisories) в веб-интерфейсе. Теперь вы можете искать бюллетень не только по его идентификатору, но и имени пакета и по описанию бюллетеня (в которое обычно включают ошибки, исправляемые обновлением — в том числе и проблемы с безопасностью со ссылкой на соответствующий CVE).

Во-вторых, мы добавили возможность регулярной сборки проектов по расписанию. В настройках проекта теперь есть раздел, где можно указать — в какие репозитории и с какой периодичностью надо собирать пакеты.

Из других улучшений в веб-интерфейсе можно отметить возможность автоматической публикации в testing-репозиторий. Теперь можно либо явно запретить автопубликацию, либо опубликовать пакет в testing-репозиторий, либо выбрать пункт «По умолчанию» — в последнем случае автопубликация будет производиться (или не производиться) в соответствии с настройками репозитория.

Наконец, консольный клиент ABF также получил ряд полезных функций. Теперь с помощью клиента вы можете создавать проекты на ABF из локальных SRPM-пакетов, клонировать проекты и приписывать/убирать проекты к репозиториям.

Клонирование проекта осуществляется с помощью команды fork, которой необходимо указать имена исходного и целевого проектов, включая владельцев:

abf fork dsilakov/foo import/bar

Для создания проекта из SRPM-пакета, дайте клиенту команду «create», указав SRPM-пакет для импорта и имя владельца, для которого будет создан проект (владельцем может быть как пользователь, так и группа, но у вас должны быть соответствующие права на создание проектов):

abf create foobar.src.rpm import

Имя и описание проекта будут взяты из соответствующих тегов пакета.

Такая возможность оказалась особенно удобна для импорта большого числа пакетов. Загружать их по одному через веб-интерфейс — долго, для массового импорта через веб пакеты надо сначала выложить на какой-нибудь публично доступный сервер, а с помощью клиента можно все провернуть в одну строчку:

for p in *rpm; do abf create $p import; done

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

abf add -p import/foobar rosa2012.1/contrib
abf remove -p import/foobar rosa2012.1/contrib

Если вы находитесь в директории склонированного проекта import/foobar, то указание его имени с помощью опции «-p» можно опустить.

Напоминаем, что пожелания по улучшению ABF всегда приветствуются на трекере идей и пожеланий.

Надеюсь, эта новость вас…

Последние приготовления

За два дня FOSDEM посетило несколько тысяч человек — организаторы дают расплывчатую оценку «5000+», но поскольку вход абсолютно бесплатный, свободный и не требует никакой регистрации, то точное число узнать вряд ли получится. Посчитать посетителей можно только косвенно — например, по количеству подключений к dhcp-серверам wifi-сети. К слову, wifi работал без нареканий, но организаторы решили провести эксперимент и основную сеть сделали IPv6-only. Судя по достаточно большому количеству вопросов от людей, которые вроде бы подключались к wifi, но до интернета достучаться не могли, далеко не все настольные системы на данный момент готовы переехать на IPv6 прозрачно для пользователей. Впрочем, организаторы сжалились, параллельно развернули сеть с IPv4.

Днем жизнь на стенде кипела

Возвращаясь к количеству посетителей, цифра 5000 на самом деле может оказаться и заниженной. Ведь всего на конференции было около полутысячи докладов, презентаций и круглых столов (и значит, почти столько же докладчиков). Доклады шли параллельно в 23 аудиториях, каждая из которых вмещала минимум несколько десятков человек, а многие — и несколько сотен. Конечно, на некоторых докладах залы были заполнены процентов на десять, но на некоторых из тех, что я посетил, было более двухсот слушателей.

К тому же помимо докладов, народ активно изучал стенды представленных на конференции проектов и общался с разработчиками. Стендов было 45 штук, и пообщаться было с кем. Из дистрибутивов помимо OpenMandriva были представлены Fedora, OpenSUSE, Debian, Mageia, а также дистрибутив для детей — DoudouLinux. Представлявший его товарищ сам похож на большого ребенка, так что есть основания полагать, что он знает, что делает:) Интересно полное отсутствие Ubuntu, хотя на машинах для общего пользования, стоявших в коридорах, была установлена именно эта ОС. Коммерческий Red Hat как дистрибутив тоже представлен не был, однако сама компания являлась основным спонсором конференции и ее сотрудники представили достаточно много докладов про открытые технологии, продукты и процессы, развиваемые и используемые в крупнейшем коммерческом Linux-вендоре.

Foreman Architecture

Помимо рассказов о продуктах и технологиях (большинство из которых так или иначе были связаны с облачными технологиями и обслуживанием большого количества машин), представители 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 вполне в общем тренде, только гораздо ближе к завершению, чем задумки большинства зарубежных коллег.

KDE5 — the beginning

Разработчики 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 — тоже вопрос открытый.

Вот так вроде выглядит Web-интерфейс RemoteRoot

Техническими докладами конференция не ограничивалась. Много слушателей привлекли доклады на юридические темы, рассказы про формирование сообщества и работу с ним и прочие аспекты, немаловажные при создании любого продукта. Было много докладов с научным уклоном — например, про эвристические алгоритмы для решения NP-сложных задач. Целая секция была посвящена инструментам работы с графами — но до туда никто из нас не добрался, так что можем только отослать на сайт FOSDEM за тезисами, видео и презентациями.

В завершение конференции мы побеседовали с представителями Google Summer of Code, в рамках которого сотрудники РОСЫ не раз выступали в роли менторов от Linux Foundation. Обсудили возможность участия в этом году OpenMandriva как менторской организации — представителям OMV тоже такая идея понравилась, так что они попробуют побороться за право участия, и сейчас идет сбор идей для студентов. В конце концов, старая Mandriva участвовала в GSoC, почему бы не попробовать и ее правопреемнице? Конечно, было бы неплохо там поучаствовать и РОСЕ. Но пока объективная реальность такова, что у европейской OpenMandriva шансов существенно больше, чем у российской компании, пусть даже и с международным сообществом. Однако представители РОСЫ вполне могут предложить свои идеи OpenMandriva — ведь у нас много общего в плане кодовой базы, OpenMandriva использует огромное количесвто наработок РОСЫ, так почему бы не поработать совместно над студенческими проектами? На представление идей и подачу заявки от организации есть еще чуть больше недели.

Заодно представителям GSoC был задан вопрос, волнующий студентов из России и ряда близлежащих стран — почему Google в прошлом году перестал присылать в эти страны футболки, ручки и прочие наклейки, ограничившись выплатой стипендий и рассылкой сертификатов. Ведь многие студенты радуются футболкам ничуть не меньше, чем стипендии:) Ответ был таким, что решение было принято на высшем уровне, и точные его причины неизвестны — может, с таможней что-то не так, а может решили упростить логистику. И в этом году улучшений не планируется.

Вот такая вот европейская конференция по свободному ПО. По масштабам российским конференциям до FOSDEM еще расти и расти. Но зато мы гораздо лучше организуем запись докладов:)

Сорри за много букв, но конференция действительно нереально большая, и выше изложено только то, что вспомнилось навскидку, и что я видел своими глазами:)

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

Надеюсь, эта новость вас…