Вход
Закрыть
Вход
Войти, используя:
Зарегистрироваться Экспертная сеть по вопросам государственного управления

Партнеры сообщества

Подтверждение удаления
Отменить
Удалить

Комментарий по НПП от R&D ЗАО "РОСА"

27 сентября компания PingWin из нашей группы компаний была объявлена победителем федерального конкурса ИО/04-11 (разработка прототипов Национальной Программной Платформы). 18 октября был подписан госконтракт и началось выполнение работ. Ввиду того, что проект привлекает существенный общественный интерес, за прошедшее время в сети было размещено огромное количество разнообразных комментариев, написаны десятки статей (в т.ч. в Коммерсанте и Ведомостях), проведена пресс-конференция РАСПО. Однако по большей части обсуждаются темы политические и налицо существенный недостаток информации о внутренней реализации наших прототипов, в связи с чем на онлайн-ресурсах начинается мифотворчество. Я посчитал правильным дать комментарий с точки зрения команды R&D компании РОСА. В двух словах, для нас этот проект является крайне серьезным challenge и, как мы надеемся, позволит нам обогатить мир СПО рядом собственных разработок.

Многие интересуются, с чем мы пойдем на сдачу и показывают на старые сборочные инструменты Мандривы. На самом деле, выигрыш ПингВином первого этапа НПП и, как следствие, пришедшая в R&D РОСы задача по предоставлению системы сборки дают нашей скромной команде повод продемонстрировать публике развиваемый в РОСе/Mandriva внутренний проект универсального билд-сервера ABF. Этот проект мы начали в России для реализации нашей давней идеи автоматизированного согласования зависимостей при пересборке пакетов. А именно, ABF работает так, что новые пакеты не проходят апрув (и не попадают в репозитории) пока не достигнута пересборка всех зависимых от них. Процедура согласованной пересборки позволяет в т.ч. обрабатывать кольцевые зависимости. Как результат – один раз достигнутые корректность и воспроизводимость сборки набора пакетов (а значит – дистрибутивов и любых программ для них) далее не нарушаются неосторожными действиями майнтейнеров (с чем идеологам ABF приходилось в своей предыдущей жизни часто сталкиваться при построении производных Федоры, а позднее и самой Мандривы). Если майнтейнер предлагает некачественный пакет, он немедленно и автоматически получит его обратно с указанием переделать.

На взгляд системных архитекторов РОСы/Mandriva, continuous integration при построении дистрибутивов – это не сколько сам факт ежедневных сборок из пакетов разной степени свежести, как часто бывает, но в гораздо большей степени – уверенность билд-менеджера в том, что все пакеты в образе собраны без конфликтов друг с другом, и проверять это нужно в целом, а не только набором локально применяемых тестов. Нам кажется странной ситуация, когда нарушение пакетом сборки других пакетов обнаруживается в значительной степени случайно, вручную и запросы на пересборку размещаются вручную же в списке рассылки без гарантии какой-либо реакции. Это – прошлый век.

Конструктивно ABF представляет собой расширяемое распределенное множество билд-клиентов (для разных платформ и архитектур), работающих с единым хранилищем кода и управляемых из единого диспетчера-балансировщика. Уже сейчас есть билд-клиенты для Mandriva и для ряда RH-производных, то есть единообразно собираются различные дистрибутивы. От приходящего в эту инфраструктуру разработчика платформы/дистрибутива требуется создать на основе нашего шаблона собственный сборочный бэкенд (используя фрагменты скриптов оригинальной процедуры сборки) и импортировать исходные коды в хранилище. То есть, собрать любой RPM-based дистрибутив – это дело техники. С Debian-based дистрибутивами создание бэкендов несколько сложнее, но достижимо и уже запланировано. А уж создание производных дистрибутивов и сборка одного приложения для нескольких платформ – все это перестает быть хоть сколько-нибудь сложным. 

