Единое окно доступа к образовательным ресурсам

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

Голосов: 0

В книге собраны тезисы докладов, одобренных Программным комитетом десятой конференции разработчиков свободных программ, которая прошла в городе Калуге 20-22 сентября 2013 года.

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.
    Дневное заседание (14.50–18.10)                                         51


Заключение
   на этом можно было бы закончить, тесты выполняются. Но в ре-
альной разработке также полезно установить модули
   • grunt-coffee-jshint проверяет корректность coffeescript
   • grunt-contrib-jshint   проверяет корректность js
   • grunt-mocha-cli  может быть полезно для прямого тестирова-
     ния JS, минуя браузер
   • grunt-browserify конвертирует coffeescript в js и собирает един-
     ственный файл app.js
   • grunt-contrib-concat объединяет полученный app.js со статич-
     ными скриптами типа jQery
   • grunt-contrib-watch   наблюдает за изменениями в указанных
     файлах, автоматически стартует выполнение тестов
   Все они устанавливаются предельно просто, без каких-либо хит-
ростей по соответствующим описаниям. Вместо Browserify.js можно
использовать Component.js.
   Voila.

Дмитрий Костюк, Алексей Шитиков
Брест, Брестский государственный технический университет

Оценка эффективности мультипрограммной работы
оператора в современном графическом интерфейсе
                   GNU/Linux

                               Аннотация
      Выполнена сравнительная оценка эффективности взаимодействия
   оператора с несколькими приложениями в интерфейсе графических
   окружений KDE Plasma Desktop, Ubuntu Unity и Gnome Shell (включая
   модифицированный вариант последнего). Для оценки состояния опе-
   ратора используются хронометраж, протоколирование, измерение сер-
   дечного ритма и энцефалограммы. Сравниваются темп работы, физи-
   ческая нагрузка, концентрация внимания, а также время реакции. Вы-
   полнено ограниченное тестирование тех же оболочек на планшетных
   ПК. Обсуждается негативное влияние неотвлекающих полноэкранных
   интерфейсов на сосредоточенность оператора.


52                                                    21 сентября


    Ряд публикаций последнего времени ставит под вопрос пригод-
ность для многозадачной работы графических окружений (DE),
совершивших в 2011 г. отход от метафоры рабочего стола (DM)
в сторону сенсорного управления, заимствованного у портативных
устройств. Этот шаг влил конкретный смысл в термин post-DM
interface , долгое время бывший умозрительной абстракцией. При-
чиной перехода можно считать реакцию на планшеты, оказавшиеся
весьма популярными, но оставлявшие чувство неудовлетворённости
из-за слабого, в сравнении с ПК, функционала приложений и гра-
фических оболочек. Очевидно, что DE, удобное одновременно для
планшета с сенсорным экраном и для управления мышью, получило
бы огромное преимущество на рынке [1].
    В этих post-DE наиболее заметны перемены, связанные с от-
казом от панели задач, с альтернативным управлением окнами и с
запуском приложений. Изменения касаются также способов оповеще-
ния о событиях. В рамках концепции неотвлекающего интерфейса
пользователя стимулируют работать с приложениями в полноэкран-
ном режиме, скрывая неосновные элементы DE.
    Реальная цена перемен не очевидна как на ПК, так и на планше-
тах. Поэтому, чтобы получить количественные критерии эффектив-
ности многозадачной работы, мы сформировали ряд тестов, нагру-
жающих оператора взаимодействием с мультипрограмной средой и
отслеживающих показатели его активности скорость работы, вели-
чины физической и ментальной нагрузки, а также способность свое-
временно реагировать на события.
    Разработанные тестовые программы взаимодействуют с графиче-
