авторефераты диссертаций БЕСПЛАТНАЯ  БИБЛИОТЕКА

АВТОРЕФЕРАТЫ КАНДИДАТСКИХ, ДОКТОРСКИХ ДИССЕРТАЦИЙ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ

Pages:   || 2 |
-- [ Страница 1 ] --

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

ALT Linux

Девятая конференция разработчиков

свободных программ

Обнинск, 23–24

июля 2012 года

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

Москва,

Альт Линукс,

2012

УДК 004.91

ББК 32.97

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

сы докладов / Обнинск, 23–24 июля 2012 года. М.: Альт Линукс, 2012.

64 с. : ил.

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

c Коллектив авторов, 2012 ISBN 978-5-905167-11-9 Программа конференции 23 июля 11.00-12.30 Регистрация участников и заселение Дневное заседание 12.30–13. 12.30 А. Е. Новодворский. Открытие. Информация оргкомитета 12.40–13.10 Д. А. Костюк Организация веб-площадки конференции с помощью lvee engine.......................................... 13.10–14.40 А.Ю. Боков Свободное программное обеспечение в облачных сервисах Microsoft........................................ 14.40–15.00 Перерыв на обед Вечернее заседание 15.00–19. 15.00–15.30 Д. Силаков, Е. Буданов RPM5 основные достижения и планы на будущее....... 15.30–16.00 М. С. Пожидаев Deepsolver инструмент управления пакетами с программным обеспечением....................... 16.00–16.30 В. А. Липатов Korinf: трудности на пути к универсальной сборочной системе......................................... Программа конференции 16.30–17.00 В. А. Шаршов ABF: система для совместной работы над свободным ПО.. 17.00–17.30 Кофе-пауза 17.30–18.00 И. Ю. Власенко Автоматизация сопровождения программных пакетов..... 18.00–18.30 В. В. Кузнецов Седьмая платформа ALT Linux........................ 18.30–19.00 Д. В. Левин strace глазами апстрима.............................. 24 июля Утреннее заседание 10.00–14. 10.00–10.30 И. В. Воронин Использование КУМИР-а для управления сенсорными сетями роботов.................................. 10.30–11.00 А. Г. Михеев Концепция межпроцессного взаимодействия в свободной системе управления бизнес-процессами и административными регламентами RunaWFE........ 11.00–11.30 Р. А. Юсупов, Л. Н. Шакиров Zarafa. Создание решений уровня Enterprise для российского бизнеса.............................. 11.30–12.00 М. В. Быков Морфологический анализатор Морфеус (латинский язык). 12.00–12.30 Кофе-пауза 12.30–13.00 М. А. Шигорин Макраме из дистрибутивов: mkimage-proles............. 13.00–13.30 Д. Е. Баранов Git Upstream Manager средство для организации разработки и взаимодействия с upstream проекта..... Программа конференции 13.30–14.00 А. В. Чеусов Mk-congure система сборки программного ПО......... 14.00–15.00 Перерыв на обед Дневное заседание 15.00–17. 17.00–17.30 И. Ю. Власенко Облачно-дружественная распределенная инфраструктура для сервисов автоматизации ALT Linux Team........ 17.30–18.00 Д. Р. Михайлов Единая команда управления пакетами.................. 18.00–18.30 Г. М. Кушнир Web-сервисы обмена данными в РУЖЭЛЬ.............. 18.30–19.00 А. П. Загацкий Writeat: доступные книги для читателей и писателей...... 23 июля Александр Боровский, Дмитрий Костюк, Павел Чеботарёв Минск Проект: lvee engine http://lvee.org, http://github.com/partizan/lvee/ Организация веб-площадки конференции с помощью lvee engine Аннотация Проект lvee engine вырос из внутренних нужд конференции Linux Vacation / Eastern Europe, и на текущий момент используется в ка честве основы веб-сайтов ещё двух международных конференций. По мимо средств работы с многоязычным контентом и переводами, lvee engine предоставляет функции создания и анонсирования мероприятий (конференций, семинаров и т. п.), регистрацию и обработку заявок на участие, онлайновую подачу и рецензирование тезисов. Проект написан на Ruby on Rails и распространяется под лицензией GPL v. 2.

История проекта Изначально lvee engine создавался как основа сайта конферен ции LVEE1 и под ее особенности: подготовку на волонтёрской основе и многоязычный контент. В первые годы конференция использовала сайт на медиа-вики, однако в 2008 г. организаторы получили разра ботчика и дизайнера, предложивших создать веб-площадку, лучше отражающую её нужды, на платформе Ruby on Rails. Первая реа лизация была весьма ограниченной и приняла сходство с текущим вариантом только в 2009 г., когда вместе с новым разработчиком по явился базовый функционал lvee engine: управление контентом на ос нове разметки textile, а также пользовательские акаунты и поэтапная регистрация, рассчитанные на проведение нескольких конференций.

По итогам LVEE 2010 стало очевидным, что разработка достаточ но универсальна, чтобы её можно было использовать в виде сети сай тов дружественных конференций на одном и том же движке с раз ными оформлением, контентом и хостингом. В 2011 г. на базе lvee engine были подняты сайты конференций FOSS Lviv2 и WebCamp3, 1 http://lvee.org 2 http://conference.linux.lviv.ua 3 http:webcamp.in.ua Дневное заседание (12.30–13.40) начат процесс доработки функционала для обмена акаунтами поль зователей между сайтами.

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



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

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

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

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

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

Роли пользователей Для пользователей предусмотрены следующие роли:

• none (без привилегий) права на создание и редактирование вики-страниц, своих анкетных данных и тезисов;

• editor (редактор) права на редактирование контента и доступ к дополнительным управляющим страницам;

23 июля • reviewer (рецензент) разновидность редактора с доступом к общему списку тезисов;

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

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

Технически процесс редактирования контента бывает двух видов:

редактирование сообщений (в виде yml-файла для каждого языка) и редактирование текстов, причём последнее делится на редактирова ние статей (страниц сайта), новостей и тезисов.

Редактирование статей построено следующим образом: на каж дой странице редакторы видят под текстом ссылку перевести либо править. В дополнение к разметке textile можно использовать html теги и формулы LaTeX (последнее реализовано для нужд подготов ки тезисов). Механизм редактирования поддерживает предваритель ный просмотр и показ полной истории изменений, а для переводчиков предусмотрен RSS-канал правок.

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

