Участник:StasFomin/rp8

«Фичи» — наши наработки и доработки, все для юзабилити и надежности

• Мы покончили с национальной дискриминацией хоткеев в GNOME!

Достаточно очевидно, что если у вас десктопный линукс, то у вас десктоп или лептоп (thanks, C.O.), и скорее всего, вы действительно используете клавиатуру, на данный момент самый эффективный интерфейс между человеческим мозгом и компьютером. Иначе, вы бы уже превратились в смартфоноюзера или планшетопользователя, где вроде как есть «sensable interfaces», которые на самом деле маркетоидная ложь — это смартфон чувствует ваши касания, но вы его — нет.

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

Знание хоткеев, как показали исследования ученых, погружается в костный мозг, и становится неотъемлемым автоматическим навыком, типа езды на велосипеде или вождения автомобиля… И даже если вы будете возмущенно утверждать обратное — «хоткеи для гиков, я приличный человек!», заметим, что уж «CTRL-C CTRL-V» знают все, ведь этот простейший хоткей и привел к той информационной лавине, в которой мы живем…

Казалось бы, да, линукс на десктопе, вроде бы он должен быть оптимален для гиков, которым кроме командной строки и клавиатуры ничего не надо, ну а уж хоткеи в офисном софте должны работать 100%, потому как третье тысячелетие на дворе, Natural UI на подходе, и вообще, о чем речь.

Но нет. Если у вас GNOME версии выше v3.4, и вы не чистокровный WASP англоговорящий и англопишущий, то вас ждет странная засада — под неанглийскими раскладками во всех приложениях все хоткеи не работают! Даже «CTRL-C CTRL-V»! Ужас охватывает, когда то, что всегда срабатывало — не срабатывает… Это похоже на паралич новых кибернетических органов, это бесит, к этому нельзя привыкнуть…

Это мы обнаружили когда проводили специальные юзабилити-сессии, да впрочем, учитывая, что почти все сотрудники компании, включая менеджмент, и так «сидят на ROSA GNOME», проблема была обнаружена быстро.

Почему это так? Была ли это специальная диверсия Запада против России? Оставим конспирологию депутатам.

Скорее всего, ребята из GNOME взяли такое ускорение на пути в космос,

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

Кстати,

А какие Desktop Environment-ы вы используете?

GNOME SHELL 48 20% GNOME CLASSIC 21 9% LXDE 10 4% KDE 64 27% Enlightment 3 1% MacOS 11 5% Windows 27 11% что-то еще… 42 18% Ничего из перечисленного 4 2%

Все это последствия сращивания классической системы ввода XKB с новомодным ЯАвтобусIBus в одну ротацию раскладок, чтобы все между всем бесшовно переключалось… но все эти тонкости неважны для пользователей, которые безуспешно хотят вернуть утраченное по форумам (См, например, ЛОР, УбунтуФорум, Арч…… куча ссылок). Предлагаются разные хакерские воркараунды, от отключения ibus в пользу xkb до использования специальных русских локалей на базе японских.… Но все эти workaroundы, увы, с побочными эффектами — либо не будут работать индикаторы раскладки, либо отвалятся стандартные настройки…

Мы же решили сделать все это по-уму, и просто починить.

Корень проблемы был найден в плагине к gnome-settings-daemon под названием keyboard, именно там реализованы механизмы контроля переключения и задания раскладок.

В реализации этого плагина по умолчанию для того, чтобы работали горячие клавиши предусмотрено добавление «us» раскладки на последнее место в списке раскладок при выборе не-«us» раскладки.

К сожалению, по какой-то причине такой подход не работает, отсюда и возникает проблема. Подготовленный нами патч перерабатывает механизм добавления раскладки, ставя «us» всегда на первое место и просто переключая активную раскладку на нужную в данный момент, например на «ru». Именно такой механизм используется самим XKB, если исключить вмешательство gnome-settings-daemon в переключение раскладок.

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