ской оболочкой, требуя поочерёдной работы в нескольких окнах, с
оценкой числа выполненных за фиксированное время типовых опе-
раций либо длительности их выполнения. Помимо темпа и точности
действий, состояние оператора фиксируется монитором частоты сер-
дечных сокращений (ЧСС) и электроэнцефалографом (ЭЭГ). В экс-
периментах нами использован спортивный пульсометр, фиксировав-
ший среднюю и пиковую ЧСС за время теста, а также бытовой ЭЭГ
NeuroSky Mindwave, встроенный контроллер которого вычисляет в
условных единицах степень концентрации внимания оператора (т. н.
технология eSense).
    В качестве классических DE тестировались LXDE и KDE с пане-
лью задач внизу экрана, а в качестве post-DE Gnome Shell и Unity
из дистрибутива Ubuntu 12.04. В ряде тестов рассматривалась также


Дневное заседание (14.50–18.10)                                 53


модификация Gnome Shell с миниатюрами окон вдоль левой границы
экрана. Мини-окна реализованы расширением WinThumbnails [2].
    Тестирование проводилось преимущественно на ноутбуке с экра-
ном 13 дюймов, а также на 10-дюймовом Android-планшете, получав-
шем удаленный доступ к DE по протоколу VNC. Близкое разрешение
экрана в ноутбуке и планшете позволило убрать масштабирование в
VNC-клиенте, что по возможности приближало работу к варианту
запуска DE непосредственно на планшете.
    Тестирование проводилось в три этапа. На первом этапе пользова-
тель имел дело с двумя перекрывающими друг друга окнами, озаглав-
ленными как Source и Destination . В ходе итерации теста требует-
ся без клавиатуры скопировать число из одного окна в другое с помо-
щью контекстного меню, после чего нажать в исходном окне кнопку
перехода к следующей итерации. На втором этапе для вставки чисел
на каждой итерации указывалось одно из трех присутствующих окон
 Destination , что позволило оценивать эффективность управления
для многооконных приложений [1]. На третьем этапе окна Source
и Destination поочередно показывают графические фигуры: снача-
ла кнопку с изображением фигуры в окне Source , затем 25 кнопок
с фигурами в окне Destination (в ходе итерации требуется нажать
кнопку с одинаковой фигурой в обоих окнах). Третий этап копиру-
ет методологию исследования запоминания и распознавания фигур,
в свое время выполненного Р.М. Грановской и И.Я. Березной [3].
   На первом этапе KDE и Gnome показали малое расхождение в
темпе; зато включение мини-окон в Gnome позволило добиться мак-
симального темпа. Монитор ЧСС предсказуемо зафиксировал мини-
мальную физическую нагрузку на пользователя в KDE и максималь-
ную в Gnome с мини-окнами. Концентрация внимания находилась в
нейтральной зоне для всех оболочек и имела минимальный уровень в
стандартной версии Gnome.
   На втором этапе благодаря визуально-различимым миниатюрам
Gnome получил преимущество, показав наибольший темп (а мини-
мальный, аналогично [4], продемонстрировала оболочка Unity из-за
неудобного переключения между окнами одного приложения). Фи-
зическая нагрузка также оказалась максимальной в Gnome. Наи-
большую сосредоточенность пользователя демонстрировала оболочка
Unity (однако к концу работы концентрация внимания несколько сни-
жалась). Минимальной концентрация оказалась в KDE, а кроме того,


54                                                      21 сентября


в KDE этот параметр характеризуется меньшим размахом колебаний
(т. е. большей стабильностью).
    Третий этап теста дополнительно к исследованию DE проводился
в тайловом режиме, без переключения окон. В данном режиме те-
стируемые показали максимальный темп, и в среднем более корот-
кие паузы на поиск фигуры (время поиска). При сравнении графиче-
ских оболочек максимальный темп продемонстрировали DE с пане-
лью задач (преимущественно на данном этапе тестировалась оболочка
LXDE), а минимальный темп был получен для Unity. При этом субъ-
ективно большинство тестируемых давали неверную оценку темпа,
утверждая, что миниатюры окон ускоряют работу, позволяя начать
выбор фигуры ещё в процессе переключения окон.
    Среднее время поиска среди DE имело минимальные значения в
