Материал из eSyr's wiki.

• Аудиозапись: http://esyr.org/lections/audio/uneex_2009_winter/uneex_09_09_30.ogg

[править] Конспект Kda

[править] Введение

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

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

То, о чем будет идти речь, затрагивает всю структуру дистрибутива и свободного ПО. Не инструкция по сборке пакета в Сизиф АльтЛинукса, а общий рассказ о сборке пакетов на примере Сизифа, будет также речь о BSD и других системах.

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

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

Дальше в планах рассмотреть весь путь от апстрима до его попадания в дистрибутив. Некоторые примеры из известных лектору технологий разработки дистрибутивов. Под конец — краткая методичка по разработке пакета.

10 планируемых лекций. Еще одна, а то и две пары, которые не будут заняты плановыми лекциями, там будет свобода маневра. Выяснится тема, которой нет, а интересна. Или рассказ еще кого-то о других системах.

[править] Дистрибутив на базе свободного ПО

Понятие дистрибутива как такового приобретает специфический уникальный смысл. Несмотря на уникальность, понятие дистрибутива существует давно, еще до изобретения свободного ПО. Беркли — классический дистрибутив. Таким свободным дистрибутивом он и стал, когда в 80-х стали заморачиваться на свободность софта. Дистрибутивов на базе ядра линукс порядка 300 штук, из них живых, активно обновляющихся меньше.

Что такое дистрибутив ОС? Здесь важны обе половинки.

[править] ОС

Начнем с конца. Если мы определили, что такое дистрибутив, чем отличается дистрибутив ОС? Мы получаем, устанавливаем и получается ОС на компьютере. Дистрибутив Denwer он дистрибутив, но не ОС.

[править] Дистрибутив

Свойство дистрибутивности, распространяемости. На развалинах чего был создан первый прообраз юникс — мультикс, по заказу минобороны США. Установок этой системы было две или одна. Когда речь идет о дистрибутиве — обратная ситуация. То, что разрабатываем, должно распространяться. Не так очевидно, но понятие распространения, дистрибуции будет сужаться. Предоставление услуг сервиса через браузер. Там нет дистрибутива, а один сервер и сервис на нем.

Совокупный программный продукт. Часто дистрибутивом называют установщик, устанавливающий одну большую программу. Здесь программ много, дистрибутив состоит из них.

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

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

[править] Свободное ПО

Отдельная тема для тех, кто не в танке. Что такое свободное ПО? Начать нужно с того, что есть классическое определение свободного ПО, которое достаточно просто формулируется, данное Столлманом. Это ПО, которое не накладывает никаких ограничений на 4 способа использования этого ПО. Предоставляется 4 права. Право использовать программный продукт. Право изучать и изменять программный продукт. Нет запретов на реверс-инженеринг, но более верное определение — есть исходный текст. На сегодняшний день не так много систем подразумевают отсутствие исходного текста. Есть система без исходного кода, с объектами. Там нет исходного кода, но право изучать и изменять не нарушается. Право распространять. Право распространять изменения.

Определение Open Source. Состоит из 10 пунктов, все 10 пунктов перечислить лектор не может, не вполне совпадает со свободным ПО. В Евросоюзе эти лицензии объединены законодательно в одну.

Довольно забавное ограничение в старых BSD-лицензиях. Должны сохранять имена всех людей, которые внесли вклад в разработку. Ограничение лицензии PHP — ПО должно начинаться со слова PHP.

[править] Copyleft

Популярное ограничение — понятие copyleft. Что такое copyleft? Имеем полное право что-то модифицировать и превратить в несвободное ПО. Все BSD-системы так и распространяются. Такая лицензия называется разрешающей. Эта стратегия очень удобна для могучих BSD-шников, каждый из которых сам себе дистрибутив.

Если же мы продаем программный продукт, то есть лазейка. Вкладываемся в фичу, получаем преимущество, начинаем распространять. Конкурент берет свободный код, доделывает то, что не доделали мы, и начинает распространение несвободного кода. Проблема не в том, хорошо это или плохо. Проблема для бизнеса, если нет возврата кода. Когда на продаже несвободного софта можно получить преимущество, в добавок к 4 правам вводится обязанность. Право распространять и распространять изменения должно быть реализовано так, что распространяемое нами должно распространяться не хуже, чем по этим 5 пунктам. Гугл пользуется, но никому не дает, не распространяет.

[править] Дополнительно

Самих свободных лицензий насчитывается несколько десятков штук. Чем они отличаются, понять сложно. На это накладываются юридические тонкости. Мировая тенденция к сокращению количества лицензий. Но есть свои лицензии у крупных корпораций — майкрософта, сана и других. Разговор о лицензиях вполне допустим. В рамках российского законодательства они применяются.

[править] LGPL

Что считать производным программным продуктом? Если не вносим изменений в код, то скомпилированные с ним продукты могут быть несвободными.

[править] Сообщество

Более важная вещь — разговор о том, кто все эти люди? Цикл лекций под названием «Дистрибутивы Линукс», вылившийся в разговор о сообществе.

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

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

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

[править] Принципы свободного сообщества

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