Ввела в экстаз ^_^ 39 38% Порадовала :) 44 43% Оставила равнодушным -_- 15 15% Огорчила :( 5 5%

• Хоткеи для Windows-свитчеров. Смело переходите на GNOME!

Про «инновационную оболочку», ну или если многословно и официально — «окружение рабочего стола, GNOME SHELL», в сообществе линуксоидов сложилось несколько превратное, хотя и местами обоснованное мнение, что это слишком инновационно и не для «простых людей». Некоторые даже причисляют GNOME SHELL к так называемым post desktop интерфейсам, уходящим вдаль от классической метафоры «захламленного рабочего стола», с переключением задач через вездесущую панель.

Да, в GNOME SHELL есть большая схожесть с MacOS, и можно было бы надеятся, что эта схожесть сможет привлечь макюзеров…, но взглянем в глаза жестокой правде — их доля тоже невелика, в то время как высока их «верность Яблоку».

А основная масса потенциальных пользователей Linux Desktop, это — вольные или невольные пользователи Windows, и хотелось бы зазвать именно их, причем не только на схожие интерфейсы KDE/LXDE, но и на GNOME SHELL — ведь на самом деле, GNOME вполне расширяем, там легко поставить привычную панель задач, а визуальные метафоры GNOME SHELL тоже вполне неплохи, и хотя их почему-то считают «планшетоориентированными», они весьма эффективны, например, для ноутбуков с небольшим экраном.

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

Но. Если достаточно легко понять изменение некоторых метафор (лаунчер «не иерархическое меню по кнопке пуск, а полноэкранное», «Dash» вместо панели, нижний док вместо «tray»…), то вот изменить клавиатурные навыки невозможно очень, очень непросто. Они уже «опустились» на уровень рефлексов и костного мозга, и если смена Desktop Environment — это как новый автомобиль — да, множество мелочей находится в непривычных местах, возможен ступор при поиске кнопок управления стеклоподъемниками и т.п., то управлять машиной, если перепутаны педали — нереально (см. также размышления в Blog:Точка Росы/Мы покончили с национальной дискриминацией хоткеев в GNOME!). Особенно, если приходится ездить на разных машинах.

Собственно среднепродвинутый Win-бизнес-пользователь привык к продвинутым Windows клавиатурным хоткеям серии «WIN+XXX», когда по WIN-E у него откроется «Проводник по файлам», по WIN-D → уберется свалка окон, чтобы открыть свалку ярлыков на нескучных обоях, а кнопки «WIN←» и «WIN→» легко, без специальных тайлинг-менеджеров и виртуальных рабочих столов наведут порядок в перекрывающихся окнах. Это было замечено и девствене пробовавшими linux desktop пользователями на наших юзабилити-сессиях, и собственно, сотрудниками компании, которые еще помнят Windows.

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

На всех клавиатурах есть привычная кнопка «WIN», и есть куча привычных навыков — «позвать файловый менеджер по WIN-E», «WIN-D, чтобы убрать свалку окон со стола, чтобы увидеть помойк аккуратно разложенные иконки на любовно выбранных обоях», «WIN+←» или «WIN+→», чтобы сделать мгновенно сделать тайлинг окон на большом мониторе, или «WIN+↑», чтобы наоборот, максимизировать окно на маленьком экране лептопа…

Так вот, если смотреть на стандартные хоткеи самых распространенных DE, то оказывается, что многие Windows-хоткеи совпадают с как раз с хоткеями GNOME по умолчанию.

К сожалению, правда, далеко не все.

---

Good news everyone!

Мы реализовали «ROSA Hotkeys» — специальное расширение для GNOME, который поддерживает большую часть самых необходимых хоткеев.

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

Запускалки

Win+L

(и/или Ctrl+Alt+Del) — Заблокировать компьютер.

Win+R

Открыть окно «Выполнить».

Win+Е

Запуск файлового навигатора (Nautilus).

• Shift+Ctrl+N

  Создать новую папку.

Win+F

Открыть окно поиска.

Сtrl+Shift+Esc

Открытие диспетчера задач (Запуск gnome-system-monitor).

Win+Pause

Свойства системы (Центр управления) .

---

Окна

Win+D

Показать рабочий стол (свернуть все окна).

Win+Home

Свернуть все окна, кроме активного.

Win+←/Win+→

Вертикальный Tiling — окно занимает полмонитора слева/справа соответственно.

Win+Shift+↑

Развернуть по максимуму окно по вертикали.

---

Многомониторные конфигурации

Win+Shift+←/Win+Shift+→

Перенаправить окно на соседний монитор.

Win+P

Переключение режимов «проектора» — клон → расширенный стол → только второй монитор → только основной.

---

По умолчанию, это расширение установлено и включено.

• Если оно не установлено, то установите его:

urpmi gnome-shell-rosa-hotkeys

• Если оно выключено, то его надо включить через «Параметры → Дополнительные параметры системы → Расширения Shell → ROSA hotkeys».

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

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

Ввела в экстаз ^_^ 9 27% Порадовала :) 18 55% Оставила равнодушным -_- 5 15% Огорчила :( 1 3%

• GNOME для нетбуков — режим без тормозов

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

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

Теоретически, в GNOME есть специальный режим, «GNOME classic», от которого пользователь ожидал, что там все будет, «как при бабушкеGNOME2» — c меню в левом верхнем углу, без свистелок но и без тормозов. К сожалению, нет — меню в этом режиме появлялось, но вот тормоза и свистелки никуда не девались, причем тормозит и оконная система, и даже видео — тупо не посмотреть без дергания сериальчики, даже не в HD!

Дело в том, что в GNOME 3.8 решено было полностью отказаться от режима совместимости (fallback-режима), работающего со старыми проверенными компонентами окружения Gnome — gnome-panel и metacity, в пользу сосредоточения всех усилий разработчиков на дальнейшем развитии gnome-shell, без оглядки на «старое железо». В результате, gnome-panel перестал развиваться и остановился на версии 3.6.2, а из компонентов среды, таких как gnome-settings-daemon и nautilus был вырезан функционал по взаимодействию с gnome-panel.

Мы решили поправить ситуацию и начали с портирования gnome-panel на библиотеки из состава GNOME 3.8. После этого, мы вернули необходимый функционал по взаимодействию с gnome-panel в gnome-settings-daemon и nautilus, и тем самым восстановили fallback-режим в GNOME 3.8.

Теперь все летает даже на вымершем классе нетбуков, и если вы хотите подарить старый нетбук теще — уже не обязательно ставить LXDE или WinXP, а можно и новый GNOME с привычным обличьем.

Тестируем воспроизведением видео высокого разрешения:

Кстати, совсем свежий проект Gnome Flashback ставит своей целью добиться того же и даже большего — помимо простого восстановления работоспособности, планируется продолжать развитие компонентов, в том числе портировать их на GTK+3.

Но на данный момент произведено лишь портирование gnome-panel для работы в GNOME 3.8 и восстановление сессионной записи для Gnome Fallback.

Тем не менее, очень надеемся, что этот проект будет развиваться, так как иметь поддержку нужного функционала в upstream’е — всегда хорошо.

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

Ввела в экстаз ^_^ 49 25% Порадовала :) 127 65% Оставила равнодушным -_- 13 7% Огорчила :( 5 3%

---

Update

К сожалению (а может и к счастью), обнаружилось, что этот режим не востребован. Поэтому начиная с GNOME 3.12, и релиза R5, мы его исключаем. Для слабых компьютеров, мы по-прежнему рекомендуем использовать либо LXDE, либо оптимизацию KDE.

• WiFi и Broadcom - работа над ошибками

Две проблемы, связанные с обработкой ошибок, были исправлены нашими разработчиками в проприетарном драйвере для WiFi-адаптеров Broadcom (broadcom-wl, он же broadcom-sta, он же wl). Обе эти проблемы (#2146, #2667) приводили к падению ядра при загрузке системы на ноутбуках у некоторых наших пользователей.

Кстати, на момент подготовки этого материала указанные ошибки далеко не во всех популярных дистрибутивах Linux были исправлены.

Ранний вызов wl_cfg80211_detach()

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

Пока это было исправлено "симптоматически": в нужных местах в коде были добавлены соответствующие проверки. Разработчикам драйвера также было сообщено об этой проблеме - пока видимой реакции нет.

Обращение по нулевому указателю в wl_inform_single_bss()

Разобраться с этой ошибкой было проще. Функция ieee80211_get_channel() может возвращать NULL в некоторых случаях, но в драйвере это не было учтено. Исправляется это несложно.

• Легализация Gnome-tweak-tool

Согласно концепции GNOME-строителей, восходящей к патернализму яблочной компании, пользователю не нужны настройки системы, ведь в правильно сделанной системе все уже правильно!

Отсюда и серьезная бедность настроек GNOME SHELL по сравнению с KDE, в котором, правда серьезно ударились в другую крайность, и что самое обидное — настройки то остаются, только они исключены из стандартных «Параметров», и заметены под плинтус доступны из отдельных утилит, в частности, утилиты gnome-tweak-tool, недоступной из стандартного интерфейса, да и зачастую не входящую в образ дистрибутива.

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

В целом, сейчас ситуация с настройками GNOME SHELL скорее близка к ненасыщенной — многие очевидно необходимые настройки спрятаны в gnome-tweak-tool. Некоторые настройки мы выносим с чулана gnome-tweak-tool на свет «Параметров», например, «Настройки шрифтов», но в любом случае, надо сделать его «легализовать твикер», сделав туда легким вход любому пользователю.

И мы сделали это, добавив вызов gnome-tweak-tool из «Параметров», назвав его, после некоторых дебатов, «Тонкие настройки»

Да, название получилось длинноватое и скучно… Впрочем, если у вас есть удачные предложения — пишите в комментарии, рассмотрим все варианты!

Инструменты мантейнера, качество репозитория

• Urpmi, rpmdrake и автоматический выбор зависимостей

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

Есть у нас в репозиториях система распознавания символов (OCR) Tesseract. Ей для работы необходимы пакеты с данными для конкретных языков. Tesseract сейчас поддерживает более 70 языков, и для каждого из них у нас отдельный пакет. Однако вся эта куча языков пользователю вряд ли понадобится — большинству достаточно поддержки родного для них языка. Поэтому при установке tesseract надо каким-то образом решить — какие языковые пакеты надо поставить. Непосредственно на уровне пакетов этот вопрос решается следующим образом: сам пакет tesseract требует абстрактную зависимость tesseract-language, а ее предоставляет каждый из соответствующих языковых пакетов.

При установке tesseract, urpmi (или rpmdrake) видят, что зависимость tesseract-language может быть разрешена несколькими способами. В такой ситуации они либо спрашивают пользователя, какой пакет выбрать, либо, в случае выставления опции --auto (или аналогичной галочки в настройках rpmdrake), выбирают один из пакетов самостоятельно.

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

Кстати,

При установке пакетов, вы предпочитаете автоматический или ручной выбор зависимостей?

Автоматический 15 88% Ручной 2 12% Когда как 0 0%

Так как же работает автоматический выбор?

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

Раньше, для разрешения зависимости urpmi просто выбирал первый попавшийся пакет. Встречается мнение, что выбор происходит случайным образом, однако это не так — пакеты при выборе упорядочиваются согласно их внутренним идентификаторам, которые использует urpmi в своей работе, и изначально urpmi выбирал пакет с наименьшим идентификатором. Однако нет гарантии, что в разных системах эти идентификаторы будут идентичны (поскольку идентификаторы присваиваются при считывании данных о пакетах в репозиториях, а у пользователей могут быть подключены разные репозитории и в разном порядке).

Как результат, при установке одного и того же пакета с опцией '--auto' в разных системах зависимости пакета могут быть разрешены по-разному. В принципе, большой проблемы в этом нет — например, если пакету нужна Java, и он работает как с OpenJDK 6, так и с OpenJDK 7, то пользователю должно быть безразлично, какую версию OpenJDK выберет urpmi. Тем не менее, хотелось бы иметь более унифицированное поведение в разных системах, и при этом более умное — чтобы избежать хотя бы часть ситуаций, когда некоторый пакет предоставляет что-то по ошибке (ведь мэйнтейнеры тоже люди, они могут ошибиться сами или, что более вероятно, пропустить ошибку автоматического генератора зависимостей).

Чтобы убить двух зайцев сразу, мы реализовали в urpmi выбор пакета с именем, содержащим наибольшую общую строку с затребованной зависимостью. То есть если некоторому пакету требуется 'java', то будет выбран 'java-openjdk-1.6.0' или 'java-openjdk-1.7.0', но не 'cacao' или другие экзотические java-машины. Конечно, полной однозначности все равно добиться не удастся (как видно на примере той же java), но как показал практика, такой эвристический алгоритм в реальной жизни дает лучшие результаты, чем просто выбор первого попавшегося пакета.

Однако есть ситуации, в которых пользователю не так уж и безразлично, что выберет инструмент управления пакетами. Самый распространенный случай — это выбор пакетов, зависящих от языка системы. Так, в приведенном в начале примере с tesseract, пользователь будет рад увидеть поддержку родного языка (ну в крайнем случае — английского), а не какого-нибудь древнеиспанского. Для разрешения таких ситуаций необходимо решить две задачи:

1. объяснить urpmi, что выбор пакета должен зависеть от языковых настроек системы;
2. со стороны urpmi, выбрать пакет, соответствующий текущим настройкам ОС.

Первая задача решается посредством добавления пакетам зависимостей на соответствующие пакеты с системной локализацией — так что tesseract-rus зависит от locales-ru, tesseract-eng — от locales-en и так далее.

Решение второй задачи осуществляется urpmi в два этапа — сначала он смотрит, какие locales-* пакеты уже установлены в системе (помимо locales-en). Если таких пакетов несколько, то дополнительно анализируется настройка локали системы (точнее, значение переменной LANG).

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

Перечисленные изменения затрагивают и ситуацию, когда urpmi спрашивает пользователя, какой пакет выбрать — в таком случае вверху списка всегда показывается пакет, который сам urpmi выбрал бы при использовании опции '--auto'. Более того, в случае выбора языковых пакетов, urpmi даже не предложит пакеты, для которых в системе не установлены соответствующие locales-*. Например, у меня в системе стоят locales-ru, locales-en, locales-da и locales-ja. При этом системная локаль — русская. В такой ситуации, «urpmi tesseract» предложил мне следующий выбор:

Как видим, первым идет русский вариант, за ним — пакеты, зависящие от локалей, отличных от английской, а в конце — пакеты, зависящие от locales-en (Тагальский и язык Чероки зависят от locales-en, поскольку для них просто не нашлось соответствующих локалей, а вот heb-com должен зависеть от locales-he; вот и баг нашли заодно:)). Пакеты, зависящие от других локалей, в список вообще не попадают.

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

• Работаем над качеством пакетов, или Новости Rpmlint

Одним из инструментов проверки корректности пакетов, с которым волей или неволей имеет дело каждый мэйнтейнер, является Rpmlint. Этот инструмент, проверяющий соответствие пакетов политикам дистрибутива, запускается автоматически при каждой сборке на ABF. Также мы проводим регулярный мониторинг репозиториев РОСЫ на портале FBA.

Правила сборки пакетов не высечены в камне и меняются со временем. Кроме того, время от времени появляются новые идеи - что еще можно статически проверять в собранных пакетах. Не стоит на месте и Rpmlint. Недавно мы провели его рефакторинг, выбросив неактуальные для РОСЫ проверки - вызов ldconfig в post-скриптах, определение и очистка BuildRoot и ряд других. Эти проверки уже долгое время не использовались, но загромождали код и увеличивали время работы инструмента.

Помимо чистки кода, мы добавили и ряд новых возможностей.

Во-первых, мы усилили проверки пакетов, исполнимые файлы или библиотеки которых выставляют параметр RPATH. Этот параметр влияет на то, в каких каталогах производится поиск библиотек при загрузке приложения - пути, указанные в RPATH, просматриваются в первую очередь. Пользоваться этой возможностью следует аккуратно, особенно в библиотеках, которые могут использоваться другими компонентами дистрибутива. В РОСЕ при необходимости использовать RPATH в каком-либо пакете рекомендуется помещать все библиотеки, доступ к которым будет контролироваться RPATH, в отдельный подкаталог директории /usr/lib (желательно, чтобы имя подкаталога совпадало с именем пакета - например, /usr/lib/fglrx содержит библиотеки, специфичные для fglrx). Если же RPATH указывает на директорию, в которой могут оказаться не ожидавшиеся авторами пакета библиотеки, то поведение приложений может оказаться непредсказуемым. Часто встречающимся примером такого рода является установка RPATH в системные значения наподобие /lib или /usr/lib. Как показала практика, установка RPATH в такие значения может оказаться даже фатальной - например, мы недавно исправили проблему с Empathy, "падавшего" на системе с драйверами Nvidia из-за RPATH, выставленного в библиотеке libwebkit (используемой Empathy). Отныне Rpmlint выявляет такие ситуации непосредственно при сборке пакета и при обнаружении исполнимого файла или библиотеки, в которых RPATH установлен в /lib, /usr/lib, /lib64 или /usr/lib64, останавливает сборку с ошибкой.

Во-вторых, по просьбе команды локализации, мы добавили проверку desktop-файлов в пакетах на предмет наличия в них непереведенных на русский язык описаний. Локализация таких файлов является важной, ведь именно информация из них используется для предоставления пользователю сведений о приложении, запускаемом при нажатии на ту или иную иконку. Поскольку такая проверка предназначена только для русскоязычных разработчиков, мы не стали включать его в основную ветку Rpmlint, распространяемую с РОСОЙ. Этот тест используется только при запуске тестов на FBA и результаты его можно наблюдать в соответствующих разделах FBA. Например, для репозитория main дистрибутива ROSA Desktop Fresh R1:

Непереведенные названия

Непереведенные описания

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

Наконец, Rpmlint теперь может проверять корректность суффиксов в названиях пакетов. В РОСЕ каждой версии дистрибутива соответствует свой суффикс, который автоматически выставляется средой сборки. Однако бывают ситуации, когда пакет не собирается на ABF, а подкладывается в репозиторий руками из другой версии дистрибутива. Например, некоторые пакеты имеют кольцевые сборочные зависимости, и для пересборки таких пакетов под новую версию дистрибутива проще всего использовать уже собранные зависимости из предыдущей версии. Как правило, "подложенные" пакеты удаляются из репозитория, как только в них отпадает необходимость. Однако человек может и забыть удалить какой-либо пакет, поэтому надежнее автоматизировать их отслеживание. Чем теперь и занимается Rpmlint, а точнее - проверка non-standard-distsuffix.

Список "корректных" суффиксов необходимо задавать в настройках Rpmlint, в параметре ValidDistSuffixes.

• Linux Kernel ABI Tracker - инструмент для отслеживания изменений в ABI ядра

Ядро операционной системы Linux постоянно развивается: улучшается поддержка оборудования, оптимизируются различные подсистемы ядра и др. В результате этого размер ядра и количество его ABI/API интерфейсов постоянно растет от версии к версии. При этом, в процессе разработки, могут быть изменены некоторые старые интерфейсы, что может неблагоприятно повлиять на работу других программных компонентов, использующих интерфейсы ядра: модулей, драйверов, динамических средств тестирования и трассировки ядра и др.

Для регулярного автоматического анализа изменений в интерфейсах ядра мы разработали инструмент Kernel ABI Tracker. Этот инструмент следит за появлением новых версий ядра на офф. сайте kernel.org, собирает их и анализирует изменения с помощью набора базовых инструментов. Для каждой версии ядра создается так называемый ABI dump ("снимок" или "дамп" ABI ядра) из его debug-информации при помощи инструмента ABI Dumper. Дамп ABI включает в себя информацию о всех публичных экспортируемых интерфейсах ядра, их параметрах и структуре типов данных. Для получения отчета об изменениях в двух версиях ядра сравниваются два соответствующих дампа ABI при помощи инструмента ABI Compliance Checker. В отчете описаны все изменения в интерфейсах ядра и разделены по уровню опасности для приложений. Отдельно описаны добавленные и удаленные интерфейсы, изменения в типах данных и в параметрах интерфейсов. Кроме своего прямого назначения дампы ABI могут также использоваться для других видов анализа интерфейса ядра сторонними разработчиками и поэтому доступны для скачивания всем желающим.

Интерфейс инструмента предоставляет отчеты о результатах тестирования defconfig-конфигураций всех последних longterm, stable и mainline версий ядра. На главной странице показан график зависимости количества интерфейсов ядра от версии. На данный момент результаты получены для двух архитектур: x86 и x86_64. Поддержка архитектуры arm планируется в ближайшее время. Также планируется тестирование других конфигураций ядра, например, allyesconfig.

Базовые инструменты ABI Dumper и ABI Compliance Checker, ранее разработанные в компании РОСА для проверки совместимости Си-библиотек, потребовали существенных изменений для возможности анализа изменений в ядре Linux. В силу огромной глубины дерева структур данных ядра и большого количества интерфейсов, требуемые для обработки одной версии ядра процессорное время и объем оперативной памяти были неудовлетворительными и вследствие были оптимизированы в несколько раз до нормальных величин. В результате этих улучшений, инструменты теперь работают быстрее при анализе библиотек большого объема. Код новых версий этих инструментов был выложен на их офф. сайте.

• Updates Builder – Pull Request'ы и автоматическое исправление ошибок сборки

Репозитории ROSA Desktop Fresh R1 содержат порядка 15.000 пакетов, способных удовлетворить нужды практически любого пользователя. Однако поддержка такого обширного набора библиотек, приложений, утилит и прочих программных компонентов — задача непростая. Ведь новые версии многих программ выходят очень часто, и мэйнтейнерам необходимо оперативно отслеживать их появление, собирать их для РОСЫ, тестировать и решать — стоит ли обновлять пакет в репозитории до новой версии. Для автоматизации подобных задач мы используем инструмент Updates Builder, осуществляющий мониторинг апстрима и автоматически собирающий новые версии программ на ABF.

До недавнего времени процесс работы Updates Builder’а был незатейлив — он брал имеющийся spec-файл от старой версии пакета, заменял в нем версию и имя файла с исходным кодом и пытался собрать новый пакет. Практика продемонстрировала эффективность такого подхода — достаточно часто новые версии содержат минимум изменений по сравнению с предыдущими, и никаких серьезных изменений в spec-файле для их сборки не требуется. Как результат — за три месяца использования Updates Builder’а мы с его помощью обновили несколько сотен пакетов. Но аппетит приходит во время еды, и нам захотелось еще больше повысить эффективность инструмента.

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

Для реализации такой возможности мы разработали скрипты анализа ошибок, возникших при сборке пакета. Скрипты запускаются автоматически в случае, если сборка новой версии пакета с помощью Updates Builder’а завершилась неудачно. При обнаружении одной из ошибок, известных скриптам, они сами вносят в spec-файл изменения, которые должны позволить избавиться от этой ошибки, и отправляют пакет на пересборку. Этот процесс может иметь несколько итераций — ведь после исправления одной ошибки могут появляться другие. Таким образом, процесс работы Updates Builder’а в РОСЕ устроен следующим образом:

Список ошибок, которые скрипты в состоянии исправить на данный момент, таков:

• ставшие ненужными патчи
  • Reverse (or previously applied) patch detected
• Нехватка сборочных зависимостей Perl
  • Can’t locate <perl_module> in @INC
• Добавленные или удаленные файлы:
  • File not found / File not found by glob
  • Отсутствие файла, указанного в %doc
  • Installed (but unpackaged) file(s) found
• Ошибки rpmlint
  • debuginfo-without-sources и empty-debuginfo-package

Исправление этих ошибок носит эвристический характер и мы не можем гарантировать, что исправление корректно, даже если после его внесения пакет собрался успешно. Например, ошибки debuginfo-without-sources и empty-debuginfo-package сейчас решаются просто отключением сборки debug-пакета; но возможно, более правильным было бы пометить пакет как архитектурно-независимый (noarch) или добавить какие-то флаги сборки, в отсутствии которых не генерируется отладочная информация. Поэтому перед переносом предложенных Updates Buider’ом обновлений в основной репозиторий, мэйнтейнерам следует присмотреться — какие изменения были внесены в spec-файл и не стоит ли их скорректировать.

К слову об анализе предлагаемых Updates Builder’ом обновлений и их переносе в основные репозитории — этот процесс недавно стал гораздо более удобным и наглядным. До сих пор Updates Builder только оповещал о результатах сборки по e-mail, после чего мэйнтейнерам необходимо было самим смотреть, какие изменения были внесены в ветке auto_update Git-репозитория и сливать эти изменения в основную ветку. Теперь в случае успешной сборки на ABF формируется Pull Request на внесение изменений в целевую ветку, так что мэйнтейнеры могут визуально изучить все модификации и принять их нажатием одной кнопки.

Pull Request от Updates Builder’а для python-m2crypto — можно обновиться до версии 0.21.1

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

IT-конференции — мы снимаем и публикуем записи разных IT-конференций, это интересно даже тем, кто не связан с Linux и Open-Source

• talks.rosalab.com — конференции, которые всегда с вами

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

Публикуем мы все это на «ROSA-Медиатека», http://talks.rosalab.com. Это удобная видеотека докладов с ряда софтверных конференций, удобно категоризованная, присобленная и для удобного просмотра, и для фидбека.

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

Низок КПД и для докладчиков — человек может несколько недель готовить доклад, а получить аудиторию всего из пары десятков человек.

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

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

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

• Тупая запись одной камерой — невозможно ничего рассмотреть на экране.
• Все это вываливается, в лучшем случае, единым альбомом на ютуб. Тут еще проблема в том, что нет
  • никакой связи с докладчиком — непонятно, кто автор, стоит ли его смотреть, кому задавать вопросы, если возникнут, как посмотреть другие его доклады и т.п.
  • сложно понять, стоит ли смотреть — аннотация отдельно, даже если слайды выложены на слайдшаре — их долго листать, чтобы понять, примерно о чем, достаточно ли качественно сделана визуальная часть, или там «смерть от Powerpointa».
  • Ютуб грузит рекламу, и на дает загрузить само видео (без специальных приседаний, о которых мало кто в курсе).
  • Комментировать в ютубе (плоский список комментов) не очень удобно, и трудно вести длинную осмысленную дискуссию, для которой, как минимум, требуется древообразная система комментариев.

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

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

У нас же:

• Правильная видеосьемка и монтаж, с раздельной сьемкой докладчика и экрана, c ускорением, на базе наших обкатанных технологий (вот мой короткий рассказ о них, рекомендую).
• Единая база по целому спектру конференций, пара сотен докладов, куча дополнительных статей — категории, участники, всего где-то под тыщу.
• Сделана и расширяется тематическая классификация, каждый доклад может быть приписан к нескольким темам (например, Образование + Программирование или Управление продуктами + Юзабилити …).
• Есть группировка и классификация и по авторам, причем для каждого автора, кроме подборки его докладов, есть ссылка на его актуальный профиль в профессиональных социальных сетях, чтобы можно было ознакомится, кто это, стоит ли его слушать, и чтобы с автором можно было связаться, даже если он сменит работу. Ох, как это было непросто. Ведь часто про автора даже после доклада ничего не известно, контактов на слайдах нет, сам не представился, в программе только фамилия и инициалы... Иногда приходилось делать целое расследование, потратив несколько часов, и бывало даже, безрезультатно…
• По конференциям тоже все разложено.
• Для каждого доклада есть аннотация, ссылки на дополнительную информацию, а слайды развернуты в «быструю инфографику» листаемых картинок, чтобы можно было просто пролистать колесом мыши, и гештальтно ознакомится с визуальной частью («смерть от PowerPointa» или нормальная визуализация, какие там ключевые слова и картинки видны, будет ли это про архитектуру, или просто «веселые картинки» менеджерского доклада).
• Верстка максимально адаптирована для зрителя:
  • в целом — чистый whitespace дизайн, что сейчас в тренде.
  • никаких лишних блоков, рекламы и прочего спама.
  • adaptive design — удобная для чтения основная колонка, оптимальной для чтения ширины, а дополнительные блоки — классификации, поиска и комментирования на широких экранах идут вбок, а на узких — уходят вверх и вниз — теоретически все должно быть ОК на планшетах и даже смартфонах.
• прикручена стандартная, известная всем система комментирования DISQUS (~80% сайтов c внешней системой комментариев сделана на этой системе) — вполне можно всласть пообсуждать.

Теоретически, у нас тут возникает «Непрерывная Распределенная Многотематическая IT-конференция», когда вброшенные в сообщество мысли и идеи продолжают обсуждаться задолго после доклада, связывая задающих вопросы с знающими ответы. Ведь на самой конференции практически никогда не бывает достаточно времени для обсуждения, фраза модератора «Время вышло, обсуждение можно продолжить в кулуарах» звучит практически на каждом докладе, да и не всегда слушатель готов сразу отрефлексировать тему, и задать осмысленные вопросы. Другое дело, что сейчас люди уже почти отучились писать отзывы и рецензии, поэтому…

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

Welcome! Посмотрите, возможно найдутся интересные вам доклады.

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

Кстати, кроме записей конференций, есть также проведенные нами записи вебинаров дружественной нам компании PingwinSoft.

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

Живые инсайд-вебинары от команды «РОСЫ»:

Отличная, буду участвовать 8 73% Хорошая, возможно посмотрю. 3 27% Плохая, «нинужно» 0 0%

Возможно это развеет безумные мифы о нашей работе, бродящие в анонимных обсуждениях на ряде сетевых ресурсов…

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

• OSSDEVCONF-2013

19-22 сентября в Калуге прошла Десятая конференция разработчиков свободных программ, там же, мы назвали ее для краткости и твиттера OSSDEVCONF-2013. Собственно раньше она проходила в Обнинске, но в этот раз организаторам удалось найти более приличное место, и не сильно дальше от Москвы, место, удобное для туризма — старинный русский город, колыбель Циолковского, и при этом еще есть интернет и островки высоких технологий.

Туда высадился и десант из «РОСЫ» — с докладами, и, что, возможно более интересно, с кучей видеотехники — сто килограмм штативов, камер, фотоаппаратов, ноутбуков и прочего. Да, мы стараемся снять и опубликовать проходящие конференции про линукс и опенсорс (см. например, OSDN-UA-2012, PingWinFest-2012, OSEDUCONF-2013, ROSS-2013, OSSDEVCONF-2013), чтобы увеличить аудиторию докладов (см. Blog:Точка Росы/talks.rosalab.com — конференции, которые всегда с вами).

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

Но в этот раз все было в очень цивилизованном месте, в IT-центре «Астрал», который хоть и находился среди пасторальных российских пейзажей прошлого тысячелетия, но в котором все было отлично и с проекторами, и со звуком, комфортными креслами и столиками, и кстати, с кофе, бутербродами и плюшками — так что если вы думали приехать, но не собрались — зря. Wish you were here!

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

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

В целом, очень большая часть докладов была связана с организатором — ALT LINUXом, и ALT-овая тусовка была и среди докладчиков и среди участников (см. «видеофотки» справа). Технологии сборки и дистростроительства, история и перспективные эксперименты с ARM-овым железом, всего понемногу:

• Прошлое, настоящее и будущее школьного комплекта ALT Linux (Андрей Черепанов, OSSDEVCONF-2013)
• Systemd в ALTLinux (Алексей Шабалин, OSSDEVCONF-2013)
• Mkimage-profiles, как инструмент укрощения ARM (Михаил Шигорин, OSSDEVCONF-2013)

• Крутим ARM в руках (Глеб Фотенгауэр-Малиновский, OSSDEVCONF-2013)
• Deepsolver. Статус разработки и предложения (Михаил Пожидаев, OSSDEVCONF-2013)

• кластер автоматизации сопровождения пакетов (Игорь Власенко, OSSDEVCONF-2013)

---

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

Про это и доклады и двухчасовой мастер класс Игоря Власенко, и доклад нашего ведущего системного архитектора:

• ROSA Updates Builder — автоматическое обновление пакетов из апстрима (Денис Силаков, OSSDEVCONF-2013)

За скобками обсуждений об оптимальной автоматизации, правда остался философский вопрос — ведь все таки изначально «дистростроительство с ментейнерами» подразумевало действительно, «феодальные наделы», множество ручной, «ремесленной» работы, «цеховые» регламенты «гильдии» ментейнеров, и плотную, духовную или практическую связь ментейнера с пакетом, когда ментейнер отлично разбирался и во внешнем, и внутреннем интерфейсе поддерживаемой софтины, активно пользовался ей, замечал косяки сборки, отвалившиеся фичи, баги, да и следил за изменениями, минимизируя шансы внедрения подлых закладок. А теперь, когда изменения роботизированно расползаются по репозиториями, а пакеты лишаются «души», то даже опенсорс не может служить защитой от внедрения хитрых типов уязвимостей, о чем и был доклад-дискуссия Проблема доверенного компилятора в механизме сертификации ПО (Дмитрий Державин, OSSDEVCONF-2013)

---

Лично меня очень заинтересовали доклады Михаила Пожидаева. В одном он рассказал о обреченном?смелом подходе к инсталляции пакетов через решение NP-полных задач → Статус разработки и предложения (Михаил Пожидаев, OSSDEVCONF-2013).

Немедленно вспоминается классика:

… — Голубчики, — сказал Фёдор Симеонович озабоченно, разобравшись в почерках. — Это же проблема Бен Бецалеля. Калиостро же доказал, что она не имеет решения.

— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как её решать.

— Как-то странно ты рассуждаешь, Кристо… Как же искать решение, когда его нет? Бессмыслица какая-то…

— Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица — искать решение, если оно и так есть. Речь идёт о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос… © «Понедельник начинается в субботу»

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

Второй же его доклад → Luwrain. ОС для людей с проблемами зрения (Михаил Пожидаев, OSSDEVCONF-2013), внезапно решено было закончить реальной демонстрацией того, что практически никто не видел → интерфейсом для слепых пользователей. Это было удивительно и пугающе, практически постапокалепсичная картина → затемненный подвал, мигающие черные буквы на красном фоне, механический голос компьютера и последние люди у клавиатуры… Это надо видеть, и это наверно обязательно надо посмотреть UX-специалистам, ибо UX → это не про раскрашивание кнопочек и шрифты.

---

Разумеется, не обошлось без роботов, рожденных как ползать, так и летать → был доклад и даже целый мастер-класс → Образовательный проект по робототехнике УМКИ на основе СПО (Игорь Воронин, OSSDEVCONF-2013)

---

Ребята из ИСПРАНа, поддерживающие проект «Linux Driver Verification», рассказали о мощных технологиях статического анализа, которыми они мучают линуксовые ядра, к сожалению, насколько я понял, сами технологии тащить в отдельное дистростроительство сильно непросто, с другой стороны, пока эти ребята работают, ядро линукса улучшается во всех дистрибутивах.

• Оценка покрытия кода при статическом анализе (Павел Андрианов, OSSDEVCONF-2013)
• Генерация модели окружения для группы модулей ядра для статической верификации (Илья Захаров, OSSDEVCONF-2013)

---

Веселая дискуссия вышла и по окончании доклада О свободных форматах публикации результатов научных исследований (Филипп Занько, OSSDEVCONF-2013) → ведь действительно, все старые форматы, ориентированные на обязательную страничную печать статей, и распространение через монопольных монстроиздательства, надо выпиливать, переходя к

• свободному распространению
• веб-публикации материалов.

И раздумывать надо уже над конкретными технологиями «авторинга», чтобы можно было максимально и совместно создавать контент, эффективно донося идеи до аудитории.

В некотором смысле, можно сравнить oldschool бумажные сборники тезисов конференции и страницы с аннотированным видео докладов → возможно пока еще бумага и нужна, но еще несколько лет, и бумажные носители точно можно будет списывать, а в вебпубликации, кроме текста, картинок и формул (уже можно в SVG-виде), видео и аудио, появятся какие-нибудь живые интерактивные модели, и вопрос, что лучше будет закрыт окончательно.

---

Были еще и другие доклады, например,

• Простой стек технологий для BDD-style разработки SPA на coffescript (Михаил Быков, OSSDEVCONF-2013)

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

---

Впрочем, еще один момент. Без потерь обойтись не удалось. Были и материальные поломки (колесо, аккумулятор ноутбука и т.п.). И, нематериальные — возможно потерян один доклад. Несмотря на многократную перестраховку (сьемка экрана фотоаппаратом, скринкастом на ноутбуке и захват фреймбгаббером), некий фейл случился → испорчен MP4 файл с записью экрана.

Если вы действительно разбираетесь в видео, (ffmpeg, VLC, untrunk, mplayer, mencoder я уже пробовал), попробуйте починить. Вот торрент с этим файлом (8GB!), если у кого получится — напишите мне, обещаю подарить ноутбук с ROSA Fresh.

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

(Десятая конференция разработчиков свободных программ)

• OSDN-UA-2013

Неделю, только опубликовав видео с OSSDEVCONF-2013, поехал с с миссией видеосьемки в Киев, на конфу с длинным названием «Всеукраинская конференция разработчиков и пользователей свободных программ», нареку ее сразу для краткости OSDN-UA-2013 (собственно аббревиатуру «OSDN-UA» я уже использовал в прошлом году, когда тоже снимал ее и публиковал видео, так что с «брендингом и неймингом» все ОК).

Да, путь неблизкий, SYSTEM INTERRUPTS таможнями и пограничниками, все дела, хотя в этот раз добрался удачней. В прошлом году организаторы рекомендовали мне взять такси на вокзале… и мне достался какой-то сельский крендель, который возил меня (с распечатанным адресом и картой) битый час, и умудрился высадить за пять км от цели — и я еще час плюхал пешком ориентируясь по Яндекс.Картам. В этот раз я опросил Яндекс.Карты сразу, и обнаружил, что до места конференции можно 20 минут доехать на самом модном евротранспорте — трамвае, параллельно устроив себе небольшую экскурсию. Опять куча оборудования, хотя и поменьше.

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

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

--- Где сядем?

--- Да все равно, главное --- не возле камер.

©

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

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

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

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

PR/продуктовые доклады

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

• Шестая платформа ALT Linux в медицинских учреждениях России 2012-2013 (Алексей Новодворский, OSDN-UA-2013) — Success-story от альтлинукса, в пику очередному брожению по рулинукснетам историй про 36тыщ убунт в Приватбанке и 30тыщ каких-то других линуксов у французских жандармов тут целых 45 тыщ по медицинским учреждениям по всей РФ! Уели, win! Хотя кто знает, сколько по этой программе поставили «виндов», вдруг миллионы?.

• OpenShift — окрытое PaaS-решение Red Hat (Андрей Маркелов, OSDN-UA-2013) — Yet another *aaS, с платным сервисом, но опенсорс в душе. На сервисе я даже полгода как зарегистрировался, помню что как-то жало ограничение по бесплатным контейнерам (хотел отдельно тестовый, отдельно продакшн), но все дело в лени и нехватке времени — просто надо сесть и родить какое-нибудь фейсбук приложение, заодно и потестить облачко. Или все таки реализовать мечту о личном датацентре на балконе, и развернуть OpenShift там.

• GRID in Cloud (Дмитрий Сподарец, OSDN-UA-2013) — Yet another GRID, да еще и в облаках, ну и притом стартап.

• OpenSCADA — целевая стабилизация (Роман Савоченко, OSDN-UA-2013) — Наконец-то продукт, не от «айтишников айтишникам», а полезный в рил-индустрии! Бизнес, алло! Сколько можно брать дырявые (плюс прочий Stuxnet) залоченные на вендоров системы! Вот стабильный продукт, причем автор поддерживает даже DE → TDE=KDE3 для удобства и стабильности. Кстати, прошлогодний доклад автора по теме → [1]

• Эволюция лени, или об использовании облаков для максимальной автоматизации ИТ (Владимир Мельник, OSDN-UA-2013) — еще раз «облака» от компании «tucha». Надо наверно зарегить домены «tucha.*» и перепродать их под какие-нибудь Национальные Облачные Платформы.

Для программистов

• LIVR. Language Independent Validation Rules. Независимые от языка правила валидации (Виктор Турский, OSDN-UA-2013) — фреймворк валидации, под которой имеется в виду именно валидация данных вебформ, а не 100500 других возможных значений. Yet Another DSL на JSON-структурах, из которого кодогенерацией рожается и JS-фронтэнд проверки, и бекэнд проверки на нескольких языках (Perl/PHP/Ruby).

• Учи Perl…! (Дмитрий Шаматрин, OSDN-UA-2013) — апология Perlа, бой всему молодому и модному дает вроде как главред PragmaticPerl — издевательские тролль-тесты над Python-ом, хейтерские картинки, ragged faces, издевательские примеры для перл-неосиляторов, и недоумение — «за что вы нас ненавидите, мы же не нападаем на Ruby/Python и все остальное новое и модное?». Я пожалуй, все таки поясню — если бы каждый программист имел абсолютную свободу воли по выбору языка-фреймворка, причем в каждый момент времени — нет вопросов. Счастье всем даром и никто не уйдет обиженным. Проблема возникает в том, что старые языки и фреймворки реально занимают место, мешают пробится более правильным фреймворкам и языкам, а программистам постоянно приходится поддерживать либо legacy системы, либо старые opensource проекты, в которых куча функционала, но writeonly язык сделал невозможным портирование… Вот я давно не могу собраться с силами чтобы залезть и патчить-мержить багзиллу. Так что в некотором смысле, эта ненависть вполне обоснована, и иногда нельзя не согласится с Пушкиным «Мой дядя самых честных правил, когда не в шутку занемог, то уважать себя заставил, и лучше выдумать не мог», и понять, что иногда стюардессу реально нужно окончательно закопать.

• «Покращення вже сьогоднi» или оптимизация процесса разработки (Николай Маржан, OSDN-UA-2013) — отличное описание процесса разработки, с заданным ритмом деплоя и git-ветвлений, с регулярными стабильными релизами («Хотела похороны на Красной площади? — ОК, делай что хочешь, deploy будет завтра»), когда опоздавшие фичи не ждут.

Сисадминам

• Keep Calm and Enable IPv6 (Дмитрий Кохманюк, OSDN-UA-2013) — бодро, с шутками и прибаутками про неизбежный новый мир с IPv6, населенный роботами, домашними приборами, без NATa и бизнеса на продаже IP-адресов, когда опять таки «счастью будет всем, даром и никто не уйдет…».

• Simpleness Parental Control (Дмитрий Иванов, OSDN-UA-2013) Забавная DIY-поделка на тему толи антипорно фильтров для детей, толи для сбора этих самых порноадресов, выбранных детьми.

• Практическое применение Asterisk (Алексей Радецкий, OSDN-UA-2013) — рассказ от практика, который на внедрениях астериска «крокодила сьел, собакой закусил». Кратко — везде в конторах Адѣ и Бардакѣ, но опытный спец все равно все настроит, и роботы и прочие сотрудники коллцентров продолжат спамить вас «холодными звонками», а если вы звоните в банк, и просрочили кредит, вас сразу автоматика переключит на специально обученных людей, и вы быстро все заплатите.

Дистростроителям

• Mkimage-profiles. Образы трёх лет (Михаил Шигорин, OSDN-UA-2013) — Очередная серия Мишиного многосерийного сериала про mkimage-profiles. Предыдущие серии → [2], [3].

• Автоматизированное сопровождение пакетов в дистрибутивах ALT Linux (Игорь Власенко, OSDN-UA-2013) — продолжение темы сборочных роботов (см. [4]), и даже дискуссия с нашим отзывом по философским вопросам. Ну, тут можно все таки развить мысль, что мои возражения были связаны не с тупым луддизмом, а с тем, что изначальная структура ручной сборки подразумевала, что полноценный дистрибутив был обязан собрать вокруг себя коммьюнити, сформировать структуру социальных связей, и тем самым, легимитизироватся (как это было с вопросами власти в феодальные времена). Сейчас небольшая группа хакеров все это может сделать автоматически, и будет свежий дистрибутив, но почти без людей… Может даже представить фантастический роман «все люди вымерли, а дистрибутивы продолжают собираться и публиковаться…» Бррр. С другой стороны, может это и более правильно, исключить человеческий фактор, чтобы дистростроители делали минимальное вмешательство в апстримовые программы, а не вообразив себя супер-программистами, грязными руками приступали к нейрохирургии «улучшений и оптимизаций», эпикфейлово ломая продукт.

Научно-фантастическое

• Велосипедостроение - старые “новые” идеи, которые стоит иметь в виду (Руслан Шевченко, OSDN-UA-2013) — Хорошая мысль, на тему необходимости образования в Computer Science и истории развития языков и технологий, чтобы за модными программерскими брендами видеть реализацию архетипов — моделей вычислимости, алгоритмических подходов и т.п.

Тогда бы не пришлось делать доклады из серии «ненаучная фантастика»:

• Фреймворк QSMM, как прототип системы синтеза алгоритмов (Олег Волков, OSDN-UA-2013) — Автору просьба посмотреть, что такое недетерминированные и вероятностные машины Тьюринга, локальные и вероятностные эвристики оптимизации, и ведь выражение «алгоритм запускается несколько раз», может означать экспоненту от экспоненты длины входных данных, а эвристика «продолжаем, пока улучшается» — может свалится в локальный оптимум, и вообще не гарантирует никакого качества.

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

• Data Science. The art of «foul play» (Сергей Шелпук, OSDN-UA-2013) — Научно популярно, о Data Mining in Big Data, с рассказом о баянах из серии «компьютер угадал беременность по покупкам», «нейросеть гугла по распознаванию картинок сформировала котего-нейрон» и т.п.

• Оценка эффективности мультипрограммной работы в современных Linux GUI (Дмитрий Костюк, OSDN-UA-2013) — по мне, это самое прикольное и вкусное — любимая тема Димы, юзабилити исследование Desktop Environmentов на кошках-студентах, с использованием подручных девайсов, от нейроизмерителей и датчиков сердечного ритма… Пока эти исследования неинвазивные, но кто знает, может следующий раз нам представят прототип нейрошунтового управления «рабочим столом», на базе «трепанированный студент, провода, скотч, линукс». Более серьезно на эту тему надо будет написать отдельно… Может опубликовать стенограмму или статью, и даже сунуть куда-нибудь на хабр для массового фидбека.

Доклады на украинском

Ничего не могу сказать, кроме как, смотрите, пожалуйста, товарищи, господа пане украинцы.

• Использование СПО на факультете электроники ЛНУ ИМ. И. ФРАНКО. ПЕРЕЗАГРУЗКА (Григорій Злобін, OSDN-UA-2013)

• OpenOrienteering Mapper (Eugeniy Fedirets, OSDN-UA-2013)

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

Впрочем, если на эту страницу попали строгоукраиноговорящие, то вот отчет о конференции на украинском:

… Допо­віді були різні, в основ­ному, огля­дові, зві­сно. Про від­вер­тий треш не хочу зга­ду­вати, а от Мар­ке­лова з OpenShift'ом, Раде­цького з Asterisk'ом, Мар­жана з «Покра­ще­н­ням…», Шама­тріна з Perl'ом, ну і, зві­сно, Костюка з оці­ню­ва­н­ням GUI хоче­ться виді­лити окремо. Цікаво було. На пере­р­вах із задо­во­ле­н­ням слу­хали Фоміна, який тепер пиляє дескто­пну ROSу. Жаль, що не було купи ціка­вого народу, як київ­ських, так і не київ­ських, напри­клад, Злобіна. …

---

Итак, приятного просмотра, на всякий случай, вот еще

• фотки с конфы,
• мой отчет о прошлогоднем OSDN,
• другие Open-Source конференции, снятые нами за последний год: OSDN-UA-2012, PingWinFest-2012, OSEDUCONF-2013, ROSS-2013, OSSDEVCONF-2013).

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