Повторю, речь идет о давно задуманных и развиваемых в РОСе технологиях, причем изначально развиваемых для внутренних нужд. Сдавать эти технологии наружу мы не стремились, специально для конкурса не готовили (и в процессе подготовки прототипов приходится срочно адаптировать код под некоторые требования), к тому же бюджет заявки от ПингВин не покроет даже наших собственных, уже понесенных, расходов на разработку этих технологий. Тем не менее, если ставить вопрос о технических альтернативах в данном контракте, мы считаем наши технологии вполне достойными участия и, что важно, достаточно современными (см. выше). Уровень, на который мы претендуем – это уровень Launchpad и OBS.

Вопрос о том, в каком режиме вести проект после сдачи для нас остается открытым. Безусловно, мы заинтересованы развивать его и приглашать дистрибутивные команды, особенно работающие с Debian-дистрибутивами, производными Мандривы (особенно будем рады глубокоуважаемой команде EduMandriva), а также собирающие дистрибутивы на других аппаратных архитектурах.

Теперь пара слов по прозвучавшим в сети обвинениям в монополизме. Российский рынок госзаказа на Linux/СПО-решения существует немногим более 10 лет, а применительно к невоенным решениям – и того меньше. Попытки монополизировать этот рынок начались задолго до появления ПингВина и РОСы.

Итоги школьного пилотного проекта 2007-2008 гг и ряда последующих проектов федерального уровня достаточно убедительно показывают, как вместо развития рынка государство можно заставить оплачивать разработки одного поставщика (дистрибутив, инфраструктура, отдельные пакеты, учебные материалы и др.) путем серии конкурсов с минимальными сроками на исполнение, при этом публику и представителей государства убеждали в том, что остальные участники “не справились” в силу “недостатка компетенции” и монополия эта – “не от хорошей жизни”. Уроки “сотрудничества” с тем замечательным генподрядчиком все участники процесса (и я в том числе, бывший тогда гендиректором одной из компаний, входивших в возглавляемый этим подрядчиком “консорциум”) хорошо запомнили и усвоили. Результат – появление более вменяемых генподрядчиков, организующих реальное сотрудничество независимых исполнителей и занимающихся развитием рынка, в том числе через отраслевые ассоциации типа РАСПО.

Рынок СПО невозможен без альтернатив. Следует внимательно присматриваться к ситуации одного дистрибутива, к использованию экзотических технологий без обоснования необходимости их привлечения, к ограничению совместимости платформ и приложений. Иначе все это может стать очередной зацепкой для монополистов, жаждущих реванша. У нас и наших единомышленников есть желание заниматься развитием рынка, а не его ограничением. Например, в ABF конструктивно может быть собран любой дистрибутив. Это намек ;)

Евгений Соколов

ROSA R&D


Комментарии (112)

Дмитрий Комиссаров, Бизнес 

С Богом Денис Валерьевич я не ссорюсь а с людьми неприличными да. 

Денис Сосновцев, Разное 

слишком субъективно, на мой взгляд

как отделить одно от другого.... Это риторический вопрос.

Дмитрий Комиссаров, Бизнес 

Отделить несложно - если нет обилия принципов.

Денис Сосновцев, Разное 

многие так самонадеянно полагают... :-) 

Сергей Голубев, СМИ 

Дмитрий Комиссаров писал(а):

Я уже говорил на эту тему - не будет Ухлинова к лету. Но давайте унесем отсюда - хочется все таки вернуться к техническим вещам.

Давайте. А глупые вопросы можно задавать? :)

Будут ли опубликован требования к "входящим"? В каком виде разработчики смогут присылать программы для среды сборки? 

Допустим, мои знакомые сделали систему мониторинга для коммуналки. Они хотят разместить ее в "госрепозитории" (или как он там). Что им надо делать?

Дмитрий Комиссаров, Бизнес 

Напомню - это НИР. После него должен быть ОКР в результате которого будет уже не прототип а работающая система. В НИРе мы предоставляем рекомендации относительно функционирования ФАП. После ОКРа они конечно уже будут утвержденными и опубликованными. Кстати вы помогли мне вспомнить - там есть большой концептуальный вопрос. Заметку напишу.

Денис Сосновцев, Разное 

