Роботы

Введение

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

Концепция такой песочницы -- "Quality on demand". Начать с базового сервиса, т.е. предоставлять репозиторий пакетов, а далее обеспечить пользователям возможность делиться с другими пользователями своим опытом с пакетами, т.е. по сути, отмечать результаты тестирования. А майнтайнер песочницы будет чинить пакеты по факту обращений пользователей. Т.е. сделать так, чтобы пользователи участвовали в работе таких песочниц как тестеры.

Зачем все это нужно?

Кризис дистрибутивостроения

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

Вот как обрисовывает ситуацию Ingo Molnar в "What ails the Linux desktop?"

[en] https://plus.google.com/109922199462633401279/posts/HgdeFDfRzNe

[ru] http://www.linux.org.ru/news/opensource/7536825

"... many OSS developers don't realize what a deep hole we are in.

The desktop Linux suckage we are seeing today - on basically all the major Linux distributions - are the final symptoms of mistakes made 10-20 years ago - the death cries of a platform.

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

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

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

Выход, который предлагает Ingo Molnar - брать пример с Android - на техническом уровне, IMHO, это не выход, а очередной не жизнеспособный cargo cult. Сравнение с Android выглядит как сравнение теплого с мягким. То, что там работает, работает только из-за определенной специфики, которой у нас нет и без которой оно не приживется. Но на идейном уровне там есть много здравого, в той части, что связана с ожиданиями пользователей. Хотя это надо еще уметь правильно реализовать. Это IMHO, не хотел бы уклоняться в сторону.

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

Апология роботостроения

Слово в защиту роботов-упаковщиков.

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

История повторяется - до сих пор у нас в рассылке при виде роботов-сборщиков пакетов иногда слышны призывы в духе "робот, поскорее убейся, как Томми". (последний был в марте).

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

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

Также часто всплывает аргумент, что пакеты, сопровождаемые роботом, менее качественные. Здесь логическая ошибка - качественно сопровождаемые пакеты потому и качественные, что на их сопровождение тратится много времени. Когда много времени, то основное время уходит на code review, просмотр тематических рассылок, bug tracking systems, просмотр изменений в других дистрибутивах, пробные сборки, тестирование и т.д. Доля механической работы в сопроводжении такого пакета ничтожна, поэтому при его сопровождении робот вряд ли будет применяться. А если робот применяется, то скорее всего, по другому не получилось бы - просто бы времени не хватило.

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

Разница между количественным и качественным мышлением

Говорят, что когда вожди греков пришли за хитроумным Одиссеем, то их встретили новостью, что три дня назад, еще ДО того, как прибыл вчера от Менелая глашатай с новостями, Одиссей обезумел: запряг осла и вола в плуг, и три дня и три ночи не ест, не пьет, но распахивает поле плугом, и засевает пашню солью. Засевает пашню солью? Явное безумие! Когда вожди греков пришли проверить новость, то картина, которую они увидели, была вполне убедительной с точки зрения качественного мышления. Одиссей не обращая ни на что внимания, мерно шел за плугом и засевал пашню солью. Но был среди греков многомудрый Паламед, хорошо владевший, кроме качественного, еще и количественным мышлением. Он сказал грекам: Смотрите! Пока мы удивлялись Одиссею, он провел плугом уже две борозды. С такой скоростью он за три дня и три ночи давно бы распахал это поле. Тем не менее, он всего лишь успел распахать этот клин, как будто пашет только с раннего утра -- уже ПОСЛЕ того, как пришли ему новости.

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

Что подвело хитроумного Одиссея? Качественно картинка сошлась. А вот количественно - нет.

Вернемся к пакетам. С качественной точки зрения особо не чуствуется разница, сопровождать ли 10, 100 или 1000 пакетов. Допустим, сопровождение 100 пакетов занимает 10 дней в месяц. тогда сопровождение 1000 пакетов должно было бы занимать 100 дней в месяц. Но в месяце 30 дней и это потолок, даже работая на износ с этим ничего поделать нельзя - качественно масштабировать картинку не получится, количественно она не сойдется. Упираемся в физиологический предел. Как если еще пробежать стометровку за 7+ секунд еще теоретически можно, а вот уже за 6 и меньше секунд - никак.