LXDE и максимальные в Unity. Однако интересен разброс пиковых
значений времени поиска, т. е. ситуации, когда тестируемый впадает
в ступор. Самый длительный ступор наблюдался преимущественно
в Gnome, а второй по длительности в тайловом режиме, что под-
тверждает роль переключения окон как полезной помехи, снижающей
умственное напряжение [1]. Наименее же заметным ступор оказался
при использовании панели задач. Средняя концентрация внимания
предсказуемо была максимальна в тестах с тайлингом, а среди DE
с панелью задач. Далее по величине, как ни странно, идет концентра-
ция внимания в Unity, а Gnome Shell замыкает ряд. Распределение
пиковых значений концентрации внимания аналогично усредненным,
за исключением того, что Unity и Gnome Shell меняются местами, т. е.
уровень внимания в Gnome оказался менее ровным.
    Учитывая наихудшую скорость прохождения теста и высокую кон-
центрацию внимания в Unity, достаточно интересен вопрос, на что
именно тратится умственная энергия: можно предположить, что на
взаимодействие с механизмом переключения окон, а также на тре-
бующее большей сосредоточенности [4] горизонтальное перемещение
мыши.
    Относительно Gnome следует отметить, что за счет энергичного
забрасывания указателя мыши в угол экрана, скорость прохождения
теста в этой оболочке оказалась выше, чем в Unity. Более того, части
тестируемых удалось разогнаться в процессе работы, приблизив-
шись по скорости к LXDE (конечно, за счет большей ЧСС).
    При тестировании пользователей на планшете применялся пре-
имущественно второй этап теста. При этом не тестировались мини-


Дневное заседание (14.50–18.10)                                 55


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

   Меньшая скорость работы с планшетом по сравнению с ПК оче-
видна. Однако превышение темпа при управлении мышью было
неодинаковым: минимальное отличие в 1.5 раза наблюдалось в KDE,
а Gnome и Unity показали на планшете падение темпа приблизитель-
но в 2.5 раза. Физическая нагрузка в KDE оказалась практически
аналогична для сенсорного экрана и для управления мышью, а post-
DE оправдали свое назначение, показав на планшете слегка меньше
значения (в 1.1–1.2 раза) не в последнюю очередь благодаря более
крупным виджетам тем оформления. Умственная нагрузка на план-
шете и ПК, наоборот, была практически одинакова в оболочке Unity,
а для настольных версий KDE и Gnome составила соответственно 0.8
и 0.7 от таковой в планшетном варианте.

   В качестве вывода можно заметить, что в целом классические DE
остаются высокоэффективными и предоставляют наиболее удобное
переключение окон для сенсорного экрана, если пользователь может
себе позволить место для массивной панели задач. Переключение в
отдельный режим управления окнами вносит скорее негативный эф-
фект: не обеспечивает высокой скорости работы и при этом прико-
вывает внимание, что при продолжительном активном переключении
окон приводит к росту усталости и может периодически вводить поль-
зователя в состояние ступора. Это явно противоречит цели разработ-
чиков создать неотвлекающую рабочую среду. Актуальным также яв-
ляется вопрос эффективности расходования ментальной активности:
с учетом того, что в проведенных тестах показали себя наиболее про-
блемными Unity на ПК и Gnome на планшете, тезис о незначительных
жертвах настольных DE в пользу удобного сенсорного управления
ощутимо теряет в убедительности, а также делает целесообразным
сравнительный анализ существующих модификаций данных графи-
ческих оболочек.


56                                                           21 сентября


Литература
[1] Костюк Д.А. и др. Исследование эффективности переключения окон
    в современных графических интерфейсах // Вестник БрГТУ., 2011.
    № 5(71): Физика, математика, информатика. С. 45–48.
[2] Starun A. WinThumbnails. http://extensions.gnome.org/extension/
    335/winthumbnails
[3] Грановская Р.М., Березная И.Я. Запоминание и узнавание фигур. / Л.:
    Изд-во Ленинградского ун-та., 1974. 96 с.
