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

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

Голосов: 0

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

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.
    За основу взята система CL-XML[6]. James Anderson, её автор, проде-
лал большую работу, так что CL-XML уже обрабатывает все примеры
из спецификации XQuery.
    CL-XML переводит XQuery во внутреннее промежуточное пред-
ставление в виде абстрактного синтаксического дерева (AST). Этот фор-
мат можно использовать для высокоуровневой оптимизации запросов.
    Большая часть языковых конструкций Common Lisp реализована
с помощью макросов. Если взять CL-XML и раскрыть все макросы,
то получится программа, состоящая из примитивов. Набор полученных
конструкций является черновой версией виртуальной машины.
    Реализация диалекта минимального Lisp (или Scheme) не состав-
ляет сложности, так как является хорошо изученной задачей [7].
    Отдельный интерес представляет трансляция нашей виртуальной
машины на LLVM[8] — промежуточное представление и набор инстру-
ментов для оптимизации программ. Благодаря LLVM и высокоуровневой
оптимизации, код вычисления XQuery может быть эффективнее вруч-
ную написанного аналога.

Статус
    Проект находится в начальной стадии. Пока только готов план ра-
бот, проведены первые эксперименты и подобраны инструменты для
реализации. Промежуточные отчёты будут выкладываться на страни-
це проекта Protva XQuery[1], код будет распространяться по лицензии
LGPL.
    На конференции будут представлены черновая версия виртуальной
машины и первые результаты.
    Первой вехой проекта будет добавление поддержки XQuery в
XSLT-процессор xsltproc[9].


Список литературы
 [1] Проект Protva XQuery http://xmlhack.ru/protva/
 [2] Extensible Markup Language (XML) http://www.w3.org/XML/
 [3] XML Path Language (XPath) http://www.w3.org/TR/xpath
 [4] The Extensible Stylesheet Language Family (XSL)
     http://www.w3.org/Style/XSL/


                                 21


 [5] XML Query (XQuery) http://www.w3.org/XML/Query

 [6] CL-XML: Common Lisp support for XML http://cl-xml.org/
 [7] Scheme Compiler Technology/Implementation Techniques and
     Optimization http://library.readscheme.org/page8.html
 [8] The LLVM Compiler Infrastructure Project.
     http://llvm.cs.uiuc.edu/
 [9] The XSLT C library for Gnome http://xmlsoft.org/XSLT/




16:15–17:00
Андрей Орлов                           Москва, Инфо Индастриез Групп
Павел Узорин                                         Москва, Интеко АГ
Александр Разоренов                    Москва, Инфо Индастриез Групп
Проект: Neural.RU

  Информационно-справочная система rPAS

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

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

                                  22


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


                                23


лище и прогнозировать возможность возникновения потребности в ин-
формации определённого рода в ближайшем будущем. Результаты могут
доводиться до сведения заинтересованных пользователей или использо-
ваться самой системой для получения дополнительной информации из
внешних источников.
    Для создания такой информационно-справочной системы потре-
бовалась разработка специального объектно-ориентированного сервера
приложений rPAS. rPAS имеет клиент-северную архитектуру, в которой
сервер обеспечивает хранение и обработку документов, а клиентские
приложения предоставляют интерфейс операторам или служат коннек-
торами к другими внешним источникам или потребителям данных.
    Документы хранятся в виде объектов, каждый из которых может
предоставлять один или более интерфейсов. Интерфейс является уни-
фицированным, независимым от типа способом работы с объектом, из-
вестном клиентским приложениям. Это позволяет исключить перепро-
граммирование клиентских приложений до тех пор, пока для работы
с объектами новых типов достаточно уже существующих интерфейсов,
поэтому в rPAS возможно создание клиентских приложений с достаточ-
но сложным интерфейсом без особых опасений о совместимости с бу-
дущими версиями объектной модели. Клиент-серверное взаимодействие
может осуществляться посредством различных протоколов, основным
из которых является семейство протоколов CORBA.
    В настоящее время закончена разработка первой версии rPAS,
включающей в себя сервер, простую объектную модель, ориентиро-
ванную на хранение и редактирование документов, браузер хранимых
объектов, коннектор к почтовой службе и некоторым другим источ-
никам данных. Независимо от целей его создания, в текущем состоя-
нии rPAS может применяться как простая, объектно-ориентированная
клиент-серверная среда.
    Это позволило начать работы по реализации алгоритмов, обеспе-
чивающих использование rPAS в качестве информационно-справочной
системы. Работы находятся в различной степени завершённости и на-
правлены на решение простой тестовой задачи: создание настраивае-
мого классификатора входного потока документов, полученных, напри-
мер, просмотром новостных лент или электронной почты. Хотя работы
над основными алгоритмами находятся в начальной стадии, существу-
ющий каркас и их упрощённые версии позволили провести тестовую
эксплуатацию rPAS для разбора входного потока почты и новостей, что
показало принципиальную правильность выбора архитектуры.
    17:00–17:15: Кофе


                                24


                 Вечернее заседание
                           17:15–19:00
                 (Председатель — Алексей Смирнов)