Видите, и от Госбука есть польза :)

Евгений Соколов, Бизнес 

2 aen:

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

Что же касается претензий к генподрядчику 2007-2008 года, по-моему Альт - единственная команда, которая осталась довольна. Не находите странным? Считаете, то именно так нужно развивать рынок? Я ведь много чего помню, и Сомс, и Фролов. Факты кто выигрывал и что сдавалось говорят сами за себя. Делаю вывод - генподрядчик плохой, негодный, рынок не развивает, действует как мелкий лавочник.

Алексей Новодворский, Бизнес 

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

Евгений Соколов, Бизнес 

2 Алексей Лим:

Если Вы станете использовать ABF, OBS Вам не потребуется. Будем рады сотрудничеству.

Евгений Соколов, Бизнес 

2 Евгений Крестников: 

Ни об Альте, ни о Сириусе у меня речь не идет. Вы в описываемый мной период (2007-2008) кажется еще не писали на тему СПО)

Евгений Крестников, СМИ 

Евгений Соколов писал(а):

2 Евгений Крестников: 

Ни об Альте, ни о Сириусе у меня речь не идет. Вы в описываемый мной период (2007-2008) кажется еще не писали на тему СПО)

Как раз начал в 2008-м работать с LXF Russia )))

Да, протупил, наезд был по другому адресу -- прошу прощения )

Евгений Соколов, Бизнес 

2 Денис Сосновцев:

Денис, ты что, издеваешься? У нас десятки бразилов, французы, шведы (Oden Eriksson), норвежцы (Per Ovynd, Eskild), немцы (Sebastian Trug), американцы (Jeff Johnson). 

Все руководители R&D РОСы много говорят и пишут на английском.

Денис Сосновцев, Разное 

Женя ! Вы сказали: щас напишем collateral, white paper ( я так понял). Я подумал: надо бы н аанглийском тоже , чтобы поглядеть , что именно происходит в этой части в других местах, дистрибутивах и мандривах (Red Hat, IBM ...)

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

Так что никакой издёвки. Всё на полном серьёзе.

Евгений Соколов, Бизнес 

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

- -, Разное 

2 Алексей Новодворский

>А Коринф смотрели?

Конечно, его и ссылки на документы, которые вы привели, все смотрели. И не только журналисты :). 

Цитата: "Сборка пакетов, не являющихся системообразующими (неправильно применять Коринф для сборки glibc или rpm для разных систем)."

Спрашивается, как это можно использовать для построения сторонних (RH,Meego,Nau,Centos,SuSe) систем полностью? Никак. Занавес.

Тогда чтоже предлагается еще? 

- Репозиторий СПО. 

1.. совсем 1. На базе Сизифа. Как можно собрать продукты иных производителей? Никак. Занавес.

Получается, что как на тащи с завода запчасти для стирально машины, все равно выходит автомат калашникова (С). Т.е. в переводе на русский язык - предлагается использование кодовой базы Аль-Линукс во всех его проявлениях. А под "разными продуктами" на деле выступает кодовая база Альта в различных инкарнациях..... Ах, пардон, я забыл, что Альт-Линукс не имеет ничего общего с Сизифом и его производными. :)

-------

Что из себя представляет ABF:

Это сервер сборки, выступающий больше как диспетчер "внешних" сборочных систем. Есть ядро-диспетчер и ряд бэкэндов физически располагающихся на отдельных аппаратных платформах. Ядро работает с любыми репозиторями, сборка пакетов выполняется в бэкенде. Причем, замечу и системных тоже ;). Т.о. они используются как "черные ящики" и общение с ними производится посредством стандартизированого и открытого API. Любой производитель может "залить" свой дистрибутив в ABF и *без переделок* своей структуры образов и репозиториев, спеков, систем сборки - выполнять формирование своих продуктов - совершенно отличающихся от Мандривы, если кто-то об этом подумал. Заливайте хоть оргинальную слаку, только требуется немного (на основе шаблона и документации) подрихтовать бкенд, который администратор ресурса регистрирует в системе (просле, ращмуеется аудита кода и т.д.), и собирайте себе нативную слаку. В этом мы похожи на OBS, но пошли еще дальше, т.к. в OBS контроль ада-зависимостей ложиться на мантейнера. Т.о. построить систему, которая без проблем может автоматически пересобраться сама на себе *в любой момент* времени - сложно. (дада, без использования рассылок с просьбами о пересборке как у Альт)

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