Но можно разумно распорядиться временем. Из Петербурга в Москву можно пропутешествовать пешком за месяц. Или же пролететь за час на самолете в гораздо более комфортных условиях. То же самое и с пакетами. Я свой потолок при работе с пакетами без использования средств автоматизации, вручную, "на зло роботам", оцениваю в пределах 150-900 пакетов, в зависимости от сложности конкретного набора пакетов.

В частности, при ручном сопровождении на протяжении достаточно долгого времени я бы потянул java репозиторий не более чем в 250-300 пакетов. Это достаточно точная оценка, так как последние три месяца я в основном занимался обновлением java репозитория и переездом на maven3. При этом последний месяц это было спасение репозитория бросанием с шашкой на танк - ручной починкой множества сломавшихся обновлением пакетов. Хотя это не было "честным" примитивизмом - я рылся grep'ом в логах beehive, генерировал полуфабрикат своей утилитой srpmnmu и скармливал его hasher'у, и только потом уже правил руками - эти 3 инструмента автоматизации здорово помогли - но эта работа позволила заново прочуствовать и дать достаточно точную оценку затратности ручного труда для пакетов java.

Там нет особых идейных сложностей, не так много гимнастики для ума, но много достаточно надоедливой монотонной кропотливой работы. Отсюда и оценка в 250-300 пакетов.

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

Java - язык достаточно тяжеловесный, многословный, с многоуровневой защитой от дурака, китайского, индусского и русского программиста; изобильным использованием XML где ни попадя; плохой привычкой апстримов, к тому же поощряемой инструментальными средвтвами, собираться с протухшими версиями библиотек - что постоянно приводит к разломам при обновлении.

А что такое разломы?

Тривиальный 10% разлом, требующий в среднем по 10 мин. ручной работы на пакет, при оптимистическом подсчете обошелся бы в 2 полных дня напряженной работы по починке. Но на практике с учетом регрессий и других неприятностей, это 4-6 дней.

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

А серьезный 50% разлом, требующий по часу ручной работы на пакет, обошелся бы теоретически в пол года напряженной работы по починке, но на практике дешевле сразу сдаться и выбросить 1) не пересобирающиеся пакеты (50%) и 2) сильно зависящие от них пакеты (20%-30%). При этом после выбрасывания сборка оставшихся пакетов тоже будет нарушена, но проще и дешевле будет потратить силы уже на починку сухого остатка.

