«Пятая конференция разработчиков свободных программ на Протве Обнинск, 21–23 июля 2008 года Тезисы докладов Москва, Институт Логики, 2008 В книге собраны тезисы докладов, одобренных Программным комитетом Пятой ...»

АНО Институт логики, когнитологии и развития личности

ALT Linux

Пятая конференция

разработчиков свободных программ

на Протве

Обнинск, 21–23 июля 2008 года

Тезисы докладов

Москва,

Институт Логики,

2008

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

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

c Коллектив авторов, 2008 Программа конференции 21 июля 10.00–12.00: Регистрация 12.00–12.30: Кофе Доклады спонсоров 12.30–14. Дмитрий Ткачёв Программа exCellenT-Platforms разработка программного обеспечения для архитектуры процессора Cell................................. Павел Мельников Практическая демонстрация системы тестирования Inquisitor на серверном оборудовании ETegro Technologies.................................... 14.00–14.45: Обед Дневное заседание 14.45–16. Вартан Хачатуров Опыт портирования репозитория Sisyphus на архитектуру PowerTM : проблемы и решения.................... Михаил Гусаров, Евгений Хоружий OpenInkpot: освобождая электронные книги............. Денис Овсиенко RackTables свободное решение для управления датацентром.................................... 16.45–17.15: Кофе Программа конференции Вечернее заседание 17.15–19. Михаил Пожидаев Возможные варианты правил конфигурирования речевого вывода в среде ALT Linux........................ Михаил Якшин Inquisitor cвободная платформа тестирования и мониторинга аппаратного обеспечения.............. Александр Боковой Новая Samba....................................... 22 июля Утреннее заседание 09.30–11. Вячеслав Пупышев Использование FreePascal при обучении школьников основам программирования....................... Алексей Дьяченко, Евгений Цыганцов, Виктор Мяэотс Среда дистанционного обучения Moodle................ Евгений Цыганцов, Алексей Дьяченко, Виктор Мяэотс Модуль Электронный деканат для СДО Moodle....... Владимир Рубанов, Константин Власов, Андрей Смачев Анализ совместимости Linux-приложений с различными дистрибутивами................................. Денис Силаков, Владимир Рубанов LSB Navigator онлайн-справочник для разработчиков Linux-приложений............................... 11.30–12.00: Кофе Дневное заседание 12.00–14. Михаил Шигорин ALT Linux Terminal Server Project..................... Программа конференции Андрей Михеев, Алексей Русаков Workow Server и Workow Desktop совместные дистрибутивы Альт Линукс и Консалтинговой группы Руна на базе дистрибутивов ALT Linux 4.0 Server и Алексей Турбин Ринат Биков 14.00–14.45: Обед Станислав Иевлев Владислав Завьялов Евгений Синельников, Дмитрий Масленников Проблемы построения интегрированной сетевой Дмитрий Масленников, Евгений Синельников Tartarus. Интегрированная среда для построения сетевых 16.45–17.15: Кофе Егор Гребнев Государственные НИОКР в области ПО с открытым кодом Вартан Хачатуров Свободное и открытое ПО: экономический взгляд на Анатолий Якушин Кого накормит волшебный котёл? Экономические аспекты 23 июля Евгений Чичкарёв Моделирование физических полей: особенности Дмитрий Сподарец Разработка аппаратно-программного комплекса TERM- по измерению температур быстропротекающих процессов на основе открытого программного Михаил Быков Приложение Склад интернет-провайдера на Ruby-on-Rails Андрей Черепанов Проблемы разработки свободного учётного программного 11.30–12.00: Кофе Максим Тюрин, Александр Фейлик eКлючи от системы, или использование смарт-карт в Алексей Куклин Резервное копирование в реальной жизни: анализ задачи, организационные и технические аспекты, Роман Савоченко Вадим Лебедев Вне программы Zbigniew Braniecki Фёдор Зуев Новации в российском законодательстве и свободный софт Дмитрий Ткачёв Москва, Т-Платформы Программа exCellenT-Platforms разработка программного обеспечения для архитектуры Компания Т-Платформы ведущий российский разработчик и производитель комплексных решений для высокопроизводительных вычислений. Т-Платформы единственная российская компания, пять собственных кластерных решения которой вошли в рейтинг самых мощных суперкомпьютеров мира Тор500. С декабря 2007 года компания Т-Платформы начала реализацию программы exCellenTPlatforms, основная цель которой разработка и внедрение комплексных решений на базе инновационных процессоров Cell, а также активное объединение сообществ разработчиков, что позволит значительно ускорить реализацию внутренних возможностей Cell в отечественных программных разработках.

Основная цель проекта exCellenT-Platforms разработка и внедрение линейки комплексных решений на базе инновационных восьмиядерных процессоров CELL, а также активное объединение и развитие сообществ разработчиков, что позволит значительно ускорить реализацию внутренних возможностей Cell в отечественных программных разработках. Наличие столь мощных вычислительных решений параллельной обработки данных позволит российской наук

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

Процессор CELL был разработан альянсом Sony Group, Toshiba и IBM в центре STI Cell Design Center в Остине, штат Техас. Его архитектура предусматривает использование управляющего процессора на базе архитектуры Power, совместно с которым работают несколько высокопроизводительных процессорных элементов Synergistic Processor Element (SPE) с архитектурой SIMD, и широкого набора команд DMA для эффективного обмена между процессорными элементами.

Компания Т-Платформы и Фонд содействия малых форм предприятий в научно-технической сфере объявляют конкурс среди молодых программистов на лучшие проекты по разработке и адаптации программного обеспечения для решений на базе восьмиядерных процессоров Cell.Конкурс с призовым фондом в1 000 000 рублей проходит в рамках программы exCellenT-Platforms и программы Участник молодежного научно-инновационного конкурса (УМНИК) Фонда содействия малых форм предприятий в научно-технической сфере.

В рамках программы УМНИК Фонд содействия поддерживает научно-техническую инновационную деятельность молодежи и выделяет гранты на реализацию проектов НИОКР молодыми специалистами.

Павел Мельников Москва, ETegro Technologies Практическая демонстрация системы тестирования Inquisitor на серверном оборудовании ETegro О компании ETegro Technologies ETegro Technologies является ведущим разработчиком высокопроизводительных серверов, систем хранения данных, графических станций и индустриальных компьютеров для любых применений, от webсервера начального уровня до центров обработки данных крупных компаний.

Инновационные продукты ETegro Technologies созданы для работы в современной ИТ-инфраструктуре, при этом предоставляя запас мощности и наращиваемости для задач завтрашнего дня. Сбалансированная архитектура, высокоскоростные объединительные среды, гибко конфигурируемые опции адаптеров ввода-вывода, подсистем хранения, высокая производительность, высочайшая надёжность всё это делает продукты ETegro отличным выбором. Постоянные инвестиции в исследование новых технологий позволяют ETegro Technologies быть реальным лидером ИТ-рынка. Среди наших клиентов такие общепризнанные лидеры своих отраслей, как АК Алроса, ОАО НК Роснефть, ОАО РЖД, АКБ Региональный Кредит, медиа-холдинг РБК, ОАО Вебальта, Rambler, Masterhost и многие другие.

Неизменно высокое качество продукции и профессионализм команды ETegro позволили компании за три года своего существования добиться значительных успехов и занять общее пятое место на серверном рынке России и стран СНГ с совокупной долей около 7 % (по данным IT Research, 4 кв. 2007 г.).

Вартан Хачатуров Санкт-Петербург, ALT Linux Опыт портирования репозитария Sisyphus на архитектуру PowerTM : проблемы и решения Доклад посвящён описанию методики портирования репозитория Sisyphus на новую архитектуру на примере платформы PowerTM.

Основные части доклада следующие:

Bootstrap Этот раздел посвящён описанию самой нетривиальной части процедуры переноса: созданию первой сборочной среды.

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

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