[4] Костюк Д., Дереченник С., Шитиков А. Оценка эффективности управ-
    ления окнами в современных графических оболочках // Седьмая кон-
    ференция Свободное программное обеспечение высшей школе : Тези-
    сы докладов / Переславль, 28–29 января 2012 года. М.: Альт Линукс,
    2012. C. 20–23.


Иван Хахаев, Дмитрий Державин
Санкт-Петербург, ОАО    НИИ ПС , СПбФ ОАО      Концерн   Вега

     Проблема доверенного компилятора в механизме
                  сертификации ПО

                                  Аннотация
        В ходе аудита на предмет наличия недокументированных возмож-
     ностей программных средств, написанных на компилируемых языках,
     возникает необходимость проверки соответствия исходным текстам
     программы двоичного кода, полученного в результате компиляции.
     Необходимым условием проведения такой проверки сейчас является
     наличие доверенного компилятора.
        Обычный компилятор представляет собой чёрный ящик до тех пор,
     пока его код не прошёл аудит и пока он сам не был собран доверен-
     ным компилятором. В этот момент проявляется проблема курицы и
     яйца: чем собрать из проверенных исходных текстов доверенный ком-
     пилятор? Решение оказывается настолько трудоёмким, что возникает
     вопрос    будет ли результат стоить затраченных ресурсов?
   Проблема доверенного компилятора впервые была обозначена в
1974 году в закрытой публикации, а впервые публично сформулиро-
вана десять лет спустя Кеном Томпсоном в его Тьюринговской лек-
ции [1]. Тогда же была продемонстрирована техническая возможность


Дневное заседание (14.50–18.10)                                 57


распространения вирусного кода через бинарные версии компилято-
ров без необходимости модификации их исходных кодов.
   После долгих обсуждений проблему признали не имеющей реше-
ния и забыли о ней до 2005 года, когда Дэвид Уилер представил [2]
методику двойной раздельной компиляции, позволившую достоверно
распознать успешно проведённую атаку на компилятор. Сложность
реализации методики заключается в необходимости наличия доверен-
ного компилятора, способного собрать из исходных текстов компиля-
тор, подлежащий проверке. Понятие доверенный в данном случае
подразумевает гарантированное отсутствие недекларированных воз-
можностей.
   За 20 с лишним лет, прошедших с тех пор, как существование
проблемы было доказано, до того момента, как было объявлено о её
решении, размножение бинарных версий компиляторов происходи-
ло беспорядочно и бесконтрольно. В результате вплоть до настоящего
времени найти доверенный компилятор, пригодный для сборки, на-
пример, gcc-4.7 практически невозможно. Таким образом, мы не мо-
жем с приемлемой степенью достоверности утверждать ни о наличии
в программном обеспечении недекларированных возможностей, ни и
об их отсутствии.
   Этот важный вывод говорит о вероятном существовании фунда-
ментальной уязвимости в современной системе сертификации про-
граммного обеспечения.
   Фактически речь идёт о том, что в течение более чем 20 лет суще-
ствует возможность тайно и беспрепятственно вносить вирусный код в
программное обеспечение, применяемое в том числе в оборонной про-
мышленности. И единственный известный на сегодняшний день спо-
соб противодействия атаке предполагает наличие доверенного ком-
пилятора, обладание которым в такой ситуации является ключевым
моментом в области информационной безопасности.
   Способ получения доверенного компилятора зависит от желаемой
степени доверия. Учитывая масштабы проблемы, вариант с мини-
мальной трудоёмкостью представляет собой получение эволюционно
чистой линии, берущей начало от простейшего компилятора, написан-
ного на языке, максимально приближенном к аппаратному уровню
ЭВМ.
   Учитывая возможность реализации атак, задействующих аппарат-
ную часть компьютера, ещё большую степень доверия можно полу-


58                                                           21 сентября


чить, используя к тому же аппаратную часть, разработанную по прин-
ципам Open Hardware.
   Конечно, для достижения высоких степеней доверия потребуется