Вечернее заседание (15.00–19.00) Работа с тезисами Создать новые тезисы участник может, перейдя по ссылке в лич ном профиле (после подписки на участие в конференции). Рецензен там доступен список тезисов, поданных на текущую конференцию, а остальные участники могут видеть только собственные. За осно ву формы создания тезисов взята форма новостей с дополнитель ными полями, часть из которых генерируется автоматически: назва ние конференции, авторы, лицензия (по-умолчанию Creative Com mons Attribution-ShareAlike 3.0), комментарий к изменениям (при по вторных правках), флаг готовности к рецензированию. При редакти ровании тезисов доступен выбор пользователей для совместного ре дактирования и прикрепление файлов (например, изображений). Ни же текста тезисов, готовых к рецензированию, отображается область комментариев. В комментариях рецензенты могут сообщить автору о принятии тезисов, либо предложить их доработать, либо вести с автором более длительную дискуссию.

Алексей Боков Москва, Microsoft Проект: Windows Azure http://windowsazure.com/http://windowsazure.com Свободное программное обеспечение в облачных сервисах Microsoft Аннотация Доклад посвящен практическому опыту использования свободного программного обеспечения для облачных проектов на базе платфор мы Microsoft Windows Azure. Экосистема разработчиков свободного программного обеспечения как важный фактор развития облачных сер висов. Вклад компании Microsoft в разработку и развитие свободного программного обеспечения.

23 июля Денис Силаков, Евгений Буданов Москва, ROSA Lab.

Проект: ROSA, RPM5 http://www.rosalab.ru RPM5 основные достижения и планы на будущее Аннотация Отличительной чертой многих дистрибутивов Linux является ори гинальный подход к управлению программным обеспечением, основан ный на формировании пакетов ПО и использовании специализирован ных систем управления такими пакетами. Распространенным является мнение, что подобные системы это всего лишь архиваторы, однако в современном мире это далеко не так. Доклад посвящен RPM5 одной из активно развивающихся систем управления пакетами, являющейся ответвлением широко распространенного инструментария RPM. При водится обзор нововведений, реализованных в рамках проекта RPM5, а также улучшений, которые планируется добавить в будущем.

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

Улучшения для мантейнеров Одним из наиболее активно используемых мантейнерами нов шеств являются файловые триггеры. Механизм триггеров позволя ет избавиться от указания в post- и pre-скриптах повторения ру тинных действий, необходимых при установке или удалении мно гих пакетов например, запуска ldconfig для перегенерации кэша /etc/ld.so.cache при изменении состава библиотек или обновления кэша иконок при изменении файлов в /usr/share/icons. В RPM вместо этого предлагается использовать триггеры скрипты, запус каемые самим RPM при появлении или удалении файлов с опреде ленными именами или местоположением.

Еще одной активно прорабатываемой областью является локали зация описаний пакетов. Существующие в настоящее время подходы Вечернее заседание (15.00–19.00) (помещение переводов в spec-файл, использование отдельного паке та specspo) на практике оказались не очень удачными. Разработчики RPM5 предложили использовать для хранения описаний пакетов спе циализированное хранилище (базу данных), работа с которой будет производится непосредственно инструментарием RPM.

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

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

• Возможность использования встроенных интерпретаторов RPM5 может быть собран со встроенной поддержкой Ruby, Python, Perl, Tcl и Lua, а также с базовой поддержкой ODBC и языка запросов SQL.

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

• Улучшенная работа с сетью практически все операции, рабо тающие с локальными файлами, могут работать и с файлами по сети (по протоколам HTTP и FTP).

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

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

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

Наконец, встраивание в RPM минимальных возможностей по ра боте с системами контроля версий позволяет использовать такие си стемы для отслеживания модификаций конфигурационных файлов при обновлении пакетов. В настоящее время RPM умеет сохранять предыдущую версию файла с суффиксов.rpmsave (либо оставлять старую версию на месте, устанавливая новую с суффиксом.rpmnew).

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

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

За развитием RPM5 можно следить на сайтах http://rpm5.org/ и http://launchpad.net/rpm. Процесс разработки полностью открыт и принять в нем участие могут все желающие.

Вечернее заседание (15.00–19.00) Михаил Пожидаев Томск, ALT Linux Проект: Deepsolver http://deepsolver.org Deepsolver инструмент управления пакетами с программным обеспечением Аннотация Доклад посвящён новому инструменту управления пакетами с про граммным обеспечением, разработка которого ведётся сотрудниками компании ALT Linux. Особое внимание уделяется алгоритмам вычис ления списков пакетов для внесения изменений в состояние операци онной системы.

Deepsolver новый инструмент для управления пакетами с про граммным обеспечением (ПО). Разработка ведётся сотрудниками компании ALT Linux с целью замены менеджера APT новым продук том, удовлетворяющим современным требованиям. Основные функ ции Deepsolver:

• доставка с удалённых узлов, установка, обновление и удаление пакетов;

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

• поиск доступных пакетов в удалённых репозиториях и предо ставление информации о них;

• поддержание целостности операционной системы (ОС).

Разработка ведётся с выделением трёх основных компонент:

1. Обработка запросов пользователя на внесение изменений в ОС.

2. Поиск информации о доступных пакетах.

3. Построение индексов репозиториев.

Схема зависимостей и конфликтов между пакетами в современ ных дистрибутивах GNU/Linux может быть сведена к булевому урав нению. Это доказывает, что задача обработки запросов пользовате ля является задачей из класса NP-полных алгоритмов. Нахождение точного решения за полиномиальное время невозможно, и необходи мо использовать методы приближённого или ограниченного поиска.

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

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

Во время вычисления изменений состояния ОС в ответ на запрос пользователя обрабатываются три множества пакетов:

1. Пакеты, непосредственно указанные пользователем.

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

3. Пакеты, установка, обновление или удаление которых необходи ма для сохранения целостности ОС.

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





1. При нарушении зависимости на пакет в случае его обновления произвести обновление зависимых пакетов.

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

Вечернее заседание (15.00–19.00) 3. Полностью удалить зависимое поддерево установленных паке тов.

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

Пусть пакет p зависит от r1 и r2, а конфликтует с c1 и c2. В таком случае соответствующий фрагмент уравнения должен быть следую щим: (!p r1 ) (!p r2 ) (!p!c1 ) (!p!c2 ). В роли p выступают все па кеты, для которых необходимо принять решение, а также связанные с ними путём зависимостей или конфликтов. Для каждой альтернати вы удаления поддерева или установки замещения в уравнение должен добавляться новый элемент вида (p1 !p2 ), где p1 пакет замещения, а p2 пакет удаления.

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

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

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

23 июля Виталий Липатов Санкт-Петербург, Etersoft Проект: Korinf http://wiki.etersoft.ru/korinf Korinf: трудности на пути к универсальной сборочной системе Аннотация Доклад посвящён системе Korinf, позволяющей осуществлять сбор ку пакетов под множество операционных систем из единого исходника.

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

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