Как вам эта конфа?

Гуд! Уже смотрел и буду еще. 7 58% ОК. Не смотрел, но взгляну, вроде есть интересные темы. 3 25% Как-то не заинтересовала. 0 0% Ненавижу (опенсорс, линукс, украину, конференции) 2 17%

(Всеукраинская конференция разработчиков и пользователей свободных программ)

• LinuxCon Europe 2013 - О поиске "гонок" в ядре Linux

22 октября состоялось выступление нашего сотрудника Евгения Шатохина на конференции LinuxCon Europe 2013. Речь шла о средствах поиска таких трудноуловимых ошибок, как «состояния гонки», они же «data races» в компонентах ядра Linux (слайды, пояснения к слайдам).

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

Такие ситуации далеко не всегда просто выявить, а последствия у них могут быть самыми разными, от незначительных до критических. Для ядра Linux это особенно актуально: код драйверов, например, может выполняться многими потоками одновременно. Добавим к этому обработку прерываний и других асинхронных событий, а также учтём, что правила синхронизации доступа к общим данным из разных потоков далеко не всегда описаны чётко (а нередко — не описаны вообще)…

Об инструментах, позволяющих выявлять data races в компонентах ядра Linux, в основном, и шла речь в выступлении. Наиболее подробно — о системах KernelStrider и RaceHound, одним из основных разработчиков которых Евгений и является.