Демонстрация Демонстрация работы дистрибутива, основанного на Sisyphus, на процессоре Cell Broadband Engine.

Михаил Гусаров, Евгений Хоружий Новосибирск, Минск OpenInkpot: освобождая электронные книги OpenInkpot проект разработки свободного дистрибутива для устройств для чтения книг на базе электронных чернил. В докладе рассказывается о предпосылках к созданию проекта, о достигнутых результатах и об устройстве дистрибутива.

В 2007 году на массовом рынке появились специализированные устройства для чтения с экранами на основе электронной бумаги (e-ink).

Электронная бумага тип экрана, принципиально отличающийся от LCD/OLED-экранов, массово применяющихся в небольших устройствах. Отличия состоят в следующем:

• Небольшое количество оттенков серого цвета (конфигурация, давно не интересная разработчикам графических библиотек);

• Очень большое время обновления экрана (порядка 0,5 секунды);

• Мультистабильность экрана (возможность удержания изображения в выключенном состоянии).

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

Оборудование и ядро Linux Основная разработка ведётся для HanLin/lBook eReader V3.

Устройство имеет микропроцессор S3C2410 (SoC, система-на-кристалле) на ядре ARM. К нему подключаются контроллер экрана, память, слот SD/MMC, USB-разъём, контроллер батареи, MP3-декодер, светодиод и кнопки.

Такой же процессор используется в проекте OpenMoko, поэтому часть драйверов (в частности, SD/MMC) были взяты из него. Написаны драйвера клавиатуры, контроллера дисплея, контроллера зарядки батареи.

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

В драйвере контроллера дисплея используется механизм отложенного ввода-вывода (deered IO), что позволяет объединять несколько последовательных изменений изображения за короткий промежуток времени в одну транзакцию. Данный механизм появился в ядре Linux 2.6.22.

Ядро поддерживает корректное засыпание-просыпание процессора, однако это занимает некоторое время и пока не удалось избавиться от проблем с работой драйвера e-ink контроллера после просыпания.

Дистрибутив Разработка основана на embedded-дистрибутиве SLIND1. Изначально работа велась на базе OpenEmbedded2, но неудовлетворённость системой сборки долгие циклы полной пересборки и плохой контроль за сборочной средой заставили взять другой, хоть и менее известный дистрибутив.

Технологическая база полностью унаследована от SLIND: используется Debian Etch в качестве базовой сборочной среды и кросс-компиляция с применением некоторых трюков для выполнения bootstrap на хост-системе. Исходный код пакетов хранится в git, а собранные пакеты в APT-репозиториях.

Целевая система представляет собой deb-based дистрибутив, усечённый для embedded-целей, но сохраняющий высокую степень совместимости с Debian по формату source- и binary-пакетов и по инструментарию разработки.

На текущий момент работает kdrive (X server для встраиваемых устройств), читалка книг FBReader. Идёт работа по портированию библиотек EFL на libxcb.

В рамках Google Summer of Code идёт работа над портированием OpenInkpot на устройства Sony PRS-505 и Bookeen Cybook Gen3.

1 http://slind.org/ 2 http://openembedded.org/ Денис Овсиенко Москва, независимый разработчик RackTables свободное решение для управления RackTables свободное ПО, являющееся средством координации деятельности в центрах обработки данных (датацентрах) малого и среднего размера. Проект представляет собой типичный образец современного web-приложения и состоит из PHP-интерфейса к базе данных MySQL. Доклад описывает как принципы решения, так и вопросы, чаще всего возникающие в результате его внедрения.

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

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

Общий подход Фокус возможностей RackTables выполнен на автоматизацию деятельности так называемых application service providers и (в меньшей степени) colocation providers. Оба вида деятельности предполагают концентрацию технических мощностей в специально сконструированных центрах обработки данных. В практике функционирования датацентров возможно выделить устоявшиеся операции, выполняемые относительно независимо друг от друга:

постановка на инвентарный учёт;

управление адресной ёмкостью (3-й уровень модели OSI);

управление портовой ёмкостью;

генерация серверов по шаблонам;

выделение монтажного места, монтаж и перемещение оборудования;

• установка и изменение кроссировок (1-й уровень модели OSI).

В зависимости от организации работ эти операции могут выполняться как одним человеком, так и независимыми группами людей. Эти действия полностью покрыты набором базовых функций RackTables, для чего в рабочем пространстве представлены: монтажная база в виде стоек, собственно оборудование, ёмкостной ресурс в виде IP-сетей и среда передачи данных в виде данных о кроссировках. Каждое действие выполняется относительно некоторого объекта, являющегося единицей учёта. Все объекты типизированы и, кроме минимального набора основных атрибутов, обладают зависимым от типа переменным набором дополнительных.

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

Кроме базовых функций, RackTables предлагает специально разработанную тэговую классификацию, которая основывается на формируемом пользователем дереве тэгов. Это дерево является единым для всех фигурирующих в RackTables сущностей: пользователей, серверных стоек, объектов, IP-сетей и других элементов. Эффективность классификации, в первую очередь, определяется структурой дерева, причём отдельно взятая сущность может иметь назначенным любое количество тэгов, входящих в произвольное число иерархий. Например, функциональная роль сервера и его принадлежность могут быть никак не связаны между собой. С помощью тэгов можно быстро составить представление о какой-либо незнакомой сущности и отыскать другие такие же.

Опыт внедрения При использовании RackTables в рабочей практике начинают действовать различные факторы.

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

2. Дружественное инженеру окружение. Чтение подготовленной структурированной информации всегда быстрее, чем проведение экспресс-расследования, особенно при отсутствии необходимого (физического или удалённого) доступа. Это позволяет новичкам быстрее осваивать уже имеющиеся конструкции, а опытным сотрудникам недавно появившиеся.

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

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

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

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

Последнее время в процессе разработки речевых систем наблюдается рост активности. Появилось движение в сторону консолидации механизмов передачи речевой информации. Текущее направление разработки речевых систем позволяет говорить, что в GNU/Linux в будущем будет возможна работа без зрительного контроля в графической оконной среде, в то время как раньше речь шла только о консольных приложениях и о emacspeak. Такие крупные проекты, как OpenOce.org, FireFox, Java Swing, GTK+, QT, заявили о реализации механизмов передачи оповещений об изменении в пользовательском интерфейсе для вывода их в речевом виде. Ведётся также разработка AT-SPI центрального компонента для сбора такой информации, являющейся частью проекта Gnome.

Возникает серьёзный вопрос о реализации в дистрибутивах ALT Linux инструментария для централизованного конфигурирования речевых систем. Сложность в том, что важно сохранить работу инструментов, используемых в настоящий момент. К примеру, emacspeak остаётся самой развитой средой и имеет множество достоинств. Наиболее вероятным развитием событий будет существование отдельных механизмов обработки речевой информации для KDE, для Gnome и для консольных приложений. Трудно сказать, удастся ли создать компонент для Альтератора, в котором у пользователя будет возможность менять настройки одновременно для всех систем. Вероятно, что это может оказаться неудобным, и тогда лучше предоставить настройку вывода в KDE и Gnome средствам, поставляемым вместе с этими системами, а через Альтератор выполнять настройку только консольных приложений.

Главный параметр, который пользователь должен уметь свободно менять, речевой синтезатор, используемый для обработки английВечернее заседание (17.15–19.15) ской и русской речи. Желательно выработать соглашения, которые позволяли бы качественно поддерживать список установленных синтезаторов. Это дало бы возможность пользователю видеть каждый новый синтезатор в списке поддерживаемых сразу после его установки. В качестве такого соглашения предлагается ввести специальную директорию, например /etc/tts.d, для добавления файлов, поставляемых в пакете синтезатора и содержащих необходимую информацию для конфигурирования. Содержимое такой директории возможно обрабатывать специальным модулем Альтератора. Формат подобных файлов и множество содержащейся в них информации ещё предстоит выработать.