Алексей Новодворский в рассылке devel@altlinux.org, 17.02. Сборочная система нужна для сборки бинарных пакетов с про граммами из исходных кодов. Сборочная система необходима как производителям дистрибутивов, так и поставщикам (разработчикам) программ, причём они предъявляют разные требования. В дистри бутиве стоит задача собрать множество пакетов в одной сборочной среде (определённой версии дистрибутива). Поставщику проприетар ной (или свободной, но не попавшей во все дистрибутивы программы) требуется собирать свою программу под множество различных дис трибутивов, или по крайней мере сделать её работающей на разных дистрибутивах.

Варианты тут следующие:

• собирать программу статически со всеми библиотеками (или со многими, потому что со всеми нереально). Например, собрать статически с Qt, и на довольно широком круге систем это будет работать;

• носить все библиотеки с собой (так поступал раньше Oracle и Dr Web, причём с собой они носили даже glibc);

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

Вечернее заседание (15.00–19.00) • можно собирать программу под каждую конкретную систему в каждой конкретной системе.

Стоит заметить, что по последнему варианту собираются все пакеты в штатных репозиториях дистрибутива. Сборка с конкретными вер сиями библиотек и последующая работа с этими же библиотеками самый предусмотренный путь (по сути знаменитый congure && make && make install).

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

Тут тоже есть несколько решений:

• поставлять собранную программу просто в архиве (tar.gz) в виде набора файлов;

• поставлять программу в виде саморазархивирующегося архива (по сути инсталлятора);

• поставлять программу в неком отдельном формате (например, проект OpenPKG), не совместимым с пакетным менеджером си стемы ;

• создавать пакет под конкретный пакетный менеджер целевой системы.

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

• программа собирается из одного исходного кода, но по специ фикации (спеку), написанной для каждого дистрибутива (его пакетного менеджера) и для каждой версии;

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

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

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

23 июля В Korinf используется следующий подход: программа (пакет) соби рается под каждую конкретную систему в соответствующей ей сбо рочной среде (то есть в самой целевой системе). Сборка происходит с помощью rpm по спеку, полученному путём конвертирования из иде ального спека, созданного для ALT Linux Sisyphus. Полученный rpm конвертируется в формат пакетного менеджера целевой системы.

При этом решаются следующие задачи:

• получение списка бинарных и сборочных зависимостей пакета (названий пакетов в системе, от которых зависит данный пакет);

• конвертирование названий пакетов и названий групп пакетов в названия, принятые в целевой системе;

• создание списка зависимостей для целевой системы из списка бинарных зависимостей пакета для ALT Linux;

• конвертирование спека в формат, принятый в целевом rpm менеджере;

• портирование rpm-макросов, созданных для ALT Linux, на це левую систему.

Что не решено хорошо и подлежит улучшению:

• сборка для большинства систем происходит в обычном chroot, только для ALT Linux используется hasher. Нужно использо вать изолированное сборочное окружение: портировать hasher, использовать mock, pbuilder и пр., доступное для соответству ющих платформ, чтобы обеспечить повторяемость и изоляцию сборки;

• разворачивание минимальной сборочной системы. Задача похо жа на создание шаблона системы для OpenVZ. Общего решения нет, обычно это делается вручную;

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

distromatch, packagemap);

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

Вечернее заседание (15.00–19.00) • конвертирование исходного src.rpm в src.rpm для целевой систе мы происходит в хост-системе, что накладывает ограничения (например, для python-пакетов может неверно сохранится тре буемая версия python);

• веб-интерфейса для взаимодействия нет, только командная строка;

• нет полного взаимодействия с girar (сборочной системой в ALT Linux), поэтому автоматическая сборка делается скриптом, ко торый следит за изменениями в заданных репозиториях ALT Linux и пересобирает пакеты при появлении новой версии.

Описанный подход позволяет из одного исходника собирать бинар ные пакеты для систем на базе Linux, FreeBSD, Solaris. Для сборки под Windows требуется написание отдельного сценария для сборки и для инсталлятора.

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

Роман Вялов, Владимир Рубанов, Евгений Соколов, Владимир Шаршов Москва, ЗАО РОСА Проект: Automatic Build Farm(ABF) http://abf.rosalinux.ru Automatic Build Farm (ABF): система для совместной разработки свободного ПО Аннотация Доклад посвящен системе для совместной работы над свободным программным обеспечением ABF (Automatic Build Farm). Описыва ются основные идеи, положенные в ее основу при проектировании и разработке, рассматриваются наиболее важные возможности для раз личных групп пользователей. Дается обзор текущей архитектуры, опи сываются недостатки, выявленные в процессе первичной эксплуатации, рассматриваются дальнейшие направления развития.

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

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

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

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

Логичным видится объединение подобных систем сборки и серви сов разработки в единую среду, которая бы позволила разрабатывать, тестировать и собирать ПО, а также общаться и обмениваться кодом, используя единую площадку. Самая известная на текущий момент си стема, которая попыталась объединить эти направления Launchpad от компании Canonical.

ABF система для совместной работы над свободным ПО Изначально для разработки продуктов в компании РОСА исполь зовались наработки Mandriva одного из старейших международных Linux дистрибутивов, разработка которого велась с использованием собственной системы сборкиnull Kenobi. К сожалению, к 2010 году система морально и технологически устарела, не осталось специали стов, которые могли бы её активно поддерживать и развивать. Исходя из этого, в РОСЕ было принято решение начать разработку новой сбо Вечернее заседание (15.00–19.00) рочной системы на основе опыта, современных знаний и технологий, накопленных мировым сообществом.

Основные идеи, которые были взяты за основу:

• хостинг, разработка и сборка кода должны быть доступны на единой площадке;

• пользовательский интерфейс важная часть системы;

• поддержка разработки множества различных дистрибутивов;

• собрать свою образ дистрибутива должно быть не просто, а очень просто;

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

• всесторонние автоматические проверки пакетов залог здоро вья репозитория.

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

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

• Интегрированная проектная wiki - сохранять знания о проекте рядом с ним, как показал опыт Github, удобно и полезно как для разработчиков, так и для сообщества.

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

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

Архитектура ABF Главная идея архитектуры: изолированные подсистемы (модули), общающиеся друг с другом строго по API и оперирующие обобщен ными (абстрактными) элементами. Изоляция позволяет точно опре делить зоны ответственности каждой подсистемы, уменьшить вза имное влияние и возникновение “наведенных” ошибок, а также раз рабатывать подсистемы параллельно разными командами. Важным 23 июля следствием такого разделения стала возможность сделать сборочные клиенты для множества дистрибутивов, так как вся специфическая для конкретного дистрибутива логика сосредоточена именно в самом клиенте, в то время как остальные элементы системы по-прежнему работают с общими абстрактными элементами.

Система состоит из следующих компонентов:

• система хранения git-репозитория;

• веб-подсистема;

• ядро сборочной системы;

• сборочный клиент;