ну вот, померялись, как того и просила общественность :)

(за возможные орф. и грам. ерроры - сорри, пишу в спешке без спелчекера)))) )

Алексей Новодворский, Бизнес 

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

Все разработки "Альт Линукс" основаны на Сизифе, с чего Вы пишете что мы это отрицаем, -- просто ума не приложу. Напротив, мы это всегда подчеркиваем.

Наконец, Сизиф открыт, равно как и документация к нему. Хорошо, если Вы делаете лучший продукт. Подождем кода.

Алексей Новодворский, Бизнес 

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

- -, Разное 

Я знаю, рассылка - это хорошая и правильная политика в условиях "общественной" системы сборки, т.к. нет возможности доверять всем кто бы ни комитил.

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

Конечно, АБФ это только 1й релиз, он будет развиваться и мы будем весьма рады любым советам и улучшениям.

Дмитрий Комиссаров, Бизнес 

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

- -, Разное 

Сложно описать АБФ не сравнивая. Но я постараюсь.

Алексей Новодворский, Бизнес 

Андрей, а контроль разрешения "ада зависимостей" на ядре-диспетчере?

Иначе: это просто диспетчер или он добавляет функциональность сборке для любых бекендов?

- -, Разное 

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

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

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

Алексей Новодворский, Бизнес 

Довольно конкретный вопрос, потому если не ответите или ответите приблизительно, то пойму.

В конце нашего документа "Репозиторий СПО" есть подперечень "Конвейеры сборки и тестирования задания, развернутые <...>" .

Вопрос: какие из описанных там операций по сборке и тестированию заданий ABF реализует в
универсальном диспетчере, а какие в бэкендах?

- -, Разное 

Я полагаю, вся документация на по-пунктное соответствие сдаваемых продуктов требованиям будет опубликована по завершению проекта.

Алексей Новодворский, Бизнес 

Я говорил вовсе не о требованиях, а о списке из документа на нашем wiki, там другое. Но на Ваше усмотрение.

Алексей Новодворский, Бизнес 

Более простые вопросы:

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

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

- -, Разное 

Алексей Новодворский писал(а):

Более простые вопросы:

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

Конкретный пакет, некоего репозитория, требуется для сборки другим пакетам. Эти зависимости вычисляются ядром, бекенд только собирает в родной для пакета среде - федорины пакеты, в среде федоры, по правилам федоры, средствами сборки федоры (например mock), мандривные пакеты - в своей родной среде, своими ср-вами сборки. От бекенда требуется сформировать chroot для сборки пакета в его родной среде и собрать все те пакеты которые от него зависят (если эту "галочку" включили).

Алексей Новодворский писал(а):
2. Вы пересобираете те и только те пакеты, которые без пересборки остались бы с неудовлетворенными зависимостями?
Пакеты которые не удовлетворяются зависимостями и не соберутся, конечно - ибо как он это сделает? Или я не понял вопроса. 

Работает так - берется новый пакет на сборку. Вычисляется кто его хочет. (у вас так тоже сделано). И автоматом эти пакеты тоже пересоберуться на базе нового пакета, чтобы выраванился репоз. И так для каждого - т.о. в системе не может иметь место ситуация, когда собраные пакеты и которые лежат в публичном репозе рассогласовались по сборке - что мы наблюдаем практически в любом линуксе. Т.е. бинарно они есть, но собирались в разное время на других версиях которые потом не поднимали и если попытаться пересобрать скажем Федору на репозе "release" то, как ни смешно - ничего не выйдет. Часто эти поломки сборок не связаны с soname, а с кривыми спеками или модификацией конфигов. Что-то не туда переложили, что-то убрали и все - пакеты не собираются, хотя их бинарные сборки (собраные ранее на более ранне пакетной базе в процессе подготовки дистрибутива) - собраны и лежат в релизных репозах.