17:15–18:00
Алексей Воинов, Георгий Курячий                       Москва, ALT Linux

 Модульный подход к управлению ОС: проект
                 Alterator

    Аннотация:
    Цель проекта Alterator — создание полностью открытого инструмен-
    та, который позволит перевести на пользовательский уровень проце-
    дуру настройки и сопровождения типовых решений на основе UNIX-
    подобной ОС и её служб. Задача проекта — упростить процедуру раз-
    работки таких решений на всех стадиях, от формирования пользо-
    вательской модели и создания интерфейса до задания команд, непо-
    средственно управляющих системой.

    Печальная реальность сегодняшнего времени — т. н. «неподготов-
ленный администратор», человек, обязанности которого приближаются
к обязанностям «настоящего» системного администратора (высококва-
лифицированного пользователя), а знания зачастую не превосходят зна-
ний «оператора ЭВМ» (как включать, как делать такие-то стандартные
действия, куда звонить, если не работает).
    Если система предназначена для решения комплекса типовых за-
дач (например, WWW-сервер + почта + межсетевой экран), под каж-
дую из них находится готовое решение, с большей или меньшей степе-
нью удовлетворяющее потребителя. Поэтому нет необходимости в том,
чтобы администратор имел квалификацию разработчика.
    Как правило, обслуживание таких систем — также комплекс типо-
вых действий оператора, не требующий, за редким исключением, ква-
лификации администратора. В этом случае удобна «шаблонная» органи-
зация интерфейса (например, в виде кнопок и меню), ориентированная


                                   25


на выбор готового решения из множества. «Конструктивная» же орга-
низация интерфейса (например, изменение файла настроек), напротив,
неудобна, так как ориентирована на самостоятельную постановку и
решение задачи.
    Обычные методы организации «шаблонного» интерфейса: Webmin,
LinuxConf, DrakX и т. п. созданы, по всей видимости, по единой схеме
замены действий администратора их наглядным представлением. След-
ствием такой схемы обычно является жёсткая привязка интерфейса к
реальным элементам управления. Каждое дополнение такого продукта
функциональностями требует повторения процесса разработки и инте-
грации их в готовую программу. Всё это приводит к очень негибкой,
целиком зависящей от коллектива разработчиков структуре.
    Цель проекта Alterator — создание полностью открытого инстру-
мента, который позволит перевести на пользовательский уровень про-
цедуру настройки и сопровождения типовых решений на основе UNIX-
подобной ОС и её служб. Задача проекта — упростить процедуру разра-
ботки таких решений на всех стадиях, от формирования пользователь-
ской модели и создания интерфейса до задания команд, непосредствен-
но управляющих системой.
    Для этого в проекте предусмотрено разделение потока управления
на уровни: горизонтальные (интерфейс—модель—реализация) и верти-
кальные (соответственно задачам). Каждый элемент такой сетки — от-
дельная программа, получающая данные со стандартного ввода и/или в
командной строке.
    Горизонтальное деление предполагает, что модели среды и языки
представления данных и заданий на всех уровнях различны и соответ-
ствуют терминологии, используемой, соответственно, дизайнером, опе-
ратором и системным программистом. Верхний уровень (модель пред-
ставления, язык LOO) заведует тем, как объекты и действия над ни-
ми отображаются в конкретном варианте GUI. Центральный уровень
(пользовательская модель, язык WOO) соответствует задаче в терми-
нах «неподготовленного пользователя». Нижний уровень (модель реа-
лизации, язык HOO) реализует конкретные действия над системой и её
объектами, которые надо произвести для решения задачи.
    Вертикальное деление предполагает, что любая WOO-команда мо-
жет обрабатываться сразу несколькими обработчиками-трансляторами
WOO в HOO (commander), каждый из которых использует только необ-
ходимую часть передаваемого WOO-объекта. Для этого они регистри-
руют типы обрабатываемых WOO-объектов и команд в интегрирующем
модуле (chooser).


                                26


     Неизбежные при этом конфликты в результирующем потоке HOO-
команд разрешаются при помощи упорядочивания по зависимостям фор-
мальной проверки на непротиворечивость. Стоит отдавать себе отчёт,
что обратное преобразование (низкоуровневого HOO в высокоуровне-
вый WOO) далеко не всегда возможно, однако каждый commander мо-
жет сделать некоторые предположения на основании результата работы
всей очереди HOO-команд и знания породившей её WOO-команды.
     Для унификации интерфейса HOO-команд используется AdmFS,
виртуальная файловая система, верхняя половина которой — стандарт-
ное файловое API, а нижняя — вызов соответствующей программы-
hook, которая и производит специфические для конкретной операци-
онной системы действия.
     Таким образом, компоненты к Alterator можно разрабатывать на