• клиент для сборки ISO-образов.

Конечно, высокий уровень абстракции накладывает ряд ограничений.

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

Текущие проблемы и способы их устранения В процессе первичной эксплуатации при разработке релиза ROSA Marathon 2012 был выявлен ряд недостатков и узких мест в текущей реализации:

• хранение архивов c исходным кодом (tar, zip) в git в буду щей версии будет реализован отдельный сервис хранения таких архивов, что позволит значительно сократить объемы трафика при работе с системой, позволяя в том числе работать мейнтей нерам со spec файлом через веб разработка Linux с не-Linux машин станет реальной;

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

• общая файловая система NFS для взаимодействия между кли ентами и ядром сборочной системы сборочный клиент будет Вечернее заседание (15.00–19.00) изолирован от основных подсистемы как наиболее уязвимое зве но, все команды будут передаваться через очередь сообщений, а передача данных осуществляться через протокол HTTP.

Заключение ABF находится в самом начале своего развития, хотя уже обладает минимально необходимым набором функций и качеством. В частно сти, с помощью ABF были проведены работы по созданию и выпуску промышленной версии дистрибутива ROSA 2012 Marathon, а сейчас осуществляется поддержка весеннего и подготовка осеннего выпус ков, а также разработка серверной версии ROSA. Кроме того, ABF используется для пересборки целого ряда дистрибутивов (НауЛинукс, Fedora, OpenSUSE, Альт Линукс и др.) в рамках проекта Минобразо вания.

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

• REST API для управления сборочными заданиями;

• интеграцию автоматических тестов от rpmlint до LSB;

• повышение безопасности сборочной системы путем изоляции сборочных клиентов;

• консольный клиент работы с ABF.

ABF является свободной и открытой системой и доступна для разво рачивания частных сборочных для разработки различных дистрибу тивов. В частности, ведутся обсуждения об использовании ABF для разработки коммьюнити версий Mandriva, MIB и Unity Linux. Мы предлагаем всем желающим участвовать в проекте.

23 июля Игорь Власенко Киев, ALT Linux Проект: Автоматизация сопровождения программных пакетов http://www.altlinux.org/Категория:Packaging_Automation Автоматизация сборки и сопровождения пакетов для дистрибутива. Технологии и инфраструктура.

Свободное программное обеспечение за последнее десятилетие сде лало потрясающие успехи в своем развитии. Однако этого нельзя ска зать о собственно дистрибутивах Linux. Linux все еще не стал осно вой рабочего стола пользователя;

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

среди недовольных пользователей дис трибутивов Linux такие люди, как Линус Торвальдс и Инго Молнар.

В своей статье Что отравляет Linux desktop? Инго Молнар пи шет: Удивительно, но главным недостатком дистрибутивов Linux для настольных ПК является их недостаточная свобода....

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

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

Отвечая Инго Молнару, можно сказать, что централизованные Linux-дистрибутивы с иерархической структурой являются вынуж денным ответом на проблему взаимодействия. Распределённые в про странстве свободные сообщества являются действительно огромной силой;

но для того, чтобы ей воспользоваться, необходимы техноло гии и инфраструктура. Днепр, протекающий через Украину, облада Вечернее заседание (15.00–19.00) ет огромной энергией;

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

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

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

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

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

– активно привлечь пользователей к тестированию пакетной базы.

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

Литература [1] http://www.altlinux.org/Croncopy [2] http://www.altlinux.org/Cronport [3] http://www.altlinux.org/Gear/cronbuild [4] http://www.altlinux.org/Git.alt/girar-nmu [5] http://www.altlinux.org/Packaging_Automation/DistroMap 23 июля [6] http://www.altlinux.org/Repocop Виталий Кузнецов Москва, ALT Linux Проект: Sisyphus http://sisyphus.ru ALT Linux: Седьмая платформа Аннотация ALT Linux Sisyphus постоянно развивающийся нестабильный ре позиторий свободного ПО. На его базе периодически выпускаются раз личные решения. Доклад посвящён готовящемуся выпуску очередного стабильного бранча ALT Linux, описываются основные задачи выпуска, трудности на пути их решения, текущий статус процессов разработки.

Что такое платформа ALT Linux?

Платформа ALT Linux это всё необходимое для выпуска ста бильных поддерживаемых дистрибутивных решений. В неё входит:

• Cтабильный поддерживаемый срез Sisyphus с определёнными свойствами;

• Инструменты создания дистрибутивов (mkimage), типовые про фили (mkimage-proles, mkimage-proles-desktop,... );

• Инфраструктура поддержки (сборочница, bugzilla,... );

• Сопутствующие инструменты.

Почему настало время выпускать новый бранч?

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

Вечернее заседание (15.00–19.00) Что нового будет в p7?

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

• Новый xorg-1.12 с поддержкой современных методов ввода (multitouch). Будет обеспечена поддержка выпуска дистрибу тивов для ноутбуков с тачскринами и планшетных устройств.

• Поддержка Systemd. Решаемые в рамках выпуска задачи:

– Обеспечение возможности выпуска дистрибутивов на sys temd;

– Поддержка systemd в основных сервисах;

– Unit-файлы для распространённых сервисов.

• Поддержка работы в облачных окружениях Amazon EC2 и Microsoft Azure. Задачи:

– Поддержка утилит для работы с окружениями (ec2-api tools, azure-sdk-for-node);

– Поддержка создания образов VM;

– Публичные образы VM (как минимум на EC2).

• IPV6 для основных приложений – Обеспечение функционирования основных компонентов дистрибутива в IPv6 сети (тестирование);

– Обеспечение настройки IPv6 в установщике / конфигура торах (Alterator).

• Поддержка установки на EFI (с помощью grub2-e) в установ щике.

• Новая, беспроблемная для пользователя реализация arepo:

– Разработка способа перепаковки RPM ‘на лету’ в момент сборки задания в репозиторий;

– Интеграция в сборочницу.

Карманы :

• – Обновление инфраструктуры;

– Распределённая сборочница, способная обрабатывать боль шое (сотни) количество репозиториев;

– Оптимизация обработки задания (параллелизация прове рок, сборки,... );

23 июля – Межрепозиторные зависимости.

• Современные toolchain, autotools.

• GNOME3.

• Синхронизация ARM-репозитория.

• Поддержка deepsolver в режиме ‘technology preview’.

Что хотелось бы видеть, но не стоит ожидать в p7?

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

• Новый alterator-vm:

– Отказ от EVMS в установщике (либо его активная разра ботка);

– Установка на шифрованные разделы;

– Установка на iSCSI.

– Простой интерфейс для простых десктопных установок.

Человеческая программа установки ПО:

• – Установка прикладного ПО, каталог на основе desktop файлов;

– Поддержка установки проприетарных RPM (Google, Skype и т.п.).