KernelStrider собирает информацию об анализируемом компоненте ядра (например, драйвере) в процессе работы этого компонента. Информация об обращениях к памяти, выделении и освобождении памяти, блокировках и т. д. затем, уже в user space, анализируется инструментом ThreadSanitizer (Google). Алгоритм поиска races коротко описан тут.

KernelStrider может в некоторых случаях выдавать сообщения о data races там, где data races нет («false positives»). Например, при анализе сетевых драйверов такое было в случаях, когда драйвер отключал генерацию прерываний соотв. устройством и затем обращался к каким-то общим данным, не опасаясь конфликтов с функцией-обработчиком прерываний.

Система RaceHound позволяет проверить результаты, полученные с помощью KernelStrider, найти среди них те, которые, действительно говорят о data races. RaceHound работает так:

• На инструкцию в коде ядра, которая может быть «замешана» в data race, ставится программная точка прерывания («software breakpoint»).
• Когда эта точка прерывания срабатывает, RaceHound определяет адрес области памяти, куда эта инструкция обратится, и ставит аппаратную точку прерывания («hardware breakpoint»), чтобы отследить обращения нужного вида к этой области (только запись или произвольные обращения).
• Делается небольшая задержка перед выполнением интересующей инструкции.
• Если во время задержки какой-то другой поток обратится к указанной области памяти, аппаратная точка прерывания сработает и RaceHound сообщит о найденной data race.

