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

Лектора зовут Георгий Курячий, он работал системным администратором на факультете в прошлом тысячелетии, в этом тысячелетии большую часть работы по администрированию факультетской сети выполняет Роман Кондаков. В этом семестре читаются лекции по сопровождению пакетов. С 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 способа использования:

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

Довольно забавный пример несв. лицензии — лицензия 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, но, возм., не так часто не всегда, только по опр. тематике и так далее.

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

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

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

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

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

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

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

LecturesCMC/PackageMaintaining2009/Conspects/01/eSyr (последним исправлял пользователь eSyr 2009-10-04 13:26:22)