• Поддержка ввода в домен AD.

• Централизованное управление серверами и десктопами.

Когда ожидать релиза?

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

Вечернее заседание (15.00–19.00) Дмитрий Левин Москва, ALT Linux Проект: strace, http://sourceforge.net/projects/strace/ strace глазами апстрима Аннотация Напоминается история проекта, рассматриваются основные воз можности strace и нововведения в недавно выпущенных версиях, при водятся примеры использования strace, дается обзор ptrace API и реа лизации strace, рассматриваются перспективы дальнейшего развития.

История проекта 1991-1992: Paul Kranenburg;

• 1993: Branko Lankester;

• 1993-1996: Richard Sladkey;

• 1996-1998: смутное время;

• 1998-2002: Wichert Akkerman;

• 2002-2009: Roland McGrath;

• с 2009.

• Основные возможности и примеры использования Отслеживание порождаемых процессов:

-f, -.

• Мониторинг процессов, существующих на момент запуска:

-p.

• Сбор статистики:

-c, -C, -S.

• Дополняющие описатели:

-i, -r, -t, -tt, -ttt, -T.

• Формат вывода строк:

-s, -x, -xx.

• Выбор множества отслеживаемых системных вызовов:

-e trace=set.

• Глубина детализации множества системных вызовов:

-v, -e • abbrev=set, -e verbose=set, -e raw=set.

Выбор множества отслеживаемых сигналов:

-e signal=set.

• Мониторинг операций чтения/записи:

-e read=set, -e write=set.

• Конвейеризация:

-o.

• buildreq.

• 24 июля Нововведения с 2009 года • 4.5.19: прозрачность, новые архитектуры, новые системные вы зовы, улучшенные парсеры.

• 4.5.20: новый ключ -C, новые архитектуры, новые системные вызовы, улучшенные парсеры.

• 4.6: переход на новый Linux ptrace API для реализации отслежи вания процессов, новые архитектуры, новые системные вызовы, улучшенные парсеры.

• 4.7: новые ключи (-y, -P, -I), новые архитектуры, новые систем ные вызовы, улучшенные парсеры.

Обзор реализации • Linux PTRACE API.

• Отслеживание процессов.

• Парсеры системных вызовов.

• Реализация multiarch.

Перспективы дальнейшего развития • Интерфейс PTRACE_SEIZE.

• Все более и более детализованные парсеры.

• Надежный multiarch.

Утреннее заседание (10.00–14.00) Воронин Игорь Вадимович Шатура, ИПЛИТ РАН Проект: Образовательный проект УМКИ http://umki.vinforika.ru/ Использование КУМИР-а для управления сенсорными сетями роботов Аннотация Работа посещена вопросам управления и связи множества разнооб разных устройств в единую сенсорную сеть для выполнения различных миссий, при помощи которых в игровой и увлекательной форме проис ходит обучение базовым навыкам программирования и управления ди станционным способом различными роботизированными передвижны ми комплексами. Проект основан на идеологии свободного программ ного обеспечения и в нём используется программный пакет КУМИР для удобства и наглядности программирования передвижения роботов.

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

А если таких машин 5, 10, 100? И действуют они не на открытой взору поверхности, а за углом или за каким-то препятствием?

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

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

Так вот, чтобы легко и просто как бы играя, научиться управ лять такими устройствами, был разработан образовательный кон структор который называется: УМКИ. Это Управляемый по ра дио каналу Машинный Конструктор Инновационный. Достоинство конструктора в том, что он комплектуется роботизированными плат формами, которые связываются между собой в единую сенсорную сеть, на основе протокола ZigBee. Изучив этот курс, ученики получа ют базовые знания по управлению сначала одним устройством, потом группой устройств объединеных в распределённую беспроводную сен сорную сеть. Каждая роботизированная платформа оснащается либо набором сенсоров датчиков для различных физических величин, либо исполнительными механизмами. Вы сможете заставить машин ку двигаться по программе, ориентироваться на местности и выпол нять разнообразные задания. Курс составлен так, чтобы на каждом его этапе было максимально интересно получать знания. Выполняя шаг за шагом задания к занятиям вы будете проходить разнооб разные миссии. Занимаясь с УМКИ, в игровой форме вы овладеете серьёзными инженерными знаниями которые сможете реализовать в дальнейшем, например в научных исследованиях.

Текущая версия УМКИ, базируется на элементах и различных инженерных схемах конструктора Знаток. С её помощью можно с интересом использовать конструктор. Она укомплектована мето дическими материалами для преподавателей, которые включают в себя поурочное планирование. Аудитория курса это начальные классы дополнительного школьного образования. Документация по работе с роботизированными машинками УМКИ наполнена научно популярной информацией для детей и представлена в игровой форме как процесс изучения окружающего нас мира. Вдобавок, для боль шей наглядности в ней используются интерактивные технологии. Все Утреннее заседание (10.00–14.00) миссии курса представлены в разных вариантах и связаны между со бой логической составляющей.

Первым вариантом является Миссия на Марс.

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

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

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

1. 4-х колёсного вездехода, или иначе говоря передвижной плат формы с модулем zigbee, который позволяет связываться мно жеству платформ по стандарту IEEE 802.15.4 в единую, распре делённую самоорганизующуюся сенсорную сеть.

2. Радио шлюза который по USB соединяется с ПК и служит для отправки команд по радиоканалу и приёма ответов о вы полненных процедурах.

24 июля Рис. 1: Состав конструктора 3. Программного обеспечения (ПО) на ПК, для управления пере движной роботизированной платформой одной конкретной выбираемой по МАК адресу, или множеством сообщества.

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

Программное обеспечение для управления вездеходом состоит из следующих модулей:

1. Серверной части, написанного на C++, и скомпилированной под GCC, которая загружается при запуске системы в оперативную память и находится там в постоянно активном состоянии для фор мирования команд управления передвижной платформой, и приёма ответов о выполненных командах.

Ниже приведён код обработки USB порта.

while (1){ if (flag\_com == 0){ fs = fscanf(fl\_com,{\textquotedbl}\%s{\textquotedbl},ss);

if (fs{\textless}0) break;

} } 2. Модуля внешнего интерфейса, написанного на QT и предназна ченного для управления мышкой или с клавиатуры для управления передвижением поворотной платформы.

Утреннее заседание (10.00–14.00) Рис. 2: Внешний вид монитора и программы управления Ниже приведён код отрабатывающий при нажатии клавиши впра во.

void Vench::BPressRight() { if(fl_play)return;

if(fl_rec){ b_tim_comm=GetTime();

} if (checkOld-isChecked() == TRUE) { if (shiftPress==0) SendCommRight();

else SendCommExtrRight();

} if (checkOld-isChecked() == FALSE) { if (shiftPress==0) SendCommRight1();

else SendCommExtrRight1();

} PressRh=1;

} Внешний вид монитора и программы управления приведен на рис. 2.