То есть при анализе компонентов ядра KernelStrider работает своего рода «детективом-аналитиком», сужая круг «подозреваемых» — мест в коде, которые могут участвовать в data races. RaceHound тогда — система слежки за этими подозреваемыми. Если ей удаётся поймать подозреваемого с поличным (то есть при выполнении конфликтующих доступов к памяти) — всё ясно. Если не удаётся — это ничего не значит.

Как во время, так и после доклада, вопросов было довольно много. Слушателей интересовали, например, такие вещи, как:

• Планируется ли поддержка ARM (пока всё работает только на x86), — возможно, но не в ближайшем будущем.
• Может ли KernelStrider пропускать data races (то есть возможны ли false negatives) — да, может в некоторых случаях, в основном, из-за особенностей алгоритма работы ThreadSanitizer и из-за неточностей используемых правил определения порядка событий.
• Переживает ли KernelStrider suspend/resume — да, переживает.
• Можно ли с помощью KernelStrider и RaceHound анализировать не только модули ядра, но и само ядро — пока нет.
• Можно ли в KernelStrider инструментировать код анализируемого драйвера не при загрузке этого драйвера, как сейчас, а при компиляции — очень вероятно; это одно из возможных направлений развития.
• и т. д.

В обсуждении data races, найденных указанными выше инструментами, активно участвовали сотрудники Intel, что немудрено: речь шла о races в сетевом драйвере e1000, разработанном как раз в этой компании. Во время обсуждения выяснился интересный факт: для обращений к памяти в некоторых частях сетевых драйверов средства синхронизации использовать почему-то не принято, хотя там из-за этого могут быть «гонки» (они там и обнаружились). Это, в частности, относится к NAPI и функциям драйвера, участвующим в передаче данных по сети. Вроде бы всё так делается, чтобы избежать потерь производительности из-за блокировок, но ни оценок этих потерь, ни конкретных рекомендаций, как при этом избежать проблем из-за «гонок», пока найти не удалось.