Попытаться собрать релиз для сертификации - анрил. Все приходиться чинить. 

Разница у нас в том, что хешер показывает, что надо пересобрать дополнительно, а АБФ - собирает сам (если разрешить).

Алексей Новодворский, Бизнес 

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

Алексей Новодворский, Бизнес 

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

Алексей Новодворский, Бизнес 

Андрей, спасибо! Надо и поспать.:-)

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

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

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

То есть для Мандривы такая система есть серьезный шаг вперед, так как BS там самизнаетекакая. Для Debian -- большой вопрос, скорее все же нет. Для Сизифа сами понимаете, -- Вы хорошо изучили нашу систему сборки, что очень приятно.

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

- -, Разное 

Алексей Новодворский писал(а):

Андрей, спасибо! Надо и поспать.:-)

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

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

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

Алексей Новодворский писал(а):

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

Если делать монолитный, то возможно, если делать модулями общающимися через RPC - то нет. Никто не запрещает вынести совсем уж экзотические депендинс-вычислители в их родную среду как и backend. (например деб)

Алексей Новодворский писал(а):
То есть для Мандривы такая система есть серьезный шаг вперед, так как BS там самизнаетекакая. Для Debian -- большой вопрос, скорее все же нет.
Мы изначально планировали делать и это. АБФ строился так, что доработать его можно не сильно меняя структуру. Выше я описал как. Сборка дебов у нас в планах есть - но не на все есть время и наличие производственной необходимости.

Алексей Новодворский писал(а):
То есть баланс между универсальностью и специфичностью, а стало быть и правильную архитектуру, еще надо искать и искать. Возможно, она должна быть трехзвенная. Цитируя Евгения, "это намек ;)"

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

- -, Разное 

2 Алексей Новодворский

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

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

> .... сборки другой платформы в целом нужно портировать на нее hasher. 

Сказать просто. Но на деле hasher (а мы его тоже изучали конечно) сильно.... как бы это сказать, сизифо-зависим. Придется слишком много кода переделывать. Это время и деньги. Вы уже делали такое решение (портировать например для сборки Сузи) или это просто абстрактное предложение. Портировать можно почти что угодно. Вопрос в затратах. 

Наше решение скорее походит на cloud-контроллер, при котором ничего никому не нужно переделывать, а только адаптировать шаблон бэкэнда связав его с любой нативной системой сборки, которая как всем известно, всегда глубоко специфична для каждого продукта. Т.е. "порог вхождения" других продуктов у ABF весьма низок. Приносите свой самовар, мы к нему адаптируем способ подачи воды и варите чай по собственному рецепту. К слову сказать у нас уже это сделано для Nau-linux и прочих RH-клонов. На адаптацию бэкэнда ушло не более 2х недель. Четверть этого времени ушло на освоение документации и примеров.

>Все разработки "Альт Линукс" основаны на Сизифе, с чего Вы пишете что мы это отрицаем, -- просто ума не приложу. Напротив, мы это всегда подчеркиваем.

Пардон, мне сложно угнаться за таким быстрым переключением контекста. Альт-Линукс не имеет отношения к сизифу - вы это лично при мне говорили (ну и писали в инете). Теперь он вот имеет. Что-то уже поменялось наверное. Видимо, слушатели могут интерпретировать это по-разному в разное время. А что имеется ввиду в каждый конкретный момент - контроль ли кода сизифа, независимое наследование кода от сообщества сизифа (ну, например, как мы LXP на федоре делали в свое время) или юридические отношения между сизифом и альтом, этого я увы не всегда улавливал, да и не было серьзной необходимости. Но такие обсуждаемы тут фразы - у вас были. Развейте, плз., эти туманы и люди перестанут путаться :)

>Наконец, Сизиф открыт, равно как и документация к нему. Хорошо, если Вы делаете лучший продукт. Подождем кода.

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