3. А так же свободно распространяемого пакета КУМИР для программирования и задания пути движения передвижной платфор мы (см. рис. 3).

Код кумира использовать Робот алг нач. нц 3 раз.. вниз. кц. вправо. вправо. нц пока сверху стена 24 июля Рис. 3: Программа КУМИР.. закрасить.. вправо. кц кон Следует также обратить внимание на то, что программный пакет КУМИР рекомендован для использования в школах при подготовке к сдаче ЕГЭ.

В дальнейших планах развития этого проекта переход от обу чения программированию перемещениями в плоскости 2D, посред ством использование алгоритмов, заложенных при разработке данно го УМКИ, на управление объектами, перемещающимися в 3D про странстве, например беспилотными летательными аппаратами.

Литература [1] http://wiki.laser.ru/index.php/Беспроводные_распределённые_се нсорные_сети Утреннее заседание (10.00–14.00) Михеев Андрей Геннадьевич Москва, Консалтинговая группа РУНА Проект: RunaWFE http://wf.runa.ru/rus Концепция межпроцессного взаимодействия в свободной системе управления бизнес-процессами и административными регламентами RunaWFE Аннотация В докладе рассказывается про реализованную в системе RunaWFE в начале 2012 года концепцию взаимодействия выполняющихся экзем пляров бизнес-процессов при помощи сообщений Системы управления бизнес-процессами и административными регламентами Процессную организацию управления организацией используют для повышения эффективности работы организации. Эффективность повышается за счет оптимизации бизнес-процессов коммерческой ор ганизации или административных регламентов ведомства, появления возможности быстрого изменения бизнес-процессов в ответ на изме нение условий деятельности предприятия, а также за счет повышения производительности труда работников..

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

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

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

Система RunaWFE RunaWFE открытая, масштабируемая, ориентированной на ко нечного пользователя система управления бизнес-процессами и адми нистративными регламентами. Система платформонезависима (напи сана на Java), распространяется под LGPL-лицензией.

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

Для посылки и получения сообщения в палитру графических эле ментов были добавлены новые элементы Отправить сообщение и Получить сообщение (см. Рис. 1) Для отправки и получения сообщений используется технология JMS. Узел-отправитель посылает сообщение сразу после прихода в него точки управления, после этого точка управления перемещается Утреннее заседание (10.00–14.00) Рис. 1: Элементы отправки и получения сообщений в системе RunaWFE (вариант UML нотации) в следующий узел, а узел-получатель ожидает сообщения, и точка управления может находиться в этом узле неопределенно долго.

В сообщении содержится следующая информация:

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

Адресат сообщения может быть определен следующим образом:

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

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

24 июля Рис. 2: Форма, связывающая переменные бизнес-процесса и парамет ры сообщения Если сообщение послано по названию бизнес-процесса, а выполня ющихся экземпляров этого бизнес-процесса не существует, то сообще ние будет ждать появления первого экземпляра этого бизнес-процесса и передаст значения своих параметров первому появившемуся экзем пляру в узле Получить сообщение. Если, наоборот, существует сра зу несколько выполняющихся экземпляров этого бизнес-процесса, то сообщение будет передано сразу всем этим экземплярам.

Литература [1] Сайт проекта: http://wf.runa.ru Утреннее заседание (10.00–14.00) Радик Юсупов, Ленар Шакиров Казань, ГК Центр Проект: Zarafa http://www.zarafa.com/, http://openware.pro Zarafa. Создание решений уровня Enterprise для российского бизнеса.

Аннотация Бизнес избалован вниманием крупных и мелких IT-компаний, ко торые предлогают разные решения, которые различаются как по ка честву, так и стоимости владения. Компания Центр в своих реше ниях использует СПО-решения, достигая оптимального соотношения цена/качество. Но решения СПО зачастую требует большой доработки и адаптации Позвольте представиться, меня зовут Юсупов Радик Анасович.

Я руководитель отдела Инфраструктуры Информационных Систем.

Мой отдел занимается разработкой и внедрением инфраструктурных решений в Татарстане и регионах России.

Многие инфраструктурные проекты создавались нами с использо ванием СПО. Наши решения на основе ALTLinux работают например в ТатНефть, МЧС, министерствах и банках.

К нам часто обращаются с вопросом замены MS Exchange на ли нуксовый функциональный аналог. Мы протестировали несколько си стем групповой работы, такие как ClearOS, Zimbra, Open-Xchange и др. и остановились на Zarafa.

Zarafa Collaboration Platform это сервер групповой работы с от крытым исходным кодом, предназначенный для обмена сообщениями и организации совместной работы сотрудников компании. Благода ря совместимости с MAPI, Zarafa является лучшей масштабируемой заменой Microsoft Exchange.

Zarafa предоставляет все необходимые возможности связки Ex change/Outlook:

• почта;

• адресная книга;

• задачи, записки, календари;

• персональные/публичные папки;

• планирование мероприятий.

24 июля Благодаря своей открытой архитектуре Zarafa легко масштабируема и включает в себя лучшие возможности в своем классе продуктов с открытым исходным кодом, такие как МТА (например, Postx), базы данных SQL и сервера Apache. Среди возможностей Zarafa следует упомянуть следующие:

• поддержка Outlook 2000-2010;

• поддержка POP3/IMAP-клиентов;

• веб-интерфейс, привычный для пользователей Outlook Web Access;

• синхронизация с любым устройством, поддерживающим Ac tiveSync (iPhone, Android, Nokia);

• поддержка MTA;

• интеграция с LDAP-каталогами (в том числе Active Directory);

• хранение данных в MySQL;

• интеграция с антиспам- и антивирусными решениями;

• интеграция с открытыми решениями SugarCRM, O3Spaces, OpenERP и Alfresco, благодаря собственному фреймворку.

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

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

Почти все патчи и локализацию разработчики приняли и добавили в свой код.

Патчи создавались при поддержке ALTLinux Team, за что им огромное спасибо!

В качестве LDAP-сервера был выбран 389 Directory Server. Это весьма мощный инструмент, предоставляющий возможности по управ лению пользователями, группами и серверами средствами графиче ского пользовательского интерфейса. Для удобства пользования этим удобным продуктом, мы произвели локализацию 389DS на русский язык и через ментейнера 389DS в сизифе Виталия Кузнецова, пе редали переводы разработчикам. Надеемся, что в ближайшее время локализация на русский язык появится в новых версиях 389DS.

Утреннее заседание (10.00–14.00) Итак. На данный момент мы имеем локализованный на русский язык сервер групповой работы Enterprise уровня, который легко ин тегрируется с 389DS, который в скором времени будет получит ло кализацию на русский язык. И все это в дружелюбном Российском дистрибутиве.

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