Итог один -  в java репозитории катастрофа и массовое вымирание пакетов :(. При таком разломе от репозитория остаются руины в виде 20-30% того, что было раньше.

Получается, что для java репозитория ручная работа - это Дамоклов меч, что-то вроде мифической звезды Немезиды, которая раз в 60 млн.лет подходит к Земле и вызывает катастрофу. Приятных чувств не вызывает.

Впрочем, это не специфика роботостроения, а именно специфика нашего java репозитория, заключающаяся в том, что по жадности я брал за основу пакеты из наиболее богатого репозитория, JPackage, но эти пакеты относительно низкого качества, и их приходится постоянно в полуручном режиме допиливать. Как говорит турецкая пословица, "Если ты пьешь воду из грязного источника, не удивляйся, если у тебя будет болеть живот". Если бы я брал пакеты только из меньшего, но более консистентного репозитория, например, из Fedora, то в основном пакеты допиливать не нужно было бы, отложенная ручная работа не накапливалась бы, Дамоклов меч над java репозиторием не висел бы. (Есть надежда, что так в будущем и будет: Fedora сейчас стала активно развивать свой java репозиторий без оглядки на JPackage).

Чтобы проиллюстрировать тезис о консистентном репозитории, обратимся к Fraus Magnum, к статистике. Согласно подсчетам, за период 1 Jan 2012 - 31 Mar 2012

$ rpmlsmonthchangelog --user viy --min '1 Jan 2012' --max '31 Mar 2012' \ /ALT/Sisyphus/files/SRPMS | egrep '(jpp|java|jpackage)' | wc -l     872

За этот период я все бросив, занимаясь только java, и, как Одиссей, ни на что не отвлекаясь, с титаническими усилиями отправил в incoming 872 java пакета. В то же время, сам удивился, общее число залитых за это время пакетов составляет 2093.

$ rpmlsmonthchangelog --user viy --min '1 Jan 2012' --max '31 Mar 2012' \ /ALT/Sisyphus/files/SRPMS | wc -l    2093

Т.е. 872 пакета с титаническими усилиями, и около 1200 пакетов незаметно для себя, почти без усилий. Что это за странные пакеты?

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

При таком применении он демонстрирует потрясающую пиковую производительность: тестовое множество недостаточно большое, чтобы точно ее измерить, но можно говорить, что речь идет, как минимум, о повышении производительности в 50-100 раз.

При работе с роботом время расходуется на

• разработку робота
• сопровождение робота
• сопровождение пакетов (тонкая ручная подстройка).

Для fedoraimport сопровождение пакетов (тонкая ручная подстройка) занимает достаточно мало времени. С другой стороны, все свободное время я вкладываю в его разработку. Уже удалось научить его достаточно уверенно работать с кодом на С/С++. Далее планируется подружить его с переупаковкой подпакетов модулей и обвязок для большой тройки Perl,Python,Ruby.

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

Даже для такого не самого хорошего случая это означает, что одним jppimport'ом выполняется работа филиала из 5-6 человек. Да, эти виртуальные люди гораздо тупее реальных, но зато и гораздо более выносливы, упорны, исполнительны.

Как пример, wrar@ давно уже ушел из Team, а cronbuild, как верный пес Хатико, уже полтора года все собирает и собирает его пакет fortunes-ALT-irc.

Академик Глушков говорил, что у человеческих возможностей свои пределы: так же, как невозможно руками поднять 10-тонный булыжник, так же нельзя прочитать все книги в библиотеке им. Вернадского (ЦНБ, аналог Ленинки в Москве). Надо знать свои пределы и не надо их стыдиться.

Также и с нами. Пользователи хотят, чтобы "все работало", т.е. если уже ALT предоставляет свой ABI, то должен и опакечивать все используемые ими приложения под этот ABI. А имеющихся сил не хватает и на сопровождение того. что уже сопровождается. Роботы могут залатать этот разрыв, добавив к Team сотню-другую виртуальных майнтайнеров.

Сто дуболомов - это же армия! С такой армией Урфин Джюс брал Изумрудный город :)

Хотелось бы назвать данное письмо "Похвала роботам". Увы, пока это "Апология", слово в защиту.

Откуда берутся роботофобии? Впрочем, нет ничего нового под солнцем.

Процитирую Торстейна Веблена, его "Теорию праздного класса":

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

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

В современном промышленном обществе дешевые, а потому не соответствующие внешним приличиям предметы повседневного употребления обычно являются продуктами машинного производства; и общей характерной чертой товаров, изготовленных машинами, по сравнению с предметом, сделанным вручную, является их значительно более совершенная обработка и большая точность в детальном исполнении замысла. Следовательно, будучи престижными, явные несовершенства сработанных вручную товаров оказываются признаками большей красоты или полезности этих товаров или того и другого. Отсюда и возникло то возвеличивание несовершенного, с которым в свое время так горячо выступали Джон Раскин и Уильям Моррис. И на том же основании их пропаганда всякой незавершенности и расточения сил была подхвачена и донесена до наших дней. А отсюда и пропаганда возврата к ремесленному труду и домашнему промыслу. Как же много из того, над чем работали и размышляли эти люди и что вполне подходит под характеристику, которую мы даем описываемым явлениям, было бы невозможным в те времена, когда еще не было такого положения, чтобы явно более совершенные товары стоили дешевле." <a href=http://sociology2015.ru/index/0-85>развитие семьи как социального института</a>

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

<a href=http://sociology2015.ru/index/0-8>школа как социальная организация</a>

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

<a href=http://sociology2015.ru/news/2013-09-01-48>социология учебник 2013</a>

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