Мы свой ABF делаем за забором, т.к. это более эффективно в услових сжатых сроков. Разумеется, код и покажем и расскажем. Нам же его сдавать Заказчику :). Тогда и сообщество сможет, если захочет - поучаствовать в развитии кода.

Двери открыты всем. Любым производителям любой системы.

Алексей Новодворский, Бизнес 

Из моего ответа Алексею Лиму (не умею тут давать ссылки на реплики, научите, если умеете):

"Про Korinf: это ровно Ваш usecase. Этерсофт как раз собирает небольшое число пакетов под все востребованные свободные системы."

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

- -, Разное 

 >Наверное, Вы меня неправильно поняли, -- я имел в виду, что Сизиф общественный проект, а не собственность Альт.

Вы правы, я вас понял иначе, спасибо за разъяснения!

- -, Разное 

>"Про Korinf: это ровно Ваш usecase. Этерсофт как раз собирает небольшое число пакетов под все востребованные свободные системы."

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

Алексей Новодворский, Бизнес 

Андрей Шубин писал(а):

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

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

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

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

- -, Разное 

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

Денис Сосновцев, Разное 

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

Алексей Лим, Общественные организации 

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

Для меня системы сборки представляется в двух ипостасях:

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

Второй случай может подразумевать:

  • большую социальную ориентированность, например низкий порог вхождения для создания первого стороннего репозитария, богатый возможностями Web клиент, и т.д.
  • здравую толику "meta" для упрощение ведения одного пакета на куче дистрибутивов (как это пытаются сделать в OBS в случае с универсальным RPM спеком, или в Коринфе с "идеальным" спеком)

Разрабатывается ли ABF с прицелом только на первый случай, или система изначально будет универсальная?

Дмитрий Комиссаров, Бизнес 

А какому Денису вопрос ?

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

Денис Сосновцев, Разное 

Полагаю, что вопрос Андрею Ш

Алексей Лим, Общественные организации 

Пардон, вопросы были к архитектору ABF, Андрею Шубину. Хотя было также интересно будет ли НПП стараться отразить оба подхода, полагаю я получил ответ.

Хотя мои вопросы были бы праздными если бы я нашел что-то существенное по ABF в сети. Кажется это, мягко говоря, не совсем правильный подход для реализаций(прототипов) НПП.

Андрей Михайлов, Государство 

Грусто наблюдать как ссорятся уважаемые господа.

Кроме того, я не совсем понимаю зачем нужен ABF государству? Что он ему дает?

Приведу пример из жизни: пришли товарищи и предложили НИОКР по Web 3.0 - хорошая технология, классная, коммуникации тегов. На вопрос, что она дает государству, внятно ответить не смогли. Что технология давала той конкретной компании, я прекрасно понимал. Как и сейчас прекрасно понимаю, зачем нужна ABF сообществу разработчиков Мандривы.

Дмитрий Комиссаров, Бизнес 

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

Андрей Михайлов, Государство 

То есть государство покупает готовую технологию от разработчиков Мандривы, адаптированную под его нужды?

Дмитрий Комиссаров, Бизнес 

ТЗ не читали. Государство обьявило НИР в рамках которого, выигравшие его члены РАСПО, делают прототип в том числе и системы сборки, но основная часть это ТЗ на дальнейшие работы + аналитика. Делают систему если интересно РОСА+ЛИНУКС-ИНК+НЦПР+ЛИНУКС-ЦЕНТР.

Андрей Михайлов, Государство 

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

Денис Сосновцев, Разное 

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

Боюсь, для начала, что людей, которые считают СЕБЯ заказчиками , может и не быть. А, стало быть, не будет у них и понимания более глубокого. Так что мой первый тост : "за заказчика !"

Дмитрий Комиссаров, Бизнес 

Тебе прости неизвестно кто писал документацию этого конкурса?

Единого заказчика да к сожалению нет. Что считает министерство я более или менее представляю. На мой взгляд сейчас важно консолидировать мнение рынка и потенциальных заказчиков, причем включая ФСБ, ФСТЭК, военных.