В настоящий момент, благодаря наличию в QT механизма генерации оповещений об изменении состояния пользовательского интерфейса, появляется интересная возможность. Разработчики QT предусмотрели наличие уровня абстракции, необходимого для перенаправления подобных оповещений не в AT” SPI, а в любой другой компонент, в том числе и созданный сторонним разработчиком. Как известно, на QT реализован оконный интерфейс платформы Альтератор. Можно попытаться реализовать специальный мост, пересылающий оповещения в некоторый лёгкий обработчик, связанный с речевыми синтезаторами и способный работать в среде программы установки. В случае успеха возможно получить операционную систему с полностью озвученной процедурой установки, что является очень важным жизненным требованием.

Михаил Якшин Москва, ALT Linux Team Inquisitor cвободная платформа тестирования и мониторинга аппаратного обеспечения В 2005 году, на Второй конференции разработчиков свободных программ на Протве, была впервые представлена система Inquisitor[1] в своей первой инкарнации специализированной системы для автоиюля матизированного тестирования аппаратного обеспечения компьютеров.

Разработка системы была начата в 2004 году ALT Linux по заказу компании MaxSelect. Первоначально ставилась достаточно скромная задача: нужно было просто подобрать набор тестов для нагрузочного тестирования ноутбуков и сделать некий механизм их автоматического запуска.

Время шло, проект развивался, и в августе 2007 года были заявлены цели, которые должны были быть достигнуты разработкой новой, третьей версии Inquisitor:

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

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

• Масштабируемость платформа Inquisitor может работать с любыми типами компьютеров и способна протестировать как один локальный компьютер, так и многие тысячи компьютеров на производстве. Для этого существуют несколько вариантов Standalone вариант, устанавливаемый из пакета в уже инсталлированную ОС Linux, можно использовать для демонстрации, бенчмаркинга и знакомства с устройством платформы.

Live вариант, распространяемый на загрузочном Live CD или DVD, для домашнего использования удобен для того, чтобы загрузиться и протестировать один компьютер.

Серверный наиболее сложный вариант, когда есть отдельный сервер, контролирующий тестирование, с которого загружаются по сети (PXE) тестируемые машины-клиенты.

• Гибкость: система позволяет изменять большинство параметров работы модулей без изменения непосредственно исходных кодов.

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

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

Существует несколько основных классов модулей:

1. Модули анализа оборудования ( detect ) предоставляют информацию о конфигурации компьютера: производители, модели, серийные номера обнаруженного оборудования.

2. Модули тестирования оборудования ( test ) представляют собой этапы тестирования аппаратных компонентов. Тесты могут выдавать достаточно разнообразный поток информации: от ответов вида прошёл не прошёл до развёрнутой диагностики с количественными характеристиками.

3. Модули мониторинга ( monitor ) периодически записывают определённые показатели для дальнейшего построения графиков и анализа. Результаты мониторинга могут служить поводом для принятия решения о непрохождении теста.

4. Модули самоидентификации ( self-id ) позволяют привязаться к какому-то уникальному идентификатору компьютера для сохранения данных о тестировании между перезагрузками.