[править] Структура

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

[править] Требования к окружающей действительности

Требований два. Информационное пространство — динамичность и связность. Технологическая привлекательность ресурсов. Кто мне, как программисту, мешает взять программный код и похакать? С какой стати я буду закладывать код обратно? Просто нет времени. Нужно, чтобы проще было быть участником сообщества, чем не отдавать свои результаты и делать в разных местах самому по-разному.

[править] Организационный вопрос

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

Просьба ко всем собравшимся разрекламировать данное мероприятие.

Лектора зовут Георгий Курячий, он работал сист. адм. факультета в прошлом тысячелетии, в этом тысячелетии сис. администратором работает его ученик, Роман Кондаков, а лектор консультирует. В этом семестре читаются лекции по сопровождению пакетов. С 2003 года лектор работает в Альт Линукс, поэтому в последнее время лекции имеют явно линуксовую направленность.

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

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

Что же это такое на самом деле: в случае в Linux, мы имеем способ разработки, не такой, как в других видах ПО (несвободных). Когнда речь идёт о дистрибьюции, мы сталкиваемся с довлоьно интересным соц. и техн. явлением, как "человек, сопровождающий пакет". Более того, практика лектора в Альте и практика работы в Солярис и BSD, что вот эта самая деятельность, с одной стороны, требует дост. хорошей базы в области ИТ, с другой, не требует ярко выраженных, чрезмерно глубоких skills, не требует предв. глубокого влезания во что бы то ни было. Это большой бонус для челоаека, получ. общетехническое образование. Если вас научили круто программировать на С++, то вам придётся много ещ узнать, а если вы в общем предст., как устроена система, как собираются программы, как орг. система, то задача сделать так, чтобы та программа, которая нужна, оказалась в нужном дистрибутиве, она очень простая. Задача ручной сборки даже сложнее, чем задача сопровождения пакета (по количеству бессм. действий).

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

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

Что касается лекторов, лектор недавно обнаружил, что если исключить из списка разных роботов (например, Виталий Липатов имеет build farm, который собирает примерно 3000 пакетов для примерно 15 дистрибутивов), то окажется, что лектор ментейнит дост. большое количество пакетов.

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

План курса:

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

Такой план на будущее.

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

На этом лектор заканчивает вводную часть и начинает ту чатсь, которая отн. к собственно первой лекции --- дистрибутив на базе СПО.

Как лектор сегодня сказал, само понятие дистр. как такового, если речь идёт об СПО, обр. дост. уникальный в общем плане всего ПО, смысл. Не смотря на это, понятие "дистрибутив", оно сущ. очень давно, ещё до того, как было изобр. понятие СПО. Например, BSD, этоклассический дистрибутив, но если поглядеть на те принципы, которые в него заложены, но декларировались, то мы увидим, что это типичный свободный дистрибутив, каким он собственно и стал в 80-е годы, когда этим стали заморачиваться. Как только это произошло, то сразу выяснилось, что BSD-системы расп. именно под свободной лицензией (сейчас популярны примерно 5 — free, Bet, open, dragonfly, pc). Для сравнения, дистрибутивов на основе linux порядка 300 штук. (по поводу gnu --- весь самыцй страшный код в linux-дистрибутивах именно тот gnu тех хакеров, потому что они могли писать грязный рабочий код)

Что такое дистрибутив ОС. Здесь важны обе половинки. Каждую из этих половинок надои интерпретировать. Если мы опр., что такое дистрибутив, то чем отл. дистр. ОС: есть нечто, вы его устанавливается, и врезультате получается ОС. Например, дистр. denver это дистр., но не ОС. А здесь есть голый компьютер, вы втыкаете в него блин и получаете работающую систему. Это понятно, но понятность базируется на том, что ОС это такой прогр. продукт, который сост. из частей, каждя их которых предст. собой прогр. продукт.

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

Есть мнение, что вскоре понятие распр. начнёт сокращаться за счёт SaaS.

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

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

Что такое СПО. Есть классическое опр. СПО, которое, собственно, и дал Столлман, великий и ужасный. К сожалению, у лектора не твремени раскр. технологическую важность каждого пункта, но тем не менее: СПО — такое ПО, которое не накл. никаких огр. на 4 способа использования:

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

Есть По, которое не может быть свободным: напримеР, ПО для упр. телескопом в Неваде.

Довольно забавный пример несв. лицензии — лицензия PHP. Там есть пункт: "вы можете расп. какие угодно модиф., но в названии должно быть слово php"

Дополнение gq: важный пункт --- интеграция.

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

Мы поговрили о том, что классич. опр. СПО ... да, чтобы отмести всякие разночтение: есть опр. open source, оно дано другими людьми с похожей ситуацией, оно сост. из 10 пунктов, оно не вполне совп. с СПО, но эти различия не вполне понятны. Вплоть до того, что в европе принята откр. лицензия FOSS, то есть, всё свалено в одну кучу.

