Хранилища, дистрибутивы и свободное лицензирование
У нас сегодня большая плотная лекция, потому что сегодня надо упихать две темы вместо одной и обе очень важные.
Давайте начнем с оснований того, почему вообще… начнем как у Канта: как возможны априорные синтетические суждения: как возможно вообще понятие дистрибутива: вот мы взяли что-то такое, установили себе на компьютер и оно работает. В результате чего, какие основания положены в... с чего начинать? Как получилось так, что у вас операционная система, которая состоит из нескольких тысяч пакетов установленных и десятков тысяч в загашнике и все это работает друг с другом? Кто тот человек, который все эти программы запрограммировал? Хорошо, кто все эти люди и как они организовались и кто их начальник, эффективный менеджер? Все эти вопросы содержат в себе неправильный ответ заранее. Корень вот какой, смотрите: чуть ли не на первой лекции я рассказывал о таком эпохальном расколе, когда фактически программная разработка и последующее бытование программных продукта разделились на два практически непересекающихся мира, временами они так друг с другом взаимодействовали, временами переставали, в общем, практически не пересекающихся. Один из таких изводов занимался открытой разработкой, т.е. ситуация воспроизводила ситуацию, которая была до этого: такая университетская разработка, у нас есть какие-то программы, мы их все совместно пишем, мы друг с другом делимся текстами, вот это вот все, а другой эффективный, на самом деле, инструмент состоял в том, что мы внезапно осознаем, что мы продавая экземпляр программных продуктов можем делать много денег. Собственно, об этом было известное письмо Билла Гейтса, о нем даже есть отдельная страница в википедии, которое говорит «Ну зачем! Мы тут упарывались как кролики, написали этот бэйсик, а вы тут его просто так копируете друг другу, а между тем вы мешаете нормальному бизнесу, вместо этого вы бы сами могли написать какую-нибудь программу и ее продавать».
В чем, собственно, бонус, когда вы организуете бизнес, состоящий в продаже копий программного продукта? Предположим, вы хотите организовать бизнес … Вообще, откуда взялись деньги? Деньги же это товарный эквивалент, да? Деньги - нечто, что участвует в схеме товар-деньги-товар, предназначенное для того, чтобы потерявшее универсализм человеческое сообщество, называемое город, могло сосредоточиться на профессионализации областей деятельности, например, вы горшечник и вы изготавливаете горшки. Как устроен ваш бизнес: вы тратите какие-то свои ресурсы, ну, например, покупаете у землекопа или ездите куда-то за город и самостоятельно копаете, получаете глину. Значит у вас: один горшок - это одна мера глины + оплата вашего труда, труд будем измерять в трудах.
1 горшок = 1 глина (мат.расход) + 1 труд (расход чел. труда)
Как эта штука масштабируется? Это был 1 горшок:
10 горшков = 10 глин + 10 трудов
Потому что для того, чтобы сделать каждый горшок, нужно взять кусок глины, сесть за гончарный станок и давай его лепить в течении какого-то времени. В чем состоит бизнес у горшечника? Он состоит в качестве вот этого вот труда. Включим сюда ваши изыскания по подбору глины, вашу рецептуру, вот это вот все. То есть, есть какой-то расходный материал и сами эти материалы сколько-то стоят и они стоят столько, сколько они стоят, и есть какой-то ваш труд, который вы фактически продаете: рынок оценивает ваш труд, то есть если у вас есть горшок, вы продаете его за столько, за сколько люди согласны доплатить к одной глине, если бы они не были бы согласны - они бы сами сделали. Вот такое масштабирование. Собственно на этой примитивной арифметике зиждется вся денежная система, по крайней мере, зиждилась до тех пор, пока не произошли кое-какие изменения в ней, и по большей части с этой же примитивной арифметикой связано и законодательство: опять таки, лет 10-15 назад оно обслуживало только эту схему и больше никакую.
Почему такая штука?
Если кто-то захочет из этих 10 горшков у вас взять 1 - он тем самым лишает вас глины и времени которое вы потратили: он должен вам оплатить и то, и другое. Так происходит дело с материальными объектами. С нематериальными объектами ситуация немножко иная: допустим, мы написали программу.
1 экземпляр программы состоит из 1 труда (программист его писал) , а какие тут расходные материалы - не очень понятно. Допустим, вы продаете программу на флешке. Какой-то расход есть, ну, напишем флешка: это какой-то достаточно материальный объект чтобы его оценить и достаточно недорогой, чтобы не пытаться увидеть там какой-то страшный расход чего-то там. Мы включим туда же амортизацию сервера, вот это все, оплату электроэнергии...
1 экз. программы = 1 труд + 1 флешка
10 экземпляров программы: тут у нас 10 флешек, да, упс, а труд по-прежнему один.
10 экз. програмы = 10 флешек + 1 труд
Нематериальные объекты обладают свойством безущербного копирования, то есть копирования, которое не наносит прямого ущерба материального владельцу. Если вы, допустим, съели яблоко - вы больше его не съедите, да, а если вы написали программу - это как типа у девушки есть нечто, она это продает, у нее снова есть это нечто. Так и здесь: от того, что вы пользуетесь программой она хуже не становится, она даже в какой-то степени лучше становится, об этом мы сегодня поговорим. Неубывающая предельная полезность.
Не было ничего более глупым, как попытаться натянуть на эту явно иную с точки зрения арифметики и в первую очередь с точки зрения человеческого участия в процессе схему стали товарно-денежные отношения вида «товар-деньги-товар». Стали придумывать какие-то совсем волшебные штуки типа того, что вот, мол, «вы у нас украли нашу программу и мы будем оценивать, сколько мы не продадим экземпляров из-за того, что ты эти экземпляры у нас стянул». Это напоминает процесс 35 года, когда человек украл мешочек зерна, за это нельзя было посадить, тогда считали что будет, если это зерно посеять все, вырастить, сжать - все равно не хватало до высшей меры - еще раз вырастить, сжать - вот тогда можно. Как это называется - упущенная выгода.
Это надо всегда хорошо иметь в виду: когда вам впаривают о компьютерном пиратстве, о компьютерном воровстве - дело разговора исключительно об упущенной выгоде. Вот покажите мне реального творца, поэта, программиста, который кричит на каждом углу, что у него украли. Музыканта, который кричит, что у него украли. А украл кто? Издатели: люди, которые получают эту выгоду и для которых эта упущенная выгода - просто кровь.
Здесь я не буду вдаваться в подробности относительно механизма патентования - он здесь тоже причем, скажу только что патенты на сегодняшний день практически не работают если нет материального производства, патент нужен тогда, когда нужно существенно большое время на раскрутку... у нас вместо патентов - стартапы, которые живут полгода-год, если ваш стартап за год не раскрутился - вы берете новый стартап. И год, на самом деле, это очень много, потому что как часто выходят новые версии программных продуктов? 3 раза в год - нормальная частота. Если вы за один квартал не смогли свои бизнес-преимущества в вашем айтишном деле мотивировать - значит у вас какие-то проблемы, на самом деле, или вы монополист на рынке и вам пофигу. Там, где идет настоящая конкуренция - там днями измеряется, неделями максимум. А все вот эти вот "25 лет на патент»...
Короче говоря: вот этот нехитрый трюк подразумевания того, что тут было 10 трудов и, соответственно, совершенно другой оценке материального продукта и позволяют людям, торгующим копиями, в рамках текущей экономической системы, которая до сих пор по человечески не изменилась, получить гиперприбыли и платить с них гиперналоги. На самом деле отношение к творческому продукту как к материальному продукту со всеми вытекающими, вообще говоря, имеет только правовую поддержику, а здравосмысленную не имеет. Опускаю здесь момент относительно вознаграждения творцов потому что есть на сегодняшний день много площадок, где вы можете это сделать: кикстартеры, патреоны, круги, в конце концов. Ситуация, когда автор творческого продукта собирает деньги на имеющийся продукт, всякие донейшоны, либо собирает деньги на старт, если это программный продукт, эти ситуации оканчиваются успехом и, заметьте, безо всяких официальных механизмов в обществе.
Вот этот трюк связанный с продажей нематериальных ценностей по принципу материальных на долгое время обеспечивал исторически второму способу закрытой разработки ограниченного информационного пространства конкурентное преимущество перед способом первым. На самом деле, если посмотреть непредвзято и на секундочку поверить в то, что эти 2 по разному организованных бизнеса… у них нет проблемы с деньгами. На самом деле эти 2 способа - один удобнее - другой нет. Если у вас нет проблемы с ресурсами, предположим, они бесконечные или условно бесконечные - это, конечно, идеальное предположение, но, тем не менее - то ситуация закрытой разработки, когда у вас строго ограниченное информационное пространство, потому что торгуя копиями вы боитесь утечки чего-либо, что позволит этим копиям подешеветь: например вашу идею украдет ваш товарищ, он от вас отвернется, организует свой бизнес и с учетом того что это информационное производство - нематериальное - через пол года он вас забьет ногами, или, по крайней мере, станет вашим конкурентом, если главная идея ваша утечет, пол года ему хватит на все. И закрытое информационное пространство: это значит, что внутри этого информационного пространства, то есть допущенных к исходному коду очень малое число, круг разработчиков таких штук он невелик. Ну, хотя бы относительно невелик - мы понимаем что в крупных компаниях проприетарных тысячи людей работают, но эти тысячи людей - каждый знает небольшой кусок, на самом деле, полное информационное пространство недоступно никому. И поскольку бизнес, связанный с торговлей экземплярами - бизнес связанный с торговлей экземплярами, а вообще говоря даже не с программированием, выясняется, что у всего процесса производства программного продукта меняются цели. То есть когда вы идете наверх в хедквотер, вы понимаете, что там абсолютно все равно, разливаете ли вы пиво или торгуете софтом. Потому что есть понятие рынка, есть понятие таргетирования, в общем, идея свободной разработки практически прекращается, особенно в ситуациях, когда выясняется, что надо очень сильно ограничивать эту свободу.
Всегда, если мы имеем дело с закрытым бытованием ПО, всегда есть конкретный владелец, который устанавливает права распространения, и эти права распространения, как правило, очень ограничены: раньше просили деньги за экземпляр, теперь просят деньги за пользование на определенный срок. Кто говорил о неограниченном ресурсе? В программу можно заложить ограниченность - раз, и через год она у вас просрочится.
То есть возникает противоестественная ситуация, когда потребительские качества продукта ухудшаются просто для того, чтобы этот бизнес поддержать на плаву.
В противовес этому, открытый способ разработки выглядит более удобным для разработчиков: мы имеем возможность открывать наше информационное пространство, привлекать к разработке кого угодно, кому интересно этим заниматься - не нанимать индусов по 3 рубля кило, а нанимать тех людей, которым это интересно. Из этого следует 2 забавных свойства:
Первое свойство - свободная разработка, как правило, делается комьюнити: это такие организации человеков, которые самоорганизовались, во-первых, строятся по принципу свободы вхождения - свобода входа, свобода выхода, свобода мотивации. Если ты впрягаешься в какую-то открытую разработку - вообще говоря, никому не важно, то есть, конечно, очень важно, но нет разницы, зачем ты это делаешь. Ты можешь хотеть стать чемпионом мира по написанию кода: окей, если это хороший, годный код - почему бы и нет? Ты мог хотеть просто заработать, тупо взять, программу доделать, и благодаря этому что-то заработать - окей! Ты можешь быть жутким лентяем и хочешь, чтобы програма делала все за тебя, и поэтому ты ее дорабатываешь - шикарно, один из самых лучших видов мотивации. Ну, как известно, человек ведь не должен работать, человек должен думать, а работать должна программа.
Но вот эта свобода мотивация накладывает довольно специфический отпечаток на методы ведения бизнеса, связанного с открытой разработкой, и, соответственно, на методы административного управления, менеджмента. И менеджмент свободных проектов сейчас находится на состоянии чуть выше стартового. То есть уже до народа стало доходить, что это вообще отдельная тема, но не дошло, что это нужно делать по-человечески. В общем тем, кому лавры Билла Гейтса, как гениального менеджера, покоя не дают - имейте в виду, что эта площадка правовладельческая уже изрядно истоптана и уже из нее выжимают такие вещи, как деньги за подписку, анализ рынка, вот это вот все. А как менеджить свободные проекты - никто не знает, то есть это до сих пор находится на интуитивном уровне. Посмотрите на всех лидеров свободных проектов: они в своем роде гениальные менеджеры, но как они это делают - они этого не покажут. Ну, там, линукс какой-нибудь, Гвидо, какой-нибудь, Дима Левин (это наиболее статусный человек у нас в комьюнити). Такие вот дела. И главное, что свобода распространения ПО, лишенное всяких ограничений - условие успешности такого рода бизнеса. Потому что если наш продукт не может быть свободно распространен и установлен - мы не получим правильного фидбека.
Прежде, чем рассказать, как устроен бизнес, давайте разберемся со свободным лицензированием. История уходит глубоко в 80е, когда некто Ричард Столлман, известный хакер, работающий над всякими штуками, внезапно обнаружил, что тот код, который он написал, ему не принадлежит и уволившись с того места работы, где он его разрабатывал, не имеет права в него заглядывать, вообще говоря, и помнить его не имеет права. Он хотел его всего лишь напечатать, он даже не хотел продать его отдельно от своей работы.
То есть это все оно же, безущербное копирование: копирование-то безущербное, а вот ограниченное право распространения - вот нельзя и все. И задумался он над тем, чтобы так же, как любой товар сопровождается тем, что называется лицензией в Америке, что у нас называется немножко по-другому, чтобы помимо правовладельческих, ограничительных соглашений, которые в первую очередь ограничивают ваше право на распространение программного продукта, а в случае некоторых стран, еще и на условия использования этого продукта. Ну, скажем, по российскому законодательству, кажется, вам еще не могут навязать какое-то ограничение на пользование продуктом, если вы владелец экземпляра - вы им можете пользоваться как хотите, а иногда бывает в некоторых странах по-другому, законодательство устроено так, что вам могут написать, мол, только в полосатых трусах вы можете садиться за мои программы, а не в полосатых - не можете. И вы должны с этим согласиться, либо не пользоваться программой. Так вот: плодом размышления Столлмана была свободная лицензия, которая называется GPL, а пока поговорим про определение свободного ПО, которое от Столлмана выглядит очень разумным и весьма адекватным в смысле понимания его нормальным человеком.
Свободное ПО, и, соответственно, свободная лицензия - по Столлману - лицензия, включающая в себя 4 пункта, 4 «свободы», но в русском переводе принято говорить «права»:
- Право использования - гарантируется конституцией: если вы владелец экземпляра программы - вы можете делать с программой, что хотите, даже домашнее копирование, например, бэкапнуть на случай порчи, правда, кажется, вот эту вторую копию запускать нельзя, ну, не важно. Смысл вот этих 4 свобод состоит в том, что они ничем не ограничены, за исключением уголовного кодекса: если вы эту программу запускаете, чтобы устроить теракт - то нельзя ее запускать, и то, только потому что нельзя устраивать теракт, а не нельзя запускать программу. Или эта программа у вашего соседа тырит трафик или наматывает на его счетчике ваши киловатты. Ее запускать-то можно, но нельзя у соседа тырить трафик. А во всем остальном - неограниченное право.
- Право изучения и внесения изменений: при текущем положении дел это требует, опять таки, без дополнительных условий, неограниченное право изучать программный продукт и вносить изменения, в столлмановском варианте написано «улучшать»: понятное дело, что любое изменение - это улучшение, но нет. Смотрите: при нынешнем состоянии дел в программировании - это разговор о доступе к исходным кодам. Вам должны быть доступны исходные коды, вы можете в них невозбранно глядеть и невозбранно что-то делать. Возможно, в далеком будущем, появятся другие способы создания нематериальных ценностей, при которых не будет исходников, а есть что-то другое, я не знаю, ну, например, для системы скретч понятия исходных кодов вообще говоря нет, потому что в скретче есть такие объекты, которые живут в памяти скретч-машины, а исходные коды - одна из форм их представления, причем, как я понимаю, не полная. Полной информацией о том, что происходит с вашим объектом, обладает только машина, а исходник - только один из компонентов. Но это скорее усложненный случай, чем какой-то иной. Но, я уверен, что, например, когда изобретут телепатию - исходники не понадобятся. А еще есть нейросети, и если вы хотите свободно лицензировать свою нейросеть, то вам нужно под свободную лицензию выписать не только сеть, но и обучающую последовательность, иначе получится, что там будут какие-то таинственные знания.
- Право распространения копий: очень важное для ведения бизнеса и очень важное для сохранения эффективности открытой разработки. Программой будет пользоваться как можно больше людей в случае, если они имеют на это право. Напоминаю еще раз: все эти права не ограничены ничем, кроме нарушения других законов, никаких дополнительных клауз сюда вставлять нельзя, иначе это будет несвободная лицензия.
- Право распространения изменённых версий с улучшениями, которые вы туда внесли - главное для ведения любого бизнеса. Это уже, собственно, пойнт, относительно которого вы можно организовать собственный бизнес. Потому что, если вы видите свое бизнес-преимущество в переводе на русский - то, переводите и давайте как-то это дело монетизировать. И нигде не написано, что вы не имеете право это продавать. Совсем нигде. Конечно, вы имеете право это продавать, ну, с некоторой оговоркой, что доступ к исходному коду вы имеете.
Вот такая четверка образует т.н. разрешительную свободную лицензию, коих на свете так, порядка сотни. Самая известная из разрешительных лицензий - лицензия MIT, она же BSD, ну и всякие такие. Что может включаться помимо этих пунктов? Например, может включаться сохранение авторства: здесь нигде ничего не говорится об авторском праве, следует различать его и право на распространения. Автор всегда является автором.
В чем достоинство свободной лицензии? В первую очередь в том, что человек, получая на руки копию программного продукта, он сразу представляет что с ним делать: там трудно прочитать не так. И, в частности, организуется такой задел, чтобы открытая разработка продолжала работать, люди приходили в сообщество, люди работали и они чувствовали, что никто на них не может наехать. Вот мне учителя в школе очень часто говорили: «А вот эту вашу программу Линукс можно поставить? Мне Билл Гейтс за это не будет миллионные штрафы требовать?». Вот когда у нас был проект «Линукс в школах», вот ровно так было. Нет, не будет, и это написано черным по белому в бумажке, которая сопровождает эту программу.
В чем главный недостаток разрешительной лицензии - недостаток именно в плане ведения бизнеса. Будучи когда-то разработанной, в том числе в расчете на то, что я сейчас скажу, эта лицензия позволяет следующий способ ее применения: берем свободный код, дорабатываем его, пользуясь правом (но.3), и распространяем его под несвободной лицензией. Вообще говоря, никто не запрещает это делать. Люди, разрабатывающие свободные лицензии рассчитывали на то, что а) человек будет сознательный - если ты паразитируешь на открытом по, постоянно берешь его, дорабатываешь и продаешь копии - тебе никто не будет помогать, ты будешь один на базе. И каждый раз, когда будет выходить новая версия, ты будешь туда свое бизнес-преимущество дохакивать и продавать, ну, продавать-то ладно, продавай на здоровье, и потом это распространять без распространения исходных текстов. Это можно, но в каком-то смысле глупо, хотя, практика показывает, что не очень глупо. Есть множество примеров открытого и, видимо, еще большее множество примеров неявного использования свободных лицензий и свободно лицензируемых программных продуктов таким образом. Например - это tcp/ip стек в винде.
Для многих людей это стоп фактор - ну, типа, я все написал, а какой-то там Вася Пупкин возьмет, и будет мою программу продавать без меня. Вот сюда вносить изменения очень не хочется, чтобы не потерять сообщество, поэтому вносятся дополнительные требования, которые называются Copyleft
Copyleft - это такой пан, слово копирайт - копилефт, одновременно это же можно перевести как потерю права на регулирование права на копирование. Потому что самая общая форма копилефта - распространение производного продукта только под лицензией, включающей в себя пункты 0-4, такая рекурсия. Это означает, что если вы берете исходный код - то, что у вас получается, должно включать в себя как минимум 5 пунктов. За это копилефтную лицензию называют вирусной: то есть, если ты использовал копилефтный код, то твоя программа тоже должна быть копилефтной, все.
В российском правовом пространстве все это валидно, мы в 2004 году выпускали сборник терминов, связанных с этим, и он даже неплохо прошел, есть даже термин «Свободное ПО». В мировом масштабе помимо free software еще используется opensource software - это другой комплект определений, их там 10 клауз, за авторством Эрика Рэймонда, и они немного более мутные. Рэймонд со Столлманом воюют, махая огромными окровавленными дубинами, кто из них более прав, это очень смешно, оба прекрасные ребята, симпатичные дядьки, но когда они начинают говорить друг про друга - у них что-то меняется в лице и, как бы, интересность изложения резко падает, но что поделать.
После такого, более аккуратного анализа выясняется, что opensource licence и freesoftware licence примерно эквивалентны друг другу, довольно часто можно встретить такую аббревиатуру - free opensource software, все валят в огромную кучу, и это, в общем-то, нормально.
Давайте теперь перейдем ко второй части нашего разговора, вторая тема - собственно, почему то что, я сейчас рассказал вообще является основанием для создания каких-то операционных систем? В принципе, это тема нескольких лекций, но давайте я попробую по верхам. Поскольку у нас главным организующим сообщество фактором является свобода мотивации и общее дело, то есть, люди к нам приходят, когда им интересно делать то, что мы делаем, или выгодно, или еще чего-то, но мы делаем вместе с ними общее дело, ну, разрабатываем какую-то программу или сборник программ, то очень важно, чтобы эти люди контактировали между собой и чтобы они могли вносить в общее дело столько, сколько они могут.
В общем, поскольку главный принцип - свобода мотивации, то в принципе работает социальная технология которая называется технология малых и средних групп. Если речь идет о программном продукте, а не о чем-то огромном, например ядре, как устроено любое свободное сообщество? Не важно чем оно занимается, программированием, конструкторством, клеит модели - не важно. У нас есть организующее начало общее дело, возможно, у нас есть формальный глава, пожизненный добровольный диктатор, человек, который берет на себя принятие решений в спорных случаях, но это необязательно, это опцион - есть масса сообществ, в которых диктатора нету, а главная движущая сила сообщества - ядро, на языке технологии малых групп - актив. Ядро, как правило небольшое - 7±2 - люди, которые должны между собой договориться, люди, чей профессионализм позволяет строить стратегические планы и не принимать стратегически неправильных решений, люди с хорошим статусом в сообществе, их уважают, к их мнению прислушиваются, и это люди, которые посвящают все свое время работе над проектом, потому что уж наверняка при таких входных данных им за это платят. В сообществе libc долгое время управлял человек Ульрих Дреппер, который по основной профессии был директором какого-то банка, а этим занимался так, по фану, но очень жёстко занимался. В общем:
- стратегия
- профессионализм
- ядро: 7±2
Второй уровень - просто разработчики, а в случае дистрибутива - это сопровождающие или майнтейнеры. Что это за люди? Во-первых, их в 10 раз больше, это люди, которые переодически но довольно регулярно вносят свой вклад в общее дело, например, они используют продукт на работе, они находят какие-то ошибки, фиксят их и дорабатывают, если им там чего-то не хватает.
В терминологии малых групп - это люди, которые например участвуют в совместных мероприятиях, которые готовы помочь трудом, которым интересно заниматься общим делом.
И третий уровень людей, которые принимают участие в процессе - активные пользователи, в терминах технологии малых групп - аура, их еще примерно в 10 раз больше. Это пользователи, которые установили линукс, разбираются в нем, если они нашли что-то, что им нужно - они обращаются к разработчикам и вообще они внутри этого информационного пространства. Примерно так устроено любое свободное сообщество, а в первую очередь по разработке программного продукта, потому что это собственно то, почему в 80-е годы проприетарный способ разработки рулил на 100%, а сейчас уже и не очень. Потому что информационная связность и технологическая состоятельность позволяет привлечь к процессу практически кого угодно, людей со всех уголков земного шара, лишь бы у них интернет был. Типичное производство программного продукта включает в себя обязательно американца, европейца, китайца, русского-литовца-украинца-беларуса, То есть людям даже необязательно встречаться, они возможно даже друг друга не знают, лишь бы у них было общее информационное пространство.
Тут, конечно, уместно было бы продолжить разговор про информационное пространство, а закончить разговор дистрибутивами и хранилищами. Основное условие существования всего этого безобразия - информационная связность. Предположим, на дворе 80е-90е годы, люди даже тогда занимались свободной разработкой, только распространяли свой продукт на ленточках на конференциях, приезжали на конференцию, там тусили, обменивались ленточками, вот это вот все. Сейчас же мало того, что все это можно выложить в интернет, если ты не владеешь дисциплиной разработки с помощью какого-нибудь там гита - ты не квалифицированный программист. Ну сидит дома, кодит что-то у себя на коленке - ок, но для того, чтобы работать в команде, ты должен уметь пользоваться распределенной системой контроля версий, гит, не знаю.
Весь процесс разработки уже сейчас ориентирован на работу в распределенной команде.
Информационная связность и технологическая поддержка:
- Совместная разработка: инструменты совместной разработки начиная с того же гита и заканчивая всякими нужными штуками очень сильно подпитывают открытую разработку как таковую: пришел, принес свой патч, он вошел в апстрим, все, ты разработчик. Никто у тебя не спрашивает ни пол, ни возраст, ничего - годный патч - отлично.
- Общее информационное пространство: всякие вики, ресурсы хелпов, которые все вместе делают.
- Багтрекер в случае совместной разработки программного продукта. Для тех, кто возможно здесь не в курсе - это такая информационная система, когда активный пользователь, ну, кстати, разработчик - тоже активный пользователь, видя какую-то ошибку в программном продукте по специальному достаточно жесткому протоколу ошибку фиксирует, уведомляет о ней разработчика, предлагает решение и вносит свой вклад. Это похоже на систему учета билетиков, ну, в общем, ошибка распространяется, у нее есть открытый цикл, ее открыли, признали, пофиксили, ее протестили, что она пофикшена, закрыли.
- И тут мы переходим к последней части разговора: организация хранилища. Это очень важный технологически совсем не простой вопрос и именно он обеспечивает какие-то ответы на вопросы, которые мы задали в самом начале: кто написал и как так получилось, что наш линукс, состоящий из тысяч пакетов устанавливается и работает. Немножко становится понятно из этого изложения, почему открытая разработка и обеспечивающее ее свободное лицензирование необходимо для того, чтобы проект по созданию операционной системы вообще сработал. Сделаю замечание: в случае, если речь идет о разработке одного конкретного продукта - разработчики - люди, которые его доделают, исправляют и все такое. Если речь идет о создание комплекта продуктов - дистрибутива - большая часть того что делают разработчики - делают разработчики апстрим, разработчики исходных программных продуктов. Либреофис пишется в команде либреофис, а человек, который делает так, чтобы либреофис работал на линуксе, возможно вообще не входит в сообщество либреофис, даже скорее всего его не разрабатывает. Часто бывает, что человек, который оформляет программный продукт к помещению в дистрибутив - он же и разработчик, например, редхат разработчик многих вещей, альтлинукс тоже разработчик некоторых ключевых вещей, дебиан, в общем, так бывает, но основная позиция следующая:
Есть понятие upstream - ну это то, что называется «авторы». Допустим вы майнтейнер и вы как майнтейнер должны понимать, что в принципе авторам продукта все равно, как это работает в вашем дистрибутиве. А еще если он не члены вашего тима - почти наверняка есть какие-то соображения идущие в разрез с тем как принято оформлять в вашем дистрибутиве программный продукт. Например, дебиан, там у каждого программного продукта должен быть мануал пейдж. Многие этого не делают и дебиан пишет ман сам.
Поэтому надо понимать, что у авторов, у апстрима цели не такие, как у майнтейнера.
Maintainer - адаптирует написанный под свободной лицензией другими людьми программный продукт, обеспечивает распространение программного продукта. Вот такие две роли, почти всегда это выглядит так: доработка и забота о том, чтобы в рамках хранилища этот продукт работал, в том числе в виде пакета.
Кстати, необязательно только в виде пакетов, когда-то было именно так: хранилище было помойкой, куда майнтейнеры складывали свои непонятно где собранные пакеты, которыми люди пытались пользоваться. Именно поэтому большинство таких установщиков пакетов с историей, например, rpm, до сих пор умеют устанавливать пакеты из исходников: команды установки пакета из исходников и команды установки пакета из пакета - одна и та же команда, чисто формально, код там разный. Потому что в те времена, когда никакой инфраструктуры хранилища не было, иногда было реально проще собрать все из исходников, по крайней мере, оно у вас на машине заработает. Даже если это только так, было бы неплохо этот пакет подписать электронной подписью, чтобы гарантировать безопасность его содержимого, чтобы если его кто-то взломал - было понятно, что это майнтейнер.
Таким образом если у вас внезапно выясняется, что вы ставите пакет у которого с подписью какая-то фигня - может быть, это не годный пакет. Теперь, для того, чтобы этот пакет работал хорошо в рамках других пакетов - необходимо чтобы были удовлетворены зависимости, причем зависимости на тот самый набор пакетов, которые в данный момент, в тот момент, когда вы помещаете туда свой пакет, находятся в хранилище. Требование немножко бредовое, если не вспомнить, что все современные дистрибутивы, которые распространяются в виде бинарных пакетов, устроены так что пакет майнтейнер сам у себя на машине не собирает вообще никогда. Пакет собирает специальная сборочница.
Сборочница - инструмент воспроизводимой сборки (то есть вы затолкали туда все нужные данные для сборки пакета, дернули ручку - получился пакет, еще раз затолкали туда все нужные данные, дернули ручку - получился абсолютно такой же пакет, отличающийся только временем сборки) воспроизводимое окружение (это значит, что для того, чтобы собрать ваш пакет, были установлены конкретные версии конкретных пакетов и для того, чтобы это сделать в следующий раз, были установлены конкретные версии конкретных пакетов, если они не изменились), цельность: по зависимости, допустим вы собираете в хранилище новую версию библиотеки, а все пакеты собраны со старой. Если прямо так взять и бухнуть туда новую версию вашей библиотеки - все старые пакеты перестанут работать, ну, предположим, что новая библиотека настолько отличается от старой, что ее использовать в качестве замены старой нельзя, если вы просто бухнете новую версию библиотеки, потому что вы собрали самую новую, самую свежую версию хранилища - вы все сломаете. В альтлинуксе уже лет 5 так не происходит, потому что инструменты, которые лежат на стороне сборочницы, проверяют: а что будет, если собрать ваш пакет и попытаться его установить, и все пакеты, которые от него зависели, они вообще будут устанавливаться или нет? Вы не сможете поместить в нормальное хранилище пакет, который эти зависимости ломает. Что нужно сделать: нужно также пересобрать и все пакеты, которые ломают ваш: то есть, если вы помещаете какую-то библиотеку, нужно пересобрать также и все пакеты, которые должны быть собраны с новой версией библиотеки. В принципе это очень несложно, не смотря на то, что звучит страшно, потому что, возможно, в них не нужно делать никаких изменений, просто пересобрать. Тут, правда, есть одна проблема, проблема состоит в следующем. Предположим, апстрим вам гарантирует, что он собрал новую версию библиотеки, которая абсолютно не конфликтует со старой. Вы поверите на слово апстриму или будете проверять, а если будете проверять, то как? Общий ответ - да никак, потому что в принципе проверить голословное утверждение апстрима невозможно. Некоторые апстримы делают с точностью до наоборот: они вообще забивают на совместимость, выпускают новую версию и говорят: это новая версия библиотеки, так, на всякий случай удалите старую, поставьте новую, ничего не знаю. Но на самом деле хочется более тонкой манипуляции. Если речь идет о библиотеках, то возможен вот какой ход: давайте в рамках всего репозитория создадим список имен (функций), которые эти библиотеки предоставляют, и будем отслеживать не только зависимости, которые пальцами вписаны в спектр пакетов, но и множество предоставляемых символов. Мы собрали новую библиотеку, она предоставляет некоторое множество символов, сравнимое с множеством символов, которые предоставляет старая библиотека. Предположим, они равны, окей - это значит, что мы можем новую библиотеку вместо старой класть и если все сломается - то это просто апстрим полный идиот и майнтейнеру следует за ним следит. Ну, например, взял и у функций количество параметров увеличил, никому не сказав, или уменьшил. Ну, так не делают, конечно, но некоторые так делают. Предположим, эти символы разные. Является ли это причиной того, что старую библиотеку нельзя заменять на новую? Мы не только составляем множество символов, но мы еще и составляем такой граф: какие символы какими пакетами потребляются в рамках всего хранилища. И если выясняется, что мы помещаем библиотеку, в которой удалено 10 символов, но есть только 1 пакет, который этими 10 символами пользуется, тогда наш обмен будет выглядеть так: пересобери, пожалуйста, воооон тот замшелый пакет 2005 года производства с новой библиотекой и что-то там с ним сделай, потому что он пользуется вот этими деприкейнтными символами. Все остальные клиенты этой библиотеки этими символами не пользуются, они будут продолжать работать.
Если отслеживать такую более тонкую зависимость по именам символов, то проблема «дурацкий апстрим все время обновляет версии» или «дурацкий апстрим никогда не обновляет версии» частично решена. Частично, потому что ситуация «апстрим увеличил размер структурки», «апстрим, никому не сказав и не изменивши soname, поменял порядок параметров функции» - это, естественно, можно отследить только глазами. Что еще?
-параллельная сборка на хороших мощностях. Сборочница может предоставлять вам нормальную собиралку. Я свою LibreOffice собираю только на сборочнице, потому что, ну, там 32 процессора, 32 ядра, он в 4 раза почти быстрее собирается. 40 минут у меня собирается, а не двое суток.
-лицензионная чистота - все эти пакеты можно скачивать, устанавливать и распространять. Те, которые нельзя скачивать и распространять, нужно скачивать с сайта производителя и дальше страдать.
- Доступность и зеркала
Поскольку свободное копирование - мы можем брать и делать локальное зеркало, например, у нас на факультете есть зеркало репозиториев альтлинукса, так что обновление дистрибутивов может происходить со скоростью десятимегабитной.
И у нас осталось 5 минут, за них расскажу то, что у нас в Базальте называется дистрибутивом.
Вообще, дистрибутив - программный комплект, который посредством установки превращает ваш компьютер в компьютер с работающей операционной системой, вот вам определение. У нас есть нечто, что распространяется, поэтому оно дистрибутив, берем носитель с этим нечто, запускаем какую-то программу, которая называется установщик и в результате этого установщика у нас на компьютере внезапно оказывается операционная система. Либо, возможно, это делается без установки: ливфлэш втыкаем, загружаемся и у нас внезапно оказывается операционная система на компьютере.
Т.е. дистрибутив - набор пакетов из хранилища (по секрету скажу, установщик - тоже пакет из хранилища, просто, как правило, если это не лив версия, где все пакеты уже установлены на флешку, то это такой склад пакетов и установщик: системы и пакетов. Или же пакетов на флешке не установлено, это маааахонькая такая флэшечка, вы втыкаете, она настраивает сеть и все пакеты скачивает по сети). Так вот, дистрибутив - такой комплект, который будет распространяться под маркой «альт», «дебиан», или «федора» поскольку такой комплект и есть предмет распространения - требования к его качеству и работоспособности, разумеется, выше, чем в среднем по палате ко всему хранилищу, потому что понятно - сколько у нас будет пользователей - во столько больше раз поток сообщений об ошибках и доработках от активных пользователей мы получим. Поэтому хорошим тоном долгое время являлось т.н. эшелонирование хранилища, когда у вас есть текущее хранилище, где у вас может быть все разломано, ну, в частности, у нас такого нет в альтлинукс тим, пакеты устанавливаются и работают, по крайней мере устанавливаются, а то, что они работают, обещает майнтейнер, а ситуация, в которой у нас есть вообще над этим мусорное ведро входное, в которое складываются пакеты на потестить.
Дистрибутив:
- Нестабильное хранилище
Дальше из него делается т.н. ветка
- Стабильная ветка + доработки - значит, что мы в какой-то момент запрещаем изменения в нашем хранилище за исключением тех, которые исправляют ошибки или добавляют Точно так же в этом комплекте из тысячи пакетов, называемым хранилище, можно сделать такой срез и сказать: мы их сейчас разделим на 2 части, вы разработчики продолжаете разрабатывать, а те люди, которым интересно сделать постабильнее - давайте, идите сюда и ищите ошибки, если какие-то секьюрити претензии будут - их надо точно исправлять, если пользователи захотят новую версию - ее нужно будет туда положить. И вот на базе этой стабильной ветки + какой-то доработки, ну, как правило, это доработки типа доделать нескучные обои, по требованию заказчика вставить шифрование дисков по умолчанию и т.д.
Подмножество этой стабильной ветки оформлено в виде инсталляционной программы или программы развертывания на лив сиди на носителе и есть дистрибутив. По крайней мере, по версии большинства комьюнити. В случае дебиана дистрибутивом называется прямо само хранилище, потому что у дебиана эшелонирование появилось первым: там этих хранилища всего 4: экспериментал, анстейбл, тестинг, стейбл, и считается, что дебиан полиси (дисциплина разработки) настолько строгая, что ты берешь сборку из этих пакетов и она сразу ставится, и так действительно и есть.
Кажется, я сказал все, что хотел, да и время уже прошло. А, еще поддержка, но, слушайте… Я могу сказать только то, что поддержка, как правило, не дело комьюнити. Поддержка, как правило, дело той конторы, которая делает на этом бизнес, потому что за поддержку деньги платят вот такие, и их платят не за эти мифические 10 трудов, а за настоящие труды: за заказную доработку, за приезд и исправление ошибок, за деплоймент, за вот это вот все. Поэтому это очень хороший бизнес для свободного софта - ее поддержка там, где она требуется выше того, что нам даст комьюнити.
На этом хочется закончить этот кусок лекций, напоминаю, у нас остается открытым вопрос, чем в точности мы занимаемся в следующем семестре, было бы неплохо, если бы вы поспрашивали у знакомых, может быть, им тоже что-то интересно.
Список вопросов на экзамен опубликован, вжжж. Напоминаю, что экзамен устроен так, что мы собираемся и в течении какого-то времени беседуем на все темы, после чего вы получаете любую оценку, какую вы захотите, но не выше той, которую экзаменатор сочтет нужным вам поставить. Можете вообще не получить оценки.