В целом, похоже, что отношение к data races у многих разработчиков ядра такое:

— Что-то из-за этой data race упало или стало работать неправильно?

— Пока не замечали.

— А, ну, ладно.

И на этом разговор кончается.

Логично? Вроде бы да, но, если вспомнить, например, вот эту статью, всё уже не так очевидно.

• Осенний листопад конференций! SECR, ProductCamp, AgileKitchen, WUD — смотрите все

... to delete

Новости наших сайтов

• Редизайн wiki.rosalab.ru — стильная мода для нашей вики

Мы планируем активно наполнять wiki.rosalab.ru документацией, ценными статьями, переводами, блогами наших команд, и многим другим… но нас смущает один момент.

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

И в мире вебдизайна идут волны модного дизайна, «clear and simple», так, чтобы глаз отдыхал на иллюстрациях и дизайне, а все стандартные дизайны MediaWiki — это про плотные блоки пролинкованного текста сетевых энциклопедий, с кучей торчащих инструментов редактирования, доступа к истории правок, и т.п.

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

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

Итак, встречайте макет дизайна для нашей вики →

Оценить и проголосовать!

Как вам этот дизайн для вики?

•  Отлично
•  Хорошо
•  Удовлетворительно
•  Неудовлетворительно

Какие эмоции у вас вызывает этот дизайн?