5. Модули загрузки ( boot ) позволяют автоматически загружать компьютер с различных носителей (PXE, ISO CD/DVD, 6. Модули сборки ( build ) позволяют собирать Inquisitor с использованием разных репозиториев (rpm/dpkg).

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

Недавно состоялся выпуск финальной версии платформы Inquisitor 3.0, что даёт возможность open source community подключаться к развитию проекта в ширину путём добавления дополнительных тестов, детектов, мониторингов и других модулей. Далее ветка 3.x будет развиваться как стабильная, с добавлением возможностей, не требующих архитектурных изменений.

Литература [1] Якшин М. Система автоматизированного тестирования и контроля качества оборудования Inquisitor // Вторая международная конференции разработчиков свободных программ на Протве.

М.: 2005.

Александр Боковой Москва, Samba Team http://www.samba.org, http://ctdb.samba.org, С 1992 года, когда Andrew Tridgell написал свою реализацию протокола SMB для Unix-подобных систем, чтобы получить доступ из клиента PathWorks в MS DOS к данным на сервере Sun, прошло уже более 15 лет. В 1996 году Microsoft потребовалась прорывная технология, чтобы стать Internet-компанией, и такой технологией стал стек протоколов SMB, переименованный в CIFS, Common Internet File System. Расширенный и дополненный, десять лет спустя CIFS уже неотделим в сознании потребителей от Microsoft. Проект Samba традиционно рассматривался как попытка догнать Microsoft, но неожиданно в 2007 на неприметных устройствах хранения фотографий, музыки и видео их разработчики из азиатских стран пишут совместимо с протоколом Samba, а не CIFS. Тихая революция?

2007 год вообще был богат на события. Команда разработчиков проекта Samba попадает на первые страницы главных деловых газет, таких как Financial Times, за победу над Microsoft в рамках антимонопольного процесса в Европейском Союзе. Затем Microsoft публикует более 40,000 страниц документации под лицензией, дающей возможность использовать её при разработке Samba, а также впервые с 1998 года принимает участие в конференциях, посвящённых разработке Samba. В 2008 году эта документация становится доступной всем желающим. Из самой закрытой компании ИТ-мира Microsoft становится самой открытой?

Но это только вершина айсберга. В 2007 году проект выпускает версию Samba, рассчитанную на высокопроизводительные системы хранения. Кластерная Samba в составе Scale-out File Services компании IBM позволяет горизонтальное масштабирование систем хранения с доступом на основе CIFS и демонстрирует производительность минимум в четыре раза быстрее любых коммерческих аналогов, включая Microsoft, фактического законодателя мод в области CIFS.

Небольшая группа внутри Samba Team за пять лет сформировала основу для замены Microsoft Active Directory. Samba 4.0, ещё не выпущенная и вряд ли готовая увидеть свет до конца 2008 года, тем не менее уже стала площадкой для атаки на другие бастионы технологий Microsoft Microsoft Exchange. В проекте OpenChange уже реализована практически вся функциональность клиентской части Microsoft Exchange, что позволяет, например, GNOME Evolution работать в сетях Exchange наравне с клиентами от Microsoft, а MocaBox наступать на позиции Microsoft Unied Communications.

В то же время пользователи заблудились в трёх соснах. Samba 3.0, 3.2 и 4.0 развиваются одновременно и с разным функционалом, выглядят вкусными стогами сена, дразнят и манят уже не первый год.

Однако до сих пор проект не говорит пользователям, для чего планируется каждая версия и каков режим её выпуска. В докладе автор попытается объяснить позиционирование, новую модель разработки и выпуска разных версий Samba, их новинки и возможности. Также отдельное внимание будет уделено взаимодействию с разработчиками и компаниями, включая создателей Windows Vista и протокола SMB2.

Вячеслав Пупышев Ижевск, Удмуртский государственный университет Использование FreePascal при обучении школьников основам программирования Рассмотрим ситуацию, когда методика обучения школьников основам программирования разработана, и осталось только решить, в какой среде программирования это делать. Для этого нужно определиться с основными критериями. Обычно важнейшими критериями являются следующие:

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

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

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

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

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

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

Разработанная мною методика развития алгоритмического мышления рассчитана на школьников старше четвёртого класса. Курс по данной методике изучается один год. Основной частью курса является активное изучение языка программирования Pascal и написание работающих программ на нём. Тут и возникли все описанные выше критерии. Оказалось, что при должной настройке можно добиться от FreePascal удовлетворения всех этих критериев. Здесь словом FreePacal буду обозначать и компилятор и интегрированную среду разработки. Если просмотреть критерии, то получится следующее:

• Возможность следовать методике без забегания вперёд. Это позволяет сам язык Pascal.

• Бесплатность системы программирования. FreePascal поэтому и • Простота установки. После настройки всю систему FreePascal можно просто скопировать на другой компьютер. Если скопировать в такой же каталог, то работать будет сразу.

• Возможность полной русификации. Русифицировать диагностику ошибок можно, указав в настройках соответствующий файл. А русификация системы помощи требует дополнительных ухищрений, но возможна.

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

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

FreePascal мощная система, поддерживающая даже диалекты Конечно есть и претензии к FreePascal. Отладчик сыроват, система помощи уступает даже TurboPascal, диагностика ошибок тоже уступает TurboPascal. Трудности в русификацией под Unix.

Lazarus Более современно выглядит интегрированная оболочка Lazarus.

Исследование, подобное оболочке FreePascal, есть и для неё. Важным преимуществом Lazarus является современный оконный интерфейс.

Поскольку дети уже привыкли к внешнему виду, продиктованному операционной системой Windows.

Алексей Дьяченко, Евгений Цыганцов, Виктор Мяэотс Москва, ГОУ Центр Образования Технологии обучения Среда дистанционного обучения Moodle Moodle является одной из самых популярных сред дистанционного обучения в мире. Количество зарегистрированных инсталляций приближается к 50 тысячам. Система используется в десятках тысяч учебных заведений в 199 странах мира и переведена на 75 языков.

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

Среда дистанционного обучения Moodle это один из флагманов в данной отрасли, разрабатываемый по принципам Open Source под лицензией GNU GPL. Moodle реализует богатый функционал, сравнимый с ведущими коммерческими системами, а в чём-то даже их опережающий. Это возможно благодаря широкому сообществу пользователей и разработчиков со всего мира, поддерживающему данный продукт. Многие разработчики Moodle сами являются преподавателями или преподавали в прошлом, благодаря чему данный продукт отличают удобство и простота использования, сочетающиеся с широким спектром поддерживаемых методических приёмов и форм учебного взаимодействия.

Moodle начал своё развитие в качестве Open Source проекта в ноябре 2001 года, а первый релиз версии 1.0 вышел 20 августа 2002 года. Инициатором и ведущим разработчиком проекта является Martin Dougiamas из Австралии. Практически с самого начала Moodle вызвал широкий интерес среди учебных заведений во всем мире, в том числе и в России, где он с 2003 года используется в проекте Департамента Образования города Москвы по дистанционному обучению детей-инвалидов (i-Школа).

К настоящему моменту Moodle насчитывает почти 50 тысяч зарегистрированных инсталляций по всему миру, в которых создано больше 2 миллионов курсов и обучается больше 20 миллионов пользователей. Интерфейс Moodle локализован на 75 языков, а сообщество пользователей, зарегистрировавшихся на сайте проекта, превышает 400 тысяч пользователей из 193 стран мира. Moodle применяется как частными репетиторами, так и огромными университетами, обучающими по 200 тысяч студентов. В России зарегистрировано почти инсталляций Moodle.

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

В их числе возможность создавать произвольные, в том числе и нечисловые, шкалы оценивания, выставления оценок преподавателями и сокурсниками за активность в форуме, сбора и рецензирования работ в текстовом формате, в виде произвольных файлов и в виде произвольной активности, не отражающейся в системе, глоссариев, баз данных с настраиваемым форматом, wiki, тестов Hot Potatoes (расширенный формат тестов, например, в виде кроссвордов), опросов, учебных карточек, предъявляемых последовательно, вразнобой или в зависимости от корректности решения теста в предыдущей карточке (модуль лекция ) и семинаров (ученикам предлагается сначала сдать работы, а потом разобрать работы своих коллег по заданным критериям). Вся активность пользователей в системе фиксируется и отображается в виде индивидуальных отчётов о деятельности (портфолио), в которых на одной странице можно видеть все выполненные задания, сданные работы и полученные рецензии и оценки по каждому курсу.

Благодаря этим возможностям, Moodle можно использовать как для стандартного дистанционного обучения, так и для поддержки очного обучения или проведения тестирования.

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

Управление доступом в Moodle, начиная с версии 1.7, осуществляется на основе настраиваемой системы ролей и полномочий, которые можно назначать и переопределять в различных контекстах: всей системы, категории курсов, одного курса, элемента курса.

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

Интерфейс Moodle может быть настроен путём выбора подходящей темы оформления и настройки состава блоков, отображаемых в правой и левой колонках. Шаблон интерфейса и набор блоков в каждом курсе могут быть индивидуальными.

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

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

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

Немаловажную роль в популярности Moodle играет дружественное и открытое для новых пользователей сообщество. Базовым сайтом проекта является сайт http://moodle.org, построенный на осноУтреннее заседание (09.30–11.30) ве Moodle. Помимо стандартных для сайтов Open Source проектов разделов, на сайте существуют разделы сообществ разработчиков и пользователей (в виде курсов Moodle). Главным из них является англоязычный раздел Using Moodle. Для неанглоязычных пользователей заведены разделы в категории Community Discussion, в которой есть раздел и для русскоязычных пользователей Russian Moodle.

Всё основное общение разработчиков, пользователей и локализаторов происходит в этих сообществах, что является более дружественным по отношению к новым пользователям способом общения, чем традиционные списки рассылки. Сторонние разработчики модулей, шаблонов оформления и учебных ресурсов могут опубликовать их в соответствующих разделах основного сайта. Для оповещения разработчиков об ошибках, запроса новых возможностей или отправки патчей традиционно используется Tracker; в настоящее время это JURA. Вся документация, дополняющая встроенную справку, разрабатывается и хранится в wiki на базе движка MediaWiki, поэтому участвовать в составлении и переводе документации могут все желающие.

Координацию проекта осуществляет австралийская компания Moodle PTY Ltd., основателем которой является лидер проекта Martin Dougiamas. В дополнение к поддержке сообщества, коммерческую поддержку Moodle осуществляют многочисленные партнёры Moodle во всем мире, работу которых контролирует Moodle PTY Ltd.

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

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

В дополнение к русскоязычному разделу на основном сайте проекта, существует также сообщество русскоязычных преподавателей, использующих Moodle, на сайте http://www.infoco.ru, посвящённое, в основном, методическим и организационным вопросам дистанционного образования. Ежегодно, в конце марта, в городе Железноводске (Минеральные Воды) проводится конференция русскоязычных пользователей Moodle в рамках международной конференции Информационные Технологии в Науке и Образовании. На конференцию собираются представители ВУЗов и других образовательных учреждений.

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

Евгений Цыганцов, Алексей Дьяченко, Виктор Мяэотс Москва, ГОУ Центр образования Технологии обучения http://sourceforge.net/projects/freedeansoffice/ Многие отечественные ВУЗы при внедрении информационных технологий в управление учебным процессом сталкиваются с отсутствием подходящего открытого ПО, а также высокой стоимостью имеющихся на рынке решений автоматизации для ВУЗов Первоочередной задачей Open Source проекта Электронный деканат является адаптация СДО Moodle к особенностям организации учебного процесса в отечественных учебных заведениях, а в перспективе разработка гибкой системы автоматизации бизнес-процессов в ВУЗах. Система разрабатывается как модуль СДО Moodle и сама имеет развитую модульную архитектуру, позволяющую адаптировать её под потребности каждой организации без модификации кода базовой системы.

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

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

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

Таким образом, существует насущная потребность в адаптации СДО Moodle к традициям отечественной системы образования. Данную задачу призвана решить система Электронный деканат для СДО Moodle (далее ЭД), разрабатываемая сообществом российских программистов как открытый проект под лицензией GNU GPL1.

Исходной версией для разработки послужил программный продукт, разработанный для внутренних нужд и реализующий следующие возможности:

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

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

1 Подробную информацию можно найти по адресам в интернете http:

//sourceforge.net/projects/freedeansoffice/ и http://www.infoco.ru/course/ view.php?id=19.

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

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

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

6. Просматривать все оценки ученика или группы по всем предметам.

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

8. Просматривать ведомость группы.

9. Распечатывать или сохранять в excel различные ведомости.

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

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

Поддерживаются следующие типы плагинов:

1. Плагин интерфейса обеспечивает взаимодействие с пользователем системы. Реализует интерфейс пользователя.

2. Плагин справочник. Обеспечивает работу с базой данных.

Упрощает использование стандартных операций и служит слоем для инкапсуляции SQL-запросов.

3. Плагин синхронизации обеспечивает двунаправленную синхронизацию данных ЭД и внешних систем. В том числе, через плагины данного типа происходит обмен данными с Moodle. Это позволяет снизить зависимость остального кода от API внешних систем и структур данных во внешних базах данных.

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

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

Интерфейс всех плагинов поддерживает автоматические установку и удаление, выполняемые из панели администрирования ЭД.

Перспективы развития:

1. Перенос на новую архитектуру ЭД возможностей существующей версии преобразованием её кода в плагины ЭД.

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

3. Реализация всех действий участников и организаторов учебного процесса через ЭД.

4. Автоматизация организации и управления учебным процессом.

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

6. Автоматизация документооборота.

Решить эти задачи невозможно без тесного и неформального диалога между программистами и представителями ВУЗов педагогами, администрацией, бухгалтерией, представителями учебной части и др. Большое внимание уделяется мнению будущих пользователей о том, что и как они хотят делать в ЭД, их пожеланиям к интерфейсу ЭД. Для этого на сайте http://infoco.ru открыт соответствующий раздел, в котором идёт обсуждение структуры и возможностей ЭД, модели бизнес-процессов, протекающих в учебных заведениях, и её реализация в ЭД. Там же открыто несколько wiki, в которых редактируются форматы типовых бланков отчётной документации для средней и высшей школы.

Исходный код ЭД доступен в разделе проекта на сайте http:

//sourceforge.net.Там же находятся формы для оповещения разработчиков об ошибках, отправки пожеланий или фрагментов кода.

Таким образом, модуль Электронный деканат является продуктом не только с открытым исходным кодом, но и разрабатываемым в виде открытого проекта. Связка СДО Moodle + Электронный деканат полезна организациям, которые внедрили или только собираются внедрять дистанционное обучение, прежде всего ВУЗам но не только им: модульная архитектура и открытость исходных кодов даёт возможность адаптации под нужды любых организаций. ЭД даёт возможность автоматизации управления учебным процессом и переноса привычной среды очного обучения на дистанционные курсы.

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

Владимир Рубанов, Константин Власов, Андрей Смачев Москва, ИСП РАН Анализ совместимости Linux-приложений В докладе представлены средства для анализа приложений на совместимость с различными дистрибутивами Linux на основе базы знаний и инфраструктуры, созданных в Linux Foundation. Анализ основывается на сопоставлении сведений о наличии различных версий библиотек и их функций в различных дистрибутивах с требуемыми приложением внешними библиотеками и функциями.

Linux как платформа для приложений В настоящее время в мире насчитывается более 500 публичных дистрибутивов Linux1. Каждый из таких дистрибутивов представляет собой уникальную комбинацию определённых версий/модификаций базовых компонентов, таких как ядро, библиотеки, системные утилиты, приложения и т. д. В данном докладе дистрибутивы Linux рассматриваются с точки зрения платформы для обеспечения функционирования сторонних приложений (то есть не включённых в комплект поставки самим производителем дистрибутива). С этой точки зрения главными компонентами дистрибутива являются собственно ядро операционной системы и набор разделяемых библиотек, которые предоставляют приложениям прикладные бинарные интерфейсы (ABI) в виде функций или глобальных данных.

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

Linux Foundation Database Для стандартизации, защиты и продвижения Linux крупнейшими ИТ-компаниями, среди которых стоит упомянуть IBM, Intel, 1 См. например, http://lwn.net/Distributions/.

HP, Novell, Oracle, был создан международный консорциум Linux Foundation, который в настоящее время представляет собой основную в мире площадку, объединяющую усилия и экспертизу различных организаций и лиц, заинтересованных в успешном развитии Linux.

Для централизованного анализа экосистемы Linux в рамках деятельности Linux Foundation была создана база данных, содержащая информацию о составе различных дистрибутивов (наличие определённых библиотек и интерфейсов), о внешних зависимостях реальных приложений и о стандартизованных в рамках Linux Standard Base (LSB) элементах.

В настоящее время эта база данных включает более 80 таблиц с суммарно 25 миллионами записей. Основную часть данных занимают сведения о дистрибутивах и приложениях. По состоянию на июнь 2008 года база содержит информацию о 41 дистрибутиве и о приложениях. Эти сведения используются в том числе для поддержки принятия решений по развитию стандарта LSB.

Содержимое базы данных доступно для удобного просмотра с поиском и кросс-навигацией с помощью специализированной информационной системы LSB Database Navigator2.

Linux Application Checker Для проведения собственно анализа конкретных приложений на совместимость с различными дистрибутивами предназначен инструмент Linux Application Checker, созданный в рамках проекта LSB Infrastructure3 в российском Центре верификации ОС Linux4.

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

В процессе работы пользователю предлагается задать целевое приложение в виде набора исполняемых файлов и поставляемых с приложением библиотек. Такие файлы можно задавать по отдельности или 2 http://linuxfoundation.org/navigator/ 3 http://ispras.linuxfoundation.org/ 4 http://linuxtesting.org указывать целые пакеты rpm, deb, tar.gz, из которых все найденные в ELF формате файлы будут автоматически трактоваться как относящиеся к приложению. Кроме того, в качестве целевого приложения можно указывать просто одно из установленных в системе в таком случае все компоненты приложения будут автоматически получены из менеджера пакетов.

В процессе анализа заданного таким образом приложения на основе ELF считывается информация о зависимостях каждого компонента (список библиотек берется из DT_NEEDED записей секции.dynamic, а список интерфейсов формируется на основе фильтрации списка символов из.dynsym и.symtab секций). Затем исключаются внутренние зависимости между компонентами приложения и формируется объединение внешних библиотек (идентифицируемых по soname) и конкретных интерфейсов, необходимых приложению от дистрибутива.

Полученный список сопоставляется с предоставляемыми различными дистрибутивами версиями библиотек и интерфейсов, и формируется отчёт о совместимости заданного приложения с конкретными дистрибутивами. Отчёт создаётся в виде набора связанных HTMLфайлов от общей сводки до конкретных деталей. Где возможно, выводятся сведения и рекомендации из базы знаний Linux Foundation, например рекомендации, чем заменить устаревшие (deprecated) интерфейсы, советы включить определённую библиотеку в состав поставки приложения или советы исключить неиспользуемые библиотеки (присутствующие в DT_NEEDED зависимостях, но без реально используемых интерфейсов).

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

Денис Силаков, Владимир Рубанов Москва, ИСП РАН http://ispras.linux-foundation.org/index.php/LSB_DB_Navigator LSB Navigator онлайн-справочник для разработчиков Linux-приложений В докладе представлена веб-система LSB Navigator, являющаяся составной частью новой версии Linux Development Network (LDN). Инициатива LDN позиционируется Linux Foundation как аналог MSDN для Linux. LSB Navigator позволяет разработчикам быстро находить информацию о конкретных интерфейсах программирования и библиотеках Linux, их статусе и ссылки на документацию.

Linux Development Network Linux предоставляет разработчикам приложений богатый выбор инструментария и библиотек для реализации своих идей. Более того, для воплощения одной и той же функциональности зачастую существует несколько альтернатив. В результате, программисты оказываются перед выбором какие именно библиотеки использовать? Какие функции из этих библиотек стоит использовать, а какие нет? Поиск ответа на такие вопросы осложняется тем, что каждая библиотека имеет свою собственную документацию; при этом качество описания различных библиотек сильно разнится, и для использования многих из них полезными оказываются дополнительные источники информации. В результате, при создании сложного программного продукта разработчикам приходится иметь дело со множеством разрозненных спецификаций, статей, и т. п.

В ОС Windows разработчикам предоставляется Microsoft Development Network (MSDN) целая электронная библиотека, объединяющая различные источники документации по программированию в Windows. С целью создания аналога MSDN для Linux консорциум Linux Foundation выступил с инициативой Linux Development Network (LDN), призванной собрать в одном месте спецификации, статьи, ссылки на документацию и другую информацию, которая может быть полезна при разработке приложений под Linux.

LSB Navigator Одной из составных частей LDN является веб-система LSB Navigator, предоставляющая пользователям доступ к информации, хранящейся в базе данных стандарта Linux Standard Base (LSB). Наиболее подробными являются данные об элементах (библиотеках, функциях, командах), включённых в LSB, однако пользователь может получить сведения и по большому количеству объектов, не входящих в стандарт. Например, число бинарных интерфейсов (функций и глобальных переменных) в разрабатываемой версии LSB приближается к 40 тыс., в то время как всего в базе данных содержится информация о почти трёх миллионах интерфейсов.

В соответствии с характером предоставляемых пользователю данных, LSB Navigator разделён на три основных секции LSB Elements, Distributions and Applications и Workgroup Services.

LSB Elements Данная секция позволяет получить информацию об элементах стандарта LSB, к числу которых относятся:

• библиотеки;

• классы;

• бинарные интерфейсы;

• команды;

• модули интерпретируемых языков.

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

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

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

Помимо элементов стандарта, секция LSB Elements предоставляет информацию о тесно связанных с ними сущностях. К таковым относятся:

• заголовочные файлы, которые необходимо подключать для использования тех или иных функций;

• типы, необходимые для использования функций;

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

Distributions and Applications Данная секция содержит сведения о библиотеках, классах, командах и бинарных интерфейсах, предоставляемых дистрибутивами и используемых приложениями. Для каждого такого элемента существует домашняя страница, аналогичная домашним страницам элементов LSB; однако информации на страницах элементов, которые никогда не входили в LSB, существенно меньше можно получить список дистрибутивов, предоставляющих данный элемент, и список приложений, его использующих. Для функций, объявленных устаревшими разработчиками библиотек, в которые они входят, на домашней странице приводится соответствующий комментарий с предложением альтернативной замены.

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

Workgroup Services Как следует из названия, эта секция предназначена, в основном, для членов рабочей группы LSB, однако информация, содержащаяся здесь, может быть интересна любому человеку, интересующемуся LSB. Здесь можно получить статистические данные о развитии стандарта (сколько элементов каждого вида появилось/было исключено в каждой версии), список спецификаций, на которые ссылается LSB, данные о покрытии интерфейсов сертификационными тестами.

Подраздел Applications Statistics содержит статистику использования в приложениях функций и библиотек, как входящих, так и не входящих в LSB. Страница LSB Rating of Applications этого подраздела отображает степень совместимости приложений, информация о которых загружена в базу данных LSB, со стандартом.

Заключение LSB Navigator лишь часть Linux Development Network. Объём предоставляемой LSB Navigator информации достаточно велик, однако это, в основном, ссылки на внешние источники документации и данные, собираемые автоматически с помощью соответствующих инструментов. В рамках превращения LDN в действительно полезную для разработчиков систему эта информация будет дополняться различными статьями и документацией компаний-партнёров, написанными специальными техническими писателями и просто активными членами сообщества.

Михаил Шигорин Киев, ООО Медиа Мэджик http://www.freesource.info/wiki/Dokumentacija/LTSP http://www.magic.kiev.ua/ru/solutions/servers/altsp5/ Преимущества использования терминальных технологий для целей миграции на свободное ПО и повторного использования морально устаревшего железа. Участие в проектах ALT Linux и LTSP: порознь и вместе. ALTSP как уникальный сплав лучшего из двух миров LTSP4/5.

Доистория В 1999 году уже существовало как движение свободного ПО, так и намерение разработчиков ядра Linux вплотную заняться настольными системами. Этим воспользовались в одной детройтской фирме, занимавшейся обслуживанием госпиталей; так появилась первая версия LTSP.

События развивались довольно быстро, и в 2004 был выпущен LTSP4 с очень неплохими эксплуатационными характеристиками: работа на 12M RAM, загрузка в полминуты, поддержка балансировки нагрузки и локально запускаемых на клиенте приложений (например, для интернет-телефонии с доступом к микрофону).

LTSP В 2005 году начались работы над фреймворком по составлению терминальных решений из существующих дистрибутивов, а не над специализированным мини-дистрибутивом. Эта работа выполнялась в тесном сотрудничестве с проектом Ubuntu.

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

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

В 2007 году к разработке LTSP5 присоединились участники проектов Gentoo, openSUSE, Fedora, Slackware, принося с собой кусочки специфического для их дистрибутивов кода, исправляя и улучшая общий.

ALTSP В том же 2007 году был доведён до бета-состояния и использован в деле форк LTSP5 на базе ALT Linux, сочетавший в себе как наработки по использованию дистрибутива из пятой ветки, так и зрелые компоненты из четвёртой; наш офис[1] успешно переехал на технологию ALTSP5 в конце весны.

К концу года был наработан дистрибутив, который обеспечил на стенде загрузку и нормальную работу Pentium 166/32M как одного из тонких клиентов, подключённых к более мощной машине даже при использовании KDE, OpenOce.org и Eclipse.

Почему форк?

Рассматривались разные варианты. В итоге остановились на LTSP5 в качестве основы, но были выкинуты те части LTSP 5.0, которые были сочтены незрелыми, и втянуты элементы LTSP 4.2, которые доказали свою лучшую пригодность (NFS root и использование XDMCP).

Upstream merge Результат вскоре был работоспособен, но сильно отличался от основного направления разработки LTSP5. После ряда обсуждений было решено всё-таки попробовать объединить ветки весной 2008, что позволило сократить объём различий примерно вчетверо.

Текущее состояние ALTSP5 остался таким же гибридным вариантом: используется специальная сборка ядра с патчами для надёжного свопа по сети;

потребность в памяти терминала получилось свести к сопоставимому с требуемым для LTSP4.2 объёму 16M.

Доступны снапшоты терминального решения на основе ALT Linux 4.0 Desktop и школьного дистрибутива Линукс Терминал, которые позволяют воспользоваться терминальным сервером непосредственно после установки (при возможности загрузиться по PXE).

Написана документация[2] и система управления клиентами обе скорее в минимальном объёме: документации чем меньше приходится читать тем лучше, а вот улучшение модуля Alterator один из главных участков дальнейшей работы.

Планы Существует намерение разрешить возникший конфликт поколений LTSP (в первую очередь по части требований к ресурсам) за счёт реализации поддержки множественных транспортов в стиле LTSP4/ и расширяя их для:

• загрузки терминалов (NFS/NBD);

• регистрации в системе (XDMCP/LDM/RDP/...);

• работы с приложениями (X11/X11+ssh/RDP/...);

• работы с локальными устройствами (ltspfs/RDP/...).

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

Контакты Загрузить бета-версии (и будущие релизы) можно с серверов ftp.

linux.kiev.ua и beta.altlinux.org; подписаться на рассылку, где идёт обсуждение разработки и применения по адресу https:// lists.altlinux.org/mailman/listinfo/ltsp-server.

Докладчика можно найти как [email protected] (email/jabber).

Литература [1] Терминал-сервер. 2007.

http://www.magic.kiev.ua/ru/solutions/servers/altsp5/.

[2] Chumachenko, A. Ltsp5 в altlinux. 2007.

http://freesource.info/wiki/Dokumentacija/LTSP5.

Андрей Михеев, Алексей Русаков Москва, Консалтинговая группа Руна Workow Server и Workow Desktop совместные дистрибутивы Альт Линукс и Консалтинговой группы Руна на базе дистрибутивов ALT Linux 4. Server и ALT Linux 4.0 Personal Desktop Программный продукт решает задачу автоматизации процессов административного управления. Дистрибутивы содержат клиентские и серверные компоненты workow-системы. Основная задача системы раздавать задания исполнителям и контролировать их выполнение. Система является открытой, распространяется под лицензией LGPL. Достоинствами продукта являются простота установки и эксплуатации, наличие подробной документации.

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

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

Процессный подход реализуют компьютерные системы, называемые workow-системами. Эти системы позволяют быстро разрабатывать и изменять процессы, не меняя кода системы.

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

Краткое описание системы Система состоит из:

• Собственно workow-системы;

• Графического редактора процессов;

• Клиента-оповещателя о поступивших заданиях.

Основные функции Собственно workow система:

• Работа с определениями и экземплярами процессов;

• Работа со списками заданий;

• Визуализация форм, соответствующих заданиям;

• Работа с системой через web-браузер;

• Предоставление возможности работы с системой приложениям специального вида (ботам1 );

• Авторизация и аутентификация пользователей.

Графический редактор процессов:

• Редактирование графа процесса;

• Создание и редактирование графических форм заданий;

• Создание и назначение ролей ;

• Создание переменных.

Клиент-оповещатель о поступивших заданиях:

• Оповещение о поступивших заданиях;

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

• Работа с системой через специальное приложение-клиент.

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

• Получение необходимой для выполнения задания информации;

• Передачу результатов своего труда другим работникам;

• Изучение должностных инструкций.

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

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

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

Состав дистрибутивов Дистрибутивы представляют собой два диска:

• Установочный диск для клиентской части (Клиентский дистрибутив);

• Установочный диск для сервреной части (Серверный дистрибутив).

При помощи клиентского дистрибутива можно установить следующие компоненты:

• Клиент web-ссылка на клиентский web-интерфейс;

• Клиент-оповещатель о поступивших заданиях;

• Графический редактор бизнес-процессов;

• Документация;

• Симулятор бизнес-процессов (устанавливаемый на клиенте компонент, при помощи которого можно тестировать разработанные бизнес-процессы).

После того, как компоненты установлены, с ними можно работать через меню системы Меню/Офис/Runa WFE и значки на рабочем столе (при установке RunaWFE в уже существующую ОС значки на рабочий стол не устанавливаются).

При помощи серверного дистрибутива можно установить следующие компоненты:

• Runa WFE сервер;

• Бот-станция.

При помощи дистрибутивов можно доустановить RunaWFE на уже установленную систему ALT Linux 4.0 Personal Desktop или ALT Linux 4.0 Server.

Литература и ссылки 1. OnLine demo системы доступно по адресу: http://wf.runa.ru/ 2. Ссылка на сайт проекта: http://wf.runa.ru 3. Что такое системы управления бизнес-процессами: А. Михеев, М. Орлов. Цикл статей: Перспективы workow систем.

PCWEEK

• http://www.pcweek.ru/themes/detail.php?ID= • http://www.pcweek.ru/themes/detail.php?ID= • http://www.pcweek.ru/themes/detail.php?ID= • http://www.pcweek.ru/themes/detail.php?ID= • http://wf.runa.ru/images/9/93/Article04_examples.pdf Алексей Турбин Рязань, ALT Linux Team Новая система сборки rpm-пакетов поддерживает целостность репозитория за счёт транзакционных переходов, при которых полностью вычисляются характеристики репозитория. По умолчанию разрешены только переходы, которые не ухудшают характеристик. Система ориентирована на асинхронное продвижение транзакций, а окончательная сериализация и учёт взаимного влияния между транзакциями осуществляется при помощи слияний (merge). Для этого система поддерживает внутреннюю структуру данных интроспективный метарепозиторий.

Во введении дан обзор средств совместной разработки ALT Linux Team, созданных на основе распределённой системы контроля версий Введение Сборку rpm-пакетов можно рассматривать как процесс, который реализует функцию B(S,C)->P, где S src.rpm-пакет с исходным кодом, C (chroot) сборочная среда, P собранные rpm-пакеты. Надёжная сборка rpm-пакетов, т. е. воспроизводимость процесса сборки B (build), осуществляется с помощью программы hasher [Левин 2004].

Позже была разработана программа gear [Левин 2007], которая позволяет хранить исходный код src.rpm-пакетов в системе контроля версий GIT [Торвальдс 2005]. Gear-репозиторием G мы называем gitрепозиторий с исходным кодом, из которого можно получить src.rpmпакет для сборки: G->S.

Несмотря на некоторые преимущества src.rpm-пакетов (такие, как сохранение полностью оригинального тарболла, а также сама возможность распространения исходного кода в виде, готовом для сборки), использование gear-репозиториев значительно упрощает совместную разработку пакетов. Вообще, использование системы контроля версий стимулирует переход от пассивной поддержки пакетов к более интенсивной работе с исходным кодом, даёт больше возможностей для разработки. Это преимущество можно считать решающим, поэтому было предложено использовать gear-репозитории как основной формат хранения исходного кода пакетов в ALT Linux Team. (При этом src.rpm-пакеты продолжают существовать лишь как промежуточный полуфабрикат для сборки; в дальнейшем возможен полный отказ от хранения src.rpm-пакетов.) Сервер совместной разработки gear-репозиториев ALT Linux Team мы кратко обозначаем как git.alt. Одной из подсистем git.alt является girar (архив gear-репозиториев); girar осуществляет доступ разработчиков к gear-репозиториям. Каждый разработчик имеет собственные копии gear-репозиториев, в которые он может вносить, вообще говоря, достаточно произвольные изменения (предлагая, таким образом, включить эти изменения в очередную версию пакета). Реализована система почтовых уведомлений, которая упрощает обмен изменениями. При этом фактический обмен и аккумуляция изменений осуществляется средствами распределённой системы контроля версий GIT.

Несмотря на то, что любой разработчик может внести изменения в пакет, окончательную версию пакета могут подготовить только один или несколько разработчиков, за которыми закреплён этот пакет (maintainers). Контроль осуществляется подсистемой girar ACL, и неавторизированные версии пакетов по умолчанию отвергаются (вместе с тем, сохранена возможность для т. н. NMU, non-maintainer upload).

Когда новая версия пакета окончательно подготовлена, разработчик делает в gear-репозитории метку (tag) с криптографической подписью и инициирует запрос на сборку пакета. Запрос обрабатывается сборочной системой girar-builder, которая является предметом настоящего доклада. Сборочная система взаимодействует с кеширующим сервером gear-репозиториев. Если запрос на сборку был обработан успешно, то собранные rpm-пакеты помещаются в репозиторий rpm-пакетов, а gear-репозиторий с новой меткой публикуется на кеширующем сервере. Названия gear-репозиториев на кеширующем сервере совпадают с именами src.rpm-пакетов (это требование не является обязательным для gear-репозиториев разработчиков). Таким образом, кеширующий сервер предоставляет доступ к официальным gear-репозиториям, содержимое которых соответствует фактическим сборкам пакетов.

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

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

Выделим следующие проверки, выполняемые сборочной системой:

• Неудовлетворённые зависимости (unmet dependencies). Если при помещении пакетов в репозиторий возникают новые неудовлетворенные зависимости, то по умолчанию такой переход не может быть разрешён.

• Тестовая пересборка пакетов в наибольшей степени обнаруживает взаимное влияние между пакетами. Эта проверка может быть довольно ресурсоемкой: должны быть пересобраны все пакеты, у которых в сборочной среде C оказывается хотя бы один новый пакет из транзакции. Если же хотя бы один новый пакет их транзакции входит в базовую сборочную среду, то потребуется полная тестовая пересборка всего репозитория rpm-пакетов.

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

• Идентичность noarch пакетов при сборке на всех архитектурах.

• Нарушение ACL у какого-либо пакета в задании не относится, строго говоря, к характеристикам репозитория; однако включение его в общий список нарушений транзакции упрощает NMU.

Воздействовать на задания в отложенном режиме можно, в основном, двумя способами:

• Добавление новых пакетов, которые исправляют нарушения. Например, если у библиотеки изменилось имя (soname), то в репозитории могут образоваться неудовлетворённые зависимости на старое имя библиотеки. Тогда в задание можно добавить все пакеты, которые зависят от старой библиотеки, чтобы пересобрать их с новой библиотекой.

• Разрешение нарушений. Например, администратор git.alt может разрешить нарушение ACL, если неавторизированная версия пакета (NMU) содержит исправления критических ошибок.

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

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

• Сборочные зависимости (BuildRequires) src.rpm-пакетов.

Хранение сборочных зависимостей упрощает запуск тестовой пересборки пакетов.

• Зависимости собранных пакетов. Изменение зависимостей при тестовой пересборке позволяет изучать взаимное влияние между • Логи сборки пакетов. Изменения в логах сборки пакетов позволяет анализировать свойства пакетов, которые трудно учесть формально (например, новые предупреждения при компиляции).

История изменений в метарепозитории соответствует истории продвижения транзакций. В каждый момент времени основное состояние (master) метарепозитория соответствует текущему (стабильному) состоянию репозитория rpm-пакетов. Когда открывается новая транзакция, в метарепозитории создается новый бранч (в терминах GIT), имя которого соответствует целочисленному идентификатору задаДневное заседание (12.00–14.00) ния; дальнейшие изменения в бранче метарепозитория соответствуют этапам продвижения транзакции.

Когда отложенное задание вновь активизируется, может потребоваться слияние (merge) master в бранч, которое учитывает, в частности, возможные изменения в сборочной среде C. Наконец, при транзакционном переходе осуществляется другой тип слияния: окончательное слияние бранча в master (в простейшем случае оно может быть реализовано при помощи т. н. fast forward). Оба типа слияний являются не чисто текстовыми (как в системе контроля версий), а логическими, т. е. результат слияния определяется дополнительной логикой работы сборочной системы.

Литература [Левин 2004] Дмитрий Левин, Hasher: технология безопасной сборки пакетов // Первая международная конференция разработчиков свободных программ на Протве. Тезисы докладов. М., 2004. С. 28– [Левин 2007] Дмитрий Левин, От SRPMS к GEAR // Четвёртая международная конференция разработчиков свободных программ на Протве. Тезисы докладов. М., 2007. С. 14–18.

[Торвальдс 2005] Линус Торвальдс, GIT the information manager from hell.

http://git.or.cz и др.

Ринат Биков Ижевск, УдГУ Система событийного программирования SEvents Введение Событийное программирование стиль программирования, при котором вычисления активизируются в результате некоторого собыиюля тия в системе и являются реакцией на происшедшее событие, изменяя локальные характеристики системы[1].

Событийное программирование можно разделить на программирование от событий и от приоритетов. SEvents система событийного программирования с фактором случайности, которая в некоторой степени реализует стиль программирования от приоритетов. Однако она имеет некоторые особенности.

Описание SEvents обладает следующими чертами:

• Сценарий событий описывается на специальном языке скриптов;

• Переменные в сценарии могут быть трёх типов: int, boolean, • Все переменные глобальные;

• Описания всех событий и глобальных переменных располагаются в одном файле;

• Условия выполнения событий произвольны;

• Нет циклов, условных операторов, массивов и других структур;

• Объекты сценария реализуются в виде динамических библиотек;

• Предоставляются минимальные возможности визуализации • Обработчики неотделимы от событий;

• Обработчики активных событий выполняются псевдопараллельно, согласно приоритетам1 ;

• Обработчик события состоит из последовательности операторов, имеющих приоритет события;

• Соблюдение приоритетов операторов системой является необязательным;

• Производится полное журналирование изменений системы.

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

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

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

Литература [1] Н.Н.Непейвода. Стили и методы программирования, Москва: Интернет-Университет Информационных Технологий, 2005.

Станислав Иевлев Москва, ALT Linux После нескольких лет разработки в ALT Linux была создана новая современная программа установки операционной системы. Она обладает высокой функциональностью (широкий выбор источников установки, возможность автоустановки), простым интерфейсом, модульностью и широкими возможностями по адаптации к конкретному продукту.

Инсталлятор неотъемлемая часть любого дистрибутива. Основная задача инсталлятора корректное развёртывание системы на оборудовании пользователя. От него же зависит и общее впечатление от системы в целом.

Инсталлятор ALT Linux есть результат объединения следующих продуктов: общая инфраструктура (installer), штатный конфигуратор системы (alterator) и профиль установки (installer-desktop, installerserver и т. д.).

Alterator модульная система с поддержкой трёх различных интерфейсов взаимодействия с пользователем: командная строка, традиционный GUI и http-интерфейс через web-браузер. В инсталляторе и центре управления системой используются одни и те же модули.

Благодаря этому достаточно легко отлаживать отдельные компоненты инсталлятора.

Installer состоит из трёх стадий. Первая, загрузчик, поддерживает массу способов загрузки основной части инсталлятора: диск, nfsсервер, cdrom, ftp-сервер (анонимный и с паролем), http-сервер. В первых двух случаях возможна работа как с развёрнутым дистрибутивом, так и с iso-образом непосредственно. Вторая стадия инсталлятора выполняет основную часть работы разбивку диска и установку базовой системы. Третья стадия работает уже внутри установленной системы. Благодаря такому разбиению на каждом этапе имеет место минимальный расход оперативной памяти, что позволяет устанавливаться на достаточно слабые машины.

Инсталлятор работает в стиле пошагового выполнения модулей конфигуратора. Шаги могут быть интерактивные и неинтерактивные. Последние оформлены в виде скриптов и разделены на следующие группы: initinstall.d инициализация инсталлятора, preinstall.d перенос настроек из среды инсталлятора в установленную систему (между второй и третьей стадиями инсталлятора), postinstall.d изменения в установленной системе по окончанию работы инсталлятора.

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

Профиль инсталлятора содержит описание шагов, описание порядка исполнения шагов, а также набор дополнительных скриптов.

Для наиболее распространённых случаев можно воспользоваться готовыми коллекциями скриптов из пакетов серии installer-feature. Например, installer-feature-pxeboot делает все необходимые настройки в системе, чтобы сразу после установки она могла функционировать как tftp-сервер.

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

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

Владислав Завьялов Москва, ALT Linux Платформа alterator является основой для систем инсталляции и конфигурации в дистрибутивах ALT Linux. Для конфигурации каждого компонента операционной системы создаётся специальный модуль, который предоставляет пользователю графический интерфейс для изменения тех или иных параметров системы. Аlterator обеспечивает удобную инфраструктуру для создания подобных модулей. В докладе рассказывается про современное устройство модулей alterator и особенностях их создания.

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

Каждый модуль состоит из описания пользовательского интерфейса и бакенда части, предназначенной для собственно изменений настроек системы. Бакенды могут создаваться на произвольных языках программирования. Существует инфраструктура, упрощающая создание бакендов на языках perl и shell. Разрабатывается подобная инфраструктура для создания бакендов на ruby.

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

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

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

В alterator также существуют единые системы сборки и локализации модулей, общая для html- и qt-интерфейсов система справки.

Евгений Синельников, Дмитрий Масленников Саратов, ООО Этерсофт Проблемы построения интегрированной сетевой инфраструктуры на основе GNU/Linux Доклад посвящён проблематике администрирования корпоративных IT-систем. В докладе рассмотрены возможные пути решения проблем администратора с точки зрения разработчика. Приведён обзор технологий, используемых при построении таких решений, как Microsoft Active Directory, Novell eDirectory, FreeIPA.

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