любом языке программирования. Для этого достаточно соблюдать тек-
стовые протоколы управления WOO и HOO, использовать интерфейс
командной строки, файловое API.
     Добавление очередной функциональности (новый commander) в Al-
terator не требует изучения внутренности других commander’ов, доста-
точно соблюдения протоколов WOO и HOO. Добавления дополнитель-
ных системных (hook) и интерфейсных (look) модулей может вообще не
потребоваться, и в любом случае их можно разрабатывать независимо
друг от друга.
     Наконец, разделение по уровням позволяет адаптировать Alterator
к конкретной версии операционной системы, изменяя один только уро-
вень hook (под AdmFS), а к конкретному внешнему виду — только уро-
вень look (над chooser).
     Необходимые для Alterator механизмы были частично реализованы
в пилотном проекте «ИВК Кольчуга».




                                27


13:00–13:45
Дмитрий Левин                                         Москва, ALT Linux
Проект: ALT Linux Team

hasher: технология безопасной сборки пакетов

    Аннотация:
    Рассматривается задача безопасной воспроизводимой сборки пакетов
    в большом репозитории на примере Sisyphus, изучаются требования,
    накладываемые этой задачей на архитектуру системы сборки, рас-
    сматривается архитектура hasher’а и существенные моменты её реа-
    лизации. Приводятся примеры производных решений на базе hasher’а.



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

Требования к сборочной технологии
    Технология сборки элементов дистрибутива (пакетов) должна:
   • не снижать уровень безопасности хост-системы;
   • обеспечивать собственную безопасность от атак со стороны
     пакетов;
   • обеспечивать безопасность сборки пакетов от атак со стороны
     других пакетов;
   • гарантировать надёжность (воспроизводимость) результатов
     сборки;
   • обеспечивать приемлемый уровень производительности.

                                   28


Архитектура hasher’а
    В основе архитектуры hasher’а лежит трёхпользовательская модель:
вызывающий непривилегированный пользователь (C) и два непривиле-
гированных вспомогательных псевдопользователя; первый (R) играет
роль root в порождаемой сборочной среде, второй (U) — обычного поль-
зователя, собирающего программы.
    Переключение между вызывающим и вспомогательными пользо-
вателями осуществляется с помощью специальной привилегированной
программы (вызываемой посредством sudo), написанной с применением
параноидальных мер защиты от непривилегированных пользователей.
Кроме того, с помощью этой программы удаляются процессы, запущен-
ные вспомогательными псевдопользователями и не завершившиеся в
срок, а также создаются устройства. Наконец, эта программа предо-
ставляет возможность контролировать ресурсы, выделяемые процессам
непривилегированных пользователей, для защиты от DOS-атак.
    Путь пакета через сборочную систему в общих чертах выглядит
следующим образом:
  1. Пользователь C порождает среду (aptbox) для работы с apt.
  2. Полностью удаляется сборочная среда, возможно оставшаяся от
     предыдущей сборки. Удаление происходит последовательно в
     chroot пользователем U, в chroot пользователем R и, наконец,
     пользователем С.
  3. Пользователь C создаёт каркас новой сборочной среды,
     состоящий из вспомогательных каталогов и вспомогательных
     статически слинкованных программ (ash, find и cpio). С помощью
     вспомогательной привилегированной программы создаётся
     фиксированный набор устройств, достаточный для нормального
     функционирования сборочной среды и при этом не несущий
     угрозы host-системе.
  4. Порождается базовая установочная среда, представляющая собой
     набор средств, необходимых для штатной установки пакетов в
     эту среду. Пользователь C с помощью apt определяет набор
     пакетов, необходимых для порождения базовой установочной
     среды. Пользователь R с помощью вспомогательных статически
     слинкованных программ распаковывает эти пакеты.
  5. Порождается базовая сборочная среда, представляющая собой
     набор средств, необходимых для сборки любого пакета.

                                29


     Пользователь C с помощью apt определяет набор пакетов,
     пользователь R устанавливает их.
  6. Порождается сборочная среда для данного пакета. Пользователь
     U извлекает сборочные зависимости пакета, пользователь C с
     помощью apt определяет набор пакетов для установки, и
     пользователь R устанавливает их.
  7. Пользователь U осуществляет сборку пакета.
    Такая схема призвана исключить атаки вида U→R, U→C, R→C, а
также все виды атак на root.
    Для повышения производительности, особенно важной при сборке
большого числа пакетов, применяется кэширование базовой сборочной
среды.
    С помощью средств apt реализована возможность использования
собранных ранее пакетов для сборки последующих пакетов.

beehive: распределённая сборка с помощью hasher’а.
    Благодаря свойству воспроизводимости результатов сборки hasher
можно использовать для параллельной сборки большого числа пакетов
на нескольких серверах. Таким образом удаётся достичь разумного вре-
мени сборки при средних вычислительных ресурсах. Открывается воз-
можность организовать регулярное тестирование на пересобираемость
большого репозитория пакетов, что и было сделано на примере Sisy-
phus с помощью средства параллельной сборки beehive.




                                30



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