•  Возмущение
•  Грусть
•  Надежда
•  Одобрение
•  Отчаяние
•  Радость
•  Смех
•  Страх
•  Стыд
•  Удивление
•  Удовлетворение

Ну или пишите ваши замечания и предложения → можно комментариями здесь (но надо зарегистрироватся), можно в том месте, где вы увидели ссылку, можно просто писать на почту Стасу Фомину → мы постараемся собрать все отзывы.

• talks.rosalab.com — конференции, которые всегда с вами

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

Публикуем мы все это на «ROSA-Медиатека», http://talks.rosalab.com. Это удобная видеотека докладов с ряда софтверных конференций, удобно категоризованная, присобленная и для удобного просмотра, и для фидбека.

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

Низок КПД и для докладчиков — человек может несколько недель готовить доклад, а получить аудиторию всего из пары десятков человек.

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

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

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

• Тупая запись одной камерой — невозможно ничего рассмотреть на экране.
• Все это вываливается, в лучшем случае, единым альбомом на ютуб. Тут еще проблема в том, что нет
  • никакой связи с докладчиком — непонятно, кто автор, стоит ли его смотреть, кому задавать вопросы, если возникнут, как посмотреть другие его доклады и т.п.
  • сложно понять, стоит ли смотреть — аннотация отдельно, даже если слайды выложены на слайдшаре — их долго листать, чтобы понять, примерно о чем, достаточно ли качественно сделана визуальная часть, или там «смерть от Powerpointa».
  • Ютуб грузит рекламу, и на дает загрузить само видео (без специальных приседаний, о которых мало кто в курсе).
  • Комментировать в ютубе (плоский список комментов) не очень удобно, и трудно вести длинную осмысленную дискуссию, для которой, как минимум, требуется древообразная система комментариев.

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

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