координация усилий большого коллектива разработчиков. Результа-
том работы может стать стенд для сборки доверенного компилятора
и проверки программного обеспечения методом двойной раздельной
компиляции. Если такая работа будет проведена и опубликована, её
результат сможет существенно повысить уровень доверия к свобод-
ному программному обеспечению, а так же стать ещё одним важным
шагом к достижению независимости в области информационных тех-
нологий.

Литература
[1] Thompson, Ken, Reflections on Trusting Trust, https://www.ece.cmu.edu/
    ~ganger/712.fall02/papers/p761-thompson.pdf
[2] Wheeler, David A., Countering Trusting Trust through Diverse
    Double-Compiling (DDC), http://www.dwheeler.com/trusting-trust/
    wheelerd-trust.pdf


Михаил Шигорин
Киев, ALT Linux

     mkimage-profiles как инструмент укрощения ARM


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

Краткая предыстория
   Изначально mkimage-profiles, или m-p, задумывались как исследо-
вательский проект с целью уменьшения степени внутреннего дубли-
рования в mkimage-profiles-desktop и схожих профилях, применяемых


Дневное заседание (14.50–18.10)                                 59


совместно с пакетной базой ALT Linux для создания решений на её
базе.
   По мере прояснения предположений и проработки реализации про-
ект стал применяться для сборки публикуемых экспериментальных
образов, а затем и официально выпускаемых ALT Linux заготовок
для опытных пользователей (starterkits, сборки для ARM).
   С тем, что такое форки и мержи, можно ознакомиться по моей
отдельной тематической презентации Скрестим вилки , представ-
ленной в Обнинске на конференции 2011 года; обзор mkimage-profiles
доступен в ещё одном материале (2012).

Вводные
   Сколь-нибудь единой ARM-платформы сегодня не существует:
широчайшее применение процессоров данной архитектуры и отсут-
ствие эталона вроде того самого IBM PC обусловило тесную адап-
тацию железа и ПО к конкретной задаче, решаемой конкретным
поставщиком конечного устройства, а отсутствие возможности заме-
нять ПО (полностью либо частями) привело к культуре прошивок,
нередко одноразовых.
   При этом даже появление претендующих на субплатформы вари-
антов оставляет весьма широкую вариативность по части периферии
и организации загрузки.
   Всё это приводит к тому, что создание образов для конкретных
устройств приводит к взрывному росту количества случаев, которые
имеют много общего, но и достаточно различий, чтобы без чёткого
разделения общего и специфичного утонуть в дублях оказалось до-
статочно просто.
   И вот здесь задумка m-p, которая как раз и включает такое разде-
ление с возможностью наследования общего и описания специфики,
оказалась достаточно эффективной.

Что получилось
   На сегодня m-p позволяет собирать образы корневой файловой
системы и чруты, предназначенные для развёртывания на соотвест-
вующих ARM-устройствах.
   В общем усилия сосредоточены на поддержке ARMv7 (репозито-
рий Sisyphus/armh), а в частности практический результат достиг-


60                                                     21 сентября


нут на платформах Marvell ArmadaXP, Marvell Dove, NVIDIA Tegra3.
При этом добавление поддержки платформ не создаёт особых про-
блем благодаря гибкости и модульности получившегося инструмента.
    Публикуются сборки для Nexus 7 (архив ФС) и Cubox (образ ФС),
причём в нескольких вариантах с различными DE для каждой плат-
формы.
    При этом возможность быстро взять существующую конфигура-
цию и легко дополнить/изменить её сообразно своим нуждам являет-
ся одной из основных особенностей m-p, заложенной изначально. Так,
сборка с MATE для Cubox потребовала написания всего трёх строчек
конфигурации.

Ссылки

     1. http://altlinux.org/arm
     2. http://altlinux.org/m-p
     3. http://altlinux.org/cubox
     4. http://altlinux.org/nexus7


Глеб Фотенгауэр-Малиновский, Михаил Шигорин
Москва, ALT Linux


                     Крутим ARM в руках


ARM для конечного пользователя

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



    
Яндекс цитирования Яндекс.Метрика