Какие можно наложить поверх СПО: например., огр., накл. в BSD — вы должны сохр. все упоминания авторов в комментариях. Если посм. в, напр. FreeBSD, то первые неск. килобайт любого сишного файла --- имена сотен авторов. Иногда огр. могут сделать лиц. несвободной. Типичное и популярное огр. --- понятие копилефта. Что такое копилефт: если вы получаете на руки некий исх. код некоей св. программы, то вы формально имеете полное право что-то намодиф. и превратить её в нсвободную. Никто не мешает это делать. Все bsd-подобные лицензии расп. под такой лицензией, она наз. разрешающей, примеров тому масса: macos X, juniper, примеров масса. Эта стратегия очень удобна для могучих bsd-шников, который каждый сам по себе уже дистрибутив: он и дизайнер и программист и с железках разбирается, и если ему заплатить, то но сделает что хотите. Это удобный способ, если вы продаёте своё рабочее время. Если вы продаёте продукт, то bsd-щная лицензия даёт лазейку --- вы можете вложиться в некую фичу, начинаетее её расп., поск. расчитываете на преимущества СПО, но приходит конкурент, берёт ваш код, вкладывает туда ещё что-то и начинает расп. своего несв. кода, сделанного на базе вашего, и получать на этом деньги. Проблема в том, что если вы хотите зарабатывать именно на продукте, то те улучшения, они потеряны --- сама разработка старадает, что люди берут и не возщвращают.Для предотв. этого вводится ограничение --- вы можете расп. изм. прогр. продукт на условиях не хуже, чем данная, например, на той же лицензии. Тем самым, что вы делаете --- если конкурент взялся ваш вытеснять, то он вынужден будет их расп. с исх. кодами. Это не касается единич. внедрений. Например, гугл — он очень сильно завязан на СПО,но он мало чего открывает, поск. он ничег оне расп.

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

Разговор о лицензиях у нас вполне допустим, в частности, GPL имеет валидность в рамках российского законодательства. Самих лицензий довольно много — например, есть промежуточная LGPL, отл. в том, что считать derivated продуктом: если изм. код, то понятно, если же вы не меняли ни байта в исх. коде, но продукт, получившийся в рез-те линковки с библиотекой, она наследует лиценизю или нет? По LGPL это может не наследоваться (этим пользуются чатсо тулкиты), а GPL — обяз. наследуется.

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

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

В случае откр. разр. Тут тоже моного неквалиф. раб. силы, но она применяется не для того, чтобы писать много грязного кода, а, наоборот, чтобы внести пропорциональный вклад. И так, как правило получается, что наиб. вклад вносят люди наиб. талантливые и наиболее в этом смысле качественные. Второе --- откр. сообщества, эти люди общ. не только в офисе, но и со всем миром, св. проекты, как правило, включают людей из разн. стран. Главное --- у вас, как у лидера подобного сообщ. есть возм. привлечь потенциально колько угодно народу, лишь бы привлекли. И это накл. отпечаток: если у ас 10 человек, то можно просто на диске хранить, а когда их 1000, то это не работает. И с этим связн тот факт, что чем больше сообщество, тем оно технологичнее, в то время как не во всех конторах про vcs знают. И при отрытой разр. дост. бессм. пытаться соср. права на код в каких-то одних руках, поск. разработка тогда будет неоткрытая. Как правило, человека, который манип. этом кодов в случае св. разр., довольно тяжело орг., на это должны быть причины внеэкономические.

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

Св. сообщество. Три принципа, на которых строится свободное сообщество:

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

Лектор не будет говорить про то, почему это позв. сформировать единицы социума.

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

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

Картинка.

У свободного сообщ. есть ядро: люди, которые делают осн. работу и принимают осн. решения. Ядро должно быть маленьким, ядро с собой договариваться.

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

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

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

Часто разр. явл. пользователями в других проектами. Главное --- не относиться к программам как к данности. Сбственно польз вообщество --- они польз. продуктом, будоражат пространство. Если нет польз., то ядро и разр. договорятся и сделают такую кривульку...

Какие требования предъявл. к окр. действ., чтобы в ней могло зарод. своб. сообщ., св. с СПО:

* Связность и динамичность инф. пр-ва. Что имеется в виду: если эти люди вынуждены были ехать друг к другу в гости, чтобы обс. свои нас. проблемы, то скорость сообщ. как инстр. разв. СПО, работала в десятки и сотни раз медленнее. Были примеры подобного: академические сообщ. в США, когда связность была обесп. конфренциями, где обменивались кодом и идеями. В случае прогр. продуктов и вообщ. сообщ необх., чтобы инф. пр. было связным и динамичным (то, что видно соотв. тому, что есть на самом деле). Лектор приводил в пример китай: в прошлом десятилетии в китае свободных проектов не было вообще, потому что не было связности.
* Технологичность. С какой стати кладётся обратно похаканный код? Чтобы таких вопр. не возн., в сообщ. есть технологии для автоматизации внесения изм. в кодовую базу. Тезн. привлекательность рес. сообщества: проще быть участником сообщества, чем им не быть.

В след. раз поговорим о сообщ. вокруг дистрибутива.

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

В след. раз осталасть тема про сообщ. вокр. дистрибутива и говорим про пакеты.