У нас же:

• Правильная видеосьемка и монтаж, с раздельной сьемкой докладчика и экрана, c ускорением, на базе наших обкатанных технологий (вот мой короткий рассказ о них, рекомендую).
• Единая база по целому спектру конференций, пара сотен докладов, куча дополнительных статей — категории, участники, всего где-то под тыщу.
• Сделана и расширяется тематическая классификация, каждый доклад может быть приписан к нескольким темам (например, Образование + Программирование или Управление продуктами + Юзабилити …).
• Есть группировка и классификация и по авторам, причем для каждого автора, кроме подборки его докладов, есть ссылка на его актуальный профиль в профессиональных социальных сетях, чтобы можно было ознакомится, кто это, стоит ли его слушать, и чтобы с автором можно было связаться, даже если он сменит работу. Ох, как это было непросто. Ведь часто про автора даже после доклада ничего не известно, контактов на слайдах нет, сам не представился, в программе только фамилия и инициалы... Иногда приходилось делать целое расследование, потратив несколько часов, и бывало даже, безрезультатно…
• По конференциям тоже все разложено.
• Для каждого доклада есть аннотация, ссылки на дополнительную информацию, а слайды развернуты в «быструю инфографику» листаемых картинок, чтобы можно было просто пролистать колесом мыши, и гештальтно ознакомится с визуальной частью («смерть от PowerPointa» или нормальная визуализация, какие там ключевые слова и картинки видны, будет ли это про архитектуру, или просто «веселые картинки» менеджерского доклада).
• Верстка максимально адаптирована для зрителя:
  • в целом — чистый whitespace дизайн, что сейчас в тренде.
  • никаких лишних блоков, рекламы и прочего спама.
  • adaptive design — удобная для чтения основная колонка, оптимальной для чтения ширины, а дополнительные блоки — классификации, поиска и комментирования на широких экранах идут вбок, а на узких — уходят вверх и вниз — теоретически все должно быть ОК на планшетах и даже смартфонах.
• прикручена стандартная, известная всем система комментирования DISQUS (~80% сайтов c внешней системой комментариев сделана на этой системе) — вполне можно всласть пообсуждать.

Теоретически, у нас тут возникает «Непрерывная Распределенная Многотематическая IT-конференция», когда вброшенные в сообщество мысли и идеи продолжают обсуждаться задолго после доклада, связывая задающих вопросы с знающими ответы. Ведь на самой конференции практически никогда не бывает достаточно времени для обсуждения, фраза модератора «Время вышло, обсуждение можно продолжить в кулуарах» звучит практически на каждом докладе, да и не всегда слушатель готов сразу отрефлексировать тему, и задать осмысленные вопросы. Другое дело, что сейчас люди уже почти отучились писать отзывы и рецензии, поэтому…

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

Welcome! Посмотрите, возможно найдутся интересные вам доклады.

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

Кстати, кроме записей конференций, есть также проведенные нами записи вебинаров дружественной нам компании PingwinSoft.

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

Живые инсайд-вебинары от команды «РОСЫ»:

Отличная, буду участвовать 8 73% Хорошая, возможно посмотрю. 3 27% Плохая, «нинужно» 0 0%

Возможно это развеет безумные мифы о нашей работе, бродящие в анонимных обсуждениях на ряде сетевых ресурсов…

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

Как обычно, описание большого числа доработок GRUB2

• Ряд улучшений и багфиксов для GRUB2

Наши разработчики продолжают работать над улучшением загрузчика GRUB2.

Были реализованы и приняты в апстрим ещё 14 патчей.

Улучшено билинейное масштабирование

Было

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

Стало

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

Было

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

Стало

Новая опция scrollbar-slice

В GRUB графическое оформление реализовано в виде «коробок», состоящих из 9 областей. Угловые области не масштабируются,

• «северная» (верхняя) и «южная» (нижняя) масштабируются по горизонтали,
• «западная» (левая) и «восточная» (правая) — по вертикали,
• центральная — по горизонтали и по вертикали.

Есть элемент графического оформления меню загрузки («menu_pixmap_style»). Можно выбрать, в какой области будет нарисована полоса прокрутки.

• «east», восточная — так же, как было раньше, полоса прокрутки рисуется в восточной части оформления меню.
• «west», западная — полоса прокрутки рисуется слева от меню, в западной части оформления меню.

Особенна интересна опция «center». Полоса прокрутки рисуется в центральной части оформления меню. В этом случае можно не указывать и не создавать оформление меню. Если полоса прокрутки не нужна (пунктов меню загрузки мало), пункты меню загрузки будут занимать всю ширину центральной части оформления меню (или всю ширину меню загрузки, если оформление не указано). Если полоса прокрутки нужна, ширина пунктов загрузки будет уменьшена. Таким образом, мы получаем более привычное и ожидаемое поведение окошка меню загрузки. Это, к тому же, сильно упрощает процесс разработки новой темы GRUB2.

Новые опции для отступов полосы прокрутки

Можно задать отступы для полосы прокрутки в пикселях.

Новая опция scrollbar_overlay

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

Новая опция progress_highlight_overlay

Аналогично «scrollbar_overlay», но для горизонтального индикатора отсчёта обратного времени.

Исправлен подсчет минимальной ширины меню загрузки

Если задать значение ширины меньше, чем минимально необходимое, меню загрузки будет автоматически расширено. Формула расчёта минимальной ширины была улучшена.

Исправлена прорисовка полосы прокрутки (1 патч)

Ранее полоса прокрутки прорисовывалась неверно, если использовать все 9 областей для фона и для ползунка.

Исправлена прорисовка полосы прокрутки (2 патч)

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

Исправлено отображение горизонтального индикатора отсчёта обратного времени

Были проблемы с прорисовкой горизонтального индикатора отсчёта обратного времени в случае, если выделение имеет западные / восточные области.

Исправлена утечка памяти

Обнаружена и исправлена утечка памяти.

Реализована проверка корректности параметров полосы прокрутки

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

Реализована проверка корректности параметров горизонтального индикатора отсчёт обратного времени

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

Обновление официальной документации

Документация, относящаяся к синтаксису тем GRUB приведена в актуальное состояние.

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

Ввела в экстаз ^_^ 10 63% Порадовала :) 6 38% Оставила равнодушным -_- 0 0% Огорчила :( 0 0%

• GRUB2: новый функционал - размеры и положение терминала

Наши разработчики продолжают улучшать GRUB.

В этот раз они реализовали новый функционал - теперь в файле темы можно задать местоположение и размеры терминала.

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

terminal-left: "50"
terminal-top: "50"
terminal-width: "800"
terminal-height: "600"
terminal-border: "10"

Патч был одобрен апстримом и добавлен в исходный код.

И еще раз отдельно — статьи-опросы, займут считанные секунды вашего внимания

• Редизайн wiki.rosalab.ru — стильная мода для нашей вики

Мы планируем активно наполнять wiki.rosalab.ru документацией, ценными статьями, переводами, блогами наших команд, и многим другим… но нас смущает один момент.

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

И в мире вебдизайна идут волны модного дизайна, «clear and simple», так, чтобы глаз отдыхал на иллюстрациях и дизайне, а все стандартные дизайны MediaWiki — это про плотные блоки пролинкованного текста сетевых энциклопедий, с кучей торчащих инструментов редактирования, доступа к истории правок, и т.п.

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

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

Итак, встречайте макет дизайна для нашей вики →

Оценить и проголосовать!

Как вам этот дизайн для вики?

•  Отлично
•  Хорошо
•  Удовлетворительно
•  Неудовлетворительно

Какие эмоции у вас вызывает этот дизайн?

•  Возмущение
•  Грусть
•  Надежда
•  Одобрение
•  Отчаяние
•  Радость
•  Смех
•  Страх
•  Стыд
•  Удивление
•  Удовлетворение

Ну или пишите ваши замечания и предложения → можно комментариями здесь (но надо зарегистрироватся), можно в том месте, где вы увидели ссылку, можно просто писать на почту Стасу Фомину → мы постараемся собрать все отзывы.

• Наши дистрибутивы используете? Какие? Опрос.

Секундучку внимания, если вы используете какой-нибудь из наших десктопных дистрибутивов — пожалуйста, отметьте, какой — ваше мнение очень важно для нас!

Какой из наших дистрибутивов-систем вы используете в данный момент:

ROSA 2011 1 1% ROSA MARATHON 7 10% ROSA FRESH KDE 41 60% ROSA FRESH GNOME 9 13% ROSA FRESH LXDE 6 9% Неупомянутый дистрибутив от ROSA (секретные и т.п.). 3 4% Ничего из перечисленного 1 1%