Михаил Быков Москва, http://diglossa.ru http://diglossa.ru Морфеус, морфологический анализатор латинского языка Аннотация Простой морфологический анализатор Морфеус построен на ос нове стандартных хорошо знакомых выб-технологий. В качестве ос новной структуры данных всегда используется JSON, в качестве базы данных CouchDB. При разработке для генерации тестов (более 3000) использовалась хорошо себя зарекомендовавшая программа words У.Уитеккера.

Морфус [1], морфологический анализатор латинского языка, по e строен с использованием стандартных методов веб-разработки на языке Ruby и CouchDb. Имеет систему тестов, гарантирующих кор ректность полученных результатов.

Большинство известных мне морфологических анализаторов по строены на основе openSFT [2] на конечных преобразователях. То есть на преобразовании строк с помощью регулярных выражений. По лучающееся в результате чудовищное (много экранов) регулярное вы ражение компилируется в бинарник, способный очень быстро обрабо тать большой объем текста. Происходит преобразование строка (ана лизируемое слово) строка (морфологический анализ этого слова).

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

Это очень трудоемкий подход.

В Морфеусе я предлагаю, напротив, подход более человечный. Все данные о парадигмах языка хранятся в JSON и легко читаются и 24 июля модифицируются человеком. Обрабатываются не строки, а ruby (на сервере) или Javascript (на клиенте) объекты.

Алгоритм работы простого морфологического анализатора таков:

Каждая словоформа проходит через сито парадигм и связанных с ним правил, и на первом шаге 1) выявляются парадигмы, способные породить данную словоформу и возможные словарные формы, затем на втором 2) выбираются только те парадигмы, которые порождают действительно существующее в словаре слово и наконец 3) результат кешируется в БД. Вдобавок есть механизм заполнения базы слово форм исключениями, (терминами, не требующими никакого анали за, вне системы парадигм.). Все происходит в NoSQL-БД (поскольку json), а именно в CouchDB [3].

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

Преимущества: 1) знакомые и обкатанные веб-технологии, все на http-rest запросах, все на стандартных библиотеках обработки ruby хеша или js-объекта. И 2) крайняя простота и человекоразмерность данного подхода, 3) возможность постепенного улучшения анализа тора, 4) возможность коллективной работы. И, очень важно, про зрачная возможность предварительной и заключительной (синтакси ческой, контекстной) обработки поступающего потока текста.

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

Вначале клиент (браузер) посылает анализируемую строку на сер вер. Сервер выполняет предварительный анализ строки, выделяя предложения, части предложения (главные, подчиненные), и обраща ется к Морфеусу за морфологическим анализом каждой словофор мы. В результате получается упорядоченный массив морфологиче ских данных. На следующем этапе выполняется частичный синтакси ческий анализ, а именно, находятся жестко связанные между собой слова, например предлог, сочетающийся только с определенным па дежом, или причастие и определенная форма глагола esse, прилага тельное плюс его существительное, и т.д. На этом же этапе мы можем отбросить лишние морфологические результаты, избавившись от неопределенности морфологического анализа (в том распространен ном случае, когда морфологический анализ вырванной из контекста Утреннее заседание (10.00–14.00) словоформы дает несколько взаимоисключающих результатов). На конец, приходит время terra incognita полноценного синтаксическо го анализа. В результате же должен получиться граф синтаксических связей предложения. Но это дело будущего, крайне заманчивое.

Отдельно я хочу отметить, что данный подход опирается на тесты, точнее, спецификации. И является примером стандартного BDD-style [4] способа разработки. Я использовал несколько источников вер ного ответа для создания спецификации. В основном, программу words Уильяма Уитеккера [5]. Каждая парадигма имеет исчерпыва ющий набор примеров, и разработка ведется до тех ровно пор, пока все полученные морфологические формы не совпадут с верными ответами. Кавычки я употребляю потому, что и в программу Уитек кера (лучшей из всех), и на сайте Персея [6], и на сайте Wiktionary [7] существует масса расхождений и между собой, и с известными мне учебниками. Улучшение работы Морфеуса сверх этих черновых BDD спецификаций, т.е. полировка программы, потребует работы уже не программистов, но лингвистов и филологов и, видимо, годы труда.

В качестве вывода, я хотел бы предложить, чтобы на основе этого подхода, или схожих с ним, 1. объединились бы люди, разрабатывающие подобные морфоло гические анализаторы для всех близких нам языков, всех глав ных европейских языков, и всех языков будущего ЕАС, древних языков и т.д.

2. возникла бы общедоступная веб-служба с простым стандартным API для запроса анализа любой словоформы любого языка.

Некоторые подробности.

Морфеус написан на руби и имеет несколько удобных для работы классов с самообъясняющими названиями: Paradigm, Dict, Term (для исключений), Spec и некоторые вспомогательные классы, например Couch для работы с Кауч-DB.

load ’morpheus.rb’ пример парадигмы:

pp Morpheus::Paradigm.get "verb_act_fut-perf_ind" [{:_id="8417feaa0669fda52d6d4d8d2b409302", :_rev="1-b2cd18b4cc2d616ed767fb7b47401940", :type="latin-paradigm", 24 июля :pos="verb", :descr="act.fut-perf.ind", :dict="i", :flexes= {:"sg.1"="ero", :"sg.2"="eris", :"sg.3"="erit", :"pl.1"="erimus", :"pl.2"="eritis", :"pl.3"="erint"}... часть вывода опущена для ясности] пример вычисления возможных словарных форм:

pp Morpheus::Morph.guess "aquae" {:nouns= [{:pos="noun", :dict="aqua", :descr="prima", :gend="fem", :stem="aqu", :full="aquae", :sggen="ae", :morphs=["pl.nom", "pl.voc", "sg.dat", "sg.gen"], :var="a"}, {:pos="noun", :dict="aqua", :descr="prima", :gend="masc", :stem="aqu", :full="aquae", :sggen="ae",....

:adjs= [{:pos="adj", :dict="aquus", :descr="primsec", :gend="fem", :stem="aqu", :full="aquae", Утреннее заседание (10.00–14.00) :sggen="ae", :morphs=["pl.nom", "pl.voc", "sg.dat", "sg.gen"], :grad="pos", :var="us-f"},...

:parts=[], :verbs= [{:pos="verb", :dict="aquaeo", :descr="act.pres.imp", :stem="aqua", :morphs=["sg.2"], :var=2},....

:infs=[]} прмер получения окончательного результата:

pp Morpheus::Morph.parse "aquae" ;

[{:pos="noun", :dict="aqua", :form="aquae", :morphs= [{:gend="fem", :number="pl", :kase="nom"}, {:gend="fem", :number="pl", :kase="voc"}, {:gend="fem", :number="sg", :kase="dat"}, {:gend="fem", :number="sg", :kase="gen"}], :type="latin-form"}] Литература [1] https://github.com/mbykov/morph-couch [2] http://wiki.apache.org/couchdb/FrontPage [3] http://www.openfst.org/twiki/bin/view/FST/WebHome [4] http://rspec.info/ [5] http://ablemedia.com/ctcweb/showcase/whitakerwords.html [6] http://www.perseus.tufts.edu/hopper/morph?la=la&l=rationi [7] http://en.wiktionary.org/wiki/aquae#Latin 24 июля Макраме из дистрибутивов: mkimage-proles Шигорин Михаил Киев, Massive Solutions Ltd Проект: mkimage-proles http://www.altlinux.org/Mkimage/Proles/m-p Морфеус, морфологический анализатор латинского языка Аннотация Когда дистрибутивов было ещё меньше сотни, а создавались они вручную вопрос управления конфигурацией особенно не стоял:

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

Как мы уже обсуждали [1], раздвоение чего-либо (форк) может являться мощным средством как развития, так и уничтожения про ектов в зависимости от того, насколько приветствуется и удобно сведение результатов опять воедино (мерж).

mkimage-proles на данный момент является экспериментальной разработкой по части уменьшения излишнего дублирования общей части конфигурации и вспомогательного кода, необходимого для фор мирования образов дистрибутивов и виртуальных окружений. Он создан на основе опыта расширения и рефакторинга альтовского mkimage-proles-desktop и семейства схожих профилей плюс созда ния набора installer-feature-*, а также более ранних наработок (spt proles-*).

Проект стартовал в августе 2010 года по мотивам очередного ре факторинга m-p-d;

после первоначальных экспериментов по опреде лению траектории тогда же осенью был опубликован черновик, а ещё через год состояние оформилось в достаточной степени для офици ального представления. Коллектив разработчиков потихоньку уве Утреннее заседание (10.00–14.00) личивается [2], а патчи либо кусочки кода приходят от ещё нескольких человек.

Использован для создания tech preview дистрибутива Simply Linux 7.

Поддерживается:

• наследование конфигурации на всех уровнях от перечня па кетов до образа • гибридные ISO с LiveCD, RescueCD, инсталятором или их ком бинацией • шаблоны виртуальных окружений OpenVZ • образы VM • архитектуры i586, x86_64, ARM • пакетная база ALT Linux 6+ (возможно бэкпортирование для более ранних) Возможны:

• при востребованности PowerPC • более ранняя пакетная база ALT Linux, как минимум до 5+ • иные пакетные базы (проведены эксперименты с openSUSE 11. и CentOS 6) Литература [1] Восьмая конференция разработчиков свободных программ: Тезисы до кладов. Обнинск 25–26 июля 2011 года. М.: Альт Линукс, 2011. 43 с.:

ил.

[2] https://www.ohloh.net/p/mkimage-profiles 24 июля Денис Баранов Санкт-Петербург, Etersoft Проект: Gitum http://freesource.info/wiki/GitUM Git Upstream Manager средство для организации разработки и взаимодействия с upstream проекта.

Аннотация В докладе рассматривается инструмент для работы с системой контроля версий Git Git Upstream Manager (Gitum), позволяю щий эффективно создавать и сопровождать ответвления от upstream репозиториев;

области его применения и принципы работы.

В большинстве случаев проект на основе свободного ПО строит ся на базе стабильного релиза, добавляется новый функционал. При попытке смержиться с upstream-веткой происходят конфликты, по сле исправления которых все наработки сползают в середину истории коммитов. В такой ситуации поиск своих патчей становится зада чей не из лёгких. При ведении быстроразвивающихся проектов, та ких как WINE (http://winehq.org), частые мержи и невозможность отделить свои и upstream-коммиты делают актуальным вопрос о корректном управлении и разборе кода. Проект Gitum (Git Upstream Manager), разработка которого была начата в 2011 году, призван по мочь более легко и быстро ориентироваться в коде.

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

Краткая характеристика рабочего процесса с gitum.

Gitum имеет 5 рабочих веток:

1. Ветка апстрим репозитория upstream.

2. Ветка с патчами наверху rebased.

3. Ветка с непрерывной историей изменений рабочая ветка mainline.

4. Ветка с патчами в виде отдельных файлов каждый коммит относится к состоянию репозитория patches.

5. Ветка с конфигурационным файлом, где содержатся имена че тырёх предыдущих веток gitum-cong.

Утреннее заседание (10.00–14.00) Таким образом, разработчик всегда имеет актуальную версию upstream-ветки, ветку со всеми своими патчами и всей историей изменений в процессе разработке ответвления.

Разработанная система Git Upstream Manager позволяет разработ чикам с меньшем количеством усилий производить обновление своих продуктов до последних версий upstream и отсылать пачти в основ ную ветку разработки.

Алексей Чеусов Минск, IHS Проект: mk-congure https://github.com/cheusov/mk-congure mk-congure легковесная система сборки ПО Аннотация mk-congure is a lightweight replacement for GNU autotools written in bmake (portable version of NetBSD make) and traditional UNIX tools such as awk, grep etc. The main goal of the project is to make development process easier, for example mk-c provides only one top-level tool mkcmake instead of aclocal+automake+autoconf+autoheader. Other goals are portability, clean design, no heavy dependencies, simplicity, and of course "NO CODE GENERATION!".

В феврале 2009 года в результате очередного обсуждения в од ной из эхоконференций сети FIDO различных вопросов, связанных со сборкой программных проектов, как то чей make лучше, без альтернативен ли autotools, GNU make vs. BSD make и прочих веселых вопросов я решил, что пришло время реализовать свои идеи и представления об идеальной с моей точки зрения (или близкой к идеалу) системе сборки ПО. Так, в ответ на вопрос Зачем слова? Вы мне покажите..., родился еще один проект с открытым исходным кодом, один из десятков тысяч других, претендующих на место под солнцем. Называется он mk-congure (иногда я называю его mk-c или mkc). Его целью и задачей является упрощение написания приложе ний под UNIX-подобные ОС, и, ни много ни мало, составить конкурен цию таким известным и популярным проектам, как autotools, scons, cmake, а также другим, менее популярным, но решающим все ту же задачу сборку программного проекта и установку его на систему пользователя для дальнейшего использования.

24 июля Наиболее часто задаваемый мне вопрос Зачем?. И действи тельно, зачем? Проектов аналогичного назначения масса. К тому же GNU autotools прекрасно у всех работает. Зачем что-то еще? c.



Pages:   || 2 |
 

Похожие работы:





 
2013 www.netess.ru - «Бесплатная библиотека авторефератов кандидатских и докторских диссертаций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.